2015-04-19 15:42:22 chenleixing 阅读数 3745
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
敏捷开发-站立会议要点:
1、站立会议全员都需要参与;
2、当值员必须提前准备,识别出问题和风险,做好协调;
3、每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行;
4、每日站会实践不能超过15分钟;
5、三段论:昨天完成什么,今天计划做什么,困难;
6、成员之间信息共享,每个组员都能了解项目总体进展;
7、不要陷于技术细节的讨论,当值人员应该记录下所有的阻碍并跟踪;
8、把每个问题用跟踪卡片(或在JIRA)跟踪起来。
2018-06-11 09:09:17 mebusw 阅读数 891
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

Daily Scrum的问题

当你问一个初创敏捷开发团队“你们会开站立会吗”,经常会碰到这样的回答“我们的开发团队对开站会比较抵触,团队本来就在一起坐着,认为站立会太形式化,没有什么价值”。还碰到过实行过两年以上的敏捷研发团队,也经常说到“开高质量的站会很难”。

敏捷团队到底怎么开高品质站立会?

先看看敏捷教练口中的站立会(Daily Scrum)。

敏捷教练说站立会

  • “在15分钟内,团队站着开。“
  • “Scrum培训中讲到Scrum指南标准定义中,团队在开每日站会的时候需要回答三个问题:我昨天完成了什么?我今天计划做什么?我遇到了什么障碍?”
  • “开站立会的目的是:
    1. 我们团队的昨天的目标是否达成了?每个人的贡献是什么?有哪些差距?
    2. 我们团队的Sprint目标现在还有多大差距?是否延迟了?遇到了哪些问题和障碍?
    3. 为了达成Sprint的目标,我们今天的目标是什么?为了实现今天的目标,我们每个人做什么?”

回归敏捷站立会的实质,它有以下作用: 1)对齐目标:互相同步信息,聚焦于当前迭代目标;2)相互协作:尽快交付工作成果,减少半成本,发现当前障碍,团队成员通力协作让价值流动。

每日站立会实践的反模式

  • 每日站立会的时间定在下班前

在敏捷实施过程中,我们的敏捷团队就走过这样的弯路:一个号称自组织的敏捷团队,起初站立会定在早上9:00开始,后因早上经常有迟到现象,大家倡议更改到9:30;再因各种会议冲突问题,站立会时间更改到下午18:00;又因种种原因,变更成17:00。在一次次以自组织的名义下,团队成员在不断互相妥协迁就的过程中,站会的时间变成下班之前。在这个过程中,站会变成了一天的结束会。

开站会时间定在下班之前,有以下问题,会议的目的之一--大家相互协作,如果会上有人遇到障碍,需要寻求帮助解决,但是因为这个时间以后大家有可能下班,有两种处理方式:强制加班当天要求处理和第二天再处理。无论哪种解决途径,都影响到敏捷迭代的正向促进作用,因此每日站立会不建议在下班之前开。

  • 开会时间过长或过短

会议时间太长或太短都是问题。太长的情况通常有两种:1)当某个成员抛出一个问题的时候,大家都对这个问题有浓烈的兴趣,这个时候很可能会陷入一种集体的讨论环节,人人都有话说,或者对一个话题陷入帕金森琐碎中。开会时间不可控,很可能还没有实质讨论成果。2)开会人数多,敏捷的每个站立会建议是5-9个人;如果人数过多,一轮站立会下来,就很容易超时。

还有一种是开会时间特别短,内容通常是这样“我昨天修了XXBug,今天计划修XXBug”; “我昨天做XX功能,今天继续做XX功能”;“按计划进行,我这边没什么问题”,“我这边也没啥问题”。多次这样简短又没内容的站立会,和敏捷站立会的目标:对齐目标和相互协作都相距甚远,这样没营养的站立会要少开。

  • 每日站立汇报会

这个主要发生在开站立会的成员中有绝对权威性的情况,通常都是领导在场,开会的时候,不自觉的从互相相同步信息的会议,改成单向领导汇报工作的形式。

很多敏捷团队的站立会议是以上这种形式,如果领导这个时候表达某种倾向性,与会成员很容易就直接接受并执行。特别是技术方案相关决策,很可能没有充分讨论清楚,因为某方的一言堂决策,导致多走弯路甚至失误。

  • 开站会发言表达混乱,没有主次

