敏捷模型的优点与缺点

scrum里面的三个角色：

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产 品负责。

scrum master 负责召开各种会议，协调项目，为研发团队服务。 研发团队(开发人员，测试人员，ui设计人员...)则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

scrum里面的五个会议：

产品经理负责整理user story，形成左侧的product backlog。

发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出 这一期迭代要完成的story列表，sprint backlog。

迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有 明确的负责人，并完成工时的初估计。

每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。

演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成 果。期间大家的反馈记录下来，由po整理，形成新的story。

回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改 进的效果。

特征：

迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成，有些项目则每天都在这么做。现在的低代码开发平台也是敏捷开发的一种产物，它可以根据企业不同阶段的需求对软件的功能进行多次开发，而不会影响软件的正常使用。

开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

适用场景：

产品复杂，不断有新的需求加入。当产品的开发受市场影响较大时，业务需求的变动就十分常见了，为了不影响项目开发进度，需求管理必不可少。有些团队会一个个排需求、做需求，而敏捷开发是通过任务分解把工作拆分为半天到几天的工作量，然后制定里程碑时间点，将复杂的需求细化成一个个小任务，再根据轻重缓急梳理优先级，简单快捷地帮助开发人员化繁为简，提高效率。

团队庞大，沟通协作效率低。有时一款新产品的开发，需要多部门联动协作，然而每个成员的岗位和职责不同，所以每个人关注的项目信息不一样，关注信息的频率其实也不一样，有的比较频繁，有的则可能整个项目过程就只需沟通两三次。由于每个人的习惯不同，所以他们获取信息的手段也不太一样，有些人喜欢微信、QQ，有些人喜欢邮件，还有些人喜欢以会议的形式获取信息。这就导致了团队内部沟通效率低下，许多重要的信息难以实时传递。

希望高效地管理开发进度。产品经理为了掌握项目的进展，掌握各项工作的状况，就必须对项目过程进行监控和跟踪。只有这样，出现了问题，才能及时进行资源调整和进度计划调整，重新规划某一个任务开始和结束的时间，并记录实际的进度情况。

优点：

·频繁交货

·与客户面对面的交流。

·高效的设计并满足业务需求。

·随时可以接受更改。

·它减少了总的开发时间。

缺点：

·由于缺少正式文件, 因此会造成混乱, 并且各个团队成员随时可能会误解贯穿各个阶段做出的重要决定。

·由于缺乏适当的文档, 一旦项目完成并且开发人员被分配到另一个项目, 完成的项目的维护就会变得很困难。

何时使用敏捷模型？

·需要频繁更改时。

·有一支高素质和经验丰富的团队。

当客户准备好一直与软件团队开会时。

·当项目规模较小时。