敏捷概述

微之风
441 阅读16分钟

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。

由此我们建立了如下四大价值观：

  • ✅个体和互动高于流程和工具；
    更加注重人的沟通，而不是用流程和工具；
  • ✅可工作的软件高于详尽的文档；
    写出再完善的文档，不如开发出好的软件；
  • ✅客户合作高于合同谈判；
    注重和客户合作来实现共赢，而不是像传统那样用合同谈判；
  • ✅响应变化高于遵循计划；
    敏捷就是拥抱变化，而不是循规蹈矩的按照计划执行；

敏捷开发宣言并不是说，不需要流程，工具，不写文档，不要合同，谈判，更不是没有计划，只是相对而言。只是以一种新的角度去看和新的方式去管理项目。

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷十二原则

  1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意；
  2. 欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化；
  1. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期；
  2. 业务人员和开发人员必须相互合作，项目中的每天都不例外；
  1. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以新人，从而达成目标；
  2. 不论团队内外，传递信息效果最好的效率也最高的方式是面对面的交谈；
  1. 可工作的软件是进度的首要衡量标准；
  2. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续；
  1. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强；
  2. 以简洁为本，它是极力减少不必要工作量的艺术；
  1. 最好的架构、需求和设计出自自组织团队；
  2. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷思维模式由价值观定义，以原则为指导，并在许多不同的实践中体现。

敏捷方法

是一个囊括了各种框架和方法的涵盖性术语。

敏捷是一个总称，包含符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。

敏捷方法和看板方法是精益方法的子集。它们都是精益思想的具体实例，都反映了诸如以下概念:“关注价值”、“小批量”和“消除浪费”。

精益

精益思想（现在）： 精益生产、精益设计、精益服务。

看板

心得

  • 敏捷首先是一种价值观，这体现在“敏捷软件开发宣言”中。
  • 敏捷软件开发方法最直接的特点体现在其与传统的瀑布开发的对比上。
  • 敏捷之所以好用、流行，是基于人们对软件开发的特点的认知，比如“需求不可预测”。
  • 敏捷的核心：
    1、基于适应而非预测。
    2、以人为导向而非过程导向。
    3、快速反馈。
  • 软件开发的特点，是所有“管理软件开发的方法” 的基础。敏捷之所以如此流行，就是它更适合软件开发。

项目生命周期

  • 预测型生命周期。这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。
  • 迭代型生命周期。这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。
  • 增量型生命周期。这种方法向客户提供各个已完成的， 可能立即使用的可交付成果。
  • 敏捷型生命周期。这种方法既有迭代，也有增量，便于完善工作，频繁交付。

迭代型生命周期

项目范围确定，但时间及成本随着项目团队对产品理解的不断深入而定期修改。
强调对软件的每一个功能时反复求精，提升软件质量的过程。

  1. 允许对未完成的工作进行反馈，从而改进和修改
  2. 按照版本发布
  1. 每个版本都是一个小瀑布
  2. 下一次迭代在本次基础上进行优化、升级

增量型生命周期

在预定的时间区间内渐进增加产品功能。
强调软件在发布不同版本时，软件功能数量渐增的过程。

  1. 每次构建一部分
  2. 向客户提供各个已完成的，可立即使用的可交付成果

区别

敏捷

  1. 需求易变
  2. 同时利用迭代和增量模型
  1. 固定迭代周期和资源
  2. 相关方持续参与

特征对比

混合型生命周期

  • 预研阶段，用敏捷去验证需求；
  • 正式开发阶段，用瀑布来加强计划性和控制力；

  • 软件部分，敏捷
  • 硬件部分，瀑布

敏捷的角色

敏捷教练

  1. 敏捷团队中没有传统意义上的项目经理，敏捷团队倡导自组织。
  2. 一般称为为“敏捷教练”。
  1. 提倡“仆人式领导”（服务型管理）。
  2. 仆人式领导按照以下顺序从事项目工作：

