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

1.3 处理不确定性

在复合区域,传统的工程实践效果不理想。使得基于过去的事件来制订计划成为一个不可行的做法。必须要有一种更实战的方法。这就是这些年软件开发实践者们所学到的东西。这并不意味着他们不做计划,他们只是做法不同。在复合区域,不管你多么小心地规划未来,如果你不每天调整你的计划,它将更可能只是一场梦。
让我们来举例说明这一点。设想一下,如果有人声称:她可以根据详细的传统计划开发一种超级药品。作为投资者,你会仅仅根据一个计划就投资几百万美元做这个项目吗?事实上,完全遵照一个计划而没有持续的调整以适应变化是不可能做到的。经理们和投资人通常会避免投资这种波动太大的项目,因为针对“如何做”有太多的不确定性。各级组织这些年学会了一件事,那就是如果在“如何做”这件事上有太多的不确定性,那么他们是不会采纳传统方法的。
图1-4展示了适用于研发(R&D)的复合区域。你可以假设在这个区域,关于需求“是什么”几乎没有不确定性。通常的情况是,我们需要解决什么问题是没有分歧的。所有的风险都跟解决方案有关。

相反,当几乎所有的风险都跟需求有关时,你就会面临大多数软件开发团队所经历的问题。图1-5正是说明了这种情况。这时候适合使用敏捷框架,比如Scrum。

那些千千万万参与签署“软件开发敏捷宣言”的人们这些年明白了使用传统的工程实践去解决复合区域的不确定性是很困难的。因此,他们提倡使用不同的策略。这一点对研发(R&D)来说也一样正确。研发和敏捷都是用一种受“试错”流程影响的非传统的方式去解决不确定性。试错是一种启发式解决问题的方法。只有最有希望的尝试才会被采纳,并在将来的尝试中逐渐改进,而那些被认为不太有希望的则会被淘汰掉。当需求处于不断变化的情况时,你必须使用基于“试错”流程的迭代式探索的方法。

时间: 2024-09-20 23:35:46

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

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

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

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

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

《敏捷可执行需求说明 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.4 小结

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

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

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

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

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

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

2.8 小结 本章主要介绍了如何识别出不会轻易发生变动的软件属性和如何建立坚实的基础.它首先强调了一个运作良好的团队以及让所有干系人参与的重要性.接下来讨论如何确定一个共享的愿景.有意义的共同目标和一组高级别的特征,这些都是设立一个明确而清晰的目标的核心.因为这三个要素不太可能很快发生变化,它们是每个人都可以依赖的防护栏.虽然设置边界很有必要,但仅有这个还不足够,尤其是当你面对的是一个变更持续发生的情况时.尽管这个解释似乎过于化繁为简,但这只是朝着掌握可执行的需求说明书前进的一小步.创建新的软件