磕磕拌拌的Scrum之行

改造旧的系统有三种做法:
1、重构旧代码，添加新功能
2、添加新功能，重构新代码
3、一边添加新功能，一边重构
我不清楚你们怎么做，我的倾向是先重构旧代码后，有足够的测试用例后再添加新功能，关键是二项工作必须分开来做

呵呵，你是站在程序员的角度上看问题了。

（六）走上敏捷之路

很高兴地通知大家，经过三个月的努力，一个完完整整的Scrum，包括它的管理思想、组织策略、沟通方式甚至对传统过程颠覆的部分，都已经被整个公司所接受，CTO已经了解并掌握了整个Scrum的各项定义和组织细节并会根据所掌握的项对我们的工作进行评估，运维安全部门的同事也积极地学习敏捷的相关知识，参与到我们的会议讨论中来，整个Scrum团队正式成形，真是事在人为呀！

前文已经说过，Sprint 2我们的主要目标是清扫技术障碍：
1.建立团队分工；
2.完善团队成员技术成熟度；
3.可度量的技术积累。

Sprint 2的周期是11.11~11.19，今天顺利完成并举行了回顾会议，本次我的经验是：
1.对于每个Sprint，我未做出明确的提交审核的时间，以至于周中要求大家在周四中午提交产出时，大家有些惊讶；
2.手上事情太多，如Sprint的各项任何分解在开会、口头确认后，还不能及时更新到项目管理工具中去（我们采用的是TFS 2010），所以每天的任务状态跟踪做得不够细，在接下来时间异常紧张的情况下，这个必须控制起来；
3.燃尽的概念还未在团队中推广起来。

此前团队的整体情况是没有敏捷经验，对流行的一些开发思想了解不多。但团队中有一名很让人放心的高级成员，总是超出预期地完成工作，我的安排是，让他有更多的机会参与到高层设计中来，如领域驱动设计的开发方法中，让他参与到业务分析中来，进行业务建模，更深入地理解领域知识和领域语言。

在本次Sprint回顾会议中，尽量让大家秀亮点和改善方法，否则，好好的回顾会议就变成批斗会了，这对团队无益。随后讲解了从Sprint 1开始我们设计思路的变化，我们是演进式架构设计，这点得到了上层的认可。

另外讲解了已完成的原型部分，由于原型的开发比较紧张，我决定将团队中可塑性最强的新手锻炼成为从产品角度上独挡一面的成员，他会参与到我的原型设计中来。

在下一期，我们会从上到下，从头到尾真正地进行敏捷开发。

（七）我们具体是怎么做的

简单地说，就是整个完整交付品远超开发团队交付能力的情况下（我相信大多数时候都是这样的），如何去尽可能准时交付并且保障交付品的功能满足及良好的设计，还有质量的保证。

对传统的开发过程，项目中往往会有权衡之事发生，最常见的就是，管他三七二十一，我们把功能实现了就行了，先不管架构、质量，整一个可以跑的东西出来，整上线再慢慢来修修补补。这种情况导致的最恶劣的后果就是质量问题导致不断延期，架构的不合理导致整套系统的生命周期很短。

对一个成熟的敏捷团队的开发过程，如采用Scrum的模式是，我们会在第一时间编写产品积压事项（Product Backlog）来代替传统的需求用例，然后根据Backlog的优先级、依赖顺序进行分组，划一个时间周期为一个Sprint，将一组Backlog加入到这个Sprint中形成Sprint Backlog，指定Backlog负责人、开发人员，开评估会议，定义每个Backlog如何分解成8小时一份的Task来进行完成。每天的状态会更新在看板上，遇到的问题被标记为阻碍Backlog，一个Sprint的目标，就是消灭所有的Product Backlog和阻碍Backlog.

再说一下架构设计方面。在这个开发过程中，没有架构设计的概念。是因为：
1.我们默认我们无法提出良好的架构——通常这样的系统由很多子系统组成，在Project Architecture这一级设计上，我们仅仅提出“我们将采用分布式架构设计，子系统各自的数据库不允许外部子系统直接访问”这样一个概念，除此之外，定义采用何种平台、何种语言、开发环境、发布环境和数据库类型等等，物理架构基本上可以定义，逻辑架构出一个轮廓。无文档产出，无签字确认。
2.在Application Architecture这一级别，我们会定义采用什么样的设计方法，如我们现在的一个业务系统，我们采用领域驱动设计的方法进行设计和开发。在这个过程中，我们发现以前对分布式架构的“如何分布式”的认知有一些偏差，于是，我们在这里将“如何分布式”定义得更准确了，我们将基于业务重用度而不是“隔离应用操作”来定义分布式架构，从另一个角度上来说，我们把整个构架从物理部署上演进到了逻辑应用上，但之所以可以改变的原因是我们是增量交付，架构部分没有文档需要修改，也没有具体的项目解决方案需要重写。
3.持续重构。在我们这个项目中由于时间比较紧，每次我们只会做最关键的重构，而把更新的设计思路体现在下一个Sprint中，这样，至少大部分的结构是优秀的，不断改善的。

