敏捷开发
转自：
https://blog.csdn.net/qy924120316/article/details/76551279
https://www.cnblogs.com/byvar/p/7235650.html
敏捷开发的主旨：（这个时候再看看就感觉很有意义了）
一：个体及交互比流程与工具更具价值
二：可用的软件比冗长的文档更有价值
三：与客户的协作比合同谈判更有价值
四：对变化的响应比遵循计划更有价值
而我们之前的问题，交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试，先看一张敏捷开发的流程图。
创业公司敏捷开发敏捷流程化
敏捷开发简单流程：
我们怎么结合敏捷开发解决现有项目的问题，要记得任何措施都是为了保证按时按质按量把软件交付给用户，不要为了敏捷而教条实施敏捷，公司不能产生商业价值，任何先进的理念或者技术都是无意义的。我们做了这些措施：
1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的，才能被认可。
-
首先培养测试小妹学习敏捷开发，后续让她承担部分产品责任人和敏捷指导者的角色，原因有：a、测试要验收功能，必须理解业务需求。b、测试也是QA质量体系的一块，学习好了对于软件质量有个更深的认识。c、团队大部分是男生，女生推广更有亲和力一些。
- 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下，怎么给大家说更有效，更容易接受。她要讲解一定要自己非常清楚敏捷开发，并且准备充分知识点。开会时先指出我们现在问题，让大家看看有什么想法解决问题吗？现在我们做的产品，客户不认可、老板不满意、自己很累没有成就感，有什么办法解决。在大家讨论后，抛出敏捷开发的优势，一般情况下大家都会认可的。大家可能会问到如何执行、落地，可以尝试找一个项目试点，如果实施成功就可以让大家全面推广，不成功也只影响了部分项目。
2、搭建敏捷开发环境。大家要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件：nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》。
3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说，目的是完成这个项目，需要进行这几步：
- 先根据各自的能力和意向聚集一批完成这个目标的勇士，不管技术和非技术。如果聚集的人不够，技术总监可以根据总体项目的投入机动调整资源以支持，不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试，除去大家做其他事情的时间，总共可以算作4个人。
- 充分调动客户（老板和业务同事）参与进项目，他们的参与直接决定了项目成功与否。结合之前的经验，如果他们参与不够，最终做出来的东西就不是他们要的，或者离他们要的差距很大。他们刚开始加入的时候，很迷茫有时会表现的比较抗拒，这个时候一定要耐心坚持让大家把第一个sprint开发成功，使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化，如果有需求变化，就添加任务到任务墙，大家可以对所有任务的时间有个全面了解，如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
- 技术总监安排和客户沟通，客户这里指老板和业务。测试小妹负责和客户沟通记录，技术总监辅助。多次沟通后，尝试让测试把需求原型用最简单的工具绘制出来，技术总监审核通过后和客户沟通确认，反复迭代，直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行，但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题，过度技术设计产品。
- 产品设计出来后，召集项目成员分解任务，确定每个任务的时间，可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度，这样大家1-2天就可以做出一个能测试的原型，尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周，不能太长，也不能太短。太长会出现疲劳，太短的sprint会让大家觉得工作太多，做完一个又一个。“项目1”估算结果为120人天，总共投入4个人，需要30天4周时间，我们切成了4个sprint，差不多1个月时间完成，满足业务的时间要求。
- 分阶段实施sprint，绘制任务墙，划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙，贴到未开始的地方。
- 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务，统一管理起来。强调的是一个团体，如果有同事请假，其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题，对于当前的任务有什么建议，尽量控制在15分钟内，有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果，而是团队驱动，每天大家做的事情都反映在墙上，谁出现了什么状况，大家都会帮他想办法，保证整个项目能够成功。每一个任务完成，由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
- 软件开发过程。认领任务后，怎么保证大家开发有质量的代码？团队有资深点的工程师，不需要太多指导，直接可以参与项目的开发。而学习型工程师，需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务，他负责开发团队的概要设计审核，没有审核通过的设计不能开发，并指导大家分析和设计系统。大家都知道，系统思路有了，剩下就是技术实现的过程，只要技能掌握熟练实现基本难度不大。大家可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？我们这里也不是像传统开发软件一样为了文档而文档，只是让大家把自己的设计思路写下来，只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论，这样的文档是不欢迎的，受欢迎的文档只需写出用例分析，表设计，复杂的逻辑需要画出流程序列图。
- 结对编程。之前这个编程模式被无数人调侃过，其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时，会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时，很多时候都会结对，比如指导新同事、讨论设计模块，而之前这些都没有算在我们的开发工作量里。
- 项目演示和总结会议。在项目结束后，让所有参与项目的成员都参加，一起演示给客户展示，并解答客户的问题，充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享，并为下一个sprint做准备。
经过敏捷实施后，我们的生产力提高了很多，员工的积极性提高了，业务的参与使整体需求把控也很好，大家沟通多了，30天的任务提前了5天完成。我们多出来的时间，让大家每周有一天或者半天研究自己感兴趣的领域，但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术，最后做完需要写个ppt给大家分享下。既能让大家做自己想做的事情，也给大家创造了一个互相学习的氛围。
------------------------------------------------------
“敏捷开发” 知多少？
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方式。
它并不是一门技术，而是一种开发方式，也就是一种软件开发的流程。它会指导我们用规定的环节去一步一步完成项目的开发。因为它采用的是迭代式开发，所以这种开发方式的主要驱动核心是人。
那为什么说人才是主要的驱动核心了？我们学过瀑布开发模型，它是以文档作为驱动，开发人员都是根据产品部门提供的需求文档进行开发的，一切的核心是文档，所以说文档是这个模型中的一个核心。而敏捷开发的意义在于它只关注文档中的重要点，或者尽可能的去简化文档，敏捷开发其实更注重的是人与人之间的沟通、交流。所以它强调以人为核心。
迭代：迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
Scrum 和 XP
Scrum: 英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时， 大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
XP:极限编程（Extreme Programming）。可参考：http://blog.csdn.net/fw0124/article/details/48713959
文章开头谈敏捷的时候更注重的是概念性的，并没有谈到实际敏捷开发的实际应用情景。这里开始之所以聊 Scrum 和 XP，因为这就是敏捷开发的具体方式了。在实际开发中，你可以采用 Scrum 方式也可以采用 XP 方式。
Scrum 和 XP 的区别是，Scrum 偏重于过程，XP 则偏重于实践，但是实际中，两者是结合一起应用的。
Scrum开发流程中你会经常听到三个项目角色，比如 PO \ SM \ ST ，对于一个刚接触敏捷开发的初学者来说，听到这种简称内心还是极为崩溃的，我当初也是感同身受。这里顺便简单的补充下关于这三个角色的一个简介
产品负责人（Product Owner）：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
Scrum 的流程图：（以下图片来自网络）
读到这里，我想你对敏捷开发应该有了一个初步的认识了。接着我们继续聊下敏捷开发的具体开发流程。
在此之前，我们先来谈个在敏捷开发中最长听到的单词 “Sprint” 。谈到这个词，以往我第一次听到的时候私下去查了，各种各样的解释，真是十脸懵逼。借着这次机会也给大家简单的解释下。
请看以下小段落：
Sprint：是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为 Sprint
那么最后我们来细聊下如何进行 Scrum 的开发。
1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ，这是由 PO（Product Owner） 负责的
2.ST（Scrum Team） 会根据 PB 列表，进行工作量的预估和安排
3.有了 PB 列表，我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog
4.Sprint Backlog 是由 ST 去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）
5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）
6.做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员
7.当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）
8.最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中
下面是运用 Scrum 开发流程中的一些场景图：
（每日站立会议，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图）
（任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
（计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时）