一个真实的大规模敏捷开发的故事
2019-12-24
来源：敏捷行动派
度，确保有足够的推动者推动大房间计划。通常情况下，一名推动者可以应付一到三支团队。
那支12个人的团队有另一个要克服的难题。它简直太大了，很难在一起做有实际意义的计划。我走过去告诉了他们。他们所有人一起看着我，就在我刚要告诉他们拆分之前，Pia赶紧走过来低声对我说，“嘘，Ole。交给他们自己处理，看看会是什么结果。”然后，不一会儿他们就站起了身，分成了两组，开始了单独的交流。很快，他们就弄了两块团队看板讨论起来。他们自己组织成了两个团队。太神奇了!
给予控制权，形成自主性
面对大问题时(以及所有其他类似的局面)，你需要让个人发挥主观能动性。否则，你永远都无法取得成功。和那么多人在一起，你作为管理者是无法计划和控制所有问题达成目标的。你只能让他们拿出主动性，如果你给他们控制权，会比你大包大揽要好。
现在，我们只剩下“我们不理解史诗故事”这个难题了。但在大房间计划期间这一点没那么重要，所以我们并没去解决它。
我们很清楚，让商业各个部门陈述和交付史诗故事就会带来这样的问题。我们坚持六月这一天是不是难度太高了?如果我们给他们更多的时间，团队会不会更多地参与到描述中，从而理解史诗故事?实际上，我们不这么认为。我们把它视为一个学习机会，我们向自己保证，在三个月后的大房间计划会之前要支持团队更好地理解史诗故事。
设定一个日期——促使大家去做准备
为第一次大房间计划会设定一个多少偏乐观的日期，能促使大家去做准备。如果你想等所有人都准备好了，那么可能你会永远等下去。
切分——细化——理解
在团队以某种方式开始开发一些业务特性之后(最终，与业务部门有很多的交互)，他们想为下次大房间计划会做准备了。这是出于业务方面的考虑，我觉得这非常好。我们已经有了主人翁精神。这不再是管理者的计划，而是他们自己的计划。
其中一支团队请我帮忙解答一个问题：完美的史诗故事看起来是什么样的?
我看了看我在以往项目中经历过的史诗故事。又看了看别的项目中其他的史诗故事。我思忖良久，又看了很多，最终觉得很泄气，因为我没找到一个可以称之为完美的史诗故事。
然后我开始思考成功的项目和不成功项目之间的差异，发现史诗故事的格式无关紧要，甚至其他任何模版或需求规格说明书都是如此。
我遇到该团队后跟他们分享了切分和细化需求的关键：
共同理解
切分史诗故事的方式
描述的格式
这些顺序分先后，所以史诗故事的格式在这三点之中相对最不重要。
为开始共同理解它，我们做了两件事。第一件事，我们把他们带来的需求进行了分组。史诗故事、特性和故事融为一体是种不错的组合。有些人问道：“这是故事地图吗?”我说，“是的”，然后解释了为什么我把故事地图看得这么简单：把你的需求放在一张表外，然后移动它们使结构合理，最好将潜在的发布作为结构的一部分。
这引发了一场关于如何组织需求的激烈讨论。大多数需求都与三个新投资银行产品有关，从简单的投资建议到完整的投资证券组合支持。大多数人辩称应按产品切分(潜在的发布)，所以我们应该将一个产品100%开发完成，把它投入到市场，然后再转向另一产品。其他两个人主张我们应该首先为所有这三款产品想出所有的法律问题，因为不管怎么说我们已经有律师参与了，然后是所有这三款产品的上市计划，再
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
