什么是自我管理
自我管理就是充分发挥团队成员的自主性，通过使团队在不需要（或极少需要）专门的管理者的干预下仍然能够正常运作的方式达到提供管理效率的一种管理思想。就其具体实践而言，笔者认为主要有以下几个：
- 主动通报进度
- 建立和使用团队的共同词汇
- 任务任领
- 站立会议
- 基于原则的工作方式
- 定义完成的标准（Definition of Done）
- 行为激励
主动通报进度
进度的控制、汇报是项目经理的一项重要职责。然而，很多刚刚走向管理岗位的人却是通过询问的方式来掌握进度信息。这种方式不仅效率低下，而且，更严重的是信息的真实性、准确性都不可靠。项目成员在被询问进度的时候可能会因为害怕被责备而慌报进度，心存在事后可以赶上进度的侥幸心理。笔者则是要求团队成员对自己负责的任务的进度主动通报。这里我用的词是“通报”而非“汇报”。汇报是指下级对上级之间的。而在一个敏捷团队中，项目的进度应该是每个成员都要关心的事情，并非项目经理一人要关心的事。因此，每个人的任务进度信息要传达给项目组的其他所有成员，所以称其为“通报”。具体的实施笔者则是要每人在每个任务有实质性进展或存在个人通过努力仍然无法解决的问题时，在即时通讯工具中知会所有人。
团队成员通报的进度信息，项目经理要及时通过检查相关产出物（artifacts）以评价其真实性和准确性，并有效得评估风险。比如，笔者曾经带领团队从事 SOA 系统开发，在这种系统中，本系统同其它系统之间的联调工作相当重要，笔者则要求负责联调的人及时提交联调过程中的抓包文件以及系统日志文件，并知会团队成员对这些联调产出物进行评审。
建立和使用团队的共同词汇
一个团队的沟通要顺畅，团队成员在沟通时必须要采用统一的词汇来表达相同的意思。词汇的统一可以减少不必要的误会和解释，可以减低沟通成本，提高沟通效率。譬如，笔者所带领的团队，由于是所开发的系统是基于 SOA 架构的，其共同词汇主要有抓包、码流、路由等，所有团队成员对这些词汇的含义的理解是一致的。
任务认领
传统项目管理中，任务是由项目经理分配的，团队成员总是被安排做这个做那个。而根据Fredrick Herzberg 的双因素理论（Dual-factor theory），我们不难想到工作的报酬某种程度上是工作本身。任务本身也可以成为一种激励形式。因此，让员工选择他喜欢做的事情，远比安排他做事情的好。因此，在敏捷项目中任务相反是由团队成员主动认领的。项目经理更多的是考虑这个团队需要做什么事情，并将这些代办事项公布出来由团队成员认领。比如，基于 story 驱动的开发，所有 story 的分析是全员参与的，而具体某个 story 的开发任务则可以由开发人员自行认领。这样，可以使团队中的每个成员对本次迭代的所有 story 都有所了解，而其个人所开发又是其最感兴趣的、最擅长的。从而减低了风险。
项目经理只有在当前任务的认领情况有问题时才对其进行调整。
同样，其它的任务也可以采用任认领的方式落实到人。而项目经理要做的是向其他团队成员说明需要完成的事情，并定义完成的标准，据此跟踪任务的进度。比如，对于联调工作，笔者会先确定需要联调的接口以及对方系统，然后由团队成员认领这些任务，据此形成联调接口列表。同时，定义了任务完成的标准是相关联调产物（抓包文件、系统日志文件）通过评审。
每日站立会议
项目经理可以教导团队所有成员每日站立会议召开的目的、会议的主题、原则以及会议控制的技巧。并要求团队成员按照这些要求轮流主持会议。这样，即使在项目经理缺席的情况下，每日站立会议仍然可以召开，团队仍然可以正常运作。
基于原则的工作方式
所谓原则，是指必须遵守的、在绝大多数情况下都适用的规则。笔者在所带的团队中主要强调以下几个原则：
公共代码的改动知会
公共代码一旦改动出错，其影响甚大。然而，指定专人负责公共代码的维护，在敏捷团队中又显得太奢侈（一般敏捷团队成员数在 10 人以内）。显然公共代码又不能任由所有人参与修改。一个折中的方法是制定一个改动代码的规则，凡是涉及公共代码的修改，所有人都必须遵守这些规则。基于上述考虑，笔者制定如下规则：
- 公共代码应当避免修改，即这部分代码能不改则不改。
- 公共代码修改前，修改人需在即时通讯工具中知会所有人改动的理由和方法。
- 修改过的代码在 checkin 到配置库后需立即知会所有开发人员及时同步代码（以便及时暴露代码改动的风险）。
主动跟进需要他人配合的工作的进度
笔者要求每个团队成员对于自己手头上的工作需要他人配合的部分其本人要负责跟进这些任务的进度。比如，文档开发人员在完成初稿后知会所有团队成员对其初稿进行评审。而其本人要及时跟进其他人员的评审意见的反馈情况。而参与评审的每个人要自动跟进其所提意见是否被采纳已及文档作者的修改是否符合其本意。
任务进度风险控制
很多开发人员可能有这样的心理，在碰到问题而自己又不能解决的时候，仍然硬着头皮不肯求助，甚至于陷入问题的死胡同。一方面可能是害怕求助会被人看不起，另一面可能急于求成，而忽视了效率问题（时间是最大的成本）。因此，项目经理要打消他们的疑虑，要鼓励团队成员在做了必要的努力后仍然不能解决问题时要及时主动寻求帮助。因此，笔者要求团队成员 在任何一个问题上个人已经采取各种方法但仍然未能在 30 分钟内将其解时，当事人要立即寻求帮助。
讨论原则
一个没有人讨论问题的团队是一个不健康的团队。既然有讨论，就必然有冲突。而讨论的目的在于达成一致意见。因此，凡是双方或多方讨论问题时，当事人未能达成一致意见的，要主动引入另外一个人以达成一致意见。
定义完成的标准（Definition of Done）
所谓完成的标准，简单得讲就是一个任务做到什么程度才算是完成，要输出那些产出物（artifacts）。可能现在仍然有不少团队要求其成员提供诸如日报、周报之类的工作报告，其中自然少不了每件任务的完成情况，这个完成的情况通常是以百分比来计算。但是，也许大家不难发现一个情况，比如，某个成员报告中写明某个任务的进度是 100％，也许这个人工作态度是很诚实的，能力也不差，但是，当项目经理真正检查这个任务的进度（比如通过评估其产出物）才发现这个任务的进度是 0，根本没有完成——实际所“完成”并非项目经理、或者团队所期望。其原因在于，定义任务时没有定义其完成的标准，此时任务的执行者往往只是照着自己的理解去“完成”任务的。
笔者所带团队常见的完成标准如下：
开发人员开发某个 Story，其编码完成的标准可以定义为：其负责的 Story 经过单元测试（要求提交单元测试时产生的系统日志文件到配置库），并且该 Story 通过由测试人员定义的预测试用例。开发人员在完成编码、单元测试后主动召集测试人员及其他人员对其负责的 Story 进行演示，演示时要求其展示各个预测试用例的执行结果，只有演示通过了，该 Story 的编码才算真正完成。而一个 Story 的开发完成，则是定义成其通过 Story 测试。
某个文档写作任务的完成标准可以定义为：初稿发出评审后，没有发现如何问题，或者评审者提出的意见初稿作者均已处理，且处理的结果经过评审者的确认。这样一个文档的写作才算完成，其进度可以报告为 100％，否则，仅仅完成初稿，而初稿未经评审，其进度最多算 40％（甚至都不到！）。
行为激励
自我管理的实施需要团队中每个成员的认真配合，这就要求每个成员要站在团队的角度去改变自己。甚至，很多自我管理实践真正的落实是需要靠全体成员去养成一些良好的工作习惯，比如，自动通报工作进度、主动跟进需要他人配合的工作的进度等。养成一个坏的习惯很容易，而一个成人去养成一个好的习惯却不是那么简单，需要不断的重复。因此，这个过程中，项目经理要对符合自我管理要求的行为及时进行激励。
结论
团队自我管理不是没有管理，而是通过管理者和团队成员的共同努力，使团队达到一种极少甚至不需要专门的管理者干预的情况下仍然能够高效率得运作的一个境界。团队自我管理的实施，需要项目经理发扮演好导师的角色，给团队指明发展的方向。同时，也需要团队的每个成员的积极配合。
参考资料
学习
访问 IBM Rational 项目管理工具包，本工具包为您提供了一系列关于项目管理，以及 IBM Rational 交付平台（SDP）如何帮助您进行项目管理方面的最佳实践资源，包括白皮书、案例分析及文章等参考资源。通过本工具包，您将了解如何实现软件开发项目的高效开发和有效监管，使项目能沿着正确的方向走向成功。
访问 IBM Rational 敏捷开发工具包，本工具包将帮助您了解 IBM Rational 为敏捷开发所提供的技术和解决方案，以及 IBM Rational 在敏捷开发方面所积累的最佳实践。帮助您更好地运用 IBM Rational 软件实施敏捷开发，将敏捷开发的实践落到实处。
访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
| 
