读书笔记——《构建之法》

《构建之法》

——读书笔记

前言

　　　　谢谢大家能来看我的博客，这是我第一次写博客，大概也会石沉大海吧。但我会逐渐成长，写出更优秀的博客。

　　　《构建之法》一书面向初级程序开发者，讲述个人开发、小组开发、团队开发中所要注意到的问题。有助于本学期软工课程的机会，我第一次能够担任一个较大小组（8人）的组长，

并带领大家完成自己的小项目。但我深知自身的管理知识是非常贫乏的，又因本书章节很多，所以我特别挑选了几个章节借鉴经验，并且遴选了最有意义的两个章节将精华部分记录下来与大家

分享。

 

正文

第5章团队和流程

　　　　　　团队模式问题是由人数渐增而产生的，2、3人的团队大多不需要多少事前规划就可以没有多少冲突地将事情解决，而人数渐增所带来的角色、任务分配问题几乎无法避免。然而各种团队模式和开发流程都是

　　优劣并存的，如何选择取决了我们所要处理的问题以及队员们的水平。

　　1、团队模式：软件团队有各种形式，适用于不同的人员和需求，有几种较为流行的模式及其优劣如下：

　　（1）主治医生模式：首席程序员负责处理主要的设计和编码，其他人从各个方面协助其工作。

　　　　　　优：最大限度发挥首席程序员的能力。

　　　　　　劣：“明星”也是人，也会受伤、犯错误。

　　　　　　评：如何让团队的利益最大化，而不是“明星”的利益最大化？（IBM SYSTEM 360）

         （2）社区模式：由许多志愿者参与，每个人参与自己感兴趣的项目，大部分人不拿报酬。

　　　　　　优：众人拾柴火焰高。

　　　　　　劣：如果大家不愿拾柴或柴火质量差，最后火就灭了。

　　　　　　评：成功的社区项目需要很严格的代码复审和质量控制。（Linux操作系统）

         （3）秘密团队模式：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。

　　　　　　优：团队内部有极大自由、较高热情、较少外界干扰。

　　　　　　劣：士气会随着时间推移而下降。

　　　　　　评：若发挥得好，很大的驱动力能让团队发挥超高的效率。（苹果研发Macintosh之后的系统）

         （4）交响乐模式：某个软件领域处于稳定成长阶段的时候，许多大型开发团队会采取。

　　　　　　优：门类齐全、各司其职。

　　　　　　劣：进行的都是很有经验的项目。

　　　　　　评：适合大规模的，有明确任务细分的软件工程。（Office97~2013…）

　　　（5）功能团队模式：具备不同能力的同事们平等写作，共同完成一个功能（Dev、UX、AQ、PM）。在一个功能完成后，这些人又重新组织，共同完成下一个功能。

　　　　　　优：每个小组都是一个有自主权的单元，自由度高而带来了开发时的高效。

　　　　　　劣：零散的小团队就要求团队间需要频繁的交流，从而一定程度上降低效率。较高的自由度不适用于一些等级制度森严的公司。

　　　　　　评：很多公司最后都会演变为这一模式，能充分利用每一个人的能力，整体团队分工又不死板。（FORTRAN语言项目）

　　2、开发流程：一群人一起开发软件，必定需要有一定的流程，否则一窝蜂地毫无章法地干，最后有可能做成，但也是一堆没有意义的程序。开发流程的选择关乎到软件开发的效率、容错程度、开发周期、对风险的规避能力。

　　　　（1）瀑布模型：将硬件开发领域的分析->设计->实现->销售->维护运用到了软件工程中，先有一个模拟版本，在此基础上收集反馈，再走一次流程，最后交付最终版本。

                   优：  1）各个阶段非常明晰，更容易把握项目的进展。

                            2）不需要频繁的交流。

                   劣：  1）最终产品出现过晚，各个阶段相互独立，难以应对客户变化的需求。

                            2）各个过程难以回溯，但软件生产过程中需要时时回溯。

　　　　　 评：适用于客户要求非常稳定、技术人员较为分散、团队成员对所用的技术非常熟悉的情况。

         2）统一流程：在系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中：【开发->发布->听取反馈->根据反馈做改进】。为了早日听取客户的意见，把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。

                   优：1）能尽快地听取客户的意见，及时纠正软件开发的走向，规避风险。

                   劣：1）不适用于创造性、颠覆性的技术开发。

                            2）过早地发布可能带来更激烈的商业竞争。

