2019-01-22 19:56:09 KamRoseLee 阅读数 222
  • SCRUM敏捷开发视频教程

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

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

软件开发遇到重要问题:

  • 学习  是软件开发中一大瓶颈
  • 如何让成员积极主动,负有责任感,能解决问题,并凝聚成一支高效的团队?

敏捷开发历史:

  • 敏捷开发并不现代   起源于20世纪30年代的一些项目(美国航天局水星计划)
  • 最早记载使用在20世纪70年代  最早的有记载的使用迭代和增量开发的主要项目之一,是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码,进行得非常成功。
  • 1976年,第一部阐述敏捷方法的书籍    Tom Gilb在他的著作《软件度量》(“Software Metrics”)一书中阐述了他的迭代和增量开发实践
  • 20世纪80年代正式定义迭代开发螺旋模型  20世纪80年代在1895年,巴里贝母(Barry Boehm)正式定义了使用迭代开发的螺旋模型
  • 20世纪90年代推荐使用迭代和增量开发的出版物和文献显著增加
  • 2001年二月敏捷开发宣言后形成敏捷联盟  一组由17位在DSDM,XP,Scrum,FSD等领域的专家组成的代表团齐聚美国犹他州,寻找这些方法的共同点。最终,这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟

敏捷开发介绍:

敏捷开发(agile development)

     是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,

但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发由几种轻量级的软件开发方法组成

   它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等

敏捷开发原则和方法

1)迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

 

  1. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
  2. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。
  3. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成, 有些项目则每天都在这么做。

5)开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

敏捷开发实践都基于一个简单的周期

  1. 测试先行开发1)写一个失败的测试2)编写代码让测试通过3)运行测试---通过了吗?4)如果测试仍然失败,回到步骤2
  2. 日常工作流程1)在每日的站立会议中,设置团队需要完成的任务2)执行这些任务3)第二条对任务的执行情况和遇到问题进行沟通4)总结经验教训,调整第二天的工作计划
  3. 测试驱动需求1)将需求转变为测试 2)进行软件开发 3)运行这些测试,如果测试通过,任务完成,如果没有回到2
  4. 迭代 1)设定一个 完成状态 2)找到一系列需求,构成迭代待办事项,并承诺完成3)一一解决待办事项4)迭代结束,一一检查每个事项是否达到,“完成状态”,如果是,标记完成,否则将他们放回待办事项中,以待日后处理。
  5. 演示 通常在迭代末进行演示,客户可以利用这个机会,验证针对预期需求的实现是否真正地解决了当前的问题 1)确定需求的业务价值  2)定义需求 3)实现需求 4)验证实现的功能是否满足业务需要
  6. 回顾1)确定团队的工作方法 2)在迭代中应用这方法 3)反思总结实践过程中的好坏方面 4)找到一些更加有效的方法,确定什么时间,谁负责实行
  7. 版本发布 1)创建该版本的远景,并设定需要达到的业务目标2)创建该版本的待办事项3)通过多次迭代来发布该版本4)为部署,并为下一个版本收集反馈信息
  8. Scrums的Scrum会议  会议来进行信息同步,通过沟通和讨论来展示自己的进度和解决遇到的问题,这能提高大家感知整个企业的变化,从而积极应变
  9. 管理检验 1)与那些产品所有者或者项目负责人一起,定义项目或者是某个版本的验收标准 2)在团队开发过程中,保证这些验收标准随时可见,使项目始终朝着期望的方向发展3)回忆会议中,一起评估标准4)让产品所有者或项目负责人和团队一起工作,保证在每一个迭代中针对这些验收标准进行检验

