近日，我跟业内优秀的敏捷教练们以及公司内部热忱、致力于敏捷转型的内部教练们一起，渡过了行程紧凑、收获满满的两天敏捷实践分享之旅。这两天听到分享师们提到很多次的一个名词，就是团队自组织。所以我也想基于自己的思考和大家的观点，谈一谈怎么样更好的达到团队自组织的状态。
首先简短介绍下团队自组织的理想情况：自组织团队自己决定最好的方式/流程是什么，从而可以达到他们的目标。外部没有人分配他们工作（没有外部的命令控制），他们自己决定需要完成哪些工作以达到整体目标。团队还需要反思他们的工作方式，并在需要的地方进行改进。
致力于实现上述的理想情况，在我所在项目中，我们实践了以下的方式：
信息对齐
任务领取
风险控制
反思提升
1.信息对齐
很多走入管理岗位的人喜欢通过询问的方式来掌握进度信息，这种方式不止效率低下，而且信息的真实性和准确性都不太可靠。
在敏捷团队中，我们更多提倡的是信息对齐。团队成员通过坐在一起办公的方式，开放式而非格子间的办公环境方便大家随时讨论交流，理想情况下，团队内部应不存在信息堵塞，大家都能知悉项目的最新目标、项目进度和风险点。每日晨会和看板，则是让团队成员进一步对齐信息的有用工具。晨会上每个人轮流发言，基本要求是：我昨天做了什么，今天计划做什么，遇到的问题/风险点是什么。看板则将大家的任务和状态可视化，让风险点无所遁形。团队外部的人和领导者也能随时依据看板知悉项目的状态，而不需采用一一询问、成员汇报的方式。通过信息对齐，我们就可以达到团队主动通报进度的自组织。
2.任务领取
在瀑布式的软件开发方法中，具体的开发任务一般是由项目经理或者技术经理进行分派，这种方式会导致部分成员“能力越强、责任更多”的情况发生，无法完全调动全体成员的积极性和成长性。我们希望有更好的方式能够帮助成员主动成长、调动成员的积极性。通过让员工选择他喜欢的任务的方式，让任务本身成为一种激励方式，这是一种很好的激励员工走出舒适区，来到挑战区的方式。
我们可以让成员自己领取任务，进而让领取同一用户故事的小团体共同对那个用户故事负责，更进一步可以小团体内推举一个该用户故事的负责人，由他/她来推动用户故事的完成，进行内部的沟通协调。这种方式可以让站在小团体外部的人（包括项目负责人）都不用过于深入用户故事对应的任务细节，而只需要关注故事的整体完成度情况。
3.风险控制
对于团队内一些性格特质的人来说，主动暴露问题提出请求，对他们来说是一件是比较难做到的一些事情，他们更倾向于内部消化和承担。但在大型组织内，有些问题需要上升才能解决，例如外部依赖的问题，或者是棘手的技术问题。为了合理控制风险，我们在一次敏捷回顾会里专门详细讨论了风险点的分类和对应的行动项。针对单独的技术问题，独自解决的时间应控制在2个小时以内，超过2个小时就上升为风险，并且约定了哪几类问题分别向哪些人求助，以及不这样做的个人应接受的惩罚措施。通过这种集体约定，极大提升了风险不可控影响效率的问题。
4.反思提升
每日都用习以为常的方式来工作，慢慢地我们会受困于这种方式，变得难以改变，也就失去了变得更好的可能性。作为一个自组织的团队，我们希望能够定期反思我们的工作方式，找出关键节点进行改进。
回顾会能够极大的改善团队合作、改进工作方法、提升工作满意度，以及实现更好的工作结果。这是带着自我监控的方式去回顾过去一轮迭代的工作。在回顾会上，我们不去讨论好与坏，而是讨论过去发生的事情在未来可以改进的地方，剔除失败，放大成功因素。而且回顾会也是很好的拉进团队成员关系的一种方式。
网友评论