标签：另一个 运行 需求文档 用户 ali 地方 成功 建议 编写
本小结来自于我在公司的敏捷开发实践中总结而来，记录下来，如果有疏漏或者不正确的地方，欢迎批评指正。
所谓的敏捷开发是相当于瀑布式开发而言的，传统的瀑布式开发严格遵循预先计划的需求、分析、设计、编码、测试的步骤进行的，每个阶段都有每个阶段对应的文档；其主要问题是严格的分级导致的自由度降低，导致后期需求的变化难以调整或者代价高昂；
敏捷开发以用户的需求为核心，采用迭代增量、循序渐进的方式进行开发；项目在构建初期就被分为多个子项目，每个子项目可以独立运行和交互，在此过程中软件一直处于可运行状态；每个子项目都要经过设计、编码、测试等几个阶段，相当于就是把一个大的项目拆分成多个子项目来单独开发，降低风险，确保每一个子项目的成功，从而保证到整个大项目最终的成功；往往大项目是复杂的，难以把控的，拆分成多个子项目后，每个子项目的复杂度就降低了，这样项目更容易成功；
下面是敏捷开发的各个阶段做的事情，也就是敏捷开发到底该怎么去执行：
1、团队搭建阶段：
敏捷开发团队不像瀑布式开发那样的大团队，而是小而稳定、跨职能的团队，也就是说这个团队的分配并不是固定的，而是根据功能模块随时组合搭建而成；比如说某项目拆分成了六个子项目，在开发第一个子项目时进一步拆分成五个子功能模块，在第一个迭代开发中，可以将大团队拆分成五个小的团队，每个团队分配对应的开发、需求和测试人员，同时每个小团队需要一个负责人，这个负责人需要对子功能模块的进度和质量负责；在每一个迭代中，小团队的划分和人员分配以及负责人的指定并不是固定；
2、需求分析阶段：
项目被拆分成多个子项目，每个子项目被拆分成多个子任务模块，每个模块都有对应的需求分析人员，需求人员需要针对这个子任务模块编写需求文档和进行需求交底，在需求交底时需要开发人员、测试人员和客户共同参加，分别针对需求文档中的分歧之处提出并讨论并形成最终方案；子任务模块相对于整个系统来说，难度已经降低很多了，而且又有开发人员、测试人员和客户的共同交底，因此能保证需求的正确性；
3、设计阶段；
每个子任务模块的开发人员需要针对当前迭代开发的任务进行方案设计、任务拆分和估时，拆分粒度以不超过2小时为宜，如果任务超过2小时，建议再进一步的拆分；设计完成后由组内资历较老的开发人员进行设计评审，一来可以发现设计方案中不合理的地方，二来可以对任务拆分的粒度给以指导，判断子任务的估时是否合理，是否有漏掉的任务项；
设计评审通过后，需要将拆分的子任务录入到jira中去，这样领导在开发过程中就能随时查看到当前开发进度情况；
4、编码实现阶段：
开发阶段每天早上开一个晨会，下班之前开一个夕会，晨会和夕会的时间不宜过长，以10到15分钟为宜，会议的主要是每个人汇报下自己的进度，在这个过程中有没有遇到什么问题和影响进度的问题，如果影响到进度了，评估下影响的范围，如果在可控的范围内，比如说通过晚上加两个小时的班，或者向其他组员请求支援都能解决并使得记得能正常进行的，则在可控范围内解决；如果范围太大，则说明前面的设计或者任务拆分上出现了严重的问题，此时就需要领导及时调整方案策略，或者向公司上级领导请求其他支持之类的；
5、测试阶段：
测试阶段分两个阶段，一个是开发工作还没有完成的时候，一个是开发已经全部完成的时候。在前一种情况的时候，测试是在开发环境进行测试的，此时早会会正常进行。开发人员已经开发完成的时候，早会可以取消，每天早会时间，测试人员在敏捷小组群里发一下测试进度，以及遇到的风险。
测试测试出来的Bug，开发要及时的修改，每天把剩余Bug数控制在一定范围内，避免最后进度失控，另一个需要注意的是比较大的修改则需要请组内的经验丰富的开发做代码审查，避免改掉一个Bug结果引出多个Bug的现象；
6、迭代反思总结阶段：
每个迭代完成后都需要开个迭代总结会，会上把遇到的问题提出来讨论，总结出现这些问题的原因和症结所在，找出解决的办法，在下一个迭代中进行改进；如果某个方法在多个迭代中被验证是行之有效的，那么可以以制度化的方式固定下来；
标签：另一个 运行 需求文档 用户 ali 地方 成功 建议 编写
原文地址：https://www.cnblogs.com/laoxia/p/11590279.html
