如何理解敏捷开发

1. 定义

敏捷开发是以用户需求为导向，需求进化为核心，采用迭代、逐步完善的方式进行软件开发；其中的核心是“用户需求进化”与“迭代、逐步完善”！
前者保证我们所做的工作于用户（包含终端用户、产品、领导、实施、研发等所有提出合理需求的人）而言是有意义的（或者说有商业价值的），后者保证需求开发的有序性、并在一定周期内的研发工作不会被打断。
迭代开发：先发布一个有核心功能的软件，但是每次迭代都会不断的改进产品和添加新的功能。
增量开发：新增的功能都是一个完成的功能，并且能够给用户带来一定的益处。
好处：早期交付，增加了资金的流转，减少经济压力；降低风险，快速更改产品某些功能

2. 如何做
敏捷开发如何实施和难度
PO，5-7人，测试不能拖后腿，需要有自动化测试参与到项目中来
需求
详细设计
编码
测试
部署和评估

	迭代的管理，我们用的是**leangoo**，bug管理是用的**禅道**，下面是迭代流程：
	Scrum迭代
	1、Scrum开发中，所有的需求都需要进入到PO的Project Backlog；
	2、在迭代启动前，由PO将里面的代办需求进行优先级排序，并整理成能执行的有价值的Story，移入Spring Backlog中（注意：这些Story是可执行的，PO一般应清楚需求的验收点，并对该Story有一个预估的时间点）；
	3、在迭代周期内的第一天，这一天主要是进行项目启动会（需求评审、时间评估、实现思路及细节讨论、故事拆分、时间安排等），PO会对Spring Backlog中的Story进行描述，团队成员进行细节询问后，会进行一轮开发点评估（按团队成员进行一个增删改查业务为一个点来评估Story需要几个点进行开发或测试）；第一轮评估后，会由团队成员阐述评估时间点的原因，之后再进行1~2轮时间点评估。团队成员之间评估相近，且PO认为合理，取最终评估点最大值（注意：开发评开发时间，测试评测试时间）；如果最终评估点过大（我们一般取3以下的点，超过3则认为过大），需要进行Stroy拆分，拆分后继续评估；
	4、所有Story评估完毕后，由团队成员自主领取任务，每个成员能完成的任务量参考之前迭代的任务量（一般是几个迭代后，才能比较准确的得到一个迭代团队和个人能顺利完成的任务点数）；
	5、评估完毕后，当天，所有成员需要进行故事拆分，拆分为每天或者每半天能完成的任务，并给每个任务定一个时间点，一般是开发先定完时间点后，在开发的时间点基础上，测试再加上相对应的测试时间；
	6、一般第二天或者第三天，会进行测试用例评审，这个主要是PO和测试参与，有需要时可让对应Story的开发人员参与；
	7、每日站会，在迭代中，每天成员开始工作应该是先根据leangoo梳理每日的工作，然后在每日站会上叙述昨天完成的内容，今天计划做的以及面临的困难，是否需要支持（这个会议时间不宜过长，原则上是仅叙述，不实际解决问题，最重要的一点是PO闭嘴，因为PO一旦说话，肯定会聊到详细内容，然后整个团队的时间就浪费了。所以问题在会后解决，当然，更加提倡的时开发时候碰到问题立即解决，而不是等待每日站会）
	8、项目验收会，在迭代的最后一天上午，我们一般会对项目进行验收，由测试展示给PO，由PO最终决定每一个Story是否达标，迭代是否顺利完成，这是PO的验收会，也是整个团队的成果展示会。
	9、在最后一天下午，一般会进行迭代总结会，会评选出迭代之星，迭代中的优缺点，以及缺点的解决方案，并将解决方案分配到负责人，下个迭代努力去改进。
	10、一般，在迭代中途，我们会有一些代码ReView，可以在成员的每次提交代码前进行update时看看别人的代码，并建议每周花一两个小时进行团队的代码ReView。

3.leangoo工具的作用

PO的Product Backlog

1. 待梳理需求
   PO从用户（包含领导、客户、自己）得到的需求，肯定是不完善的，大多都是需要做一个什么功能之类的“一句话需求”，对开发团队而言，这些都是不可执行的；但是PO可能也不能及时进行梳理，所以先把这种“一句话需求”放入该列记录起来。

