敏捷开发进度面积图_敏捷开发项目进度 - CSDN
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的...

    谈谈敏捷开发模型
    我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的认识和想法。

    但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的主要做法是:

    1、项目中开始划分更短的制品交互周期,而不是以前那样等待产品开发完毕后发布各种测试版本。
    2、更充分与市场人员交流,在市场人员进行需求交底时,让更多的甚至全体成员参与会议,了解产品的原始业务及需求。并且在过程中有问题也及时的解答及沟通。
    3、加强沟通力度,开发测试都在一起每天都会开个小会,通报每日的工作成果,将自己的问题说出来。
    4、不同以往的发布频率,测试从项目开始便要切入到产品生产过程,而不是等到最后所有功能都完成后。从而大大减少变动对计划的影响。

    在做这些工作的时候我并不知道敏捷开发这个东西,直到在2010年进入一个公司非常提倡敏捷开发,已经有了迭代周期、backlog、站立会议、周例会等等,在这个团队中对开发过程有各种规章要求,完全是制度化的,这在我加入的初期非常的不适应。事实上回头想想,那种方式已经变的不敏捷了,完全是一种教条式的应用。

    后来自己有机会回到了老东家,开始自己带团队,很巧老东家被收购后开始推广敏捷开发,只不过因为不是总部,所以这次没有范本,完全由我自己来组织及控制。很高兴这个小团队几个月下来,个人觉得比较成功,当然后面也得到了公司的认可。

    下面就敏捷开发分享一些应该着重注意的点,解决这些问题我想对任何开发团队都会有很大的帮助。

    需求在开发中的重要性

    大量的开发过程告诉我,需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析,这个过程对于一些正规的团队会产生大量的文档,而后交由开发展开产品生产。

    然而,事实却不是想象这么简单,无数的例子说明了一点,仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们,需求是会变的,变的原因很多。在极端的情况下,有些客户签字的需求在开发完后,有需要变更也很正常。

    所以需求是影响软件开发的第一重要因素,需求来源于业务,我们开发的产品不就是因为这些业务才去做的吗?如何需求都无法把握好,还谈什么开发出好用的产品?

    然而如何做好需求呢?我想首先要确立需求的地位,然后只有通过不断的沟通、尝试、反馈向真实需求迈进。

    强调人与人的交流

    不管怎么样开发过程中主要还是靠人的,而且软件开发是个复杂的团体工程,一个小些的产品也会涉及到各类人:客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情,有一方没有处理好结果肯定就会有问题。

    有这样一个例子:客户提出了一个会员管理功能需求,需求人员了解后组织了解决方案,于是交付了开发实现。而经过二个月无尽的黑夜之后交付,需求一看有个模块做的有偏差,但是已经来不及修改了。交给客户看后,发现这不是他们要的会员管理功能相差较大,另外在功能开发的这一段时间,客户又有了新想法,要对原先需求做调整。

    这种例子可能大家经常经历吧?

    这种问题在敏捷开发方法中提出了解决方法,就是通过不断的交付可用的制品。看起来很抽象,其实很简单。同样是上面的例子:
    Ø 客户提出会员管理功能需求
    Ø 需求人员在了解需求后与开发负责人商量,确定一个快迭代的开发计划,每二周向客户演示一次,并将这个计划与客户确认
    Ø 确认后需求人员向全体成员讲解需求背景故事
    Ø 开发负责人组织并确定迭代计划内容,明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
    Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
    Ø 后面就是每二周向客户演示一次产品,并获得客户的反馈
    Ø 根据客户的反馈调整下个迭代计划,并继续下一个迭代
    Ø 直到产品交付

    通过上面的步骤,就不至于在开发完成后才知道用户的真实想法,因为很多用户对软件开发是没有概念的,他只知道自己有某种需求,但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型,这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内,这样一来可以大大的减少软件返工的情况,自然就不会拖延计划了。

    而这个过程中,需求已经完成了一个真正的过渡,不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的,在开发不断的交付制品时,需求也更加及时的了解到产品的进度,把握开发人员开发的功能是否符合需求。
    当然这并不是一个标准做法,不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去,及时的与客户沟通交流,了解到客户的真实想法。

    强调文档的作用

    我觉得很多对敏捷开发的一个误解就是不需要文档,敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中,特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理,最痛苦的是不好维护,文档需要随着变化而变化,比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性,太难了。特别是对于一些无法进行有效管理的开发团队就更加明显,经常是软件已经几个版本了,文档却是两年前的。

    但敏捷真的不需要文档吗?我想不是的,如何把文档做到好维护我想才是最重要的。文档到底指的指的什么?什么样的算文档?

    提出上面两个问题,我们先想想经常说的文档的作用是什么?不就是一个传播工具吗?可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题,比如wiki系统。维护一个wiki系统,可以随时写,随时维护,可以方便的查找。嗯,多方便。

    另外一个问题就是什么样的工作需要形成文档呢?

    记得在前一家公司,维护一个10多年的老系统修改一个公式计算的BUG,但是怎么也不知道这个复杂的公式是什么意思,问过了公司大部分的人也无人可解。这时想,如果当初有那么一份文档,谢天谢地。

    像这种关键的内容有份文档还是很重要的,否则随着时间推移,谁也不能保证能记得住当时为什么会这么干。

    记得多年前一次记笔记的经历,我看了一篇文章了解了DELPHI实现单实例模式的方法,这种方法很酷。于是整理成了笔记写在了wiki上,第二天就得到了回复,帮助到了别外产品开发组的同事。

    嗯,文档就是这样他具有传播性,你不可能跑去跟所有人说出你的想法,但是文档却更容易达成。他也有传承性,有些文档也许10多年后又起了重要作用。

    团队协作

    1、减少对开发人员的干扰

    曾经接手一个产品的开发,最初遇到一个很头痛的问题,原先写好的迭代计划,而且工作量也较大,大家都在忙着。即便在这样的状态下,客服人员却经常跑来找某个程序员A维护各种系统问题,程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力,而每天的这些问题又不得不解决,加之新版本又有很重的开发任务无法完成,最终导致整个开发计划变更。

    我无法再忍受,找到了需求及客服的负责人,沟通后发现这些问题很多都是重复性的,主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能,并交付给了客服人员,之后就没有再来找过这位程序员A。后续我又找到了客服负责人,要求不能直接找开发人员解决这类问题,并与负责人约定了处理过程。

    这是个例子,在实际情况中还有很多这种事情,甚至有很多开发人员要直接面对客户。我想对于职能型团队来说,开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。

    大部分的人都不是超人,在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点,尽量让开发人员有比较好的工作进度环境,通过外界的方式来解决一些开发团队的干扰。

    我接触过的很多程序员都很反感这种干扰,虽然有些人在这种全面的工作强度下成长很快,但是并非所有人都适应,长期下来会有怨恨和不快,工作效率会下降。心情舒畅还是很重要的,记得有一次迭代总结时,有个程序员总结说:发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。

    2、不要忽略测试人员在开发阶段的作用

    曾经多少次在项目发布前加班到深夜2点的情景还历历在目,那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了,产品却迟迟未集成完成,测试只能干等着上网聊QQ。就在下班前的一刻发布了,测试开始了紧张的测试,在屏幕闪动中,一个个的BUG提交,直到流程都无法都走不下去,测试无奈了。第二天就要发布,实施人员就等着制品第二天出差。只有不断的改,再发布,无尽的循环。直到大家都憔悴的看着老大,终于老大说:还剩下的这几个问题无关紧要,大家回去吧。

    几个月的开发过去后在总结会上,只能抱怨测试资源不足,时间太短,需求更改太多,需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。

    上面的这个例子很多人应该经历过,真的测试只有最后一刻才能体现价值吗?我想不是的。

    在后面的项目中我总结了这个问题的,针对每个开发任务要求进行测试验证。而测试如何验证呢?他需要知道这个开发任务的需求是如何,提前做好测试计划及测试用例,在接到开发制品后测试并提交BUG,这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量,可以大大减少后期集成的错误量。

    另外根据敏捷开发的思想,测试团队在开发过程中也需要加强与开发团队的交流,甚至有必要组成虚拟团队,位置调整到一起,这样可以及时快速的交流,参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度,反过来把握测试计划及测试内容。

    特别是测试从另一个角度来审视需求,这样也可以一定程度上发现或者改善需求上的不足。

    3、发挥团队人员的潜力

    敏捷开发比较提倡开发任务由开发自己评估并认领工作任务,这样可以激发开发的潜在动力。

    之前在做一个新产品时,需要使用java,而我们团队是使用C#的,面临转型问题。而有一位同事很感兴趣,于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高,我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时,这位小伙已经成为了团队的大牛,大家有问题都找他解决。也正是因为这个过程,这位小伙被全面激活,也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!

    所以充分发挥好每个人员的特点,让人能够在自己感兴趣的工作中,效果会很多。减少指派方式的任务的分配,充分发挥个人的主动性,这个团队精神面貌也会好很多。

    4、管理者不要离团队太远

    作为团队的Leader要参与到团队的工作中去,比如一个开发主管一定要写写代码,参与架构等对项目有关的事情,而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。

    特别是有些开发主管在带队后离团队越来越远,有时对于开发进度不如意时就说:“这么个简单功能怎么会搞了这么久?”,其实每天都在加班的同事心里想着:“有本事你来?”,即使这个小组长有这个能力,但对于团队来说也不是一件好事,因为大家都抱有怨恨之心,还谈什么好好工作呢?这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因,并且自己要加入到解决问题的工作中去,而不是在边上抱怨别人。

    5、小组织不要搞太多的官

    中国几千年的文化,官本位一直影响着我们,大家都想坐在那指挥,自己啥事也不用干,想想都惬意。在我们这个行业是不是发现也很类似?大家都想着干几年当个小组长,然后升个部门经理,当上CTO迎娶白富美。

    团队的管理基本是事与人的管理,非常的伤脑和心。如果一个组织内,特别是小组织内“官”太多,协调就会非常的难,大家就会经常性的扯皮。

    结束

    与敏捷开发结缘也有几年,从开始的抵触到后面的认可经历了许多,这个过程并不是一蹴而就的,需要花时间花精力,特别是要去实践、总结。

    还有我觉得是不能太教条,很多事情都要有怀疑的心,然后去实践总结,找到合适自己团队的方式方法。

    展开全文
  • 什么是敏捷

    2019-08-11 20:46:23
    1、什么是敏捷 敏捷是指能够让团队更加有效、工作更为高效,并且作出更好决策的一组方法和相关理念,即它是一种思维模式。 2、敏捷测试的方法 目前主要有4种:Scrum、极限编程(XP)、精益、看板 3、敏捷...

    1、什么是敏捷

    敏捷是指能够让团队更加有效、工作更为高效,并且作出更好决策的一组方法和相关理念,即它是一种思维模式。

     

    2、敏捷测试的方法

    目前主要有4种:Scrum、极限编程(XP)、精益、看板

     

    3、敏捷软件开发的12条原则

    (1)最优先要做的是尽早、持续交付有价值的软件,让客户满意

    (2)接受需求变化,即使在开发后期,敏捷过程利用变化为客户维持竞争优势

    (3)频繁的交付可工作的软件,交付周期越短越好(从数周到数月)

    (4)面对面交谈

    (5)以受激励的个体为核心构建项目

    (6)研发人员、业务人员必须在一起工作

    (7)可工作的软件是衡量进度的首要标准

    (8)倡导可持续开发

    (9)追求技术卓越和良好的设计,增强敏捷的能力

    (10)尽最大可能减少不必要工作的艺术,是敏捷的根本

    (11)最好的架构、需求和设计来自组织的团队

    (12)团队定期反思如何提升效率,并以此调整自己的行为

     

    4、Scrum

     

     

    scrum规则

    Scrum规则:

    1. 开会制定计划,会议分2部分,每一个部分限定时间为4小时。(需要提前准备优先级排序的积压工作表)
    2. 团队每天召开Scrum会议。(3个问题:干了撒?接下来做撒?遇到了什么障碍和困难?)
    3. 冲刺限定时间限制
    4. 冲刺评审会,展示可工作的软件
    5. 召开冲刺回归会议,讨论可以改进工作方式的方法。(做的不错的?有撒可改进的?)

     

    5、极限编程

     极限编程有13种实战,主要分为4大类:编程、集成、计划和团队。

    极限编程的要点:

    1. 测试先行编程,是指先编写描述产品代码行为的单元测试,然后编写产品代码以通过测试
    2. 开发团队需要有一个10分钟构建机制,也就是10分钟以为运行完毕的自动构建系统
    3. 持续集成
    4. 极限编程团队以周或季度循环的方式进行迭代,并像Scrum团队那样使用故事
    5. 丢车保帅,将次要的、优先级低的故事加入迭代周期
    6. 团队坐在一起,渗透式沟通获取项目信息
    7. 高信息量的工作空间里面工作,设置信息辐射体来自动把信息传达给附近的人。

    极限编程的价值观:

    1. 沟通:清除他人在做什么,并随时保持沟通
    2. 简化:代码简单、直接,尽量使用最简单直接的方案,避免复杂的方案
    3. 反馈:不断测试和反馈,保证产品质量
    4. 勇气:专注项目作出最佳选择
    5. 尊重:每个团队成员都是重要的、有价值的

     

    6 看板方法

    看板方法是一种流程改进方法。

    1. 看板团队的目标:最大化工作流量,即最大化工作项移出系统的速度。
    2. 看板方法的测量并管理工作流量实践意味着对工作流量进行测量并对流程进行调整,以达到最大的工作流量。
    3. 累积流量图,即工作进度面积图。(每天新增加到工作流中的数量[到达速度]、工作流中全部工作项的数量[工作存量]、每个工作项在系统中存在的平均时间[交付时间])
    4. 看板团队会把流程规则明确化

    看板方法的基础原则:

    1. 从你现在的做法开始
    2. 愿意追求增量式的、渐进的改变
    3. 再最一开始,要尊重现有的角色、职责和职位

     7.精益

     

    8.给敏捷测试工程师的一些建议

     

    转载于:https://www.cnblogs.com/wendyw/p/10006527.html

    展开全文
  • 如何将你的敏捷项目可视化

    千次阅读 2015-12-21 15:37:05
    敏捷事关“整体团队”经验。我们在一起做计划、在一起编码、在一起测试、在一起检视过去,以便团队中的每一个人都能达成一致的共识。然而,随着项目增大,团队开始迷失在大堆的用户故事里,很难让每个人都能看到相同...

    敏捷事关“整体团队”经验。我们在一起做计划、在一起编码、在一起测试、在一起检视过去,以便团队中的每一个人都能达成一致的共识。然而,随着项目增大,团队开始迷失在大堆的用户故事里,很难让每个人都能看到相同的全景图(big picture)。本文讨论了可视化全景图的各种方法。不仅可用于负责人和管理者,更可以用于每一个人。

    在理想的情况下,敏捷团队应该针对当前迭代提出清晰的计划,而后续的发布计划可以较为粗略。而事实上很多情况是,团队在当前迭代只是急于实现下一步的小创意。他们完全忽略了全景图。通常会有这样一种情况:这张图保存在一个角色的脑中,比如团队领导、业务分析师、项目经理、产品经理、甚至是ScrumMaster。这往往是由于他或她没有真正地推动自组织所导致的。这一现象在某些情况下还是可以接受的,比如一个不重要的短期项目,但在许多情况下,这会造成恶劣的后果,当团队偏离轨道时他们也什么也察觉不到,因为他们觉得所有的工作都还在正常地运转。

    商业价值

    在很多时候,我们在一些伟大想法(这可能来自于公司创办人、部门主管、顾客群或社区)的基础上去规划一些事情。在我们的现实世界中,这些想法通常不是静态的,它在不断地发生着变化。如果能够精确地看出项目进展全景图(big picture),可以使我们具备更多的洞察力,帮助我们保持正确的运转方向。

    例如:你的大老板洞察力到通过LinkedIn登录将是一个很有杀伤力的特性,它对于渗透到尚未开发的专业市场很有帮助,但是,一旦传达到产品经理那里,在种种原因影响之下信息沟通产生了畸变,而且优先级未被正确理解。用以连接的API不是现成的。你的生产环境上还有5个其他的问题,以及许多其他正当的理由,导致你没有把这项新功能安排上日程。到最后,距离发布日期还有不到一半的时间了,你们甚至还没有开始这个集成功能的开发。最好让你的老板和团队能够从一开始就知道这种差异,而不是拖到最后。

    有时候,团队迷恋在次要特性的技术问题上,投资过高而业务价值回报较低。假设,团队为了努力解决与FourSquare的集成,在前3个迭代中已经花费了一多半的精力,了解到这一点的产品经理会决定说“算了吧”,然后继续前进。

    那么,我们如何使这些信息可见呢?

    燃尽图(Burndown Chart)

    产品燃尽图是敏捷团队经典的进度可视化工具,它非常有效的描绘了团队进展的速度和生产能力。它可以基于数百个故事的故事点和状态精细地展示概要。它有自己独特的美,但只有这些可能还不够。假设你已经按时达成了目标,但却发现这是一个错误的目标!燃尽图可以判别完成的时间,但不能判别完成的内容。下面这张虚构的燃尽图(来自Mike Cohn的《敏捷估算和规划》)显示,在迭代2末端追加了一些范围,然后一切都回到了预计的轨道上。

    我们如何可视化全景图?这里有几个技巧。

    史诗故事(Epic)

    史诗故事从根本上说只是大的用户故事。凭借Mike Cohn和他《敏捷估算与规划》一书,这个术语已经被广泛采用。然而,史诗故事和类似的术语(如主题和特性)在不同的敏捷团队有着不同的应用,但无论在哪一个团队中,它们都是为用户故事进行分组的技巧。在他自己博客的一个评论中,Mike Cohn提到,最初是Kent Beck向他解释了史诗故事这个术语。这里有摘自该博客的一些定义:

    我们将一个特定的故事称为史诗故事时,并没有什么特殊的界限。它的意思只是“大的用户故事”。

    “主题”是一系列用户故事。我们可以把关于月度报表的故事分为一组,并拿条橡皮筋把它们束起来,然后称之为“主题”。

    这也意味着史诗故事与主题之间是无关的。下面的图片可以帮你更好地去理解。

    (点击图像放大)

    Mike作出一个有趣的总结,“把一个故事称为史诗故事有时能传达额外的含义”。比如说这个故事估计会很大,我们需要将它分解为一些较小的故事。

    精益人还介绍了其他术语,如MMF(最小市场特征或最小市场特征集Minimal Marketable Feature or Minimal Marketable Feature set)这是另外一种定义需求的方式。MMF通常比故事更大,于是许多人已经将它视为史诗故事了,但是它比刚才的大故事有更多具体的定义。如果你发布的东西有客户来买,功能再少了客户就不买了,这样的最少特性集就是MMF。如果它没有市场,可能是它太小了,而且不能分解出更大的故事。一个或多个MMF与最小可用产品(MVP)一起发布。因为精益企业(Lean Startup)活动的出现,最近这个词已经非常流行。

    于是我们有了史诗故事、主题和MMF。现在该怎么办?我们如何使用它们,以帮助我们获得更好的全景图?

    故事映射(Story Mapping)

    故事映射模式因Jeff Patton而流行起来,它是大量待处理故事(backlog)的可视化方式。按照Mike Cohn对史诗故事这一术语的描述,故事映射只不过是一张史诗故事地图,它们所有的子故事都在一面大墙上。主干(backbone)包含一个有序的史诗故事列表,当列出子故事时,你认为要讲述哪些故事,就像骷髅人(walking skeleton)那样在主干下排出优先级(编辑注:即,在只有骨架没有肉的状态下开始行走)。下图出自《新用户故事待办工作是一张地图(The new user story backlog is a map)》一书,由Jeff Patton写于2008年。

    如下,杰夫描述了故事映射的用法。

    当这个项目正在运行时,它成为我们冲刺或迭代计划的公示板。我们直接在示意图上识别或划分出要在下一次迭代中去构建的故事。在迭代期间我们将不只放置故事,我们采用任务墙去管理它们的开发——但这个故事示意图放在规划墙上提醒我们什么是全景图,我们已经取得了多少进展。

    故事映射的确是一个把大量待办工作组织起来的好方法。相比平白直叙地描述待办工作,它可以更好地去讲述一个故事。在同一骨干项目(如史诗故事)下把故事分组,帮助我们可以在更高的级别上沟通,效果优于在详细故事上的沟通。它也非常有助于挑选最小可用产品部件,你或许需要从各个骷髅人的一个(顶层)点堆积组成一个最小可用产品。

    然而,有时候你只需要一张单独的图片来描绘项目概要。你已经给老板展示了燃尽图,但它表达的是“什么时候”而不是“什么”。你很希望老板在大故事映射墙上花些时间,但事实很难如愿。我们该怎么做?是否还有其他选择?

    停车场图(Parking Lot Diagram)

    由Mike Griffiths写于2009年的《重新讨论停车场图——使用区域去展示成就(Parking Lot Diagrams Revisited – Using Area to Show Effort》书中,提到了一个有趣的全景图可视化技术——“相对尺寸”停车场图。

    (点击图像放大)

    红绿灯颜色代表了紧迫感,如红色意味着它已经错过了进度,而绿色意味着它可以满足最后期限的要求。因为大多数项目仍然在向最后期限进发的进程中,所以它们一直用黄色来表示。相对尺寸是原始尺寸停车场图的改进版。较大的矩形表示它有较大的估值(在故事点中)。作者指出,该图很容易理解,但在PowerPoint中很难用手工来绘制。博客还提到了一些其他想法,包括一个简单的按比例缩放的柱状图,它比较容易用Excel绘制或编码实现。

    (点击图像放大)

    树图(TreeMap)

    另一种可视化方式是通过树图(也称作热力型地图(Heatmap))可视化大型产品的待办工作。这个方式由Mike Cohn写于2008年,我觉得用它来记录大型和复杂的数据集很有意义。尽管写于几年前,Mike迈克在最近的评论中仍坚持认为,它一直是展现大型项目的最佳方法。

    “是的,我仍然认为这是可视化大型产品待办工作的最佳方法。树图已经经受住了时间的考验,比如图形化股票市场,所以在最近这段时间,对我们来说它依然是一门好的技术,我不希望它们被替代 [Mike Cohn,2012年5月11日]。”

    下面这张树图源自Eidos beta版最近的待办工作,是通过Google Chart Tools API绘制的,我所在的公司正致力于这个敏捷项目协同工具。深绿色的块表示下一步的史诗故事已取得一定进展,它们的面积与史诗故事的规模(所有故事的故事点总和)成比例。此树图告诉我们,因为已经完成了许多大型史诗故事,Eidos的beta版本差不多准备就绪了。

    (点击图像放大)

    这些图片提供给我们不错的今日快照,但它不能告诉我们关于过去和未来的任何信息,因为这里只有两个维度的数据,比如在本例中,只有史诗故事的规模和状态,但没有时间维度。

    镖靶图(Dartboard)

    下面的镖靶图,由Nicholas Muldoon在《针对产品的史诗故事(Epic)可视化》中提出,每个史诗故事图形化的“计划”由每块区域来表示。每个方块符号是一个故事。最内部的圆圈是当前版本,在它外围的4个圆圈是接下来的4个版本。圆圈外面的符号是计划外的故事。红绿灯颜色代表故事已完成的程度,从红色、黄色到最终的绿色。

    尽管该图显示了时间维度,但它并不能真实地显示出故事之间所需的相对努力。也许,以每个符号的大小去反映它相对的规模,可以很容易地将它进一步增强。

    面积堆叠图(Stacked Area Chart)

    在Eidos,我们正在研究如何去有效地可视化全景图。还有一个方法是面积堆叠图。本图不仅显示相对规模和状态,并且显示进度已经历的时间。例如,针对故事板(Storyboard)和故事卡(StoryCard)上的史诗故事,你可以看到我们从开始到现在所有的工作进展,以及我们刚刚在迭代6中提交的迭代计划和附件。

    (点击图像放大)

    带有史诗故事条的增强型燃尽图

    还有一个方法是在燃尽图下显示史诗故事进度,原始Eidos截图如下。在燃尽图下的条形图中,每个色块代表每个史诗故事的故事点总数。在其他图中,增强的燃尽图还能显示每个史诗故事“还剩哪些”没有实现。

    (点击图像放大)

    总结

    所有这些可视化方法都在努力解决同样的问题,比如在时间、规模和需求组等不同维度概括大型、复杂的数据集。更为复杂的数据与可视化,你就需要去更加自动化地表达全景图。

    让我们再来回顾一下所有已讨论过的可视化。关键的不同在于维度和打算要可视化显示的内容。很明显,如果采用了仅显示某时间点的截图(如树图),就无法显示各时间段上的数据(如燃尽图)。

    可视化

    时间

    范围与状态分类

    赞成意见

    反对意见

    可编程绘制

    (发布) 燃尽图(Burndown)

    时间序列

    发布层

    直观,易于手绘

    没有衰变数据

    困难

    故事映射

    (Story Mapping)

    截图

    故事层

    直观,易于手绘

    待办工作太多时难以维护

    非常困难(主要通过往墙上贴便笺来完成)

    停车场图

    (Parking Lot)

    截图

    史诗故事级(Epic Level)

    直观

    创作较费时

    非常困难

    刻度条图

    (Scaled Bar Chart)

    截图

    史诗故事级(Epic Level)

    直观

    创作较费时

    容易

    树图(Treemap)

    截图

    史诗故事级(Epic Level)

    更全面地显示全部范围和状态

    不直观

    中等

    镖靶图

    (Dartboard)

    截图

    史诗故事级(Epic Level)

    占用空间小

    不适用于太多的待办工作

    困难

    面积堆叠图(Stacked Area Chart)

    时间序列

    史诗故事级(Epic Level)

    同时记录时间序列与衰变

    不直观并有些杂乱

    中等

    燃尽图+史诗故事条

    (Burndown + Epic Bar)

    时间序列

    史诗故事级(Epic Level)

    直观

    有点杂乱

    困难


    展开全文
  • 1. 敏捷项目vs传统瀑布项目的最大不同  快速交付,分拆交付,快速迭代,拥抱变化! 迭代故事点示意:    不断增长的已完成story point时,谁敢拍胸脯说以前的功能百分比不出问题?谁又去承担这快节奏的...

    1.  敏捷项目vs传统瀑布项目的最大不同

     快速交付,分拆交付,快速迭代,拥抱变化!

    迭代故事点示意图:

     

     不断增长的已完成story point时,谁敢拍胸脯说以前的功能百分比不出问题?谁又去承担这快节奏的回归测试的压力?

    此时,自动化测试就成为重要的备选解决方案之一。

      2 自动化测试对于敏捷项目的必要性

      

    持续交付的需求 流线化测试流程使其更快以适应敏捷

       代码的持续集成是基础,而自动化测试则是保障持续交付的重要步骤。

      以装修铺地板砖为例,房间那么大肯定不是用一块整砖铺上去,每个房间面积不同工厂也不可能批量生产定制化的地砖,所以采用一块块的地砖(story)铺上去。这就是持续集成。铺的过程中还可能根据情况进行切割(变化)。为了检验是否铺的合格,工人不是铺完后再进行检测,一般每铺完一块就通过各种工具进行(测试),如果有问题(缺陷)就及时调整(fix defect)。这就形成了持续交付。当铺完最后一块地砖,这个工程步骤也随之宣告结束。

      在测试环境部署完成进行测试时,敏捷项目对时间的苛求,快速测试、快速报告(例如自动化测试结果自动push到用例管理工具中)、持续部署对结果自动化的要求,都意味着离开统一的工具和自动化无法达成。

      3.3 在敏捷环境中执行自动化测试的挑战及对策

      不仅仅是敏捷开发的方法学引入到软件开发中,QA在项目中的角色也随之改变。既然是敏捷,那么不再是一群QA坐在角落里,等着开发团队交付功能进行测试。敏捷项目的自动化QA不仅要熟识传统自动化测试项目的知识,更要对敏捷开发方法学和流程有很好的了解。知晓敏捷测试的挑战,有助于自动化测试人员有针对性的制订措施予以克服或缓解。下面进列出一些主要的挑战及其对策。

      3.3.1 不断/最后一分钟仍在改变的需求

      敏捷项目中需求变更是一个永恒的话题。当sprint进行一半时需求的改变甚至被砍掉,是整个团队包括开发和测试团队的梦魇,而不断重复则会完全摧毁整个项目的成功交付。作为项目经理整体把控,建立变更控制的流程,通过相应的方法和工具来管理监控变更。

      具体到自动化测试项目中,通常可采用下面的办法很好的管理变更。

      1)把控backlog/test case(测试用例)完整度

      所谓backlog完整度,是指供自动化的测试用例细节不明确、后续各种变化多等情况。

      很多时候这项被忽略,往往拿到用例就开工,当自动化测试在敏捷项目中失败时回过头做教训总结时,很意外归结到此项的比例特别的高。

      在开始编码前增加业务梳理的环节,最好由专人负责,确保自动化测试人员开始编码/学习业务的时候拿到的是相对完整的场景用例。

      需要注意大多自动化测试的backlog来自于手工的测试用例,但供手工测试的用例有时一些描述是比较模糊的,在自动化前需要予以明确清晰的定义。

      粗陋的backlog,退回或延迟自动化!!

      2)自动化开发过程中严控变化

      一旦BA业务梳理结束开发启动,这时需要尽量的控制变化,尽快的根据当前版本的backlog完成脚本的开发。如果发生变化,交由维护阶段进行。

      这里说的严控变化,不能理解为说脚本开发过程中完全不能有变化,小的不影响进度的变化可以脚本开发人员酌情安排修改(需要上报lead/PM知晓),特别大的backlog的变化应停止脚本开发,退回BA重新进行业务梳理,而不是一味根据原有版本的用例完成。

      3)保持相对唯一/独立的产品环境

      唯一是指脚本开发过程中的产品环境版本不变。例如保持2周一升级。这样不仅有利于开发,还能保证交付的脚本验收是在同一个环境下;

      独立是指开发基于的产品环境和产品实际集成环境彼此独立分离,互不影响。这样不仅保证功能的不变,还能避免不同数据带来的风险。

      注意:持续交付讲究的是类产品(production-like)环境下进行交付,这里的方法与其不冲突。只是针对脚本开发阶段,脚本交付使用后仍然处于类产品环境下运行是最佳的。

      4)选择适合项目情况的代码管理

      多人协同开发环境下,代码管理就尤为重要。

      下图举了一个基于Git的分支管理的简单示例,

      Fork仓库的应用也有很多很好的实践。

      5)主动管理变化,尽量使变化有计划的集中发生

      除前述外,如果预期自动化基于的测试用例有频繁变化,可以采取分离/克隆用例库的方法,根据项目安排同步最新的用例。

      关于分离/克隆用例库:自动化测试基于的测试用例不一定是最新的测试用例,可以分别置放于不同的位置(suite/folder/DB),定期或者有计划的进行同步(利用测试用例管理工具的自动同步功能)。

      6)采取方便后期维护的方式控制变更

      不要hard coding (Step Reporting, Assertions, etc),数据驱动,测试数据和脚本step分离,采用适用的数据管理方式以方便后期更改和维护,例如CSV/XML/JSON/TXT文件、枚举类class文件等等。

      针对数据驱动的应用本身有很多关于利弊与方法的讨论,此处不详述,重点强调的是no hard coding并采用适合自己项目维护的方式。

      7)(UI自动化)采用最佳实践进行元素定位

      元素定位在自动化测试中是非常重要的部分,也是非常容易在软件开发过程中变化的部分,应尽可能的规避潜在变化。

      定位方式优先级别(常规,有例外的情况):

      自定义的字段 (例如Automation ID) > CSS > X-path

      如果ID和CSS能定位到,尽量避免使用X-path方式定位。

      3.3.2 User Story(用户故事)中缺乏足够的细节信息

      有时产品/项目经理建的story中只有一些关于new feature (新功能) 的大致描述缺乏细节行为动作和功能合格准则,然后要求开发根据这些概念进行原型开发。

      解决方案:

    与产品经理/负责人协作来完善story的细节和接收准则。

      与自己任务息息相关的事情需要最大程度的参与。在中大型的自动化测试团队中,这项任务往往会分拆出专门的角色由BA进行。

    • 确保所有相关干系人对于story的描述和接收准则清楚明了,在开发之前。

      特别强调在开发之前,做正确的事情高于正确的做事。自动化测试大多很依赖开发完成的产品/功能,如果开发有问题,会导致测试不可信/采纳。

    • 否则,拒绝自动化测试,进行high-level场景的手工测试。

      自动化测试是非常精准的测试类型,用于替代手工测试和回归测试,目前的自动化测试手段大多做不到那么人工智能。

      3.3.3 Continuous Testing持续测试

    对于敏捷而言,测试不是一个阶段而是一项项目活动。因为周期短,开发/产品经理更期望尽早的得到对于功能完整度的反馈。实时/及时的质量反馈是持续测试的目的。而对于测试人员来说,关注点不仅仅是新开发功能的正确程度,也包括对不破坏既有功能的确认。

      解决方案:

    敏捷中测试与开发并行进行,越早看到接近最终交付成果的产品越有利于帮助测试人员理解和验证脚本的正确性。

    • “盲写”自动化脚本

      参考产品原型图或需求文档先行进行脚本开发,并优先进行page/API object的开发,然后再进行case层级的组装,不管是UI还是API的测试。笔者所处的项目也有工期特别紧张的时期,自动化测试脚本开发时往往产品功能未就位,就利用“盲写”进行快速跟进。“盲写”必然伴随着一些临时的hard code或者伪代码,这时添加comment (注释)就尤为重要,以提醒后期维护时进行替换。

      “盲写”最后的校验环节比较重要,需要等功能完成后再进行校验调试,特别注意真实数据的替换、case步骤的最终顺序是否调整、clean-up、元素定位等等。

      3.3.4 选择适合的自动化工具 

    因为敏捷项目的变更非常多,传统录制回放类的自动化工具显然不适合,需要采用更为灵活的工具,这也是Selenium等UI自动化测试工具近几年大加流行的原因之一。

    再例如SoapUI,这是一个优秀的轻量级的API测试工具,其Pro版也可以进行一些性能安全的测试。对于脚本开发人员的语言能力要求比较低,容易上手。

      3.4 自动化测试在敏捷项目中的应用

      3.4.1 什么项目适合做

    • 公司/软件类型

      互联网、游戏等这种实际上大多都是拿用户做β测试的公司,遇到重大问题一般都需要在小时为单位的严格限制中进行解决。总不能慢慢的等着手工测试结果,或者不管不顾解决3个小问题冒出1个大问题来。

    • 大型长期的软件产品

      例如美国的人力管理软件公司Kronos、国内的财务软件公司用友等等,一个软件客户用10年,对外发布大版本的开发周期有的也是长达数年,大部分功能相对固定,大量沉积的丰富的API库。

     

     

     

      对于敏捷项目,无非是在每个sprint里计划开发不同feature的脚本并进行执行。每个迭代的自动化测试执行可以囊括所有已开发完成的脚本。

    4、延伸:DevOps不可或缺的测试自动化

      4.1 关于DevOps

      DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发dev 应用程序/软件工程)、技术运营Operation 和质量保障QA部门之间的沟通、协作与整合。

    DevOps可以实现持续部署,以解决持续提高的部署频率的需求。

      4.2 DevOps实践模型

     

     

     

      4.3 自动化测试in DevOps

      DevOps作为敏捷开发项目的一种过程,快速的产品发布必然需要加强自动化测试的覆盖率、最大可能缩短开发周期、减小维护时间,传统的手工测试基本无法跟上高速产品发布的节奏。

      这时,单纯将自动化代码放入CI中已不能满足要求,同时需要做到

     

    • 产品功能点与测试用例科学对应(最小化原则)

    • 测试用例彼此独立且容易复用(子用例)

    • 产品代码/API与测试代码紧密关联结合

      某些产品变化,无需修改自动化代码。例如用产品API进行数据初始化,当相关的UI变动时,并不会对自动化脚本造成影响。

    • 测试整体自动化

      测试自动化,不仅仅是进行自动化测试,更包括自动化代码的持续集成编译、自动部署、自动执行、自动化报告、自动搜集抓取相关log及异常等。

    • 同开发团队达成一致,将自动化测试的结果作为将开发环节推进到测试环节的准入标准。

    本文摘取自51testing微信公众号,结合自己工作对在捷开发中如何做自动化测试进行学习和总结

     

    展开全文
  • 项目进度跟踪的最佳实践:每日站立会议1 每日站立会议的具体做法每日站立会议是Scrum方法中的一条关键实践,看似很简单的一个活动,其实内涵丰富,站立会议通过每天面对面的沟通,可以: (1)快速同步进展,让项目...
  • amp;wfr=spider&for=pc转载自科技夜谭本人专注于敏捷开发实践,在IT软件...目前,是美国敏捷联盟认证的敏捷教练(CSM),致力于推动国内的敏捷实践与宣传。累积流(CFD: Cumulative Flow Diagram)是看板方...
  • scrum经典管理工具:白板和即时贴

    千次阅读 2013-03-14 09:19:21
    见下一:任务看板: 分为三列,todo表示为开始,doing为正在进行中,done表示已完成。团队的成员每天将自己负责的任务移动到相应的栏中,并且更新其剩余时间。 二、燃尽: ...
  • 这份最佳实践将帮助你掌握 CODING 敏捷管理工具,更好地实践敏捷开发流程。 点击原文链接,更多实践案例持续更新中。 什么是敏捷研发 敏捷研发是涉及整个软件工程的理念与实践,它的核心是迭代和增量式软件开发...
  • 由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码,所以在完成当前迭代新增特性测试工作的同时,还要通过回归测试来保证历史功能不受影响。为此我们期望:  测试范围足够广:  1、测试用例要覆盖...
  • 让每个人学会更好的沟通软件项目活动的主体是人,项目计划的执行过程中从开始到结束,始终都贯穿着频繁的沟通...Robert Cecil Martin在他的《敏捷软件开发》一书中曾经清晰的描述了沟通为什么总是那么费劲。作者在书中
  • 敏捷自动化测试

    2015-09-29 16:07:52
    由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码,所以在完成当前迭代新增特性测试工作的同时,还要通过回归测试来保证历史功能不受影响。为此我们期望: 测试范围足够广: 1、测试用例要覆盖所有...
  • 生活处处有敏捷

    千次阅读 2010-01-26 10:33:00
    近来工作忙碌,虽未提笔,但心中一直惦念不忘仔细斟酌如何才能将本书作者对于敏捷的理解和著述浓缩成文,写出一篇精彩的序而不负期望。 本书写得有生趣。大概是有很多共通之处吧,所以读主人公的故事就回忆起了许多...
  • 产品&研发&测试在敏捷各环节的职责

    千次阅读 2019-04-10 18:38:46
    RD:开发 FE:前端开发 QA:测试 TTL:tech team leader 产品负责人、研发负责人、测试负责人 规范|角色 PM(含UE) RD(含FE) QA 备注 迭代、项目...
  • 你好,欢迎使用 CODING!这份最佳实践将帮助你掌握 CODING 敏捷管理工具,更好地实践敏捷开发流程。 什么是敏捷研发 敏捷研发是涉及整个软件工程的理念与实践,它的核心是迭代和增量式软件开发方法。开...
  • 看板方法本身并不是一种软件开发流程或者项目管理方法。使用看板方法之前,你必须已经具备某种流程或方法,而看板方法的作用就在于逐渐改变你已有的流程或方法。——David Anderson《看板方法》 Scrum主要关注的是...
  • 项目全景是如何可视化的?

    千次阅读 2014-03-28 14:26:17
    敏捷事关“整体团队”经验。我们在一起做计划、在一起编码、在一起测试、在一起检视过去,以便团队中的每一个人都能达成一致的共识。然而,随着项目增大,团队开始迷失在大堆的用户故事里,很难让每个人都能看到相同...
  • 第8章 精益、消除浪费和着眼全局 精益是一种思维方式,是一种世界观。 ——Mary Poppendieck,Tom Poppendieck,The Lean Mindset: ...对极限编程也是一样:如果你不断重构,使用测试驱动开发,持续集成并且进行...
1 2 3 4 5 ... 18
收藏数 351
精华内容 140
关键字:

敏捷开发进度面积图