磕磕拌拌的Scrum之行

甲方项目比乙方项目有优势的地方是控制权更大，什么业务部门，直接摆平，因为我的职位是研发经理而不是项目经理。

项目麻烦的地方就是不是一个简单的软件项目，很多外面的事情要去操心，公司制度、外包管理、人事招聘神马的，你在社会上关系越多资源越多，搞起来就越顺手。

因为这个帖子只是写Scrum的实践，其它的就不涉及了。

（三）承上启下

今天举行了Sprint 1回顾会议，包含以下几个主题：
1.整个团队的过程回顾，几个关键点的决策，为何要如此决策（我主讲）
2.演示现有产出中的关键代码和设计（我主讲）
3.下期工作预告
4.代码评审结果分析（评审人员主讲）
5.轮流个人总结：遇到问题、改进措施、上级建议（我当面反馈）
6.我的个人总结

团队成员的个人总结基本上是日常中的反馈，改进多为“学习”型。高级人员反映沟通不足。本期我的工作总结是对业务、技术的驾驭还够，产出还不够有说服力。

接下来是一个为期7天的Sprint，做一些基础性的工作，编写框架，熟悉调用。团队分为两个小组，我带一中程做框架编写，两高程做业务系统，另一初程主攻单元测试，这样让大家更专注，更容易成为高手。

本周也搞掂了UI的外包采购，QA服务正在进行中，衡量了外包测试的价格后，我们决定招一名初级测试人员，工作为Web功能测试，预计下周搞定。

哎，要是我做楼主的下手，估计就惨了，这么多条条框框的真让人郁闷。真是什么样的架构师，带什么样的人。

（四）管理业务技术一手抓

到此我已经为这个项目工作了三个月。第一个月团队组建、软硬件搭建，第二个月项目启动，部门沟通，需求调研，第三个月进入Sprint 1，与外部咨询公司、外包接洽。

现在与开始时最大的不同是整个公司在渐渐“接受”我带来的东西：

第一、业务再造。我和CTO一起将整个业务梳理了一篇，砍掉多余部分，设计流程，与业务部门沟通员工职能的定位。引入了Case的概念，将整个业务活动全部管理监控起来。本周原型设计框架评审通过，工作再进一大步。

第二、推行敏捷。从最初的不理解、冲突，到现在CTO和其它部门成员一起钻研敏捷^_^CTO在渐渐地接受在前期不会有“系统架构设计”这个说法。

第三、团队内部的分工，以便于技术的深入。每日例会、周会抓起来，主动培训和跟进成员的工作。

当前做得还比较弱的地方就是产出了。

（五）人的管理

补上一节说说过程中遇到的一系列问题和我的解决方式。

技术实现，就是“用什么技术，怎么来用”的问题，这玩意跟你爱看什么电影听什么歌一样，各人有各人的喜好。工作六、七年以上的程序员，实现技术基本上被固化了下来，会习惯于“以前就是这样做的”的思维方式；当你遇到一个很少使用框架、工作经验又丰富的程序员，他首先会很排斥框架，回答千篇一律的“框架不灵活”；另一些经验丰富的程序员有自己的一套编码风格和习惯；新手中的新手不是不知道如何下手，而是不知道如何学习；另一些新手是学了一小半，就忘了自己还有一大半没掌握。

解决方式吧，我比较暴力直接^_^

因为有项目架构师和框架开发人员近四年的工作经验（海量失败经验），在技术这块，我是有问必决的——直接写代码、讲明白，再与成员确认先了解、再结论——看问题尽可能客观。对方反馈是使用框架后确实很强大。

编码习惯问题，其实改起来确实不容易。首先对方花了很多时间与我争论，自称“太影响效率了”，于是一部分工作改由另一人执行，最后把结果拿整个团队一比对，该人工作项全部返工，了事。另一些不合规范的在代码审查中查出，安排专人修改。

半桶水问题，安排给有难度的任务，不懂的地方手把手教，辅以小故事，言传身教，倒不是为谁洗脑，要达到什么样的水平，取决于什么样的态度，要做什么样的成绩，取决于什么样的能力。否则，团队就被拖后腿了不是？

至于新手中的新手，真的只有手把手教，再出考卷考试成绩了。安排给他的角色是敏捷团队中的单元测试编写者，在持续集成中，渐渐地让他把BUG分析工作做起来。

昨天与业务部门主管的会议中遇到一个搞笑的事，某主管报怨下属能力差，什么都不会做，被上司评管理有问题，于是群策为其找解决方案：

报怨主管：他什么都不会做。
总监A：不会做就请示主管啊！
主管A：主管之所以成为主管，就是比下面的人更强才成为了主管。
总监B：……怎么这样说哦？
总监A：&*（&*你这种说法是错误的，怎么能上升到这种&*（*（居然忘了原话了）层次来？
报怨主管：每次给他说了，每次他还是不会，最后还是我做。
总监A：你要给他一个机会啊！
总监B：要适当地放权，要不然你就太累了……
我：作为上级，培训和指导下属是工作的一部分。

把敏捷搞得这样不轻松,是不是有些用力过度.
一方面按照架构自然形成的思路进行工程实践,另一方面一开始就对数据库进行整体设计,有些不理解.

是针对子系统的数据库进行整体设计，因为整个项目是大型重构，架构是全新的，数据库只是结构上的较小调整和命名规范的约束。

没有大型重构的说法，如果一定要全面对软件架构进行重构，关键是建立大量的测试用例，第一个sprint应该是建立测试用例->重构编码，而不是一开始就添加什么新功能。

大型是指项目是大型项目，这个是根据投入的人月来评定的。
以前的系统基本上没什么架构，从一般的外包项目不同的是我们是甲方，业务再造权也掌握在我们的手上，更多是从业务入手去重做，所以，针对系统本身不太有很多东西可挖掘。但由于团队是新组建的，所以对旧系统、业务都应该有一个熟悉的过程。

在下一篇我会更详细地叙述，放在周末来提交。