软件团队模式和开发流程

更新日志

软件团队的模式

主治医师模式（Chief Programmer Team，Surgical Team）

就像在手术台上那样，有一个主刀医师，其他人（麻醉，护士，器械）各司其职，为主刀医师服务。

这样的软件团队中，有首席程序员（Chief Programmer），他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。

在一些学校里，软件工程的团队模式往往从这一模式退化为『一个学生干活，其余学生跟着打酱油』。

明星模式（Super-star Model）

主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落之后任然能够保持？是这个模式要解决的问题。

社区模式（Community Model）

社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是『众人拾柴火焰高』，但是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。『社区』并不意味着『随意』，一些成功社区项目（例如开发和维护Linux操作系统的社区），都有很严格的代码复审和签入的质量控制。

业余剧团模式（Amateur Theater Team）

这样的团队在每一个项目中，不同的人会挑选不同的角色。在下一个项目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。

秘密团队（Skunk Work Team）

一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。这种模式的好处是：团队内部有极大的自由，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示，等等），团队成员有极大的投入。

特工团队（SWAT）

软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。

交响乐团模式（Orchestra）

想象一下交响乐团的演奏，有下面的特点。

• 家伙多，门类齐全。
• 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
• 演奏都靠谱，同时看指挥的。
• 演奏的都是练习过多次的曲目，重在执行。

当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会才去这种模式。

爵士乐模式（Jazz Band）

和交响乐团相比，这种模式有以下特点。

• 不靠谱。他们演奏时都没有谱子。
• 没有现场指挥，平时有编曲起到协调和指导作用。
• 也有模式，架构师先吹出主题，然后他走到一旁抽烟去了，其余人员根据这个主题各自即兴发挥，最后迈尔斯加入，回应主题，像是对曲子的总结。
• 人数较少。

功能团队模式（Feature Team）

很多软件公式的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。

在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。这些功能小组也称为Feature Crew，小组内的交流比较频繁。

每个小组都由一到三个人组成，每个小组都是一个有自主权的单元，可以自由选用最有利于他们完成工作的任何技术。但是，每个小组必须与其他小组就编码规范达成一致。

官僚模式（Bureaucratic Model）

这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。

这种模式如果应用不好，最后会变成『老板驱动』的开发流程。

<!-- more -->

开发流程

写了再改模式（Code-and-Fix）

这个流程不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。

• 『只用一次』的程序
• 『看过了就扔』的原型
• 一些不实用的演示程序

瀑布模型（Waterfall Model）

Rational Unified Process统一流程（RUP）

RUP 把软件开发的各个阶段整合在一个统一的框架里。

要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在 RUP 中叫做规程（Discipline）或者工作流（Workflow）。

业务建模

为用户提供软件，就要理解目前用户的业务流程，但是精通计算机语言细节的工程师并不能马上理解对用户活动和期望值的各种自然语言描述。为了解决这个问题，业务建模（Business Modeling）工作流用精确的语言（通常是UML）把用户的活动描述出来。这个工作流的结果通常是用例（Use Case）。

需求

有了用例之后，开发人员和用户要分析并确认软件系统得提供什么样的功能来满足用户的需求，功能有什么约束条件，如何验证功能满足了用户需求。这就是需求（Requirement）工作流的作用。

分析和设计

分析和设计（Analysis & Design）工作流将需求转换成系统的设计。这一步结束之后，团队成员就能知道系统有哪些子系统、模块，他们之间的关系是怎样的。

实现

在实现（Implementation）工作流中，工程师按照计划实现上一步产出的设计，将开发出的组件（Module），连同验证模块（例如：单元测试）提交到系统中。同时，工程师们集成由单个开发者（或小组）所产生的结果，通过手工或自动化的手段，把可执行的系统搭建出来。

测试

测试（Test）工作流要验证现阶段交付的所有组件的正确性、组件之间交互的正确性，以及检验所有的需求已被正确地实现。在这个工程中，发现、报告、会诊、修复各种缺陷，在软件部署之前保证质量达到预期要求。

部署

部署（Deployment）工作流的目的是生成最终版本并将软件分发给最终用户。

配置和变更管理

配置和变更管理工作流（Configuration and Change Management）负责管理 RUP 各个阶段产生的各种工作结果（例如源代码控制系统管理和备份各种源文件），要记录修改人员、修改原因、修改时间等属性，有些团队还可以考虑并行开发、分布式开发等。

项目管理

软件项目管理工作流（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功地在各个阶段交付达到要求的产品。

环境

环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括工程和工具。

RUP 把软件开发分成几个阶段，一个大阶段的结束称为一个里程碑（Milestone），每个阶段内可以有几个迭代，以比较灵活的形式实现本阶段的任务。从这一点来说，RUP在大尺度上像瀑布模型，在每个阶段内像迭代模型。

四个阶段：

初始阶段——此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里（我们的系统究竟和什么别的外部实体打交道），大致的成本和预算是多少，系统的风险主要来自哪里，成功度过初始阶段的项目会达到生命周期目标（Lifecycle Objective）里程碑。

细化阶段——它的目标是分析问题领域，建立健全的体系结构基础，编制目标计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板并准备工具。细化阶段结束时，项目达到了第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。

