什么是敏捷开发？
- 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。敏捷开发一种开发方法，也就是一种软件开发的流程，这种开发方式的主要驱动核心是人；它采用的是迭代式开发；敏捷开发的核心就是在一个高度协作的环境下，不断的通过反馈来进行自我调整和完善。重点强调的是协作和反馈，协作体现在团队与客户之间的协作，团队成员之间的协作。反馈则是在开发中的任何环节，包括代码质量、自动化测试、部署、项目进度、需求变更、客户验收等，而且反馈越快越好。 以人为核心、迭代，协作、反馈；
- 传统的瀑布开发模型，它是以文档为驱动的，在整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
敏捷宣言
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
名词
- PM:Project Manager 项目经理，负责沟通协调，保证项目进度，维护团队等。
- PO:Project Owner 即甲方熟悉业务的人，验收软件的人，因为TW是外包公司。
- BA:Business Analyst 业务分析师，思维敏捷，英语流畅，负责与客户沟通，整理需求，拆成故事卡。
- UX:User Experience 用户体验设计，传统的UI升级版，不仅要会做图，还要考虑用户体验如何。
- TL：Technical Leader，技术领导
- DEV:Developer 前端后端的程序猿/媛们。
- QA:Quality Analyst 质量分析师，即测试工程师
- AC：Acceptance Criteria，验收条件
- UAT：User Acceptance Test，用户验收测试
- Retro：Retrospective，回顾会议
- TB: Team building，团队建设
为什么要有固定的迭代周期
- 建立团队的节奏感：有预期的节奏，容易让团队形成习惯，团队生产效率更规律。
- 降低协同成本：能够并行的去安排多个迭代的规划，评审等活动，减低沟通和协同成本。
- 简化规划活动：如果固定的迭代长度，当团队人力固定的时候，团队的生产率理论上也是固定的，有利于规划的合理性。
- 此外，长周期从需求完整性、频率、工作强度上优势明显，短周期从产品规划、交付效率、质量以及试错成本上优先明显。
INTERATION
- IPM -> STAND UP -> STORY KO -> CODING -> CODE REVIEW -> TESTING -> SHOW CASE -> RELEASE -> RETRO;
- (SESSION -> TEA PARTY -> CATCH UP WITH CLIENT/PD/DEV/UX)
- (FEEDBACK LOOPS / CONTINUOUS INTEGRATION / STORY BOARD)
- IPM
- Stand Up
- Story Board
- Code Review
- TDD
- Refactoring
- Simple Design
- Show Case
- Continuous Integration
- 360/daily FeedBack
- Regular catch up with client
- Story kick-off
- Pair
传统项目和敏捷项目管理区别
- 价值理念，流程框架，实践方法
价值理念
- 项目管理的三要素：时间（进度）、范围（需求和特性）、成本（资源）
- 传统项目管理，是先确定产品的范围，然后评估这些需求要花费多少时间，协调花费多少人力，然后形成各种计划，如排期计划、沟通计划、人力分配计划、风险计划等等，然后按照既定的计划来推进，计划驱动。（范围固定，时间和成本可调整，计划驱动）
- 敏捷项目管理，是先固定了成本、和时间，如一个团队就10个人，迭代周期两周，那我们先做哪些有价值的需求和特性。（时间和成本固定，范围可调整，价值驱动）
研发模式
- 传统项目管理，通常用瀑布的研发模型，瀑布模型是最典型的预见性方法，什么叫预见性方法呢，就是做之前先严密的分析计划，严格遵守预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序化进行。为了后期的执行过程中不会有太大的风险和偏差，所以前期会花大块的时间准备繁重的各种文档，并且会有很严格的评审流程。通过预见性的方法来保证有个好的研发过程。这样的研发模型是不接受变更的，因为变更的代价会较大。
- 敏捷项目管理，通常用迭代的研发模型，在初步分析后，产品就以小的增量进行开发。先小布快跑起来，然后实现小部分功能找到用户做验证反馈，在一步步的完善产品方案，最终交付完成产品。迭代的研发模型的好处是，一直围绕这用户变化的需求适应调整，保证最终交互的是用户满意的成果。
- 通常这两种研发模型，第一种通常是保证了有一个“好过程”，而第二种通常是有一个“好结果”，而“好过程”不一定等于“好结果”，所以尽量选择能产生好结果的研发模式。
实践方法
- 传统项目管理用到的实践方法，如waterfall、PMBOK、RUP；敏捷方法，如XP、scrum、kanban等。
- XP：极限编程，XP是偏工程实践和方法，缺乏对项目管理的指导方法。但它里面提到结对编程，持续集成等很好的实践方法。持续集成的核心就是快速试错，提前发现问题，而不是把问题放到集成之后。
- Scurm：提供一套基于团队运作的敏捷方法，scrum引入了“backlog”、优先级、迭代例会等；scrum优势是简单，易于使用，所以很多互联网团队都在参考和实践。
- KANBAN：最初是制造业应用的方法，后来被敏捷相关管理进行改良事件，变成故事板。KANBAN能将现有的管理可视化，透明化，有利于管理工作的有效推进。
- 传统项目管理方法更像是计划经济体制，更注重规划和过程把控的方法实践；而敏捷管理方法更像是市场经济体制，更多的是适应环境，小步快跑，灵活变化的方法实践。
参考文档：https://www.tapd.cn/forum/view/23641
极限编程(XP)和Scrum区别
- 区别之一： 迭代长度的不同(XP1-2周，scrum 2-4周)
- XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。
- 区别之二: 在迭代中, 是否允许修改需求;(XP可替换，scrum严格要求，不允许)
- XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。
- 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。
- 区别之三: 在迭代中，User Story是否严格按照优先级别来实现;(XP严格按优先级，scrum灵活)
- XP是务必要遵守优先级别的。
- 但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。
- 区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量;(XP严格流程方法，scrum不定义，自觉)
- Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。
- XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。
