2019-05-09 16:01:10 yangrendong 阅读数 57
  • SCRUM敏捷开发视频教程

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

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

   我们继续讨论大厂的敏捷方法应用。

    我们上节提过,如果每周一个Sprint,怎么保证每周都有交付,同时还能保证产品质量?

    一个应用敏捷开发的小组日常

这个小组是做网站开发,基于微服务负责网站的某一个小模块,标准配置7人、4个程序员(要起码有一个资深程序员有架构能力)、1个产品经理(Scrum里叫Product Owner),1个测试、1个项目经理(Scrum里叫Scrum Master),主要负责网站某模块的维护和协调工作。

    分工上:

  1. 产品经理:写需求设计文档,将需求整理成Ticket,随时和项目成员沟通确认需求;
  2. 开发人员:每天从看板上按照优先级高低提取Ticket,完成日常开发任务;
  3. 测试人员:测试已经部署到测试环境的程序,如果发现Bug,提交Ticket;
  4. 项目经理:保障日常工作流程正常执行,协调团队成员的沟通工作,提供必要帮助和解决问题

如何完成需求和修复Bug

这个小组的日常工作,也是围绕Ticket来开展的,所有的需求、Bug、任务都作为Ticket提交到项目Backlog,每个Sprint的任务都以看板的形式展现出来。

    每个人忙完自己的“To Do”后把对应的Ticket移动到“Done”,再按优先级选取新的Ticket,然后移动到“In Process”栏。

  1. 每周一部署生产环境

    一般部署放在周一,如果是周五的话,万一部署发现问题,周末就需要加班无法好好休息了,所以除非紧急,部署都是放在上半周,这样遇到的问题后续有足够的时间去应对。

    部署很简单,按照流程执行几个命令就可以完成生产环境部署,然后需要对线上监控图标进行观察,有问题及时甄别,必要的话对部署进行回滚操作,但要记得不要轻易打补丁重新上线,仓促之间的修复会导致更大的问题。

    敏捷开发一周一个Sprint的好处在于即使这周的部署回滚了,下周再一起部署不会有太大影响。

  1. 每周二开迭代回顾会议,总结上周Sprint

    每周二,小组会预留一个小时的时间,作为迭代回顾会议(Sprint Retrospective)会议,目的是总结迭代中,团队做的好的地方和不好的地方。

    对于后续需要改进的,需要创建Ticket,加入到Backlog中,后续迭代中改进完善。

    例如测试人员反馈说,上一个Sprint,开发人员上线前几个小时还往预部署的分支里更新代码,导致测试需要重新弄做回归测试,但因为时间不够了,来不及测试完整,导致上线后不稳定,对于这样的问题,可以反映出流程出了问题,需要商定不是紧急的修复,不能在预部署分支上更新,确实需要加,要和测试确认。

    会议中涉及项目的决策,最好通过集体表决的方式决策,尽可能避免独裁式决策,因为敏捷的原则之一就是要善于激励项目人员,给他们需要的环境和支持,并给予充分的信任。

  1. 每周四迭代规划会,计划下周工作

每周四也需要一个小时的组织会议来迭代规划(Sprint Planning Meeting),大家一起讨论下一个Sprint的内容。

    开会前,产品经理和项目经理商量好Ticket优先级,大家按照优先级从Backlog中选出下个Sprint的内容。团队每个成员对下个Sprint Backlog中的Ticket进行同时打分,决定Ticket的工作量。

  1. 评估每条Ticket工作量的大概流程如下:
  1. 会议组织者阅读一条Ticket,可能是用户故事,可能是Bug,可能是优化任务,询问大家是否有疑问
  2. 大家一起讨论这个Ticket,确保充分理解Ticket
  3. 大家对Ticket进行工作量估算
  4. 估分存在分歧,出分最高和最低说明理由,最有达成一致

这种估算方法叫估算扑克,也就是poker,此方法的评估好处:

  1. 大家积极参与,详细了解需求,
  2. 工作量是由实际参与开发的成员做出评估,往往更准确易接受
  3. 促进成员的交流和经验分享

所以,经过N个Sprint的磨合后,一般一个团队的每个Sprint产出是比较稳定的,比如上面那个团队组成,一个Sprint预计完成20-30分的Ticket。

  1. 每周五分支切割

周五标志着一周的工作结束,所以下班之前,做branch out,把Master主干分支代码克隆到分支上,因为一周的开发,master已经合并了不少新的PR,如果我们直接把master部署到生产环境,是有风险的,毕竟自动化测试无法完全代替专业测试人员,所以需要再人工测试出来的Bug进行修复,直到稳定下来。此预部署的分支测试验收通过后,预部署分支的代码会部署到生产环境中。

