本文通过作者担任项目负责人的经历，探讨了敏捷开发的实际应用和挑战。作者指出，敏捷开发的计划应是动态调整的，初期的长远计划至关重要。同时，每日站会和回顾会议对于监控进度和风险管理具有价值，但需要团队有明确的目标和任务划分。文章强调，真正的敏捷开发需要“Self-Organized”团队，每个成员不仅对自己的任务负责，还要为整个项目负责。最后，作者认为敏捷开发的效果取决于团队是否适合这种模式。
不论怎样，生活还是要继续，我们就这样懵懵懂懂、半推半就地实践着我们自认为的敏捷开发……
前段时间，一个偶然的机会，我的工作角色发生了比较大的变化，开始做一个项目(Feature)的负责人，我们称之为FP(不是Fang Pi，是Feature Prime)。此时，因为两年多的实践结果并不理想，公司已经不再大肆鼓吹敏捷开发了，但是车子大了不是说刹车就停得住的，在我们的开发过程中还是掺杂着一些敏捷开发过程的元素，这也刚好让我有机会从另外一个角度重新审视敏捷开发。
作为FP，我的工作主要是制定计划、监控进度、预估风险和风险发生时作出相应处理。
首先，要说一下这个“计划”，一个项目的计划绝对不是一个静态的、一成不变的计划，项目的计划是要随着项目的进行不断调整以适应各种变化的一个动态的计划。当然，这并不表示项目初期的长远计划没有意义，项目刚开始的时候，一个比较长远的计划，对整个项目的开展具有重要的指导意义，很简单，凡事只有有了方向才能向前进。其实，这也常常是初尝敏捷开发者的一个理解误区，认为敏捷开发的项目都没有一个长远的计划。诚然，敏捷开发因为以小步快走的方式进行，所以更多的是短而小的计划，一个Sprint通常不超过三个星期，但这并不表示敏捷开发的项目就没有长远计划，只是这个长远的计划更多地是被项目负责人所关心的，开发团队更多的是关心当前或下一个Sprint要做的事儿。
再说“监控进度”和“预估风险”。项目的第一个Sprint结束后，我们开了一个Retrospective meeting(这个会议我一直是支持的，因为我认为阶段性的反思和总结是很重要的)，会上大家一致认为刚刚结束的一个Sprint里，团队成员之间的沟通太少，导致信息不同步，会议决定从下个Sprint开始恢复每天站会(Daily Standup meeting)。每天都进行一次15分钟左右的同步会议，对于FP了解项目的进度和估计可能的风险，都有很大的帮助，因为每天同步可以保证信息的实时性，而面对面交流则可以保证信息的准确性。可在我们团队里面，我慢慢地发现了一个问题，每次同步得到的信息都不是那么清晰，都有一些模棱两可、不是很确定的地方。究其原因，则是因为在Sprint开始之前，整个团队并没有设定一个明确的目标，而只是大致讨论一下，接下来的三个星期要做什么，至于做成什么样、具体怎么做则完全没有讨论。其结果就是团队成员在没有明确目标的情况下即开始工作，每天都在摸索中前进，所以在每天同步会上反馈的信息自然是模糊不清的。此时，Sprint Planning和Sprint grooming会议的重要性就体现出来了，这些会议的目的就是要整个团队明确设定当前Sprint的目标，并清晰划分每个人的任务(Task)，只有这些都清楚了，每天的同步会议才有更多意义。然而，在我们的实际情况中，这些意义又常常仅仅是为FP监控整个项目的进度提供了方便，开发人员则不太愿意关心这些，他们更多地是急于写代码去实现需求，用代码来实现自己的价值。这个时候，我们就需要一个能够真正做到Self-Organized的团队。”Self-Organized”通常译为“自组织”，我觉得译为“精诚合作”更为贴切，意思是说团队的每个成员不仅要对自己的任务负责，更要积极主动地为整个项目负责。总之，只有一个Sprint的目标清晰了、任务划分细致明确了，每天同步会议反馈的信息才足够准确，才能帮助FP更好地监控项目的进度并预估可能的风险。
洋洋洒洒千余字，总要有点结论性发言。首先，敏捷开发对于管理项目不能说不好，但是想做好很难。其次，想做好敏捷开发，必须有合适的团队，也就是”Self-Organized”的团队。所以，敏捷开发好还是不好，取决于它是不是你的那道菜。
-- 2013年8月
扫一扫
556
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
