写这篇文章的主要目的有：
1. 总结项目团队转型的经验，提供其他团队借鉴；
2. 评估团队敏捷成熟度，找出不足的地方进行优化。
薪酬管理平台于2018年10月前立项，11月中旬组建团队启动项目，项目初期依靠直觉管理团队，大体上采取的是传统的瀑布模型：
第一步：需求评审（少数核心人员参与），理解系统业务功能；
第二步：由资深的开发人员做概要设计，包括表结构和功能点梳理；
第三步：开发人员入场，按照模块分工，前后台分离开发；
第四步：经过两个月的混乱、高压、高强度加班后，系统第一个版本上线。
回过头看这段时期，从项目阶段描述中就能发现不局限于以下问题：
问题1：开发人员入场较晚，对业务知识缺乏整体认识，为前期开发乃至后期组装测试埋下了巨大隐患；
问题2：设计难以承受之重，设计的不全面是必然的，加上需求变更，导致开发人员在组装测试才发现设计问题，返工成本巨大；
问题3：一些开发人员个人原因极大的拖累了项目进度。
好在系统成功上线，到2019年3月份项目组决定改变，开始敏捷转型。这时团队的人员组成包括：
管理人员：项目经理1位、技术经理1位，建行（甲方）
产品经理：2位，建行（甲方）
开发人员：前端2位、后端7位，建行/合作公司
系统管理员：版本环境管理员1位、生产系统经理1位，建行（甲方）
其中，开发人员大部分来自乙方合作公司，而且还包括两家合作公司，对于团队文化和管理具有一定的难度。转型之处，我们做了评估，转型的优势有：
优势一：团队人员构成比较全面、且几乎都是全职（生产系统经理兼职）；
优势二：前后端分离，且都在项目组手里，迭代迅速；
优势三：外部依赖较少，主要依赖的代收代付组件是自己人（薪酬管理平台是代收代付的衍生项目）；
优势四：部署在建行公有云，版本迭代频率可以自己控制。
于是薪酬管理平台团队敏捷之路，经过5个月的实践，做了如下改变：
1. 看板导入
逐渐用看板完成迭代版本的生命周期管理，效果还不错。
2. 站会
项目信息共享和冲突管理，高效有士气。
3. 需求梳理
增加团队成员的参与感，开发人员更早更全面认识业务需求。
4. 自动化工具引入
减轻了团队的工作任务，提高了项目绩效。
5. 版本迭代
大版本、小版本可以自由选择，版本迭代效率极大的提高。
6. 回顾会
积累经验和教训，不断改进和优化，构建学习型团队。
当然，团队还存在不足之处：
1. 知识库
没有创建知识库，也较少组织知识交流会，缺少团队成员提升计划。
2. 文化
敏捷文化不够活跃，团队成员更多的是执行项目管理计划，较少主动发扬敏捷文化。
路漫漫其修远兮，项目管理之路才刚开始，敏捷之路也当继续走下去。
网友评论