读《大规模敏捷开发实践》

初识敏捷开发是在2006年，那时愉快的加入了毕业后第二家公司，一家打算在中国开展外包业务的美国公司。其业务形式就是让在美国的总部接当地的IT单子，然后拿到中国来做。

中国分支的名字也很高大上，Global Development Center，其实当时在全球就这么一个分支机构，不知当初的美国老板怎么选上杭州，而不是上海的。

我那时对软件开发的流程认识基本停留在软件工程课本里描述的所谓瀑布式开发，在项目开始前拼命的收集需求，根据可怜的尚不明确的信息进行分析，争取设计出一套合理的逻辑抽象，并祈祷在开发过程中客户千万别拍脑袋变更需求。由于国际外包规则就是看外包公司的CMMI等级，所以就是这家公司将看似风马牛不相及的两套开发流程（Scrum和CMMI）结合在了一起，有SQA team对质量进行度量，参加每日站会，challenge team leader，跟踪文档。

那时有个为美国政府开发的较大项目，断断续续持续了近两年，开发人数有近30人，为了提高跟美国BA(业务分析员)的沟通效率，同时派到美国去的开发最多时也有10几人，成本很高。项目组一个PM，拆分成了4个team，每个组一个leader，再下面的开发3-5人。那是我就在考虑敏捷项目是否适合大项目，因为敏捷之所以能敏捷，是因为人数基本上是在9人以下的，这样才能坚持短时间站会，提高每个迭代结束时review meeting的效率，在迭代开始做任务估算能半天搞定。

超过9人，人与人间的沟通成本大增，本来坐在一起的几个人，喊下就能沟通的，现在不行了；物理上不能近距离的坐在一起，可能要靠IM，EMAIL,电话。大型外企呆过的都有个毛病，就是干啥都喜欢写邮件，大家发来发去，抄送一堆人，不亦乐乎，为什么这样？因为人离的远了，交流要留下点文字的证据。不要说跨部门沟通，同一个部门人都有隔阂。

这样的情况下如何让大型开发团队，而且还可能是跨国异地文化不同的团队进行敏捷开发，那时我还没有想清楚。直到年初朋友介绍了我这本书，内容就是HP如何将自己500人的团队进行敏捷化改造，开发其核心功能Firmware的。其组织文化敏捷化过程改造也经历了长时间阵痛，顶住了因循守旧的人类根性的质疑，提高了产品线的生产效率。

这是一本值得仔细品味的书。

---

文章来自微信平台「麦芽面包」。转载请注明。