浏览 5387 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2014-05-14
最后修改:2014-05-20
本心得是基于近两年两个中小项目(一个2000 Manday, 一个1500 Manday)的实践总结,希望能与大家一起探讨和进步。 - 要有明确的项目所有者 - 项目所有者愿意并有时间参与项目讨论,并帮助团队做出决定,如定时的问题讨论,重大问题决定 - 项目所有者能积极提供项目的反馈 - 每个模块都有指定的责任人,各司其职,共荣辱同进退 项目所有者 如果对应着CMMI的理论,项目所有者就是项目干系人。 所谓项目所有者,指的是项目的收益人,指的是由这个项目的成败而收益(经济效益,荣誉光环,等等)或倒霉的人。反过来说,如果项目的成败对一个人一点影响也没有,你还觉得他还会关心这个项目吗? 项目组需要好好地“利用”项目所有者。请不用自责,因为一个真正的敏捷的项目所有者会比你想像中还积极地参与项目,是非常乐意被“利用”的。就拿我们项目来说,我们的项目所有者就主动跟我们说,如果有哪位客户和你们提出了不合理或不合适的需求,你可以让我来帮你们协调!推都推不掉。 敏捷项目中的项目经理有一个重要的职责就是寻找、确定项目所有者,需要项目所有者在沟通时使用“我们的项目”而不是“你们的项目”。甚至去转变原来不是很敏捷的项目经理的观念。不过不得不承认,这很难。 理想的情况是项目所有者与项目团队能够处在同一个工作环境,或者至少也能做到定时的项目讨论。 项目职责 项目职责就是常谈的Ownership。 敏捷团队强调的是每个团队成员都有清晰的职责,项目由团队共享,成功是整个团队的成功,失败是整个团队的失败,共荣辱同进退。所以敏捷团队应当是一个互帮互助、相亲相爱的团队。 在敏捷团队里,文化比制度来得重要。 这个看起来有点矛盾,我们还是分开来分析。 先说职责,这会要求每个团队成员一定要做好自己的工作,在每个人都把自己的工作做好的情况下,整个项目就可以成功。其实这是不一定的,谁能保证边界与边界之间没有一些缝隙呢。单纯的以“职责”来管理,是边界明确的管理,是一种只有“是”和“否”的管理,是一种很“生硬”的管理。 再说敏捷,敏捷是一种比单纯的职责管理更进一步的管理,把那些生硬的职责用“柔性”的文化包装起来。使模块与模块之间互相沟通,互相交流,密切合作,水*乳*交*融 (乳*交是个关键字,长知识了 )。而这些柔性的部分,是项目中最难通过管理解决的部分。 当然,这些柔性的特点给人一种不可控或者混乱的感觉,也正是由于这些柔性的特点,造成了敏捷的两大误解。 1. 敏捷只适合由优秀程序猿组成的团队。 2. 敏捷不适合大项目。 其实不然,我们会看到下面的两个例子并不需要敏捷成员有多优秀,却做到了很多各自为战优秀程序猿做不到的事。 例如,敏捷团队会在平时的交流或Daily Meeting中出现下面的场景。 引用 程序猿A:Hey, 程序猿B,我的模块的输出由NUMBER(18,2)改成了NUMBER(18,5),你注意到了这个改动了吗?
程序猿B:完蛋,只注意到了你输出的数据类型没变,没想到精度有变化,太谢谢了。 引用 程序猿A:Hey, 程序猿们,我今天写了一个很common的计算费用的方法,对你们有用吗?
程序猿B:太棒了,我明天正准备写一个类似的方法呢,我们下来研究研究,看看是不是可以共用一下。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |