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

初识敏捷开发是在2006年，那时愉快的增加了毕业后第二家公司。一家打算在中国开展外包业务的美国公司。

其业务形式就是让在美国的总部接当地的IT单子，然后拿到中国来做。

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

我那时对软件开发的流程认识基本停留在软件project课本里描写叙述的所谓瀑布式开发。在项目開始前拼命的收集需求。依据可怜的尚不明白的信息进行分析，争取设计出一套合理的逻辑抽象。并祈祷在开发过程中客户千万别拍脑袋变更需求。因为国际外包规则就是看外包公司的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的。其组织文化敏捷化过程改造也经历了长时间阵痛。顶住了因循守旧的人类根性的质疑，提高了产品线的生产效率。

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