2018-06-28 16:23:04 sun491922556 阅读数 1749
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

在Scrum敏捷开发中有三种主要的角色:

Product Owner(产品负责人,简称"PO"); 

Scrum Master(敏捷教练); 

Team(团队)。

其中,Scrum Master是其重要的角色之一。那么今天我们就来探讨一下如何做一个合格的Scrum Master。

Scrum Master在许多的项目开发中被视为项目经理,这其实是个误区。同时我也经常看到有人主张将Scrum Master与项目经理完全区分,对于此我也不太同意。在我看来Scrum Master虽然并非项目经理,但是仍然肩负着很多项目经理的职能。那么Scrum Master的职责究竟是什么呢?该怎样做才能成为一名合格的Scrum Master呢?以下六项,供您参考。如有不妥之处,欢迎探讨;)

管理Scrum流程


这是Scrum Master最核心的职责,也是Scrum Master区别于项目经理的最显著的特征。Scrum Master需要维护每个sprint的流程,确保每个sprint能够顺利的实施以及完成。

首先,Scrum Master负责主持召开sprint期间的每一个会议,包括sprint plan meeting, daily scrum meeting, sprint grooming meeting,sprint review meeting以及sprint retrospective meeting。

另外,Scrum Master还需要帮助PO建立product backlog与sprint backlog,并确立其中每个story的优先级。

最后,Scrum Master还需要帮助Team清除在开发的过程中遇到的障碍。Scrum Master应该有一个block list用来记录Team在开发中遇到的问题障碍,由Scrum Master自己进行管理并最终使得列表中的每一问题得到及时处理。

保护团队


Scrum Master应该最大限度的保护Team,以确保Team不会被外界,尤其是PO干扰。那么Scrum Master该如何保护团队呢?Team在什么情况下需要保护呢?

在每个sprint的初期制定计划的时候,Scrum Master应合理的根据Team的工作能力以及过往经验,承诺工作量。不要盲目乐观的给PO承诺过量的工作。我就遇到过有的Scrum Master可能是对于Team的能力估计不足,也可能是希望通过承诺更过的工作获取老板的芳心,承诺了太多的工作,结果导致Team在sprint的后期连续加班,致使Team的效率严重降低。同时由于时间的匆忙,急于交付,导致了项目的质量很低,最终形成了恶性循环。一个好的Scrum Master在这个时候是应该要懂得如何与PO“周旋”,获取合理的工作量。这里的“周旋”并非消极怠工,故意减少Team的工作量,这其实是通过安排合理的工作量来使团队达到最大的工作效率,同时不会伤害Team的积极能动性。这是一个良性的循环。

我们都知道,需求的变更对于每一个开发人员来说都是噩梦,而敏捷诞生的其中的一个很重要的原因就是为了解决这一问题,让开发者拥抱变化。然而在我们采用敏捷开发的项目中,经常可以遇到Product Owner越过Scrum Master,直接找到Team, 对他们指手画脚,发号施令。这个时候,Scrum Master应该像“猛兽”一样将PO“吼开”,以避免Team受到“伤害”。需求改变可以,但是不应该在sprint的过程中干扰Team, 可以在daily scrum meeting或者sprint plan meeting上提出,共商解决方案。我觉得Scrum Master对Team在很多时候都应该有一种“护犊子”的精神。确保Team神圣不可侵犯。

有效沟通


很多时候Scrum Master起到了一种“承上启下”的作用。一头面对的PO以及自己的老板,另一头面对的是Team。很容易使人感觉Scrum Master仿佛在夹缝中求生存,容易两边都不讨好。因此,沟通艺术的重要性不言而喻。如何说服PO,使得老板满意,并且让Team开心,这是一门学问。对于此,下面几点可以作为参考:

1. 面向老板:

