什么是敏捷开发？

敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

通俗点说：就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并且拥抱变化，对不断变化想需求做出调整，在此过程中软件一直处于可使用状态的开发方式。

瀑布式开发和敏捷开发有什么区别？

瀑布开发是什么样的？

瀑布式开发的缺点

不适合长周期，需求变化快的项目开发，开发节奏慢，周期长，难以把控风险。

敏捷开发和瀑布式开发对比

流程对比

风险对比

区别

大部分瀑布开发模型是以文档为驱动的，因为在整个瀑布开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发只写有必要的文档，尽量少写文档，敏捷开发注重的是人和人之间，面对面的交流，强调的是以人为核心；
瀑布模式对于市场和用户需求变化相应较慢，成本较高，导致最后生产出的产品与市场需求存在较大差距，影响最终交付质量。

敏捷工作流程是什么样的？

名词解释：

迭代：是指把一个复杂且开发周期很长的开发任务，分解成很多小周期可完成的任务，这样一个周期就是一次迭代的过程；同时每次迭代都可以生产或开发出一个可以交付的产品；
敏捷开发：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。我们用规定的环节去一步步完成项目开发，这种开发方式的主要驱动核心是人，采用的方法是迭代式开发；
故事点：相当于一个理想开发人员的人天（man-day）为单位（开发人员一天理想的开发进度）；
计划纸牌：例如一个任务，A程序员需要5小时开发，B程序员需要1小时，他们抽取对应的纸牌，藏在手中，最后摊牌，如果时间差距过大，那么A和B就可以讨论为什么A需要5个小时；
Sprint：Sprint是短距离赛跑的意思，这里指的是一次迭代，而一次迭代的周期是1-4星期，也就是我们要把一次迭代的开发内容以最快的速度去完成它，这个过程我们称为Sprint。

有哪些角色？

Product Owner：主要负责确定产品功能和达到要求的标准，指定软件的发布日期和交付内容，同时有权力接手或拒绝开发团队的工作成果；
Scrum Master：主要负责整个Scrum流程在项目中的顺利实时和进行，以及清除挡在客户和开发之间的沟通障碍，使得客户可以直接驱动开发；
Scrum Team：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5-10人左右，成员可以采用任何工作方式，只要达到Sprint目标。

敏捷Scrum流程是什么样的？

首先我们需要确定一个Product Backlog（按优先级顺序排列的一个产品需求列表），这个是由Product Owner负责的；
Scrum Team根据Product Backlog列表，做工作量评估和安排；
有了Product Backlog，我们需要通过Sprint Planning Meeting（Sprint计划会议）来从中挑选出一个或几个User Story作为本次迭代的完成目标，这个目标的时间周期是1-4星期，然后对这个User Story进行细化，形成一个Sprint Backlog；
Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在两天内完成）；
在Scrum Team完成迭代目标的过程中，需要进行Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，要想所有成员回报你昨天完成了什么，并且想所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，方便团队同步开发过程中的进度、风险和把控；
做到每日集成，也就是每天都有一个可以成功编译、并且可以演示的版本（理想情况）；
当Sprint中的所有Sprint Backlog完成（所有任务），也就表示一个Sprint完成，这时，我们需要进行Sprint Review Meeting（迭代演示会议），也称为评审会议，Product Owner、客户、Scrum Master、Scrum Team、测试，每一个Scurm Team的成员都要向会上人员演示自己完成的软件产品（这个会议非常重要）；
最后就是Sprint Retrospective Meeting（回顾会议），也称为结束会议，以轮流发言的方式进行，每个人都要发言，总结并讨论流程上的改进方案，放入下一轮的Sprint流程中；

在这个流程中，还有两点需要额外关注：

不问责：对Sprint结果负责是整个团队，所有问题从流程上去优化而不是人；
注意把握迭代节奏，使用小迭代处理Bug和技术债。

如何用Gitee企业版的标准项目模板做敏捷开发？

首先Product Owner（产品负责人）确定Product Backlog（需求池），并排列好优先级：

之后由Product Owner创建好里程碑，这里我们将一个里程碑当做一个迭代，并设定好迭代周期，一般为1-4周，并在描述中写好本次迭代的目标，将迭代负责人设置为Scrum Master：

由Scrum Master组织Product Owner、Scrum Team进行Sprint Planning Meeting（Sprint计划会议），在会议上确定每个需求的合理性，并将需求拆分为可评估的用户故事，形成Sprint Backlog（迭代需求池），之后对用户故事进行工作量评估（我们在规划时可以对工作量做出调整）：

之后由Scrum Master组织Scrum Team进行Daily Scrum Meeting（每日站立会议），我们可以在知识库中建立一个文件夹对每日站立会进行记录：

在迭代结束时我们需要开两个会议，第一个是Sprint Review Meeting（迭代演示会议），是由我们的开发小伙伴，对这个迭代的需求和任务进行交付演示，这个阶段会暴露出很多Bug和产品需要处理的微小问题，所以一般都会在迭代结束的前一天进行演示会议，留一天进行Bug和问题的处理；第二个是Sprint Retrospective Meeting（回顾会议），这个会议主要让团队成员对本次迭代内出现的协作上的优缺点进行分析，并提出可执行的建议，在下次迭代内进行改进。

最后当我们的迭代内容稳定上线后，具有仪式感的关闭我们的迭代，整个敏捷开发流程就结束了：

总结：

本文只是做了一个简单敏捷流程的演示，在实际场景中会更加复杂多变，我们需要做到灵活地使用工具应对。

敏捷开发看似很简单，但是各个企业进行敏捷转型或者敏捷实践时遇到的困难数不胜数，最主要的还是对于企业文化、人员配置、沟通协作、和敏捷规范上的问题。

敏捷实践是个长久的过程，并不是一朝一夕说变就变的，就像回顾会议，是一个周期性反馈持续改进的过程，对于一味的学习理论照搬照抄，不如按照自己企业的文化和风格，不断实践和调整，最后总会形成一套独特和适合自身企业的敏捷方法论。

如何用Gitee企业版的标准项目模板做敏捷项目管理