　　　　　 评：这是很实用的流程，尤其适用于高校内尚不成熟的学生在规定时间内开发代码，不断地更新换代保证了时刻有可以交付的版本。当然这不是说就不适用于大企业的开发，微软的MSF模型正是来源于这一构想。

第7章 实战中的软件工程

　　　　分析实战中的软件工程，莫过于分析最成熟的大公司的开发过程。本章选取了经典的微软公司的MSF模型进行分析，从它的基本原则、团队模型、过程模型入手，描述了微软开发团队内的开发精神、开发方式、开发过程。

　　　基本原则：

         一、推动信息共享与沟通：

　　　　　　1、  在整个软件生命周期中使用团队协作服务器（GitHub或TFS），推动信息共享。

　　　　　　2、  借助于以上平台，团队成员之间的交流简明扼要即可。

　　　　　　3、  保留并公开所有的信息，以便让项目进度和项目中存在的问题及时为所有人知道。

         二、为共同的远景而工作：

　　　　　　1、  在设定项目时，所有成员需要明确项目的预期目标，统一思想，否则团队内的分歧会随时间而累加，对项目的发展是很有害的。

　　  三、充分授权和信任：

　　　　　　1、  微软的MSF团队模型就是建立在两个原则之上：1）平等协作2）充分授权给团队和成员。

　　　　　　　　优：每个人都有权利估计并决定自己的任务需要的时间，所以人人都会支持计划和时间表。

　　　　　　　　劣：充分的授权可能会导致倦怠的滋生，不停地追踪会加重主管的负担。

　　　　　　　　评：在团队工具VSTS的帮助下，所有工作的进展都记录在案（这也是要推动信息共享的原因），任何延迟都会被及时发现。当然授权的管理理念又和一些集权类企业格格不入。

         四、重视商业价值，提供渐进的价值：

　　　　　　1、  首先，团队需要明确　　1）产品解决的问题　　2）为谁解决问题　　3）为什么你的产品能解决这些问题　　

　　　　　　　　　　　　　　　　　　4）客户怎样付钱让你解决问题。因为项目需要重视市场和客户，技术是处于第三位的。

　　 五、重视商业价值需要保持敏捷，预期和适应变化

　　　　　　1、项目需求的生存期是有限的，一旦开发过久，需求可能已经发生了很大的变化，而一个经验值是18个月。

　　　　　　2、客户的需求也是会变化的，我们需要预期变化而不是期望变化，这对开发流程和团队模式也带来了挑战。

　　 六、在变化中需要抓住投资价值

　　　　　　1、投资讲究效率。我们并没有提质量第一，而是解决用户的问题第一，不惜一切代价达到最高质量往往错过了最佳的发布时机，而大型项目发布后追踪式的修补也是允许的。

　　　　　　2、投资讲究时机。为了尽量在产品中减少上述中的bug，1）在构想时充分讨论各种可能缺陷  2）发展与测试应该并行发展  3）为迎合客户的时间需求，可以有针对性地取舍功能。

　　七、投资是长期的。

　　　　　　1、团队的成长、成熟需要时间，生搬硬套大公司的开发模型与团队构成大多是南橘北枳。

 

　　　　团队模型：

　　　　　在MSF团队模型中，每一个部分都是非常重要的，任何一个角色无法实现其目标都会危及整个项目。这也和微软内部的理念相契合，即：每个成员之间都是平等的。

　　　　　这样的团队中，需要的是直言不讳，例如为了团队方案的争吵、因为产品质量而不赞同增加功能，每个人都参与设计规划、具体执行是指导思想，在对立中寻找共同利益，在冲突中达到平衡是团队的目标。

 

　　　　MSF过程模型

　　　　　每一个项目都要经过一个生命周期，图示是MSF过程模型的生命周期简图，它吸收了瀑布模型基于里程碑的规划优势和渐进式交付的不断完善的长处。

 　　　　　　　　优势：里程碑式的规划：团队里用里程碑来检查工作和同步各个角色的进度。

                     　　　　　　渐进式交付的不断完善：利于尽快交付产品，获得内外反馈。

　　　　　　　　劣势：各个阶段并不是理想化的，但可以通过设置缓冲区，不需要强求一律，但可以通过统一整体步骤，从而调节好团队间的依赖关系。

　　　　　　　　评：这是一个内外兼顾的模型，既考虑了外部的客户因素，又考虑了内部的成员间相互依赖的关系。