应定期及时的通报项目的状态与进展,不要等到老板亲自来问,可以通过表格以电子邮件的方式发送。主要汇报进展状态,避免过于细节的内容;
遇到问题,应及时上报,使得问题在出现时就能得到重视,并被及时解决。如果等到截止时间才发布坏消息,那么就给了你的老板对你进行微观管理的机会。

2. 面向Team:

最重要的一点,应以身作则,态度端正;
充分了解Team中每个成员的能力状况,防止出现工作量盲目承诺的问题;
通过daily scrum meeting让Team中每个人都能明确了解最新的进展与形势;
遇到问题,应对事不对人。

把关质量


此刻开始,Scrum Master更像是一个项目经理。无论是质量,进度还是团队建设都更像是项目经理的职责。对于Team来讲,这时的Scrum Master不再是那个“保护”我们的人,而变成了那个“收保护费”的大佬。然而,在实际项目中,Scrum Master确实要承担这些职责,只不过有些已经融入到日常的scrum流程中去了。

关于质量的管理,我想其重要性不言而喻。质量是决定了产品的命运。那么如何把关质量了。在敏捷实践中,如下的经验可供参考:

1)欲速则不达。不应过于强调速度,应保持合理的开发节奏,才会使得产品质量具有一定的保障。Scrum流程在每个sprint应统一完整,使得Team形成习惯,最终达到良好的开发节奏。

2)制定coding style,并坚持代码审查。代码的规范非常重要,好的代码可以提高整体团队的开发与沟通的效率。好的代码会说话。代码审查可以结对完成,只有审查通过,才可以提交代码。可以通过创建pull request来进行代码的审查,通过之后,再merge到代码库中去。

3)写单元测试。单元测试的重要性我想大家都明白,只是很多人觉得写起来痛苦,麻烦,占用开发时间。有了单元测试,你的代码才是经得起考验的代码。

4)冒烟测试。在每天下班之前,停止push代码,然后进行冒烟测试。冒烟测试成功之后,才会下班回家。这是一种很好的方法,它保证了每天功能都是可用的,从而确保了质量。

5)自动化测试。它的好处,不用多说,谁用谁知道:)

6)提早集成,以便频繁获取反馈。这样的好处在于我们可以及时的得到用户的需求反馈,进而能够及早修正。

7)最后,我要强调一句:不要加班,不要加班,不要加班。

跟踪进度


进度管理是Scrum Master的又一项项目经理职责。对于scrum中进度的监控,我们有很多的方法,也非常有效。

先说工具,敏捷开发中,比较传统的跟踪进度,同时使用也非常广泛的一种方式是Story Board(故事版)。这种方式简单直观,非常有效。即使现在已经涌现了很多非常优秀的电子管理工具,许多团队仍然对它情有独钟。近些年一些电子的跟踪进度的srcum工具出现了很多。比较有名的像是jira. 它的使用也非常的简单直观,而且功能非常丰富强大,强烈推荐大家使用。

另外,我们可以通过daily scrum meeting获取到Team每天的工作进展。此时我们可以根据进展进行一些必要的调整。

团队建设


团队建设是项目开发中绝对不容忽视的一环。团队凝聚力如何,直接影响了整个团队的战斗力。因此,建设好团队,是每个Scrum Master的重要使命。

那么如何有效的进行团队建设呢?

1)放权。敏捷开发的其中的一个重要的特征就是团队自组织。团队自组织的优势就在于,通过放权给团队,让它们自主的思考,设计开发,不对其干预,从而使得团队中每个人具有成就感,进而提高整个团队的积极能动性。

2)打造学习型团队。一个方法就是通过团队内部知识定期分享的方式,使得每个人都能可以学到新的知识,从而逐步使得团队成长。比如每周五的下午4点,可以利用一小时的时间,让团队的成员举办知识讲座。通过这种形式,大家的积极性会变的很高。可以约定分享的内容并非一定是技术方面的,也可以是生活娱乐等,只要大家感兴趣就好。这样做的好处在于不仅提高了团队的技术能力,也使得团队之间能够更轻松愉快的交流,从而提升团队的凝聚力,战斗力。

