百人团队敏捷转型日记 第一集 架构师没了、版本管理的蜕变

首先简单介绍下背景： 
博主所在软件公司的某产品线一个百人开发团队，自2015年至今，从传统的瀑布开发模式， 
成功转型敏捷开发管理（SCRUM+XP要素）。有效提高了客户需求响应速度、 
开发团队工作效率，给公司带来了新的活力，变革过程中也对敏捷方法做了改进。 
博主有幸在其中担任一个开发组组长和版本管理组成员，此处将博主在整个转型过程中， 
看到的一些弯路、以及成功经验分享给大家。 
文章会涉及到 组织扁平化、持续集成、自动测试、自动部署、SRUM框架、结对编程等敏捷要素。 
以及敏捷倡导的价值观： 
个体与交互重于过程和工具、可用的软件重于完备的文档、客户协作重于合同谈判、响应变化重于遵循计划。 
这是一场带着温度、历历在目的思想碰撞，欢迎大家来和博主交流。 
*

第一集 架构师没了 版本管理的蜕变

2015年之前，博主所在产品线（综合管理平台）还是传统的瀑布开发模式，整个产品线子项目多达十几个。各子项目各自为战，子项目之间依赖关系多且不明确，实际上线的产品各子项目版本不统一。整个产品线软件版本管理很难控制。 
2015年初，突然有一天，听说公司要引进敏捷。研发基本上只听过敏捷的一些概念，甚至连项目经理也不甚了解。 
公司采取的方式是，专门请了敏捷培训公司首先对项目经理进行了两周的培训。博主大学学的软件工程，加之之前参加过 
一些敏捷的沙龙活动，所以对团队一些想法理解的要快些。很快，一些实际的改变发生了。

1. 架构师没了，自组织的团队、项目经理–>敏捷教练 
   首先，之前的管理模式中，一个项目中最关键的人是 项目经理+架构师。项目经理掌控着项目的进度，架构师决定了项目的整体设计，研发人员则在整体架构的基础上进行模块设计。在敏捷框架中，更强调团队的自组织能力。 
   首先被取消的是研发团队中这种明显的上下结构。各个研发成员在开发过程中，有对自己负责模块的充分自主权并承担相应责任。模块开发完成后，只对于关键的代码邀请团队成员进行代码评审。 
   项目经理的职责从严格把握项目进度，变成在迭代起始阶段指定粗线条的任务，然后让团队成员细化任务并给出自己的计划。 
   更多的自主权放给团队成员。项目经理关注关键时间点和关键任务，并保证敏捷活动在团队中的实施。 
   总结： 
   自组织的团队，要求团队成员的平均技术水平较高，因为没有架构师的团队，产品质量更多的依赖每个成员的技术水平。
   同时自组织带来的好处是，可以锻炼整个团队的成员，可以激发团队的积极性和活力。 
   我们在实施的敏捷的初级阶段，确实带来了一些产品质量下降的问题，这一方面要测试团队的方法改进（自动化测试、单元测试）。另一方面在开始阶段可以使用经验老道的开发人员和新人结对开发、定期组织代码评审来解决。
2. 研发资源池的出现，跨团队的研发人员，团队之间人员互相流动，团队活了. 
   传统的开发模式中，往往一个项目组中有些人很忙有些人则工作不饱和。这种情况主要是由于成员的工作情况不够透明，一般一周项目组才开一次周会。而在敏捷中，故事墙+每日站会则可以解决这种工作不透明的情况。加之统一的工时管理，可以直观的看到某个成员的工作饱和度。 
   在整个基础上，一个新的部分“研发资源池”出现了。这个部门整体上掌控各个研发团队的人力情况。当某个项目缺人手，就可以从其他项目调其他成员过来。团队人力情况透明化，人员灵活分配，团队就盘活了。 
   总结： 
   在具体实施的过程中，会有各种现实的问题，有些项目组虽然有空置人员，但是项目经理总是有着被挖人的感觉不愿意放人。而团队成员也会 
   有自己的喜好，可能更愿意待在一些轻松、自己喜欢的项目里。 
   这种问题一方面公司要全局意识传递项目经理，对于各个项目的实际情况要把握准确。有一就有二，我们在实施的前一阶段确实有遇到过阻力，但是当整个团队都对这种流动形式达成共识后，就会顺利好多了。执行者要坚决。
3. 版本管理组–>敏捷活动中的关键职能团队 
   因为敏捷之前各个项目组各自为战，整个产品线的版本管理工作基本上停滞于半年出一次大版本，对各个子项目的基本没有控制力。 
   敏捷开发中，强调快速的迭代，及时响应需求。版本管理工作在敏捷活动中扮演了重要的角色。 
   迭代的周期、迭代中各关键时间点的确认、持续集成、自动部署。这要求版本管理必须对各个项目提高掌控力。 
   博主有幸参与了版本管理组的工作，在后续的篇章中将详尽描述。 
   欢迎大家留言讨论，另有相关的微信讨论群，欢迎加入。 
   3月19号之前有效。