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

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

    10404 人正在学习 去看看 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. 延迟产品生命周期
2016-02-26 18:12:50 njafei 阅读数 5116
  • SCRUM敏捷开发视频教程

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

    10404 人正在学习 去看看 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下来、就可以拿着记录去和产品负责人谈这些问题。

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

2017-08-09 10:48:10 senliaobeng9550 阅读数 265
  • SCRUM敏捷开发视频教程

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

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

敏捷开发模式的修炼之道

CSDN:请问你是如何接触到敏捷开发的?你如何理解敏捷开发?

黄勇:曾经我们开发项目都是采用传统的“瀑布式”流程进行开发,即需求、设计、开发、测试、上线等阶段,其中每个阶段都有明确的交付时间点,且每个阶段都依赖于它的上个阶段,一旦需求有变化,就会影响后续的每个阶段,项目管理存在一定的风险。为了避免这个风险,做到更好地拥抱变化,我们尝试使用了敏捷开发方法,最为典型的是 Scrum。我们参考Scrum 的流程结合自身的特点,总结了一套更容易落地的Scrum,后面我会跟大家讲到一些相关细节。

我理解的敏捷开发实际上是一个轻量级的项目管理规范,因为我们可以将整个大的需求范围拆分成若干迭代周期,我们为这些迭代周期设置明确的里程碑,且评估完成这些功能需要花费的成本,更重要的是,每次迭代完成以后,我们会对本次迭代进行一个回顾,取其精华,去其糟粕,不断完善,持续改进。

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 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

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

2014-01-11 18:46:45 YHC2113 阅读数 747
  • SCRUM敏捷开发视频教程

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

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

开发工作中使用的敏捷开发模式

来现在的公司有一段时间了,现在主要用java开发采用敏捷的开发模式。因为以前工作中对敏捷的了解比较少所以觉得有必要进行梳理总结下。

敏捷开发的定义及解释说明这里就略过了,想要详细了解的朋友可以猛点这里(敏捷开发详解)。

谈敏捷开发先从流程讲起吧。首先,每天早上我们会有一个晨会( 站立会议 ),主要汇报昨天自己所做的工作及自己在工作的过程中所遇到的问题,然后叙述今天计划的工作,组内成员依次汇报组长做好笔录。如果组内成员有遇到自己不能解决的问题,晨会上提出来大家共同探讨,但如果估计讨论时间会比较长的时候就会安排会下协调处理,毕竟每个人的时间是宝贵的。这是一个高效的会议意在了解组内各成员的工作进度及状态。

会议结束后大家就得忙各自的Story去了,说到Stroy可能有朋友会问了,什么是Story?下面我们就一起来了解下,说白了敏捷里面Story就是项目启动前你的项目经理或组长将项目划分出来的一个独立的功能模块。然后根据组内成员的特长安排的开发任务,在迭代中(通常两个星期为一个迭代周期)开发完成。一般测试人员会在开发人员开发Story的期间完成测试用例的编写,便于开发完成Stroy后showCase(开发人员在本地环境运行story供测试人员测试)时进行验收。showCase通过后Story算是初步通过,因为迭代模式中的每个模块交付时都必须是独立可运行的也是集成可测试的,所以,功能代码在测试环境集成测试无误后该Story才算验收通过。

开发人员完成编码工作后并不意味着任务就结束了,这只是刚刚开始。是的,没说错,刚刚开始!测试人员会在测试环境对各个模块进行测试,如果发现问题会及时的在bug反馈系统中(用于跟踪问题的解决进度及完成情况)提出问题单进行跟踪,开发人员编码完成后最主要的工作估计就是和这个系统打交道了,需要及时的查看解决bug系统上面的问题单然后对问题单的状态进行变更,便于测试人员回归测试。

当然,让测试人员发现并反馈了很多的问题也是让我们开发人员比较苦恼的一件事情,毕竟不是什么好事儿。谁都希望自己交付的代码能够经得起考验,少出现或不出现问题(当然我们知道这是不可能的),那么怎么办呢?敏捷里面针对类似的情况也有合理的应对流程,确保高效、高质、高产按时的交付。那就是我们常说的结对编程,通俗的说就是A和B两个人划分为一个编程小组,有问题及时沟通反馈。甚至A看着B或B盯着A写代码也是一件比较常见的情况。A在提交自己的Stroy时必须先让B检视Review一下自己的代码,发现了问题应修复完成后才能让测试人员去测试。这样可以避免一些不必要的错误和疏忽出现,提高开发效率的同时提高编码质量。