几种敏捷实践:

  1. 自组织团队  整个团队紧密合作,同心协力,主动承担责任,竭尽所能去完成工作,响应各种变化
  2. “联合驻扎”团队  团队成员在一起工作,经常进行小组讨论,随时可以听到各种谈话,潜移默化中就了解到发生的事情
  3. 跨职能团队  来自不同背景的人组成一个团队,自始至终地进行开发来解决一个问题。因为大家在一起紧密协作,各自的专长就会得到分享和传播
  4. 结对编程   两个人一起,齐心协力完成一些任务,这个是共享经验和专长的极致体现
  5. 信息辐射器  这种大幅图表存在的唯一目的就是把重要的信息传达给每一个人
  6. 唤醒式文档  为了更好的沟通,敏捷团队成员共同撰写文档,日后每次阅读这些文档,都可以唤起大家对讨论内容和相关背景的记忆。
  7. 站立会议 在敏捷团队中,大家每天都会彼此交流自己完成什么,遇到了什么问题,明天计划如何,这就保证了所以成员步调协调一致

敏捷实践的主要动力来源:

主要动力来源:带给客户价值

  1. 缩短上市时间
  2. 增加产品使用行(市场价值)
  3. 提高产品质量
  4. 提高灵活性
  5. 增强透明度
  6. 降低成本
  7. 延迟产品生命周期
2017-03-01 16:56:54 zhyb0306 阅读数 6077
  • SCRUM敏捷开发视频教程

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

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

CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法?

黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想,Scrum 是对让这个思想落地的一个参考。也就是说,我们大可不必完全拘泥于 Scrum 定义的规范,只需要参考它并结合自身的条件做适当调整即可。比如说,每日站会这个环节就非常重要,不管是放在每天上午,还是放在每天下午,总之最好要有固定的周期。此外,每次 Sprint(迭代)结束后除了有评审会以外,Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结,哪些是本次迭代中做的好的地方,哪些是做的不好的,再对比上次迭代的的结论,哪些是有改进的,哪些是新的问题。

Scrum 提供了三类角色,分别是:Product Owner(一般由产品经理担任)、Scrum Master(一般由开发经理担任)、Scrum Team(包括开发与测试人员),其中,Scrum Master 的角色至关重要,对项目的成败起决定性作用。

阿里巴巴也在广泛使用 Scrum 敏捷开发模式,而且整个项目几十人都可以用 Scrum,只是首先需要将整个团队拆分成若干小团队,保证每个小团队按照 Scrum 进行操作,此外,再将每个小团队的 Scrum Master 召集在一起,再做一轮 Scrum,这就是所谓的 Scrum of Scrum。过程稍微复杂一点,但可以将敏捷用于更大的团队规模,并能保证敏捷的效果。

CSDN:你认为Scrum Master 的角色至关重要,对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题?

黄勇:我个人不太建议由产品经理来担当Scrum Master,原因如下:

  1. Scrum Master 关注的是项目开发视角,而产品经理关注的是产品功能视角,两者关注的视角是不一样的。
  2. Scrum Master 需要有一定的技术开发功底,需要对开发工作量进行评估,也需要对技术实现进行评审,可能还会有一定的编码工作,而具有技术功底的产品经理毕竟太少了,即便有的话,可能对技术方面也不会太深入。
  3. 需要有一个人,他来对整个产品负责,这个人就是Product Owner,该角色最好由产品经理来担任。

CSDN:敏捷开发过程中测试团队的职责和产出是什么?

黄勇:在敏捷开发过程中,我认为测试团队的职责有以下几点:

  1. 根据产品需求,定义测试用例。
  2. 针对测试用例进行功能测试,并将测试的结果反馈给开发人员。
  3. 负责搭建系统运行所需的环境,包括软件安装、数据初始化等。

CSDN:除了Scrum,还有XP、CM、FDD、ASD、DSDM等敏捷开发方法,如何去选择一个合适的敏捷开发工具或者方法呢?

黄勇:敏捷开发方法有很多,不仅仅只有Scrum 一种,其实不妨相互借鉴,再结合自身的特点,定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等,这些都是很好的方法,值得借鉴。包括看板也是一个很不错的工具,可以结合Scrum 来工作。

CSDN:从博客上,你也研究过「使用看板进行敏捷开发」,能不能分享你的研究成果?

黄勇:敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

那么 Kanban 到底是什么呢?我们先来看看这张表格吧:


下面我们来理解一下这个表格吧!

  • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)
  • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)
  • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

好!继续我们的 Kanban,有意思的事情即将发生!


