敏捷开始的前提--团队配置和工作方式

“搞敏捷，你我要有个约定，请不要忽悠我”

我们的最终目标是要从需求分析开始进行敏捷实践，因为需求分析才是敏捷的开始。

我害怕我们一直坚持在做的，那些正确的实践，到最后都变成没有错误的无价值品，那么敏捷的精神在哪里，真正的价值驱动体现在哪里？
各种看板、Story拆分、任务划分、验收条件等等这些应该成为价值验证的有力工具，被我们当作验证设计文档里面的文字转化成可用的代码，但对于它是不是被需要，我们并不关注。

那些隐藏在200页设计说明书里面的需求，那些淹没在文字里的细节和那些没能够达成共识的设计，因为这个复杂的文档，和它之前那长达数个月内经历的多次评审，变得理所当然的准确无误。当认为有时开发团队的人太固执于实现细节的时候，你其实并没有太多硬性的责任让需求转化为可用的软件，你更多的时候，只是尽义务地等待那些刚进入团队不久的新人，羞涩地向你提出本该你主动解释清楚的问题，而你的工作，应该在那部巨大需求设计文档的最后一个句号后基本完毕。

让开发团队与"需求团队"紧密合作：把"模块设计师"尽量推向客户，让需求收集、分析和设计在一个团队完成，并使这个团队和开发团队紧密合作。

如果一个80个人的团队，只有一个分析人员进行需求的澄清，绝大部分依靠文档传递需求信息，寄希望于开发团队能够根据文档实现需求真正的功能，需求失真后又必须等待到上线时才能发现，若管理一个天才团队，我尚未有足够信心，对一般水平的开发团队而言，真的不是拆分Story，每日晨会，故事墙能够解决的问题。

 

当我被问道：“请问如何拆分Story才是正确的？”，但上下文是分析人员基本不在团队内，需要由开发人员尝试理解文档并写用户故事，这样的问题，我确实无法回答，因为我怎样的回答，放在这个上下文里，都是没有实际意义的。

 

敏捷是一个太容易被误解成工具集合的概念，认为它是一套方法论指导下的工具集合，使用其中某一部分的工具便能达到预期的效果，但是实际上，敏捷中的所有实践都是这个方法论体系中不可缺少的东西。我明白，学习敏捷需要阶段，但第一课应该学到的是，如果开始敏捷，请答应我在不远的未来实现两件事，第一分析人员会跟开发团队大部分时间在一起；第二敏捷实践必须从需求分析开始。不然，我们所有的实践都是，得其形骸，不得精要。