敏捷软件开发之Scrum/Sprint(3)

　　Self-managing: 以前领导布置了任务，我们实现就可以了，现在要自己挑选任务;每次sprint 结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自我管理”不等于“没有管理”。

　　Self-organizing: 以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。

　　cross-functional: 以前spec 由PM 来写, test 由测试人员来做, 现在每个人都全面负责，自己搞定spec, 和别人沟通, 同时自己搞定测试。

　　如果你的团队很弱, 那么强行把Scrum (或者其它高级方法)套在上面也没有用, 也许还会适得其反，往往需要多次Sprint 才能让Scrum 走上正轨。换句话说, 如果你的团队已经是这么厉害 (self-managing, self-organizing, cross-functional)的一帮人, 那么用不用Scrum 都能写好软件!

　　经验:

　　这里有一些实践者的经验教训:

　　ScrumMaster 不是一个官，而是一个没有行政权力的沟通者，就像微软的PM 那样。她同时还要在团队中做具体的工作。直接把原来的 “经理”变成 ScrumMaster 大多行不通。

　　在一些公司中，不少项目需要很多暗箱操作和政治角力才能搞定, Scrum 会把这些矛盾都摆到明处。这有好处，也有风险。

　　在复杂的项目里，要让一线团队成员做决定。

　　创业公司的团队其实经常是运行在 Scrum 的模式中 (只不过大家太忙，没功夫论证到底多么Scrum)。

　　在Scrum 计划阶段的估计不是一个“合同”, 领导们不要把它当成一个合同。估计总是不准的。 坚持短期的Sprint，即使不准的估计也不会有大的损害。

　　不要和管理层谈 “流程”, 他们只关心 “结果”。

　　在大型团队，复杂项目中，Scrum 并没有非常完美的答案，Scrum 的创始人也承认这一点。 (我曾看到30多人挤在会议室里搞 Daily Scrum，一叹! )

　　总结:

　　Sprint/Scrum 对项目的众多需求采取分而治之的办法, 能让相关人员集中精力, 在一定期限内解决部分问题。

　　它强调短时间的迭代 (iteration)， 在多次迭代中不断总结, 改进团队的流程和产品功能。

　　它明确地指出不同人在一个项目中的投入和责任的不同 (猪和鸡), 并坚持让全身心投入的“猪”来主导项目。

　　它通过 daily scrum, ScrumMaster 等方法和角色，鼓励团队内部交流并优化团队和其他人员的交流方式。

　　它对团队成员提出了很高的要求, self-managing， self-organizing， cross-functional。 一般人不能马上做到这一点。

　　它不是 “银弹”，不能解决软件开发的所有问题，至于具体项目进度如何跟踪, 如何管理测试工作， 如何管理复杂项目, 还要靠战斗在一线的团队成员见招拆招，想出合适的办法。

　　SCRUM 视频: Scrum 看似容易, 门道挺多, 这里是一个视频系列，大家可以观赏: http://blogs.collab.net/agile/scrum-training-series

　　思考题:

　　在一个冲刺中, 团队预计每天的进度为 30 小时。当项目完成了一半的工作量的时候, 大家发现实际的进度为15小时/天, 问: 在余下的时间中, 团队的进度要到多少, 才能在项目结束时让整个项目的平均进度恢复到每天30 小时?

原文转自：http://www.ltesting.net