3)最后,提高团队最有效的一个方法,那就是一个字:吃;)这是拉拢吃货们的大好时机。当然这个需要经费,不过方法总会有的,你懂的;)



作者:Ifdef_Max
链接:https://www.jianshu.com/p/72a5c42cec8b
2016-08-13 17:23:56 Jasper_Hou 阅读数 3906
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波


图片来源于网络

Scrum Master: Beauty and Beast

在Scrum敏捷开发中有三种主要的角色:Product Owner(产品负责人,简称"PO"); Scrum Master(敏捷教练); Team(团队)。其中,Scrum Master是其重要的角色之一。那么今天我们就来探讨一下如何做一个合格的Scrum Master。

Scrum Master在许多的项目开发中被视为项目经理,这其实是个误区。同时我也经常看到有人主张将Scrum Master与项目经理完全区分,对于此我也不太同意。在我看来Scrum Master虽然并非项目经理,但是仍然肩负着很多项目经理的职能。那么Scrum Master的职责究竟是什么呢?该怎样做才能成为一名合格的Scrum Master呢?以下六项,供您参考。如有不妥之处,欢迎探讨;)

管理Scrum流程


这是Scrum Master最核心的职责,也是Scrum Master区别于项目经理的最显著的特征。Scrum Master需要维护每个sprint的流程,确保每个sprint能够顺利的实施以及完成。

首先,Scrum Master负责主持召开sprint期间的每一个会议,包括sprint plan meeting, daily scrum meeting, sprint grooming meeting,sprint review meeting以及sprint retrospective meeting。

另外,Scrum Master还需要帮助PO建立product backlog与sprint backlog,并确立其中每个story的优先级。

最后,Scrum Master还需要帮助Team清除在开发的过程中遇到的障碍。Scrum Master应该有一个block list用来记录Team在开发中遇到的问题障碍,由Scrum Master自己进行管理并最终使得列表中的每一问题得到及时处理。

保护团队


Scrum Master应该最大限度的保护Team,以确保Team不会被外界,尤其是PO干扰。那么Scrum Master该如何保护团队呢?Team在什么情况下需要保护呢?

在每个sprint的初期制定计划的时候,Scrum Master应合理的根据Team的工作能力以及过往经验,承诺工作量。不要盲目乐观的给PO承诺过量的工作。我就遇到过有的Scrum Master可能是对于Team的能力估计不足,也可能是希望通过承诺更过的工作获取老板的芳心,承诺了太多的工作,结果导致Team在sprint的后期连续加班,致使Team的效率严重降低。同时由于时间的匆忙,急于交付,导致了项目的质量很低,最终形成了恶性循环。一个好的Scrum Master在这个时候是应该要懂得如何与PO“周旋”,获取合理的工作量。这里的“周旋”并非消极怠工,故意减少Team的工作量,这其实是通过安排合理的工作量来使团队达到最大的工作效率,同时不会伤害Team的积极能动性。这是一个良性的循环。

我们都知道,需求的变更对于每一个开发人员来说都是噩梦,而敏捷诞生的其中的一个很重要的原因就是为了解决这一问题,让开发者拥抱变化。然而在我们采用敏捷开发的项目中,经常可以遇到Product Owner越过Scrum Master,直接找到Team, 对他们指手画脚,发号施令。这个时候,Scrum Master应该像“猛兽”一样将PO“吼开”,以避免Team受到“伤害”。需求改变可以,但是不应该在sprint的过程中干扰Team, 可以在daily scrum meeting或者sprint plan meeting上提出,共商解决方案。我觉得Scrum Master对Team在很多时候都应该有一种“护犊子”的精神。确保Team神圣不可侵犯。

有效沟通