https://static001.geekbang.org/resource/image/a1/67/a1ff4dc93ffa7d68ab5d757317623167.png

  1. 每周轮值

日常开发还有很多琐碎的事情,比如每周部署生产环境,每天部署测试环境,每周的branch out,回答其他小组的问题,主持每日会议,这些琐碎的事情在敏捷开发中,通过轮值让每个人去体验一下,大家会更有集体荣誉感和责任感。

问题就出来了,

  1. 基于这种敏捷开发的方式加班多吗?

加不加班跟是不是敏捷开发关系不大,要看项目组情况,基于敏捷开发一个Sprint,一个Sprint迭代,节奏稳固,这个Sprint做不完可以顺延到下个Sprint,不影响发布,而瀑布模型会前松后紧,后期加班可能性很大。

  1. 一周一个迭代怎么保证质量
  1. 足够比例的自动化测试代码,可以很好的保证质量,用户的主要功能通过自动化测试覆盖时,基本可以保证主要功能流程不会出问题
  2. 一个Sprint开发完毕后,并不立马部署到生产环境,而是先部署到测试环境,会有一周时间测试。
  3. 有专业的测试人员进行测试,并非完全依赖自动化测试,甚至有时打的功能更新,会组织全组成员一起测试。

https://static001.geekbang.org/resource/image/30/c5/30f2a81130d5adc74921c88a0f7464c5.png

  1. 基于敏捷开发如何做计划

大厂通常会在上一年底确定第二年的大的开发计划,并确定上线的时间范围,每个季度再根据实际情况进行调整,大的计划会变成具体的开发任务,大的开发任务会分拆到各个部门,各部门再将任务分拆到各个项目组,基于敏捷开发的话,要看开发任务放到哪几个Sprint去做,并且确保在规定的时间范围内完成。攻击估算上,会对每个Ticket进行打分,根据分数评估工作量。

  1. 如何沟通协作?

组和组之间的沟通协作,主要通过邮件、会议、内部沟通工具,最终任务会以Ticket的形式体现,团队内部的话,每天站立会议都是很好的沟通方式。敏捷开发中的一种实践结对编程,两个程序员一台电脑工作,这个争议一直比较大,不过我觉得如果两个人一起排查Bug,或者资深程序员带新手程序员,我觉得到时非常好的协作方式。

  1. 上面介绍的实践案例和标准Scrum有什么不同?

角色称呼不一样,Scrum里是Product Owner、Scrum Master和Team,而本案例是产品经理、项目经理和开发测试人员,而且传统项目经理是偏控制型,而Scrum Master是服务型,主要职责就是保障敏捷流程的执行,以及提供必要的帮助,集体决策是很好的团队决策法。

Scrum有四种会议,每日站会(Daily Scrum)、Sprint计划会(Sprint Planning)、Sprint回顾会议(Sprint Retrospective)和Sprint评审会(Sprint Review)。

敏捷开发核心其实并不是应用了哪个方法,而是应用的时候,是否遵循了敏捷开发的价值观和原则。

总结起来,大厂的敏捷实践,关键是分而治之,很注重流程和工具使用,通过Ticket方式来管理和跟踪开发任务,通过自动化方式来部署生产环境测试。一般基于Scrum、极限编程和看板。

2018-01-02 09:48:07 unize4 阅读数 720
  • SCRUM敏捷开发视频教程

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

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

开发模式以及流程

参考禅道敏捷开发论坛1整理除了一份(可能)适合自己公司的开发模式,具体如下图:
这里写图片描述

小团队对于项目开发上也走了很多弯路,目前还处在一个探索阶段,出于多种考虑很多看起来比较完善的方案无法去实施。


2019-09-19 21:57:41 qq_39188747 阅读数 681
  • SCRUM敏捷开发视频教程

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

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

敏捷开发:

      就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态

优点:

1、敏捷开发的高适应性,以人为本的特性。

2、更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

缺点:

  1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难

传统瀑布开发优缺点:

优点:

1. 为项目提供了按阶段划分的检查点。

2. 当前一阶段完成后,您只需要去关注后续阶段.

3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导

缺点:

1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。

2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险

3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4. 瀑布模型的突出缺点是不适应用户需求的变化

 

Scrum开发流程中的三大角色 

产品负责人(Product Owner)

主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

流程管理员(Scrum Master)

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

开发团队(Scrum Team)

主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

过程:

1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品

7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中

2017-04-11 08:43:33 lsh000111 阅读数 8915
  • SCRUM敏捷开发视频教程

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

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

