敏捷开发五个阶段,敏捷项目管理的5个阶段

关于敏捷开发的含义、原则、目标和机制

理解敏捷开发，我们可以先了解一下瀑布式开发。

瀑布开发模式把开发分成一系列阶段，如需求、设计、开发、测试，就像下图它画出来的，看起来很像瀑布，所以叫瀑布开发。

问题是需求的交付难道不都是要经历这些阶段吗？

瀑布开发的本质问题并不是阶段，而是批量。需求批量地在一起进行设计，然后是批量地开发，批量地测试、交付等等。

批量有什么问题? 首先，批量让价值交付延迟，所有需求在最后的阶段才能交付，价值交付比较晚。Google执行董事长施密特提出过反摩尔定律，表述为：

“如果18个月之后我们只能卖出跟今天一样的东西，我们就只能得到一半的收入。”价值的交付时间将直接影响收入。

敏捷的目标

敏捷开发有第一个目标就是更快的交付价值，这里的快指的不是绝对速度，而是更早的交付。

在项目结束的时候，一定是对产品和项目的知识理解最充分的时候。这显而易见，我们在项目进程中积累了知识特别是当向用户交付产品后，用户反馈：

“我要的不是这个啊，我说的明明是……”，这时候你瞬间狂涨知识，并感叹道“你怎么不早说呢？”。

这中间可能有沟通问题，但更多可能的是，用户这时才清楚或能够描述他们要的是啥，更有甚者，我们可能一开始连用户是谁也未必能准确地定义。产品和业务开发本来就是一个探索的过程，开始时一定是最无知的时刻。

项目中的大部分决策也一定是在项目开始的时刻做出的，这将有一个重大的悖论，在最无知的时刻，做出了最重要而且是绝大部分的决策，并把它作为随后执行的依据。面对不确定的技术、市场环境，传统开发模式已无法适应要求，悖论越发突出。

敏捷开发将通过迭代应对这一问题，只做初始决策，定大致的方向。通过市场反馈不断修正对产品的认知，增量的决策和调整。

产品开发过程中，技术环境、市场环境、竞品策略、团队认知都会发生变化。面对变化的环境，我们必须承认自己的无知，在开发过程主动有效地学习，不断地汲取反馈，灵活地调整。

这也是敏捷的第二个业务目标，有效学习和灵活响应变化。

敏捷开发工具

敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。

在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。

在2001年年初，一些业界专家成立了敏捷联盟，起草了敏捷软件开发宣言。该宣言针对一些企业的现状，提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则，其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则 。

敏捷开发的价值观

1.个人和交互胜过过程和工具。

2.可以运行的软件胜过面面俱到的文档。

3.客户合作胜过合同谈判。

4.响应变化胜过遵循计划。

敏捷开发应遵循的12条原则

1.通过尽早的、不断地提交有价值的软件来使客户满意。

2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3.以从几个星期到几个月为周期，尽快、不断地提交可运行的软件。

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5.以积极向上的员工为中心，建立项目组，给他们提供所需的环境和支持，并对他们的工作予以充分的信任。

6.在团队内部，最有效、效率最高的传递信息的方法，就是面对面的交流。

7.测量项目进展的首要依据是可运行软件。

8.敏捷过程提倡可持续的开发，责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。

9.时刻关注技术上的精益求精和好的设计，以增强敏捷能力。

10.简单是最根本的。

11.最好的构架、需求和设计出于自组织的团队。

12.每隔一定时间，团队要反省如何才能更有效地工作，然后相应地调整自己的行为。

敏捷组织提出的敏捷开发模型的整体框架主要有三个：

Scrum、XP（eXtreme Programming）、OpenUP 这3个敏捷实践。

敏捷开发的原则

1.凝聚人的力量，紧密协（合）作。包括业务负责人、开发团队、客户、管理者之间的关系，所有这些关系在以前都是造成项目危机的原因之一，那么，在敏捷时代，我们需要这些角色 紧密合作，最大限度的发挥各个角色的力量.

2.聚焦客户价值，消除浪费（如何聚焦用户价值，即频繁的交付用户可工作的软件，快速收到用户反馈）

敏捷团队运作机制

1.一个团队有自己的代办事项，对代办事项进行拆小。

2.按客户价值进行优先级排序，产品经理负责价值排序。

3.小而稳定，跨职能团队。

4.多个团队松耦合（依赖性比较低），对齐迭代时间和战略目标。

关键的团队角色

产品负责人

Scrum主管（流程主管）

开发团队

产品负责人（Product Owner）

负责管理产品backlog（代办事项）的唯一负责人

代表客户/项目如责任人

定义产品的所有特性

