2015-09-29 22:21:25 jnqqls 阅读数 7536
  • SCRUM敏捷开发视频教程

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

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

        

        通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster.

 

Scrum Master(SM)

 

        敏捷开发中的SM即ScrumMaster,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

 

       Scrum Master是团队的导师和组织者,与ProductOwner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

 

       ScrumMaster并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 ScrumMaster是规则的执行者,他是Scrum团队中的服务型领导。

 

       这一点在实际项目经验中是很难达到的,因为想要达成自我组织的团队并非一朝一夕,尤其是新组建的团队,本身团队就是一个磨合的过程,只不过我们是通过哪种方式可以磨合的更快,更有效率.如果SM这个角色能够很好的担当和把控,非常有利于整个团队的磨合.

 

Scrum Master主要工作职责

 

      确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

 

1、保证团队资源合理利用;

 

2、保证各个角色及职责良好协作;

 

3、解决团队开发中的障碍;

 

4、作为团队和团队外部的接口,协调解决沟通中的问题;

 

5、保证开发过程按计划进行,组织ScrumPlanning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint ReviewMeeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

 

            结合我们项目中的实践,SM的角色一直处于变化的过程中,大概在项目进行半年之后才稳定下来,前期因为变更着,导致项目整体比较混乱,没有一个主线.SM稳定之后,整个局面有好转,但是并没有预期的效果好.

 

        总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

 

2015-09-29 23:23:16 jnqqls 阅读数 3299
  • SCRUM敏捷开发视频教程

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

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

        

      在敏捷开发中除了POSM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.

 

      因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个新的团队磨合成敏捷开发所要求的自组织团队是一个比较难得过程,尤其是在实际的开发进度和需求等不定因素的影响下.

 

     因此提高Team的凝聚力是创建自组织团队一个 重要因素.

 

    团队的凝聚力来自于大家都在为一件事而努力,每天都在做,而且经常有提高。

      为了提高团队凝聚力,有很多途径可以实施,例如在每天的站立会议,Team成员除了介绍每天的工作,还可以做两个额外的事情:

 

        一个是快速形成某个团队级别的决议,例如将某个方法作为公共模块,临时调整资源等,解决阻碍团队的重大问题;

 

          另一件事情是代码分享或者代码复查,每个人都会拿出昨天最核心的功能代码,讲给大家听,只包括外部模块的耦合,业务逻辑,大家进行讨论,结果不是发现了漏洞,就是发现了某个人的代码更加规范,其他人都会和他保持一致。当然,因为涉及到具体代码此过程在站会的时候进行可能会耽误比较长的时间,项目团队可以根据实际情况,每天留下固定实际来进行此项操作,因为是良性的,所以会越来越好.

       

 

       Team成员每天进行集体沟通,每个人都有机会发言,每个人都不只是听客,每个人都可以感受到其他人对项目的贡献,每个人都有是整个项目和产品的主人翁的感觉.

 

       为了让整个Team的沟通有效率,因此每个敏捷团队人数不易太多,如果有很多人,首先站会就会浪费大家很多时间,也同时因为人数太多,大家的关注点就开始分散起来,不利于高效的去解决问题.

 

       所以在实践过程中,我们原先的20多人的团队分开成两个敏捷团队,每个团队都有各自的PO,SMTEAM.每天的站会分开两部分进行.如果需要两个团队共同来解决公共问题,则还有站会的站会,每个Team派代表来给项目经理说明问题,进度等.

 

       至此,整个敏捷项目的角色基本上全了,PO+SM+TEAM.


2018-05-10 09:31:13 An1090239782 阅读数 3171
  • SCRUM敏捷开发视频教程

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

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



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

敏捷开发:项目管理的一些思考
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-07 20:59:52 spfLinux 阅读数 42
  • SCRUM敏捷开发视频教程

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

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

接触敏捷开发一年了,打算写点什么。

    敏捷开发 — 是什么

1. 敏捷开发 — 角色

2. 敏捷开发 — 道具(story/defect/task...)

3. 敏捷开发 — 游戏(自己做一个?或找些玩法过来?)

4. 敏捷开发 — 需求

5. 敏捷开发 — 开发

6. 敏捷开发 — 测试

7. 敏捷开发 — 会议

8. 敏捷开发 — 面板

9. 敏捷开发 — CI/CD

10. 敏捷开发 — 迭代

11. 敏捷开发 — release

12. 敏捷开发 — 常见问题及解决方案

   12.1 敏捷开发 — 新人进来怎么安排(新人story...)

...

先列个大纲吧,慢慢写,如果有写,会在每个item后面给出Link的。

搜罗一点做其他人写的做参考。

https://blog.csdn.net/zhaoenweiex/article/details/78108248

2011-04-12 09:58:12 jxdwuao 阅读数 8
  • SCRUM敏捷开发视频教程

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

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

Scrum 

 

Scrum是一种敏捷软件开发框架。

 

Scrum中的主要角色包括:

项目经理类似的Scrum主管角色负责维护过程和任务,

产品负责人代表利益所有者,

开发团队包括了所有开发人员。

 

产品负责人主要是确定系统需求.

产品负责人 Master  负责和产品经理沟通,   监督开发进展情况 , 和负责对外的沟通,  让团队内部人员尽量少受到外部的干扰.

开发团队   包括开发\ 测试\ 运营等人员 .  定期向产品经理演示开发成果.

 

开发周期主要有几个小的 Sprint 迭代而来 .

 

Sprint 会议

前期 :  产品经理负责整理需求, 确定开发的内容 , 确定各项功能的重要性, 优先级 . 和完成的时间.

中期 :  产品经理把开发内容给开发团队讲解,  开发团队讨论, 把任务分解成功能点 , 对开发时间进行预估.

后期 :  最终确定开发的工作日 / 人 , Master 得到任务墙,  确定任务列表, 对资源进行安排, 将任务安排给擅长的开发人员.

 

每日例会 :

每天早晨开的短会, 把昨天完成的, 未完成的任务进行确认 , 如果遇到解决不了的问题 , 团队不择手段集中资源解决开发中遇到的问题 ,或者增派别的人手 , 解决开发问题. 

 

开发完成后 :

回顾会议:

对开发完成的产品进行持续改进.

敏捷开发实践

阅读数 601

敏捷开发之PO

阅读数 1211

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