还有就是开站会时轮到某些人发言的时候,表达逻辑不清,有时候还出现当场回忆昨天工作内容,讲的内容都是流水账,与会听众关注不到重点。这样的发言多了,其他的人,也不愿意听,很容易造成与会者三心二意,这种情况不及时制止,对团队建设危害大,很容易导致团队整体氛围差,大家对待站立会的态度松懈下来,越来越不重视,流于形式。

出现这样的原因,多半是因为敏捷迭代过程中对迭代目标以及每日进行的任务没有一个清晰的关联,就会感觉任务琐碎,对任务的价值不清楚。

  • 抛出障碍无人响应

站会的目的之一,是希望能发现障碍,大家群策群力解决,但是有一些障碍(如:专业性特别强的技术问题),当与会者提出碰到一个技术难点的时候,很多时候与会人员暂时都无法给出有效的建议或方案,就会出现有人抛出障碍,无人响应。当团队不能提供实质性的帮助或建议的时候,站立会抛障碍的发声就会越来越少,渐渐站立会的价值减弱。

那怎么样才能在敏捷团队经营出高质量的站立会?下面有一些优秀的实践,可以参考。

开站会的优秀实践

  • 有规矩成方圆,尊重团队约定

“少成若天性,习惯成自然”。站立会是固定在每个工作日的同样地方同样地点站着开的会议,团队约定之后,需严格按照约定执行。站立会原则上是团队最高优先级的事,没有经过团队认可的特殊原因,成员不得缺席迟到。

我所在的团队就有过两个第一优先级的约定“1)站会是团队第一优先级别;2)团队协作是第一优先级别”。有了好的约定,还要有好的执行力,团队遵守的约定才是有效约定。

  • 把站立会上升到团队整体仪式,注重团队仪式感培养,强化敏捷价值理解

强化团队仪式感实际上就是增强团队认同度,可以把站立会看作是一个敏捷团队整体开工仪式。以站立会为起点,成员实现对团队交付的执行承诺。

我们实践中发现早上是一个好的开始。它是一种强化的仪式,大家就一定要准时,必须要有严格的执行规则。比如:早上9:00开始,任何人不得迟到,有迟到就有戳心又不打脸的惩罚措施,而且要保证公开,透明。

  • 迭代目标明确,和每日任务紧密相关

每日站立会,每个与会成员都需确保迭代目标是清晰的,当天的工作目标是清晰的。这个职责通常都落在Scrum Master身上,他能根据每位成员表述的内容和抛出的障碍,判断是否所有成员都清楚迭代目标和当前关注点。如果发现有成员对迭代和当日工作目标不够清晰时,需及时说明。整体会议的过程和发言的内容是“关注细节,又不特别详细”。

  • 开放自主的氛围:围圈站,站位很重要,你的站姿决定你的态度,聚焦圆心

所有人站立围成一圈,每日站会是团队交流会议,不是报告会议,发言的人要面向所有站立会成员,每个与会者都是在互相汇报和交流,而不是向主管或经理做汇报。

                  

  • 站会之后有小会

每日站会之后,针对抛出的障碍,问题等,会有一段活跃的讨论会议,相关人员群策群力提供合适的解决方案。

  • 站立会应立规矩有原则:有“刺头”,欢迎“刺头”,鼓励“刺头”行为

关于团队约定,团队成员要严格遵守,对于违反团队约定的事,团队鼓励“刺头”行为,在第一时间指出,并让当事人做出对应的约定承诺。

  • 更重要的,敏捷的实施,有一个最重要的原则--打造价值共同体

站会只是组织内敏捷实施的一个缩影,它可以反馈很多的问题,其实如果打造价值共同体,或者说是利益共同体,才是我们需要值得反思的问题。敏捷中当团队的所有人价值是统一的,团队是有向心力,站会也能开得足够高效有序,当大家的利益不统一的时候,站会的时候也会暴露出很多团队管理上的问题。一个敏捷团队站立会实施的情况,可以反映出团队或组织的敏捷成熟度。

 

需不要要开站会,视团队整体情况而定,“无招胜有招”,领会敏捷以聚焦团队价值,构建价值共同体的团队才是敏捷实施的灵魂。无敏捷的形式,但是自成体系,也是好的敏捷。

总结

