对MSF八个原则的思考

第一个原则，也是MSF中最基础的一个原则，推动信息共享与沟通。这个原则的一个特点是，对于团队成员的所有工作，都会被记录下来，包括走了弯路的、出现bug但已调试解决的部分。对于新加入团队的成员或者以前没有参与过MSF开发的成员来讲，第一步便是要学会“不遮掩自己的错误”，因为每个人都是想要展现自己完美一面的，但是为了给团队成员提供经验，也为了真正实现信息的共享，已经提交的工作便不可删除。这让我想起第一次结对编程时因为不熟悉TFS的使用，误把自己的代码签入了服务器，当时还联系助教修改，但是助教说不行，现在我懂为什么不行了。

 

第二个原则是要求团队成员有共同的远景。作者对这个远景提出了三个要求：明确、通过努力实现和具有指导作用。这样的要求可以说是不仅仅适用于MSF的，几乎所有的远景，都应满足这三个要求。一个模棱两可的远景，或者把一个团队已经达到的成就当成远景，或者一个太空泛让人不知道该做什么的远景，都不利于项目的实现。然而对于项目的远景由谁提出，作者说应该由一个“有远见的人”提出，再交由大家讨论，这里的问题在于作者似乎没有过多讲述远景的提出基于一些什么样的考虑，用户需求？技术难度或者开发人员的水平？另外一个问题是在于，远景这样一个说起来很宏大的词，是怎么对软件开发过程起到如此重要作用的？

 

第三个原则讲的是团队人员之间的授权和信任。最吸引我注意的是对于团队事件安排的一个建议：由下而上地制定时间，由负责开发的成员自己拿捏时间表，这样做的好处在于提高了大家的主动性，由于是自己做的计划，应该就已经考虑清楚了开发中会遇到的问题，也考虑了自己的技术水平，那么自然比别人为自己定deadline的情形更有动力，这样的授权充分地考虑了个人因素在开发中的作用，确实是一个非常好的方法。那么作为项目的管理者，既然计划都是开发人员自己制定了，那么他做什么呢？作者看来，开发者要实时地跟进项目的进度，及时地位开发者提供技术上的帮助，比如通过组织学习解决一些新的技术问题等等，为了避免不能按时提交工作的情况，管理人员当然不能坐等验收，而是参与整个过程。最后一点，关于充分发挥团队成员的特长，也就是每个成员都能在自己擅长的领域担任领导者，带领团队其他成员在相关的工作中做得更好，这当然是充分授权和信任的表现。

 

第四个同第三个原则相互制衡。在第三个原则的最后，作者提出了一个问题：如何避免“授权与信任”之后，每个人都有很多想法，反而达不成一致意见了。第四个原则讲各司其职。核心就是每个人要对自己负责的项目负责，主要体现为哪个环节出现了问题，这个环节的负责人就要做出解释甚至承担相应的惩罚，我们在完成某个模块任务时，当然会询问他人的意见，他人也都会乐于给与我们帮助，但是他人提出的建议可能过于理想化，因为他不对这个任务的完成与否负责任，自然不能设身处地地思考，所以，只有将责任捆绑到开发者身上，才能督促上认真思考旁人的建议，认真决策，不会出现被旁人的建议牵着走而耽搁了进度的情况。而且，从另一个方面讲，我们在为他人提建议时，也应该注意一下建议的可行性，不要以一种旁观者的态度提出一些无意义甚至帮倒忙的建议。

 

第五个原则是我疑问比价大的一个原则。这个原则本身很简单，因为毕竟软件开发是一个商业过程，我们的大多数软件项目都是希望能盈利的，这无可厚非。然而是不是存在一些软件项目本身就不以盈利为目的呢？我的答案是肯定的，令人高兴的是，作者也提到了开源和闭源的问题，遗憾的是我并没有这么多知识储备，也找不到一个好的“闭源转开源”的项目来分析，不过在我看来，有的开源项目本身是出于更深层的一些终极价值发起的，具体是哪些终极价值在本文中也不便说明，我想表达的问题其实更像是通读本书的过程中贯穿始终的一个问题：本书是一本实战型的书，导致它的行文风格显得过于职场化，用我很讨厌的企业家、很欣赏的言说者罗永浩的话来讲，这也太没有情怀了。对于这个原则，开了一些玩笑，总结一下，我是想借此机会向一些伟大的开源项目致敬，向一些致力于为所有人提供公平的互联网服务的项目致敬，比如说基于Google Appengine的goagent项目组。

 

下一个原则是关于敏捷开发。这算是一个同我们软工的实践比较贴近的原则了，正巧我们最近就刚刚因为需求的变化对后面的计划做了相应的调整，把本来要做的一个比较有意思的功能给放弃了，因为下一个组用不上这个数据。作者说到了一个偏执追求质量导致软件跟不上客户需求变化的例子，这当然是对软件开发团队必须要平衡质量和需求的警示，目前我的体会还不深刻，但是这也是第一次比较学术地接触到软件开发的指导思想的问题，需要认真地学习。

 

后面的一个原则仍然和质量有关，准确地讲是和如何对待质量有关。质量当然是软件开发过程中最重要的一个交付条件了，你总不能给用户一个bug漫天飞的软件吧？那是不是开发者就必须要交付给用户一个没有bug的软件呢？答案尽管很直接，但确实是这样：不可能，在质量上耗费过多功夫就意味着在满足客户需求、提升用户体验等方面花费了少的功夫，而一个软件最重要的是解决用户的问题，如果能够解决用户当前的问题，就应该越早地交付，非要等到软件完美以后，可能就会出现上一个原则中的悲剧例子。所以作者把这个原则叫做投资质量，投资意味着质量不是最终追求，而是通过追求质量达到更大的目的：解决用户的问题。

 

最后一个原则是关于学习经验，我们也做了alpha阶段的事后诸葛亮会议了，而且这一个原则也贯穿我们的整个学习生涯，我也不再赘述了。