特性团队

今天参加公司半年的有效性评估，在AMM评估的时候，一开始给评委讲解特性的环节，就把评委给讲晕了。其实评委想要看到的举证很简单，无外乎就两点∶

• 不管是项目，还是团队，都需要关注特性的端到端交付，之所以强调特性团队，就是为了强调一个特性是可以由一个团队完整对外交付的，这和一般的组件式团队完全不同。举个例子:做前端的在一个团队，做后端的在一个团队，测试在第三个团队。一个特性从进来以后，需要三个团队间协同去开发，测试才能完整对外交付，且不说因为协同配合一致的节奏，这期间的沟通成本有多高，更关键的，这样的组件式团队在运作过程中，极其难以保证一个特性在一个迭代内就能快速的对外交付，因为有依赖，就会涉及不同团队优先级排序，再从前后端团队开发完成后，再传递到测试团队的测试。这里面涉及了两个层面的沟通协作:业务层面和职责层面。为了保证一个特性能完整，快速，高质量的在迭代内交付，特性团队就需要从业务和职责领域来考虑这个事情。团队的划分强调:按领域做纵向切分，而不是横向切分，团队能做的事情是端到端可交付的。其次，职责上，从需求分析，方案研讨，开发，测试都在一个团队内完成，保证沟通协作的高效运转。如此，才是一个特性团队。
• 特性能够有预测的加入迭代，且能尽快测试，尽快发布。孙教举了一个例子，非常好。特性就好比桌子上，一个一个的盒子，我们期望的不是把盒子一个一个都打开，然后一个一个装完东西，再挨着一个一个检查东西是否装对，最后再将这些盒子封闭好交给别人。而是，打开一个盒子，装上东西，检查东西对了没，然后将盒子封闭好，交给别人。并快速从对方得到反馈，比如，盒子里的东西多了？少了？有没有缺什么？这些有效反馈信息对后面的盒子装东西交付环节产生很有意义的反馈。如此，即是更好的。

再说回来，目前项目做得可改进的一个地方在于，迭代过程中，我们过度的强调用户故事，只把特性作为PO、SE和BA间传递需求的一个载体，团队层面，以及项目对迭代交付物都强调用户故事。只有在R版本中去关注特性。这样做有一个问题，我们对用户交付的产物应该是特性，而迭代过程中不强调特性，只在R版本快结束时，再来关注特性，是一个不太好的导向。更为妥当的做法应该是，更加强化特性的概念，迭代过程中重视特性的验证和交付，引导团队重视对用户交付的承诺。而用户故事本身只是团队层面一个用于迭代协作的需求载体。
我们对于这些载体的运用，会对整个组织的运作产生一个长远的导向性运用。想要团队更加重视迭代交付，这样的导向很重要。它明确指引着团队，每个迭代对外提供的都是潜在可交付的增量。这样的做法，也更加契合特性团队的定义。

图片发自App