关于敏捷开发的思考

刚接触敏捷一个月左右，看各种设计模式、TDD、scrum、xp，但是当别人问到我什么是敏捷开发的时候，还是不知道怎么去回答，所以就想着，是时候理一下这些天学习的关于敏捷的所有，在心里搭一个框架。

什么是敏捷开发？

在《高效程序员的45个习惯：敏捷开发修炼之道》中这样写道：敏捷开发就是在高度协作的环境中，不断地利用反馈进行自我调整和完善。

红色的关键字也指出了敏捷开发的三个特点：高度协作——以人为核心，不断自我调整和完善——持续集成，循序渐进，反馈——迭代开发，尽早反馈。

何为高度协作？

由于大学课程软件工程的限制，还有一些小公司的实习经历，曾一度让我以为瀑布式开发就是最正确的，一叶障目。与敏捷不同，瀑布式开发是以文档为核心的，严格遵循预先计划的需求、分析、设计、编码、测试的顺序，各个环节彼此分离，主要依靠记录的文档进行沟通，要求写详细的文档，但是，任何人在做任何事之前，都不可能预测出所有的可能性，一次性设计完美，所以可想而知，这样的开发方式，会导致整个项目周期又臭又长，问题不断，返工不断，效率低下，严重打击团队成员的积极性，工作乏味。但是敏捷开发呢，强调以人为核心，各个环节的人面对面交流，用户也参与其中，客户协作胜过合同谈判，只写必要的文档，人为可工作的软件胜过面面具到的文档，团队中所有人一起工作，不论哪个环节，有问题及时提出，沟通调整，响应变化胜过遵循计划，所以敏捷开发可以及时发现问题，防患于未然。

何为不断自我调整和完善？

敏捷开发强调开发要持续不断，只要有人使用这个软件，开发就没有真正结束。在《高效程序员的45个习惯》中这样写道：为什么要持续开发呢？因为软件开发是一件复杂的脑力劳动，任何遗留下来的问题，要么侥幸不会发生意外，要么使情况变的更糟，慢慢恶化到不可控制。面对这样的问题，唯一的办法就是持续地推进和完善项目，把问题扼杀在萌芽状态。

何为反馈？

敏捷开发将冗长的项目周期划分为一个一个短暂的小周期，每个周期都有一个可交付的产品，一个周期就是一个迭代，每个迭代的成果都要给客户演示，及时获得反馈，定期回顾，持续改进，这样小步开发，及时获得反馈，就不会出现像瀑布开发一样到最后交付出用户不满意到产品，然后再大动筋骨地改造，耗费成本。

敏捷开发的好处是什么？

从敏捷开发的特点不难看出它的好处，提高开发效率，每一次迭代都能及时获得用户的反馈，大方向不容易走错，步步为营，不用返工，效率必然提升；降低开发成本，不用返工，自然成本降低；提高产品质量，敏捷开发要求团队成员面对面工作，及时沟通，交流代码，共同进步，产品的质量自然高，也不容易出现一个人离开团队，其他人就无法接受他的工作他的代码这样的事。

怎样敏捷开发？

敏捷开发的具体方式有两种，scrum和xp（极限编程）。xp有五个核心价值观：交流、简单、反馈、勇气、谦逊，xp偏重实践，成功打破了软件工程“必须重量”才能成功到观念。scrum偏重过程，是一个包括了一系列的实践和预定义的过程骨架（是一种流程、计划、模式，用于有效地开发软件）。两种方法在实际使用中可以结合使用，这里主要介绍scrum，后期补充xp。

scrum

像上面提到的，scrum是一个过程，这个过程通过一些角色的设定和配合使团队能高效工作，就像这个词的汉语意思”争球“，迅速，激情。

scrum中的角色设定

产品负责人（product owner）：确定产品是否达到标准，确定发布日期及发布内容。

scrum主管（scrum master）：负责scrum过程顺利进行，使整个过程收益最大化。

开发团队（scrum team）：负责开发工作，一般5到10人，团队人员自我管理能力很强，每个人可能负责不同的技术。

scrum的工件

产品订单（product backlog）：按照优先级排列的高层需求，有product owner负责。

冲刺订单（sprint backlog）：要在冲刺中完成的任务清单，一个sprint通常为2～4周，就是一个迭代，冲刺订单记录了本次迭代要完成的工作以及具体安排。由scrum team制定，越细越好。

冲刺燃尽图（burn down chart）：在冲刺长度上显示所有剩余工作时间逐日递减的图。

scrum的活动

计划会（sprint planning meeting）：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。

每日立会（daily standup meeting）：团队每天进行沟通的内部短会，站立参加，因为站立可以避免在椅子上打盹儿，事实上是比坐着效率高，一般只有15min左右。

评审会（review meeting）：在冲刺结束前给产品负责人演示并接受评审的会议。

回顾会（retrospective meeting）：在冲刺结束后关于自我持续改进到会议。

scrum工作周期图