• 目的。与团队一起定义“为什么”，整个团队在项目层面而不是在人员层面优化。

• 人员。鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。

• 过程。不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价

值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。

敏捷教练的26项修炼

  1. A 即Advice（建议）：“我曾见别人做过。我觉得你们这样做效果更好。”

注：建议和引导，而不是命令和强迫，教练的作用就是引导，而不是简单的指手画脚。

  1. B 即Balance（平衡）：“别把好东西丢掉。”

注：易经的系统观是平衡，中庸的过犹不及也是平衡，项目经理最重要的技能之一就是平衡。

  1. C 即Celebration（庆功）：“嘿，上个迭代你们干的太棒了！”

注：随时随地的培训和引导，随时随地的一句话表扬，阶段和里程碑点的庆功会，保持团队士气。

  1. D 即Daring（勇敢）：“跟你们说，我豁出去了，是这样的……”

注：一个激情的团队一定是勇于承担责任，勇于面对挑战，勇于自我突破的团队。

  1. E 即Encouragement（鼓励）：“加油！这玩意很NB！”

注：责备使士气低落，鼓励使士气高涨。敏捷项目最重要的资产就是团队，团队最重要的就是士气。

  1. F 即Feedback（反馈）：“你有没有发现团队……？”

注：有了快速反馈的流程才是闭环的流程，有了反馈的沟通才是积极寻求改善和突破的沟通。

  1. G 即Guidance（引导）：“看上去我们有三种选择，我觉得前两种可能更好，你们觉得呢？”

注：一切众生皆有佛性。自性迷，佛即众生；自性悟，众生即佛。去激发每个人的潜能！

  1. H 即Humility（谦虚）：“实际上，活儿是大家干的，不是我。”

注：教练一定要勇于承担责任，时刻强调和发挥团队的力量。傲慢自大的教练在团队中没有容身之地。

  1. I 即Infectious（感染力）：“你得过来看看这个！”

注：团队教练，你有感染力吗？有人愿意追随你吗？

  1. J 即Jiggle（摇摆）：“这样调整一下，再那样调整一下。”

注：翻译为摇摆不太合适，应该理解为精益求精和持续改进。实践过程就是持续改进过程。

  1. K 即Knowledge（知识）：“你读过这本书/这篇论文/这个邮件列表了么？”

注：随时随地的知识传授，知识的共享和沟通，知识的转化和升华。

  1. L 即Listening（聆听）：“你说你想要做……”

注：团队教练的重点是沟通，而沟通首要学会的就是积极的倾听。

  1. 即Mentor（导师） : 让自己成为多余的人

注：导师的目标就是毫无保留的知识和技能的传授，最终形成自学习和自适应的团队。

  1. N 即Naysayers（怀疑论者）：“我不信”

注：有了怀疑，有了提问，才真正有了思考和改进，才保持了整个团的真正活动而不是僵化执行。

  1. O 即Obligated（担当）：“团队中的一部分”

注：一个真正的管理者一定是勇于担当的。

  1. P 即Principles（原则）：“不要只看到现象，还要看清本质。”

注：没有规矩不成方圆，时刻牢记敏捷团队更加强调纪律。

  1. Q 即Questioning（提问）：“你看到了什么？感觉如何？”

注：有了怀疑，有了提问，才真正有了思考和改进，才保持了整个团队的真正活动而不是僵化执行。

  1. R 即Retrospectives（回顾）：“我们学到了什么？哪些东西我们会继续坚持？”

注：有了回顾和复盘才有了真正的闭环持续改进的流程，虽然现在有可能离你期望的目标还很遥远，

但是你必须要看到整个团队一天天的在进步。

  1. S 即Sensitive（敏感）：“我在想他们是不是已经准备好……”

注：优秀的教练需要有敏锐的洞察力，充分发挥你的嗅觉，听觉和各种感觉器官。

  1. T 即Transparency（透明）：“我希望你可以这样试试看，因为我觉得这有助于你……”

