软过过程与管理学习之（2）Process Control（流程控制）

Process

• process 分为两种：

  • well-defined process
  • empirical process

• waterfall 的整个过程特点是：

  • 可知的（预先把所有的需求分析完成）
  • 按部就班的（每一步按照提前的计划进行）
  • 简单的（整个过程变数不多）

• agile 的流程特点是

  • 未知的（中途可能有很多变化）
  • 创新的
  • 复杂的

well-defined process 的流程控制

• 对一个 defined process 的开发，在理想情况下无论是哪个软件团队来开发，其最终形成的软件结果是一样的

empirical process 的流程控制

• 采用快速迭代的方式
• 期待 change
• 在每个 sprint 结束的时候进行总结，并决定下一个 sprint 如何进行

Defined vs Empirical

• defined 的 process 就如同流水线生产汉堡，所有的流程都是提前设定好的（defined），原材料按照流水线的方式一步步完成（steps），整个过程中不会出现更改的步骤。
• empirical 就像飞机从 A 飞向 B 起飞的时候并不知道天气的具体情况,遇到乌云的时候会适度调整躲避

process 和 项目管理 & 软件工程之间的关系

---

软件开发过程 SDLC 有多种不同的模型，其中包括 formal 风格的和 agile 风格的

Formal

formal 风格的 SDLC 有：

• waterfall

• incremental

• v-model

waterfall

优势

• 非常易于理解和使用
• 因为这个模型定义非常明确而且弹性很低所以也很容易管理
• 每次只能完成一个阶段的任务
• 每个阶段最后都能够得到相应的 documentation
• 当需求明确之后，后面的开发过程会非常稳定

劣势

• 对于改变很难适应
• 每个阶段只能完成一个任务，很死板无法并行
• 不明确的需求会导致整个开发过程陷入混乱
• 客户在最后一个阶段才进行审批
• 不确定性导致风险管理难以整合

Incremental model

• 将整个需求切分成几个部分（various releases) 然后每个分支都重复 waterfall 的步骤，这样增加了并行的工作，而且每个 waterfall 的体量也都更小

优势（对比waterfall）

• 每个分支交付一个可操作的产品
• 中途改变需求的成本降低
• 客户可以对每个分支的产品进行评价和反馈
• 初代产品的交付速度更快
• 客户可以提前获得重要的功能
• 在更小的迭代过程中，测试和debug 变得更容易

劣势（对比 waterfall）

• 需要更多的资源（可能组多个团队）
• 需要在管理过程中关注更多的部分
• 定义和对需求进行切分是一件困难的事情而且往往边界不清晰
• 迭代的每个阶段都是分开的，没有重叠
• 最后进行整合的时候可能出现问题

formal 方式适合哪种项目

• 客户对他们想要什么有非常清晰的看法的项目
• 几乎不需要需求改动的项目
• 软件需求被清晰地定义和记录
• 软件开发技术和工具是众所周知的
• 大规模应用和系统开发

agile

敏捷风格的 SDLC 有：

• scrum
• kanban
• extreme programming

为什么 agile 很受欢迎

• 因为几乎所有的事情都不是一成不变的，无论是什么领域都要面对 change
• 客户的需求和要求呈指数增长，产品必须不断交付和扩展
• 低技术成本、易于使用；全球市场增加了竞争，降低了进入壁垒
• 人才争夺战已经结束，我们输了!跨职能团队有助于减少潜在损失
• agile 可以将漫长的开发周期变成过去
• 不在最后验收才注重质量，而是一直注重质量
• 交叉职能团队很有趣

什么是 agile

agile 不是一种特定的模型，而是：

• 一种基于迭代开发的框架，其中需求和解决方案通过自组织的跨功能团队之间的协作演进

• 一个规制化的过程，鼓励经常检查和适应

• 一种鼓励团队合作、自我组织和责任的领导理念

• 一组工程最佳实践，旨在允许快速交付高质量的软件

• 将开发与客户需求和公司质量相结合的业务方法

agile framework

agile manifesto

12 principles

