重新讨论需求前几篇文章发表后，很多同学问我，我的团队适不适合做Scrum开发？其实我个人的建议是，首先要看需求管理的主导权是否掌握在团队手中，即产品经理是否与团队关系密切，是否有能力拒绝不合时宜的需求，尤其是反向需求领导力和市场压力。但我们经常遇到的是，产品总是游离于团队，总是以项目/市场的目的来威胁开发什么时间点必须做什么。同时，更多面向业务的公司的产品，总是对技术没有很好的理解，或者没有任何技术技能。毕业后一直在做产品，不能融入开发团队。如果是这样的话，是否走Scrum就需要商量了。需求来源一般来说，需求来自于产品经理，但不要太局限。从管控的角度，产品只需要掌握产品的大体特性方向和一次迭代的关键需求，其他需求的细节交给团队成员，让每个人真正有感属于产品。尤其是对于开发，他们有一定的心理“需求”或者“喜好”，比如代码重构或者某些细节的打磨。不要一味地否定这些，而是??要做好适当的控制安排。只是降低优先级。很多时候，一款产品的优势往往来自于整个团队的“脑洞大开”。当然，这些要求并不是随便引入的，适度很重要。不是没有它，但也不是太多。好像有点啰嗦了。:)工作量评估在Planning游戏中，一个重要的环节就是评估每个工作项的工作量。理论上的做法是使用Planning游戏卡，使用斐波那契数列值（11235813…）对每个工作项进行单独的独立估算，然后一起出示卡牌。如果相差比较大，数值大的人和数值小的人分别说明各自的原因，然后再估牌。这么多轮***就得出了每个工作项的工作量。一般的理论建议是预估一个工作项不要超过2天，超过了就需要继续分解。实际上，这并没有那么难操作。原因有几个：由于对新产品或新技术的理解经验不足，难以拆分工作项，导致工作量预估比较大，工作经验不足的团队成员，尤其是团队成员难以操作成员不在同一级别的团队可能会与实际情况有很大的偏差，从而使计划游戏耗时且难以执行。我们在实践过程中也遇到了这些问题。***对于策划游戏的估算环节，大家总是有很多意见。为了保证以后能够完成，我们总是人为地给预估注水，这样每一个任务，即使是很小的任务，也要花费大量的时间。综合后的迭代可以做什么是有限制的。多次恶性循环后，部分管理者自然而然地认为Scrum模式是开发团队的挡箭牌，从而取消Scrum开发模式，回归传统的填鸭式倒项目管理。对此，我们团队做了一些调整：首先，工作项分解交给了开发TeamLeader。他的经验比较充足，偏差很小。他会在策划游戏的时候给大家解释拆机的原因。如果还不够详细，Disassembly可以继续。不再真的是对某一个任务的评价，而是对所有任务的整体评价，只要整体团队认为需求的范围可以达到即可。同时，产品需要控制每个任务的优先级，以便后期切入。另外对于技术上的难点，需要开发的组长或者架构师提前做一个PoC（ProofofConcept），提前踩坑。在实现的关键问题上做一些设计，给团队成员布道，让开发和测试都能理解。这个不需要局限于开发的TeamLeader或者架构师，只要review做了就可以了。具体怎么做设计，下面会讲到。如何在敏捷中进行设计是一个很容易遇到的问题。一些团队做敏捷（不管是不是Scrum）的目的之一就是避免编写繁重的设计文档。一些传统的开发团队还在做概要设计，然后是详细设计，有时还会做UI设计等等。我们的方法呢？个案一个案！！！首先，我在之前的博客中说过，在reviewtheBacklog的时候，需要多方来判断是否需要做需求/系统分析（涵盖什么，后面再说）和架构设计和实现设计（可能只是改名从概要设计/详细设计）需求分析/系统设计这主要针对新特性的情况，目的是分析用户故事场景，分析系统对外接口的变化，etc.主要包括以下内容但不局限：原需求列表，尽量保持原需求描述，以便读者更好的理解。但是如果是技术人员的需求，就得小心了。通常他们是根据自己的理解来处理需求，从而掩盖了需求的本质，而是直接给你一个程序化的需求。您必须小心这些由技术人员建立的通信。需求分析与安排。这是为了原始需求而做的整理、分类、抽象等。用户故事的描述UserStory，或者用例的描述，取决于设计者的喜好。需要定位Actor，绘制不同场景的时序图。领域模型分析。根据新特性的变化，对领域模型进行修订和描述。如何画出干净的领域模型是一个很大的话题，后面会展示系统的二层接口分析。第2层表示系统之间的接口。这是我的老老板里克教的，一直沿用至今。系统第3层模块分析。Layer3通常是指系统内部模块的组成关系。这个可以由技术产品给，也可以交给架构师，看团队的情况。架构设计/实现设计这通常是架构师的责任，描述整个系统的架构。这个我就不细说了。让江南白衣来说说吧。他整理了一篇关于架构设计要点的指南，就看他什么时候发表这篇文章了。后面有他的微信公众号。实现设计是对实现过程中每个关键点的详细描述。一般我们在实施过程中发现开发有疑点，或者实施起来很别扭的时候，我们会把设计交给开发组长，再交给WIKI上级。这可能包括以下内容：具体算法具体参数配置实现的类、接口等之间关系的总结不要为了设计而设计，也不要什么都设计。这需要产品和开发负责人共同把握。根据需要设计。【本文为专栏作者“VIPDOCKER-Leoge”原创文章，如需转载请通过联系作者】点击此处查看该作者更多好文
