“搞敏捷,你我要有个约定,请不要忽悠我”
我们的最终目标是要从需求分析开始进行敏捷实践,因为需求分析才是敏捷的开始。
我害怕我们一直坚持在做的,那些正确的实践,到最后都变成没有错误的无价值品,那么敏捷的精神在哪里,真正的价值驱动体现在哪里?
各种看板、Story拆分、任务划分、验收条件等等这些应该成为价值验证的有力工具,被我们当作验证设计文档里面的文字转化成可用的代码,但对于它是不是被需要,我们并不关注。
那些隐藏在200页设计说明书里面的需求,那些淹没在文字里的细节和那些没能够达成共识的设计,因为这个复杂的文档,和它之前那长达数个月内经历的多次评审,变得理所当然的准确无误。当认为有时开发团队的人太固执于实现细节的时候,你其实并没有太多硬性的责任让需求转化为可用的软件,你更多的时候,只是尽义务地等待那些刚进入团队不久的新人,羞涩地向你提出本该你主动解释清楚的问题,而你的工作,应该在那部巨大需求设计文档的最后一个句号后基本完毕。
让开发团队与"需求团队"紧密合作:把"模块设计师"尽量推向客户,让需求收集、分析和设计在一个团队完成,并使这个团队和开发团队紧密合作。
如果一个80个人的团队,只有一个分析人员进行需求的澄清,绝大部分依靠文档传递需求信息,寄希望于开发团队能够根据文档实现需求真正的功能,需求失真后又必须等待到上线时才能发现,若管理一个天才团队,我尚未有足够信心,对一般水平的开发团队而言,真的不是拆分Story,每日晨会,故事墙能够解决的问题。
当我被问道:“请问如何拆分Story才是正确的?”,但上下文是分析人员基本不在团队内,需要由开发人员尝试理解文档并写用户故事,这样的问题,我确实无法回答,因为我怎样的回答,放在这个上下文里,都是没有实际意义的。
敏捷是一个太容易被误解成工具集合的概念,认为它是一套方法论指导下的工具集合,使用其中某一部分的工具便能达到预期的效果,但是实际上,敏捷中的所有实践都是这个方法论体系中不可缺少的东西。我明白,学习敏捷需要阶段,但第一课应该学到的是,如果开始敏捷,请答应我在不远的未来实现两件事,第一分析人员会跟开发团队大部分时间在一起;第二敏捷实践必须从需求分析开始。不然,我们所有的实践都是,得其形骸,不得精要。
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。