Scrum 开发回顾

在目前的项目中实践scrum的这种开发模式已经有半年多，遇到了来自于个方面的很多问题,首先说明我对Scrum了解很肤浅，将来可能会有更多的问题，下面对这些问题的一些回顾和思考。

简单介绍下scrum的一些基本要素：

我们遇到的一些问题：

1- 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。 > 责任心不是每个人都会有，这和性格、素质和既得利益有关, 实践中团队成员不可能都专业，称职并富有责任心,如何解决？想法：找专业有责任心的人,其它的趁早走人

2- 技术负债问题，开发过程中没有充足的技术准备，虽然可以通过TDD、连续集成、重构减轻,但是效果依然不佳。 > 尤其在新手较多的团队，很多成员都没有接触过相关技术，需要边做项目边指导，但是每个sprint task压力依然存在，导致硬着头皮让新手去完成，代码质量低下,基本要重写，增加团队其它成员工作量。经过长期的恶性积累给项目造成极大的风险。传统的瀑布式开发技术负债是较少的，敏捷开发不是瀑布式开发的对立面，必须在实践中结合两者的优势。

3- Scrum团队中很难掩饰自己能力的不足,但这些成员通过消极怠工来掩饰自己能力的不足。 > 团队虽然一直努力帮助较弱的团队成员， 但较弱的成员必须表现出：a)主动 b)努力 c)对结果负责,如果不是这样，只能走人。

4- 过度关注短期目标，长期注定还是会失败,要挽救需要2-3倍的精力，而且风险极大。 > 项目功能需求和模块设置目标短期，需求分析不充分，导致数据库模型频繁更改，代码有不同的开发者频繁更改，难于维护，加上单元测试不充分和没有测试人员回归，即使重构风险也极大。

5- Scrum Master 无法对项目业务和技术细节做全局的把控，没有很好的code review的机制,导致沟通成本增加。 > 项目中经常出现,一个task分配给一个成员，这个成员是没有一个全局的业务理解的，当他需要去完成这个task的时候，可能会导致对这个task的错误分析，造成不必要的问题，如果这个成员是新手而这个task的业务相对的复杂，这个时候代码就相当可怕，需要2倍的精力来维护和重构它，目前项目中很多这种问题。

6- Code Review 种的问题无法彻底解决，经过多次code review 重复问题。 > 项目中code review 过的问题，反复出现，这固然和团队成员的代码水平有关，更重要的还是态度，项目中新手（可能包括一些老手）的代码基本写一遍就过，基本不重构，单元测试覆盖度低下，code refactor 的思想的难于推广。

7- 在SCRUM中，明显的提到，在会议中每个人只可以说三件事情: a) 我昨天做了什么 b)我今天准备做什么 c) 我在工作中遇到了什么障碍 > 目前项目的实践太多的谈到了实现细节和业务需求，由于需要向新手详细的解释这些问题，由于没有一个成员(包括scrum master)多无法对业务有一个全局的了解，每人只是了解自己的业务，需要多人用很多时间讨论，得出的结论还不一定是最好的实现。

8- 没有回顾会议(retrospect meeting) > 用Scrum的回顾不断地做改进，从而趟出自己的一条路。如果这个Sprint我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review机制, 但是目前项目中没有这种不断改善和提高的会议，退一步说如果有了，如何去发现存在的问题，如何改进，如何达成一致有效推进这些改进？

9- 关于scrum 团队人员的要求，自我管理、自组织、跨职能，这三点要求实际上很难做到。
> a) 每次sprint结束之后,还要总结不足,提出改进,并且自己要实施这些改进，新手则要求更高，”自我管理”不等于没管理。 > b) 每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。如何做到？ > c) 以前test由测试人员来做,现在没有测试，每个人都全面负责,自己搞定文档,和别人沟通,同时自己搞定测试。如何做到？

我始终认为ScrumMaster是Scrum实施是否能够成功的关键。目前项目中ScrumMaster就是招呼大家开开会， 分配task, 记录每个人的进度而已。真的就这么简单吗？以上观点并不是反对scrum,只是提出问题，问自己也问大家，Scrum 并没有非常完美的答案，Scrum 的创始人也承认这一点。

107 Words 13 March 2013 Suzhou, China