《敏捷可执行需求说明 Scrum提炼及实现技术》—— 1.2 识别不确定性的影响

1.2 识别不确定性的影响

不确定性原理图如图1-2所示,这是Ralph Stacey的工作宽松适应图[6],它提供了一个可以帮助你将不确定性对“是什么”和“如何做”的影响的图形化模拟的示意图。

横坐标度量的是关于如何实现一个技术方案的不确定性程度。不确定性低代表的是过去曾经解决过类似的问题或者做过类似的决策。因此你可以从过去的经验里推断出某一行为导致的后果的确定程度。纵坐标衡量的是干系人之间需求的不确定性。当干系人们期待的软件产出物稳定且可预测性高时,不确定性程度就低。
在这个不确定性原理图中,有三个很有意思的区域。
1)简单和复杂区:传统的区域
很多文献和理论都描述过“简单/复杂”区域。传统的工程实践适用于这个区域。它们包括规划具体的、获得成果的行动路线,以及通过与计划对比监控实际的行动情况。在这一区域,重点放在从过去收集数据来预测未来。
2)混沌区:混乱的区域
不确定性和分歧存在的情况往往会导致瓦解或混乱。在混沌区域几乎不可能完成一个方案,因为传统的计划、愿景规划和谈判方法都不能解决问题了。
3)复合区:敏捷的区域
这个区域在图例中位于混沌区域和“简单/复杂”区域之间。Stacey 将这个位于中央的、面积最大的区域称为“复合区域”,也有人将它称为混沌边缘区域。这是一个需要非常高的创造性、创新性,打破以前的方式从而创建新的模式的区域。
以这个不确定性原理图为基础,图1-3用图示说明了传统工程实践最有效的区域。

这种计划驱动的方法在不确定性很小时,是最佳选择。而在不确定性很大的情况下,关于要构建什么,传统的实践者们希望用项目开始时的需求分析阶段,以及严格的需求变更流程来帮助实现预期目标。他们假设关于“是什么”的不确定性是很容易被降低的。这在不确定性不是很高的时候确实很容易做到。不幸的是,这种做法很难应用在复合区域。当面对复合状态时,过往经验会鼓励你尝试打破歧义,并采用最简约的思考方式来解决任何矛盾。这似乎是顺理成章的事情,因为它可以提升我们的掌控感。然而,事实却远非如此。你必须使用一种更强大的方法。

时间: 2024-09-19 16:18:41

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 1.2 识别不确定性的影响的相关文章

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 导读

前 言 市面上关于需求说明方面的书籍有很多.不幸的是,这些书绝大多数对于软件开发团队来说都不实用.因为那些书依赖于传统的工程实践.他们假设需求是可以事先获得的,并且一旦被写出来,在项目进行过程中就不会再修改.而且,他们认为就算发生变更,都是一些细微的变化,因此,可以通过变更管理流程来进行追踪.他们创建了从明确需求阶段开始的系列流程,而这个阶段将在团队开始设计和实现产品之前提供详细的需求说明.本书目标 我认为传统的工程实践对软件开发来说并不适用.提炼软件需求说明的流程的核心问题是不确定性很高,这与

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 第1章 解决正确的问题

第1章 解决正确的问题敏捷是一组鼓励快速.灵活地响应变更的软件开发框架.它们基于迭代开发实践,需求和解决方案都在跟客户合作过程中逐渐演进并完善.2001年发布的"敏捷软件开发宣言"[1]引入了敏捷这个词.Scrum[2]现在已经成为最著名且使用最广泛的敏捷框架.Ken Schwaber和Jeff Sutherland[3]设计的Scrum框架,由角色.事件.工件以及将它们整合在一起的一系列规则组成.Scrum使研发团队通过频繁地检查和调整,并不断优化产出成果,最终构建复杂的产品.这个术

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 1.1 从解决方案中甄别需求

1.1 从解决方案中甄别需求 敏捷并不排除从解决方案中甄别需求的必要性.它是一种从"如何"构建中识别出构建"什么"的有效实践.即使你将交付产品的迭代周期缩短到30天以内,团队仍然需要在解决问题前理解问题.不同的仅仅是需求说明方式.为了更有效地合作,只有利于开展需求相关的交流讨论的关键内容才会被文档化.描述"是什么",即需要解决的问题,组成需求说明的核心内容.需求说明定义了软件产品需要做什么,但不是"如何做".很显然,需求说明的

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 3.2 应用短周期反馈环