我觉得你有点大方法论倾向。
当你面面俱到地，按步就班地实施一个方法论时，并让自己感觉已经掌控全局时，其实敏捷已经死亡。
我认为的敏捷可能就是某几个关键能调动具体人员积极性和激活创意的实践，白板，卡片，信息墙等让人兴奋的手段，而不是一大堆漂亮，整洁的文档和规范。把sprint做得完美，让老板高兴的图表，架构驱动的开发，我认为都和敏捷背道而驰，华而不实的东西。敏捷所需要的是无处不在的测试，适应变化的重构以及真正协作的团队。

事情具体怎么做，是根据具体的情况，因为背景和资源都掌握在我的手上，所以，我是决策者。这个贴子只记录项目的真实过程，对于各位朋友的建议，我觉得可行会采纳，其它一笑置之。

（八）Sprint 3开始

11月22日团队调整了一天，11月23举行了Sprint 3计划会议一，在会议中提出了以下计划：
1.定义冲刺周期：11.23~12.31
2.提出本次冲刺的目标：a.完成系统A alpha 版本发布，b.完成系统B alpha 版本发布；
3.人日投入计划；
4.简述两个系统的功能；
5.定义各个里程碑时间点。

11月25日开始Sprint 3计划会议二，对Sprint Backlog进行评估，Backlog由我提出，向一名团队成员讲解后一起填入。评估一共有四轮：

第一轮对Backlog进行删减，移除不需要的Backlog，决策者是技术总监，此次删减了3个，原因是涉及到关键利益，业务上要制造流程复杂性，故不实现信息化；

第二轮是进行指标度量，度量的指标有业务价值、需求不确定性、复杂度、风险、工作量。开始时，一名团队成员表示不理解什么叫“业务价值”，以及业务价值是应该站在开发的角度上进行衡量还是业务部门的角度上进行衡量。我和技术总监的回答是：按你的理解来评估。因为我们的目标是一步一步让开发团队向产品团队转变，这就需要开发人员能够从商业上理解自己做的程序功能。这轮的结果是大家整体上还是有共识。（下次的话，我准备不公开评估）

第三轮是任务分解和工时评估，将所有待做的任务定义出来。这轮遇到了不少的阻力，开发人员提出任务分解应由项目经理定义好后他们可以主动领取，我的理解是他们现在还不知如何着手定义任务。于是我在会议上开始单独定义任务。技术总监认为毕竟大家是每一次这样搞，有个适应期，可以继续试着让他们定义。最后的结果是我定义了绝大部分任务，剩下的由团队提出。此轮评估的结果是针对系统A的预估工时已经用完了Sprint 3的全部时间，于是大家一起讨论，最后与每位成员确认Sprint 3我们的新目标是仅交付系统A的alpha版本。在此轮中，有两项任务大家都无法预估时间，于是被标为“阻塞”，并在确定具体方案之前，不排入计划之中。另一个评估时间很长（70~84小时）的任务被分解成一组小任务再进行预估，经分解的最小估算是45小时。

第四轮是任务优先级安排和任务领取，比较顺利，也因此确定了下周的工作计划。

最后会议收尾，调整了一下计划会议一中定义的里程碑时间。

一个团队的效率取决于这些技巧：
1.在没有依赖关系的情况下，先做简单、费时少的任务；
2.衡量一个任务是否进入开发计划，请用SMART原则进行检查。

此外团队也有一些调整，在Sprint 3开始之前我手中的工作依然堆积得非常多，业务沟通、原型设计、功能说明、管理，都要抓起来。因此我开始安排组里的新手开始跟着我学习User Story的编写和原型的绘制，以分担一些任务，他在渐渐地上手并会负责整个界面开发。

一个团队的成长在于，有经验的人为后来者照亮道路，但绝不是铺平道路。

（九）产品计划的前瞻性思考

随着项目的深入，我与公司高层也开始计划着未来的远景，现在我们已经定义好市场和竞争对手，开始设想如何推广或是如何创造出行业产品。

在Sprint 3计划会议二上我们有一次激烈的争执，关于如何向平台引入新的角色用户：



这个会议开了整整一天半，第二天我有了好的想法：



随后，我开始计划在项目结束后开始新产品计划。

就在今天早晨我第一下睁开眼，两个字进入了我的头脑：这就是未来产品的名字。接下来的首要任务，依然是为当前项目保驾护航的同时，开始分化团队职能：

1.培养技术解决方案专才小组。当前我们有许多技术问题，如架构模式，文件存储，多平台等，都需要有一个专业投入钻研的小组进行解决。在文件存储的问题上，来自豆瓣的同事给了我很多指点：



2.培养产品设计专才小组。主要职能包含行业研究、原型设计、可行性评估等。

一步一步地走吧。

由于JavaEye非常不稳定，我已经把这个系列的所有帖子备份到个人博客，可能以后慢慢地也仅会在个人博客上进行更新。有感兴趣的朋友，欢迎来我的博客浏览评论。

博客地址：http://www.justinablog.com

几位有价值的发言我也署名拷贝过去了。