产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了 然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!


CSDN:一个成功的项目,离不开每个人的努力,能够分享下你曾经的项目管理经验?

黄勇:给大家提出以下 10 点建议及其目标:

  1. Sprint 第一天,需要将目标定义清楚,并让团队所有人都知道「确保建立一致的目标并使之明确」;
  2. 若出现需求变更,则优先排到下次迭代,特殊情况需特殊处理「确保本次迭代可以按时完工」;
  3. Scrum Master 将迭代中的需求分解为任务,每个任务只能有一个任务负责人,且不超过一个人天「确保每日任务可评估」;
  4. 让 Product Owner 直接与相关开发人员确定需求,Scrum Master 需一同参与「确保需求与实现不会发生偏差」;
  5. 每日定时站会,时长不超过 15 分钟,规模不要太大「确保任务完成情况与计划保持一致」;
  6. 每日进行一次代码评审,由 Scrum Master 负责,并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」;
  7. 各个团队的 Scrum Master 保持每日沟通一次,时间不要超过 15 分钟「确保项目管理不会出现风险」;
  8. 每次迭代结束,让大家稍微放松一下,可提供一些团队活动,比如聚餐「确保团队能够更加凝聚」;
  9. Scrum Master 需要给团队一些承诺,比如项目奖金或特殊福利等「确保团队更加有激情」;
  10. 对于情绪异常的员工,Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」;

此外,作为项目管理者,需要不断在团队中加强以下 6 点文化:

  1. 方向一致
  2. 当面沟通
  3. 全情投入
  4. 充分信任
  5. 说到做到
文章节选自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315,如需阅读完整访谈内容,请移步大神博客。
2018-10-09 17:08:50 u014526891 阅读数 827
  • SCRUM敏捷开发视频教程

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

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

上面一篇文章我们提过为什么分布式需要做前后端分离,今天这篇我们从开发模式来详解为什么互联网项目使用于敏捷开发?

因为笔主经历过瀑布开发模式和敏捷开发模式这两种开发模式,所以存在有一些自己的见解跟大家交流。

下面所以我们这边先来简单介绍下这两种模式:

瀑布开发模式:

瀑布开发模式是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。
瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行
步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 总的来说,迭代周期长一些,一次性解决所有的任务,一次上线。

下面我们说说瀑布开发模式的几个特点

1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。

2.重视和强调过程文档,在开发的中后期才会看到软件原型,早起只能通过文档来了解系统的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

3.瀑布模型每个阶段的人员只关心自己阶段的工作,不需要关注其他阶段的工作。

优点:

1、可以让开发人员能够更专注于本职工作,提高阶段效率

缺点:

1、在项目各个阶段之间极少有反馈,风险往往迟至后期才显露,失去及早纠正的机会。

2、项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂

3、测试人员最后才参与到项目中来,后期风险较大。

4、只有在项目生命周期的后期才能看到结果。

 

敏捷开发模式:

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。总的来说,拆分成多个小迭代,多次上线。

下面我们说说敏捷开发模式的几个特点

1、最核心的功能最先完成,容易出成果。

2、小步快跑,尽早交付,拆分各个小迭代(spring),一定的迭代周期内需要确保开发的完成,规避了一定的上线风险。

3、各组人员分迭代来有序工作,比如:设计人员出一个模块RP,开发人员完成这个模块编码,测试人员完成这个模块测试。

4、敏捷的管理是团队的自我管理和项目经理的服务式管理,项目经理需要根据当前开发资源确保每个迭代的的可完成性,团队成员需有良好的自我管理能力,来确保小迭代内功能的完善;项目经理需要对整体启到把控作用,迭代中可以根据开发进度进行各成员工作的微调,保证迭代进度的完成

优点:

1、容易出成果,可以快速提高软件发布周期,敏捷确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品

2、测试人员能够尽早参与进项目中来,规避了一定的风险。​​​​

3、每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈​​​。

缺点:

1、迭代周期端,为了不影响迭代完整,需要项目中存在经验较强的人,要不大项目中容易遇到瓶颈问题,延误迭代进度。

