• 我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.1 任务板任务是分解到手头的... 2 需求特性板需求特性是软件大的功能需求,通常按照月份来进行归类.3 敏捷开发需要把软件设计分成三个部分: 特性->用

    我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.

    1 任务板

    任务是分解到手头的实际的工作

    把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

    可以画一些横的泳道来表明任务应该是谁来完成.

     

    2 需求特性板

    需求特性是软件大的功能需求,通常按照月份来进行归类.

    3 敏捷开发需要把软件设计分成三个部分: 特性->用例->任务

    特性: 对最终用户有意义的一个功能
    用例:由特性分解而来的一个可以用来做功能测试的小情节
    任务:用例分解而来,有开发人员需要完成的一个最小的工作单元

    4 敏捷过程中,时间分为: 发布->迭代->每日

    发布:通常一到六个月
    迭代:通常一到四周
    每天:

    5 我们把工作和时间对应起来,就是这样

    在每一个发布过程中,我们完成需求.
    在每一个迭代周期中,我们实现案例
    每一天,我们都要完成多个任务

    6 更形象一点,我们把他们都结合起来:

    你要准备三块黑板:

    需求特性黑板:每一列标识一个发布需要完成的特性
    案例黑板:每一列标识每一个迭代周期需要完成测试的案例
    任务黑板:每一天要做的任务

     
    展开全文
  • <iframe align="top" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog01.html" frameborder="0" width="...
    <iframe align="top" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog01.html" frameborder="0" width="728" scrolling="no" height="90"></iframe>

    原文地址:http://www.infoq.com/articles/agile-kanban-boards

    我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.

    1 任务板

    任务是分解到手头的实际的工作

    把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

    可以画一些横的泳道来表明任务应该是谁来完成.

    2 需求特性板

    需求特性是软件大的功能需求,通常按照月份来进行归类.

    3 敏捷开发需要把软件设计分成三个部分: 特性->用例->任务

    特性: 对最终用户有意义的一个功能
    用例:由特性分解而来的一个可以用来做功能测试的小情节
    任务:用例分解而来,有开发人员需要完成的一个最小的工作单元

    4 敏捷过程中,时间分为: 发布->迭代->每日

    发布:通常一到六个月
    迭代:通常一到四周
    每天:

    5 我们把工作和时间对应起来,就是这样

    在每一个发布过程中,我们完成需求.
    在每一个迭代周期中,我们实现案例
    每一天,我们都要完成多个任务

    6 更形象一点,我们把他们都结合起来:

    你要准备三块黑板:

    需求特性黑板:每一列标识一个发布需要完成的特性
    案例黑板:每一列标识每一个迭代周期需要完成测试的案例
    任务黑板:每一天要做的任务



    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1763113


    展开全文
  • scrum最传统,也是最直观的管理工具就是白板和即时贴。一个团队通过一个白板和即时贴来完成对scrum中story和task的跟踪管理。见下图: 图一:任务看板: 分为三列,todo表示为开始,doing为正在进行中,done...

    scrum最传统,也是最直观的管理工具就是白板和即时贴。一个团队通过一个白板和即时贴来完成对scrum中story和task的跟踪管理。见下图:

    图一:任务看板:

    分为三列,todo表示为开始,doing为正在进行中,done表示已完成。团队的成员每天将自己负责的任务移动到相应的栏中,并且更新其剩余时间。



    图二、燃尽图:

    团队成员每天负责将所有任务剩余时间累加,然后绘制在图表上面,形成燃尽图。这里面有两条线,蓝色的表示计划中的燃尽图走向,红色的则是实际绘制出来的图。从这个图里面可以看出,最开始任务消耗比较慢,说明任务可能遇到了难关,暂时没有解决方案。到了第六天,燃尽图有一个明显的下行,可能是任务得到了解决,发现不需要原来那么多的时间。也有可能是任务取消。



    图三、scrum总结会议

    srpint结束之后,团队成员坐在一起,总结本期所取得的成绩,需要改进的地方。



    白板和即时贴的优点

    1. 直观。通过一个白板,团队的成员可以非常直观的了解到项目的进展。
    2. 操作比较方便。只需要一个白板,几包即时贴,白板笔即可。
    3. 趣味性较好。

    白板和即时贴的缺点:

    1. 历史记录无法保存。
    2. 受白板和即时贴面积的限制,无法容纳更多的信息。
    3. 容易受物理因素的影响,比如风的影响,或者即时贴不干胶失效。
    4. 只能是坐在一个屋子里面的团队使用,跨地域的团队无法共享信息。


    转自另一个转载的网站,原文出处未知

    展开全文
  • 落地敏捷典型问题:固定的白板,失败的起点 在Scrum的模式中,白板被用来发现风险、团队协作、透明化等,确实是一种简单实用的手段,很多团队在使用白板后获得了直接的效果。但是,白板的使用过程中经常会出现...

    落地敏捷典型问题:固定的白板,失败的起点

    在Scrum的模式中,白板被用来发现风险、团队协作、透明化等,确实是一种简单实用的手段,很多团队在使用白板后获得了直接的效果。但是,白板的使用过程中经常会出现以下问题,例如:

     

    1)      一种固定模式的白板,对应一种固定模式的协作方式,但是在不同的实际场景中行不通

    2)      白板上的关键信息不做持续记录和更新,失去存在的意义

    3)      白板只是被研发团队的成员在使用

    4)      没有分析流程中的瓶颈、浪费、问题,无助于改进的白板作用就褪色很多

     

     

    这里重点想讨论和分享我们如何解决第一种问题。解决方案就是不同的场景,用不用的协作方式,对应的白板也会随之不同。我们实际工作中有很多场景,举例如下:

    #1:固定迭代周期交付,迭代周期内需求无变化

    #2:固定迭代周期交付,迭代周期内有一些新增变化

    #3:固定迭代周期交付,迭代周期内有很多新增变化,或者团队内部是强分工

    #4:无固定迭代周期交付,即按需交付,可能是有固定周期(例如一周一次),也可能没有固定周期

    #5:固定迭代周期交付,同时迭代周期内需要临时按需交付

    #6:资源紧张,每个人同时负责多个任务,不清晰的协作导致无法快速交付重要的功能,混乱无序

    #7:多团队协作,但团队之间或者和第三方的依赖非常强

     

     

    这里重点介绍#1、#2、#4场景的具体白板。

     

     

    对于#1的场景,我们用的是Scrum标准白板,加入了我们的具体实践,白板如下:

     

     

     

     

     

    对 于#2的场景,我们用的是ScrumBan类型的白板,即借鉴了Scrum的要素,并结合Kanban的要素。由于只是一些新增变化,所以在迭代开始时还 是会进行迭代计划会议。#2的白板如下。但是对于#3,在迭代开始时没有统一的计划会议,对于要进行的需求进行即时计划。

     

     

     

     

    对于#4,我们用的是比较标准的Kanban,加入了我们的具体实践,白板如下:

    我们用过两类Kanban,一种类似这样的:

     

     

     

     

    另一种把需要协作的点都放在了白板上,并增加了适当的细节,以便于更快更准确的发现风险,消除瓶颈和障碍,类似如下的样子:

     

     

    需要说明的是,如果团队较为成熟,磨合时间长,效率高,第一种Kanban为推荐,甚至可以更为简单;如果团队磨合时间短,交付出现的问题较多,第二种Kanban为推荐,即展示更多的细节。

     

     

    展开全文
  • 敏捷开发,贵在敏捷,如何敏捷?我们需要一系列成熟的工具去帮助我们敏捷。 这篇文档不写技术,就是纯粹地说工具,介绍我们实施scrum过程中,起到关键作用的工具。 1、Jira或物理看板 Jira配合JIRA Agile...

    做敏捷开发,贵在敏捷,如何敏捷?我们需要一系列成熟的工具去帮助我们敏捷。

    这篇文档不写技术,就是纯粹地说工具,介绍我们实施scrum过程中,起到关键作用的工具。


    1、Jira或物理看板

    Jira配合JIRA Agile插件,即可实施敏捷开发,核心就是提供了一个电子看板,再配合上可自定义的工作流



    如果不喜欢对着冷冰冰的电脑,我们完全可以采用最原始的方式,准备一块白板,相信互动和交流都变得“生动”和“开放”起来。


    不想再去取材了,直接引用网友的图片:http://pmohome.blog.163.com/blog/static/1946610792012630102610284/

    2、confluence

    进行敏捷开发怎么能少了Confluence,它一个专业的wiki程序。它是一个知识管理的工具,通过它可以实现团队成员之间的协作和知识共享。

    想想维基百科,你就知道confluence的便利之处。



    3、jenkins

    持续集成倡导团队开发成员必须经常集成他们的工作,甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证,包括自动编译、发布和测试,从而尽快地发现集成错误,让团队能够更快的开发内聚的软件。

    没错,jenkins就是帮助我们完成持续构建和集成的。



    4、maven和nexus
    Maven是一个采用纯Java编写的开 源项目管理工具。Maven采用了一种被称之为project object model (POM)概念来管理项目,所有的项目配置信息都被定义在一个叫做POM.xml的文件中,通过该文件,Maven可以管理项目的整个声明周期,包括编 译,构建,测试,发布,报告等等。目前Apache下绝大多数项目都已经采用Maven进行管理。而Maven本身还支持多种插件,可以方便更灵活的控制 项目。

    所以,怎么能少了maven呢!既然maven用上了,nexus还会远吗?

    上网copy一段介绍吧。

    Nexus 是Maven仓库管理器,如果你使用Maven,你可以从Maven中央仓库 下载所需要的构件(artifact),但这通常不是一个好的做法,你应该在本地架设一个Maven仓库服务器,在代理远程仓库的同时维护本地仓库,以节省带宽和时间,Nexus就可以满足这样的需要。此外,他还提供了强大的仓库管理功能,构件搜索功能,它基于REST,友好的UI是一个extjs的REST客户端,它占用较少的内存,基于简单文件系统而非数据库。这些优点使其日趋成为最流行的Maven仓库管理器。



    5、checkstyle

    不要总是在你的员工面前一遍又一遍地喊:要遵循代码规范!直接使用checkstyle检查一下,然后利用eclipse自动format就搞定了。
    如果连手动检查都懒得做,那就交给jenkins吧。

    6、findbug
       
    静态分析工具承诺无需开发人员费劲就能找出代码中已有的缺陷。当然,如果有多年的编写经验,就会知道这些承诺并不是一定能兑现。它会发现一些伪问题,但这并不能掩盖它的贡献。FindBugs 检查类或者 JAR 文件,将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具,就可以在不实际运行程序的情况对软件进行分析。

    不需要手动做,交给jenkins吧


    7、javamelody

    JavaMelody能够在QA和实际运行生产环境监测Java或Java EE应用程序服务器。并以图表的形式显示:Java内存和Java CPU使用情况,用户Session数量,JDBC连接数,和http请求、sql请求、jsp页面与业务接口方法(EJB3、Spring、Guice)的执行数量,平均执行时间,错误百分比等。图表可以按天,周,月,年或自定义时间段查看。 

    看了上面简介,你就知道我为什么推荐你使用它了吧。


    好东西,还有很多,慢慢来,站在巨人的肩膀上,这句话可不是白说的。




    展开全文
  • 敏捷性是以微小增量的方式构建软件,那么我们该如何设计软件呢?在敏捷团队中,全局视图和软件一起演化。每次迭代,团队都改进系统设计...在《敏捷软件开发:原则、模式和实践》一书中提出几种设计原则: 单一职责原
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • hursing所在的公司推行敏捷开发有两年多了,其中最让人直接感受到的就是scrum晨会。从生搬硬套到过程创新,令大家由抵触变成积极响应,这个过程真的很花费心思。 09年12月,hursing开始在自己的团队推行晨会。当时...
1 2 3 4 5 ... 20
收藏数 3,217
精华内容 1,286