1、通过面对面的，面向问题的，合作性的沟通，达成对问题域和解决方案的共识。
团队成员、项目经理、高层、客户和其他关心项目的人员的视角和所能理解的概念是不同的。开发人员需要区分不同的沟通对象，以对方的视角对问题进行合理抽象并选用合适的词汇进行沟通，以提高效率。对于达成的重要的结论，应予以记录，并作为双方实践的约束。任何一方在沟通过程中出现欺骗、诱导、含糊不清的现象都可能导致失败。这种失败的可怕在于，可能在沟通之后的数天、数月，甚至已经造成了严重后果才被发现。因此沟通应该是合作性的，在达成共识之前消除一切分歧，或者约定下一次沟通的时间。经验技巧和对工具的熟练应用不是团队优秀成员的充分条件。优秀成员应该要有一个通过团队合作达成目标的良好愿景。
2、发挥文档的作用，拒绝为维护文档付出不必要的代价。
文档的首要作用是为了降低软件开发和维护过程中的沟通和培训成本。文档是团队成员之间有效沟通的第二媒介。
在分析、设计过程中出现的阶段性产物，如用例图、类图、时序图、框架等模型可以直接作为独立的文档或者设计文档的一部分。这类文档通常短小，但主题明确，对表达系统的高层结构和设计是必要的。最重要的是保证这类文档与代码同步所要花费的时间，相对于口头传授或者通过研读代码来提取相同信息的代价要小得多。以这样的标准，库作者应该提供接口的详细说明文档，通讯双方应该制定协议文档，配置管理员应该有某版本系统对应重要组件的路径和版本文档，对软件产品的兼容性应该有一份说明文档。与外部文档相比，自说明代码是从编码或略高的层次理解软件实现的最佳文档。结构和命名合理的代码，加上一些更高抽象层次的注释构成的文档，在不借助他力的情况下也能表达足够的信息。
3、制定合理的计划，并给变化预留一些机会。
关键是要有一个可行的计划，有足够的灵活性来迎合变化。近期的计划需要有较细的粒度，而越远期的计划粒度应越粗。因为时间越长不可控的因素就越多，出现变化的可能性也越大。另一方面，制定精细的计划行为本身也需要大量的时间。一旦出现变化，计划的调整则需要更多的时间。而粗粒度的计划甚至可以吸收掉部分细微的变化而暂不做调整。
4、让客户或客户代表参与到开发过程。
只有完全满足客户需求的软件才是有价值的软件。即便有时不能与客户面对面沟通，开发人员也应该尝试从客户角度分析问题，经常性的向客户提交可以工作的软件，并确认客户的满意度。根据客户的反馈，开发人员及时的调整软件以符合客户利益。不能等到客户抱怨才做这样的事情。
附：
敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也具有价值，
但我们认为左项具有更大的价值。
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
敏捷原则
1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3、经常性的交付可以工作的软件，交付的周期可以从几周到几个月，交付的时间间隔越短越好。
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并信任他们能够完成工作。
6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7、工作的软件是首要的进度度量标准。
8、敏捷过程提倡壳持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9、不断地关注优秀的技能和好的设计会增强敏捷能力。
10、简单——使未完成的工作最大化的艺术——是根本的。
11、最好的架构、需求和设计出自于自组织的团队。
12、每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
浙公网安备 33010602011771号