磕磕绊绊的Scrum之行适应现状

Posted 2021-04-25 加兴曰

旧文新发，看到很多行业中的朋友都在问“如何实施Scrum“，新事物在组织中面对不理解、阻力、能力不足，业务又需要正常运转，应该怎么办？重发我们10年前的真实项目记录，也是业界最早的完整Scrum实践的项目之一，供大家参考。

12/16

2010年

星期日

Sunday

我现在手上有一个预期八个月的重构+新功能项目，四个开发人员，UI、测试、QA人力外包。

在项目启动之前的设想是采用敏捷的开发方式，不断地给用户交付系统、分三次增量发布，最后一次发布与计划时间点一致，作为项目完成的标志。在前两周我们进行了Scrum、TDD的基本培训。

实际遇到的问题是：用户希望一次上线，不要新旧系统并行，即使是八个月后才上线，反正让我只用一个系统就行了。

开发上也遇到同样的问题，上司（技术总监）希望团队每个人都参与业务学习，把整个平台全部设计出来，经常在团队走查，提出一些细节性很强、比较分散的技术实现问题。

花费了一个半月的时间在这上面之后，产出了一份《项目需求分析说明书》、《业务可行性分析说明书》，随后进行了系统架构设计，包含物理架构和逻辑子系统，再设计了数据库的分库。随后选择了一个子系统进行开发，与相关用户确定了需求细节。途中上司有发散性需求和设计整个系统的要求，被我分别以在第二个周期实现和逐步细化设计为理由挡了。

磕磕拌拌进入了第一个Sprint。我的计划是整个项目包含三个发布里程碑，内部每个Sprint中包含设计、编码和单元测试，采用持续集成，QA会在每周检查我们的产出，测试在每个测试版本发布后到现场进行功能测试。

每周五会公布下周的工作安排，细化到每天，工作时间安排是面对面沟通。每天我会检查程序员的工作，即时排除问题。

另外遇到的问题是因为团队人员水平参差不齐，两名程序员争执太多，我调整为一名高程进行设计，交付开发，然后三名开发进行编码实现，这名高程转入下一个Sprint的设计工作以及即时走查现有代码。这样的好处是高效，并且统一了设计风格。

JavaEye的ozzzzzz评论道：

我比较关心是否事实上实施了持续集成。

其实上线和发布是两个不同的概念，而发布也有多种不同的发布。而就我的经验猜测，你这种项目最好是做到不论任何时候都有一个可以上线的版本——即使你的这个版本没有完全的功能，但是总是有部分的功能可以实现。

其次业务学习是必要的，但是也是很容易堕落为纯粹扯淡而没有半点实际意义的空谈。关键在于，你们必须得到一个通过计算机的角度描述的业务逻辑模型，而不是成为一个业务专家。

最后我感觉你们做项目有点照本宣科的意思，比如什么需求分析说明了之类，什么scrum之类。关键点在于你们实在的真正知道自己在做什么，用处是什么，效果又是如何。

我强烈的建议，你们应该在3到4个月之内拿出一个类似原型但是要能实际运行的简易程序，以验证客户和你们的理解是否真正合乎实际的需求。

我回复道：

谢谢老大指点。

我们的项目是招投标应用，未来的方向是建筑行业应用（公司方向）。

我们的项目是招投标应用，未来的方向是建筑行业应用（公司方向）。

我来了之后理顺了一个业务方向是围绕工程项目管理展开，第一个推行的是业务流程管理的概念，此前，公司的业务部门是没有项目这个整体概念的。未来的商业模式是Saas.

技术上，内部应用未来的规划是SOA，按业务领域切割，外部应用这个要明年动工，加上我对网站方面的经验比较少，暂时还没有成型的技术方案。

持续集成这是一定要做的，我自己也有半年的实践经验。在这个项目我们使用的是.NET Framework 4.0开发框架，TFS 2010作为团队管理工具。我发现TFS的Scrum模板只是个半成品，非常难用，相关的SharePoint集成之类的，问题也不少。现正准备在第三个Sprint开始使用Mingle。

我把项目按照自然月拆成了7个Sprint，分别在3次Release里，实际上这个Release只是发布到测试环境中，所以团队之外宣称为里程碑。在每个Sprint之前我都会把原型交给用户进行确认，因为UI是外包的，这个进展比较慢，好在主框架和风格确认之后，细节和易用性可以我自己来设计了。

ozzzzzz又回复道：

关于工具其实应该尽量用普通的，比如白板，玻璃墙之类。实在要用信息系统，那就自己造一个好了。其实不复杂，而且可以通过建造一个这样的系统促进大家对管理流程的理解。特别是你们用sharepoint，这个应该是更加简单。

其实关于业务方向，我觉得你最好不要多参与，领导做战略部署就好了，你没这个能力（不是自己的素质，而是你不掌握全局，所以不可能有能力看清很多问题），也没有这个权利搞这个。具体将来是SaaS还是其他什么，随着项目的进展，自然会清楚。

技术上来说，先解决目前第一期上线吧，其他以后再说。说实在的项目周期8个月仅仅是计划，我看搞不好会一年。而又没有跟现有项目结合，所以风险很大的。对你这个新人来说，现在是不求胜利，但求能平安就好。而一旦第一期通过了，第二期其实也是比较恶心人的。要等做到三期以后，一切才会顺起来。这点是我长期经验之谈，可能你会走运，没这么背时。

另一位坛友jiangduxi回复道：

这个才是正 道！千万不要生搬硬套。你的领导和用户想法就是你必须将整个原型做成出来。你可以将这个原型进行划分到开发中去！

srdrm回复道：

经验很多，说一个大家都没有提到的，确定好客户方的一个需求对接人，一个对业务熟悉的人，同时要要求他的工作时间必须腾出一部分来做这方面的工作。这个人需要有一定的决策权。比如你们约好每两周作一次功能反馈及确认，以及时给客户反馈，同时听取客户的意见。

这个接口人非常重要。要不你们项目可能会有问题，如果是一个全新的项目的话。如果是重构的项目，可能需要考虑得更多，客户方希望要增强到什么程度，对现有系统哪里不满意，这些都是必须重视的。

再支一招吧，

8个月的时间，做计划是不能按 8 个月做的。

依据不同团队成员，客户，项目的情况，应该做成 6, 7 个月的。