• 我们的最高优先级是通过尽早和持续交付有价值的软件来满足客户。
• 欢迎需求的变化，即使是在开发后期。敏捷过程利用变更来获得客户的竞争优势
• 频繁地交付工作软件，从几周到几个月，更短的时间框架是首选。
• 在整个项目中，业务人员和开发人员必须每天一起工作。
• 围绕积极的个人建立项目。给他们需要的环境和支持，并信任他们。
• 向开发团队传递信息以及在开发团队内部传递信息的最有效的方法是面对面
• 工作软件是进度的主要度量标准。
• 敏捷过程促进可持续开发。发起人、开发人员和用户应该能够无限期地保持恒定的速度。
• 持续关注卓越的技术和良好的设计可以增强敏捷性
• 简单——最大化未完成工作量的艺术——是必不可少的。
• 最好的架构、需求和设计产生于自组织的团队。
• 每隔一段时间，团队就会反思如何提高效率。然后相应地调整其行为。

kanban

Scrum

• scrum 是应用了 agile 思想的一种实现方式，agile 还可以体现在很多方面，但是 scrum 只是其中的一种方式； scrum 专注于在最短的时间内发布具有最高商业价值的产品
  

• 它使我们能够快速、反复地检查实际工作的软件(每两到四周)。

• 设置优先级，团队通过自组织的方式决定按照何种优先级发布最高价值产品

• 每 2-4 周，都可以看到实际的软件开发产品，然后决定是按照当前的样子发布还是在下一个 sprint 中继续提升
  

scrum 的关键特点

• self-organizing teams

在普通的 waterfall 或者 formal 的 sdlc 过程中，通常会采用一个全局的管理者为各个功能分配人员和任务，但是 scrum 的团队中大家自发地讨论决定项目的优先级，大家各自的任务分配和交付速度

• Product progresses in a series of focused sprints

用看板等任务管理工具将任务按照优先级划分成多个不同的 sprint 然后用最快的速度完成 sprint 的任务再进行下一个 sprint

• Requirements are captured as items in a list of product backlog

• Scrum is one of the agile processes - the one most widely used, discussed and debated

• Time frame is contained to a manageable size (weeks or months)

scrum 框架

sprint

• PO 要站在所有的角色的角度进行考虑，收集他们的需求，代表所有的 users ，负责填写 product backlog

  Backlog 不是针对某一个 sprint 或者一段时间的注意事项，而是整个项目持续过程中都应该注意的问题或者是对项目的整体规划

• 在每个 sprint 开始的时候，都要开会 sprint planning meeting；要根据 product backlog 确定这个 sprint 的 sprint backlog；在整个 sprint 的执行过程中我们不会改变 sprint 中规定的内容，如果到期 sprint 中的内容没有完成就移到下一个 sprint 中，我们通常不会延长一个 sprint 的时长也不会在一个sprint 的过程中改变或者扩展计划

• 每个 sprint 持续时间 1-4 周，按照 sprint backlog 上的任务进行开发，每天展开 daily scrum meeting 做完事情通过 burndown 或者 burnup charts 来记录；每个 sprint 结束之后要通过 sprint review 来进行反思

www.mountaingoatsoftware.com 可以查到更多有关于 scrum roles ceremonies artifacts 的信息

roles

• product owner

• 定义整个产品的特点
• 决定产品内容和发布时间
• 对产品的效益负责
• 根据市场价值决定产品开发过程的优先级
• 在每次 iteration 中调整产品的定位和优先级
• 接受或者拒绝工作结果（在 sprint 结束的时候决定按照当前的方向继续开发还是改变开发的方向和设计）

• scrum master

• 对项目进行管理
• 负责制定Scrum的价值和实践
• 消除障碍（需要更好的设备或者是开发工具）
• 确保团队的功能和生产力
• 支持所有角色之间的紧密合作
• 保护团队不受外部干扰
• 是Scrum团队的成员之一也是积极参与者（active participant）

• team

• 通常 6-9 名成员组成
• 构成人员涉及的能力是交叉的：程序员、测试人员、用户体验设计师、业务代表等。
• 参与者应该是全职的——有些例外
• 共同定位(物理或虚拟)——更有利于及时的沟通和协作

ceremonies

• sprint plannning

• 决定以何种方式完成当前的 sprint
• 根据 user story 和 product backlog 来指定当前的 sprint backlog
• 评估 sprint backlog 判断能在多长的时间内完成（这是一项比较困难的任务），是否超过了团队的能力负荷
• PO 制定的优先级来指导整个 sprint 任务
• 创建发布计划
• 顶层设计也需要在这个阶段完成

• Sprint planning meeting

• 前半部分会议讨论关于 what 的问题，即确立当前 sprint 的目标，应该做什么

• 写下来当前的 sprint goal