很多时候Scrum Master起到了一种“承上启下”的作用。一头面对的PO以及自己的老板,另一头面对的是Team。很容易使人感觉Scrum Master仿佛在夹缝中求生存,容易两边都不讨好。因此,沟通艺术的重要性不言而喻。如何说服PO,使得老板满意,并且让Team开心,这是一门学问。对于此,下面几点可以作为参考:

1. 面向老板:

应定期及时的通报项目的状态与进展,不要等到老板亲自来问,可以通过表格以电子邮件的方式发送。主要汇报进展状态,避免过于细节的内容;
遇到问题,应及时上报,使得问题在出现时就能得到重视,并被及时解决。如果等到截止时间才发布坏消息,那么就给了你的老板对你进行微观管理的机会。

2. 面向Team:

最重要的一点,应以身作则,态度端正;
充分了解Team中每个成员的能力状况,防止出现工作量盲目承诺的问题;
通过daily scrum meeting让Team中每个人都能明确了解最新的进展与形势;
遇到问题,应对事不对人。

把关质量


此刻开始,Scrum Master更像是一个项目经理。无论是质量,进度还是团队建设都更像是项目经理的职责。对于Team来讲,这时的Scrum Master不再是那个“保护”我们的人,而变成了那个“收保护费”的大佬。然而,在实际项目中,Scrum Master确实要承担这些职责,只不过有些已经融入到日常的scrum流程中去了。

关于质量的管理,我想其重要性不言而喻。质量是决定了产品的命运。那么如何把关质量了。在敏捷实践中,如下的经验可供参考:

1)欲速则不达。不应过于强调速度,应保持合理的开发节奏,才会使得产品质量具有一定的保障。Scrum流程在每个sprint应统一完整,使得Team形成习惯,最终达到良好的开发节奏。

2)制定coding style,并坚持代码审查。代码的规范非常重要,好的代码可以提高整体团队的开发与沟通的效率。好的代码会说话。代码审查可以结对完成,只有审查通过,才可以提交代码。可以通过创建pull request来进行代码的审查,通过之后,再merge到代码库中去。

3)写单元测试。单元测试的重要性我想大家都明白,只是很多人觉得写起来痛苦,麻烦,占用开发时间。有了单元测试,你的代码才是经得起考验的代码。

4)冒烟测试。在每天下班之前,停止push代码,然后进行冒烟测试。冒烟测试成功之后,才会下班回家。这是一种很好的方法,它保证了每天功能都是可用的,从而确保了质量。

5)自动化测试。它的好处,不用多说,谁用谁知道:)

6)提早集成,以便频繁获取反馈。这样的好处在于我们可以及时的得到用户的需求反馈,进而能够及早修正。

7)最后,我要强调一句:不要加班,不要加班,不要加班。

跟踪进度


进度管理是Scrum Master的又一项项目经理职责。对于scrum中进度的监控,我们有很多的方法,也非常有效。

先说工具,敏捷开发中,比较传统的跟踪进度,同时使用也非常广泛的一种方式是Story Board(故事版)。这种方式简单直观,非常有效。即使现在已经涌现了很多非常优秀的电子管理工具,许多团队仍然对它情有独钟。近些年一些电子的跟踪进度的srcum工具出现了很多。比较有名的像是jira. 它的使用也非常的简单直观,而且功能非常丰富强大,强烈推荐大家使用。

另外,我们可以通过daily scrum meeting获取到Team每天的工作进展。此时我们可以根据进展进行一些必要的调整。

团队建设


团队建设是项目开发中绝对不容忽视的一环。团队凝聚力如何,直接影响了整个团队的战斗力。因此,建设好团队,是每个Scrum Master的重要使命。

那么如何有效的进行团队建设呢?

1)放权。敏捷开发的其中的一个重要的特征就是团队自组织。团队自组织的优势就在于,通过放权给团队,让它们自主的思考,设计开发,不对其干预,从而使得团队中每个人具有成就感,进而提高整个团队的积极能动性。

