敏捷团队之旅(1) - 新的开始

前段时间同一些公司交流，大家对什么敏捷Scrum很是好奇与怀疑，总结一下有这么几点：

• 敏捷是个新鲜东西。
• 敏捷理念很好，但只适合与国外；甚至有一位Boss说：在哪都行，唯独在中国不行 。
• 敏捷对人的要求很高，我们现在的人不行，因此不适用。
• 敏捷导致成本提升。
• 团队自我管理是一件不可思议的事情。
• 全栈不现实，流水分工更合适
  blabla.....

在这里，我不打算解释什么是敏捷，什么是Scrum，因为网上有许多大牛介绍的非常清楚。

我只是想用我们一个团队的养成过程来分享给大家，尽量根据记忆与资料还原整个经过。

时间退回到2016年12月，我加入一家新创业公司，负责技术团队组建与架构搭建，从招募队友到设备购买，一切全新开始。

---

队友招募

如同大多数创业型公司，资金是很有限的，预算必须严格控制，每一分钱都要发挥最大价值（这里小小吐个槽，为了节约成本，这几个月我每天都是自带设备，背着重重的MBP上下班），因此一致认同采用精兵策略运作团队，最大化发挥团队的效率。首选的成员目标是之前一起共事过的且离开原单位的伙伴。

值得高兴的是，当我发出招募请求给一起从Z公司出来的几个同事时，他们纷纷表示就算是降薪也愿意跟我一起做事，不得不说这是令我感动的事。

人员陆续到位，由于本来就在Z公司跟我一起工作了一年左右，大家都熟悉，团队的组建阶段与震荡阶段就比较好度过。

初始成员： 后端人员开发 2名，前端APP开发 1名，UI设计 2 名，产品经理 1名，加我共 7名。
人数上倒是蛮符合Scrum的最佳人数 (7 ± 2) 。

这里面居然没有测试人员！！！ 漏了吗？ 不重视测试与质量了吗？
也没有IT运维人员！！！
这个问题后面再说。

其他小伙伴就不在这里列出来了。

---

技术选型与分工

团队组建完成后，大家开始分工干活。

技术的小伙伴购买并部署云主机，技术选型与制定框架。
基于投入产出比角度考虑：
后端 采用 Ruby开发语言，RubyOnRails作为开发框架；
前端App 采用 React Native 混合开发模式；一个人员同时搞定 iOS & Android；
源码管理 购买github的企业服务；避免自己部署维护GitLab CE；
主机 数据库 缓存 全部购买云服务；节约运维成本；
redmine 做计划任务；

后端系统架构方面，直接改进在Z公司验证过可行的系统架构(以后有机会把这个框架的设计写出来)，原来的系统架构需要处理历史包袱，导致架构相对复杂，这次是个全新的系统，没有历史包袱，所以把原来的架构做柔合简化，重新编写。

后端的小伙伴主动提出，给他机会，我提供指导，让他来负责实现这个架构，这样他可以更好的得到学习与锻炼。

前端的小伙伴也是非常优秀，从刚接触React Native，边学习边实现，一路走来踩了不少坑。

产品经理与UI也在啃哧啃哧整理需求、画原型、做设计。

---

似成相识的轮回起点

一周后，产品经理把需求整理出来了，并向我们扔了一堆用Axure RP画的看起来详细的交互原型，然后要我们给出开发计划。

这个很常规的做法，但是当时我的心里却是一万头小动物在奔跑，我仿佛看到之前那些项目的场景又在重演：产品与技术的相爱相杀、互相伤害、无尽的需求变更/澄清之争、BUG与功能进度的交织导致的加班、项目的不断延期、以及到最后的互相甩锅。

这些场景是否或多或少出现在你们的项目之中呢？

为了避免这些的发生，为了项目最终真正成功，我直接喊停了产品经理的需求工作，向他说明了我们曾经因为这种方式而遭受的痛苦，要求采用用户故事的方式来描述需求。

产品经理当时对用户故事是简直一脸懵逼，随即对他做了讲解，并推荐《用户故事与敏捷方法》一书。产品经理值得点赞的是，不懂就学，立即下单买书学习。

---

只有亲身经历一遍，才有经验教训

产品经理内心还是不以为然，不认为现有的方式会有问题。

那么我们用一个星期按照原来需求方式来实现一个小demo，交付的时候让他感受一下会的到什么。如我预测的一样，几个简单的小功能就有好些地方公说公有理婆说婆有理的差异。

让他明白需求原型上有写明了的，开发人员如果没有照做，是开发人员的问题。
需求原型上没有说明的，开发人员没做或者按照他们的理解去做了，如果有问题是产品经理的问题。否则就只能导致互相伤害。

经过这次体验，有了共同的认识。他便认真看书学习。

---

重新开始

我们的美女CEO Phoebe看到这本书，也好奇拿去看了两天，然后跟我说这上面的方法看起来很不错，她们商务方面也能借鉴。让我给她讲解了什么是Scrum，然后问，我们能不能用Scrum来做事，我说当然行，但是要用就严格遵照Scrum的原则，我们做事的方式需要发生改变。她说我们刚开始，没有那么多条条款款，拍板决定用Scrum，。

同时，团队也很有兴趣做这种尝试。因为我声明出现任何问题，都将有我负责承担，为团队提供一个安全的空间。

那么，Scrum的角色分配：
ScrumMaster (SM) - 我
Product Owner (PO) - 产品经理，以后我们将用PO代替产品经理(PM)
Dev Team - 前后端开发 + UI

给大家讲解了一天的Scrum，让全体人员动手练习如何写用户故事与验收标准。
根据Scrum原则约定我们的准则：

1. 质量优先与进度，不对质量问题妥协；
2. PO负责整理用户故事并排序；
3. 开发团队负责为用户故事编写验收标准，PO审核验收标准;
4. 开发团队对交付与质量负责，单元测试、功能测试、集成测试、持续集成都是开发团队的职责；
5. 由团队承诺一个Sprint完成多少故事；
6. 不在使用Redmine作为任务跟踪，仅它的Wiki写文档；
7. 使用物理白板作为进度跟踪，并拍照留存。团队不再另做汇报工作;
8. 为了强化对用户故事与验收标准的掌握，完全用告示贴手写;
9. 不加班，不加班，不加班；
10. 两周(10个工作日)为一个Sprint, 不提前也不延后；
    .....

然后，PO花了一天时间按照规范重写用户故事并与团队讨论。第二天启动迭代计划会。

事实上，当时从CEO到开发团队，会做出什么效果，心里都没有什么底。有的只是对我的信任。

在这里感谢我们的美女CEO Phoebe的信任与全力支持、各位小伙伴的鼎力协助，否则就没有后续的故事了。

---

未完待续....

敏捷团队之旅(2) - 新年前的第一个迭代