构建之法第六章

构建之法第六章

本章为敏捷流程，主要介绍了敏捷流程及其原则，Backlog、Burn-down、Sprint、Scrum方法论，各种软件开发方法论的优缺点，，选择软件流程根据等

敏捷开发：是一系列价值观和方法论的集合

敏捷开发的原则：

1、尽早并持续地交付有价值的软件以满足顾客需求

2、敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势

3、经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

4、业务人员和开发人员在项目开发过程中应该每天共同工作

5、以有进取心的人为项目核心，充分支持信任他们

6、无论团队内外，面对面的交流始终是最有效的沟通方式

7、可用的软件是衡量项目进展的主要指标

8、敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步骤持续合作下去

9、只有不断关注技术和设计，才能越来越敏捷

10、保持简明—尽可能简化工作量的技艺—极为重要

11、只有能自我管理的团队才能创造优秀的架构、需求和设计

12、时时总结如何提高团队效率，并付诸行动

敏捷的步骤：

1、找出完成产品需要做的事情—Product Backlog

2、决定当前的冲刺需要解决的事情—Sprint Backlog

3、冲刺

4、得到软件的一个增量版本，发布给用户

第三步半：后面的20%往往要花费80%的时间

长期任务：软件项目中常常有一些比较艰难和底层的任务

敏捷的团队：自主管理、自我组织、多功能型

敏捷流程的经验教训：

1、敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论

2、Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通

3、一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。

4、在复杂的项目里，要让一线团队成员做决定

5、创业公司的团队其实经常是运行在Scrum的模式中

6、在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害

7、不要和管理层谈“流程”，他们只关心“结果”

8、在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点

软件匠艺宣言：

1、不仅要让软件工作，更要精益求精

2、不仅要响应变化，更要稳步增加价值

3、不仅要有个体与交互，更要形成专业人员的社区

4、不仅要与客户合作，更要建立卓有成效的伙伴关系

5、也就是说，左项固然值得追求，右项同样不可或缺

    总结来说，本章围绕敏捷流程展开论述，从敏捷的发展谈起，强调了敏捷做法带来的价值以及所适应的情况，介绍了敏捷开发的原则，步骤，问题，经验教训，以及敏捷的团队应该具有自主管理、自我组织、多功能型的能力；后面也通过问答的形式将敏捷更详细的展现，说明了敏捷的使用范围，以及我们应该对敏捷流程抱有正确的态度，对自己团队是否合适应能做出正确的判断。

 

个人感受部分：

 

1、我过去怎么做的；认为开发更多是按照自己的想法设计

 

2、结合书中所讲，这样有什么不好：最终软件不能满足用户的需求，可能达不到用户的满意

 

3、提出一个解决办法，避免再次掉入陷阱：多进行与客户的沟通交流，让软件更加贴近客户的需求，更能争夺市场