敏捷开发实践总结

前言

敏捷开发它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。

什么叫敏捷开发？

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

对概念的理解：
以人为核心：敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。而瀑布开发模型，它是以文档为驱动的，整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据。
迭代：迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发的4句宣言

1，个体与交互 胜过 过程与工具
2，可以工作的软件 胜过 面面俱到的文挡
3，客户协作 胜过 合同谈判
4，响应变化 胜过 遵循计划

我对这4句宣言的理解：

产品结果大于形式，先把产品做出来，然后再整理出完善的文档
在互联网软件产品开发过程中，需求是不断发生变化的，需要对原有的计划及时更改，应对变化。

为什么要使用敏捷开发模式？

敏捷开发注重人与人之间的交流和合作，可以快速实现功能，以小步快跑的形式，不断试错，不断调整方向，不断完善产品。总结起来就是：适应变化，不断迭代。

scrum流程图：

image.png

scrum 开发中的三种角色：

1，product owner:产品负责人，确定大家要做什么（一般产品经理）。
2，scrum master:scrum的推动者，掌握大节奏的人。
3，team:一般由多个developer组成，开发的主力。

image.png

scrum 开发中的三大神器：

1,production backlog（产品待办事项列表）
2,print backblog（详细任务列表）
3,sprint burn down（计划走向和实际走向组成燃尽图）

image.png

scrum 开发中的四个会议：

1,sprint计划会（理解需要做什么，然后讨论怎么做）
2,每日站会（昨天做了什么，今天打算做什么）
3,sprint 评审会（大家评审sprint产出，然后对待办事项做相应调整）
4, sprint回顾会（讨论哪里完成好，哪里需要改进）

image.png

SCRUM敏捷开发流程是什么？

1、Product Backlog（产品需求列表）我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、Sprint Planning Meeting（Sprint计划会议）有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog（迭代任务列表） Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、Daily Scrum Meeting（每日站立会议）在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6、Daily Build（每日集成）做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、Srpint Review Meeting（评审演示会议）当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、Sprint Retrospective Meeting（回顾会议）也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
9，重构 因为迭代开发模式在项目早期就开发出可运行的软件原型，一开始开发出来的代码和架构不可能是最优的、面面俱到的，因此在后续的Story开发中，需要对代码和架构进行持续的重构。
10，TDD（测试驱动开发）测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

下面是crum开发流程中的一些场景图：

image.png

上图是一个 Product Backlog 的示例,产品需求列表

image.png

上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。

image.png

上图就是任务看板了，任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）。

作为客户端开发人员在实际的迭代开发过程中，有以下感想和总结：

1，每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划，无形中让让人做事更加的积极
2，及时是敏捷开发，也要尽可能的有详细的需求
3，在实际的开发过程中也需要写api文档，并且尽可能写上注释，以便于其他人的理解
4，严格按照开发流程去走，但不要流于形式，否则就是浪费时间
5，坚决杜绝以下问题的出现：
需求拍脑袋随意改动，叫快速试错迅速响应用户需求；
代码质量低劣不停出更新版本，叫快速迭代中；
不写正规设计文档，叫降低沟通成本和最好的文档是代码；
领导站身后指挥码农写代码，叫结对编程；
产品质量不靠设计靠测试的，叫测试驱动研发；

改文章已同步到公众号，欢迎大家专注！

公众号.jpg