2)打造学习型团队。一个方法就是通过团队内部知识定期分享的方式,使得每个人都能可以学到新的知识,从而逐步使得团队成长。比如每周五的下午4点,可以利用一小时的时间,让团队的成员举办知识讲座。通过这种形式,大家的积极性会变的很高。可以约定分享的内容并非一定是技术方面的,也可以是生活娱乐等,只要大家感兴趣就好。这样做的好处在于不仅提高了团队的技术能力,也使得团队之间能够更轻松愉快的交流,从而提升团队的凝聚力,战斗力。

3)最后,提高团队最有效的一个方法,那就是一个字:吃;)这是拉拢吃货们的大好时机。当然这个需要经费,不过方法总会有的,你懂的;)

2018-05-10 09:31:13 An1090239782 阅读数 3170
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波



记录一些优秀的敏捷开发案例或经验:

敏捷开发:项目管理的一些思考
w_fsovereign:三个月(敏捷)项目收获
RobinsonZhang:敏捷开发入门



一、敏捷过程

敏捷开发是一种以人为核心,以迭代方式循序渐进开发的方法,其软件开发的过程称为“敏捷过程”。
在这一过程中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。
在2001年年初,一些业界专家成立了敏捷联盟,起草了敏捷软件开发宣言。该宣言针对一些企业的现状,提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则,其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。

1.1 敏捷开发的价值观

  1. 个人和交互胜过过程和工具。
  2. 可以运行的软件胜过面面俱到的文档。
  3. 客户合作胜过合同谈判。
  4. 响应变化胜过遵循计划。

1.2 敏捷开发应遵循的12条原则

  1. 通过尽早的、不断地提交有价值的软件来使客户满意。
  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  3. 以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。
  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  5. 以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。
  6. 在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。
  7. 测量项目进展的首要依据是可运行软件。
  8. 敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
  9. 时刻关注技术上的精益求精和好的设计,以增强敏捷能力。
  10. 简单是最根本的。
  11. 最好的构架、需求和设计出于自组织的团队。
  12. 每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

敏捷组织提出的敏捷开发模型的整体框架主要有三个:
Scrum、XP(eXtreme Programming)、OpenUP 这3个敏捷实践。



二、敏捷开发的原则

  1. 凝聚人的力量,紧密协(合)作。包括业务负责人、开发团队、客户、管理者之间的关系,所有这些关系在以前都是造成项目危机的原因之一,那么,在敏捷时代,我们需要这些角色 紧密合作,最大限度的发挥各个角色的力量.
  2. 聚焦客户价值,消除浪费(如何聚焦用户价值,即频繁的交付用户可工作的软件,快速收到用户反馈)

2.1 敏捷团队运作机制

  1. 一个团队有自己的代办事项,对代办事项进行拆小。
  2. 按客户价值进行优先级排序,产品经理负责价值排序。
  3. 小而稳定,跨职能团队。
  4. 多个团队松耦合(依赖性比较低),对齐迭代时间和战略目标。

2.2 关键的团队角色

  • 产品负责人
  • Scrum主管(流程主管)
  • 开发团队

2.3 产品负责人(Product Owner)

  • 负责管理产品backlog(代办事项)的唯一负责人
  • 代表客户/项目如责任人
  • 定义产品的所有特性
  • 负责产品的投入产出
  • 负责最大化产品和开发团队工作的价值

2.4 Scrum Master(流程主管)

  • 起到教练的职责,领导团队完成Scrum的实践以及体现其价值。
  • 排除团队遇到的困难,使得团队紧密合作,使得团队个人具有多方面职能的工作能力。
  • 确保团队能胜任其工作,并保持高效的生产率。
  • 保护团队不受到外来无端影响

