国内项目的Scrum实践---前期准备:了解项目情况,介绍Scrum,提出一些解决方案,搜集对Scr

2009-03-02
今天是我第一天上班，出于对公司负责，公司的业务和组织结构这里不详细描述。我计划每天更新博客，以纪录我作为ScrumMaster如何在一家软件公司开始我的工作，以及遇到的各种问题，如何解决。
公司的简单状况：
外资
我所在的项目组有8人，做电信相关的项目，客户是中国移动运营商
第一天上班的工作：
人力资源办手续
部门总监简单介绍项目的总体情况（业务层面），由于要开会，中间没有讲完
晚上部门所有人员加班
问题：
1. 对新员工没有业务和总体架构的介绍文档


2009-3-3
今天是我第二天上班，了解业务需要和技术架构

2009-3-4
今天，领导向项目介绍了我这个新成员－：）
今天了解了一些问题：
1. 项目成员的协作不够，一个功能只是一个人在做（弊端：他精通后台，但页面开发比较花时间，而且没有人讨论，同时这样项目风险高（人员流动）。
2. 整个项目没有明确计划,scope,user story给所有成员share
3. 没有专职的QA，整体业务只是集中在项目经理（总监）少数人，项目提交前没有足够的人力完整的测试
4. 功能完成（done）的标准不明确
5. 客户没有明确需求，需要乙方设计；或者原始需求过于简单，细节需要不断完善：需求从业务部门获得，但细节由研发部门补充（例如业务部门提出要有发短信功能，但仅是这三个字而已）
6. 产品发布、更新流程不明确，没有delicated role 负责delopy，reboot
7. 产品权限不明确，任何人都可以无限制使用产品，至少应该有Demo、测试等权限
8. 没有代码统一规范和代码评阅，导致代码质量不高
9. 页面的跳转不流畅，有些页面必须在brower的“Back”支持下才能到前一个页面，缺少统一的导航
对于这些问题的一些想法：
1. 了解资源：项目组内部，外部关联资源
2. 介绍Scrum给团队（为什么用Scrum）
a. 前期需求不细化，需要分步开发
b. 把优先级最高的最先开发，同时用working system来避免各种风险（大数据量，稳定性，测试人员不足）
c. 人员遵从cross-functional
d. 明确的PO 或者 customer，Team和PO 一起完成spring planning，做功能和质量权衡的产品（以Business Value为标准：用户用到的，看到的，仅做必须的，先做有相似特征的一个，避免浪费Effort和返工）
3. 以Scrumworks为工具管理项目，要求每一个user story必须填写所有信息项，以部分解决#2，#3，#4；每一个US，原则上两人以上共同完成，以部分解决问题#1；Sprint开发，以解决问题#5；
4. task evaluation，以完成该任务的小组意见为重
5. 压力、稳定性测试对于电信级系统是必须的

2009-3-6
今天给所有研发部的同事们简单介绍了Scrum，看看大家的反馈，反馈如下：
1. 对敏捷开发的细节了解不多，不清楚和传统开发的具体区别，而大家在传统开发的经验和心得都很多，所以对敏捷开发不置可否，需要更多的沟通
2. 对按照优先级开发比较认可，而且和PO确认后再开发比较认可，认为可以避免很多返工和扯皮
3. Daily meeting，如果超过20分钟，大家认为没有效率，而且比较烦人。同时部分人建议不要每天都开，2~3天开一次最好


