敏捷开发的总结_敏捷开发总结 - CSDN
  • 项目管理之敏捷开发总结

    千次阅读 2018-04-13 01:15:16
    瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...

    瀑布模型

    简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品

    一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。

    弊端:

    1.接力棒的协作模式带来信息差:瀑布模式下,业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,研发团队不了解需求背后真正的业务诉求,业务方不了解技术方案背后的权衡。

    2.难以响应变化瀑布模式下,所有的需求分析和设计工作在开发前完成,并假设需求不会改变,研发过程只需遵循最初的项目计划和范围。事实上,对需求的发掘和理解,应该是一个持续的过程,需要不断地反馈。”


    敏捷开发:

    敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征


    Scrum:

    目的

    1. 适应变化。Scrum 的一个基本假设,就是外部需求模糊而难以理解。Scrum 对此的理念是:让客户直接看到半成品,他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的:比如每个 Sprint 结束时由 Product Owner 为客户进行展示,又比如任务细化一般不超过一个 Sprint。理解了这一点,才会理解为什么 Scrum 似乎总在变化,因为需求总在变化。
    2. 快速迭代。Scrum 的另一个基本假设,是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本,而竞争对手半年就能发布,那么几年之内,我们就会被对手甩得远远的。Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
    3. 我们作出的决定中, 50% 都是错误的。早早失败,早早学习。因为发布周期缩短,团队没有能力保证作出的每一个决定都正确,很多开销都必须花在试错上;快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布。

      Scrum 对此的解答是:不要试图不犯错误,而是保证小的错误能被尽快发现从而不会酿成大错

    流程:

    1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ,这是由 PO(Product Owner) 负责的

    2.ST(Scrum Team) 会根据 PB 列表,进行工作量的预估和安排

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

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

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

    6.做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员

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

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


    极限编程:简称XP

    思想:交流、简单、响应和勇气:加强交流;从简单做起;寻求反馈;勇于实事求是


    敏捷开发的特点

    1)敏捷开发中更加强调沟通,沟通频率可能比以前更高,沟通时间可能会比以前更长,占用更多的个人工作时间,反而可能因此导致实际开发时间起过原来开发出某个功能的时间; 

    2)敏捷开发是从用户视图出发,可能会要求工程师成为所谓“全栈工程师”,使开发人员反而感觉工作量增加了,短时间内会表现出开发效率的下降,而且要求所有开发人员对需求的理解能力也要求更高了,所以很多人会感觉敏捷开发对人员的要求更高,其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。 

    3)快速的迭代使重构工作量增加,会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识,不仅会误以为影响了工作效率,而且会使程序员很受伤,因为他们认为是在不停地返工。 

    4)信息的透明性要求较多的数据收集,敏捷成熟度越高,收集的信息就越多,收集这些数据会占用一定的精力,如果不能够正确的理解这些数据的价值,会让程序员感觉浪费了很多时间在做无用功,反而降低了开发效率。 


    敏捷开发的流程:

    需求评审:

    (1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

    (2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

    (3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

    (4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

    (5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。


    敏捷开发的思想

    1)拥抱变化:各种因素都会影响计划的执行,所以计划要短,及时调整才能响应一切变化导致的计划的不可行性,避免走弯路。 

    2)快速响应:市场环境的变化,越来越要求产品、服务的响应及时。比如按照传统方式,规划半年一个版本,一旦需要调整需求,后面所有的计划都得改变,会为项目管理带来极大的挑战,变化的成本奇高,多数情况下会因为多数人的反对而不了了之。响应变化胜过遵循计划

    3)快速将功能推向市场变现:迅速占领市场更显得尤其重要,这是在向时间要效益。比如做个用户系统,按照程序员的想法,一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完,而如果按功能逐版本开发而不是一次开发完成,而是放在不同的版本里,可能需要更多天数,因为里面会有重构、修改界面等,但是应用可以在第3天就上线。争取了15天上市时间,有哪个系统因为没有验证码在上线后第3天就就被恶意注册?有几个用户会在6天后就忘记密码?有几个人会在9天后就修改密码?有几个人会因为登录频繁因为没有记住密码功能而不在使用?,讲到这里,那位朋友想起他们在上一个版本中的一个功能,如果这个功能按照敏捷的方式开发,可以早3个月推向市场,每个月有上千万的收(上线后的效果统计数据),这才是敏捷真正的价值所在。 

    4)做最值得做的事:什么事最值得做,什么事就优先级最高,也就是ROI最高,ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标,非常复杂的综合指标,它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关,需要全方位评估。


    敏捷开发的误区

    1)敏捷开发不是用来管理开发人员的,不是用来提高开发人员的工作效率的,而是企业全面提升团队绩效的方法

    2)瀑布开发模型是以文档为驱动的,把需求文档写出来后,根据文档进行开发的,而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。 

    3)在敏捷开发中每次迭代都被成为一个sprint,中文意为“冲刺”,可见其速度与效率

    4)尽管对敏捷开发的变通运用,可以带来巨大的效益,但现实情况是,多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中,在经历阶跃变化前,交付能力可能还会下降,当经历这个转变后,才开始获得交付能力的提升。

    5)当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时,存在一个显著的风险,即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情,却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展,同时执行业务最好的方式也在不断转变。因此,执行一个大爆炸式的“敏捷”转型后,想当然地认为进一步的改进不再必要,是一个错误认识。

    6)没有MRD,如何管理好需求?使用story模式来管理需求,将庞大的MRD划分为一个个可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了可节省大量的需求评审时间。

    7)项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。从这里可以看出通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。

    8)敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”,  “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?  答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:

    客观因素\最适用方式敏捷 (Agile)计划驱动 (Plan-driven)形式化的开发方法 (Formal Method)
    产品可靠性要求不高, 容忍经常出错必须有较高可靠性有极高的可靠性和质量要求
    需求变化经常变化不经常变化固定的需求,需求可以建模
    团队人员数量不多较多不多
    人员经验有资深程序员带队以中层技术人员为主资深专家
    公司文化鼓励变化, 行业充满变数崇尚秩序, 按时交付精益求精
    实际的例子写一个微博网站;开发下一版本的办公软件; 给商业用户开发软件开发底层正则表达式解析模块; 
    科学计算; 复杂系统的核心组件
    用错方式的后果用敏捷的方法开发登月火箭控制程序,  前N 批宇航员都挂了。用敏捷方法,  商业用户未必受得了两周一次更新的频率。敏捷方法的大部分招数都和这类用户无关, 用户关心的是:  把可靠性提高到 99.99%,  不要让微小的错误把系统搞崩溃! 

    专有名词:

    PB: Product Backlog , 即按优先顺序排列的一个产品需求列表,只能有一个产品backlog

    poProduct Owner产品负责人

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

    sprint backlog和Product Backlog的关系


    每个矩形都表示一个故事,按重要性排序。最
    重要的故事在列表顶部。矩形尺寸表示故事大小(也就是以故事点
    估算的时间长短)。

    sprint每次迭代都被成为一个sprint,中文意为“冲刺”

    story:翻译是故事,本意是产品的功能,backlog中包含了许多story,故事中包含了如下字段

    1、id

    2、name,也即功能名

    3、重要性,越高越重要

    4、初始估算,该故事所需工作量,单位是故事点,3个人需要4天时间,就是12故事点

    5、如何做演示,测试规范

    6、注解

    例如:



    注意点:

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

    2、Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

    3、sprint计划会议:

    内容:

    (1)制定Sprint目标

    (2)团队成员名单

    (3)Sprint backlog(Sprint中包括的故事列表)

    (4)确定sprint 演示日期

    如何做:

    创建索引卡,放到墙上,这种用户体验比计算机和投影仪好得多。


    每个故事下面有多个任务,任务只会存在于故事下面,而不会存在于product sprint中


    4、们已经完成了 sprint 计划会议,应该创建 sprint backlog 了。它应该在 sprint 计划会议之后,第一次每日例会之前完成,这样规划:没做的,正在做的,已经做的,和燃尽图


    经过每日scrum后变成这样:


    最后变成这样:


    对于燃尽图:


    5、每日例会,时间15分钟,每个人都会一边描述昨天已经做的事情和今天要做的事情,一边移动任务板上对应的即时贴,如果他讲的是一个未经计划的条目,那他就新写一张即时贴贴到板上。如果他更新了时间估算,那就在即时贴上写上新的时间,把旧的划掉。

    如果有人不知道今天干什么,解决方法

    (1)请人添加更多的即时贴上去。接下来我就会对觉得自己没事可干的人说,“我们已经过了一遍任务板,你们现在对今天要做的事情有想法了么?”。希望他们有点儿概念了。

    (2)如果他们还不知道该干什么,我会考虑他们是不是可以去跟其他人结对编程。

    (3)从任务板右下角的“Next”区域中拿出一两个故事,放到左边的“not checked out”列中。接下来重新进行每日例会。告诉产品负责人一声,你已经把一些条目加进了 sprint

    6、对于大部分的团队sprint长度为三周,一个sprint包含10个故事左右

    7、对于故事的任务量估算需要每个成员都参与,每个故事的估算,需要每人给出一个故事点,如果两人故事点相差太大,要讨论为什么,直到把所有工作估算完

    8、Sprint 演示(有人也叫它 sprint 回顾)是 Scrum 中很重要的一环,且所有的 sprint 都结束于演示

    9、Scrum 注重的是管理和组织实践,而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题,可以互为补充,相得益彰

    10、测试驱动开发(TDD):测试驱动开发意味着你要先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复。整理一下,然后继续

    11、把测试人员放到 Scrum 团队来提高质量。如果团队在做 TDD,从第一天开始,大家都会花时间来编写测试代码,此时测试人员应该跟编写测试代码的开发人员一起结对编程。

    12、多项目一起进行,那么两个项目的sprint应该是同步的


    同步进行的 sprint 有如下优点:
    可以利用 sprint 之间的时间来重新组织团队!如果各个sprint 重叠的话,要想重新组织团队,就必须打断至少一个团队的 sprint 进程。
    所有团队都可以在一个 sprint 中向同一个目标努力,他们可以有更好的协作。
    更小的管理压力,即更少的 sprint 计划会议、sprint 演示和发布

    13、团队构建:




    参考资料:

    1、https://blog.csdn.net/nocky/article/details/51236848

    2、https://blog.csdn.net/xinxing__8185/article/details/46708439

    3、https://blog.csdn.net/baynkbtg/article/details/52402727

    4、https://blog.csdn.net/liyangbing315/article/details/5387129

    5、https://blog.csdn.net/ostrichmyself/article/details/5375223

    6、http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html

    7、https://blog.csdn.net/b0Q8cpra539haFS7/article/details/79245096

    8、https://www.zhihu.com/question/19638322

    9、scrum and xp chinese version.pdf


    展开全文
  • 敏捷开发实践总结

    千次阅读 2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
    敏捷开发实践总结

    前言
    敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

    什么叫敏捷开发?
    敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

    对概念的理解:
    以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
    迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    敏捷开发的4句宣言
    1,个体与交互 胜过 过程与工具
    2,可以工作的软件 胜过 面面俱到的文挡
    3,客户协作 胜过 合同谈判
    4,响应变化 胜过 遵循计划

    我对这4句宣言的理解:
    产品结果大于形式,先把产品做出来,然后再整理出完善的文档
    在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

    为什么要使用敏捷开发模式?
    敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

    scrum流程图:


    scrum 开发中的三种角色:
    1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
    2,scrum master:scrum的推动者,掌握大节奏的人。
    3,team:一般由多个developer组成,开发的主力。

    scrum 开发中的三大神器
    1,production backlog(产品待办事项列表)
    2,print backblog(详细任务列表)
    3,sprint burn down(计划走向和实际走向组成燃尽图)

    scrum 开发中的四个会议:
    1,sprint计划会(理解需要做什么,然后讨论怎么做)
    2,每日站会(昨天做了什么,今天打算做什么)
    3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
    4, sprint回顾会(讨论哪里完成好,哪里需要改进)

    SCRUM敏捷开发流程是什么?

    1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
    3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
    4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
    5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
    6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
    7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
    8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
    9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
    10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

    下面是crum开发流程中的一些场景图:
    上图是一个 Product Backlog 的示例,产品需求列表

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

    上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

    作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
    1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
    2,及时是敏捷开发,也要尽可能的有详细的需求
    3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
    4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
    5,坚决杜绝以下问题的出现:
    需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
    代码质量低劣不停出更新版本,叫快速迭代中;
    不写正规设计文档,叫降低沟通成本和最好的文档是代码;
    领导站身后指挥码农写代码,叫结对编程;
    产品质量不靠设计靠测试的,叫测试驱动研发;


    参考:


    展开全文
  • 敏捷开发大会总结

    千次阅读 2012-09-20 14:08:29
    9月份的12日下午、13、14两天,参加了第七届敏捷开发大会,虽然自己没有做过敏捷项目,但因为现在“敏捷”是流行词,想看看自己公司的项目能不能用,所以就拿着领导的大洋,风风火火的参会去了,接受各位牛人的轮番...

            9月份的12日下午、1314两天,参加了第七届敏捷开发大会,虽然自己没有做过敏捷项目,但因为现在“敏捷”是流行词,想看看自己公司的项目能不能用,所以就拿着领导的大洋,风风火火的参会去了,接受各位牛人的轮番知识轰炸。

            Neal Ford Agile Architecture& Design

            总觉得演讲的内容与题目不太相符,在讲主要内容之前,引用了很多名人名言,比如戴明的“坏的流程会打击好员工的积极性”,泰勒的科学管理理论等,之后,主要讲了4部分内容:

            1、沟通的重要性,每个团队都要找到适合自己的沟通方式,面对面的沟通时,站在白板前,语言+文字的沟通可能是最好的。

                沟通一定要有反馈,比如敏捷中可能有即时的反馈,每天的反馈,每周的反馈等等。

            2、为什么结对编程有效

                这个最主要的论据是一个人很难同时使用左大脑和右大脑,而结对编程则可以分工,达到同时使用的目的。

            3、反馈与沟通如何结合

                这部分,讲的是具体的实践,比如在构建的时候放一点歌,在办公室里边放玩偶,在工作中创造乐趣等。

            4、为什么敏捷开发是有效的

                 因为沟通是闭环的,沟通是高效的,工作是快乐的,所以敏捷开发是有效的。

            回答的问题:

    Q1:结对编程时,对人员水平有要求吗?

    A1:要尽可能水平相近,以提高生产力为目标

    Q2:是否要保持结对的稳定?

    A2:最好1~2天换一次,以保持信息的可传承行

    Q3:如果是异地,可以形成结对吗?

    A3:尽可能在本地,可以以互相出差的方式形成本地结对。

           王红超:大规模敏捷转型

           主要讲的是华为如何开展敏捷转型工作的,听完之后的第一感觉是:“有钱真好”!

          华为是以“业务目标达成”为导向推荐的敏捷,并且把敏捷提高到了战略的高度,在这过程中请了很多业界的牛人做咨询和辅导。

           华为的敏捷转型,简单来说可以分为两步:

           第一步:统一对敏捷的认识

                  敏捷 = 理念 + 优秀实践 + 具体应用

                  其中,理念指的是敏捷的核心思想,优秀实践指的是经验的积累,而具体应用,指的是能够结合自身灵活应用才是真正的敏捷

                  在敏捷中,领导的作用是“激发”团队,而成员是全方位的积极参与者。

            第二步:建立敏捷开展辅导队伍

                    建立公司级和产品线级两级敏捷教练体系,引进几乎业界所有的顾问。采用开展日常培训、讲座等等;每年组织年度软件工程大会进行优秀实践的分享;建立内部交流社区等方式促进内部沟通。

            华为在引入敏捷的过程中,也遇到的很多问题,比如新员工大量进入对原来团队的冲击,能力的稀释;研发过载,需要面对交付压力、能力不足、沉重的技术债务等。

            最后的总结是,引入敏捷,一定要务实、理性。

             Ritchard Markelz Global AgileStrategy

            主要讲了敏捷中的领导力及创新,还有为什么要用敏捷。

            敏捷中的领导力主要体现在,把团队看成整体而不是层级,在组织中创建授权,把优秀领导从合格领导中区分出来。将焦点集中在优秀实践和成功模式上,采用激励式询问方式,如什么事我们做的好的,什么是有效的。

          使用敏捷的一个很重要的原因是:客户时敏捷的,客户关心的是如何快速解决问题,因此灵活性和适应性才是其中的关键。

          回答的提问:

    Q:敏捷方式中,计划怎么做?

    A:分层,更高层的做传统的计划,不具体到细节。

           荣浩:百年历史看管理

           不得不说,荣浩真的是才子,将管理的历史帮我们梳理的简单而清楚,把这些人和事都按照顺序列出来的话,应该就能理清大概的思路了。(理不清楚的,去了解一下这些名字代表的具体事情和理念就知道了)

            亚当·斯密、泰勒、亨利·福特、法约尔、韦伯;摩登时代、霍桑实验;休哈特、PDCA;彼得·德鲁克、列维特、钱德勒;权变理论。

            80年代的日本制造、PDCATDD、精益;90年代的组织瘫痪、流程再造,哈默和钱皮、彼得·圣吉。

            21世纪以来,扁平化的组织结构、全球供应链的挑战及国内最严重的管理的道德问题等等。

           所有的这些都说明了,管理只有恒久的问题,没有终结的答案, 敏捷也不过是解决现在遇到的问题的一个方法而已。

            乔梁:组织转型的十个要点

           主持人介绍时说,这位是传说中的乔帮主,无奈本人孤陋寡闻,愣是没听说过。

           乔帮主说,敏捷实践中,大约有75%的失败率,其中文化变革的范围是其中的原因之一。

           乔帮主还说,因为用英文表达比用中文更好理解一点,所以用英文表了。

          组织文化变革中,只变革需要变革的部分,因为人天性是害怕变革的,只有不满意程度达到一定程度时,才会变革,而变革时,应该先unfreezingunfrozen and moving to a new state 之后再 refreezing

    1、Align with business urgency。只解决TOP3的问题,不要去做那些True but useless的事情。

    2、Proper leading team。结论性的东西才能推出。

    3、Quick assessment。谁执行谁做决定。

    4、Define the roadmap and specificactions。

    5、Pilot team carefully。因为这个与信心有关,一定要考虑人的积极性和能动性。敏捷中最主要的是开放的心态。

    6、Be aware of antibody education。注意生产率与teammotivation 之间的关系。

    7、Work as a whole。把团队所有成员弄到一起,坐在一起,对所有的实践,都要体验而不是判断。

    8、Visualize everything

    9、Metrics is important。结果和过程的数据一定要有,这样才能知道底细和过程。

    10、Just give it a try。敏捷都是经验主义者,所有的事情都需要试一下并给出反馈。

            钱安川:可视化——敏捷项目管理

            钱老师其实就讲了一个故事,怎么把项目管理用数字表达出来,设计问卷的过程中和问卷的使用过程中遇到的问题,其实跟敏捷不敏捷没有太大的关系。

           仝健:共识、乌合之众和可视化

            仝老师主要通过一个经典的博弈“协同谬误”来说明信息共有的重要性,讲在项目中,信息不共有会产生的问题及信息共有会带来的收益。

            常见的信息共有的方法包括发布信息、公布标准、设定目标和制定规则。

            在项目中,把权限放给每个人,会更有自主性和责任感。

            如果不能解决问题,就把问题暴露出来,让能解决问题的人看到它。

            杜伟忠:利用可视化的工作方式打破部门壁垒

            可视化主要解决部门之间沟通成本高、管理层因为项目过程不透明而对项目组不信任的问题、每个部门都想着自己部门利益的问题。

            张忠:以客户价值为中心的公司级敏捷开发

            张老师主要讲了用友是如何推进敏捷的。在软件行业,研发人员总是很被动的,而敏捷让大家的参与度提高了。而要推进敏捷,必须把敏捷变成一种公司级的价值观。

           用友从2009年开始推进敏捷,已经有3年的时间,2009年的主题是“快速响应”,因为市场与客户都希望能快速响应;2011年的主题是“效益化研发”,公司内技术人员感觉可能不是很明显;2012年的主题是“全面推进”,重在吸引大家,建立内部俱乐部,专题推进等,转变研发视角,更关注市场价值,这时候要站在巨人的肩膀上而不是站在腰眼儿 上。

           用友在敏捷的过程中,也遇到了很多问题,如开发人员压力大(负面反馈具体而大量,实现价值与研发交付无关联等);交付物难以进行实际客户交付;多角色间协调一致的耗费比较大;保证持续发布能力的敏捷工程方法支撑不足;缺少全面支持的研发管理平台等。

           敏捷应该采用阿米巴的方式,自我生长,自我分裂,自主经营。

           如果敏捷最后能做成有趣的研发、与客户紧密关联的研发、幸福的研发就算成是成功了。

            王宇:如何引导团队快速建立信念

            王老师教会我的第一句话是“当学生准备好了,老师自然会出现”,以前总觉得自己是幸运,总是能够在希望学到什么的时候及时出现可以教会自己的人,看到这句话之后突然发现,原来在这件事上,大家都是一样幸运的。同理,当自己没有准备好的时候,即便老师在眼前晃来晃去,在耳边喊来喊去,仍然不可能有收获一样。

            亨利·福特曾经说过,我需要的是一双手,但他带给我一个脑袋。而在我们现在,员工带来的不仅是一个脑袋,更包括了他们的家人、他们的经历、他们的懊恼和忧愁。

            作为敏捷项目的领导,要有能激发出团队信念的信念。而团队最基本的信念,在Scrum里边是:开放、专注、勇气、承诺、尊重,XP中则是:简单、沟通、有序。

            要记住,每个人都是部分正确。教练的作用是在舒适的区域外迈一步。

            阳陆育:做减法的艺术

    Louis 主要讲的是CMMI3及以上团队中,如何实现敏捷转型,主要讲了几个公式:

    1、自适应流程 = 选择团队熟悉的流程 + 不断修正

    2、PMO如何管理 = 敏捷项目管理≠监管

                                   = 提供暴露问题的环境 + 专业的流程优化服务

    3、质量成本 ≠ 测试成本

                           = 沟通成本 + 团队的学习成本

    4、成功的项目 ≠ 做完了的项目

                              = 客户需要的产品 + 用户可接受的方案 + 团队可接受的质量

    5、协作 ≠ 消除分工

                  = 各司其职 + 紧密沟通

    6、开发 ≠ 编码

                   = 正确的理解问题 + 提出可接受的设计 + 完成可交付的代码

           在CMMI3及以上团队中做敏捷,要使用做减法的艺术,要提取现有流程资产引入敏捷基础实践逐步剔除控制式监管 + 构建学习型组织 + 引入更多工程实践,其中学习型组织是关键,敏捷之所以能敏捷,就是因为每个人的能力都在提高,而所谓的学习型,则是指把某些人的知识传递给别人并固化下来。

           把现有流程当成资产对待,按照以下方式处理:

    1、文档:有区分的对待,有计划的简化。尽量避免write only的文档。

    2、检查点:权力下放,减少或者延迟检查。让每个做事情的人成为检查的执行人。

    3、测量域:明确目标,服务导向。根据团队的实际情况制定测量域,测量结果要纵向对比而不是横向对比。

    4、测试:是开发协助型测试还是验收型(放行性)测试?前者的作用是改进生产的正确率,测试人员是开发人员的助手。

    展开全文
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
    敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。  敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 ...

    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    
    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • Scrum实施【敏捷开发总结

    千次阅读 2015-02-02 17:12:26
    Scrum敏捷开发 实施
  • 关于敏捷开发总结

    千次阅读 2012-08-31 16:28:07
    用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会...
  • Scrum 敏捷开发ppt 实用篇
  • 敏捷开发总结

    2018-05-24 11:20:45
    一、敏捷开发是一种开发方式 敏捷开发,英文是Agile Development,是一种以人为核心、迭代、循序渐进的开发方式,是一种软件开发的流程。它会指导开发人员用规定的环节去一步一步完成项目的开发。由于它采用迭代式...
  • 关于敏捷开发的一点总结与感悟

    万次阅读 2017-08-01 19:23:51
    一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值
  • 敏捷开发 Scrum 总结

    千次阅读 2015-03-06 15:31:07
    最近把之前学习 Scrum 的资料整理为一篇文档,在接下来的团队和项目...《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》硝烟中的Scrum 和 XP火星人敏捷开发手册Scrum-Checklists维基百科:http://zh.wikipedia.org/wik
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发方法总结

    2018-10-23 10:10:39
    敏捷开发方法 极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快 水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论 并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。 背景 我们公司引入敏捷开发的时间并不长,在实施敏捷的过程还存在一些...
  • 从传统开发模式的思维,转换到敏捷和迭代开发肯定会有很多的疑问,这些疑问通常是公司管理层对敏捷和迭代开发抱怀疑态度,或者没有信心的主要原因,因此,在本文中,我以问答的方式,试图去整理一下自已对敏捷和迭代...
  • 敏捷开发架构图5.Scrum管理框架 敏捷学习总结-敏捷思想与基础 1.敏捷宣言 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 2.敏捷12条原则 (1)...
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 09:58:51
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这个引号给去掉。 本文...
1 2 3 4 5 ... 20
收藏数 42,372
精华内容 16,948
关键字:

敏捷开发的总结