《构建之法》阅读笔记

书中所写敏捷开发的原则大概如下：在满足客户需求，且迎合用户的需求的变化的过程中，使用简明的技艺，尽早提交满足用户的需求的软件。但是，软件提交后，其更新迭代还需要不断的进行，不断的根据新的要求，改进软件，提高用户的竞争优势。此外，还有一项非常重要，那就是注重团队成员的选取以及团队合作的效率，选取合适的人担当大任，使整个团队能高效率的进行工作。一言蔽之，处处恰到好处。

  敏捷流程大概如下：第一，找出完成产品需要做的事情，其次，决定当前的冲刺需要的事情，且这个过程中被细分的任务的时间不宜过长，由团队成员根据自己的情况来进行认领。再者，就是冲刺阶段，团队成员们火力全开，进行开发，同时还要每天开例会，辅以燃尽图来督促成员的项目进展。最后，得到软件的一个增量版本，发布给用户，同时根据用户的反馈进一步改进软件。一言蔽之，简单干脆，循环上升。

 敏捷流程遇到的问题的解决：需要考虑各个需求和任务之间的复杂依赖关系，且在计划中体现。解决团队成员中，任务分配不均衡的问题，以及个人能力适应问题。需要定义好任务是什么，不仅仅要在任务自述中说明自己的任务完成情况，还要说明未完成情况，还差多少能完成。此时就需要燃尽图了。燃尽图的规划：应有3个每天跟踪的时间值，实际剩余时间，预估剩余时间，实际花费时间。而且，燃尽图应该是短期的规划，因为长期的不确定性太强，会使得燃尽图功能失效。最后，当代码码完后，其实任务并没有完成，剩下还有许多需要解决的兼容性或者底层性的问题，往往会占据非常多的时间，对于此的任务以及工作人员安排需要得当。此外，每一次冲刺后，大家要放松一下，总结一下上次的经验教训，争取下一次做的更好，我觉得这个非常重要，不仅有益于阶段性总结，还能释放冲刺过程的压力，让开发人员有足够的精气神应付下一次开发。

  敏捷的团队：敏捷对团队的要求有自主管理，自我控制，多功能型，且关键还在每日例会上的规范与收获性上。对于成员来说，需要自己挑选任务，同时总结不足，提出改进，还要帮助其他落后了的工作人员。整个开发过程中，每个人都全面负责，自己搞规定说明书，和别人沟通，自己完成测试。

  书中所提的一些经验教训：

①   敏捷宣言表明的是优先级，不是争论的重点。

②   Scrum Master更应该是一个沟通者，还需要在团队中做具体的工作。

③   复杂的项目里，要让一线团队成员做决定。有点像，将在外，军令有所不受。

④   管理层注重结果，不关注流程。

⑤   Scrum需要有些许个性化，因人因物因事而异，怎么利于解决问题怎么来。

原文：https://www.cnblogs.com/wispytrace/p/9119302.html