微软解决方案框架(MSF) -- 八个基础原理

---来源于网络

九、MSF核心的八个基础原理

(一) 推动开放式沟通
在软件项目中有一个很明显的特点，那就是项目的成果或解决方案都是从事项目的团队的成员的智慧、能力和观点的结晶，这是与其他的工程项目很大的不同的地方。团队成员在做出自己的解决方法或做出自己的决定之前，必须对整个项目的目标、背景、目前的状态、各组件之间的关联、当前面临问题的关键、做出决定之后的影响等等方面的相关信息有一个很好的理解才能做出正确的、符合项目的决策或决定。所就是说对当前项目的深入理解是做出正确决定的基础。而传统工程类项目则不一样，它往往要求施工人员仅对他们自己所在的环节的一部分情况理解即可做出正确的判断，做出正确的决策方案。
所以在软件项目中为了将团队成员的个人效力最大化，同时优化团队成员的工作效率，关于软件项目的各方面的信息就必须随时可用，并且能够被积极共享。如果没有能够从多种渠道获取该信息的沟通方式或渠道，那么团队成员就无法有效地完成其任务，也无法做出正确的决策。“左撇子不知道右撇子在做什么”的情况在软件项目中的危害是十分巨大的，而且随着软件项目规模和复杂性的增加，这种危害的影响范围和破坏力也会随之剧增。
一个畅通的信息流不仅会减少误解和无用功产生的机会，还能够减少与项目相关的不确定性。MSF认为，在项目里可以采用任何形式来进行开放式和包容式的沟通。它是 MSF 小组模型的基本原理。开发式沟通会推动客户、用户等的积极参与。这种参与也通过将开方式沟通的概念融合到 MSF 过程模型中。
需要注意的一点是：完善的项目文档不可能取代开放式沟通所带来的好处。一来文档不管如何地完善，也不可能把项目中的一点一滴都详细记录在案。这样做不可能，也不经济;二来，文档交流少了快捷的特点，想一想，一个人把自己的想法进行总结、归纳，最终形成文档并发给一群人。接收文档的这一群人中各人都有自己的理解，而且这种理解很可能不相同，甚至相反。于是又要对自己的理解进行总结归纳形成文档反馈给原作者，这样原作者又要做出回应。如此下去，哪里来的效率？三来，完善的文档，意味着大量的文件数目。文件多了，就需要项目中的成员花费大量的时间来领悟文档中的内容。特别是文档中如果有错误或矛盾的地方，让人找不到北。但文档并不是绝对无用，只是在最需要文档的地方采用档，其他情况下要以开放式的沟通为主。
(二) 为共同的前景而工作
“共同的前景”是MSF小组和过程模型里的一个关键组件，它强调理解项目目标的重要性。当所有的团队成员都理解了共同的前景并为之而工作的时候，他们就能够通过这一前景来表达团队的目的，进而调整自己的决定和工作重点。MSF 过程模型要求有一个共同的前景存在，以便指导解决方案朝着最终的业务结果前进。没有这一前景，解决方案的业务价值就只会走向平庸。
项目的“共同前景”是小组工作的基础。建立这一前景的过程会有助于明确目标，减少并解决可能发生的冲突和错误。一旦达成一致，前景就会激励团队前进，并确保所有的努力都服务于项目目标。 “共同的前景”尽管很简洁，但它会描述业务的去向。拥有一个长期的前景会激励团队成员专注于事情当前的状态，取得应该取得的成果。
如果没有共同的前景，团队成员和利益相关人可能会在项目目标上产生分歧，无法形成一个具有凝聚力的团队。成员的努力如果不协调，就会浪费和削弱团队的成果。即使交付了软件成果，团队成员也将很难评估其是否成功，因为大家的目标不一致，评估成功的标准和方面就不一致。
这一点的运用与MSF团队模型结合地相对来说要紧密一些，基于过程式的、分层次的织组结构，要做到这一点，多少有些困难。
(三) 赋予小组成员权力
权力的赋予对 MSF 有着重要的影响。从MSF团队模型中可以看出，MSF团队模型建立在同级团队的概念之上。被赋予权力的团队成员认为他们自己以及其他每个人都对项目的目标和交付内容负有责任。团队成员都接受项目风险管理和团队就绪管理。因此能够预先就对这样的风险和就绪进行管理，以便尽最大可能确保项目成功。
MSF 主张从下到上的日程安排方法，这就意味着正在工作的人要承诺它会在什么时候被完成。这样做的结果就是一个能够得到小组支持的日程安排，因为小组相信自己。 MSF 团队成员确信，任何延迟都会在它们被发现的时候被报告，这样就让团队领导能够去扮演一个更具推动性的角色，从而在关键的时候提供指导和帮助。对过程的监视被分布在小组里，成为了一项支持性而非控制性的活动。
在目前的情况下，如果能做好有效的授权，这一点做起来并不难。
(四) 建立清晰的职责和共同的责任
MSF 团队模型是基于“团队里的每个角色都代表了对项目的一种独一无二的观点”这样一个前提。团队的每个角色都是负有责任的，以取得角色的高质量目标。从这个意义上讲，每个角色对于最终解决方案的质量都负有责任。同时所有的职责都要在小组的同级之间共同分担，因为任何小组成员都可能导致项目的失败。
团队中的各种角色相互依存的，原因有两个：1、需要这样，因为把每个角色的工作分隔开来是不可能的；2、出于优先的原因，因为如果每个角色都了解全局情况，那么小组的效率会更高。建立对职责和责任的充分理解会减少与“谁、什么、什么时候，以及为什么”相关方面的不确定性，其结果就是执行变得更加有效和回报也更高。
无法实现对项目职责和责任的清晰理解，常常会导致重复的工作或者交付内容的缺失。同样具有挑战性的是专制地运行项目，这样会扼杀创造性，将个人的贡献将到最低，并使小组失去权力。在人力投资是主要资源的技术项目里，这是失败的主要原因。
这一方面，如果能有效地分配各个工作岗位上的工作职责，也是容易做到的。
(五) 关注交付业务价值
通过把对业务价值的关注与共同的前景结合起来，项目小组能够清晰地理解为什么项目会存在，以及如何衡量成功。
MSF 团队模型主张“团队的决定应该以对客户业务的充分理解以及客户在项目过程中的积极参与”为基础。产品管理和用户体验这两个角色分别代表着客户和用户对团队的主张。
通过把注意力放在改进业务上，团队成员的活动将变得更有可能去做他该做的事情。尽管很多技术项目都把精力放在技术的交付上，但是技术不是为了技术本身而交付的，解决方案必须提供切实的业务价值。
(六) 保持灵巧，预测变化
传统的项目管理方法和“瀑布”式的项目管理模型会假定某一层次的可预测性，但这一点在技术项目里不是很常见。常见的情况是，技术项目交付的结果没有得到很好的理解，而需要不断地改变，最后改变成了项目的一部分。在面对这种不确定性的时候要假装或者要求确定性将会是不现实的，或者是不正常的。
MSF的一个基本假设是，连续的变化应该能够被预计到，而把解决方案交付项目与这些变化隔离开来是不可能的。例如，MSF认为项目要求可能从一开始就很难说清，而且它们常常会随着参与者把可能性看得越来越清楚而发生相当大的修改。
MSF 团队模型加强了处理新挑战的灵巧性。
近几年来，产生了一些开发软件的专门方法，这些方法致力于将灵巧性的原理和为变化而做好准备的原理最大化。有了这一理念，MSF 会鼓励在合适的地方应用这些方法。
(七) 质量投资
MSF 团队模型要求小组里的每一个人都要对质量负起职责，同时承担起测试过程管理的角色。测试角色会鼓励小组在项目期间进行必要的投资，以确保质量水平。在 MSF 过程模型里，由于项目交付内容是逐步生产和审查的，所以测试就成为了质量的一部分。
有效地提高质量就需要在过程、工具和质量指导方针上的不断投资。提高质量的所有努力包括定义一个过程，用来对成果进行详尽评估。
对提高质量的投资成为对人员以及过程和工具的投资。人们对质量的期望会随着时间的推移而不断提升，在原地踏步不是一种可行的选择。
(八) 学习所有的经验
MSF 认为，通过学习把精力放在不断提高上会带来更大的成功。从一个项目获取的知识能够成为下一个项目里其他人可以利用的东西，这样就会减少因为信息不足而造成的决策的不确定性。在 MSF 过程模型里对里程碑进行有计划的审查会帮助小组来进行中途的修正，避免重复（过去的）错误。此外，捕捉和共享这一知识可以从工作良好的事物中创造出最佳做法。
MSF 强调在组织或者企业这一层次从项目成果中学习的重要性，它建议对项目进行事后检查，将项目的成功之处以及对成功做出贡献的小组和过程的特点付诸于文字。
那些忘记过去的人肯定会重复过去（的错误）。
当你看到技术项目成功率的增长微乎其微的时候，当你认为失败的主要原因没有随着时间的推移而改变的时候，那么可能的情况是：在这样一个行业里，我们无法从（过去）失败的项目中学到教训。在资源有限、期限紧迫的情况下花时间去学习对于小组和利益相关人来说是很困难的，而要去证明其合理性则更困难。但是，不去从所有的经验中学习东西肯定会让我们重蹈覆辙，并自食其后果。

上面的每个原理都显示出了自身的优势，但是它们是一个整体，各个原理是相互依存的，因为其中任何一个原理的应用都对另外一个原理的成功起到了支持作用。在应用上述原理的时候，它们共同建立了一个稳固的基础，使得MSF能够很好地适用于各种不同的项目。
这些原理共同构成了一种“统一方法”的基础，传达了 MSF 观点。这一方法用来组织项目所需的“人员和过程”，以便交付技术解决方案。它们是 MSF 结构和应用的基础。