返回 登录
0

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

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

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

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

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