中小项目敏捷实践之一（关于项目所有者和责任人）

**开发方法是一个系统工程，需要所有项目活动的相互配合。**

本心得是基于近两年两个中小项目(一个2000 Manday, 一个1500 Manday)的实践总结，希望能与大家一起探讨和进步。

- 要有明确的项目所有者
- 项目所有者愿意并有时间参与项目讨论，并帮助团队做出决定，如定时的问题讨论，重大问题决定
- 项目所有者能积极提供项目的反馈
- 每个模块都有指定的责任人，各司其职，共荣辱同进退

[u][b]项目所有者[/b][/u]

如果对应着CMMI的理论，项目所有者就是项目干系人。

所谓项目所有者，指的是项目的收益人，指的是[color=darkred]由这个项目的成败而收益[/color](经济效益，荣誉光环，等等)[color=darkred]或倒霉的人[/color]。反过来说，如果项目的成败对一个人一点影响也没有，你还觉得他还会关心这个项目吗？

项目组需要好好地“利用”项目所有者。请不用自责，因为一个真正的敏捷的项目所有者会比你想像中还积极地参与项目，是非常乐意被“利用”的。就拿我们项目来说，我们的项目所有者就主动跟我们说，如果有哪位客户和你们提出了不合理或不合适的需求，你可以让我来帮你们协调!推都推不掉。 :D

敏捷项目中的项目经理有一个重要的职责就是寻找、确定项目所有者，需要项目所有者在沟通时使用“我们的项目”而不是“你们的项目”。甚至去转变原来不是很敏捷的项目经理的观念。不过不得不承认，这很难。

理想的情况是项目所有者与项目团队能够处在同一个工作环境，或者至少也能做到定时的项目讨论。

[u][b]项目职责[/b][/u]

项目职责就是常谈的Ownership。

敏捷团队强调的是每个团队成员都有清晰的职责，项目由团队共享，成功是整个团队的成功，失败是整个团队的失败，共荣辱同进退。所以敏捷团队应当是一个互帮互助、相亲相爱的团队。

在敏捷团队里，文化比制度来得重要。

这个看起来有点矛盾，我们还是分开来分析。

先说职责，这会要求每个团队成员一定要做好自己的工作，在每个人都把自己的工作做好的情况下，整个项目就可以成功。其实这是不一定的，谁能保证边界与边界之间没有一些缝隙呢。单纯的以“职责”来管理，是边界明确的管理，是一种只有“是”和“否”的管理，是一种很[color=darkred]“生硬”[/color]的管理。

再说敏捷，敏捷是一种比单纯的职责管理更进一步的管理，把那些生硬的职责用[color=darkred]“柔性”[/color]的文化包装起来。使模块与模块之间互相沟通，互相交流，密切合作，水*乳*交*融 (乳*交是个关键字，长知识了 :D )。而这些柔性的部分，是项目中最难通过管理解决的部分。

当然，这些柔性的特点给人一种不可控或者混乱的感觉，也正是由于这些柔性的特点，造成了敏捷的两大误解。

1. 敏捷只适合由优秀程序猿组成的团队。
2. 敏捷不适合大项目。

其实不然，我们会看到下面的两个例子并不需要敏捷成员有多优秀，却做到了很多各自为战优秀程序猿做不到的事。

例如，敏捷团队会在平时的交流或Daily Meeting中出现下面的场景。

[quote]程序猿A：Hey， 程序猿B，我的模块的输出由NUMBER(18,2)改成了NUMBER(18,5)，你注意到了这个改动了吗？
程序猿B：完蛋，只注意到了你输出的数据类型没变，没想到精度有变化，太谢谢了。[/quote]

[quote]程序猿A：Hey， 程序猿们，我今天写了一个很common的计算费用的方法，对你们有用吗？
程序猿B：太棒了，我明天正准备写一个类似的方法呢，我们下来研究研究，看看是不是可以共用一下。[/quote]