唯品会敏捷Scrum实践历程总结(四)

发布时间：2025-11-05 07:30:28 来源：创站工坊 作者：IT科技

再论需求

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

需求的来源

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

工作量的评估

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

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

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

敏捷中如何做设计

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

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

需求分析 / 系统设计

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

架构设计/实现设计

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

实现设计

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

总结

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

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

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

相关文章