2.5 关键的团队活动

  • 每日例会:每日5分钟左右的一个简单例会,尽可能多的开发人员参与进来对紧要问题的讨论。
  • 评审会:需要在迭代周期的最后一天召开,1个小时左右就可以了,需要客户出席,如果客户不能出席,则需要产品经理出席
  • 迭代回顾会:迭代回顾会是在每个迭代结束时进行,总结工作中的经验和教训,时间维持在30-60分钟内,整个团队都需要参加(Scrum Master、Product Owner、开发团队以及客户)。迭代回顾会包括两部分,第一部分是定量分析,第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标,收集并评审迭代度量指标(包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等)。定性分析包含哪些工作良好(应该继续保持),哪些做的不好(应该停止)?哪些可以改进(团队选出1-2条在下一个迭代实现)?

敏捷开发
作者:木可大大

三、敏捷团队的五个约定

3.1 约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上,
不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

而我坚信“prevention is better than
cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

3.2 约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

我和敏捷团队的五个约定

四、敏捷开发的前置条件

4.1 比较固定的流程,文档,需求

  1. 需求是控制稳定性的根本,对于需求一定是整体可控的,并且是可以由迭代内进行调整的,而不是定死的
  2. 流程是指什么时间什么人该做什么事是高效的,明确的
  3. 文档是指每个流程阶段具有可交付或者可查阅参考文档,不是口头或者个人评定。

4.2 可灵活调整,允许试错

  • 检查

检查是指在每天的站会中检查每个人的工作状态,是否能完成自己的任务,存在什么问题,完成效果如何。另外就是保证整体在每天的进度,是否有有整体效果,如果没有完成今天的整体效果,需要检查是否符合整体迭代。

  • 调整

调整是指检查发现迭代的进度或者外界环境发生变化时,及时调整当前迭代的开发任务,保证迭代最终产物的准确及时性变动。当然,这种变动是不允许太多的,一般情况下在需求没有做详细分析时,不接受;在当前有风险的情况下,撤销某些需求;其他情况不做描述。

  • 试错

正是由于检查以及调整的策略,保证了迭代的灵活性,我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点,如果实验成功则可以对外拓展;如果不行,可以快速切换方案。

4.3 问题场景&&错误认识

  • 一个团队闭关开发一个项目就是敏捷

正确理解:敏捷不等于闭关,只是可能坐一起效率更高,其倡导的是何时都可以发生沟通,并准备一白板可以随时讨论方案;敏捷团队质量以及效率高于一般团队;敏捷团队开发的是以迭代为单位,不是项目;

  • 有了任务细分,开发白板,站会就是敏捷

正确理解:任务细分、白板、站会都是其形式,关键还是其将迭代的内容进行细化,可执行化,用高频的沟通反馈提高开发、沟通、理解的效率。

  • 敏捷团队没有特殊前置条件

正确理解:前面有讲到敏捷对团队,需求,文档,流程,调整等都有比较完整的规定。

  • 敏捷团队做的事情没有差别性

正确理解:敏捷完成的任务具有明细化,分阶段性,可调整性。所以在开发相关任务时,也具有类似的特点。

  • 敏捷团队会完整完美的交付产物

正确理解:敏捷在迭代结束只交付该阶段的可交付产物,很可能不完整不完美,对于可交付也有不同的理解。

2019-08-25 00:06:24 seagal890 阅读数 129
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

[敏捷开发实践] Scrum Master的职责

Scrum Master 是仆人式领导者,能够为Scrum团队提供支持,让团队功能完善并高效运作。

  • 作为Scrum框架规则的维护者,帮助项目团队和组织遵守Scrum价值观和实践;
  • 以被动和主动的方式帮助团队扫清项目障碍,并保护Scrum团队免受外部干扰而专注于Sprint迭代开发工作;
  • 促进Product Owner以及其他项目干系人(Stakeholders)和Scrum团队紧密协作;
  • 促进Scrum团队内部建立共识;
  • 保护Scrum团队免受组织层面的干扰;确保Scrum团队中的每位成员都能够在正确的时间专注于正确的工作优先级;
  • Scrum Master 是Scrum过程开发模型方面的专家,能够指导他人工作;
  • Scrum Master需要具有良好的沟通能力,并并拥有足够的组织影响力

