敏捷开发方法综述

      本周上课进度推进到敏捷开发，但是敏捷开发的内容是比较庞大的，课上的时间讲不了太仔细，否则将会花费太长的时间。由此我在网上查找了一些资料，进一步了解什么是敏捷开发：

 

      敏捷开发的定义：

      敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；

 

      敏捷开发的具体方式：Scrum和XP

      Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。下面具体介绍Scrum

 

       Scrum的定义：

       Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

      Scrum的框架：3个角色、3个工件、5个活动、5个价值

      3个角色：

        1、产品负责人（Product Owner）

        Product Owner 需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级。在每个Sprint开始之前，Product Owner可以修改功能需求和优先级。而且，Product Owner 有权决定接受或否决各个Sprint的工作成果。
    Product Owner 的角色通常由市场部门的人员或开发部门门内部主要使用该产品的人员来担任，主要工作是根据市场需求确定产品功能，将其列入Product Backlog中，并为这些功能确定优先级。
    Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
    在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，以及增加某些功能需求、删除某些功能需求、修改优先级等，但这些行为只能在各个Sprint之间进行。

       2、流程管理员（Scrum Master）

       Scrum Master的职责是：负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫清障碍；保证开发团队不受外力的干扰和阻扰；掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和 Sprint评审会议。
    Scrum Master 通常由传统开发中的Team Leader 来担当。

       3、Scrum团队        

       一般由5~10个能全职工作的成员组成较为理想。每个成员可能负责不同的方面。
        团队成员横跨各个职能，通常包括开发、测试、文档设计人员等。

 

    3个工件

        1、产品Backlog（Product Backlog）

       产品Blacklog是Scrum中的核心工件，它是对整个产品的功能描述，所有功能描述都是有顺序的排列，团队依照优先排列顺序进行工作。

       它是产品需求的唯一来源，开发团队所有工作都来自产品Backlog。

            （1）产品Blacklog由产品负责人创建和维护。

            （2）产品Blacklog贯穿于整个项目的生命周期。

            （3）产品Blacklog是一个有顺序的列表。

        2、SprintBacklog

        Sprint Backlog是当前Sprint完成的且梳理过的产品待办事项，包括了一个开发团队完成这些工作的计划。有了Sprint待办事项列表后，Sprint就开始了，开发团队成员按照Sprint待办事项列表来开发新的产品增量。

        在Sprint计划会议上，自组织团队在会议中生成Sprint Backlog。团队接受从产品Backlog挑选出要在本轮迭代实现的需求，将故事转化为具体的任务，每项任务落实到具体的责任人。

        Sprint Backlog中的每个项都是一个用户故事

        3、燃尽图（Burn-down Chart)

        Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。

       在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，Scrum     master 会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:
      1. 随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中。
      2. 程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作，这些也许可以分开进行跟踪。

    

   

     5个活动、

    （1）产品待办事项列表梳理

 

产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:

 

• 保持产品待办事项列表有序
• 把看起来不再重要的事项移除或者降级
• 增加或提升涌现出来的或变得更重要的事项
• 将事项分解成更小的事项
• 将事项归并为更大的事项
• 对事项进行估算

 

产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。需要考虑不少因素,这包括但不限于以下的内容:

 

理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。 开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。

 

产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。

 

    （2）Sprint计划会议

 

每个Sprint都以Sprint计划会议作为开始， 这是一个固定时长的会议，在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。

 

整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog),产 品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定 义”,为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时⻓的。Sprint计划会议推荐时⻓是Sprint中的每周对应两⼩时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议是限制时⻓长的,Sprint计划会议的成功⼗分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。

 

在Scrum中,Sprint计划会议有两部分:

 

1. 决定在Sprint中需要完成哪些工作
2. 决定这些工作如何完成

 

第一部分:需要完成哪些工作?

 

在会议的第一部分,产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作。

 

Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量。

 

通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于需要完成的工 作的本质,而不必花太多精力去关注那些对于我们需要完成的工作并不重要的⼩小细节。

 

第二部分:如何完成工作?

 

在会议的第二部分⾥里,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增 量。他们进⾏行⾜足够的设计和计划,从而有信心可以在Sprint中完成所有工作。头几天的工作会 被分解成⼩小的单元,每个工作单元不超过一天。之后要完成的工作可以稍⼤大些,以后再对它 们进⾏行分解。

 

决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

 

在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。

 

Sprint计划会议的产出 Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。 总而⾔言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。

 

最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

 

     （3）每日Scrum会议

 

开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。 这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息:

 

从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我的进展。

 

每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。通常,许多团队 会在每日Scrum之后⻢马上开会处理他们遇到的任何问题。

 

每日Scrum既不是向管理层汇报,也不是向产品负责⼈人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议,来保证他们对现状有一致的了解。只有Scrum团队的成员,包括 ScrumMaster和产品负责⼈人,可以在会议中发⾔言。其他感兴趣的⼈人可以来旁听。在必要时, 开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的⺫⽬目标。

 

每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助 快速发现问题,并促进团队的自组织和自⽴立。所有Scrum会议都是限定时⻓长的。每日Scrum通 常不超过15分钟。

 

     （4）Sprint评审会议

 

Sprint结束时,Scrum团队和相关⼈人员一起评审Sprint的产出。所有Scrum会议都是限定时⻓长 的,Sprint评审会议的推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint 包含2个星期,则Sprint评审会议时⻓长为2个小时)。

 

讨论围绕着Sprint中完成的产品增量。由于Sprint的产出会涉及到一些⼈人的“利益”,因此一个明 智的做法是邀请他们参加这个会议,这会很有帮助。这个会议是个⾮非正式的会议,帮助⼤大家 了解我们⺫⽬目前进展到哪⾥里,并一起讨论我们下一步如何推进。每个⼈人都可以在Sprint评审会议 上发表意⻅见。当然,产品负责⼈人会对未来做出最终的决定,并适当地调整产品待办事项列表 (Product Backlog)。

 

团队会找到他们自己的方式来开Sprint评审会议。通常会演⽰示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。

 

Sprint评审会议向每个⼈人展⽰示了当前产品增量的概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表。

 

     （5）Sprint回顾会议

 

在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时⻓长的,Sprint回顾会议的 推荐时⻓长是Sprint中的每一周对应一个小时(译者注:⽐比如,一个Sprint包含2个星期,则 Sprint回顾会议时⻓长为2个小时)。

 

Scrum团队总是在Scrum的框架内,改进他们自己的流程。

 

     5个价值

 

1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

 

注:本人是参考网上的资料进行的学习，参考资料有官方网站上进行的描述和定义，以及通过各位博主进行的更深层次的理解。并复用了各位博主的一些内容。