还有一种防范问题发生的措施,那就是集体检视代码。

迭代开发中一个星期后,团队成员的编码工作基本上完成了或完成了大半。这时候头儿会组织一个开发人员会议,就是开发人员坐到一个会议室里面瞪着大眼在投影仪上找bug或编码规范问题。团队的力量还是巨大的,一会儿功夫一个功能模块可能就给你揪出了十几个bug,大家一起发现的问题会议结束后会形成一个bug列表,按责任人给依次分配下去解决。相当于集体重构了一次代码,让系统更加的健壮、稳定。

经过九九八十一难般的两个星期就这样循环反复中一闪而过,这时候我们可以暂时的小憩一会儿了。

这一会儿是多久呢,大概也就是一天左右的时间吧。因为一个迭代周期结束后,项目组成员会再次的坐在一起开一个即重要又轻松的会议--迭代回顾会议。大家吃着零食边谈论总结这个迭代中做的好的部分及需要改进的部分,“嘿,那个谁上次那个地方我说应该XX做样吧!”、"这个迭代中XX同学给予了我很大的帮助,感谢",大家你一言我一语就这样展开讨论开来...

回顾会议的第二天,开始了上面工作的第二次循环,直到整个项目交付......

原文链接:http://www.cnblogs.com/zzxbest/archive/2012/10/29/2745639.html


2018-11-21 00:56:50 OliverZang 阅读数 605
  • SCRUM敏捷开发视频教程

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

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

“你有了解哪些开发模式?” “你了解的这几种模式有哪些不同” “测试方法与目的是什么?”
带着这些问题,我们来看看Agile 中的Scrum 与 TDD

Agile
敏捷开发模式,实质是一种以人为本的开发理念,重视团队沟通,重视客户反馈,重视产品迭代。
根据Agile的思想,我们主要有Scrum和XP两种开发实践,XP中又以TDD较为流行。

Scrum

项目经理从客户(产品经理)获取初步的需求,建立需求列表;
项目经理(可以分为PO与ScrumMaster)定一个sprint的周期(4周例如),按需求列表分配优先级,以此为前提,与开发小组讨论工作量backlog;
技术总监按backlog分配任务;开发小组集中速度开发。
项目经理每个sprint向客户递交可视化产品,评审并讨论迭代需求。
循环迭代,直至递交完整需求的产品。

优点:有效提升用户满意度,产品成功率;量化,透明的开发任务,增加效率;不同开发岗位之间的互动,培养了团队凝聚力,减少技术代沟产生的摩擦。

缺点:项目经理要求极高,对外部客户的需求更变所带来的backlog,经费以及质量控制要有明确的量化能力。对产品迭代需求的优先级划分要合理。对内部开发人员/QA的信息互换要即时。
对开发人员有更高的要求,没有完善的设计文档(UI/原型)约束,容易产生理解误差,不能解决反复修改需求带来的工作量积压问题,即递交产品前的开发工程量不变甚至更多。

Scrum小结“敏捷”实质上是对产品需求完善的速率,不是加快工程速度,而是产品后续打入市场的速度!
正如微信等产品,通过用户反馈后迭代部分业务功能并及时更新即是agile的思想。

由上可知,Scrum对开发人员个人也提出了更高的要求,尤其是对需求的认识。

此时我们需要引入TDD的开发模式了,即先写测试后写业务代码。

T实际上能映射现实业务的需求,在“莽”代码前,开发人员先分析需求,完善测试,再按照测试要求完成代码书写。这样的功能模块跑起来才是有效的,这样的集成系统跑起来才是有质量,少返工,真前进的工程。

经过一些网络资源的阅读与大佬经验谈,TDD给我的第一印象是前期引入较为困难,测试例的推导不全,后期补测试例的情况较多。如若在Scrum中引入TDD,开发人员Sprint工作量积聚上升,抱怨与抵触声随着backlog增加而来。

可以推断,TDD对技术总监的要求更高,需要对开发成员进行思想的指导与实践的论证,团队熟练掌握后,后期对于产品的质量的确会有进一步的保证。

总结:Scrum与TDD近几年的普及与实践都顺应了互联网瞬息万变的节奏,这两种开发模式都对开发人员个人,提出了更高的要求。

OK~屁文写完,继续补技术知识去了。

什么是敏捷开发?

阅读数 4515

Agile敏捷开发模式

阅读数 861

Agile敏捷开发模式

博文 来自: tmcrazy
没有更多推荐了,返回首页