前言:
敏捷开发在没有笨重的流程与过重文档的情况下, 为使产品的开发能维持高效的运作, 关键的作法便在于: 团队是否能建立一高度自主与自我学习的生态系统?
本文:
对于一由多家外包公司组成, 且外包团队成员人数上百的产品外包团队而言, 在管理的复杂度上, 本身就已相当的高; 要在这管理复杂度如此高的外包团队中, 使团队成员能具备高度自主与自我学习, 实在是一项 “不可能” 的管理project◦
然而, 这世上的很多事物是非常有趣的; 越复杂, 越不可能完毕的挑战, 往往仅仅需极为简单, 极为轻量级的方法便可搞定!
在管理复杂度极高的外包团队, 要建立起一高度自主与自我学习的生态系统, 却仅仅需专注在下列二件事情上:
1. 以外包骨干人员带动团队的其它成员◦
2. 外包人员自我持续改善计划◦
I. 以外包骨干人员带动团队的其它成员:
每一家外包公司都有自身的利益考量与自身的文化背景◦
假如, 由甲方要求外包人员要积极主动, 要自我学习, 往往是力有未逮, 耗尽力气, 却往往成效不彰◦
所以, 甲方的 Product Owner 务必需从每一家外包公司中, 找出符合下列条件的外包骨干人员, 去带动团队其它成员的积极主动性与自我学习能力:
a. 与 Product Owner 关系良好; 甚至可说是具有革命般深厚的情感◦
b. 在外包团队中具有一定的影响力与领导统御的能力◦
c. 自身便能具备主动思考与学习的能力◦
这种外包骨干人员, 在团队导入敏捷转型的初期, 或许并不存在◦ Product Owner 应用心的去挖掘, 并真诚, 推心置腹的与其建立起正向且长久的合作关系◦ 唯有如此, Product Owner 才干经由这些外包骨干人员, 使每家外包公司可自主管理, 使外包人员能由消极被动转变为积极主动且愿意的自我学习◦
II. 外包人员自我持续改善计划:
在每一轮 PI (Program Increment) 结束, 各外包人员应针对下列需持续改善的事项, 提出自我持续改善的计划:
a. 业务场景树
b. 实现场景树
c. User Story 设计
d. 代码缺陷率
e. 迭代完毕率
f. 表格式測试用例设计
g. 測试效率
h. 有效測试用例数
各外包人员应分别针对上述需持续改善的事项, 深度思考需在什么时间? 找什么人? 做那些有助于持续改善的事? 做完那些有助于持续改善的事, 实际所获得的成果为何?
藉由外包人员自我持续改善计划, 将能训练外包人员, 能深度思考该学习些什么? 该向谁学习? 更能使外包人员能主动积极的将产品的效率与质量持续优化, 尽善尽美◦
结论:
经由 “以外包骨干人员带动团队的其它成员” 与 “外包人员自我持续改善计划”, 我们将能在外包团队中, 构建一生态系统◦ 在这生态系统中, 外包人员将能….
a. 自主的成长◦
b. 自主的自我要求
c. 自然的淘汰◦