2009－3-9
由于还没有正式接手项目，所以只是部分垂直管理某几个功能（需求到验收）。
现象：
1. 整个部门没有专职的QA team，验收测试环节只是靠开发人员和PO或者SM进行测试
2. Bug管理使用Bugzilla，但没有正是系统测试需要的需求->测试用例->bug->Fix一个整套的测试管理，无法给予电信级系统质量充分的信心
3. 目前没有成型的设计文档
解决思路：
1. 认为项目组中还是应该有1~2个比较偏向于QA的成员，Acceptance Test可以是“done"的开发完成标准，但仍然需要比较专职的QA进行整合测试，特别是进入产品服务器之前（每个Sprint和最后的Release阶段）。已经向公司提交了人员申请,在部门级别上增加QATeam，分配1~2人进入我们项目组。
2. 由于使用的Scrumworks Basic版本，无法和Jira整合，所以考虑用TD来作为测试管理工具。TD纪录详细的需求，测试用例，Bug管理，Scrumworks侧重于项目级管理，包括Product Backlog，Sprint backlog， sprint plan， Burndown chart等。Acceptance Test作为开发人员完成功能的标志，来自QA的报告作为"done"中可以发布的标准。
3. 关于设计，我的思路是借鉴Agile Modeling的做法。用最直接的类图、时序图即可，必要的文字说明，白板拍照即可，有时间的话用Rose/Visio画图
4. 关于需求，简单的User Story可能还不能纪录足够的信息，画一个流程图作为补充，包括正常流程和异常流程，加上Acceptance test，研发人员认为OK。其实流程图和Acceptance Test有重叠的地方，但研发人员对于流程图易于接受，Acceptance Test对于PO等比较简单，所以暂时两者并用。

感谢“smlweb”的提醒，逐步推进Scrum的实施是明智的。目前我正在和公司的总监比较详细的介绍Scrum和我的思路，总监表示可以考虑实施。最开始大家都可以接受的是用Scrum的思路和目前的开发模式相结合。同时Scrum也需要公司层面其他部门的配合，一点一点来吧。目前首先的是和公司和项目组成员沟通Scrum的实施思路，以获得最大的支持。然后才是具体的实施。

2009-3-10
今天和大家沟通Scrum，有一些共识：
1. working system对于需求的最终确认有很大帮助。首先，需求的提出者（外部客户或者内部客户）对于需求文档，原型会去看，但没有紧迫感，这到底还没有出现在产品服务器上。而每一个sprint交付的system，原则上是可以部署到产品服务器上的，是直接面对客户的，Demo阶段客户会非常认真的评审，可能的意见都会及时提出，需求变化和扯皮的风险会小得多。
2. 国内的客户，特别是移动运营商，比较难可以和开发小组每日沟通-:)。所以在需求管理上，需要更多的文档来纪录。
3. Scrum不是灵药（silver bullet），没有一种方法可以不依赖其他同样优秀的开发方法来提高生产力（productivity）。我们要做的是：发现各种开发方法的优势，调整，组合来适应我们具体的组织环境，客户环境，开发环境。。。就目前部门最大的问题是：需求经常变化，所以以Scrum为开发管理框架，结合其他的模式。

正式接手项目后，从项目的第二期，开始实施Scrum。这个时间需要看项目第一期的收尾状况。:)

2009-3-11
按计划还有8个工作日就要发布版本，供试点使用。我用Scrumworks开始管理下面8个工作日的开发情况，看看各方反映如何：
1. sprint内的工作是这个团队的任务，大家都需要负责，在sprint开始的时候大家一起和PO讨论需求，内部讨论设计和task，可以和整个团队对项目有一个overview。资源协调也比较容易。在实际开发过程中还是要落实到人，效率比较高，但某个需求的变化和具体实现只是在完成这个需求的负责人、PO、SM之间讨论，渐渐变化的情况只有这些人了解，其他人没有得到共享。这个我们讨论用每周例会（30～45分钟）中对本周任务回顾时进行解决，目的是让每个人对需求的最新状态，设计的最新变化有共识。
2. 今天开始用Scrumworks来工作。这个工具让PO，总监，总经理，team成员都可以了解项目的进展。目前PO反映沟通很好，好处在于：可以纪录需求，分析优先级，stakeholders（PO、总监等）都很清晰剩下8个工作日我们还需要完成哪些功能，同时不再增加新的功能，或者将新功能放在后一个版本。Scrumworks提供的这个平台提高了沟通效率，业务和开发部门易于互相理解。有一个问题，Sprint planning利用task board虽然突出了优先级，直观，但对于大家熟悉的依赖关系，里程碑等概念支持不足，需要适应。

Andy Yuan
Msn: [e-mail]
Mobile: [phone]