有效的Scrum Master的特质

职责 优秀的Scrum Master的特质
维护Scrum框架规则 是Scrum流程的专家,对敏捷实践具有优秀的经验和成功案例
为Scrum团队扫清障碍,防范干扰

拥有组织影响力,可以迅速解决问题

善于表达、讲究策略、具有专业的业务能力

是优秀的沟通者和聆听者

坚定秉持Scrum Team的需求,只专注于项目和当前Sprint的工作

促进外部项目干系人(Stakeholders)和Scrum团队的密切协作

能从全局角度审视项目的需求

能避免工作中拉帮结派,帮助打破团队和成员孤立

引导建立共识 了解如何帮助团队达成一致的意见的方法
仆人式的领导者(Leader)

不需要或者不想要成为组织的领导者,或者更高级的Manager

确保开发团队的所有成员都获得必要的信息以完成工作、使用工具和追踪进度

真正渴望帮助Scrum Team成功的人

 

2019-09-01 17:49:05 playermaker 阅读数 100
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

什么是 Scrum Master

Scrum 是敏捷开发中的其中一种实践,具体是什么内容以后会慢慢细说。Master则是大师的意思。所以 Scrum Master 就是 Scrum 大师,也就是非常精通 Scrum 这套框架的人。

如果要精通 Scrum 的话,就不得不从最基础的概念开始学习。因为 Scrum 是敏捷开发的一种实践框架,那什么是敏捷开发?什么是敏捷呢?

敏捷是什么?

敏捷这个词在我们应该听到很多次了,按正常的想法来说,这个词说的是快、迅速、速度等形容,具有敏捷性,但在软件这个行业中,敏捷这个词是术语:

敏捷通过强调增量交付、团队协作、持续规划和持续学习来实现软件开发。

因此敏捷一词,在软件开发中有4个核心思想:

  • 增量交付
  • 团队协作
  • 持续规划
  • 持续学习

在2001年,美国的敏捷大师们达成一致,签署了敏捷宣言,它的建立为更好的软件开发方法确立了原则,该宣言的核心是4条价值观,代表了敏捷运动的基础。

敏捷宣言

  • 个人和互动 > 流程和工具
  • 可工作的软件 > 详尽的文档
  • 客户合作 > 合同谈判
  • 相应变化 > 遵循计划

很显然,尽管我们承认右边同样有价值,但我们更看重左边的内容。

曾经的传统开发方式,我们因为流程审批和不好用的工具,浪费了多少时间和精力?我们交付的软件有哪一次客户首次使用就竖大拇指的?各种详细的word和漂亮的ppt还不是一样没有逃过客户说:这不是我想要的命运。

为什么要用敏捷?

那么为什么有人会考虑敏捷方法呢?很明显,在过去10-15年里,围绕构建软件的交战规则发生了根本性的变化。许多活动看起来很相似,但是我们应用这些活动的场景和环境明显不同。考虑一下与2000年初相比,现在购买软件是什么样子的。你上次开车去商店买软件是什么时候?考虑一下如何从使用您产品的客户那里收集反馈。在社交媒体出现之前,我们如何理解人们对我们软件的看法?最后,考虑一下您希望多长时间更新和改进您交付的软件。每年发布一次更新听起来并不像是成功的秘诀。

规则已经改变了,世界各地的组织现在都在相应地调整他们的方法以适应软件开发。敏捷方法和实践并不能保证解决所有问题。但他们确实承诺建立一种文化和环境,通过协作、持续规划和学习,以及更频繁地交付高质量软件,解决方案就会出现。

敏捷开发

阅读数 8

没有更多推荐了,返回首页