很早以前,就有这么一个想法:开发一套高效的、用于软件开发行业进行项目管理的管理型软件。之所以有这个想法,与我本人的经历有关。早年,在做**系统的时候,部门的总监就让我去做那么一套东西,基于Visual Basic和adodb,当时确实是经验、眼界、思路都不足,确实带着尝试和研究的心态去做了,只是限于以上的局限性,做出来的东西怎么说呢?显得很小家子气,因为没有做专门的界面设计,UI设计也不大气,在部门内部只能实现基于局域网的任务分发、周报编写和文档的上传。


以上内容,和敏捷开发管理流程没有任何的关联,纯属胡乱联想而已。

1、Leangoo,这个工具是我通过网络搜索了解到的,通过网站,我注册了一个账号,新建了一个product backlog并查看了网站现有的部分实例,总体来说,综合了敏捷开发管理的思路,视图清晰,感觉不错。


2、Teambition,这个是之前就了解到过的一个软件,有网络版也有app版本。有任务管理、FAQ管理什么的,也还不错,但敏捷性管理的任务卡片、看板、燃尽图什么的概念在软件内好像没展现。给我印象最深的是FAQ,也许是和我本人的工作性质有关系,个人觉得这个模块比较实用。这些是之前的状况,不知道现在是否有改版,好久没有去看了,也许有更新吧。


附上知乎上看到的一段话,加深理解,无论什么开发管理方法,以人为本是核心,以实现目标为宗旨:

首先,敏捷开发是一种过程控制论,通俗的说,就是一种做事情的方法。

1. 它适用于软件,因为软件是软的,可以改。要是硬件,改起来就没那么方便了
2. 它适用于客户不知道自己要啥的情况,其实,这样的客户占绝大多数。因为客户不知道要啥,所以你需要不断帮客户弄明白他到底想要啥。。。换句话说,你需要和客户沟通,合作,倾听反馈,持续改进。。。
3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步的把汽车改成飞机,还能按时交付。
5. 它适用于在一个地方办公的小团队,一般10个人以内。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的。

其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个来提高工作效率。

比如:
1. 站会:三个问题,简洁有效的小团队沟通方式
2. 看板:直观反映工作进度,反映流程遵守情况,反映流程缺陷
3. 演示,计划,反思会:适合于小团队的协作和优化反馈方式
4. 用户故事:站在用户的角度讲需求



作者:付聪
链接:https://www.zhihu.com/question/19645396/answer/16635773
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

2017-11-03 22:24:58 shenmagege 阅读数 848
  • SCRUM敏捷开发视频教程

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

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

大型软件的团队有效协作对项目成功起到越来越关键的作用,“敏捷之旅广州站——精进之旅”的活动,请来了业界敏捷项目管理的专家做了几场公益性的讲座,涉及敏捷开发应用和互联网项目管理的一些实用的方法,本文结合个人体会做个总结。


敏捷开发实际上是一种增量迭代开发模式,对于直接面向市场最前端用户、前期需求不太明确项目比较合适。通俗点说是小步快跑,边跑边看用户反应,然后根据情况适当调整项目计划,也可以说是一轮又一轮的PDCA循环。


类似360安全卫士、QQ电脑管家这种大而全的软件,幕后都是数百人的团队相互协作来实现持续更新发布,具体支撑快速发布版本的方法有下面四点。


一、统一阶段目标


就是在一个周期内确定需要做什么功能,要实现什么目标,整个团队奔着统一的目标去行动,中间不要插入新功能干扰进度。确定阶段目标后,团队上车开始刚活,目标完成,团队下车准备进入下一轮功能迭代。


二、解耦


学计算机的人对这个词应该比较了解,通俗点讲就是保持独立性,解耦具体分三个方面:

1、技术解耦

即从下至上:底层核心架构、应用程序、UI有清晰的分层,这样做功能扩展开发会比较方便;

2、业务解耦

即业务功能模块的独立性,大的功能需要尽量拆分成独立的特性模块,便于划分开发任务 ;

3、团队解耦

将大的团队划分成独立的团队(5-8人为佳),每个团队负责独立的特性模块开发,团队包括产品需求分析、项目管理、开发人员、UI,所谓麻雀虽小,五脏俱全。


三、配置管理体系


一个大的项目被划分为不同的特性功能模块后,每个特性功能可以认为是这个大项目的一个配置项。


配置管理体系的主要特点:

每轮迭代周期中,开发并测试OK的特性功能模块可以先发布,不用等待这个周期内尚未开发好的功能;

云端控制,即发布出去的功能如有问题,能通过云端控制回滚;


四、自动化体系支撑


即自动化构建系统、自动化测试、自动环境部署、自动监控等辅助支撑快速发布的东西。


END


个人微信号:gdengjun

添加时请注明:[城市] [行业]等信息



作者:邓俊

坐标广州 项目管理和职场分享


敏捷开发详谈

阅读数 52

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