实践时长

到目前已接近3个月

团队规模

18人，工作半年至一年成员占多数

项目类型

面向视障人群的系统和软件研发

实施背景

一家创业公司，技术部成立之初，搭建了redmine+git/svn+jenkins的一体化项目管理、持续集成跟踪环境，然后大家就这么开始干了。历经半年摸爬滚打，最终做出一套系统，用户体验上众说纷纭。最终老大拍板：既然硬件合作方实力不济，我们改到通用设备！这一改，问题就来了：从按键设备改到触摸设备，除了后端数据服务和接口不变外，终端交互及实现都得大改，同时新的理念不断提出，需求、争执不断。上层观念不一致，下面更是动荡不安，一批批辞职申请，讨论不出头绪的会议，头大。

scrum实践关键

这时候，scrum进入视线，于是，结合实际情况，立即展开scrum实施，现总结几点关键方法：

• 调整团队架构，适应scrum开展

将先前的“终端+后台”改为“产品+开发+体验”三个职位 产品设计是故事提出源头，同时负责竞品分析，原型设计，原型验证的工作。开发则负责技术可行性分析，技术难点攻关和代码整体实现。体验人员则负责测试、体验提出意见。

• 故事看板+redmine

看板上放的主要是故事，redmine上放的是任务。 项目由故事驱动（Story Driven）：大故事细分小故事，小故事转化为任务 故事提出者：产品负责人、用户、开发者 任务提出者：开发者根据故事提出任务，在任务进行中根据任务提出子任务（Story下细分出或Task下细分） 故事（Story）与任务（Task）的区别？ 故事无时间限制，30分钟 < 任务 < 1天。每天至少细分一个Task，完成后更新状态，并填写耗时。 故事：精准产品定位 任务：开发工作的反映，作为绩效考核参考 为什么不直接提出任务，而由故事细分成任务? 整个团队过分的关注任务的完成将导致偏离当初的目标，故以故事驱动。 任务是团队细分“故事”的产物，一个“故事”[细分程度]关系开发者对故事的理解程度与心思投入度，是评价一个[故事完成质量]的主要因素。

• 每日立会

立会是推动项目进度的关键，敏捷的源泉

• 产品评审

评审拉入体验人员，体验人员有产品负责人+本团队成员+他团队成员构成，这个会议不会讨论技术问题，都将自己作为用户，提出相关意见。意见会被全部记录，在后续的产品计划会中再探讨解决方案。

• 适度把握

这也许就是理想与现实的差距，无法永远按照理论的方式来进行实践，实际操作中需要调整来保证可行性。但理论一定要作为标杆，不断趋近。

scrum实践成果

团队在经历动员之后，积极投身到开发中，1个月时间就进行了版本发布。士气得以稳定，动荡逐渐平息。元气逐渐恢复以后，接下来就是挑战更高的山峰了。

同时也发现这样的敏捷开发解决了前期遇到的问题： 如： 一个需求不明确的产品开发一段时间后发现竟比不过市面的已有产品； 开发人员做了一段时间觉得很完美了，却发现脱离方向；

总之一句话：一个自由的团队绝不是毫无章法的随意，而是一个健全的制度保障其永久的活跃