敏捷开发迭代总结会议_敏捷开发 迭代开发 - CSDN
  • 团队敏捷实践:迭代回顾会议

    千次阅读 2014-04-27 01:45:44
    迭代回顾会议(不超过1个小时) 1. 上一次的行动完成的证据。没有完成要怎么办。 2. 每次会议都要有记录人,会后形成会议纪要。 3. 上一次行动监督人汇报改进行动的执行情况。(3分钟/个) 4. 迭代总结(10...

    迭代回顾会议(不超过1个小时)

    1.   上一次的行动完成的证据。没有完成要怎么办。

    2.   每次会议都要有记录人,会后形成会议纪要。

    3.   上一次行动监督人汇报改进行动的执行情况。(3分钟/个)

    4.   迭代总结(10分钟)

    开发负责人介绍代码审查报告,测试负责人介绍迭代测试报告。

    总结上一周期的工作得失、发掘问题改进措施,进而推进团队下一周期的工作质量。(做的好的,要继续保持。做的不好的,要改进。)

    提早完成的任务:分享原因及方法。偏差较大的任务:分析原因及总结改进方法。

    5.   宣读(或大家一起念)敏捷回顾最高指导原则:"无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。"(1分钟)

    6.   安全度调查:5分什么都想说,4分有一少部分不想说,3分一半想说一半不想说,2分大部分不想说,1分都不想说。匿名写到便签纸上,然后对折交给主持人,宣读平均分。(可选)

    7.   形成改进行动项,团队认为现在存在哪些问题,并且团队一起要找到解决方案,团队每次形成一个或两个改进行动项。(团队写纸条归类,并且分析每个提出的事情)(5+5+10分钟)

    8.   找到行动项的负责人,并在卡片上签名。卡片将会放到看板上,下次回顾会议进行跟进。(5分钟)

    展开全文
  • 迭代回顾会议咨询记录

    千次阅读 2019-01-31 09:48:13
    每次敏捷迭代都是一次PDCA循环, 迭代的回顾会议则是其中的A(adjust),不断的复盘总结可以帮助项目一次比一次做的更好,使团队形成一个自学习的组织。  近日我旁观了一个敏捷项目组的迭代回顾会议,项目组成员对...

           每次敏捷迭代都是一次PDCA循环, 迭代的回顾会议则是其中的A(adjust),不断的复盘总结可以帮助项目一次比一次做的更好,使团队形成一个自学习的组织。

           近日我旁观了一个敏捷项目组的迭代回顾会议,项目组成员对本次迭代的经验教训进行了总结,我作为外部顾问旁观了整个过程,并对项目组中存在的问题,本次回归会议的优缺点进行了点评,咨询记录如下: 

                                                                                        迭代回顾会议咨询笔记

    类型

    相关实践

    现象

    建议措施

    改进点

    Daily meeting

    在每日站立会议上没有每个角色通报任务进展,尤其需要不同角色协同的任务。

    开发完成了什么,测试测完了什么都需要在站会上通报。每个角色都要了解其他角色完成了什么。并且要在看板上将任务状态可视化。

    改进点

    Daily meeting

    在迭代初期发现的测试人力的瓶颈问题,但是没有采取有效措施。

    当发现测试人员成为瓶颈资源时,需要增加人手。

    改进点

    Design

    开发人员做过了过度设计,把需求想复杂了,把设计的通用性想复杂了,并没有和需求沟通。

    简化原则;
    站立会议上及时通报进展;

    改进点

    Design

    缺少UI设计,导致开发出的软件不够美观,操作不简便。

    尽快招聘UI设计人员到位;
    对前端开发人员进行UI设计的培训。

    改进点

    Planning

    测试工作量、开发工作量估计不足。

    策划会议上要沟通,策划扑克法;
    需要召开需求梳理会议,充分沟通需求。

    改进点

    Planning

    有些任务没有识别出来,有计划外任务。

    估算时要识别可以提供的时间,把一些公司培训任务等排除在外。

    改进点

    Requirement

    PO出国2周,开发人员无法及时与PO沟通需求。

    每周,PO和开发至少1天一起工作。

    改进点

    Retrospective

    Retro会议详细回顾每个任务的进展。

    不需要详细列出每个任务的完成情况。首先回顾完成的需求;
    其次说明没有完成的需求:任务的进展。

    改进点

    Retrospective

    SM在会议中很少发言,没有及时制止跑题。

    SM要控制会议不要跑题。

    改进点

    Retrospective

    SM不需要对已发生的问题先分析原因。

    只列现象即可,不要引导成员的结论,不要限制成员的思考。

    改进点

    Retrospective

    迭代回顾时,没有迭代数据的积累与展示。

    统计某个迭代实际上班时间,投入本项目的时间,%;

    统计某个迭代的实际生产率;

    统计某个迭代的缺陷个数;

    统计缺陷修复类任务的工作量分布,为以后做缺陷修复工作量的估算提供参考。

    改进点

    Retrospective

    让大家自由发言,没有总结的主线。

    要采用海星法总结,给大家一个思考的主线。

    改进点

    Retrospective

    在回顾会上,有同事一直没有发言。

    要采用海星法总结,让所有人都参与进来。

    改进点

    Retrospective

    有人打断别人的发言,替他人总结问题

    在会议纪律中要强调一下;

    改进点

    Retrospective

    问题提的多,措施提的少。

    每个人在提出现象时,要给出改进建议;

    改进点

    Support

    开发环境,部署环境一致性。

    环境固化,使用提前通知,安排资源
    开发全自动化部署工具(专题讨论会)

    优点

    Design

    后端坐了设计文档,前后端的接口更容易,减少了接口错误。

    坚持。

    优点

    Requirement

    需求反讲很有效。

    坚持。

    优点

    Retrospective

    SM先宣布了会议纪律。

    会议纪律文档化:

    聚焦本次迭代;
    专心听其他人讲;
    不要强迫别人接受你的观点;
    不要跑题;

    每提出一个现象就要提出一个措施;

    优点

    Testing

    在测试之前,开发和测试做了需求沟通,有利于测试效率的提升。

    坚持。

    优点

    Testing

    做了UT的培训,开始做单元测试了。

    坚持TDD。

    优点

    Support

    大家都在使用confluence, Jira工具。

    继续在JIRA 中维护需求,集成更多的工具进来。

    优点

    Mindset

    大家都意识到了进度和开发效率提升了,对开发模式建立了信心。

    继续坚持敏捷的相关世界,不断总结经验教训,积累度量数据,通过数据客观刻画改进效果。

     

     

    展开全文
  • 项目管理之敏捷开发总结

    千次阅读 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


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

    万次阅读 多人点赞 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哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • 敏捷开发模式中的四种会议

    万次阅读 2017-04-01 14:31:03
    敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好...
  • 敏捷开发-迭代会议

    千次阅读 2016-04-19 00:33:42
    敏捷开发迭代会议,主要是挑出产品设计和功能问题,保证迭代版本的产品原型完整性、正确性、合理性。如果产品大致功能没有多大问题,留下些小问题,那么可以进行项目拆分、工时估算。(一个细节要提醒的,产品必须在...
  • 从传统开发模式的思维,转换到敏捷迭代开发肯定会有很多的疑问,这些疑问通常是公司管理层对敏捷迭代开发抱怀疑态度,或者没有信心的主要原因,因此,在本文中,我以问答的方式,试图去整理一下自已对敏捷迭代...
  • 敏捷开发迭代开发

    千次阅读 2019-06-27 17:05:44
    敏捷开发迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 敏捷开发 迭代回顾 Jonas Verstuyft在Unsplash上的照片 简单的习惯如何有助于成为更好的开发人员。 无论是在团队层面还是在个人层面,总有机会进行改进,做得更好。 您越了解动作,就越愿意尝试,改进的潜力就...
  • 敏捷开发 迭代流程

    千次阅读 2011-06-12 07:46:00
    敏捷是一柄双刃剑,用的好能极大的提升开发效率,适应需求的变化!用的不好则会导致项目的混乱。现在很多公司都说自己在用敏捷开发,很多程序员也说自己懂敏捷开发!简单的认为敏捷就是站立会议,... 敏捷开发提倡迭代
  • 敏捷开发-快速迭代

    万次阅读 多人点赞 2013-05-08 19:57:45
    今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也...
  • 从4月中旬开始,我们部门进行了破天荒有史以来第一次敏捷项目实践,... 说明: ◇在下面的流程中着重迭代开始的规划和迭代中,开发团队与测试团队的协作过程,对PO的review会议和回顾会议没有做详细阐述 ◇本流程...
  • 如何准备启动敏捷-迭代0如何做?

    千次阅读 2016-09-13 22:12:36
      迭代0是指在启动敏捷开发前的准备工作阶段,迭代0一般的时间长度不超过所选择的迭代周期。 对于看板类做法,如果没有明确的迭代周期,那么建议不超过2周,为方便,将看板类的准备工作阶段仍然称为迭代0。 ...
  • 敏捷开发实践总结

    千次阅读 2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
  • 浅谈敏捷开发迭代开发相结合  由于最近公司委派管理一个项目的开发,以往对开发体系没有特别的研究过,在遇到阻碍后开始慢慢学习开发体系,以往在项目组根据项目类型的不同都有各自一套软件开发体系。...
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
  • 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有...
1 2 3 4 5 ... 20
收藏数 12,093
精华内容 4,837
关键字:

敏捷开发迭代总结会议