磕磕绊绊的Scrum之行(一)适应现状

我现在手上有一个预期八个月的重构+新功能项目,四个开发人员,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 个月的。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero