里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”
——Tom DeMarco 和 Timothy Lister
微软的团队是没有固定的领导的，因为任何人都是领导，每位成员都有不可替代的作用，每位成员在自己专长的领域中担当领导的作用。
清晰的责任和共同的职责
测试一下大家对这点的理解，如果你的团队中出现这样的问题，这样处理是否合适？
项目进度推迟、项目预算超出计划，公司领导把项目经理叫去，严厉的批评了一顿，而没有责备过任何其他项目成员。
软件发布出去后，发现严重的缺陷，公司领导把测试人员叫去严厉批评，也没有责备过任何其他项目成员。
你们的团队中，有没有这样的情况:
只有项目经理为项目的进度、预算劳心劳累，其他人都在“安分”地完成“本职”工作，不会主动过问其他情况。
出现问题时，谁是问题责任人的皮球会被踢来踢去，没有人愿意承担责任。
为什么有这样的问题呢？应该如何处理呢？是责任定得不够清晰吗？
团队的每一位成员，肩负起自己所在领域的责任，团队的每一位成员共同对最终解决方案负责，同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。
软件开发团队中，有项目管理、需求分析、设计、编码、测试等各个领域的人才，每领域的负责人对自己的工作负责。
另外一个方面，软件是团队共同劳动成果，所有人对最终的解决方案负责，最终解决方案只要有问题，就是整个团队的责任，最终解决方案取得优异成绩，就是整个团队的功劳。软件开发团队，是一个“一荣俱荣、一损俱损”的团队，只有这样才能把全部人的利益扭在一起。
了解了微软的这个原理后，大家对前面提到的问题是否有了答案？
关注交付的业务价值
客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子。看上去可笑，但这样的情况却经常发生在我们的身边。关注交付的业务价值，意思就我们工作中的每一份工作产品，都应该是需求驱动做出来的，这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思:
◆小组成员要对客户的需求有一致的充分的理解;
◆要让客户积极参与到项目过程中去，随时了解小组的理解和客户的需要是否一致;
◆需求驱动地完成所有工作，保证最后的软件产品符合客户的需要。
保持灵巧，预测变化
软件是智力型创造性活动，保持灵活、适应变化是软件开发的最高境界了，笔者认为这条原理是最难把握的一条了。
这个原理主要体现在以下方面:
软件开发过程
微软采用的不是RUP，也不是XP，而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布，除了平时我们见到的Beta版、Release版，其实在Beta版之前还会有若干的内部版本。
每个版本都包含相对完整的功能，都能实现部分业务价值。每一个版本就是一个开发周期，每个周期包含远景、计划、开发、稳定、部署五个阶段。这样的一种开发模型，能很好地适应需求变化，发现设计、编码缺陷，优化设计，更容易控制软件质量，便于随时做出商业决策。
设计方案
执着于优雅设计的人士，可能很喜欢做出完美无缺的设计，关注于业务的人士，可能更关注于尽快要拿出软件。我们追求的是适度设计，而不是过度设计，如何做出一个简单的而