公司中层最近开始推scrum敏捷开发，落实到行动上大概有这么几个方面： 定期迭代，小步快跑； 产品经理创建Backlog（需求列表）； 团队进行需求评审； 开发团队组织会议，对需求进行细化，分解成一个个可以执行的具体任务（task）； 开发团队每人主动认领当前开发周期内的task，要求认领的Task不能主要是自己熟悉的部分； 及时同步Task进度到Jira上； 每天下班前站会，总结今天的工作内容，说明明天的工作计划； 当前Sprint完成后，进行总结会议，每人预先准备好总结内容，轮流发言。 实际上类似的流程我们的团队一直在进行。不同的是第5条，对于这种形式我多少持有一些保留态度。 其实第5条这种形式的优势是显而易见的： 能够促进团队成员熟悉所有的产品线； 不会出现一人缺席，一块功能就无人对接的情况； 避免团队成员挑活儿； 团队成员也能在产品、技术等多个层面得到全面的收益。 缺点则相对没那么明显：对于一个产品的每个子工程来说，它的负责人是流动的，换言之就是没有具体的负责人。正常情况下这当然是OK的；出了些问题也没什么大不了，全员一起扛，群策群力也能解决掉。但是一些中间的情况却可能出现问题，影响有这么几个方面： 每个工程有多个人插手，可能会出现整体风格的混乱，也容易出现一些互相拖后腿的情况； 因为不对具体的工程负责，可能就不会深入了解工程的每个细节； 同样因为不对具体工程负责，在需要做一些优化时，也许不会很流畅的进行下去。 举个例子吧：某个团队开发成员在偶然的情况下，发现某个模块需要做些优化，这个优化的效果可能在当下并不明显，不过却需要耗费一定的时间和精力。比较好的情况是，这个人比较有责任感，把这个情况上报了并且能够让团队领导认可这个优化有执行下去的必要性，那么这个优化就有可能被加入到下一次的Sprint中；在下一个Sprint中，负责这个优化的人，碰巧同样认可这个任务，对这个任务的了解也比较深入；那好这个人开始进行工作了，在工作中他发现这个优化需要改动大量的现有代码，比较幸运的是这个工程中的整体风格是一致的，在梳理现有工程上他只需要化费比较少的时间，其他同事也非常配合地帮助他修改各自曾经负责处理过的部分，他的态度也非常的积极，在指定时间内完成了这项任务。这样这次优化算是完美的实现了。 这个例子我写得并不痛快。只是想通过这个例子说明在这种模式下进行开发可能会面临的一些问题，这种模式的展开最需要的就是一个完美的团队：团队成员需要积极负责，团队成员间的沟通成本不能不够低，团队的每个成员对于问题的认可需要保持一致，甚至团队的编码风格等细节也有具体的要求。可想而知，比较困难。