注：开诚布公，不搞暗箱操作。

  1. U 即Unlock（释放潜能）：“我没想到这团队还能办到这些！”

注：每个人有无限潜能，团队也有无限潜能，关键是如何激发出来。

  1. V 即Vocabulary（词汇）：“YAGNI？Burn up？Muda？”

注：一个能够密切配合，高度协作的团队必须在前期有通用词汇表。

  1. W 即Welcoming（接纳）：“你们觉得我们应该怎么做？”

注：勇于聆听和接受各种建议，开发和包容的心态。

  1. X 即Xenodochial（友好）：“对陌生人友好”

注：勇于聆听和接受各种建议，开发和包容的心态。

  1. Y 即Yarn（讲故事）：“从前啊……”

注：形成团队文化，而故事是团队文化的良好传播途径。

  1. Z 即Zen（禅意）：“你必须找到自己的路”

注：不要期望完全照搬别人的路，你必须要找寻到一条适合自己的路。

敏捷团队

成功敏捷团队的属性：

产品负责人PO

  • ✅负责指导产品的开发方向。
  • ✅根据商业价值对任务进行排序。
  • ✅与团队开展日常合作，提供产品反馈，为将要开发/交付的下一个功能设定方向。
  • ✅与相关方、客户及团队合作，定义产品开发方向。
  • ✅通常，产品负责人拥有相关工作背景，会为决策提供丰富的专业知识技能。
  • ✅产品负责人将为团队创建待办事项列表，或者与团队共同创建。待办事项列表帮助团队了解怎样在不产生浪费的情况下交付最大的价值。

敏捷下的项目管理

需求管理

用户故事

定义：用户故事描述对用户、系统或软件购买者有价值的功能。

Epic

可以认为就是一个大的Stroy, 还没有拆解, 是对大Story的一个描述性标签;

Theme

可以认为是一组Story, 有相似特性的一些Story的集合。

Stroy

As a I <want/can/am able to/need to/etc.> so that .

即,言简意赅的描述清楚需求;

产品待办事项列表Product Backlog

  • ✅产品需求的列表
  • ✅包含业务需求、技术需求、NFR等
  • ✅理想情况下，每一个待完成的工作都将对客户产生价值
  • ✅PO对该列表进行优先级排序
  • ✅每个迭代开始前，优先级排序还需要再度修正
  • ✅待办事项列表中的条目以用户故事的形式呈现一组产品需求列表

故事的优先级- MoSCoW

  • Must 必须有——这些需求是强制性的。
  • Should 应该有——这些需求不是强制性的，但是高度渴望的。
  • Could 可以有——这些需求如果满足会很好。
  • Won’t 不会有——当下可以不去满足，但是将来可以加入。

卡诺KANO模型

  • 对用户需求进行分类和优先顺序排序；
  • 以分析用户需求对用户满意度的影响为基础；
  • 反映产品各个属性和用户满意度之间的非线性关系；

KANO模型的适用性

  • 适合定义功能重要性与优先级。
  • 适合用于处于运营阶段的产品：首先，有一批相对稳定的玩家群体，他们对游戏有了一定的理解；其次，运营中的游戏发出问卷可以通过游戏活动进行，成本较低。
  • KANO模型作为一种思考工具，可以让我们在工作中更好地区分哪些设计点的优先级高，哪些功能更有价值，把时间花在刀刃上。

进度管理

估算

  1. 故事点Story Point：是描述一个用户故事及其相关努力总体规模的测量单元。
  2. 故事规模取决于以下因素：复杂性、投入量、风险大小。
  1. 故事点是规模的相对测量，绝对值不是很重要。
  2. 基线选择相对较小，而不是绝对小的。

扑克估算

  1. 斐波那契数列；
  2. 每个团队成员收到有编号的卡片，如果需要数字可以延伸；
  1. 产品负责人朗读每个故事卡片并回答团队问题；
  2. 每个团队成员评估故事所需投入以及运用相对尺码给故事分配点；
  1. 当Scrum Master要求时，每个人必须同时举起写有他们估算的数字卡；
  2. 如果这里有差异，团队成员要解释估算偏高或偏低的原因；
  1. 讨论后，团队成员重新估算直到达成一致；

