敏捷开发四大宣言解读_敏捷开发四大宣言 - CSDN
  • 敏捷开发宣言

    2017-03-03 16:53:22
    敏捷开发宣言:  1. 个体和交互胜过过程和工具  2. 可工作的软件胜过面面俱到的文档  3. 客户协作胜过合同谈判  4. 响应变化胜过遵循计划  从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行...
        敏捷开发宣言:
          1. 个体和交互胜过过程和工具
          2. 可工作的软件胜过面面俱到的文档
          3. 客户协作胜过合同谈判
          4. 响应变化胜过遵循计划
          从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化
    展开全文
  • 敏捷宣言的简单介绍

    2019-06-23 23:23:47
     敏捷宣言(Manifesto for Agile Software Development),也叫做敏捷软件开发宣言,正式宣布了对四种核心价值和十二条原则,可以指导迭代的以人为中心的软件开发方法。敏捷软件开发关注保持简洁的代码,经常性测试...

     

    一、什么是敏捷宣言?

      敏捷宣言(Manifesto for Agile Software Development),也叫做敏捷软件开发宣言,正式宣布了对四种核心价值和十二条原则,可以指导迭代的以人为中心的软件开发方法。敏捷软件开发关注保持简洁的代码,经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程,例如瀑布式方法。

    二、敏捷宣言的诞生

      2000年9月,来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议,时间是2001年1月或2月,地点在芝加哥,目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来,请告诉我。”

      2001年2月11日到13日,17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟(Snowbird)雪场。经过两天的讨论,“敏捷”(Agile)这个词为全体聚会者所接受,用以概括一套全新的软件开发价值观。这套价值观,通过一份简明扼要的《敏捷宣言》,传递给世界,宣告了敏捷开发运动的开始。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

    三、具体内容

    (一)官方网站

      点我咯

    (二)四大核心价值[1]

    个体和互动 高于 流程和工具
    工作的软件 高于 详尽的文档
    客户合作  高于 合同谈判
    响应变化     高于 遵循计划

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

    (三)十二原则[1]

    我们遵循以下原则:

    1、我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

    2、欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

    3、经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

    4、业务人员和开发人员必须相互合作,项目中的每一天都不例外。

    5、激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

    6、不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

    7、可工作的软件是进度的首要度量标准。

    8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

    9、坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

    10、以简洁为本,它是极力减少不必要工作量的艺术。

    11、最好的架构、需求和设计出自自组织团队。

    12、团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    四、解读[4]

    (一)四大核心价值的解读

    1、个体与互动高于流程和工具 

      这意味着虽然流程和工具重要(尤其是大型组织),但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。

    • 当我们开发产品、解决问题或改进工作方式时,我们要寻找改进互动和提高能力的方法
    • 在项目期间,产品管理和开发团队必须在一起工作
    • 在项目期间,架构师、设计师和测试人员必须每天在一起工作
    • 面对面沟通是极其重要的,它不能被其它形式完全替换

    2、工作的软件高于详尽的文档 

      这意味着已集成、已测试、潜在准备发布的产品才是关键度量,它能够有效地跟踪项目进度和对发布做出决策。

    • 要以小步增量的方式构建产品:做一些分析、设计,然后开始编码和测试以验证设计
    • 设计需要做,比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员,简易文档还是必要的
    • 好架构是持续开发产品的关键,架构是设计出来的,建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移,架构会演进,所以持续追求卓越技术和好设计能够增强产品敏捷性。

    3、客户合作高于合同谈判 

      这意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系,而不是靠公司内的正式接口。

    • 在实践中,意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
    • 在与我们自己的业务方合作中,我们应该寻找开发期间增进和改善合作的方法。
    • 产品管理和开发应该密切合作,而不是通过契约或手续。

    4、响应变化高于遵循计划 

      这意味着欢迎需求变化,哪怕是开发后期。

    • 首先,预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
    • 如果我们对客户需求变更做的好,我们就会增强客户的竞争优势还有我们自己。
    • 为了鼓励响应变化并使其更容易操作,需要建立流程和工作方式。承认计划的不确定性
    • 计划是必要的,但计划必须适应变化:我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时,我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。

    (二)十二原则的解读

    1、我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

      客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值,这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。

      尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好,至少我们应该给我们客户一个选择。

    2、欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

      我们的目标是为了开发能够帮助客户提升价值的产品,要支持任何变化。变化不是一种否定,它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。

    3、经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

      开发周期和发布周期完全不同。尽管有发布周期,但我们的目标是短开发周期。发布周期的长度依赖业务决策,并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍,增加了敏捷性和灵活性。   

    4、业务人员和开发人员必须相互合作,项目中的每一天都不例外。

      只要在业务和研发之间建立起桥梁,我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合?我们需要作出睿智的决策

    5、激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

      知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力,自由是最重要因素。要让角色去适应人而不是让人去适应角色。   

    6、不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

      面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时,信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈,将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。

    7、可工作的软件是进度的首要度量标准。

      跟踪有多少功能已经实现,集成,测试是一种更可靠的进度度量。   

    8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

      目标是为了消除高负荷工作并保持可持续的速度工作(例如,不加班工作)。质量问题通常牺牲长期收益,人们越是疲劳创造力就越低。因此可持续开发吧!   

    9、坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

      任何技术负债(代码缺陷、架构缺陷)都会使开发减慢。我们不应该让技术负债积压,所以要持续地做重构,更改发现的缺陷,持续关注实现架构的质量。

    10、以简洁为本,它是极力减少不必要工作量的艺术。

      这种简单原则既适用于产品的功能特性也适用于流程。多余的功能不要增加。所有流程步骤应该时刻面临挑战(例如,这步真的需要吗? 谁会读这个文档?…)。  

    11、最好的架构、需求和设计出自自组织团队。

      架构、设计和需求会随着团队一起工作慢慢浮现,并且团队会从中学到很多。一些前置需求、架构和设计工作是需要的,但是不能把它们定义在纸面上传递。架构师和系统工程师是自管理研发团队的一部分,不要成为“孤岛”。

    12、团队定期地反思如何能提高成效,并依此调整自身的举止表现。

      花时间反思和从经验中学习能够促进持续化开发。因此“检查与调整”是敏捷核心实践之一。

    五、背景和意义

       Kent Beck分享了他早年的一次亲身工作经历。当时他估算的开发工作量是2个人做6个星期。结果在项目开始的时候,经理临时换了另一个人和他一起工作,最后他们花了12个星期才完成项目。他的感觉很糟,因为在后面6个星期中间,经理一直喋喋不休,嫌他太慢。Kent有点沮丧,觉得自己作为一个程序员实在是太失败。到最后,他终于意识到最初2个人做6个星期的估计其实是相当准确的。这不是他的失败,是管理者的失败(指临时换人这件事),实际上是那些持续祸害着我们这个行业的,所谓标准化、流程化的“僵化”头脑的失败。

       同样的事情每天都在重复发生。市场人员、经理、外部客户、内部客户,当然,也包括开发人员,谁都不想难为自己,去做出那些艰难的、需要折衷的决定。于是他们利用组织的权责划分将难题转嫁给他人,甚至提出荒谬的要求。这不仅仅是软件开发的问题,而是无处不在。

      先写到这吧。

    参考

    [1]  敏捷软件开发宣言-简体中文 2016/09/15  http://agilemanifesto.org/iso/zhchs/manifesto.html

    [2]  51CT0博客-历史:敏捷宣言诞生记 2016/09/15  http://davidzhang33.blog.51cto.com/3095817/1103860/

    [3]  TechTarget中国-敏捷宣言:四大核心价值和十二原则 2016/09/15 http://www.searchcio.com.cn/showcontent_54322.htm

    [4]  推酷-敏捷宣言及原则解读 2016/09/15 http://www.tuicool.com/articles/ziqIN3Y

    [5]  CSDN博客-敏捷宣言思想认识误区 2016/09/15 http://blog.csdn.net/youcharming/article/details/41865893

    转载于:https://www.cnblogs.com/super-zhang-828/p/5874386.html

    展开全文
  • 本文来自作者 glenwang 在 GitChat 上分享 「图解精益敏捷的逻辑与实证:设计您自己的工作方式」,「阅读原文」查看交流实录。「文末高能」编辑 | 哈比摘要回放精益敏捷的书籍已如汗牛充栋,但又没有给人一个...
        

    640?wx_fmt=gif&wxfrom=5&wx_lazy=1

    本文来自作者 glenwang  GitChat 上分享 「图解精益敏捷的逻辑与实证:设计您自己的工作方式」,阅读原文查看交流实录。

    文末高能

    编辑 | 哈比

    摘要回放

    精益敏捷的书籍已如汗牛充栋,但又没有给人一个明确的产生画面感的扎实理解。本文对精益敏捷的基本定义如下:

    • 一种工作方式;

    • 跟人和组织相关;

    • 其目的是达成组织的目标;

    • 以敏捷四价值观和精益五原则为核心基础。

    本文基于作者十余年管理和教练经验,总结软件开发管理中各个敏捷实践的逻辑:

    • 发生作用的原因;

    • 行得通的条件;

    • 达到的效果。

    业务有架构、技术有架构、工作方式也有架构。文章脉络大致参照 PMBOK 的组织方式:五大过程组(项目启动、规划、执行、监控、收尾)和十大知识领域(整合、范围、进度、成本、质量、资源、沟通、风险、采购、干系人),并按照精益和敏捷思想有所修正。

    分享的目的是帮助您思考精益敏捷的逻辑以及设计您自己的工作方式(Way of Working)。

    // 手绘图 by @ 虎头锤

    精益敏捷的八大逻辑

    两个根本元素

    产品、技术与工作方式

    当谈到产品时,人们心目中会浮现出一副景象:生活中的衣食住行,或娱乐运动旅游教育所需的各种东西,即人们购买、使用和消费,并能满足人们某种需要的任何东西。

    当谈到技术时:人们头脑中也会浮现出一副景象:为了生产出产品,具有专业技能的人在生产产品的过程中所进行的专业活动。

    有了对产品的需求,和有了技术,是否就能进行卓有成效的生产活动,和生产出既能满足市场需要,也能帮助企业盈利的产品呢?答案是否定的。

    福特汽车是如何崛起的?丰田汽车又是如何后来居上的?这涉及到工作方式和管理问题。

    流的历史

    工作方式的概念包含的内容很多。下图通过工作方式当中的一个小概念 “流”,介绍一下流的历史,对工作方式做个初步体会。

    640?wx_fmt=jpeg

    • 1104 年建立的威尼斯兵工厂,是为威尼斯海军建造军舰的地方。威尼斯人早年经过长时间的努力,建立了标准化的设计以及可替换的零件,以致在舰船厂中狭窄的水道里,一年能制造出数以百计的战舰。工人们先建造船身,然后再 “漂” 流到下一站,去装配不同的部件。1574 年,法国国王亨利三世被邀请去参观该工厂开发出的先进 连续流 制造技术,从开始组装船身到完成,只需要不到一小时的时间。

    • 1798 年美国正笼罩在可能要与法国开战的阴影之下,惠特尼接受美国政府的委托,在 1800 年前为美军供应 10000 至 15000 支步枪。他按照枪支零件的尺寸设计出一套专门器械和流程,让一般工人通过使用它们分工生产不同的零件。用这种工艺流程生产出来的零件尺寸及公差均一,任何零件皆能适用于任意一把同型号的步枪,只要将它们组装起来便可成为一支完整的步枪。这就是 可互换零件 。而在当时流行的工艺是每把枪由头到尾皆由一位工匠打造,同型号的每一把枪的零件都无法互换。

    • 丰田集团的创始人 Sakichi Toyoda 丰田佐吉(一生研发出 84 项专利,被日本人誉为 “发明王”),于 20 世纪早期,通过在自动织布机上安装能够在任何纺线断掉的时候自动停机的装置,发明了 Jidoka( 自动化 )这个概念。这不仅改善了质量,并且使得工人能够解放出来,去多做一些增值的工作,而不只是为了避免守在机器旁。最终这个概念应用到了每台机器,每条生产线,和丰田公司的每个操作之中。

    • 20 世纪初,汽车仍然是富人们才能消费得起的奢侈品,亨利·福特在 1903 年创办福特汽车公司后,励志要打造一辆普通大众都买得起的平民车。当时美国销售的汽车普遍售价在 4700 美元左右,相当于一名普通人六年的总收入,而福特 T 型车售价仅为 850 美元。为了让福特 T 型车更加深入人心,亨利·福特决定改进生产方式以求大幅降低了福特 T 型车的成本,使其售价进一步降低。亨利·福特偶然间在一份肉类加工厂报告中获得灵感,为了满足消费者对 T 型车强烈的需求,他决定采用 流水线 的方式生产汽车。1913 年 12 月 1 日,亨利·福特开发出世界上第一条汽车组装生产线并投入生产。每个工人固定在一个工位组装车辆的某一个零件,原先一辆汽车装配时间需要 700 多个小时,T 型车采用流水线作业仅需 12.5 小时。

    • 在 20 世纪 40 年代,戴明反复强调质量控制的重要性,不断进行质量管理的培训,试图把统计学运用于工业生产。据说,在这一阶段美国政府和企业听过戴明培训课程的人数达三万人。当时,戴明已经是世界公认的抽样专家,不过,他的呼吁,在美国反应寥寥,没有多少人对他的建议和课程真正有兴趣。1950 年 7 月 10 日至 18 日,戴明受 JUSE 邀请在日本四大城市授课。他立足于一个基本信念,即高质量可以降低成本。戴明预言:“只要运用 统计过程控制 ,建立内在质量管理机制,五年后日本的产品就可以超过美国。” 果然,日本的产品质量总体水平在四年后(大约 1955 年)就超过了美国,到 20 世纪 70-80 年代,不仅在产品质量上,而且在经济总量上,日本工业最终对美国工业造成了巨大的挑战。

    精益敏捷是当今工作方式的典型代表,上述工作方式中都包含着精益敏捷的要素。

    两个根本元素:逻辑和权力

    而在精益敏捷工作方式的所有要素当中,有两个根本元素:逻辑和权力。

    • 逻辑元素 :这是工作方式当中科学的一面。一种方法行得通或行不通,有其原因、条件和结果,这是逻辑和科学。精益敏捷工作方式是可设计的,而只有经过与实际情况相符的设计,才能行得通。

    • 权力元素 :这是工作方式当中与人有关的一面。在这里,权力一词基本等同于人。在一个组织当中,每个人有他的诉求、动机、地位、法定权力、思想、意志、知识、情感等或物质或精神的属性,这些都是权力。在人的世界里,单纯用逻辑和科学方法是行不通的,因为人和权力是逻辑关系中最重要的要素。权力又大致有两种:凝结在一个个个体身上的,和蕴藏在组织结构中的。这两部分权力都要有很好的处理。

    下述精益敏捷八大逻辑当中,第五和第六逻辑重点涵盖权力元素,其他重点放在逻辑元素,但也涉及权力元素。

    逻辑一:3C 环境

    640?wx_fmt=jpeg

    精益敏捷是如何发展起来的?我们又为什么要实施精益敏捷?答案是我们生活在一个 3C 的环境当中:

    • 客户(Customer):客户的要求越来越高。客户期望能以更低的价格,买到能满足需要的产品,而且期望产品的交付周期越短越好。以手机为例,十年前市场上的手机品牌很少,升级换代很慢。而现在,手机的品种和升级换代的速度已经让人眼花缭乱,更不要说各种 App 了。就社会和市场上的总产品来说,过去几十年产生的产品数量或许超出了过去几千年产生的产品数量。经济进步、技术进步和消费者的觉醒是背后的推动力量。

    • 竞争对手(Competitor):行业壁垒越来越低,市场上的竞争对手越来越多。如果一家公司不能满足客户的期望,客户还有更多选择。公司发展不进则退,市场上总有人能以更低的价格做到同样的事。对于手机产品,汽车产品,甚至火箭产品,我们发现越来越多的 “外行” 进入这些行业,而且还玩得风生水起。比如说马斯克和贝索斯两位就分别把火箭的发射成本降到了美国宇航局的十分之一以下。

    • 复杂性(Complexity):复杂性体现在两方面,一方面是关于需求,另一方面是关于技术。这两方面的进化和不确定性都在加剧。大家都知道芯片集成度的摩尔定律,芯片的集成度每 18 个月提升一倍。十年前电子产品还可以靠人工焊接,现在的芯片管脚已经是人拿着放大镜都看不清,只能机器焊接。这是可见的物理复杂度的一个例子,更多是不可见的复杂度和不确定性。应对复杂性和不确定性的能力,是一家公司的重要核心竞争力。参阅:复杂性与敏捷 - Stacey 矩阵,Cynefin 框架,管理 3.0,敏捷宣言

    在这样一种 3C 的环境之下,精益敏捷的工作方式应运而生,成为企业的如虎之翼和强身健体的利器。

    2018 年,全球市值最大的 5 家公司分别是:亚马逊(Amazon)、苹果(Apple)、Facebook、谷歌和微软(Microsoft)。他们都采用了某种形式的精益敏捷,都在 3C 问题上有很好的处理。

    并不是说精益敏捷是这些公司成功的唯一原因,但对其成功有重要作用。而要想运用精益敏捷取得成功,需要对精益敏捷的逻辑有清醒的认识,进而设计自己的工作方式,并确保落地。

    世界潮流,滚滚向前。环境在变化,不以我们的主观意志为转移。只有顺应潮流,并相应地调整自己的行为,一个企业才有可能基业长青。

    逻辑二:三个核心

    640?wx_fmt=jpeg

    一家企业要能在 3C 环境中生存发展,需要处理好三个核心问题:

    • 把握用户需求 :一种业务,只有真正把握住用户需求,才有可能为供需双方实现价值。根据相关统计,整个软件行业的产品和功能有将近一半完全没人用,这是因不能把握用户需求而产生的最大的浪费。

    • 提升效率 :利润 = 价格-成本。提升效率,即是降低成本,提升利润。管理者的主要职责就是提升效率。而一家企业要在提升效率上有所作为,需要全体员工都能从提升效率中受益。

    • 应对复杂性 :在复杂性日益增长的时代,传统的慢时代的计划与控制的方法不再生效。应对复杂性,既需要从物的角度的科学逻辑方法,也需要从人的角度激励个体的参与和提升组织的合作。

    而对这三个核心问题的处理方法分别是:

    • 用 以用户为中心 来把握需求:贴近用户,了解他们真实的需求。

    • 用 消除浪费 来提升效率:消除浪费即是提升价值。大野耐一说:一个典型的过程中,包含着 95% 的浪费。改善是无止境的。

    • 用 探索式方法 来应对复杂性:采用多层次的 PDCA 循环,不断检视和适应。以团队合作全员参与推动 PDCA 循环。

    案例:北电网络破产的原因,在这三个核心问题上都有所体现。

    北电的错,看起来像是三大原因:一是技术路线选择的失误,二是对市场预估过于激进,三是内部缺乏有效的管理。

    这正是所有技术公司都有可能面临的风险,技术路线的错误,对市场预估的失误,都有可能将一个技术公司拖入深渊。

    其实北电的失误不仅表现在对技术市场的 “钝”,它对客户的需求也有些 “钝”。有人就认为,北电的失误是一味追求技术的先进性,而不考虑客户的需求。

    以光纤为例,在互联网泡沫破灭之后,北电急急地投入到新一代大容量的研发当中,认为市场复苏之后,运营商就会大规模升级网络。

    但当时全球刚刚经过一轮光网络的升级,10G 网络铺完成之后,网络上的业务还没有应用起来。在业务没有发展起来的情况下,运营商当然是不会感觉到网络的容量不够,所以也不会急着扩容。

    相反,运营商着急的是如何把网络用起来。所以,北电的 “前瞻性技术” 并不被运营商所接纳。

    北电并没有理解客户真正需要什么。这些年,电信运营商也处于转型期,一方面是网络的升级,另一方面,更为运营商所看重的是在现有承载能力上去挖掘业务潜力,而不是无度地投资。

    近几年,全球电信业的低迷是有目共睹,这个低迷主要是因为运营商不再疯狂地投资在基础建设方面。对于整个行业的低迷,一些供应商很早就预见到并积极根据客户的需求转型,将企业网、融合通讯、电信专业服务等新业务作为拓展领域,所以不会像北电那样陷入如此的困境。

    运营商是电信设备厂商的衣食父母,北电对运营商转型的心理抓得不准。所以,北电的几次转型并没有紧紧地贴着自己的客户去转型,而更多地将命运交给未来可能存在市场的超前技术。客户不会跟着北电走,北电就被无情地抛弃。

    远离了客户的北电,越走越远。

    至此,我们已经介绍了作为精益敏捷产生背景的 3C 环境 ,进而推导出精益敏捷所要处理的 三大核心问题 ,及对应的  三大核心解决思路 。


    下述内容是对三大核心解决思路的展开,主要是以 Scrum 作为落脚点。


    如果不采用 Scrum,也要有相应的方法保证三大核心解决方案的落地。明白了其中的逻辑之后,可以自己设计自己的工作方式。社区中有很多关于 Scrum 的争论。

    我的建议是,用什么或不用什么,要从目的和逻辑出发。只有明白了背后的逻辑,才能主动做出适合自己的选择。

    逻辑三:三个核心在 PO 的体现

    640?wx_fmt=jpeg

    我们先看一个问题:职责与职位。一种职责可以由多个职位承担,一个职位也可以承担多种职责。从单个职位出发来看,最优的职位设置是没有意义的。

    只有放在整个组织的系统中,以组织目标的完成程度来评价,才能看出整体职位设置的优劣。

    职位与角色略有区别,敏捷当中更常用的的角色,更少强调地位,更多强调合作。要理解 PO(产品负责人)这个角色,可以从它的历史来源来看。

    产品经理的起源

    自 1927 年,美国 P&G(宝洁)公司出现第一名产品经理(Product Manager)以来,产品管理(Product Management)制度逐渐在越来越多的行业得到应用和推广,并且取得了广泛的成功。

    当时公司推出一种佳美牌(camay)香皂,但销售业绩较差。公司刚启用的一名叫麦古利的年轻人在一次会议上提出:如果公司的销售经理把精力同时集中于 camay 香皂和 lvory(宝洁的一种老牌香皂)的话,那么 camay 的潜力就永远得不到充分发掘。

    同时,他提出了 “brand man”(品牌人) 的概念 , 一个品牌人应该有一个销售小组的帮助,每一个宝洁品牌应当当做一个单独的事业在经营,与其它品牌同时竞争。

    麦古利赢得了宝洁高层的支持。同时他的成功表现使公司认识到产品管理的巨大作用。之后,宝洁便以 “产品管理体系” 重组公司体系。

    这种管理形式为宝洁赢得了巨大的成功;同时,亦成为全球产品管理的典范。

    产品经理的产生,标志着从生产者市场向消费者市场的转移。众所周知的乔布斯是产品经理心目中的大神,一众追随者以某布斯的称号为荣。

    PO 与产品经理尽管不完全相同,但产品管理依然是 PO 的核心职责,只是在管理方法上与敏捷方法配套。

    XP(极限编程)中客户的概念

    1993 年开始的 C3(Chrysler Comprehensive Compensation System)项目中,诞生了著名的 XP 方法论。

    XP 重新定义了客户的概念。在 XP 中,我们希望客户、管理者和开发人员紧密地工作在一起,以便于彼此知晓对方所面临的问题,并共同去解决这些问题。谁是客户?XP 团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。

    有时,客户是和开发人员同属一家公司的一组业务分析师、质量保证专家和 / 或者市场专家。有时,客户是用户团体委派的用户代表。有时,客户是真正支付开发费用的人。但是在 XP 项目中,无论谁是客户,他们都是能够和团队一起工作的团队成员。

    最好的情况是客户和开发人员在同一个房间中工作,次一点的情况是客户和开发人员之间的工作距离在 100m 以内。距离越大,客户就越难成为真正的团队成员。如果客户工作在另外一幢建筑或另外一个城市,那么他将会很难融合到团队中来。

    如果确实无法和客户工作在一起,该怎么办呢?我的建议是去寻找能够在一起工作、愿意并能够代替真正客户的人。

    Scrum 中 PO 的概念脱胎于 XP 中客户的概念。

    产品经理、项目经理和架构师的三角形

    这个三角形更多是基于我在外企通信行业的经验。

    产品经理隶属市场部门,当采集到需求后,会以特性需求规范的形式呈现。

    特性需求规范会交给项目经理,项目经理召集人员理解需求,转化成特性技术规范,给出估算和规划。根据需求的复杂程度,决定是需要架构师参与,还是只需要一般开发人员参与。

    整体上,产品经理、项目经理和架构师呈现出一个支撑项目的三角形,分别从产品管理、项目管理和技术管理的角度发力。

    PO 的采用

    接着上面的背景,在采用 Scrum 之后,我们是由架构师充当 PO。一方面他封装住了来自产品经理的需求,并转换为用户故事,而不再采用特性技术规范的形式。

    另一方面,通过 Scrum 工作方式的采用,项目管理的职责被弱化,分摊到 PO 和团队身上,PO 也需要跟团队更密切协作保证需求被正确有效理解和实施。PO 本身的架构师背景也是一个优势,使他除了问题领域,也能理解解决方案领域。

    我们采用 Scrum 和设置 PO 之后,除了作为核心诉求的交付周期的极大缩短之外,在质量和效率方面都有显著提升。

    通过上面的溯源,总结一下 PO 角色设置的几个理由:

    • 对于团队来说,他代表的是需求方。不管需求方有多少来源,PO 要能封装住需求方的需求。

    • PO 又与团队一道密切工作,保证需求的正确传递。

    • PO 是整个管道中非常关键的一环,需要有足够能力和得到足够授权。

    • Scrum 和 PO 角色的设置也是对整体管理的简化。

    PO 角色的设置也许不是唯一可行的模式,但要想获得 Scrum 和 PO 角色设置的成功,高层管理和整个组织要对 Scrum 和 PO 套路有清晰完整的认识,合理的权力分配和严肃认真的执行。

    以下介绍精益敏捷三大核心做法在 PO 的体现。介绍不求完备,主要是理清各个实践的逻辑因果,以帮助读者思考、拓展和实施适合自己的实践。

    以用户为中心在 PO 的体现

    价值发现和验证 

    通过各种活动发现客户关注的价值,并获得验证。具体的活动包含客户访谈、客户论坛、给客户做演示、让客户试用产品等。

    对于偏后端的产品,需要建立起内部用户的概念,把功能的使用方作为内部用户。功能的提供方和使用方需要协同一致建立起有效的价值发现和验证机制。

    价值驱动 

    主要是指需求的优先级排序。这涉及到两个问题:切割和排序。首先是把需求切割到合适的颗粒度,然后是对需求进行排序,按照二八原理,把最有价值的需求排在前面。这样,也为用户终止开发或变更需求提供了灵活度。参阅:Scrum 合同模式:付费止损,免费变更

    消除浪费在 PO 的体现

    减少中间环节

    在传统的组织当中,开发团队的两端都离用户很远。在需求侧,等到需要到达团队手里,已经经过了很多环节。

    造成的问题,一是需求可能会失真,二是耽误了时间,三是不能直接获得反馈,这些都是浪费。在运维侧,通常是由专职的运维团队负责,开发团队在这方面也远离用户。

    后者的解决方案是 DevOps,参阅:DevOps 的前世来生,从《目标》、《凤凰项目》到《持续交付》

    一个组织要在整体上变成精益敏捷型组织,是很困难的,背后涉及到高层管理的认知和责权利的转移。在不理想的情况下,PO 要想尽办法接近用户,缩短团队与用户之间的距离,排除因之造成的浪费。

    成功的变革离不开权力。我们也看到过管理者的变换对团队造成的影响,比如说有的管理者是产品导向,只要有利于产品,可以打破既定部门分工的规则,而有的管理者则是规则和流程导向,缺乏打破常规的勇气。

    清晰表达

    PO 的需求表达的是否清晰,团队是最好的裁判,因为需求是给团队用的。归一化合乎逻辑的格式,是需求表达的有力工具,比如说用户故事和验收标准。

    PO 的需求表达训练是值得投资的。有一个团队,最初的时候 PO 没有事先呈现需求,到了计划会上才与团队一道 brainstorm 需求,这当中蕴含着巨大的浪费和低效。后来经过对需求表达的学习和训练,整个团队的效率因此受益很多。

    准备好

    清晰表达是准备好的一个内容。准备好指的是在每一个活动之前,这个活动所需要的条件要准备好。

    Scrum 中所用的术语是 DoR(Definition of Ready),在一个迭代开始前,相关物件和人员要达到准备好的状态。准备好是一个检查列表,示例如下:

    • 需求要有清晰的商业价值。

    • 需求要有明确的验收标准。

    • 人员具备完成产品列表所需的技能。

    • 依赖和风险被识别和管理好。

    根据 Scrum 之父 Jeff Sutherland 的研究,准备好能使团队的效率倍增。参阅:从 Vision 到 Value,Backlog 精化带你飞

    颗粒度

    不合理的颗粒度是一种浪费。颗粒度太大的需求,难以被理解,难以被估算,并因其模糊本性带来更多的沟通成本。而颗粒度太小的话,会增加管理成本。

    用户故事是一种合适的颗粒度。用户故事的一些重要特征:

    • 一目了然格式一致的表达。用户故事有两个部分:描述部分和验收标准。描述部分的常用格式是:As <用户>, I want <功能>, so that <目的>。验收标准可以有多条,常用的格式是:Given <前提条件>,When <动作>,Then<结果>。

    • 鼓励推迟细节,只需有足够的信息以使项目前行。我们不需要一次性把项目的所有需求搞清楚,我们只需要在迭代之前把一个迭代要做的事搞清楚即可。而以用户故事作为基本单元,可以支持这种开发模式。

    • 用户故事以合适的颗粒度,方便理解,方便排优先级,保证重要的事先做。随着时间的推移,不重要的事也许就不需要了。

    • 用户故事鼓励通过交谈了解细节。强调对话而不是书面沟通。

    • 用户故事的验收标准保证成果可以被审核验证。

    • 以用户故事为载体,促进结构化沟通,使谈话有落地点。

    • 从业务角度描述,可以同时被业务人员和开发人员理解。

    • 用户故事的大小适合估算和做计划。颗粒度适合迭代开发。

    • 支持随机应变的开发,检视和适应。

    • 鼓励各方参与交流,传播隐性知识。

    参阅:敏捷读书之用户故事:《用户故事与敏捷方法》解读

    探索式在 PO 的体现

    快速反馈

    《Scrum 指南》说,每个迭代都要构建一个 “完成”、可用的和潜在可发布的产品增量。Sprint 评审会议在 Sprint 快结束时举行 ,用以检视所交付的产品增量并按需调整产品待办列表。

    在 Sprint 评审会议中,Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化,所有参会人员协同讨论接下来可能要做的事情来优化价值。

    这是一个非正式会议,并不是一个进度汇报会议,演示增量的目的是为了获取反馈并促进合作。

    能否在迭代结束时交付可用的产品,是 Scrum 成功与否的试金石。而从各自为政到合作的建立则是对管理方式鸿沟的跨越。

    《精益创业》对反馈有更系统化结构化的描述:

    • Leap(信念飞跃):每一个商业计划都是从一系列假设开始的。把假设说得像真的一样,是创业者典型的超能力。正是因为整个企业的成功寄托在这一点上,所以它们被称为信念飞跃。

    • Test(测试):一个最小化可行产品 MVP 有助创业者尽早开启学习认知的历程。它并不一定是想象中的最小型产品;它是用最快的方式,以最少精力完成开发-测量-认知的反馈循环。

    • Measure(度量):一家新创企业的工作是:(1)严格测量企业目前的状况,正视评估中揭示的现实真相。(2)设计实验,从而了解如何让真实数据向商业计划中的理想目标靠得再近些。

    • Pivot(转型):每个创业者在开发一款成功产品的过程中,迟早会面临一项重大挑战:即决定何时转型,何时坚持。

    参阅:GitChat 的精益创业之旅

    分层计划

    敏捷的计划有五层:

    • 组合级 (Discussion):在这一层,主要是跟产品决策委员会一起讨论哪些产品上还是不上。

    • 产品级 (Envision,Funding,Roadmap):在这一层,主要是确定产品的愿景、预算和路线图。

    • 发布级 (Story Writing,Release Plan,PB Grooming):在这一层,包括故事写作、发布计划和产品列表梳理。

    • 迭代级 (Sprint Plan,Review):这一层包括迭代的计划和评审。

    • 每日级 (Steer Direction,Answer Question):这一层包括方向的把握和回答团队的问题,这些是通过与团队在站会上和日常的互动交流实现的。

    通过把计划分层,从更长期的角度是拥抱变化,从更短期的角度是扎实执行。通过行动排解近忧,通过变通容纳远虑。

    参考:PO 工作指导:掌舵 3355 的迭代之河

    PO 的角色建立及按照三个核心思路有效发挥,需要管理者的认知与支持、PO 本人的学习,和周边组织和人员的配合。

    逻辑四:三个核心在团队的体现

    640?wx_fmt=jpeg

    PO 是上游,团队是下游。PO 主要负责需求,是问题领域。团队主要负责解决方案领域。上下游的合理有效交接很重要。

    在 PO 身上落实的三个核心思路,同样要落实到团队身上,但有有几个不一样的地方:需求交接问题,技术能力问题,多人合作管理问题。具体说明如下。

    以用户为中心在团队的体现

    清楚了解需求

    与 PO 的清楚表达需求相对应,团队要做的是清楚了解需求。这可以发生在几个环节:

    • 产品列表梳理会:产品列表梳理会是 PO 帮助团队理解需求的主要时机。团队可以用 DoR 要求 PO,在会议前的准备度达到准备好的标准。团队也要花一些时间准备,大致了解一下背景和上下文,跟需求混个脸熟,省得到时候一头雾水。现场可以用估算纸牌做估算。采用估算纸牌最重要的目的不是估算本身,而是揭示大家的不同理解和假设。

    • 技术梳理会:如果是因为没有解决方案而妨碍了对需求的理解,可以增加一个技术梳理会,探讨解决方案,达到可估算的标准即可。

    • 迭代计划会:是理解需求的第二道闸,提供了又一次澄清需求的机会。

    • 日常工作和每日站会:如果还有不清楚的需求,团队有提问的责任,PO 有解答的责任。

    • 迭代评审会:正常来说,到了迭代评审会不应该再有对需求的分歧。有的话,可以利用迭代回顾会找下原因,对症下药解决。

    需求主要是 PO 的责任,但团队要主动参与理解,并且有质疑和追根到底的精神。

    对于团队成员不主动参与理解需求的情况,通常是动机和合作的问题。功夫在诗外。需要从后面的权力结构和人的激励入手。

    消除浪费在团队的体现

    自管理

    被管理,是一种浪费。对于管理者,投入是一种浪费。对于被管理者来说,被打断和被控制是一种浪费。最好的管理是自管理。

    Scrum 的仪式用得好,就已经是自管理了。人人都是项目经理。

    参阅:A1 大白纸计划法

    B=MAT,行为 = 动机 x 能力 x 触发。自管理的能力不难学习,Scrum 事件和流程就是触发,剩下的就是动机问题了。

    跨职能

    跨职能的含义是,一个团队要具备完成产品列表的全部技能,并且团队的技能分配足够均衡和充分备份,以至于能适配产品列表中对不同技能的需求量,和人员可以自由请假。

    跨职能需要组织的政策支持和个人的认知改变。跨职能会加强一个人的能力而不是削弱一个人的能力。

    参阅: Scrum 的跨职能团队建设游戏

    可视化

    隐藏,是一种浪费。可视化的六个原则是:

    • 可视化价值流动,有效管理创新全过程;

    • 可视化拥堵,分析发现问题,加速流动;

    • 可视化任务资源匹配,实现战术沙盘;

    • 可视化决策规则,养育自组织团队;

    • 可视化风险,管控创新风险;

    • 可视化投入组合情况,平衡长短期利益。

    参阅:可视化管理六原则

    流动

    在前文流的历史中,已经对流动有所介绍。流动是精益思想五原则当中的重要原则。

    在制造业的生产过程中,物有四种状态:

    • 加工;

    • 检查;

    • 停滞;

    • 搬运。

    停滞是不流动,检查和搬运是可以优化的流动,只有加工是有价值的流动。

    创造流动有三个步骤:

    • 化身为物:把自己想象成被处理的工作,被处理的工作也是没有耐性的。

    • 建立流动:排除障碍,让工作流动起来。

    • 保持流动:把流动持续保持住。

    故事泳道是一个在站会中辅助流动的工具。参阅:故事 X 人矩阵

    关于流动效率,参阅:研发组织该如何设计绩效体系

    纪律

    技能 x 纪律 = 能力。敏捷对纪律有很高的要求。

    几年前,我对 Scrum 有个总结:十论 Scrum 就是知行合一。

    1. 人人知行合一:人人计划,人人行动。

    2. 时时知行合一:时时计划,时时行动。

    3. 团队知行合一:团队决定,团队行动。

    4. 敏捷知行合一:快速决定,快速行动。

    5. 需求知行合一:接近客户,掌握需求。

    6. 支柱知行合一:检验是知,适应是行。

    7. 完成知行合一:定义完成,共识目标。

    8. 透明知行合一:高度透明,流畅过程。

    9. 纪律知行合一:自我纪律,助长能力。

    10. 美德知行合一:积极主动,集思广益。

    纪律的建立,主要靠目标感,组织目标、团队目标和个人目标的对齐,和同侪压力。

    参阅:我与 Scrum 的心路历程

    2014 年,柳传志在微博之夜上表示,联想要开二三十人的会,如果这个会是准时开的,谁迟到的话罚站一分钟;会议正开的时候停下来默哀式的让你站一分钟,这实际是个非常难过的事儿。

    这件事情从 1990 年开始一直执行到今天,只要有一定做。包括我自己迟到也被罚过三次。国内商业诚信不好的关键是选择性执法,法律面前人人平等,没有人敢触犯法律。

    柳传志的做法是否适合敏捷团队?答案是,只要大家都同意,就可以执行。

    团队规模

    根据各种研究,小团队是最有效地。其中最有名的说法是贝索斯的两个披萨饼团队。如果两个披萨不足以喂饱一个项目团队,那么这个团队可能就显得太大了。

    《Scrum 指南》中说:开发团队最佳规模是足够小以保持敏捷性,同时足够大可以在 Sprint 内完成重要的工作。少于 3 个人的开发团队,成员之间没有足够的互动,因而生产力的增长不会很大。过小的团队在 Sprint 中可能会遭遇到技能上的约束,进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言,大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在开发团队人数中,除非他们同时也参与执行 Sprint 待办列表中的工作。

    我曾经处理过一个 15 人以上的团队,开始时,大家都认为不可能分成两个团队,因为工作都耦合在一起。后来经过梳理,把工作分类,分成了两个团队,也运作得完全没有问题,效率比之前有很大提升。

    完成标准

    大野耐一对价值的定义是:

    • 客户愿意为之付钱。

    • 是一个过程。

    • 一次做对。

    对于软件开发来说,一次做对的说法不能机械应用,否则还要 Debug 干啥?有完成的标准,大致对应大野耐一所说的一次做对。没有完成的标准,就是浪费。

    对于一个迭代来说,完成的标准包括两个方面:关于结果的和关于过程的。跟准备好的标准一样,完成的标准也是一个检查列表,示例如下:

    • 发布到生产环境。

    • 零已知故障。

    • 用户文档的要求。

    • 代码评审的要求。

    • 单元测试的要求。

    • 持续集成的要求。

    前三者是关于结果的,是外部质量。后三者是关于过程的,是內建质量。

    通过扩大完成标准的范围和提升完成标准的要求,也能帮助一个团队的自我提升。

    探索式在团队的体现

    小批量

    迭代列表本身就是个小批量。

    在迭代内部,我们还可以进一步运用小批量的概念。如果一个迭代有 10 个用户故事,到迭代结束时,每个都完成了 90%,这种状态不如有 5 个 100% 完成,有 5 个还没开始做。

    这也是一种小批量思维。只要没有完成,80% 也好,90% 也好,都是不可靠的。

    如果你的团队在完成上总是有困难,可以尝试更小的批量,大家通力合作,一次完成一个更小的批量,这既能提升效率,也促进合作,为更高的效率奠定基础。

    快速反馈

    除了在迭代层面的迭代评审的反馈,快速反馈还可以在迭代内部运用。

    测试和代码评审都是反馈。结对编程、结对工作,和更紧密的协作都是加速反馈。

    参阅:细颗粒度的协作

    分层规划

    规划的分层跟在 PO 的那一部分的陈述是一致的。

    PO 和团队在规划问题上的分工合作是:

    • PO 负责方向,包括产品愿景、路线图、用户故事优先级等。

    • 团队负责估算。估算的原则是:让干活的人做估算。

    • 团队通过估算,帮助 PO 理解成本并相应地调整优先级。

    • 团队帮助 PO 理解业务故事背后可能涉及到的技术架构工作。

    • 关于风险:PO 管理与客户有关的风险,团队管理与技术有关的风险,ScrumMaster 管理与组织和沟通有关的风险。

    技术卓越

    敏捷宣言的原则之一是:坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

    技术永远是开发人员的核心能力。在需要快速响应的环境之下,技术提升是 Scrum 团队建设的重要内容。

    参阅:众筹式知识分享在团队和组织的运用

    逻辑五:权力结构

    640?wx_fmt=jpeg

    敏捷的实施好比是在大海中潜水,在靠近水面的部分没什么大的障碍。前述三大核心思路在 PO 和团队的体现,更多是一些在靠近水面部分潜水的招式。

    随着潜水深度的增加,就会遇到礁石。权力结构是一个礁石。

    企业中的权力是如何产生的?薛兆丰有一个解释:

    我不知道你有没有看过这样的场面,就是在旧社会很落后的时候,有一种职业叫纤夫。他们就是在岸上拉船的人,那是一种苦工。

    一群衣衫褴褛的工人,在岸上卖力地把船从一个地方拖到另外一个地方,而这时候,这群辛苦工作的纤夫背后还有一位举着鞭子的监工,为什么会有这样的职业?

    如果可以选择,你愿意当纤夫还是当监工呢?很多人会说那我宁愿当监工,被人抽还不如抽别人。但问题是为什么就没见到大家都变成了监工呢?

    你要再想想这船是纤夫拉的,收入是他们挣的,凭什么他们挣来的收入还要分一块给这个监工,他们可不可以合计一下,说下次我们找到工作就不要这个监工了。

    事实上,监工这个职位一直存在,我们需要对它进行解释。这个解释就是,纤夫们自己知道,他们自己会偷懒,他们会虚张声势地卖力,他们知道如果是这样的话,他们的总收入会下降。出钱请了一个人来鞭打他们自己,他们的收入反而会增加。

    我们姑且把上文中的纤夫称为工资奴隶。然而,工资奴隶制无法满足现代经济的需要。在一个被全球化、放松管制、知识工作和新技术所颠覆的市场中,企业现在需要主动、创新、承诺、聪明、激情——而这恰恰与雇佣奴隶制截然相反。参阅:为什么敏捷正在吞噬世界

    因此,这种新型的工作者需要一种新的管理方式。一些人将这种方式称为敏捷组织运作。也有用别的标签的。但是不管它叫什么,它都不只是个新流程。这是一种完全不同的运作方式。

    这在经济上更有成效。它对人类的精神有着巨大的潜在益处。它可以创造工作场所,使人类能够贡献他们的全部才能,为其他人类创造有价值和有意义的东西。

    对于精益敏捷来说,合理的权力结构是怎样的呢?

    共同目标

    在 Scrum 团队中,PO、ScrumMaster、团队三个角色各有分工,但大家的目标是一致的,都是为了通过每迭代输出潜在可交付的产品增量来实现产品愿景和价值。

    最近在一篇文章中看到一个团队的描述,我认为这是一个真正的敏捷团队,尽管不一定用敏捷的标签。参阅:挣来的普吉之行

    在小的创业公司,创始人的认知就可以决定一个团队的形态。对于大公司来说,建立真正的敏捷团队会有很多困难,但最高管理者的认知是阿基米德点。

    共同责任

    敏捷影响力第一人 Mike Cohn 说:在一个团队的迭代中,我不能说,我的任务完成了,而张三还有些任务没完成。

    一个敏捷团队一荣俱荣一损俱损。如果一个团队的 ScrumMaster 获得了好的绩效,而团队成员普遍获得了不好的绩效,那么这个组织的管理是有问题的。

    罗辑思维有个节操币制度:

    每个员工每个月可以获得 10 张节操币,每张相当于人民币 25 元。他们可以用这张节操币在我们周边的咖啡厅和饭馆随便消费,还可以获得打折和 VIP 待遇,公司月底统一与这些饭馆结账。

    但是,节操币不能自己使用,必须公开赠送给小伙伴,而且要在公司公示你为什么要把节操币送给他,说明具体原因。节操币成为了我们的硬通货,每月公司会公示当月节操王。

    每年收到节操币最多的节操王,会获得年底多发三个月薪的奖励。所以,每个人都能看到一个公开的数字,这个节操币的交易情况,反映了每个人与他人协作的水平。

    很少收到节操币的人,一定是协作水平和态度比较低的,而且是由全体员工每天的自然协作做出的评价,是一张张真实的选票。这种落后的人,会很快自觉改善,或者离开公司,他们会感受到强烈的压力。

    参阅:罗振宇跨年演讲中的精益敏捷要素

    共建体系

    上面的节操币制度已经是共建体系的一个例子。

    在敏捷团队中,大小制度都可以由团队共建。最常见的一些有:

    • 团队规范与工作协定。

    • 完成的定义。

    • 准备好的定义。

    服务而不是权力

    如果能做到上面三点,权力就不需要了。

    这里有一个有决心改变权力结构的案例。参阅:J.P. 摩根运用 LeSS 框架实施大规模敏捷。

    而对于大多数组织来说,彻底的改变是不容易发生的。管理者要有观念的扭转,从掌权者变为服务者:

    • 在团队管理方面:将团队的自组织能力和经理们的有效领导相结合。

    • 在投资管理方面:让团队从以计划为导向的思维方式转化到以价值为导向的思维方式。

    • 在环境管理方面:在由各种流程和外部资源组成的组织环境中,高效地审视组织内各流程的设计以消除各种对组织资源的浪费。

    权力是组织的障碍,主动变革才是出路。

    逻辑六:人的激励

    640?wx_fmt=jpeg

    权力结构之外,不被激励是另一个暗礁。

    对一个人绩效影响最大的是他的动机。参阅:B=MAT 在 Scrum 中的运用

    以下对动机的描述并无完备,只是列出常见的一些。

    工资

    工资这个东西,从公司的角度是成本,从员工的角度是生活的期盼,从两者关系的角度是交易。

    要在这个问题上有所提升,员工需要创造更大的价值,公司需要在整个价值流中消除浪费,大家从创造的价值中分享收益。

    奖金

    从公司的角度,奖金是业绩完成超出预期的部分,从员工角度,奖金是对生活的改善。工资对应一个人的职责和能力,而奖金对应一个人对团队合作的贡献。

    福利

    福利包含可以物化的部分和不可物化的部分,比如弹性工作制和假期。

    公平

    要有广为接受的游戏规则。

    关系

    要有相对平等的关系。

    逻辑七:ScrumMaster

    640?wx_fmt=jpeg

    ScrumMaster 是工作方式的化身。参阅:系统的化身—敏捷教练的人设

    ScrumMaster 所要做的如下:

    逻辑与招式

    ScrumMaster 需要精通精益敏捷的逻辑和招式。

    获得授权

    ScrumMaster 需要获得组织的授权,成为 Scrum 的化身。

    建立流程

    进而建立 Scrum 工作方式。

    解决问题

    还需要解决背后的各种障碍和问题。

    逻辑八:与 PMBOK 对照

    640?wx_fmt=jpeg

    最后,我们从 PMBOK 五大过程组和十大知识领域的角度来检视一下敏捷。

    五大过程组:

    1. 启动过程组 :作用是设定项目目标。在 Scrum 当中,目标不是一次设定,而是分层和逐步调整,预测性和适应性并重。PO 负责产品愿景,团队负责迭代目标。

    2. 规划过程组 :作用是制定工作路线。在 Scrum 中,有长期的产品路线图,中期的发布计划,短期的迭代计划,和每日计划。

    3. 执行过程组 :作用是让团队按计划执行。Scrum 的做法主要有两点不同,第一是通过上述的五层计划,增加了适应性。第二是全员参与计划和执行,计划的人就是执行的人。

    4. 监控过程组 :作用是测量项目绩效,并且尽量做到防患于未然。Scrum 当中的进度监控主要通过迭代燃尽图和发布燃上图,质量监控主要通过 DoR 和 DoD 来內建质量。

    5. 收尾过程组 :作用是了结项目。在 Scrum 中,收尾划分到每个迭代,通过迭代评审和迭代回顾进行,一方面可以快速获得反馈,另一方面可以持续改进。

    从五大过程组的角度来看,敏捷是把传统的大项目变成一个个小项目,大环套小环,把航母变成一艘艘快艇。每个小环依然有完整的五个过程,只是做法有所不同。

    从每个小环中的学习,可以帮助增强大环。

    参阅:1986 年第一篇关于 Scrum 的论文及內建(Built-in)思想

    十大知识领域:

    1. 整合管理 :其作用是把所有方面贯穿起来。在敏捷当中,产品导向重于项目导向,产品列表是贯穿各种事物的线索。

    2. 范围管理 :其作用是做且只做该做的事。在敏捷当中,范围被视为一个可变的要素。参阅:Scrum 合同模式:付费止损,免费变更

    3. 时间管理 :其作用是让一切按既定的进度进行。在敏捷当中,关注点放在流动和趋势,而不是严格的时间表。

    4. 成本管理 :其作用是算准钱和花好钱。在敏捷当中,基于迭代增量式的开发,对成本的测量会更容易。

    5. 质量管理 :其作用是满足需求。在敏捷当中,通过采用完成的定义来內建质量。

    6. 人力资源管理 :其作用是让团队成员高效率地和你一起干。在敏捷当中,通过 Scrum 团队建设,更大化地协同团队的生产力。

    7. 沟通管理 :其作用是在合适的时间让合适的人通过合适的方式把合适的信息传达给合适的人。在敏捷当中,通过 Scrum 框架来引导沟通。

    8. 风险管理 :其作用是防患于未然。Scrum 的五层规划和团队自管理有利于风险管理。

    9. 采购管理 :其作用是当好甲方。敏捷的迭代增量式可以帮助做出更具适应性的采购决定。

    10. 干系人管理 :其作用是和项目干系人搞好关系并令其满意。在敏捷当中,通过透明化提升信任。

    从十大知识领域来看,敏捷采用的是一种更柔性更透明更授权的方式。

    总结

    本文的重点是精益敏捷的八大逻辑 

    逻辑一 是精益敏捷产生的 3C 环境。 

    逻辑二 是因之产生的三大核心问题和三大核心思路。

    逻辑三 和 逻辑四 是三大核心思路在 PO 和团队身上的体现。

    逻辑五 和 逻辑六 是两个暗礁:权力结构和人的激励。

    逻辑七 是作为精益敏捷化身的 ScrumMaster 的作用。

    逻辑八 是敏捷与 PMBOK 的简单对照。

    八大逻辑涵盖了两个根本元素:逻辑元素或科学方法,权力元素包括个体和组织结构。

    八大逻辑祝你成功地设计和应用精益敏捷。

    扩展阅读


    展开全文
  • ACP敏捷知识点汇总

    2019-07-05 16:02:50
    行 Scrum定义以及Scrum流行的原因 Scrum理论以及三大支柱 Scrum框架组成3355 三个角色 三个工件 五个会议 五个价值观 ...Scrum不是开发产品的一种流程或一项技术,而是一个框架,在这个框架可以应用...

    Scrum定义以及Scrum流行的原因

    • Scrum理论以及三大支柱
    • Scrum框架组成3355
    • 三个角色
    • 三个工件
    • 五个会议
    • 五个价值观
    • DOD

    Scrum是由Ken Schwaber 和 Jeff Sutherland 在1990年创建的主流敏捷技术。它是最受欢迎的敏捷技术,超过50%以上的项目在运用这项方法。

    • Scrum不是开发产品的一种流程或一项技术,而是一个框架,在这个框架可以应用各种流程和技术,在这个框架中人们可以解决复杂的自适应问题。
    • Scrum提供简单和可证明的结果、它包含其他敏捷工程技术、它强调小型团队和团队授权、欢迎需求的变更、它允许单一来源的优先项目工作开展、Scrum会议包括日常状态会议、提供团队在冲刺阶段一个潜在的可交付增量承诺

    Scr基于经验型流程控制理论,或者称为经验主义。经验主义主张知识源于经验,而决策基于已知事物。

    透明性:

    • 过程或项目的各个方面必须是对结果负责任的,透明的;
    • 运用信息发射源,让这些关键信息,如产品待办事项列表,冲刺待办事项、障碍、风险和项目进展对所有的利益相关者是透明的。

    检视:

    • 团队根据项目目标定期检查他们的绩效和进展;
    • 他们不断寻找问题和计划的偏离。

    调整:

    • 基于观察期间的检查,采取必要的变更流程,以避免问题再次发生,提高项目交付成功率。

    Scrum框架由Scrum团队及其相关角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的,对Scrum的成功实施和运用都至关重要,而Scrum规则把事件、角色和工件组织在一起。

    为了方便大家记忆,我们把Scrum概述为3355。就是

    • 3个角色
    • 3个工件
    • 5个会议
    • 5个价值观

    有三种类型角色:

    产品负责人:产品负责人定义项目愿景、需求和优先级,对产品成功负责。

    Scrum Master:负责团队,并移除障碍,帮助他们实现产品负责人所设定的目标。

    开发团队:自组织、跨职能。他们协同工作,以确定如何最好地满足产品负责人的目标。

    团队中有“鸡”和“猪”的角色,“猪”的角色包括Scrum master,PO, team;“鸡”的角色是指团队成员以外的管理角色

    俩个重要特性:跨职能和自组织。

    自组织团队自己选择如何最好的完成工作,而不是由团队外的指导。

    跨职能团队拥有完成工作所需要的全部技能,不需要依赖团队以外的人。

    • 清晰地表达产品待办列表项
    • 对产品待办列表项进行排序,最好地实现目标和使命
    • 优化开发团队所执行工作的价值
    • 确保产品待办列表对所有人可见、透明、清晰,并且显示Scrum团队的下一步工作
    • 确保开发团队对产品待办列表项有足够的理解

    开发团队最佳规模是:足够小以保持敏捷性,足够大以完成重要工作。正常是7+-2,不建议小于3或者大于9。因为小于3可能会收到技能的约束,无法交付可发布的产品增量。大于9人的团队需要过多的沟通协调工作。产品负责人和sm不在这个范围内,除非他们也参与执行sprint代表事项列表中的工作。

    有自主权选择如何最好地满足目标,并且为之负责。

    Scrum Master负责确保所有人都能正确地理解并实施Scrum。因此,Scrum Master要确保Scrum团队遵循Scrum的理论、实践和规则。

    Scrum Master是Scrum团队中的服务型领导。Scrum Master帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的,通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。

    1)Scrum Master的职责是:

    在项目生命周期早期定义基本规则;

    确保团队理解干系人期望;

    同团队沟通项目愿景,有利于确保团队;

    认识到他们的目标同项目总目标紧密一致;

    以连贯的单元模式工作;

    对愿景给予承诺。

    2)Scrum Master制定的基本规则包括:

    设定Scrum仪式的开始-结束时间;

    保持对主题的专注减少分散;

    会议期间杜绝中断;

    允许团队成员特别是初级成员言论自由;

    在制定决策前应广泛搜集所有成员意见。

    Scrum的工件以不同的方式表现工作任务和价值,可以用来提供透明性以及检视和调整的机会。Scrum中的工件就是为了最大化关键信息的透明性,因此每个人都需要有相同的理解。

    ① 产品待办列表(Product Backlog)-只有PO可以修改

    ② Sprint待办列表(Sprint Backlog)-开始后,只有团队可以修改

    ③ 产品增量(PSPI:Potentially Shippable Product Increment)-要满足完成的定义

    冲刺计划会议:

    Scrum团队的所有成员出席,在此次会议中,开发团队识别当前冲刺开发交付的产品待办事项中的故事。

    这个会议时间箱为一个月的冲刺,会议时间8小时,4个小时用于选择故事和4个小时估算分配。

    由Scrum Master和开发团队参加,产品负责人可以自行选择是否参加。每日站立会议是快速专注的会议,用来分享迭代或迭代进展。

    每个团队成员就他们将要完成的任务对其他人做口头承诺。

    每个团队成员回答以下问题:

    “昨天做什么?”

    “今天将做什么?”

    “遇到了什么问题?“

    每日立会只有猪的角色可以发言,鸡的角色不可以发言这次会议时间箱15分钟,每天发生在同一时间和地点。

    这次会议是由Scrum团队的所有成员参加。

    开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。

    Sprint评审会议的结果是一份修订的产品待办列表,确定很可能进入下个Sprint的产品待办列表项。

    这个会议时间箱为一个月的迭代,4个小时,比冲刺计划会议的持续时间更短。

    冲刺评审是在迭代末期进行的时间盒(有指定时间限制)会议,此时不断变化的解决方案展示给利益相关者,他们的反馈得到收集。

    该会议是:

    针对冲刺末期召开;

    被时间盒定义到四个小时,按月冲刺和较短的时间段;

    冲刺评审会议由包括开发团队,产品负责人,Scrum Master,和企业的利益相关者的整个团队出席;这些冲刺评审会议被团队通过录音、快照来展示产品。

    是由Scrum团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括:什么进行顺利,缺少什么,需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代,3个小时,比迭代评审时间短。

    冲刺回顾是针对迭代末期进行的时间盒(有指定时间限制)会议,目的是认识团队可以如何提高他们的工作方式,就未来的迭代改进计划达成一致,该会议:

    针对冲刺末期召开;

    被时间盒定义到三~四个小时按月冲刺和较短的时间段;

    由包括开发团队,产品负责人,ScrumMaster,和企业的利益相关者的整个团队出席;在冲刺回顾中,团队将认识到他们做的好的领域以及有待改进的领域。

    来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。细节包括:什么进行顺利,缺少什么,需要改变什么等等……

    Scrum团队在冲刺中经常会面进行待办事项的梳理。

    梳理或细分是一种逐步完善待办事项的方法,所以它会保留现有信息同时反映利益相关者的需要。

    该会议有助于:

    增加新用户故事;

    丢弃不相关的用户故事;

    估算新增加的用户故事;

    重新估算用户故事;

    对用户故事进行优先级重排序;

    史诗分解成更小的用户故事。

    需要记住的点:

    梳理会议提供了调整估算范围的最佳时机;

    利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理;

    已经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相关者来评审;来自于运营和维护问题的反馈需要被考虑,新需求必须添加到产品待办事项中;识别出的现有缺陷经过分析后,需要确保他们在梳理会议上被讨论。

    开放Openness

    专注Focus,

    勇气Courage,

    承诺Commitment,

    尊重Respect

    通过事先确定一个对“完成”的共识可以为团队与业务节约大量的时间来处理反差大、模棱两可或隐藏的工作。

    这个定义也同时被用来指导开发团队了解在Sprint计划会议时能选择多少产品待办列表项。

    每个Sprint的目标都是交付符合Scrum团队当前“完成”的定义的潜在可交付功能增量。

    开发团队在每个Sprint都交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。如果开发部门制定了“完成”的定义作为规范、标准或者指引,那么所有Scrum团队都必须遵守;如果“完成”的定义还没制定,那么Scrum团队中的开发团队就必须制定符合产品的“完成”的定义。如果系统或者产品由多个团队开发,那么所有Scrum团队中的开发团队必须一起参与制定。

    每个增量都添加到之前的所有增量上,并经过充分测试,以此保证所有的增量都能工作。

    随着Scrum团队的成熟,“完成”的定义会扩大,包含更严格的标准来保证更高的质量。任何产品和系统都应该对在其上面开发的工作有“完成”的定义。

    • 信息发射源
    • 看板
    • 燃尽图
    • 障碍日志
    • 可视化图表
    • 速度

    定义:一个信息发射源在任何人都可见的地方显示信息。有了信息发射源,大家不需要问任何问题。

    有效的信息发射源

    简单:易于掌握

    突显:错误不应该掩盖,而是应该用于提高工作和性能

    当前:展示的信息必须是当前的

    转移:一旦问题被纠正,应该从图表中移除

    影响:授权团队做决定

    高度可见:容易看到和理解

    最小的数量:关键信息应该被强调

    信息发射源有助于对于成功验收、交付物的共识。

    信息发射源用来促进干系人期望管理,对当下进行的工作可见、透明。

    他们提供团队日常进展、工作质量、障碍和风险的视图。

    看板是一个跟精益和及时制生产相关的概念

    • 任务板被细分成段来反映关键活动。
    • 故事是由索引卡或代表的便利贴来表示。
    • 卡的状态由它在任务板上的位置来表示,并随着项目进展从开始到结束变化。
    • 看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指

    看板卡片

    看板任务板上的每一张卡片就是看板卡片。

    看板卡片用来显示迭代过程。

    看板任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。

    看板卡片反映所有需要被跟踪的事物。例如:用户故事,缺陷,任务。

    在用户故事定义完整前,相关干系人需要对用户故事必须经历的部分进行评估。

    及时制在制造行业很流行。及时制强调只生产、开发、交付和消耗特定时间特定量的产品,而不是堆积工作流。

    看板就是一种及时制系统,通过替换已消耗的资源来控制资源的流动。

    通过可视化和展示即将在看板面板中强调的用户故事,产品负责人可以确保用户故事正在按照及时制原则来满足“准备好定义”。

    这将确保团队已经就需求和验收标准达成共识。

    看板或任务板在项目实施期间作为信息发射源运用,它有助于相关干系人去了解冲刺或迭代的当下状态

    燃尽图

    燃尽图

    • 燃尽图显示在一次迭代或发布中的剩余工作量。这些图可以用来追踪实际速度和预期速度的对比,评估项目绩效。
    • 燃尽图用来预测团队最可能的速度,团队按照这个速度去开发即将到来的冲刺或迭代交付物,从而促进有效计划。

    发布燃尽图

    项目组在迭代末期通过更新发布燃尽图来对比计划进展。

    当曲线达到零,项目中没有更多的故事点,它已经准备好发布。

    障碍特指阻碍团队实现冲刺目标的任何因素

    障碍日志的主要方面有:

    Scrum Maters的主要职责是快速解决障碍,因为他们会直接影响团队生产力;障碍通过障碍日志得到展示,提供所有已解决和突出障碍。

    可视化图表

     

     

     

    可视化图表是信息发射源的一部分,同时也被引用为极限编程的一部分

     

     

    这些图表的特征有:

    轻松便利地给团队和其他人提供信息;

    随意,通常手绘、庞大、展示项目重要信息。

     

     

    这些图表工作时

    团队停止阅读图表;

    团队成员不再抱怨更新图表;

    他们反映项目实际情况。

    速度

     

     

     

     

    速度是敏捷项目中运用的主要度量,用来预测交付期限,它通过给在迭代中团队需要完成的用户故事增加故事点来计算。

    1、需要记住的点:

     

    • 速度是团队每次迭代完成工作量的观察,而不是估算或目标;
    • 速度是基于参考估算时间和团队规模而定,不是由时间或由团队成员以外的任何人来决定的;
    • 速度是对特定项目特定团队的跨迭代比较。

    速度举例

     

     

     

    1:团队完成了一次迭代中的4个故事,基于以下故事计算速度:

     

     

    故事A-5 故事B-3 故事C-7故事D-5

    速度等于每个用户故事所分配的故事点总和

    所以例子的速度等于以上4个数字的总和:20。

    未完成的用户故事不计入故事完成的点数

    速度测量单元

     

     

     

    速度测量单元

    速度测量单元在估算会议期间确定。测量单元有:

    故事点:如果团队基于相对规模来计划提交用户故事。理想时间:如果团队基于时间来计划提交用户故事。需要记住以下几点:

     

     

    • 只有已完成的工作进行速度计算;
    • 速度纠正估算错误;
    • 速度追踪客户满意度;
    • 速度追踪早期和持续交付。

    三、敏捷团队 干系人

     

    • 干系人管理
    • 沟通管理
    • 敏捷建模
    • 积极倾听
    • 全球化、文化和团队多样性
    • 敏捷参与式决策
    • 敏捷冲突与处理
    • 敏捷团队

    干系人管理

     

     

    干系人是:

    • 在项目中拥有股份的人;
    • 项目成果对其利益产生积极或消极影响的人;
    • 对项目有积极或消极影响的人;
    • 有效的干系人管理是项目成败中最重要的决定因素,它可以通过有效和及时的沟通实现。

    干系人管理10大原则

    1. 干系人利益需要紧密相关;
    1. 我们需要自愿精神去确保干系人参与而非组织监督来进行;
    1. 我们需要自发去寻找能够让各种干系人满意的解决方案;
    1. 我们所做的一切是为了服务干系人,我们从来不置任何其他一方干系人利益于不顾;
    1. 我们行动的目的是为了实现我们对干系人的承诺,我们充满激情地朝着目标前进;
    1. 我们需要密集沟通以及与所有相关干系人对话;
    1. 干系人组成复杂;
    1. 我们需要推广的营销方法;
    1. 我们让所有主要和次要干系人参与进来;
    1. 我们持续监控和重新设计过程去更好服务于干系人。

    沟通管理

     

     

    项目经理需要意识到影响项目成败最有价值的因素是沟通。

    敏捷强调最有效的沟通是面对面,这将促进信任和双向沟通。

     

    敏捷沟通

    敏捷识别有效沟通的需要,同时提供丰富多样的工具和检查点来促进有效沟通。

    这有助于避免目标和期望不匹配导致的项目错误。

     

    促进持续参与和干系人有效合作的会议有

    每日站立会议;

    评审会议;

    回顾会议;

    需求收集;

    计划会议;

    估算。

    随着项目推进,持续检查干系人清单确保它符合当前现状和有效性显得非常重要。

    同样,相关干系人必须参与到决策制定过程。

    敏捷建模

     

     

    敏捷建模指的是团队在实施前对过程或产品的工作流进行评审。模型可以是短暂的,自发的或一个原型。

     

     

    敏捷建模促进

    提升干系人之间的沟通;

    通过投入最少时间、降低成本去建立模型;在开发实际产品前管理期望。

    模型需要刚刚好就可以,它可以只是一个白板上的图形描绘、纸模型、投影展示或流程图。

     

     

    这些模型的重点不是完美,而是提供一个整体解决方案

    积极倾听

     

     

    积极倾听是一种要求倾听者了解、解读和评估他们听到内容的沟通技术。

    可以通过以下方式实现积极倾听

    • 给予发言者反馈;
    • 解释他们所说的内容去确认各方的理解。
    • 有效倾听的关键因素
    • 集中注意力;
    • 展示倾听手势;
    • 提供反馈;
    • 推迟点评;
    • 做出适当反应。

    全球化、文化和团队多样性

     

    随着大部分项目正在从西方国家外包,全球分布式团队已成为当今一种常态。这将涉及处理文化、多样性、语言、表情和术语的差异。通信技术的进步使得这一切成为可能。

    任何新组建的团队通常需要经历的阶段有:形成、震荡、规范、成熟、解散。文化多样性问题的建议

    文化多样性在提升团队绩效的过程中会导致延迟和困难

    为了解决这些问题,有以下建议

    1. 项目周期的早期阶段制定出差预算,因此团队成员可以短期内在同一地点开展合作,并最大限度地减少意见分歧;
    1. 开展面对面的项目启动会议,让团队能够彼此了解;
    1. 开展面对面的发布计划会议,这是团队成员常规见面的最佳机会,提高团队凝聚力;
    1. 开展文化培训,以便团队可以理解可接受和不可接受的行为;
    1. 允许每个团队成员前往现场,给他们机会进行结对编程和极限编程技术,从而提高技术知识,减少文化差异。

    敏捷参与式决策

     

     

    敏捷参与式决策指的是团队参与决策制定的过程。目标是在项目中给项目社区提供具体实践去建立框架、分析和制定不同决策。

     

     

    参与式决策的主要目标是

    • 促进目标和限制因素的清晰沟通;
    • 开放未开发的知识;
    • 发挥组织的创造力和洞察力。

     

     

    敏捷参与式决策模型

    输入型:所有参与者有机会在决策制定过程中提供输入;

    共享协作型:参与者不仅仅提供咨询参考,同时也要积极参与到达成决策的过程中。

    命令型:决策由高级领导者或者一个小群体制定,团队成员被告知决定。

    敏捷冲突与处理(一)

     

     

    冲突的五层级

    冲突是不可避免的甚至团队需要冲突。冲突的强度我们按照5个层级来区分:

    层级1最低,层级5最高,冲突层级越高,越难达成友好协议。

     

     

    第一层级:团队意识到有问题待解决,团队保持关注发生了什么改变以及如何去弥补。

    第二层级:团队成员开始有异议和冲突,团队成员疏离,进入冷战模式。

    第三层级:冲突变成竞争。人们开始寻找同盟,多种问题遗留未解决。关注点不再是解决问题、妥协,而是一定要赢。

    第四层级:冲突演变为运动。带着正义和纠正的态度,团队成员认为冲突另一方不会改变,必须打倒。

    第五层级:冲突演变成战争。没有建设性成果。

    敏捷冲突与处理(二)

     

     

     

     

       

    冲突层级

    成功应对方案

       

    层级1:问题待解决

    合作:寻求双赢

     

    共识:综合各方需求,达成一致

       

    层级2:异议

    支持:授权他人解决问题

       

    层级3:竞赛

    包容:当关系比问题重要时,遵从他人观

     

     

    谈判:如果冲突围绕着人们的价值观,这

     

    种方案无用

     

    事实依据:收集信息建立事实

       

    层级4:运动

    吸取第三方建议,将问题缓和。

       

    层级5:战争

    做所有必须的一切去阻止伤害

       

    敏捷团队-塔克曼理论

    https://img-blog.csdnimg.cn/20190705153731190.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hUMzI5OTUyMDUz,size_16,color_FFFFFF,t_70

    敏捷团队-塔克曼理论

     

    团队发展的五个阶段

    形成阶段、震荡阶段、规范阶段、成熟阶段、解散阶段,所有五个阶段都是必须的、不可逾越的,团队在成长、迎接挑战、处理问题、发现方案、规划、处置结果等一系列过程中必然要经历上述五个阶段。

     

    • 形成阶段 (Forming)项目小组启蒙阶段

    团队成员互相认识,并了解项目情况及他们在项目中的正式角色和职责;团队成员倾向于相互独立,不一

    定开诚布公。

    • 震荡阶段 (Storming)出现各种观念,形成激烈竞争、碰撞的局面

    团队开始从事项目工作,制定技术决策,讨论项目管理方法;如果团队成员不能用合作和开放的态度对待

    不同的观点和意见,团队环境可能变得事与愿违。

    • 规范阶段 (Norming)规则,价值,行为,方法,工具均已建立

    在规范阶段,团队成员开始协同工作,并调整各自的工作习惯和行为来支持团队,团队成员之间开始相互

    信任。

    • 成熟阶段 (Performing)人际结构成为执行任务活动的工具,团队角色更为灵活和功能化,团队能量积聚起来

    进入这一阶段后,团队就像一个组织有序的集体那样战斗;团队成员之间相互依赖,平稳高效地解决问题。

    • 解散阶段 (Adjourning) 任务完成,团队解散

    在解散阶段,团队完成所有工作,团队成员离开项目;通常在项目可交付成果完成之后,再释放人员解散团队。

    敏捷团队-高绩效团队(一)

     

    高绩效团队可以定义为一小群具备辅助技能的人,他们致力于共同的目标,并为了实现绩效目标自主承担共同的责任。

     

    高绩效团队(HPT)对于组织发展特别重要,在高绩效团队中团队专注于他们的目标去实现优越的商业成果。

     

    高绩效团队主要特点

    • 具备合适技能和积极性的人员;
    • 承诺和有效授权;
    • 建立信任;
    • 胜于其他团队并超过预期;
    • 保持可持续的速度去交付高质量软件;
    • 一致性和可预见的速度;
    • 具备技术水平和商业知识;
    • 具备良好的沟通技巧。

     

    虽然不是每个项目成员都能成为多面手,但是团队协同能力可以充分促进交付要求性能的提高。

    敏捷团队-高绩效团队(二)

     

    高绩效团队之多面手专家

    高绩效团队的主要特征是拥有多面手专家。

    多面手专家不仅仅在他们的核心领域具备专业知识,同时对于商业领域和技术领域也有广泛涉猎。在项目的不同阶段也许会需要一个只精通于该领域的专家,但是敏捷思维建议团队成员往多面手专家发展,比如同一个人可以肩负多个角色:项目的设计人员、开发人员、测试人员。这个灵活性有助于均衡人员资源的转移,创造高绩效跨职能团队。

     

    高绩效敏捷团队将具有以下特征

    • 参与式领导力;
    • 有效的决策;
    • 开放和清晰的沟通;
    • 价值多样性;
    • 相互信任;
    • 管理冲突;
    • 清除目标;
    • 明确定义角色和职责
    • 协调关系;
    • 积极的氛围。

    敏捷团队-授权团队

     

     

     

    授权团队会进行自我决策以适应管理的复杂性。敏捷强调具备授权和积极性的自我管理团队,他们将对项目成果充分负责。

    授权是:

    • 责任和所有权;
    • 朝着共同目标独立工作;
    • 理解为什么要做决策;
    • 衡量决策对于所有干系人的影响;
    • 创造更多权衡。

     

    授权不是:

    • 抛弃规章制度;
    • 淘汰任何说不的人;
    • 做其他人工作里有趣的部分;
    • 不考虑他人的自由决策。

    敏捷团队-团队空间

    团队空间又称作“作战室”,指的是团队进行日常工作的环境。

     

    糟糕的团队空间迹象

    糟糕的团队空间会导致团队生产力下降。通常缺乏沟通被认为是项目失败的最主要原因。

     

    糟糕的团队空间迹象如下:

     

    • 团队成员间缺乏互动;
    • 根据职位安排座位;
    • 墙上陈旧的设备;
    • 团队成员戴着耳机;
    • 专注家具布局多于创建团队空间;
    • 工作区缺乏信息发射源;
    • 缺乏吸引力的空间。

     

    关注点应该放在减少分散去避免沟通差距,以此来持续交付预期成果和价值。

    敏捷团队-集中式办公

    集中式团队在同一地点共同工作。集中式团队的特征如下:

    每个团队具备所有需要的技能;

    团队独立工作,合作式去协调工作。

     

    集中式团队

    • 团队成员全部在一个空间内,创建  作战室  ;
    • 问题得到非正式的及时解决;
    • 偶尔的互动会激发生产力;
    • 团队基于冲刺目标来确定角色;
    • 他们遵循  洞穴和共享  模式:
    • 洞穴:用于进行电话,简短的会议,或用于集中团队成员;
    • 共享:共享区域作为团队渗透式沟通的地方。

     

    渗透式沟通

    渗透式沟通指的是听到的信息在团队房间区域流动,其中一些被吸收,这是集中式团队带来的好处之一。没有障碍影响整个工作区域信息的流动。因此,在这样的环境中,渗透式沟通自然而然地发生。

    敏捷团队-敏捷领导力

     

     

    作为一名成功的敏捷领导:

    • 行为模式:应该遵循一个领导者四大最有价值的特点:诚信,前瞻性,竞争力和激励性;
    • 创建和传达愿景:一个领导者应该结合组织目标,确定未来明确的目标或愿景;
    • 激发他人行动:一个领导者要建立信任树立合作,通过授权激发他人。
    • 挑战现状:一个领导者应该通过挑战任务寻找创新方法来改变,成长。
    • 定位合适的人,并鼓励他们:一个领导者应该认识到团队的贡献并肯定个人才能。

     

    服务式领导力定位领导者作为推动者

    • 帮助团队;
    • 移除团队面临的障碍;
    • 给予他们需要的工具和技能去保护他们远离不必要的干扰。

     

    敏捷服务式领导力

    服务式领导力对任何项目都有价值,不管什么方法。而且在敏捷中它是必须的

    原因如下:

    • 敏捷坚信自我管理的团队,他们不需要任务管理的帮助,但是需要帮助去凝聚、组建。
    • 敏捷管理者用他们的行为去满足团队需要,同时愿意去帮助团队实现目标。
    • 在敏捷团队中价值应该被珍视,包括信任、同理心、协作等。

    四、敏捷方法和工具

     

     

    • 项目规模测量
    • 不确定性椎
    • 优先级技术
    • XP
    • 价值流图
    • Timebox
    • 累计流图
    • 敏捷问题检测
    • WIP

    项目规模测量-故事点

    故事点是描述一个用户故事及其相关努力总体规模的测量单元。

    1)故事点:

    • 是相对测量;
    • 用户故事的故事点互相进行对比;
    • 故事点是团队运用计划扑克等估算技术确定的;
    • 故事点对一个项目来说是独特的,不能同其他项目相比较。

    2)分配故事点需要考虑的:

    • 任务规模-故事规则取决于以下因素:复杂性、投入量、风险大小
    • 相对价值-故事点是规模的相对测量,绝对值不是很重要。
    • 估算-估算运用基准来完成,相对值被运用。
    • 选取最小故事估算价值为一个故事点。
    • 选取中等规模故事分配5个故事点。

    3)故事点估算的步骤:

    • 用户故事拆分为更小的功能,并确保每个故事具有投资属性。理想情况下,每个故事应该由1个人占用不超过2天的时间完成。
    • 确定团队达成共识的故事作为基线,创建它的故事点价值。
    • 将所有其他故事卡片同基线故事对比。
    • 每次迭代末期,将故事点同故事卡片上记录的校准。

    4故事点之类比估算:

    • 故事点估算可以通过对比来有效完成。类比估算中需要考虑:
    • 将一个用户故事同其他故事对比
    • 基于精确性,如果故事A同故事B类似,他们的估算也将类似。
    • 创建多层面基准
    • 当2到3个不同的规格设定为基准时,一个可能的比较是:故事A比故事B规格大,但是却小于故事C,如果故事C大,故事B小,那么故事A接近于中等规格。

    项目规模测量-理想日

    1)理想日估算将会回答实施故事所需时间的问题,它需要考虑:

    正在进行的唯一任务;

    没有中断;

    所有需要的信息都可用。

    一旦理想日估算达成,经过几天潜在干扰后它将被转化为实际时间。

    在极限编程中,理想日被称为完美编程日。

    2)在理想日估算被转化为实际时间时会遇到很多干扰,以下是影响理想日的因素:

    培训、评审、采访、会议、电话、管理评审、邮件、bug修复、生病、示范

    在正常的工作的8小时内,一个开发人员可能会只花5小时在编程工作上。然而,即使开发时间估算在8小时或1天的工作时间,实际时间也可能接近1天半时间。

     

    故事点VS理想日(优点)

    故事点

    • 有助于驱动跨职能行为;
    • 故事点估算不会衰变;
    • 纯规模测量;
    • 故事点估算时间很低;理想日
    • 同样的团队内理想日有差异;
    • 理想日在团队外部容易说明;故事点更加抽象;
    • 理想日迫使公司面对浪费时间的活动。

    项目规模测量-宽带德尔菲

    1)宽带德尔菲技术用来收集关于项目规模的准确估算

    • 项目经理选择一个估算团队,组织专家,通过一系列会议就估算达成一致。
    • 在项目经理收集个人估算后将汇总发送给团队成员,估算匿名完成。
    • 如果估算差异很大,另一次迭代(重新估算)进行。
    • 缺点是相对常用估算技术例如专家判断、类比估算等,它要求更多精力和协调去进行估算。

    2)宽带德尔菲的步骤

    • 团队选择:选择负责估算的专家团
    • 启动会议:计划启动会议去说程序和落地规则
    • 个人准备:允许团队成员针对每个任务个人收集初始估算
    • 估算会议:实施一系列迭代步骤组成的估算会议
    • 配置任务:收集个人估算,编译最终清单
    • 任务评审:评审估算程序、最终任务清单和假设的结果。

    3)宽带德尔菲技术之计划扑克

    计划扑克是宽带德尔菲技术的变化模式,整个团队协同合作估算每个用户故事需要的投入。在计划扑克会议中:

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

    项目规模测量-亲和估算

    亲和估算是一种被团队成员用来估算大规模用户故事的技术。

    1)亲和估算的优势

    • 快速简单;
    • 决策制定过程透明可见;
    • 它创造了一种积极合作的体验而非对抗性。

    2)亲和估算的步骤

    • 沉默的相对尺码
    • 产品负责人提供产品待办事项
    • 故事水平排列在墙上
    • 团队成员考虑执行中的努力,对比墙上物品对每样物品进行规模定义
    • 团队安静地执行以上步骤,不讨论技术或者特性问题

    3)编辑墙

    • 故事卡片的规格在这一步里编辑
    • 基于设计讨论和其他团队成员的投入,故事卡片根据相对尺码移动

    4)将物品置于相对尺码栏

    根据团队决定使用的分栏命名,把相应的规模置于墙上。

    5)产品负责人挑战

    一旦团队完成估算,产品负责人可能会不认同某些估算,如果团队决定一个物品必须重新进行规模估算,它可以通过以下:

    • 将它置于独立的墙上重新进行规模估算
    • 立即同产品负责人决定新规模

    6)储备数据

    • 数据被记录和储备,意味着亲和估算流程的结束。

    项目规模测量-T恤尺码估算

     

     

     

    一种流行的敏捷相对估算技术:(中码,大码,加大码等)

    1. 操作简单;
    1. 介绍团队使用相对估算的好方法;
    1. 亲和估算非常有效
    1. 在进行用户故事估算前,每个T恤尺码的基准需要由团队决定。

    不确定性椎

     

     

     

    不确定性椎的图示

    不确定性椎展示了估算准确性在不同阶段的提高:

    https://img-blog.csdnimg.cn/20190705153734282.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hUMzI5OTUyMDUz,size_16,color_FFFFFF,t_70

    优先级技术

     

     

    优先级排序的重要目的是识别高价值特征(功能)并且使它们得到优先交付,这将有助于组织为客户提供最大价值。

     

    优先级排序同样有助于:

    • 决定团队开展工作的顺序
    • 调整范围去满足预算或时间目标的同时保留一系列有用特征(功能)
    • 决定迭代计划、版本计划和新需求进入
    • 决定无价值的低优先级任务并避免团队去执行优先级要素

    进行需求优先级排序时需要考虑的要素如下:

    • 特征交付的财务价值
    • 开发新特征的成本
    • 开发新特征导致的风险
    • 在开发新特征时团队获得的学习量
    • 学习意义和新知识

    优先级技术

     

     

    产品负责人、商业干系人和团队必须对即将实施的技术以及每个与优先级相关的基本原理有清晰的认识。

    他们需要关注和确保优先级的定义没有改变或者稀释项目过程。

    以下是敏捷中运用的3种优先级技术:

    • MoSCoW技术
    • Kano模型
    • 相对量级

    备注:修剪待办事项是指持续对待办事项进行优先级排序的过程。

    优先级技术-MoSCoW

     

     

     

     

    动态系统开发方法(DSDM)是一种运用MoSCoW技术来进行

    需求优先级排序的敏捷方法。

    在这种技术下,需求基于以下方面排序:

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

    在开始新一轮时间箱前,会有一个新的MUSTs加入。这些可能是新的需求,或者现有需求被调整优先级进而转移成为MUSTs.

    优先级技术-Kano模型

     

     

    Kano模型是由Noriaki Kano教授开发。该模型致力于满足需求确保客户满意。

    用这种技术,需求根据以下几方面来进行优先级排序:

    基本需要

    性能需要

    愉悦需要

    Kano模型类别

     

    Kano模型四个类别如下:

    门槛(必须具备):产品必须包含这些特征(功能)才算是成功的

    线性或性能要求:客户满意度与特征(功能)成正相关,但并不是必须的

    愉悦要求:这些特征(功能)提供极大的满意度,经常增加产品的额外价值,但是缺少这些特征(功能)不会使客户的满意度降到正常水平之下。

    淡漠:这些特征(功能)对客户来说最不重要。他们将不会产生任何商业价值。

    优先级技术-相对量级

     

     

    相对量级技术由Karl Wiegers 开创。这种技术是基于成本、风险和处罚

    后能提供最大益处的特征(功能)应该拥有最高优先级

    该技术的关键要素:

    Ø一个特征(功能)的优先级和它提供的价值成正比,而和它的成本及

    实施相关的技术风险成反比。

    Ø每一类使用1-9的规模

    Ø益处将反映特征(功能)如何体现价值,同时处罚将反映特征(功能)

    缺失时客户体验到的消极感受

    Ø此外,风险反映实施特征(功能)的挑战,成本反映实施该特征(功

    能)的实际成本。

    XP

     

     

    该编程法用于:

    快速响应需求变化的高成本;

    建立强大的工程实践去提升软件质量。XP的软件开发方法引入了许多革命性的概念成为了现在的标准实践。例如:测试驱动开发、持续集成、迭代、用户故事

     

    极限编程的5个核心原则

    沟通

    简单

    反馈

    勇气

    尊重

     

    极限编程实践

    精细反馈:包括结对编程、计划游戏、测试驱动开发、整个团队;

    持续过程:持续集成、重构或设计改进、小版本;

    共同理解:编码标准、集体代码所有、简单的设计、系统隐喻;

    程序员福利:可持续发展步伐。

    价值流图

     

     

    价值流图的流程

    1. 价值流图是可视化的过程地图,又称为价值流程地图。价值流图流程如下:
    1. 识别即将要分析的产品或服务;
    1. 通过识别步骤、序列、延迟和信息流来创建当前过程的价值流图;
    1. 评审地图去寻找延迟、浪费和限制;
    1. 通过消除延迟、浪费和限制来创建未来即将实现的优化状态的价值流图;
    1. 开发路线图去实现未来状态;
    1. 计划在未来重审过程去持续校对和优化。

     

    价值流图的步骤

    1. 识别过程的开始和结束点;
    1. 识别高层级步骤、库存和序列;
    1. 识别支持群体和替代流;
    1. 根据增值和非增值活动分类;
    1. 消除或减少非增值步骤,优化过程。

    Timebox

     

     

    时间箱用来给活动设定固定的时限:

    • 它让其他特征例如范围不同;
    • 在时间箱里,如果有任务不能在时间箱内完成,他们将被顺延到下一阶段;
    • 时间箱确定迭代和冲刺间的速度;
    • 它常被用来scrum、冲刺、迭代等会议。

     

    时间箱的最佳实践

    • 时间箱可以有任何的持续时间:1年、1个月等等;
    • 在时间箱的最低层次(15分钟)实现控制;
    • 如果一个任务落后于进度,它将被顺延到下一个时间箱;
    • 时间箱确定了迭代的长度,团队确认多少特性在那段时间交付。

     

    时间箱的优势

    • 专注:时间箱有助于在一段特定时间内专注当下手头工作;
    • 增加创造力:确定固定时间,专注识别的工作有助于工作更加高效,同时有助于减少帕金森以及小学生定律的拖延症现象;
    • 时间的价值实现程度:确定固定时间有助于识别在特定时间内完成的工作量减少荒废时间;
    • 可用时间:有助于对于完成任务的可用时间有清晰认识。

     

    帕金森定律:为了去填充可用时间,工作是会自动膨胀的。

    小学生定律:人们总是习惯在最后期限前开始启动工作。

    累计流图

     

     

    累积流量图

    累积流量图由精益思想的创始人Don Reinertsen和David Anderson引入。

    累积流量图是追踪和预测敏捷项目的重要工具;它从不同方面描述工作:总范围、进行中和已完成的;相同的报告可以提供对于燃尽图、周期时间、在制品和瓶颈的洞察

     

    累积流量图-小定律(又译:利特尔法则)

    累积流量图有助于确定系统库存数量,小定律表明在一个既定的在制品水平,在制品与前置时间之比等于吞吐量。

    https://img-blog.csdnimg.cn/20190705153728797.jpeg

    敏捷问题检测

     

     

    任何项目的成功都取决于团队如何迅速和有效地解决问题。通常,一个高度关注运营的团队不能做到发现和解决问题。

    如果问题没有得到解决,它会随着时间持续增加导致延误和返工,从而破坏项目进度。

    在敏捷中可以有各种各样的仪式或会议来识别和解决问题,然而以下会议专注问题检测:

    每日站立会议:每日站立会议的第三个问题——“有没有障碍阻碍任务完成?”

    冲刺回顾会议:敏捷有助于积极解决问题,确保及时决策让团队交付成果。

    问题检测技术:

    鱼骨图、5whys、控制图、前置时间和循环时间,漏筛缺陷、在制品

    敏捷问题检测-鱼骨图

     

     

    鱼骨图又称石川图或因果图:

    它是一种快速有效识别问题或缺陷的根本原因分析方法,采取纠正措施的方法;经常同5whys工具结合起来使用;

    适用于任何类型的问题,有助于识别问题的所有可能原因;用来识别过程领域促进改进;

    在这种技术中,原因来自主要的类别,分支来自主要问题或效果。合成图之后形状类似于鱼骨。

    鱼骨图图示

    https://img-blog.csdnimg.cn/20190705153734825.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hUMzI5OTUyMDUz,size_16,color_FFFFFF,t_70

    在制品(WIP)

     

     

    在制品指的是团队已经开始进行但还没完成的需求。

    敏捷原则建议受限需求成为在制品。一系列长的在制品清单导致:

    • 沉没成本(投入的金钱没有产生任何价值);
    • 需求变更带来更多返工;
    • 隐藏的问题区域导致找出问题变得困难。

    看板任务板被用来对在制品数量进行可视化和限制管理,缺少它将导致:

    • 团队试图去承担比实际能力更多的需求;
    • 识别确定障碍变得困难。

    下图展示了带有在制品界限设置的看板任务板,挑选的类别在制品设置为3,这表示,在任何时间点,团队要完成的卡片任务不超过3个。

    https://img-blog.csdnimg.cn/2019070515373437.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hUMzI5OTUyMDUz,size_16,color_FFFFFF,t_70

    五、敏捷项目 项目群

     

     

     

    • 敏捷项目管理
    • 敏捷项目计划的多层面
    • 敏捷项目向组合级看齐
    • 发布计划
    • 敏捷产品路线图

    目管理(一)

    敏捷项目管理(APM):由Jim Highsmith所著的一书敏捷项目管理,试图扩大敏捷技术为一个整体

    敏捷项目管理:

    引入敏捷项目管理步骤同PMI所采用的项目管理步骤结合;调整传统铁三角强调价值和质量,创建敏捷三角。

    传统铁三角:范围、成本、进度

    敏捷三角:价值、质量、制约因素(成本、进度、范围)

    敏捷铁三角:进度、范围、成本

    敏捷项目管理还指出,价值是外在的,可通过交付功能来体现,质量是内在的。

    项目管理(二)

    敏捷项目管理框架

    构想:确定产品愿景,项目范围,项目群体以及团队如何一起共事。

    推测:开发基于特性的版本,里程碑和迭代计划去交付愿景。

    探索:在短时间内交付已测试的特性,持续致力于降低项目的风险和不确定性。

    适应:评审交付的结果,当前形势,团队绩效和必要的调整。

    结束:结束项目,传递主要经验教训。

     

    APM和PMBOK

    Michele Sliger将敏捷项目管理框架同PMI项目管理知识体系对齐,具体如下:

    启动过程组对应设想

    计划过程组对应推测

    执行过程组对应探索

    控制过程组对应适应

    收尾过程组对应结束

    项目计划的多层面

    敏捷项目中计划的多层面通过计划洋葱圈来表示。

    最外层:战略层面。战略层面包含领导达成一致的整体商业目标和路线图;

    第二层:产品组合层面。产品组合计划包含能实现战略规划愿景的产品;第三层:产品层面。产品计划包含产品负责人对于发布系统的演变计划;第四层:发布层面。发布计划考虑支撑产品计划的每次发布的可交付物和特性;

    第五层:迭代层面。迭代计划考虑将特性转换成工作的任务,测试软件,发生在每个迭代的开始。

    最里层:每日层面。日常计划由每日Scrum和工作活动组成。

    向组合级看

    敏捷项目支持项目组合的愿景和目标,可以持续数年。这是通过:主题和史诗,发布,迭代,用户故事来实现。

    主题和史诗用来支持项目组合或者产品路线图的长远愿景;发布用来支持产品路线图;

    迭代和冲刺支持版本;

    用户故事定义迭代内容。

    发布划

    1、发布计划表明团队在已识别的项目目标和限制因素下如何实现产品愿景。

    发布计划传达了跟正在开发的产品相关的关键信息,它们将:

    • 有助于产品负责人和团队去确定创造产品所需要的时间;
    • 传达期望;
    • 作为路标服务;

     

    对于没有历史速度参考的新项目来说,发布计划的完成通过与类似项目比较,或者通过类比估算确定速度,或通过实施一些迭代来确定速度;

     

    发布计划的目的是定义一个产品发布的版本或者一个具体可交付产品的增量。

    发布计划有2个必须的关键信息:

    • 制定发布计划的步骤团队的平均历史速度;
    • 一个发布计划内的迭代次数。

    敏捷产品

     

    产品路线图是用一个计划好的方法去帮助战略性规划和计划中重要产品里程碑的沟通。产品路线图:

    1.是任何产品战略的组成部分;

    2.为规划变更提供框架;

    3.管理变更对产品的影响;

    4.代表长远的产品愿景或者产品目标。

    六、敏捷精益价值观 原则

    • 敏捷宣言
    • 敏捷原则
    • 精益7个原则
    • Kaizen

     

    2001年敏捷宣言:

    我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人,由此我们建立了如下价值观:个体与互动 重于 流程和工具

    工作的软件 重于 详尽的文档

    客户协作 重于 合同谈判

    响应变化 重于 遵循计划

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

    敏捷原则

    ① 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意

    ② 欣然面对需求变化,即使在开发后期也一样,为了客户的竞争优势,敏捷过程掌

    控变化

    ③ 经常地交付可工作的软件,相隔几个星期或一两个月,倾向于采取较短的周期

    ④ 业务人员和开发人员必须相互合作,项目中的每一天都不例外

    ⑤ 激发个体的斗志,以他们为核心搭建项目,提供所需的环境和支援,辅以信任,

    从而达成目标

    ⑥ 不论团队内外,传递信息效果最好效率也是最高的方式是面对面的交谈

    ⑦ 可以工作的软件进度的首要度量标准。

    ⑧ 敏捷过程提倡可持续开发,责任人、开发人员和用户要能够共同维持其步调稳定

    延续

    ⑨ 坚持不懈的追求技术卓越和良好设计,敏捷能力由此增强

    ⑩ 以简洁为本,它是极力减少不必要工作量的艺术

    ⑪ 最好的架构、需求和设计出自自组织团队

    ⑫ 团队定期地反思如何能够提高成效,并依此调整自身的举止表现

    精益7原则

    F消除浪费:对客户没有带来价值的事务就是浪费

    F增强学习:通过短期迭代周期、重构、集成测试和频繁的客户反

    馈会议增强学习。

    F较迟决定:管理不确定性的最佳方法是收集信息,最后的责任时

    刻给予承诺,打破部件间的依赖关系。

    F尽快交付:短期迭代或者小批量提供有价值的反馈机会,促进有

    效的决策制定。

    F团队授权:精益专注于团队,因为决策制定和管理的来源让团队

    了解最佳选择和成本。

    F建立整体:确保质量是嵌入在整个系统的,系统需要构建自动化

    测试,安装和持续集成。

    F目光长远,脚踏实地,快速失败,快速学习。

    kaizen

    Kaizen-介绍

    Kaizen是个日本词语,指的是持续改善的意思。这个技术被各行业组织

    用来进行竞争策略开发。

    Kaizen倡导个人在所有层面的广泛参与,每个人都被鼓励持续做出改进。

    Kaizen原则之一是大成果来自于小改变,这有助于在减少浪费的同时提

    高生产力、效率和创新力。

    为了支持持续改进的概念,组织需要在培训、学习资料和持续监督上做投入。

     

    Kaizen-主要方面

    长远思考、减少浪费、高质量、低成本、授权、灵活实践、及时制、客户关注、团队工作

    七、风险管理

    • 风险管理生命周期
    • 风险日志
    • 风险燃尽图
    • 逐步减少风险
    • 小试验-探测

    风险管理生命周期

    1. 风险识别:在日常Scrum中,进行回顾、需求研讨、迭代计划和迭代评审。
    1. 风险评估:捕捉可能性、影响。
    1. 风险响应:回避、减轻、转移、接受。
    1. 风险评审:在回顾会议中进行。

    第一步-风险

     

    项目中的风险识别可以在以下阶段发生:

    需求收集:团队和产品经理讨论新想法按照价值最大化风险最小化的方式去考虑和调整需求。

    计划扑克:团队估算每个用户故事的相对规模。拒绝超过一定规模的用户故事有助于减少风险。

    迭代或冲刺计划:团队识别、评估和响应风险。团队同产品负责人一起工作去最大

    化产出,降低失败风险。

    Scrum会议:团队识别风险和问题。团队成员增加风险到风险板,记录已获得同意

    的响应计划。

    迭代或冲刺评审:团队讨论风险。团队成员应该特别标注出成功的风险减轻、回避活动,同相关干系人分享。

    回顾会议:团队讨论已成功处理的风险、风险再次发生的几率,在接下来的迭代和冲刺中风险减轻应对有哪些不同。

    第二步-风险评估

     

     

     

    风险评估-风险板

    风险板是用来提供风险对团队和相关干系人可见的信息发射源

    风险板提示了以下信息:

    已识别的风险;

    概率;

    影响;

    风险响应。

    风险板应该作为日常Scrum或者冲刺迭代末期回顾的一部分来进行定期评审。

    风险板举例如下:

    https://img-blog.csdnimg.cn/20190705153734513.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hUMzI5OTUyMDUz,size_16,color_FFFFFF,t_70

    第三步-风险响应策略

     

     

     

    1)回避:

    改变项目计划,以消除风险或其存在的条件,或保护项目目标不受其影响,或对受到威胁的一些目标放松要求。

    有些风险事件在项目早期发生,可以通过澄清要求、获取信息、加强沟通或取得专家意见等方法处理。

    2)减轻:

    降低不利风险事件发生的概率和/或影响,到可接受的临界点。

    及早采取措施比事后努力弥补要有效得多。

    3)转移:

    将后果连同应对的责任转移给第三方承担,不是消除风险。

    最适合用在财务风险上(如:票据贴现)。

    总会涉及为风险承担支付保险费。

    4)接受:

    项目团队已决定不为处理某种风险而变更项目管理计划,或者无法找到任何其他的合理应对策略。

    可以是被动或主动的。

    被动地接受风险,只需要记录本策略,而不需要任何其他行动,待风险发生时再由项目团队进行处理。

    最常见的主动接受策略是建立应急储备,安排一定的时间、资金或资源来应对风险。

    第四步-风险评审

    在风险评审阶段,团队会面对评审突出风险,重新评估风险承受力,讨论风险响应有效性

    其成果可以用来细化总体风险管理策略。

    风险评审核心关注点是:

    积极风险通过每日scrum进行评审;团队需要提供风险管理过程的反馈;评审风险影响和项目风险实际情况。

    风险评估的目的是使风险可见,定期监测它们,优先考虑风险问题,提高问责制,鼓励行动,跟踪和解决所有权和解决状态。

    风险燃尽图

    燃尽图是一种描述项目风险趋势的简单的图形化风险指标

    燃尽图的特点是:

    1. 这个表通过测绘迭代或时间风险承担总量以及风险普查的预期货币价值创建;
    1. 项目过程中风险应该有一个线性下降;
    1. 每次迭代应该通过交付用户故事来减轻或消除风险板上的风险。

    https://img-blog.csdnimg.cn/20190705153733601.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hUMzI5OTUyMDUz,size_16,color_FFFFFF,t_70

    小试验-探测

     

     

     

    探测是在极限编程中创新开发出来用于消除不确定性的工具。

    探测是在一个时间箱限定的时间内通过学习特征、技术或者过

    程来减少不确定性。这有助于更好地估算和开发即将到来的特

    性或修复缺陷。

    探测:

    1. 有助于通过进行尽早的可能性假设来降低项目风险;

    2. 应该要求最少的时间和努力,或者不超过2天的时间;

    3. 应该通过在产品待办事项中创造一个故事来让它可见;

    4. 必须谨慎使用,因为他们不创造故事点。

    8、答题技巧

     

     

     

    • 答题技巧

    考试中的敏捷团队是一个理想化的团队(团队的成员都是积极向上的,多职能的,都是能去主动领任务并积极完成的,站会都是积极参加的,团队内部是团结的,SM和PO是不会惩罚团队的,用温和的方式改善团队中出现的问题,用鼓励和支持让团队前进。)

    1、牢记敏捷价值观、原则

    2、太绝对的词要考虑仔细(参考英文作答,有时候可能是翻译问题)

    3、团队可以决定很多事

    4、站会不解决问题只暴露问题

    5、回顾会,发现和解决迭代中的问题

    6、两个选项都对,选最合适的那个

    7、仔细审题,找到关键词

    8、“协调”、“协商”、“讨论”、“鼓励”、“一起解决”、“指导”、“引导”、“教练”一般70-

    80%是对的(具体问题具体分析)

    9、“上报”、“管理”、“要求”、“必须”、“举报”、“解雇”、“竞争”一般70-80%是错的(具体问题具体分析)

     

    【注意】我们考的是ACP,不是PMP,如果有两个选项你觉得都对,A选项偏传统,B选项偏敏捷,一定选B选项,不是说A不对,只是B更敏捷。大家在考试的时候,就题论题,只针对题目作答。不要发散思维,不要钻牛角尖。

     

    展开全文
  • 全世界只有不到 1% 的人会朝着自己的梦想行动 你真是个特别的人 ...这个问题其实是在问:你的敏捷是流于形式还是将敏捷内化到企业文化? 那么,什么是Doing agile,什么是Being agile? Doi...

    全世界只有不到 1% 的人会朝着自己的梦想行动

    你真是个特别的人

    敏捷正在被越来越多的公司所接受,因为它可以实现:

    减少浪费,提前降低风险,快速交付工作软件,适应不断变化的需求。

    你的企业是在Doing agile还是在Being agile?这个问题其实是在问:你的敏捷是流于形式还是将敏捷内化到企业文化?

    那么,什么是Doing agile,什么是Being agile?

    Doing agile vs Being agile

    从字面意思,我们很容易理解:Doing 强调的是“做”,是具体的实践;而being是“成为”,由内而外的最终呈现结果。Michael Sahota曾经用一副简单的对比图,形象地描绘了Doing agile和Being agile 的区别:

    详细一点,在Doing Agile中,团队确实在敏捷思想的指导下进行着每日站会,计划会,回顾会,评审会等,快速地迭代着,最终会取得大约20%的收益。比如:产品的质量得到提升,客户满意度提升,产品生命周期加速等指标明显提升。

    而Being agile意味着,团队成员养成了敏捷的思维,组织的整体自下而上形成了敏捷的机制,这时团队从中的收益不仅仅是20%,而是3倍之多。具体表现在:整体协助的提升,团队氛围的改善,团队成员有很强的自驱力等。

    我们能看到,目前市面上执行敏捷的企业很多,朋友圈微信群大家在讨论自己组织的敏捷有遇到哪些障碍,从中我们不难看出,很多的企业正在Doing agile的路上,他们或许还不能意识到Doing agile 和Being agile的真实体验,因为浮于表面的形式迷惑了很多身在其中的执行者,那么Doing agile在哪些方面有明显的缺陷呢?

    Doing agile的缺陷

    “Doing agile”中,团队成员在积极地进行敏捷的各种实践,比如Scrum的3355,他们背下了Scrum指南,他们开了各种会,但是他们并没有去了解Scrum3355设置的原因,不理解各种会议的各自目标和互相结合机制。Doing agile时,团队永远不会去探索如何去量身定制需求,如何采用最佳的敏捷实践,因为他们只是关注流程,关注使用的工具。这违背了敏捷宣言中的“个体和互动高于流程和工具” 。

    另一个缺陷则是严格的计划和限制性的合同,敏捷思维告诉我们在任何给定的时间段里都能够随时做出变化,以便于尽快提供最大的价值。在软件项目中,存在的未知数较多,所以严格的计划和限制性的合同阻碍了团队和用户之间的协作,这违反了敏捷的思想。相反,如果产品交付团队与用户之间能够进行更多的对话和反馈,这是有助于团队提前预知很多风险,并根据其价值对相关功能进行优先级排序。

    Being agile的好处

    Being agile意味着采用正确的原则和实践,并将其应用于适应不断变化的情况和不同的客户,听起来有点绕口,其核心其实是完全体现在我们的敏捷四大宣言中的,敏捷的价值观是侧重于人员和流程与工具之间的互动,是工作产品而非文档,是客户协作而不是合同谈判,以及响应和适应变更而不是遵循计划。

    这里需要注意的是,大家很容易陷入一个既定的流程里,我们需要调整自己进入交互式,增量式,经常变化和适应性的协作过程。尽管四大宣言看起来像省略了很多,但它的设置是有助于团队获得所有权,让团队成员以主人的身份参与其中,以此来增加最终产出的有效性和可靠性,当被认为是一个主人翁时,这个成员也会更有责任感。

    同时,愿意考虑变革的组织其实也很欢迎独特的创意与更多的创新,那么设计师和开发人员是可以将客户的需求进行内化,产出更多有价值的创新产物。

    总而言之,采用Being agile 的经验过程可以带来客户满意度和卓越的发展 - 这也是组织转向敏捷的重要原因。

    如何真正做到Being agile ?

    • 从上至下的打通,得到领导者的支持,有利于敏捷文化在内部的畅行。
    • 一套完善的激励员工体制,让员工自发地进入敏捷转型中,形成一个自组织自管理系统。
    • 一份思维清单:让敏捷能够立即得到执行的实践清单!

    总结

    很多企业的敏捷转型流于形式,对于团队一线员工来说,或许只是监督工作甚至压榨劳动力的手段,他们被迫接受各种仪式,设置Scrum Master,Product Owner的角色,两周的迭代,机械地按照流程按部就班,日复一日,习惯的工作模式让自己感觉到:我已经敏捷了。

    然而,这还远远没有把Agile的魅力发挥出来!

    他和他们的团队还可以做得更好!

    当企业打算引入敏捷来改变团队现状时,管理者必须要拥有全局的视野,站在更高的位置去看待这场变革。从业务需求开始,到产品研发,到最后的测试交付,端到端的打造完整的“Being agile”系统,自上而下,一贯而成,方能实现敏捷的真正效用。

    2018年度Ethan Soo讲授的《敏捷领导力4.0 | 从爆品设计到高效交付的全新升级&完整打法》(戳链接了解课程详情),将会为每个管理者带来敏捷全新视野,站在全局的角度,教给大家端到端的敏捷落地打法。

    深圳站即将开班,还有少量(<5位)名额,赶紧报名吧。。。

    本课程将会给管理者带来一套敏捷在整个企业实施的方法,帮助更多企业在中国市场有效地落地变革,协助管理者打造快速反应的敏捷战队,把敏捷理念运用到产品的整个生命周期,培养团队持续打造爆款产品的能力,实现真正的Being agile!

    课程涵盖:解读“小米爆款模式”、爆款产品设计思维、精益创业、快速低成本验证市场、快速进入市场、打造闪电式研发组织、Scrum落地与实施,规模化敏捷、科学有序落地变革。

    报名电话:18201807014 或 添加小助手微信ccgimjxdp。

    展开全文
  • 分析认为,阿里的物联网宣言打破了之前通讯巨头对物联网领域的把控,将刺激腾讯、京东、小米等的跟进,引爆物联网生态之战。本期的智能内参,我们推荐来自中信建投的2018年物联网策略报告,从政策、产业、技术和需求
1 2
收藏数 26
精华内容 10
关键字:

敏捷开发四大宣言解读