加载中...

敏捷开发

关于敏捷开发:

敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

 

流程图:

 

优点:

更快交付价值

敏捷是基于价值驱动交付,项目团队要频繁的且尽快的给客户交付可以使用的产品,并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值,这是敏捷提倡的核心价值之一。

 

更低的风险

敏捷提倡优先交付高价值、高风险的需求,然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做,可以最早发现该产品是否可行(通常只要1~4周)。如果因为市场、技术或者其它原因失败了,可以及时停止该项目,降低项目风险。即使这个项目失败了,这个失败的代价相对来说小一些。
 

拥抱变化

在VUCA 迭代开发的后期也接受变更。因为市场在变化,用户的期望和要求在变化,客户的需求也会随着这些因素的变化而变化,只有及时响应这些变化,并尽快予以实施,才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。
注:VUCA,VUCA是 volatility(易变性),uncertainty(不确定性),complexity(复杂性),ambiguity(模糊性)的缩写
 

更好的质量

敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关,因为在这几个会议中会频繁讨论遇到的问题/解决方案,验收标准,DoD等等。同时,也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈,这样团队可以及时予以调整,以确保质量。
 

持续的改进

敏捷提倡不断调整和优化,并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方,进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习,不断提升自己经验、技能的一个很好的机会。另外,因为敏捷强调客户参与的重要性,对于客户的反馈意见和建议,开发团队也会及时给与相应以及反馈,让双方可以更好的合作,建立更加信任的合作关系。
 

更高的客户满意度

敏捷提倡尽早和频繁的为客户交付有价值的产品,以确保更高的质量,更高的成功率,为客户尽早带来商业投资回报率的机会。

 

更好的团队满意度

敏捷提倡仆人式的领导,SM需要给团队工作上的指导、帮助和支持,扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见,授权团队并引导团队成员自组织和自管理。更重要的是,团队成员可以决定要做什么、怎么做、什么时候做,并自己监控和管理工作进展,对结果负责;团队成员可以一起讨论并确认工作协议,确保考虑并接纳每个人的意见;团队成员可以一起评估故事点;同时,SM要引导团队成员之间相互协作并促进合作。通过这些,团队成员可以更高效的工作,交付的质量也会提高,团队成员的满意度也会大大提高。
 

更大的灵活

敏捷基于价值驱动,它的项目范围是可以灵活调整的,这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外,敏捷提倡频率与团队和客户沟通交流,并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有,验收标准,都可以根据实际情况进行调整。
 

缺点:

测试人员工作压力大,休息时间少,几乎没有喘息的时间。

不同版本的bug管理比较混乱,验证起来需要梳理清楚,最好是借助专业的管理工具。

bug反复性高,可能在短时间内甚至不会出现bug逐步下降的正常趋势,而是产生较大的波动。

开发无法按照bug等级来确定工作优先级,因为可能在改一个中等bug,突然来了严重bug,也得等上一个bug改完的。

需求改动频繁,可能昨天做的功能或者做一半的功能突然就舍弃掉了

 
posted @ 2022-04-21 00:40  luckyjcx  阅读(471)  评论(1编辑  收藏  举报