3.2 应用短周期反馈环 为了实现考虑周全的探索过程,敏捷框架(例如Scrum)力求采用严格的试错流程.他们通过短周期反馈环不断地根据干系人的需求说明检查和调整软件.频繁的反馈环提供给人们以最小的成本代价修正错误的能力.团队的责任是不仅要从问题中学到教训,还要帮助干系人理解团队正在给他们构建的是什么.对于需求探索来说,需要很早就启动不断循环的反馈环. 在Scrum框架里,一个反馈回路就是一个Sprint.如图3-1所示,一个Sprint就是一个可以交付产品增量的迭代时间盒. 同一个项目里,每一个

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.2 组建一个健康的团队

2.2 组建一个健康的团队 构建软件产品仍然是个体之间高度互动的活动.我们可以通过增加干系人和团队之间的高质量互动来降低一些意外产生的难度.不幸的是,你不可能控制干系人.他们仅仅是他们自己.然而,你可以组织团队来弥补这个遗憾.你可以很容易地影响团队的规模.结构和合作模式.获得坚实基础的最简单的方法就是有个运作良好的团队.团队是因为一个共同目标而聚集在一起,并拥有互补技能的一群人.如果你实施Scrum框架,你应该已经意识到一个健康团队所拥有的属性:自主性.跨职能,以及拥有不超过10个同辈成员的自组

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 3.5 小结

3.5 小结 本章讨论了运用试错法应对不确定性的价值,尤其是如何在软件需求探索环境中运用试错法.敏捷框架(比如Scrum)都力求严格的试错流程.这种刻意的探索方法使得团队能够不断地检查和调整以适应不断变化的需求,从而通过短周期反馈环澄清那些未知的问题.短周期反馈环促进了团队跟干系人之间关于"愿求"的讨论,使软件开发过程更加透明和有效."愿求"是干系人们期望的.并可看成是可演示的功能的一部分.在下一章里,我们将讨论如何表达"愿求"以及如何组织它们,

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 1.3 处理不确定性

1.3 处理不确定性 在复合区域,传统的工程实践效果不理想.使得基于过去的事件来制订计划成为一个不可行的做法.必须要有一种更实战的方法.这就是这些年软件开发实践者们所学到的东西.这并不意味着他们不做计划,他们只是做法不同.在复合区域,不管你多么小心地规划未来,如果你不每天调整你的计划,它将更可能只是一场梦.让我们来举例说明这一点.设想一下,如果有人声称:她可以根据详细的传统计划开发一种超级药品.作为投资者,你会仅仅根据一个计划就投资几百万美元做这个项目吗?事实上,完全遵照一个计划而没有持续的调整

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 1.4 小结

1.4 小结 本章探讨了为什么团队对解决"正确"的问题感到困难,这也许远比你想象的更具有挑战性.从一开始就认识到敏捷并不是要排除从方案中识别需求的做法.这仍然是一个将"是什么"和"如何做"区别开来的好实践.接下来讨论了不确定性和需求.你看到了传统的需求收集方法不适用于软件产品开发.即便你抱着最好的意图,也不可能强迫干系人同意.当需求很难把握或者一直变动时,团队不应该依赖于传统工程需求收集的方法.最后,本章总结出团队应该拥抱变化,并采用基于迭代式需

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.4 明确一个可以共享的愿景

2.4 明确一个可以共享的愿景 当你让这些干系人参与时,澄清愿景显得非常必要.谢天谢地,由于你使这些干系人紧密地合作,你就不会面对一团糟.你应该在早期就以最小的代价来强调愿景.如果产品负责人和干系人们讨论一个长远目标或者软件产品的意图时,就应该会得到一个大家都认可的产品愿景.比较完美的情况是,软件产品的名称将清楚明确地概括出产品的愿景.名字是人们第一次接触到的关于软件产品的介绍.名字将被重复使用,就会在人们脑海里形成深刻的印象.不幸的是,事实远不是这样.名字通常由市场部或项目管理办公室提供,他们