2、敏捷开发要求各员工自我管理要强,所以对人员素质和稳定性的要求又更高。

 

那为什么互联网项目要用敏捷开发呢?

1、出成果(版本)快,互联网就是以快吃慢,一般都是迭代发布的,追求创新,说明了需要快速响应用户的变化,时间就是一切,需求不确定性高,这个在软件行业也很常见;关注用户行为,倡导以用户为中心的产品设计。很典型的例子微信,腾讯一个月开发出来的产品,根据用户体验和反馈,通过反复的小迭代来优化。

2、互联网项目中市场反响和客户体验尤为重要,需要有一个快速迭代来响应客户的需求,确保客户的满意度。如果是瀑布式开发,迭代慢,更改的成本也比较高。

3、随时应对变化,因为迭代周期的减小,使得项目的弹性更足,可以更好的适应互联网项目上更多的不确定性。

 

那如何从瀑布开发模式往敏捷开发模式切换?

任何开发模块的切换都是存在风险点的,包括我们前面介绍的前后端分离模式,那我们需要做什么来减少这些风险呢?

1、优先选择周期比较长的项目,资源较充足、素质较高的团队来试行。

2、需要制定一套较为完整的敏捷体系,从产品到开发到测试,选型敏捷工具

3、刚切换过来的迭代,可以适当减少迭代内容,切换过程需要缓冲时间,避免因为试行阶段出现的问题,从而团队的整个心态。

4、项目经理需要把控好任务进度,需要在迭代的中间,每天了解迭代运行情况,最好是每天团队可以有晨会。

 

 

2016-02-26 18:12:50 njafei 阅读数 5120
  • SCRUM敏捷开发视频教程

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

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

部门推广scrum敏捷开发已经小半年了、团队也从不适应、慢慢地开始变的习惯。之前领导安排我作为我们组的scrum master、因为从来没有做过leader、然后直接之前也没有接触过scrum、更是非常别扭、很吃力、因为不仅要做master的工作、还要承担100%的开发工作、开始的时候非常吃力。现在随着大家都开始慢慢习惯scrum的工作模式、我才开始慢慢地从每天1/3的时间、降到每天只要半个多小时花在scrum的管理上面。
如果要我总结中间的模式转换的话、我觉得最关键的有两点、一是大家对于敏捷的认知要深刻、要让全体成员都自我改造成敏捷开发者、二是要做好对product backlog的管理。

自我驱动

虽然我们号称敏捷了、也每天开早会、也有了自己的sprint看板、每个sprint也要开总结回顾会议、但是我觉得这些更多的都是敏捷的行、而不是敏捷的神、那么什么是神呢?我个人觉得是作为团队成员来说、神就是从被驱动、改变为自我驱动,这两者简直是两种思路。
最开始的时候、我会每个sprint之前、为组员整理好人力分配图、其实就是帮每个人安排每天的任务、然后在接口出问题的时候、也要我去催、接口卡在哪里了、有哪些解决方法。我非常累、大小事情都要操心、组员遇到问题了、也会问”master、这个出问题了“,然后就等我帮忙解决。后来领导开会、一起聊、发现其他的组也是有这个问题、每个组的scrum master都是身心俱疲、这时候、领导也说、我们其实只是组织大家在一起协作、而不是所谓的”项目经理“。
在这之后、我就有意思的从具体的事物中脱离出来、把原来的什么都管、转换为专注为大家提供一个更流畅的合作上来。我不再帮每个人分配要做哪些、而是大家自己去分配、去协调、我不再去管具体的接口的发布日期、而是让做这个story的人、自己去商量。慢慢地、大家就知道了、这个story是我的、那么、所有关于它的事物、我都要关心、story不是产品经理、也不是master的、所以大家有责任去把它做好、这样反而极大地提高了我们的开发效率、从中央处理式、变成了分布式处理、每个人都很关心当前的story、大家也有了更高的目标、不再是“我要把这个功能完成”,而是“我要为用户创造价值”。

product backlog管理