看板kanban

燃尽图

展示剩余工作量曲线。展示了时间和项目剩余总体工作量间的关系。

燃尽图作为敏捷可视化管理的工具，发挥着重要的作用。一叶知秋，作为敏捷教练应当能够从每一张图表、每一条折线，分析出项目背后的问题，防范于未然。燃尽图的数据来源于日常工作，出自于团队本身。所以数据的准确性，直接决定了燃尽图的价值。

燃起图

它能够直观展现项目时间与已完成的工作间的关系的一种图表，根据每天完成的story情况动态展现工作成果的曲线。因为燃起图可以区分不同角色展现工作量完成状况，更易跟踪和理解，所以目前各个项目应用更广泛的是燃起图。

敏捷实践

3355

3种角色：

  1. Product Owner（PO）
  2. Scrum Master（SM）
  1. Developers

3种工件：

  1. 产品Backlog
  2. 迭代Backlog
  1. 产品增量Product Increment

5种仪式：

  1. 迭代Sprint
  2. 迭代计划Sprint Planning
  1. 每日站会Daily Scrum
  2. 评审会议Spring Review
  1. 迭代回顾Sprint Retrospective

5种价值观：

  1. 承诺
  2. 专注
  1. 开放
  2. 尊重

  1. 勇气

  2. Scrum Team 致力于达成其目标并且相互支持。

  3. Scrum Team主要关注点是Sprint 的工作，以便尽可能地向着这些目标获取最好的进展。

  1. Scrum Team 及其利益攸关者对工作和挑战持开放态度。
  2. Scrum Team 成员相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的
    人的尊重。
  1. Scrum Team 成员有勇气做正确的事并处理那些棘手的问题。

三种角色

PO：
PO的职责是将开发团队开发的产品价值最大化。

PO是负责管理产品待办列表的唯一负责人：

• 开发并明确地沟通Product Goal ；

• 创建并清晰地沟通Product Backlog 条目（items）；

• 对Product Backlog 条目进行排序；

• 确保Product Backlog 是透明的、可见的和可理解的；

敏捷教练：

  1. 作为教练在自管理和跨职能方面辅导Scrum Team 成员；
  2. 帮助Scrum Team 专注于创建符合Definition of Done的高价值Increment；
  1. 促使移除Scrum Team 工作进展中的障碍；
  2. 确保所有Scrum 事件都发生并且是积极的、富有成效的，并且在时间盒（timebox）内完成。

团队：

  1. 开发团队包含各种专业人员，负责在每个Sprint 结束时交付潜在可发布并且“完成”的产品增量。
  2. 经典团队拥有5-9 人。

三种工件

Product Backlog ：

一份涌现的和有序的清单，它列出了改进产品所需的内容。它是Scrum Team所承担工作的唯一来源。

Sprint Backlog：

由Sprint Goal （为什么做）、为Sprint 选择的Product Backlog 条目（做什么）以及交付Increment 的可执行计

划（如何做）组成。

Product Increment：

团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付。

五种仪式

  1. Sprint：Sprint 是固定时长的事件，为期一个月或更短，以保持一致性。前一个Sprint 结束后，下一个新的Sprint 紧接着立即开始。
  2. Sprint Planning： 通过安排在Sprint 中要做的工作来启动Sprint。最终的计划是由整个Scrum Team 协作创建的。
  1. Daily Scrum：每天15分钟的站会：昨天你做了什么？今天你将要做什么？你有需要帮助的地方吗？
  2. Sprint Review： 目的是检视Sprint 的成果并确定未来的适应性。Scrum Team 向关键利益攸关者展示他们的工作结果，并讨论Product Goal 的进展情况。
  1. Sprint Retrospective：目的是规划提高质量和效能的方法。
avatar
文章
阅读
粉丝