公司在敏捷宣贯培训统一了认知和理念之后，就开始了落地实践。第一周的第二天就召开了敏捷转型启动会，领导宣布（我是第一次知道）公司对业务战略做了大刀阔斧的改革。总裁说话语速不快，音调也不高，温文尔雅的背后，透着一股坚定、自信的魄力，让大家看到的是未来清晰的蓝图，和未来的希望。不知道别人怎么想，但是我从现场的气氛中能感受到一种从未有过的凝聚力，虽然大家回应不是很多，但我的身心有感应，有的时候，不用听别人怎么说，甚至不用眼睛看，从整体的气氛中就能获得信息，这种信息甚至比看到的还准确。我相信这一点。稻盛和夫先生说“经营企业最可靠的东西就是人心”。人心齐了，才有成功的可能。
根据几条产品线同时做了组织架构调整，每个产品线的角色如下图：
公司的组织变成了矩阵式，既有职能组织，也有产品线这个虚拟组织。
我从项目实施部的项目经理角色，要转换为PO角色，负责公司一条产品线的项目定制开发需求工作。这样，我实现了一年前加入晓羊时对自己的定位和规划，我记得在项目部工作两三个月的时候，我就提出了这样的想法和建议，增加一个需求分析团队（也就是现在的PO角色，目前只有两个PO）专门负责项目上的需求工作，跟项目经理配合作战。
简单来说的话，就是项目上需要找研发支持的，就是PO+研发来负责，协助实施部项目经理做定制化部分的交付，包括集成对接开发、功能性开发。
PO（相当于下面的业务分析师）和项目经理的职责划分如图：
SM这个角色，业内没有统一认可的特别合适的中文叫法，我觉得可以叫做敏捷项目经理，跟项目实施部的项目经理都是做项目管理工作，区别是一个做的是软硬件实施项目，一个做的是软件开发项目。不过，为了更容易区别于常说的项目经理，如果让我翻译的话，我觉得敏捷指导员这个称号挺不错。结合我解放军的优良传统和优秀实践，一个连队的指导员（这时候大家可以在脑海里过电影了）就跟敏捷团队的SM一样，有困难找指导员，他负责思想工作，鼓舞士气，是真正为全员服务的领导，还定期组织大家开展批评与自我批评，总结不足持续改进。
有的产品团队已经开始了实践，王立杰老师作为公司的敏捷教练，参与和指导每个敏捷团队开始思考和梳理工作如何转变和切入。我们团队因为不是做产品，而是做项目，而且有几个大项目是进入了维护阶段，不时来几个需求，做完了就要发布，不像Scrum有一个固定的时间盒，可以按版本计划去发布，除非是一个新的项目，有系统级或大功能模块级别的功能性定制开发。所以根据教练的推荐，下周准备开始尝试看板。看板跟Scrum相比，是一种更简易的框架和模式。具体如图所示：
看板框架示意图
可参考的实际看板案例
看板的三大原则：
1、流程可视化，让需求或任务滚动起来。
2、限制WIP（在制品，Works in progress），也就是限制同一阶段区域里面的任务数，超过上限会造成工作效率低下，质量也会出问题，表现出来就是忙、乱、差。
3、度量生产周期，评估一个时间段内能做完几个需求或任务，对团队的生产力做一个估算。
有几个项目已经开始找到我这边了，有些问题就是马上要解决的。于是我对需求做了了解之后，就按用户故事的方式对需求做了一个描述，定义了DoD（完成定义，或者叫验收标准），这样研发和测试就知道如何算是完成了，确保需求按客户想要的价值目标实现。
如图，这是其中一个项目的需求：
如果下周把看板建立起来，我准备做一些用户故事卡片（借用周金根老师的），类似这样的：
用户故事卡片（周老师设计）
SM跟我说，这才刚开始第一周，就感觉同时很多事情找过来了，他说得有个优先级啊，确实，他提醒了我，我跟他说，咱们下周就建立看板，其中的WIP原则就是为了限制同时进行的任务数量的，就能解决我们忙乱的困扰。
因此，周五下班前我去HR那里领了工具，下周就开始真刀真枪的干起来了。
我对我们的工作充满了期待，虽然有些忐忑，但摸索和创新让我们兴奋，因为我们的所作所为将会改进我们的交付价值，会让我们为公司做出更大的贡献，会让我们的客户更加信赖和离不开我们，也会让客户在我们的支持下更加高效和成功。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。