第二个非常重要的、我觉得是backlog的管理、我觉得一定要有一定数量的backlog、不仅让整个团队时刻有目标感、知道我这个阶段要做哪些事情、而且能帮助产品负责人理清自己的思路。可能很多人会觉得、作为产品负责人、肯定是接下来半年做的、都在心里了、我觉得未必、我就遇到过完全没有思路、甚至需要我一起帮理清产品思路的人。因为公司的业务非常多、任务也比较重、导致很多需求的质量不高、下个sprint都要开始了、UI的设计风格还没定、 这种事情就发生在身边!
从一个开发的角度来讲、我当时是希望需求早就定了下来、并且永远都不会变、但我知道、这个是妄想、但是我觉得、提到开发面前的需求、至少要是经过产品深思熟虑、考虑了很多不同的方式、最终觉得的一个比较好的方式、这样、即使有变化、也不会是大的变化。开发的角度就是、很不喜欢大的变化、尤其不喜欢不确定的东西、写了if、总要写个else吧、如果sprint过程中不断的变化需求、那感觉就像、正打着LOL、不停地断电、时间都白白浪费了、我觉得烂需求就是在扼杀开发的生命、就是在浪费团队的资源!一定不要让这种事情频繁发生。
我的经验是、最好下个sprint开始之前的两三天、就可以和产品要具体点需求、master先大致看下、没有什么致命的漏洞、也近来难过保证UI之类的都是完整的、会把后面可能的变动降低很多。另外需求的变更一定要有记录、这样几个sprint下来、就可以拿着记录去和产品负责人谈这些问题。

从普通的开发流程、到敏捷开发、是会有很多的痛苦、但我觉得、适应了之后、成果会让你觉得、都是值得的!

2019-05-23 13:51:53 u012169230 阅读数 45
  • SCRUM敏捷开发视频教程

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

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

读“零道书院|『干货』敏捷开发模式下,如何进行质量管理”有感。

原文:http://www.sohu.com/a/138301117_278472

我们今天有个新颖的idea,我们可以很快的让用户看到效果,很快的上线,然后去进行验证,如果有问题立即就下线,如果可以改进,下星期再改再上线。这是一个持续实现idea的过程。

传统的软件设计模式采用瀑布式开发,需求分析——概要设计——详细设计——编码开发——测试——交付,每个阶段都依赖于它的上游阶段。在敏捷开发模式中,软件项目被切分成多个子项目,单独子项目可以独立开发、测试、具备集成可运行特点。

由于互联网行业的竞争性,敏捷开发被提出用于快速满足用户需求,允许有所不足,不断试错,在持续迭代中完善产品。

敏捷开发下,如何保证在“快”的同时满足质量要求,成为了敏捷开发下的一大难题。

在推动敏捷开发的同时,如何降低项目管理成本,提高研发人员工作效率,保证项目交付质量,变得日益重要。以下是一种敏捷开发过程质量判断的方案。这种方法用明确的数据从各个维度来说明一个迭代的质量问题,长期可以看出一个项目多个迭代之间的质量变化趋势,如果多个项目同时进行,还可以轻松对比各个项目的迭代质量优劣和质量发展趋势。

以一个迭代为单元,从以下6个角度分析:

1. story延期率:统计功能是否按时提测,超过提测时间,标记为延期。

2. story打回率:统计story在开发完成提测后能否满足提测标准,以冒烟测试用例为例,不通过则打回。

3. bug打回率:开发人员解决了bug并提测,但经测试人员验证发现并未解决。

4. bug不收敛率:测试提出的bug未按照解决时效要求修复的,超过规定修复时间。

5. bug引发率:开发人员在解决一个bug时,引起了其他的bug。

6. bug重启率:已经关闭的bug在开发人员解决问题的过程中或部署误操作重新出现。

六个指标优先级从高至低为:story延期率、story打回率、bug打回率、bug引发率、bug不收敛率、bug重启率。story如果延期,会造成后面的工作整体受影响,并且测试人员的工作安排冲突。

JIRA是个项目管理工具,管理需求和开发过程以及bug、story的计划提测时间和打回次数可以进行记录,在迭代结束后很快就能统计出质量数据。

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