2. 以后的Sprint
   这些都是PO已经梳理了，可执行的需求，我们称之为Story（故事），一般这一列都是紧急度不是非常高，但是在后续需要做的。从这一列起，任务是带有时间点数的，这里一般是PO估算的大概点数，与迭代中团队估计的点数可能有差别，但是随着团队的默契度上升，这个点数应该能与团队评估点数越来越接近。

3. 下个Sprint
   这些一般来自于“以后的Sprint”一列，是可执行的，而且紧急度较高的（紧急度由PO根据需求来源、商业价值、工作量等因素进行确定），而且这一列的Story都应该是紧急度排好序的，越往上越紧急。PO大概评估，这一列的Story点数一般略高于团队能完成的点数。这一列的Story需要PO在当前迭代开始准备，在迭代结束前整理好，这样才能让迭代不会中断。

4. 当前Sprint
   这一列是当前迭代进行的Story，原则上是不允许替换的，除非是特别紧急的任务。这一列开始，Story的任务点数可以换为与团队评估的时间点数一致。

5. 已交付
   这一列是已经交付的Story，是一些已经通过PO验收，已经上线或者随时可以上线的Story。

leangoo上主要的两张Backlog，PO一个人就需要维护一张，可见，在Scrum迭代中，PO处于一个能决定迭代成败的绝对核心位置，PO的任务及责任都是非常重的。

Team的Sprint Backlog

Team的Sprint Backlog

1. Story
   这个很好理解，迭代中需要完成的故事，在故事都是标记好点数，标记好晚上时间，并标记好负责人的，而且每一个Story都应当有检验项供测试及PO验收。

2. Task
   对应的Story拆分为可以执行的且短时间内可完成的小任务，每一个Task都有完成时间和负责人，这些Task都是待执行的状态。

3. Task-doing
   Task的执行当天，负责人将该Task从Task列拖到Task-doing列，表示该Task正在处理。

4. Task-done
   Task完成后，由负责人将Task拖入该列。

5. Story-testing
   当该Story对应的所有Task都完成后，将该Story拖入Story-testing列，测试人员开始进行测试工作。

6. Story-done
   当测试人员完成测试后，将Story拖入该列，表示该Story已经顺利完成。

一个迭代会有很多的Story，我们每个开发人员都会建立一个泳道，然后将自己的Story拖入泳道中（也有的团队是每个Story一个独立的泳道，这个看自己的需求情况而定）；在Task及Story完成后，团队成员需要主动、及时的拖动Task和Story，不然对应Task或Story会变为红色，而且整个Sprint对应的燃尽图会变得很怪异；在迭代的第一天，应该讲Story拆分为Task，并且Story完成时间不能标记到迭代的最后一天（最后一天应该是产品验收会及迭代总结会），开发Task完成时间不能标记到迭代的最后两天（给测试预留时间，并且需要进行回归测试）；在迭代正式开始后，Story和Task应该是不变的，不然很难保证迭代的顺利进行；

燃尽图

燃尽图能反馈一个迭代任务周期内的整体进度，一般这个图由SM来管理及分析，如果发现燃尽图偏离参考值，则应该考虑具体原因：在上方则应该询问团队是否出现无法解决的阻碍；如果在下方，则迭代式朝着良好的方向走着，如果下方偏离过多，则表示该团队这个团队战斗力有所提升，可以接受更多的Story。

zentao禅道测试用例管理和bug管理工具
主要作用：我的地盘，bug列表，数据统计。

我的地盘

bug列表

数据统计

敏捷开发的原则

通过早期和持续交付有价值的软件，实现客户满意度。
欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
不断交付可用的软件，周期通常是几周，越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
项目必须围绕那些有内在动力的个人而建立，他们应该受到信任
面对面交谈是最好的沟通方式。
可用性是衡量进度的主要指标。
提倡可持续的开发，保持稳定的进展速度
不断关注技术是否优秀，设计是否良好。
简单性至关重要，尽最大可能减少不必要的工作。
最好的架构、要求和设计，来自团队内部自发的认识。
团队要定期反思如何更有效，并相应地进行调整。