《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.7 验证“可能存在”的假设

2.7 验证“可能存在”的假设

所有的软件都是为了解决问题而存在的。这个关于存在的假设是所有解决问题的人们共同认可的通用起始点。这个“可能存在”的假设在人类创建任何事物时都会出现。开发人员总是从可能存在的解决方案,和该问题将会被解决的假设开始研发一款新的软件产品。
有了愿景、有意义的共同目标,以及高级别的特征,产品负责人应该和开发团队坐在一起明确地验证“可能存在”的假设。另外还要确保每个人的理解都一致,这样能够快速发现技术问题。
在“可能存在”的讨论会上,发现根本不可能构建出软件产品的情况极少会发生。这种情况下,讨论活动似乎是不必要的。然而不可忽视的是,讨论主要是为了保证愿景被开发团队所有人都知道并理解。
作为“可能存在”讨论会的后续追踪,产品负责人应该跟Scrum Master 一起工作,保证团队将共同的愿景张贴在一个开放的场所,这样所有的团队成员,包括路过的同事也可以看到。并且,当一个新成员加入团队时,Scrum Master的首要任务就是要跟他一对一的谈话,针对愿景、有意义的共同目标和高级别的软件特征进行沟通。

时间: 2024-09-14 22:55:00

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.7 验证“可能存在”的假设的相关文章

《敏捷可执行需求说明 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.3 处理不确定性

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

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

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

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

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

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

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