[[186936]]

再论需求

在前面几篇文章出去后，遇到不少同学问，到底我的团队是否合适走Scrum模式开发呢?其实我个人的建议首先是看需求管理的主导权是否在团队手里，也就是产品经理是否是紧密和团队在一起，并且有能力拒绝不合时宜的需求，特别是来自领导、市场的压力而来的倒排的需求。但是我们更多遇到的情况是，产品总是游离在团队之外，总是以项目/市场的目的要挟开发一定要在什么时间点做到什么。同时更多的业务型公司的产品对于技术的理解总是不到位，或者说没有任何技术功底，从毕业开始就在做产品的事，所以无法融合到开发团队中。如果是这种情况，是否走Scrum需要商榷。

需求的来源

通常来讲，需求来源于产品经理，但是不要过于局限。从掌控角度看，产品只需要掌握大的产品特性方向以及一个迭代的关键需求要点就可，其它的需求细节应该交由团队成员去发挥，让所有人真正有对产品的归属感。特别是对于开发而言，他们有某些“需求”是心理性的，或者是“癖好”的如代码的重构或者某些细节的雕琢，这些不要一味的否定，而是做适当的控制排下优先级就可。很多时候一个产品的优势往往来源于整个团队的“脑洞大开”，当然也不是随意引入这些需求，适当很重要。不能没有，又不能过度。好像说的有点啰嗦。 ：)

工作量的评估

在Planning game中，重要的一个环节就是对每一个工作项做工作量的评估，理论的做法是使用Planning game纸牌，用斐波那契数列数值(1 1 2 3 5 8 13 …)来给每个工作项做出个人的独立估算，然后一起亮牌，如果差异比较大，则由大数值和小数值的人来说明各自的理由，然后再出牌估算。如此多轮***得出每个工作项的工作量。一般理论的建议是不要将一个做工作项估算超过2天，如果超过则需要继续分解。实践中，这个却是不难么容易操作。原因主要有几个方面：

• 因为对于新产品的理解或新技术等经验不足，对于工作项的分拆比较难，造成工作量估算比较大，***难以操作
• 团队成员的工作经验不足特别是团队成员本身水平不一致的团队，估计离实际偏离很大，***做planning game 费时费力，执行困难。

我们也实践过程也遇到了这些问题，***大家对于planning game的估算环节总是意见颇多，为了后续真的确保能完成，总是人为的往估算中注入水分，从而每个任务都是需要很多时间哪怕再小的任务。综合后一个迭代能做的事情有限。多次恶性循环后，有些管理者自然就认为Scrum模式是开发团队的挡箭牌，从而取消了Scrum的开发模式回归传统填鸭式的倒排项目管理了。

对此，我们团队做了一些调整：

• 首先从工作项的分解交给开发的Team Leader负责，他的经验比较足偏离性小，并在planning game时和大家说明拆解的理由，如果还是不够细则可以继续拆解。
• 不再真对某一项任务进行评估，而是对所有任务做整体评估，只要整体团队认为可以实现这个需求范围就可。同时产品需要掌控每个任务的优先级，便于后期砍需求。
• 还有就是对于技术难点，提前要求开发的Team Leader或者架构师做好PoC (Proof of Concept)，提前踩踩坑。
• 对于实现上的重点问题做些设计，并对团队成员宣讲，让开发和测试都理解。这个不用局限是开发的Team Leader或者架构师，只要做好review就可。具体如何做设计我下面讲。

敏捷中如何做设计

这是个很容易遇到的问题，有些团队做敏捷(无论是否是Scrum)的一个目的就是为了避免去写繁重的设计文档。而有些传统开发的团队，则仍然在做概要设计，然后详细设计，有时有又有UI设计等等。我们的做法呢?Case by case!!!

首先我在前面blog讲过，在Backlog的review的时候，需要多方一起确定是否需要做需求/系统分析(涵盖什么内容，我后面讲)以及架构设计和实现设计(或许和概要设计/详细设计只是换一个名字)

需求分析 / 系统设计

这个主要是针对新feature的情况，目的是分析用户故事场景，分析系统对外接口的变化等，主要包含一下内容但是不局限：

• 原始需求列表，尽可能保留原始的需求描述，以便于读者更好的去理解。但是如果是技术人给的需求，这个就要小心了，通常他们都是根据自己的理解加工过的需求，从而掩盖了需求的本质，而是直接给了你方案性的需求。这些在技术人建的沟通一定要小心这个。
• 需求分析整理。这个是针对原始的需求做出的整理、归类、抽像等。
• 用户故事User Story的描述，或者是use case的描述，取决设计者的偏好。这里面需要定位出Actors，并画出不同场景的序列图
• 领域模型分析， 根据新feature的变化，对领域模型进行修正和描述。如何画好一个清洗的领域模型，这个是个大课题，容以后再表
• 系统的Layer 2的接口分析。Layer 2的意思是系统间的接口，这个是我的老东家Rick同学教的，一直用到现在。
• 系统的Layer 3的模块分析。Layer 3通常指这个系统内的模块组成关系。这个可以由技术产品给，也可以交给架构师做，取决于团队的情况

架构设计/实现设计

这个通常由架构师负责，描述整体系统的架构。这块我就不细讲了。交由江南白衣去讲吧，他整理一个架构设计的要点指南，就看他什么时候出这篇文章了。后面有他的微信公众号。

实现设计

这个针对实现过程的每个要点的详细描述，一般我们是在实现中发现开发中有疑惑的地方，或者实现起来比较别扭的时候，就交由开发Leader来出这个设计，并落到WIKI上。这个可能涵盖的内容有：

• 具体算法
• 具体的参数配置
• 实现的类、接口等关系

总结

不要为了设计而设计，也不要一切都不设计。这个需要产品和开发leader一起把握。切实根据需要来做设计。

【本文是51CTO专栏作者“VIPDOCKER-了哥 ”的原创文章，如需转载请通过51CTO与作者联系】

戳这里，看该作者更多好文