• 从 backlog 中确认能够达成 goal 的 item

• 后半部分的会议讨论 how 的问题，即确立应该通过什么样的具体方式完成当前的 sprint

  • 分解sprint backlog中的每个(特性)用户描述/大型用户描述，以获取所需的所有工作(描述点）
  • 用户故事构成了sprint 计划的基础，用于跟踪、成本和管理进度

• sprint review

• 团队表述这段时间完成的工作（之前哪些工作没有做到位，如今我们填补了这个空白，进行了一些工作，目前他正常运行）——向投资人和利益相关者展示
• 通常采用演示新特性或底层架构的形式
• 是一种非正式的会议
• 2小时准备时间规则：大家只准备 2 个小时，不要过度准备
• 不适用 ppt
• 所有的团队成员参加
• 不设限制

• sprint retrospective

• 定期看看什么是有效的，什么是无效的，下一个 sprint 中应该着重注意什么
• 通常 30 分钟
• 在每个 sprint 结束的时候进行
• 所有的团队人员参加
• 讨论：
  • 要开始某些行动（比如应该增加对代码的规范操作，代码回顾等）
  • 要停止某些行动（到目前为止表现出的一些不好的习惯：停止在每个 standup meeting 的时候讨论整个架构，因为这样很浪费时间且低效）
  • 继续保持某些行为

• daily stands-up

• 每天 15 分钟左右
• 不是为了解决问题的，而是确认哪些是当前阻挡团队和开发进度的问题，明确 user story 中的疑问
• 帮助避免了不必要的其他会议
• 可以问三个关键问题：
  • 昨天我做了什么
  • 今天我要做什么
  • 是什么阻碍了我完成工作

artifacts

• product backlog

• User story 其实就是用户需求，是从端用户或者 customer 的角度来撰写的
• 用户故事将重心从书写需求转移到谈论需求；这样可以不用像出一版用户需求分析花费那么长的时间
• user story 简介的从 customer 或者 user 的角度描述一个用户想要的功能，每条user story使用一个具体的模板来写

• 描述点是一种度量单位，用于表达对全面实现产品待办事项列表项或任何其他工作所需的总体工作的估计；因为在现实的 scrum 开发中，我们往往很难估计一个任务具体需要的时间是多少
• 故事点可以帮助估算在一个sprint中可以完成多少工作
• 使用描述点进行估算时，将为每个条目分配一个值。 原始值不重要，重要的是相对值
• 一个 point 为 2 的 story 应该是一个 point 为1 的 story 工作量的两倍。它也应该是 point 为 3 的 story 的三分之二。
• 除了分配给每个 story 的 point 为 1,2,3 这种值之外，团队还可以分配100，200和300。或者100万，200万，300万。重要的是比率（相对值），而不是实际数字

• sprint backlog

• Scrum团队在Sprint计划期间将用户故事分解为低级用户故事(拆分用户故事)
• 用户故事用于SME和开发人员之间的对话。开发人员用任务（tasks）更新用户故事和时间估算
• 剩余的估计项目每天更新
• Sprint Backlog 很少改变
• sprint中的用户描述要么100%完成，要么没有完成（具有原子性）因为已经具体到一个最小的用户故事；如果没有完成那么就移动到下一个 sprint 中

• burndown charts

• 燃尽图是剩余工作与时间的图形表示。
• 未完成的工作(或积压的用户故事)通常在纵轴上，时间在横轴上。
• 它被用来预测所有工作何时完成。
• 图中的例子：一开始规划了 10 天，但是在第 8 天的时候就完成了所有的任务

scrum 总结

https://www.youtube.com/watch?v=9TycLR0TqFA

agile 总结

优点

• 通过快速、持续交付可用的软件来满足客户需求
• 更强调成员的作用和互动行为，这些比工具更重要
• 持续关注技术的卓越，良好的设计和质量
• 适应不断变化的环境

缺点

• 很难评估一开始所需要的努力 （因为缺乏整体的需求和安排）
• 可能会占用用户大量时间(相比于传统方法)，因为会有和用户不定期的沟通以获得反馈
• 让新手难以融入（因为每个人都需要独当一面，新手没有经验很难胜任）
• 敏捷是一种非常不同的方法——它对团队来说可能很紧张（因为任务很紧而且很push）
• 需要有经验的资源(在今天的市场上是有限的，有经验的开发者是稀缺资源)

思维导图