确保你没有构建高效团队更快地交付错误的事情
不管选择什么框架,任何产品迭代和增量开发方法可以减少到一个目标:创建一个工作产品短周期。
一个工作产品是“完成”。做意味着“没有什么剩下要做”。
“没有什么剩下要做”意味着工作状态的结果,可以发布时使用的终端用户。它不仅解决了核心功能还包括所有性能和安全相关的问题。
Ken Schwaber共同创造者的一个最流行的框架,以处理复杂的问题,解释清楚:
Ken Schwaber谈到了“完成”的定义。
此外,短周期”的频率是足够短,以减少风险的花时间在错误的解决方案太长(有时也称为一个浪费钱)”。
例如,在Scrum中,Sprint是短周期不应超过一个日历月。它导致“完成”的增量(工作产品)在最新的时间框,但多次理想过程中:
2019年的加速DevOps的状态:精英性能、生产率和扩展(注:这是给软件开发环境,由软件开发和Scrum并不局限)
一个工作产品主要测量的进展。幻灯片演示或破布状态报告监控状态交货管理干系人的期望比处理现实。
重关注后者活动(间接指标)的结果是一个开放的邀请增加默默无闻,依赖、风险和负面的ROI。它可能为当地铺平道路问题,恐惧,说谎和谄媚的文化。一些严重的后果相关联。如果你不相信我,问诺基亚高层/中层管理人员,工程师和外部专家。
是实现了“工作产品”在短周期足够了吗?
到目前为止一切我们已经是谈论“上市时间”。
减少投放市场的时间需要技术卓越,能够改变产品在一种轻松、快捷的方法。
技术优势需要良好的工程实践、自动化工具如,它消除了大量的内在和外在认知负荷。
约翰溶胀剂的认知负荷理论适应软件开发环境(灵感来自团队拓扑)——创造的视觉领域Guvenilir
但是“创造价值”呢?尽管减少“上市时间”能够提供更多的价值更早(因为提前交付价值的唯一方法就是…嗯早释放?),它并不能保证。
价值的定义可以根据上下文是不同的。标准考虑到当定义值并不复杂:
简单,价值的好处组织(钱,投资的回报),它的客户(幸福)和社会(许多人的生活变得更好),生成使用产品/服务的结果。因此,认为这三个高级价值的受益者。
现在,想象一下一个团队,可以部署到生产需求,一天多次。他们“改变失败率”< 10%。他们的“交货时间改变”从致力于代码运行在生产不到一天。他们还建立一个非常有弹性的/可靠的系统,和“平均恢复时间”并不比一眨眼的时间要长。
但是,如果他们做的是提供低价值物品更快呢?如果他们提供的增量不让顾客快乐吗?(如果你依赖于收入提取的商业模式,你会把你的客户变成敌人!)
,通常是当没有关闭反馈回路之间的生产者(开发团队)和消费者(产品)的用户,或检查不适应紧随其后。
重要信息:
- 技术优势降低“上市时间”。
- 减少“上市时间”使一个组织能够提供更多的价值。
- (2)是间接的。它只能帮助不断检验和适应。否则,该组织可能会更快地交付更没有价值的东西。
- 确保技术卓越、质量和创建“完成”增加,即使在提供更少的成本输出,是开发人员的责任。
- 确保定义的“价值”,清楚地理解每个人,连续测量和“完成”的增量的开发人员提供最高的价值是产品的责任专家。
- 治疗任何威胁(4),(5)作为一个障碍和解决(帮助开发人员、产品专业人士解决)这些障碍的责任经理和变革推动者。
奖金:但B2C和B2B是不同的…
是的,他们也是。不需要拐弯抹角。至少,这是我的经验。
如果一个B2B组织的决策者认为,他们不需要一个迭代和增量的产品开发方法,需要频繁的检查和工作产品的适应,这是可以理解的。他们的反应可能是连接以这种方式,因为他们负责“合同”驱动行为。或者,他们是对的吗?
但他们需要问自己:“断言宇宙大爆炸的证据是什么交货将是一个更好的适合让我的顾客开心,增加ROI和减少商业风险为我组织?”
最后,Bas Vodde和Craig Larman已经讨论了使用传统的影响对敏捷软件开发计划的工程承包:敏捷合同
引入敏捷合同(https://agilecontracts.org/):
“敏捷软件开发从根本上是不同于传统的工程承包。
使用传统的敏捷开发项目合同可以危及到项目执行,导致公司无法获得敏捷开发的潜在好处。
这个页面的目的是收集引用敏捷合同支持组织改变他们承包模式,减少风险和获得更多的利益采用敏捷开发。”
如果我抓住一个小妖精,我牺牲我的一个愿望,任何组织的每个人都读过他们的建议在上述文档和深入思考“收缩与客户及其影响的工作方式”。
请写一个评论或联系我分享你的观点。