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

2.2 组建一个健康的团队

构建软件产品仍然是个体之间高度互动的活动。我们可以通过增加干系人和团队之间的高质量互动来降低一些意外产生的难度。不幸的是,你不可能控制干系人。他们仅仅是他们自己。然而,你可以组织团队来弥补这个遗憾。你可以很容易地影响团队的规模、结构和合作模式。获得坚实基础的最简单的方法就是有个运作良好的团队。
团队是因为一个共同目标而聚集在一起,并拥有互补技能的一群人。如果你实施Scrum框架,你应该已经意识到一个健康团队所拥有的属性:自主性、跨职能,以及拥有不超过10个同辈成员的自组织团队。
对团队来说最重要的元素是存在一个全心致力于软件需求说明的人。这个人为产品需求说明负责。在Scrum框架中,这个人叫做产品负责人。
第二个重要的元素是团队拥有一些技能和专业知识互补的开发人员。在一个健康的团队里,开发人员可以通过个体的责任感共同承担一些角色,如程序员、测试员、分析师、系统集成员或者架构师,发挥协同作用。这就可以让每一个开发人员最大限度地发挥其所长,同时也能最大限度地降低其弱项造成的影响。
第三个重要元素是产品负责人要确保开发团队最终能够交付产品。一个开发团队不需要不愿意分享知识技能的个人主义英雄。团队通过避免成员之间的松散关系,以及经过多次要求不同成员之间共享合作和集体拥有的迭代得以繁荣发展。在一个健康的团队中,需求说明是一个共有并且共享的资产。即使产品负责人是那个为需求说明背书的人,团队中的每一个人也都必须参与到围绕需求的讨论中来。
组建一个健康团队的第四个(也是最后一)个重要元素是团队成员之间利用事先设定好的事件不断检查和调整。Scrum框架为团队检查和调整设定了四个正式的机会。
sprint计划会议
每日Scrum
sprint评审
sprint回顾
每个事件都为Scrum团队正在进行中的工作提供了检查和调整的可能性。最重要的是认真执行这些循环发生的事件。这就是为什么会有一个专门的ScrumMaster来确保这些事件被理解且被执行了。

时间: 2024-11-04 00:12:23

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

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

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

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

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

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

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

《敏捷可执行需求说明 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提炼及实现技术》—— 3.5 小结

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

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

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

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

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

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

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