敏捷团队的站立会,是敏捷实施对外展示的“形”,更重要的还是站立会背后披露出的团队整体的敏捷文化、价值观建立和演进。让我们在敏捷实施的道路上越走越稳,带来更多的敏捷真谛。

(作者:罗琼,浙江移动云平台及DevOps产品经理,CSM认证、CSPO认证,原文链接http://www.uperform.cn/rethinking-about…m-by-agile-coach/)

2010-05-27 12:21:36 zhanghsh2010 阅读数 73
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
1 站立会议全员都需要参与;
2 当值员必须提前准备,识别出问题和风险,做好协调;
3 每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行;
4 每日站会实践不能超过20分钟;
5 三段论:昨天完成什么,今天计划做什么,困难;
6 成员之间信息共享,每个组员都能了解项目总体进展;
7 不要陷于技术细节的讨论,当值人员应该记录下所有的阻碍并跟踪;
8 把每个问题用跟踪卡片(或在JIRA)跟踪起来。
2019-04-30 16:53:27 yangrendong 阅读数 52
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

最近跟以前的同事聊天,他们都在搞敏捷开发,天天站立会,那我们今天就来聊聊敏捷开发那些事儿。

   敏捷开发的实际应用,无外乎以下几种情形:

  1. 很多团队想搞敏捷开发,但是不知道如何下手
  2. 有的团队已经应用了敏捷开发的实战,但是效果不理想,不知道是敏捷开发不行还是自己时间方式不得当
  3. 甚至有的团队听说了敏捷开发,但是不清楚它是什么

为什么会导致这样呢?我们今天就围绕敏捷开发来探一探,看看敏捷开发是什么,能帮助我们解决什么问题,要不是实施敏捷开发,如何应用好敏捷开发。

什么是敏捷开发

     敏捷开发是什么呢?有人认为:

  1. scrum、极限编程
  2. 每天站立会议、每两周一个Sprint(迭代)
  3. 把需求变成故事写在便签上贴到白板,根据状态移动到不同的列
  4. 用看板软件来管理项目

那这些是敏捷开发的真正含义么?

我们先来讲讲敏捷开发的诞生背景,2001年那会,瀑布模型还是主流,我们知道瀑布模型是“重型”的开发模式,真个流程走完周期很长,比较拖沓,长期的话会导致风险增加,难以响应变化。

    当时由瀑布模型衍生出的模型,都试图改善瀑布墨香存在的问题,如雷贯耳的轻量级开发方法例如极限编程、Scrum等。但是大家都无法达成共识,但形成了敏捷联盟,宣言是:

    敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。
    各种敏捷框架、方法论和工具就想是“术”,告诉你敏捷开发的方式,而敏捷是“道”,是一套价值观与原则,指导我们软件开发中做出决策;这么说好似有点抽象,我举个例子:

    敏捷开发中流行的站立会议,主要目的是保证团队成员充分的沟通,遇到困难可以及时寻求帮助,如果每天的站立会议流于形式,并不能起到有效目的,这种我们就需要减少频度,甚至取消换成其他方式。

     也就是说,我们开发做决策的时候,遵守了敏捷开发的价值观和原则,不管我们用得是Scrum或者极限编程,都可以算是敏捷开发。

敏捷开发想解决什么问题?

    敏捷开发并没有对瀑布模型的价值进行否定,但是也表明了瀑布模型做的不够好,同时提出了自己的一套价值观。

    比如我们开始一个新项目,需要从客户那里搜集整理需求,传统开发模式下我们需要在开发前获取到所有需求并和客户签订合同,在发布前不轻易修改需求。但是我们如果采用敏捷开发模式来开发项目,这样做显然违背了敏捷的价值观:“客户合作高于合同谈判”。

    所以敏捷开发是在每个迭代后,应该向客户收集反馈,在后面的迭代中,酌情加入客户反馈修改的内容。

    敏捷开发就是想解决瀑布模型这种重型软件开发方法存在的问题,用一种轻量、敏捷的方法来改善甚或替代它。瀑布模型的典型问题就是周期长、发布烦、变更难,敏捷开发就是快速迭代、持续集成、拥抱变化

敏捷开发和瀑布模型的差异

    这些年敏捷开发已经发展出一套“Scrum+极限编程+看板”的最佳实践,Scrum主要用来管理项目过程,极限编程重点在工程实践,而看板将工作流可视化。

  1. 敏捷开发是如何做需求分析的?

瀑布模型的一个重要阶段就是需求分析,有严谨的需求分析才能产生详尽的需求分析文档,敏捷开发的需求则是来源于一个个小的用户故事,写在卡片上,在Sprint开发中,再去确认需求的细节。好处是减少了大量需求文档的撰写,尽早开发,但对开发人员对需求理解和沟通的能力上要求更高。

  1. 敏捷开发如何做架构设计的?

瀑布模型在需求分析后需要根据需求做架构设计,敏捷开发中,每个Sprint做一部分需求,是一种渐进式的架构设计,当前Sprint只适合当前需求的架构设计,这种渐进式架构设计,迭代次数一多,会出现架构满足不了需求的现象,产生不少冗余代码,我们称之为技术债务,可能需要定期对系统架构进行重构。

  1. 敏捷开发怎么保证项目质量的?

瀑布模型在编码完成后,会有专门的阶段进行测试以保证质量,敏捷开发的Sprint没有专门的测试阶段,这依赖于开发功能的同时,要编写单元测试和集成测试代码,用自动化的方式辅助完成测试,这对质量确实有部分影响。

  1. 敏捷开发是怎么发布部署的?

瀑布模型在编码结束后,开始部署测试环境,在测试阶段定期部署测试环境,测试验收通过后,发布部署到生产环境。

敏捷开发中,这种持续构建、持续发布的概念交持续集成,整个过程都是全自动化的,每完成一次任务、提交代码都可以出发一次构建部署动作。持续集成的确是一个非常好的实践,极大的缩短和简化了部署流程,自动化测试也保证了部署产品的质量,但是前期搭建整个持续集成环境需要一定技术要求。

  1. 敏捷开发的Sprint和迭代模型的迭代有什么区别?

迭代模型本质上是一个小瀑布模型,一个迭代里是需要完整的需求分析、设计、编码、测试阶段,敏捷开发的Sprint没有严格的阶段划分,每个Sprint周期会完成多个用户故事,开发时会针对用户故事有编码、自动化测试编码,完成后通过持续集成自动发布到测试环境中,整个节奏比较恒定,产品也相对稳定,即使部分用户故事没有完成,不影响版本的发布。

    因此敏捷开发更注重软件开发中人的作用,需要团队成员以及客户之间的紧密协作。

该不该选择敏捷开发

    敏捷开发在国内有失败也有成功的案例,软件工程中的好的实践如持续集成、测试驱动开发、结对编程、看板等都来自于敏捷开发,可以肯定的说,敏捷开发是一种非常好的软件开发模式。

    但是在应用上,我们确实需要满足一定条件才能用好:

  1. 团队要小,人数超过一定规模就要分拆
  2. 团队成员之间要紧密协作,客户也要自始至终深度配合
  3. 领导们要支持,敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性
  4. 写代码时一定要写自动化测试代码,要花时间搭建好源码管理和持续集成环境

因为敏捷开发对项目成员综合素质要求更高,做计划相对难一些,要实践敏捷开发,建议先找个小项目试点,有条件的话和一些顾问公司很作,找专业的人进行培训和指导。如果不具备条件,应该考虑把持续集成、每日站会、自动化测试等实践起来。

最后总结,瀑布模型面向的是过程,敏捷开发面向的是人!

2011-06-12 07:45:00 zhangweia 阅读数 7478
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

      敏捷是一柄双刃剑,用的好能极大的提升开发效率,适应需求的变化!用的不好则会导致项目的混乱。现在很多公司都说自己在用敏捷开发,很多程序员也说自己懂敏捷开发!简单的认为敏捷就是站立会议,就是迭代的开发,到最后敏捷变成了混乱,然后开始说敏捷的不好等等。其实他们都只是表面上的敏捷,而没有真正的理解敏捷的含义。敏捷做为一种新的编程方法论,是有他一套完成的方法学的。

      敏捷开发提倡迭代开发,小版本的发布和测试,首先我们来看看迭代的开发流程和附加要求,然后我们对怎样做好每个流程就行详细的设计。

image

因为敏捷开发提倡一个迭代80%以上的时间都在编程,几乎没有设计的阶段,因为我们必须保证我们的代码的质量。因此在整个迭代过程中我们要持续做到以下几个方面:

image

敏捷开发

阅读数 179

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