《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.5 识别出一个有意义的共同目标

2.5 识别出一个有意义的共同目标

有时候对于干系人来说识别出产品愿景是很困难的。这种情况在干系人企图看清未来的长期目标时经常发生。如果是这样,有一个办法可以帮助团队重新专注于围绕为来年制定一个有意义的共同目标的讨论。
除了帮助巩固产品的愿景,一个有意义的共同目标的概述是一个很重要的资产,因为它清晰地从干系人的视角阐明了为什么产品有存在的必要。它存在的理由是什么?虽然开发团队知道如何构建软件,但很少有人对软件领域懂得很多,更少的人甚至不知道他们“为什么”要做以及要做什么。“为什么”意味着驱动他们行动的动机,共同目标证明了软件存在的必要。“为什么”会帮助开发团队理解干系人的动机,使软件的共同目标清晰明了。
识别出一个有意义的共同目标通常在干系人面对面的会议中完成。三步骤启发式命名方式——为了一行字描述而争论——应该不仅用来改进目标,也可以用来保证一个开放的讨论和干系人之间可以共同理解。下面是“MTA智能卡自助服务车票咨询站”的共同目标:
不增加运营成本的情况下成倍增长销量

时间: 2024-10-28 05:55:50

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.5 识别出一个有意义的共同目标的相关文章

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

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

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.1 界定不可更改的边界

2.1 界定不可更改的边界 团队识别出那些几乎不会改变.你可以理所当然地看做是边界条件的事情,这些事情用来协助指导团队做决策.这些边界条件不仅保证方案得以实现,还通过澄清需要被构建的功能边界来缩小方案的解决范围.它们给团队提供了一个帮助他们保持健康状态的基础.面对不断变化的需求,团队往往显得徒劳无功.因此,团队必须保持高度专注,以便持续提供有价值的产品功能.这些边界提醒人们关注产品的目的.整个团队不仅要共同拥有这些边界条件,也需要每个成员都熟知.以下是一组需要落实到位并赖以探索不确定性的边界条件

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

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

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

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

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

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

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

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

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

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

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 3.1 运用试错法

3.1 运用试错法 当遇到很多不确定的因素时,我们必须识别出作为人类所面临的局限性,并接受我们很难指望通过一次尝试就能获得成功这样的现实.有时需要多次尝试.成功的唯一途径就是失败.因此,需要及早并且经常地失败. 从不断的失败中获得成功很少被上升为一种积极的体验.然而,如果你是一个幸运的孩子,你的家人会鼓励你及早并经常失败.如果你真的够幸运,你的老师也会这样做.不幸的是,我们其他人,常常从小学开始就被要求一定要找到一个完美的结果,好像每一个问题都有确定的答案一样."失败是很糟糕的!"这种

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 2.3 要求所有干系人参与

2.3 要求所有干系人参与 当团队运作良好以后,你必须确保所有干系人都参与到需求探索的过程中来,这样团队才可能构建一个正确的软件.从一开始,产品负责人就必须识别出干系人,确定他们能够参与,并尽可能处理他们对需求相关的影响. 干系人是指与软件利益攸关,又不能直接参与软件的构建过程的任何个人或群体.基本上,任何除了产品负责人.ScrumMaster或团队成员以外的人都可能是干系人和潜在的可以提供有效反馈的资源. 在简单世界里,只会有一个干系人,他就是为软件项目付钱的发起人.在真实世界里很少有这种情况

《敏捷可执行需求说明 Scrum提炼及实现技术》—— 第3章 使用短周期反馈环探索干系人的“愿求”

第3章 使用短周期反馈环探索干系人的"愿求" 上一章解决了当软件需求存在许多不确定性的时候,一个健康的团队.有着共同的愿景.有意义的共同目标和一组高级别的特征都很有必要.它们组成了引领团队前进的坚实基础.确定产品的愿景只是一个更庞大的创建成功的软件产品的流程的第一步.为了使软件产品成为现实,下一步就是学会如何应对干系人们持续变化的需求.首先,需要通过短周期反馈环的方式运用试错法,其次,你必须专注于干系人的愿望和需求.这就是本章的意图.