负责产品的投入产出

负责最大化产品和开发团队工作的价值

Scrum Master（流程主管）

起到教练的职责，领导团队完成Scrum的实践以及体现其价值。

排除团队遇到的困难，使得团队紧密合作，使得团队个人具有多方面职能的工作能力。

确保团队能胜任其工作，并保持高效的生产率。

保护团队不受到外来无端影响

关键的团队活动

每日例会：每日5分钟左右的一个简单例会，尽可能多的开发人员参与进来对紧要问题的讨论。

评审会：需要在迭代周期的最后一天召开，1个小时左右就可以了，需要客户出席，如果客户不能出席，则需要产品经理出席

迭代回顾会：迭代回顾会是在每个迭代结束时进行，总结工作中的经验和教训，时间维持在30-60分钟内，整个团队都需要参加（Scrum Master、Product Owner、开发团队以及客户）。

迭代回顾会包括两部分，第一部分是定量分析，第二部分是定性分析。

其中定量分析又包含团队是否完成了迭代目标，收集并评审迭代度量指标（包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等）。

定性分析包含哪些工作良好（应该继续保持），哪些做的不好（应该停止）；哪些可以改进（团队选出1－2条在下一个迭代实现）。

敏捷开发框架案例：

原文：windy

什么是敏捷开发？

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行

的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

例如，开发某个系统，需求确定后，首先页面ui进行设计，同时针对某些功能模块进行开发，说白了就是不影响自己干活的情况下，执行项目其他工作。

敏捷开发流程中测试工作各阶段的内容有哪些

1、story澄清会议（即需求澄清），参与人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。目的顾名思义就是让所有参与项目的人员更深入的了解需求，会议上任何参与者都可以发表疑问，对不理解的地方要及时问清楚，实践证明这个会议能尽早的发现开发人员遗漏掉的功能点以及功能实现的方式对其他模块的影响等。这个阶段开发输出的文档有：story验收标准。一般情况下对于功能复杂的模块，为了让大家跟直观的了解功能点，一般开发人员会准备demo演示，这样也更有利于测试人员测试用例的输出。

2、测试人员根据需求澄清时了解的需求点编写测试方案，然后输出用例，完成后发给开发人员、TSE对用例进行评审，编写人员根据检视意见修改用例，直到大家都认可了，再导入用例管理工具TMSS。

3、迭代story转测试之前，测试人员需要向开发人员分一部分基本功能的用例验证，用例通过后才可以转测试。转测试附带的文档包括：代码检视确认报告、测试部提供用例的执行结果报告、开发自测用例样例参考等。

4、测试人员执行测试，执行用例---提交bug---回归问题---story评价---关闭story

5、迭代结束，回归会议，开发测试人员一起进行此次迭代版本的优缺点分析等。

敏捷开发和瀑布开发的区别

敏捷开发模式：

敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。

简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

传统瀑布开发模式：

瀑布式(WM：Waterfall Model)开发是一种老旧的，正在过时的计算机软件开发方法。最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况。

大体分为这几个阶段：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。由于这个架构之中从制定计划到最后的运行维护过程中需求分析只在前期进行了一次，在后面就没有专门的需求分析过程，这个时候在需求变化的时候就很难去有效地响应变化。

因此，这个瀑布模型具有的缺点就是难于很好地表达和描述用户的需求。其优点是与一般系统工程一致，易于使用，不要求特别的技术与工具也能很好地进行软件开发。

敏捷开发模式中的四种会议

Sprint Planning敏捷迭代计划会议

敏捷迭代开始

1.PO讲解需求 2.开发Team估算工时。

1.排列需求优先级；2.分析和评估产品Backlog并确定该迭代的目标；3.制定迭代计划。

1.基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；

2.分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；

阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员。

1.Scrum Master公开迭代时间表；

2.产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；

3.团队针对Sprint Backlog和优先级达成一致；

4.Scrum Master和团队成员共同确定Sprint Backlog；

阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加

1、团队成员针对Sprint Backlog共同分解任务；

2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；

3、团队成员共同认领任务；

4、共同确定DoD，团队达成一致；

5、团队共同确认迭代目标和价值；

1.昨天我做了什么

2. 今天我计划要做什么

3.我遇到了什么问题，妨碍了我尽可能有效地工作

Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。

在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog

参与人员：产品经理、Product Owner、Scrum Master、团队所有成员

1.检验迭代成果，检查是否完成迭代计划中的迭代目标

2.用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。

3.由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。

在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：

1.本次迭代有哪些做得好；

2.本次迭代我们在哪些方面还能做得更好；

3.下次迭代准备在哪些方面改进；

4.团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