对于敏捷扩展,并没有按部就班的方法,但有了固定的原则,软件开发团队将会有据可依地创建高质量的企业软件。
敏捷方法的基本现场理念是,它要适应团队的需求,并持续改进。所以,该方法需要注意的一点是不能被条条框框锁定,不能明确定义出团队应该使用什么实践。SAFe提供了一个框架和指南,但却取决于敏捷团队的成员,例如喜爱美食的厨师,会根据他们的不同需要进行调整。为了帮助他们进行选择,SAFe为敏捷扩展提供了九个基本原则,如果考虑的话,它将帮助创建高质量的软件。
从经济角度出发
从精益原则中衍生出的第一个价值需要以最有效的方式给客户交付价值。每一天所做的决定都要以经济为前提进行思考。对于知识工作者来说,了解延迟的成本和在没有扩大管理范围前赋予决策权很重要。
运用系统思想
系统思想由Edward Deming引入,适用于所有类型系统,包括制造、社交、管理和治理系统。从更大的角度来看,系统的复杂交互是改进流程的质量的关键。根据SAFe的上下文,系统思想可应用于不断完善了和企业正在开发的产品中——它需要新的方法进行管理。
假定变量,预留选项
尽管系统思想者倾向于减少变化,这一原则提醒我我们,我们并不希望过早地消除变量。与其浪费时间在一个不是最优的特定设计上,还不如考虑更好的方法,称为集设计——开始于多项设计选择,随着时间的推移消除不好的,直到最优的设计出现。
使用快速、系统的学习周期构建迭代
这一原则是所有敏捷方法的一个最主要的特性——迭代开发。团队使用短时间盒构建工作软件,收集反馈,并持续改进来满足客户的需求 。集成点用于整合元素成一个整体,并测试可变性。这些点可用于学习和改进,这样发生的越频繁,学习的就越快。
基于对工作系统的客观评价设立里程碑
这一原则重点要于评估迭代构台小型工作系统,而不是使用瀑布式衣服的传统阶段式里程碑。里程碑应该基于工作系统的客户证据建立,使用第四原则中的集成点。
可视化并限制WIP,减少批量大小和管理队列的长度
使用任务板或Kanban,半成品(WIP)可以可视化,但是需要限制最大工作流。减少WIP并提升工作流的一个方法是减少工作项目的批量大小。处理小型的批量可通过加强对自动化和持续集成的注意来完成。
跟上节奏,合拍跨域计划
节奏为这些日常功能事件提供了一个可预测的例行程序,让知识工作者关注那些具有变量参数的任务,并要求更多的创新和创造性思维。同步用于整合多维视角。在SAFe中,发布计划活动发生在当利益相关者一起评估现阶段的解决方案,并重整共同愿景,并计划致力于下一阶段程序迭代。
解锁知识工作者的内存激励
管理人员需要建立一个环境,给知识工作者提供内存激励,通过赋予他们做出经济有利的决策权,收集频繁的反馈,并持续学习和提升他们的技能。正如Daniel Pink的书中指出,动机,知识工作者需要自主,也是高绩效团队的一部分。领导应该提供一个任务和强大的撔,并减少各种对于需求实现的限制。
分散决策
虽然有些对于敏捷扩展的战略决策仍然要管理导致决定,但赋予知识工作者做大部分决策的权利将会提升工作流,并加快反馈周期。组织将会从建立决策框架中获益,并给决策标准提供指导。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
DevOps和敏捷相结合 改进软件质量
DevOps实际上是打破了开发人员和运维人员之间的壁垒。在运维团队,你所考虑的方面可能与开发团队不同。但如果我们能更加了解相互的工作,将会更为深入得理解所需的工具和设备。
-
协作对敏捷方法的重要性
协作的意思说是一起工作,而不是单独去完成某项任务。敏捷方法强调了与跨功能团队合作的好处,大大加强了业务负责人之间的沟通。
-
敏捷式 vs. 瀑布式:软件需求最佳方式
确定软件需求很困难。很好地理解客户需求,在改变发生时维护文档和需求都不是容易的事情。
-
如何实施整体团队敏捷方法
达到整体团队敏捷方法很难。这里讲述了一个教练如何采取不同寻常的方法来使她的团队成员相关讨论、寻求帮助,以及把所有问题看作是团队级别问题来处理。