构造阶段——在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。此时的产品版本也常被称为『beta』版。

交付阶段——这时候，团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代（beta1，beta2等），团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。

渐进交付的流程（Evolutionary Delivery），MVP 和 MBP

当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的 evolution 循环中：

MVP —— Minimal Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。

具体的做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。例如：一个社交网站已经有很多用户，都是免费的，产品团队想设计一个付费的VIP服务，MVP的做法可以是这样——在目前的用户入口页面中加一个『VIP服务』的链接，指向一个简单的介绍页面。观察到底有多少用户点击这个链接。如果点击量太小，那么这个VIP服务就不用做了。

MVP的指导思想和渐进交付相似，但是它更强调更早获得用户反馈，为此可以在产品完成之前就发布，它也强调产品的核心价值（产品最区别与竞争产品的地方），为了突出核心功能，别的辅助功能可以不考虑或者用别的平台提供的服务来代替。

MBP —— Maximal Beautiful Product（最强最美产品）。如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，为何不把产品最全、最美的形态展现出来，一举征服用户。

敏捷流程

现有的做法 VS. 敏捷的做法

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷开发原则

1. 尽早并持续地交付有价值的软件以满足顾客需求
2. 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
4. 业务人员和开发人员在项目开发过程中应该每天共同工作
5. 以有进取心的人为项目核心，充分支持信任他们
6. 无论团队内外，面对面的交流始终最有效的沟通方式
7. 可用的软件是衡量项目进展的主要指标
8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
9. 只有不断关注技术和设计，才能越来越敏捷
10. 保持简明——尽可能简化工作量的技艺——极为重要
11. 只有能自我管理的团队才能创建优秀的架构、需求和设计
12. 时时总结如何提高团队效率，并付诸行动

Scrum 方法论

第一步：找出完成产品需要做的事情——Product Backlog

Backlog 翻译成『积压的工作』、『待解决的问题』、『产品订单』，都可以。产品负责人主导大家对于这个 Backlog 进行增/删/改的工作。每一项工作的时间估计单位为『天』。

第二步：决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog。

整个产品的实现被划分为几个相互联系的冲刺（Sprint）。产品订单上的任务被进一步细化了，被分解为以小时为单位。如果一个任务的估计时间太长（如超过16个小时），那么它就应该被进一步分解。订单上的任务是团队成员根据自己的情况来认领。团队成员能主导任务的估计和分配，他们的能动性得到较大的发挥。

第三步：冲刺（Sprint）

在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（Scrum Master）来完成。这一措施较好地平衡了『交流』和『集中注意力』的矛盾。有任何需求的改变都留待冲刺结束后再讨论。

冲刺期间，每天要开一个每日例会（Scrum Meeting），团队成员大多站着开会，所以又称每日立会。大家依次报告：

我昨天做了啥
我今天要做啥
我碰到了哪些问题

每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时启动每日构建，让大家每天都能看到一个逐渐完善的版本。

用简明的图表展现整个项目的进度，这个图最好放在大家工作的环境中，或者每天传达给各个成员。

也可以是简单的看板图：把一堆任务从最初的『待定』推动到『工作中』等各个状态，直至『完成』。

冲刺阶段是时间驱动的（Time-boxed），时间一到就结束。这个特点看似不起眼，但其实它有效地断了各种延期想法的后路，很高明。

第四步：得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

敏捷总结

敏捷对团队的要求很简单：自主管理（Self-managing）、自我组织（Self-organizing）、多功能型（Cross-functional），但是这很难做到。

与质量控制理论的模型如经典的戴明环（Plan-Do-Check-Act/Adjust，PDCA）类似。

Scrum 核心特点：

在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。

Sprint/Scrum 对项目的众多需求采取分而治之的办法，能让相关人员集中精力，在一定期限内解决部分问题。它强调短时间的迭代（Iteration、Timebox），在多次迭代中不断总结，改进团队的流程和产品功能。他明确地指出不同的人在一个项目中的投入和责任的不同，并坚持让全身心投入的『猪』来主导项目。它通过Daily Scrum、Scrum Master等方法和角色，鼓励团队内部交流，并优化团队和其他人员的交流方式。它对团队成员提出了很高的要求：自主管理、自我组织、多功能型。一般人不能马上做到这一点。它不是『银弹』，不能解决软件开发的所有问题。至于具体项目进度如何跟踪，如何管理测试工作，如何管理复杂项目，还是靠战斗在一线的团队成员见招拆招，想出合适的办法。

敏捷流程的经验教训

1. 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
2. Scrum Master 不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的『经理』变成 Scrum Master，大多行不通。
3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum 会把这些矛盾都摆在明处。这有好处，也有风险。
4. 在复杂的项目里，要让一线团队成员做决定。
5. 创业公司的团队其实经常是运行在 Scrum 模式中。
6. 在 Scrum 计划阶段的估计不是一个『合同』，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
7. 不要和管理层谈『流程』，他们只关心『结果』。
8. 在大型团队、跨地区的团队，或者复杂项目中，Scrum 并没有非常完美的答案，Scrum的创始人也承认这一点。