企业大部分问题都可以归结为沟通问题，沟通也是一个历久弥新的老大难问题。的确，沟通要遵循很多基本原则，诸如：营造环境、耐心倾听、平等对话、换位思考、表达明晰、及时反馈等等。
很少有人反对沟通中的基本原则，但是现实中的沟通问题，依然纠结难解。说明光有原则远远不够，还需要找到切实可行的方法，把原则落实到行动中去。显然，落实沟通原则比了解沟通原则，要困难很多。
互联网的飞速发展，也让软件开发站在了时代的浪尖之上。软件开发是一项多行业、多工种协作配合的创造性活动，风险极高。从团队组建到项目结束，处处都是陷阱和危机。稍有不慎，就会全盘皆输。为了提高软件开发的效率和成功率，一门新的学科“软件工程”应运而生，也相继出现了多种软件开发模式，诸如CMM、CMMI、RUP、Agile等等。软件工程自1969年诞生以来，看似花样百出，实际上面对和解决的依然是古老的沟通问题。
越来越多的软件开发团队，在尝试Agile敏捷开发过程。如果继续细分，敏捷开发过程又包含了多种模式，如AMDD、AUP、XP、FDD、Scrum、OpenUP等等。抛开其中的细节，会发现各种敏捷开发模式，都把“沟通”放在核心位置，而且都不约而同地推出了各种各样的沟通“仪式”。用看似轻松、有趣、儿童化、游戏化的沟通仪式，让沟通无处不在、无时不在。
沟通的仪式，在实际沟通中至关重要，却又常常被忽视。
让我们看看敏捷开发过程中的几个小仪式。
先看团队组建。
团队是沟通的前提，敏捷团队应该是完整的， 包含和项目相关的所有人员。产品、开发、测试、运营、客服，不分高低贵贱，全部都要进来团队。团队人员不能多，十人以上就要考虑拆分。宁愿多个小团队，不要一个大团队。
团队应该坐在一起。同一个城市、同一个房间、相邻的办公桌，抬头低头都能见。不要相信异地协同，不要相信在家办公。不管部门，只管团队，属于一个团队，就坐在一起工作。
团队的沟通方式应该原始一些，最好是言语和眼神，其次是白板和卡片，最后考虑文档和邮件。
除了在公司一起工作，团队也应该一起外出活动。喝咖啡、看电影、唱歌、旅游。不要小看这些小动作，经年累月地坚持下来，团队就会逐渐变得有凝聚力和战斗力。
再看立式晨会。
任何团队都要开会，开会本身也深刻地反映出了一个团队真实的文化氛围。敏捷团队应该每天在一个固定的时间开会。是每天，而不是临时召集。是固定时间，而不是临时协商。团队不能坚持每日开会，最常用的借口是工作很忙，时间很宝贵，天天开会很浪费时间，团队有必要的时候一定会开会。看似很完美的借口，如果把会议当成喝水、吃饭、睡觉、做礼拜等等必须完成的事情，就一定能挤出时间。
敏捷团队应该站着开会。只有团队成员，杜绝不相关的人员旁听。所有人员都站着，不用考虑职位，不用排定座次。站在一起说话，废话就少，整个会议容易控制在15分钟之内。
每个成员应该依次发言。准备一个道具，比如玩具小熊，开会时候依次传递。谁拿着道具谁才可以说话，没拿着道具的先闭上嘴。有些领导废话多，习惯随时插话，三分钟能讨论清楚的，弯来绕去能扯上三小时。
用真实的道具，确保团队所有成员都能依次、完整地发言，是避免会议冗长无序的好方法。退一万步说，团队中真有马云、周鸿祎这样的“超级侃爷”，每天也只能在固定的时间“祸害”一个小团队。舍小我，为大我，这已经为其他团队、为公司，做出了巨大贡献。
发言三件事。昨天做了什么，今天要做什么，需要哪些资源。说清楚这三件事，不需要上网查询资料，不需要绞尽脑汁编撰。做了啥直说，没做啥不说。
只需要几次尝试，团队成员基本就能开好立式晨会啦。
最后说说工作看板。
让工作看得见，一直都是管理者的梦想。丰田的精益管理做到了，卡普兰和诺顿的平衡计分卡、战略地图做到了，敏捷开发过程也做到了。做法不同，思想相通，而且比预想的简单很多。
准备一块看板。不是做一个软件系统，不是找一台显示器，就是墙上一块实实在在的板子，白板黑板都行。
准备一堆便签。能够写字，能够粘在前面准备的看板上。怕粘不住，就再准备几盒图钉，把便签钉在看板上。
成员都来写便签。团队每个成员，自己写自己的工作。不是领导分派，不是同事指定。自己把自己要做的事情，写在便签上。前面说的每日晨会，结合便签，就更容易说清那三件事了。当然，团队成员如何在一起清理要做的任务、如何让每个成员都知道任务的真实含义、如何把任务写到便签上、如何让团队成员自己认领已有的任务，敏捷开发流程有自己独特的方法，这些方法一点都不神秘，就像幼儿园大班的孩子一起游戏，虽然很“幼稚”，但是很可行，很有趣。
便签贴在看板上。这应该是敏捷开发过程中最有“技术含量”的事情了，看板可以分成四个区域：要做的事情、正在做的事情、做完了的事情、不再做的事情。每天的晨会，说完三件事之后，就是自己移动便签了。正在做的便签，贴到“正在做的事情”那一栏，做完了的便签，贴到“做完了的事情”那一栏。
工作看板很简单，但是团队之外的任何人，也可以一眼看出整个项目的进展。简单，但是神奇。或者说，因为简单，所以神奇。
第一次接触敏捷开发过程，很容易产生一种错觉：这是不是太儿戏了。的确，敏捷过程追求的，就是让复杂的软件开发，变得像儿童游戏那样简单、那样有趣。
进一步学习，会发现敏捷过程非常非常强调沟通。整个开发过程，就是通过一个一个的小小“仪式”，来切切实实地把沟通落到实处。
仪式，可以培养和强化习惯，习惯可以转变为信仰，信仰蕴含着无穷的力量。宗教，为什么如此成功，除了锤炼千年的理论体系，那些延续千年的仪式，也是极为重要的因素。对于很多信众而言，信仰建立的过程，更多是对仪式仪轨，从陌生到熟悉、从熟悉到依赖的过程。
仪式，比原则更容易被大多数人接受。仪式，简单可重复，更容易带给成员安全感、认同感。我们太过强调空洞的原则，效果堪忧，不如辅之以简单可行的仪式，也许会更有效果。
沟通，需要原则，需要仪式，更需要对仪式的坚持。
本文出自 “德鲁克的IT追随者” 博客，谢绝转载！
原文地址：http://wenrong.blog.51cto.com/1945908/1666039
