敏捷资料笔记

敏捷方法经验：

http://www.csdn.net/article/2013-03-25/2814622-cto-club-95

重点摘要：

1. 集中规划和项目推演。这样做的好处是：研发、测试团队和和项目经理Scrum Master一起深入理解项目要求，测试团队也应此能够更早地开始编写测试脚本，也避免了后期矛盾。
2. 站会，每个人都是众星捧月的明星。站着开会带来的紧张感和疲劳感有效地避免了过于冗长的会议。同时，让发言者站在中间的做法更能增强其自信心和责任感。
3. 团队自我驱动所做的一系列优化： 明确只有可用的功能才算完成；明确项目目标；把目标分配给明确的负责人；严格要求代码提交环节；由敏捷教练管理，明确每个人的观点；优化团队规模等等。同时要避免整体重构，尽可能局部重构。项目经理更需要确定项目能否完成而不是仅是关注项目进度。
4. 持续集成和产品演示环境。自动化集成和演示环境，省去了很多重复的工作。
5. 别开生面的复盘会。在复盘会上，队员都需要完成自评和他评，绩效与任务难度挂钩的方式也激励员工做有挑战的项目/功能开发。同时，严格的得失分析让队员更好地吸取经验和教训。
6. 保证质量可信度。虽然研发速度很重要，但是没有质量保证的快速开发非常危险，质量可信度是一项需要高度重视的标准。

Scrum 0的基本任务应该是将系统级故事分解为架构级故事，再将架构级故事分解为开发级故事，其目标在于了解系统、制定第一版本的需求列表和发布计划，以及明确随后1-2个迭代的开发需求。

因此Scrum 0的主要工作在于拆分 ——从角色的角度拆分、从实体的角度拆分、从目的的角度拆分、从解决方案的角度拆分！分解目的再拆分解决方案，通过拆分明了系统的业务流程，将项目分解为数据对象和业务操作，最后制定可行的开发流程和迭代计划。

打造最佳开发团队的建议：

http://www.csdn.net/article/2013-03-21/2814583-the-best-developer-team-structure

重点摘要：

1.

通常3-5个开发者围绕这一个PM（项目经理）能够达到最佳的工作效率。

PM是一个过于复杂并且常被滥用的术语，坦率地说，我非常讨厌这个词。这里我所说的 PM是指“解释、阐明项目需求的人” ，因此 从产品战略的角度PM需要有强烈的想法，清楚需要构建的是什么 ，但他们更重要的任务是 权衡从客户到设计师等等的全部利益相关者的需求，并据此制定计划。

2.

作为一个PM，你需要理解“团队”和“一群人”之间的区别：团队的工作方式更像一个单位；团队中有角色之分，比如四分卫、组织后卫，游击手等等，但每个人都为了同一个目标努力完成自己的任务。一群人则是指很多聚集仍在一起的人，而非一起工作的人。你需要构建的是一个团队而非一群人。

3.

组建团队的方式有很多种，这里列举一些：强制结对编程；通过将项目按组件分解，保证多人同时作业；技术设计与编码分离；降低WIP（Work-in-Progress）能够驱动结对乃至多人编程项目。

4.

每当我的团队增长到7-10个开发者时，我总会将它分为两个团队。不论是什么项目，10人的团队都过于庞大，这时候你需要以子团队为行动单位。团队划分应该很自然，需要能够明显地区分两个团队。有个非常有名的原则叫做“pizza原则”，就是说：如果两张pizza喂不饱你的团队，那么它太庞大了！

5.

新团队的组建不能凑合，不是随便雇5个人就能称之为一个团队，最好的方式是“有丝分裂”（类似于举荐）。

6.

如果你拥有多个团队，那么就需要有人来担当“首席架构师”一职。随着时间和团队人数的增长，这会很自然地成为一个任务。首席架构师不需发号施令，这只是一个头衔，但总需要有人顶着这个头衔！

这个角色更像是“软件设计协调者”，帮助所有人取得架构设计的共识。首席架构师如果做得称职会非常辛苦，因为他需要车前马后地与人辩论，并最终保证大家得到共识，但这正是关键！

7.

不要害怕修改团队的组织架构。和运动一样，队员间的化学反应非常重要！有些人在一起工作时能发出更高的工作效率，同时让员工做自己关心的事也很重要，致力于自己关心的工作通常也能带来更高的工作效率。我通常会安排合适的人去做他喜欢的工作。

8.

没有任何人愿意做的事，应该让所有人都轮流去做。如果你的团队是真正的团队，这就不会是什么问题，他们会愿意投入这些肮脏的工作。