塑造敏捷教练
至此，我们仅讨论了在开发者中发生的常见实践问题。然而，创建和维护一个具有敏捷态度的开发团队也是教练和其他领导者最重要的责任。这些领导者必须为他们的团队建立一套好的样例并成为真正的教练，而不是成为只有“教练”头衔的团队成员。
最有效的领导技能之一就是建立一整套好的样例。开发团队会建立一整套规则，比如所有的产品代码要结对编写，所有的产品代码都要先写测试等等。只有团队成员 坚信这些规则是非常重要的，这些规则才会起作用。然而，“说了不做”真的是太容易了。例如，团队领导者向团队成员宣布：“构建失败了，我们现在最重要的任 务就是修复它。”刚听到时一定会信以为真，可是接下来的话却不是那么回事了，“我第一个发现了这个问题，原本应该由我来修复它，可是我太忙了。”他的行动 使其对这件事的重要性大打折扣。别人会认为，构建可能是现在最重要的事，也可能不是。作为一个团队领导者，让别人看到他正在与一个开发者一起修复这个构建 是很平常的事情。这么做可以向团队成员进一步表明，构建是一个非常重要的事。
好的教练并不仅仅是知道如何教开发人员技巧，还要鼓励开发人员务实思考，并高效协作。这有点与Ken Schwaber所描述的ScrumMaster 的角色相似，即该角色对鼓励团队协作负有责任。当教练拒绝解释而直接用自己的知识来解决问题或者以命令的口气来领导团队时，这就是一个不太好的信号。
我想，最好从外面请一个人来作为“教练”帮助团队，而不应该是团队的固定成员。如果教练是团队中的一个固定成员，那么会存在利益冲突：有时他要帮团队成员，以便提高团队能力和效率；而有时他要客观地评估团队，在团队成员之间做一些比较。就象Kent Beck在他的《Extreme Programming Explained》一书中所提到的，一个教练应该有一个目标，即帮助团队成长，最终达到不再需要教练。一个好的教练需要一定的自信和情绪控制力，也需要技术能力和经验。
铲除潜在的问题
有几个潜在的因素会对团队态度产生负面影响。一些团队成员很担心：他们的团队领导做改革只是为了进一步达到个人目标，而不是为了使团队做得更好。另一部分 成员不愿意面对变化的原因是怯于表达。另外一个特别麻烦的问题就是：谁不喜欢自己得到夸奖，并可以批评别人呢？可是我们真正需要的是虚心地接受批评和学 习。
在软件业，很多创新可以得到个人奖励。写东西和在会议上讲演显然都会提升个人形象。技术领导者、教练或处于同样角色的人就处于一种可以引入变化的位置上。 我们应当意识到，尽管我们鼓励创新，但变化也有可能带有破坏性或给已经高效工作的团队更大的压力。因此，和团队一起进行回顾找到解决方案要比由领导宣布某 种改进策略要好得多。
此文章共有5页 上一页 1 2 3 4 5 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
