2019-03-20 11:29:36 weixin_39835036 阅读数 16
  • SCRUM敏捷开发视频教程

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

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

在敏捷开发中有很多好的想法和实践,这些想法和实践都非常管用:把项目分成小版本发布来进行风险管理和加速回馈;用时间盒(time-boxing)来限制WIP(Working In Process)并让所有人团结一致集中在项目中;仅依靠软件来作为进程度量;进行简单的估算并使用速度来预测团队的表现;和客户保持频繁而紧密的合作;持续集成持续发布以保证代码始终稳定可运行。

但是还有一些别的并不是那么重要但被很多人接受的想法和实践:就算你不遵守这些想法和实践你的项目依然可以圆满成功,也不会有糟糕的事情发生。但是有一些想法实践你最好不要去遵守。

测试驱动开发

做快速开发的团队需要依赖于一个快速高效测试安全网。在一个测试先行的或者是测试驱动(TDD)的敏捷开发中,没有任何借口可以不写测试用例。在你开始编码前你必须先写好测试用例,然后你就可以采用一些高效的自动测试工具来保证有一个高水平的覆盖测试和回归测试。

TDD不仅仅是一种供开发人员测试他们代码的保证手段,它更重要的一种开发技术,这种开发技术能够得到更高质量的代码和一个简单整洁的设计。

微软和IBM(通过测试驱动开发实现质量改进,微软研究院,2008)的研究团队发现,虽然TDD增加了15%-35%前期成本(TDD要求开发人员改变他们的想法和工作方式,这减缓了他们的的开发速度,至少在一开始他们的开发速度慢了很多),但是跟没有采取单元测试的团队相比缺陷密度降低了40%(IBM)或多达60%-90%(微软)。

但是由Burak Turhan主导的研究表明虽然TDD表面上提高了质量(根据一个或多个通过的测试用例,缺陷的数量,缺陷密度,每次测试发现缺陷数,修复缺陷的工作量,修复密度,预防性维护比例等本衡量)并且可以提高测试的质量(可以使测试错误降低,使测试变得更加容易),但TDD并不能一直提高设计质量。

TDD似乎可以降低代码的复杂度,提高代码的重用率,但是它也能给耦合内聚带来负面的影响。虽然使用测试驱动的开发可以使得方法级和类级的复杂度降低,但包级和项目级却为之变得更加复杂。

喜欢TDD的人为之疯狂,如果你也热衷于TDD,那就尽管用它吧。就算你对TDD并不那么感冒,测试先行非常自然的场景也是时不时出现——尤其是当你不得不通过一种特殊的方式来解决一个特殊的问题,或者你要修正一个bug而测试用例已经为你写好的时候。但是更重要的是,你要写一组很好的测试用例不断更新并且时不时运行它们,这跟你在写代码前还写写好代码后没有关系。

结对编程

根据VersionOne State of Agile Development Survey 2012(敏捷开发调查状况2012),几乎有1/3的团队采用了结对编程的开发方式——这是一个出乎意料的高数字,这显示出结对编程的良好的组织纪律性,同时表明有很多的团队使用了可以进行结对编程的XP(2%)和Scrum/XP(11%)方法。

有采用结对编程的非常好的理由:开发人员一起工作可以通过持续的非正式的审查来提高代码质量和进行信息共享。让开发人员结对或者让开发人员和测试人员结对来一起工作的情况非常常见,尤其是当你在解决一个非常困难的设计问题,或者你碰到一段以前从来都没有接触过的代码而以前开发过类似代码的人就在旁边可以请教,或者你碰到了一个高压力的问题需要解决为此你豪无头绪,或者你在测试系统的一个非常难的部分,或者你的团队又加入了新的成员而这些成员需要基础学习的时候。

一些(尤其是性格外向的)人非常喜欢结对编程,喜欢它提供的非常强大的能量和非常难得的认识团队其他成员的机会。但是去强迫那些更喜欢自己单独工作的人去和自己不喜欢的人进行紧密的合作,这显然不是什么明智的作法。结对编程要花费社交成本:和一些有能力的,技术强的,有工作经验的,有自己独特方式的,有自己鲜明个性的或者是有自己职业道德的人一起结对编程你需要非常小心。而且长时间的结对编程让人精疲力竭——一项研究(Vanhanen and Lassenius 2007)发现人们通常一天只结对编程1.5至4个小时,因为成天的结对编程工作强度太大以致于无法接受。

在结对《编程或许是有害的》一文中,Jon Evans说结对编程对创造力有负面影响:

研究强烈支持这个观点:当在享受更多的不被打扰的自由和隐私空间时,人们才有最好的创意......区别表现突出的大公司的开发人员的并不是更丰厚的工作经验和更高的薪酬,而是他们可以享受的不被打扰的自由的私人空间。”一篇纽约时报的文章大骂结对编程这种所谓“新的集体思维”时这样说。

另外在Pete McBreen的“依然质疑极限编程”中指出了一些结对编程的其他缺点和弱点:

不鼓励钻研思路,结对编程时开发专注编写代码,所以除非有一天的时间来钻研团队代码才能对代码有一点肤浅的理解。

开发变得过度依赖单元测试,假如测试通过了,那么代码就OK了。(这就缺乏钻研了)

没有进行详细的极端测试和边缘测试研究,特别是如果他们很难写出测试。

当结对编程时很难做到经过详细思考设计的编码,除非另外一个搭档完全控制这个编码过程。通过平时搭档间的权衡,很难建立技术复杂的设计,除非他们已经确定了一个独自会话。

结对编程时的个人风格问题,并不是所有的结对者都能像其他人一样。

和打字技能、熟练程度不同的人结对编程,往往会导致打字技能好的人完成全部的编码而其他人变得完全被动。

在分布式团队中结对编程显然也不会有效(取决于距离,不同的时区,工作方式,语言),即使这样,一些人仍然在尝试。

虽然结对编程相比独自编程提高了代码质量,你也可以通过较低代价的代码复审来获得同样的代码质量提高,并且还有一些信息共享的优势。代码复审——特别轻便,离线复审——比结对编程更容易安排,代价更低点并且没有打扰。就像詹森科恩指出的那样 即使开发们结对编程,你或许仍然需要代码复审, 因为结对编程确实是共同解决问题,但是它并没有包含所有代码复审所涉及的全部问题。

还是乔恩埃文斯关于结对编程的老话:

真正的答案是有没有答案:独自编程,结对编程还是小组合作要根据环境用你最好的判断来动态结合才是最有效的。 结对编程的确有它存在的意义。(定律又没用了!)在某些情况下,甚至是“绝对对的”。但是坚持100%结对编程是盲目的教条主义,和所有的盲目教条主义一样,最终只会适得其反。

紧急设计和隐喻

增量开发管用,而且尝试保持设计简单感觉起来不错,但试图飞速定义一个架构是愚蠢且不切实际的。几乎没有人遵循紧急设计有一个原因:它不管用。

依赖于高水平的隐喻 (系统是一条 "流水线"或 一个"物料清单"或 一箱"蜂箱的蜜蜂") ,这些隐喻被团队共享为某种 代替建筑 是更加荒谬的。 卡内基梅隆大学基金会 的研究显示,自然语言的隐喻,无论对技术和非技术项目成员之间增进沟通,还是在开发架构方面,相对来说都不是很有用。

总之几乎无人理解系统隐喻是什么 ,或者它怎样使用,或者怎样选择一个有意义的隐喻,或者如果你搞错了又怎样改变它(还有你怎么会知道你选错了),其中有人提出了这样的想法:

好吧我还是不妨公开说出来 —— 我仍然不能找到这种隐喻事情的窍门。我发现它管用,而且在C3项目中工作的很好,但这并不意味着我知道怎么做,更不要说如何解释怎样做到了。

Martin Fowler, 设计灭亡了吗?

敏捷开发方法促进了开发的成功率,并且展现出处理许多不同软件开发问题的更好方法——但不是架构和设计。

每日站立会议

当你有了一支新的团队,而每个人都需要相互了解,并且需要更多的时间理解项目是关于什么的;或者当这个团队迫于超级压力,正在试图修复些什么或者结束些什么的紧急的状况,那么将大家聚集起来开工作例会,甚至也许一天超过一次,这是必要的且有价值的。但是每个人是站还是坐,最终他们在会议上讨论些什么,将由你决定。

如果你的团队已经合作一段时间也合作的很好,而他们每个人都互相了解并且知道他们在做的是什么,如果开发人员做完事情的时候,在任务板或看板上更新卡片,或者在一个电子系统里更新状态,如果他们足够成熟可以在需要的时候请求帮助,那么你不需要每个早上在房间里让他们都站着。

集中式代码所有权

让每个人的工作都涉及到所有代码并不总是有效(因为不是团队中的每个人对每个问题都有必备的知识或者经验),并且集中式代码所有权对代码质量有负面影响。

共享代码看起来似乎更有意义,但事实上却是不是每个人或者是应该为系统的每一部分工作。

像写故事一样编写需求

每一个需求规格说明都能以用户故事的方式,以1到2行写到卡片上的想法,需求应该简明扼要(以致开发者必须向某人解释真正的需求是什么),坚持他们应该应该以相同形式的模板。

“作为某一类用户,我有目标期望因此某些问题…”

是非常愚蠢和没有必要的。在15年前,这同样是一类简单而又传统的想法,让每个人都用 UML的用例的形式试图去捕捉所有需求。

有更多不同的方式来有效的表达需求。有时候需求需要被规定到细节级别(当你必须满足合规性或者符合一种标准,或是与现有系统集成,或是实现特定的算法)有时候从一个测试用例或者一个具体的用例场景或一个框架或一切别的类型的模型开始会更有效,因为这样会让人知道如何推进,并且有些细节已经就绪。因此,运用格式化和细节层级能更有效也更容易开展工作。

对产品所有者的依赖

依赖作为产品拥有者的人,当项目失败的时候,就如客户唯一的声音和“一个发不出声音的喉咙”,无法扩展,无法持续,将团队和项目以及事实上的业务推向风险的边缘。很自然的,危险逐渐靠近正在设计的产品和管理中的开发项目,将比解决危险带来更多的问题。

一些团队意识到这一点,并试图与产品所有者的想法保持一致,因为他们必须这样做。为了成功,一个团队需要在各个层次的真实而持续的客户合同,他们需要对自己负责,为确保他们得到他们所需要的,而不是依赖某一个人去完成所有的一切。

--------------END----------------

欢迎关注【职业修炼师】头条号。

如果觉得这文章对你有用的话,能否分享、点赞、转发帮组到更多人。


 

 

2017-07-05 14:12:48 weixin_34250434 阅读数 24
  • SCRUM敏捷开发视频教程

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

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


【演讲PDF】: https://yq.aliyun.com/attachment/download/?id=1845

【演讲视频】: https://yq.aliyun.com/edu/lesson/550


2016年5月底我进入团队时,淘宝直播还是一个新业务,产品还在摸索中。迭代过了一半了,需求还没定下来;开发时间紧,需要加班加点赶工;淘宝直播并不是独立的应用,它是跟着手淘大版本,在这一超级应用中发版,而手淘的发版是火车制,有严格的质量卡点,质量不达标是不能发版的,而且火车制要求发版时间固定,错过之后就只能申请紧急发版。紧急版本线上问题非常多,运营人员忙于解决主播的问题,变成了客服。

7e42060f90d411cd9039db6255a37285ae45cce5

如上图团队仪表盘显示,判断一个团队有多敏捷,大致可以从图示的四个维度确定:

(1)Capacity:团队的容量,是指在单位时间内能够交付多少有价值的功能点

(2)Lead time:周期时间,是指从用户提出需求到用户用上其想要功能的时间跨度它是 敏捷的核心指标,反映了团队的响应力时间越短团队的迭代速度越快,对市场的 响应速度 越快,越有可能胜出

(3)Quality:质量,它决定了产品的存亡;

(4)Predictability:可预测性,它反映团队能否信守承诺

接下来的三个月,我和团队跟踪了上述指标的变化

9d61c376703a2471dcf30ffc3e9aa2b06f332704


上图是淘宝直播团队在6、7、8月变化的雷达图,在上图中,除了有上文所提到的四个维度,又加入最为重要的业务指标维度业务指标达不到,再好的研发过程指标也是竹篮打水一场空。从雷达图中可以看到,团队在稳步朝着业务指标前进。由于数据安全原因,这里不能展示具体的业务指标。下面从研发过程指标(完成需求数、周期时长、新建缺陷数、需求准时交付率看一下团队的变化

完成需求数

7c661f60c56df7bad4ea1cf14c790f37e5b0a14a 

上图是6、7、8三个月完成需求数的对比图,其中7月份之所以下滑是因为突然插队了两个需求,打乱了原本的节奏,进而影响了完成的需求数。而8月份,在没有插队需求的情况下,敏捷实践的效果就得到了凸显,完成的需求数较6月有所增加。

周期时长

c8f56bd6ba06b5f2d1a2f8825cc245fd2cb2e452 

上图是三个月的周期时长对比图,可以看到7月的开发时长和测试时长相比于其他两月有特别明显的升幅,这是由于插队的需求导致研发团队的并发度上升所致。这里也给各位团队负责人敲响了警钟,如果不想打乱团队的节奏,不希望团队一心多用,那么就要让团队按照自己的节奏来工作。另外一点值得注意的是需求分析的时长在6、7、8月逐渐下降,这是淘宝直播团队产品和UED小伙伴努力的结果;而测试时长呈现增加的趋势,是因为测试的工作压力比较均衡的分散开

新建缺陷数

2caffc398e180c38b93decc170b2e9d7fea245f2 

从上图可以看到,从5月份到8月份,缺陷总数和严重缺陷数量是不断减少的,产品质量得到了提升。同时低级缺陷(非常容易发现的缺陷)数量也明显减少,说明提测质量提高了。

需求准时交付率

54a7411a0faa2aefd78850417cc465361c200fe7 

在6月和8月,需求准时交付率做到了100%, 7月份由于插队需求的影响,交付率表现得差强人意。敏捷落地的过程并非一帆风顺这种时候,我和团队都没有失去信心。

 

变化的背后——聚焦业务目标

那么从6月分到8月份,发生这些变化的背后,我们究竟做了什么呢?我认为其中最为重要的一点就是聚焦业务目标。

 

1c66671db3f42ddbad7bb24c529c6f4da1a6b0d0 

上图是为淘宝团队制作的业务目标看板。每个月产品发版以后,都会更新上面的指标。大家可能会问业务指标不是在BI系统里,为什么还要贴到物理板上?这块板前面常常围着三三两两的小伙伴,大家一边分析指标一边想办法提升业务指标这就是看见的力量。

业务主线

明确业务目标之后的工作是寻找一条实现业务目标的思路。

ea0aae62e964d061d12494e61b1ab8e94ba27a9f 

业务主线的重要性在于能帮助我们聚焦,保证要事第一落到实处。从上图可以看到,7、8、9月份的业务主线:主播质量和转化、频道和互动升级、互动营销。这三条主线落实到具体的迭代中就变成了迭代目标:

f2bef7ab25bbe09266492f9af95626ea7508e641 

产品同学在提出功能时,就要分析这个功能能否提升业务目标,而且要用具体的数据说话,例如主播质量的提升和转化的业务目标是将主播的日均直播场次提高多少,主播的活跃度提高多少。在发版之后要进行数据对比验证这项功能是否真的有效。

迭代过程

da46ea79c831de7e78359d8fc8a5aed243288cba 

上面这块板是从需求设计到开发测试、发版端到端看板。左边白色的需求卡片是按照优先级排列的,跟业务主线相关的需求都上面黄色的卡片是任务,开发同学领任务时也是先领高优先级的任务为了限制大家的并发度,每个开发人员最多同时只能领两个任务。红色的标签表示风险有了这块板,研发过程的风险、研发人员的分工、进度一目了然。

 

变化的背后——快速验证假设

快速验证假设是所有创新业务面临的挑战。如何实现业务目标并无固定的途径,必须要靠摸索,去试错。在这个过程中,快速地试错、快速地验证假设变得尤为重要,它也是敏捷性的核心体现

下面来看一个实际的案例——首页改版。

ecc28f115d254e91c637b7b66be908feeb17f281 

首页改版有两个功能点:播放十秒视频和飘赞。前者是将淘宝直播页的静态主播照片替换为直播间最新的十秒视频,便于观众快速了解直播内容;后者是将静态的飘赞改为动态。这两个功能我们并非是直接加入新的版本,而是提前做了两个简单的原型,并且推送给1%-5%的用户做灰度测试,然后在24小时之后就拉到了第一版数据。整个流程总共花费两天时间,短时间验证功能的有效性,进而加快了迭代速度。

 

变化的背后——一起打磨需求

现在来看一下6月到8月需求时长缩短一半的原因。刚到淘宝直播团队时,产品的需求定不下来,需求评审时间长,甚至需求评审会变成了需求讨论会;开发和测试评审时才第一次看到需求,因此提出很多问题出现这种现象的一个原因是,大家是接力棒式的协作:不到我这一棒就不起跑

a2fce59f5de0cbcaf77f1dff5e035ffe70428428 

我们的改进的方式是产品在做需求分析时将开发和测试人员拉入团队,从等待接棒变成携手前行,大家一起打磨需求。具体做法是成立由产品经理、设计师、研发组成需求小组,人数控制在5人以下;需求小组一起打磨需求,其中产品经理聚焦价值、设计师聚焦用户体验、开发聚焦技术方案、测试聚焦验收标准;需求小组达成共识后再提交需求评审。

 

变化的背后——从小瀑布到持续交付

从6月到9月,测试人员的工作压力得到了很大的缓解,这得益于我们从小瀑布改进到了持续交付,而不是快发版的时候所有需求一起提测

9aeedf5951f4d61f80602acdc8e8d3f278eba869 

下图是8月迭代缺陷增量趋势。可以看出迭代进行到一半的时候,就逐步有需求提测测试和修复缺陷的压力从迭代的最后3天分散到10天,测试人员的工作压力随之减轻。

 

变化的背后——持续改进

如果一个团队出于自发的意愿,集体地、持续地改进,随着时间的发展,这个团队一定可以成长为非常棒的团队。

2746c939d4d72a22270d82d4ddf35e95ab89bfda 

上图是淘宝直播团队在6迭代回顾会的改进点行动点这些都是淘宝直播团队提出的,如最高票的提高评审效率这一改进点。我2017年1月份对淘宝直播团队回访时发现,看板、需求小组等敏捷实践团队仍在坚持使用,在完成需求和确保产品质量方面仍起到了很大的作用,有效提高了团队的效率。


2011-05-06 22:55:00 padden_zhang 阅读数 589
  • SCRUM敏捷开发视频教程

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

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

    什么是敏捷开发?

    敏捷开发是一种突出人的核心价值,循序渐进的开发方式。

    为什么说敏捷开发是以人为核心呢?

    软件的三个要素:程序,文档,数据。软件工程学的瀑布模型讲的也是文档的交流,一切都以文档为核心。 但是开发人员都知道,瀑布模型处理变需求是很恶心的,因为需求并不是一成不变的,但文档是死的。而敏捷开发中只需要必要的文档,而注重的是人与人之间的沟通和反馈。这里闲扯两句,瀑布模型是一个成熟的开发模式,但是它的弊端是处理问题过于教条,高举高打,最后阶段才进行测试,这样会造成开发人员在最后的阶段会有成堆的bug,可能有些bug会严重影响项目发布。现在有种提法是把scrum和瀑布模型结合开发。这里等到涉及scrum缺点的时候再写。

   为什么说敏捷开发是循序渐进呢?

    python之父Guido van Rossum说过:less is more,开发者认为,软件开发是一个庞大、精细、而又复杂的过程,把复杂的问题简单化是软件工程学需要解决的重要问题。敏捷开发是一个迭代的开发模式,就是说把一个复杂的模块分成若干个模块,又把这些模块再分割。实现将复杂的问题简单化。

    敏捷开发与scrum的关系:

    敏捷开发是技术规范,而scrum是敏捷开发的基于这种规范的实践。就像JMS与ActiveMQ,RESTful与java jersay一样。这里再闲扯两句:我一直不认为java是一个完全开源的语言,因为它的一些技术规范开源的并不多。

   scrum实践1:

    站立式早会:每天开个碰头会,说一下昨天做了什么,今天要做什么,有什么需要协调的,但是不谈技术细节。这样可以有效控制项目进度和风险,1个人也就1分钟左右,个人认为这样的效果要比发日报好,因为写到纸面上的总是没有面对面交流直观。

  scrum 实践2:

   任务面板:包括三栏:正在做的,还没做的,已经做完的,这样看一目了然,既能增加项目的可控性,也能增强开发者的成就感。

   scrum 实践3:

    计划纸牌:比如一个开发者写一个功能模块需要1个小时,他就把1个小时的纸牌抽中放在手里,而另一个开发者写同样的模块,他可能抽中代表5个小时的纸牌放在手里,最后把这两个人叫过来,让这两个人沟通为什么同样的模块计划实践却不一样。

2007-11-27 14:33:00 elevenXL 阅读数 1219
  • SCRUM敏捷开发视频教程

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

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

英文原文:http://www.agilemodeling.com/essays/modelStorming.htm

 

Model Storming是一种实时的建模方式: 你找到了一个需要解决的问题,你马上抓起一小撮团队里可以帮助你的同事,这个小组一起研讨解决这个问题,接下来每个人像刚才一样继续工作。这对于敏捷项目来说是很普遍的事情。使用极限编程的人称这个为站立的设计会议(stand-up design session)或者客户的问答会议(customer Q&A session),并且在传统的项目中也同样普遍。 我们是时候开始探讨一下model storm,我们可以找到某种方式让这个过程变得更好。

       我的经验是大多数的建模会议应该只有少量的人员参与,一般来说23位,这些人员讨论问题并且将草图画到纸或者白板上。这些model storming session基本上是一种即兴的事,一个项目团队成员让另一个人去和他一起建模,一般来说大概持续510分钟(model storm几乎很少超过30分钟)。 人们在围着共享的建模工具(例如白板),一起去探索直到他们满意的理解这个问题,接下来他们继续工作(经常是coding.

     Analysis Model Storming

       你将用model storm去分析需求。For example 一个项目相关人员可能告诉你你要构建的这个系统必须能够编辑学生的信息(译者:够俗的例子)。和组员们一起建立了草图,在屏幕上可以看到,see Figure 1。画了很多示例直到你们都理解了什么事你们需要构建的。这种草图是一种inclusive models 因为你们用了简单的工具和建模技术, 这将允许项目相关人员的参与敏捷建模实践。

Figure 1. Screen sketches.

 

Design Model Storming

敏捷开发者,包括XPer。当他们一旦选择了一个需求去完成,一般并不直接去编码(与敏捷开发的诋毁者告诉你的相反,:外国人也勾心斗角)。这是因为model storming对于架构和设计也很常用。java程序员在编写复杂的代码之前经常草草绘制一张UML sequence图(见Figure 2),XPer将建立CRC cardsClass Responsibility Collaborator )在索引卡片上(见Figure 3)用来揭示结构设计的一些细节问题, VB程序员可能选择画流程图(Flow charts)来为一个复杂的业务规则建模(见Figure 4)。无论你建立的是哪种模型,你一直在model storming

Figure 2. Service-level sequence diagram.

 

Figure 3. Hand-drawn CRC Cards.Figure 3. Hand-drawn CRC Cards.

 

 

Figure 4. Flowchart for enrolling in the University.

有一点很重要你必须理解,model storm并不一定必须是在白板上,你只需要一个共享的、包容性的工具(inclusive tool) 可以令人们在一起容易工作。举个例子,CRC卡片(Figure 3 被写到索引卡片上而不是白板上。

Why Dose This Work? (为什么这样做)

为什么model storming这种实时的工作比试图事前设计好所有的一切要好(model everything up front?

有很多原因:

1.       无论我们喜不喜欢,在整个项目过程中需求总是变化的。

2.       等到需要时再随即分析细节,比在项目一开始就做这些你有了更多的领域知识。举个例子,如果一个需求要加入在项目中并在三个月内实现,对于研究一些需求的细节如果你有了三个月的领域知识会多于在项目开始,因此你能提出更多睿智的问题。

3.       如果你已经经常性的交付你的软件,那么项目相关者就会有三个月的对系统使用的经验。话句话说,他们可以给你更好的建议。

4.       事先设计细节常常会出现一个巨大浪费的结果。是的,尽管在敏捷开发中,在第0次迭代你想去做一些初始化需求的猜想和一些初始化架构的猜想,但是他们并不意味着你需要跳入细节的沼泽中。

话虽如此,当在为复杂的需求建模,或者为遗留下来的系统(legacy)建模的时候,有时你还是需要事先实现一些设计。这种情况实际上很少发生(不管传统的建模者可能对这种事情的期望),但是偶尔也会有。(This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often.)

Adopting Model Storming

在你的工作环境中如何去推荐model storming呢?首先,越多的白板空间越好。一些公司不愿意去放置白板,很显然他们更关心内部的装饰,比如一个吸引人的打印出来的东西在墙上,这比起另软件开发团队更有效率的工作来讲对他们更重要。我的建议是不但要有很多的白板可供人使用,并且你还需要确定当他们背对着工作区的时候是否能看见,这可以令他们可以使用白板更easy的工作。

       你可能需要为使用白板制定一种协议,特别当要擦掉一些东西的时候。你的团队文化同样对你的成功有着举足轻重的作用,团队必须可以接受其他人要求帮助,并且可以让其他人一起建模。你需要认识到这是正常的并且是有效的工作方式。我不能记得我们不用model storm时的项目,同样我也不能记起关于这个技术的很多细节的读书或者文章。如果it产业开始谈论我们在实践中实际做了什么而不是我们想我们应该做事情 不会更精彩么?

                                         

                                                                                                                             译者:李鑫

注:以上内容来自网络,本人不承担连带责任

文章转自:http://blog.csdn.net/smalllixin/archive/2007/11/16/1888049.aspx

 

2007-11-16 10:58:00 smalllixin 阅读数 1043
  • SCRUM敏捷开发视频教程

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

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

英文原文:http://www.agilemodeling.com/essays/modelStorming.htm

 

Model Storming是一种实时的建模方式: 你找到了一个需要解决的问题,你马上抓起一小撮团队里可以帮助你的同事,这个小组一起研讨解决这个问题,接下来每个人像刚才一样继续工作。这对于敏捷项目来说是很普遍的事情。使用极限编程的人称这个为站立的设计会议(stand-up design session)或者客户的问答会议(customer Q&A session),并且在传统的项目中也同样普遍。 我们是时候开始探讨一下model storm,我们可以找到某种方式让这个过程变得更好。

       我的经验是大多数的建模会议应该只有少量的人员参与,一般来说23位,这些人员讨论问题并且将草图画到纸或者白板上。这些model storming session基本上是一种即兴的事,一个项目团队成员让另一个人去和他一起建模,一般来说大概持续510分钟(model storm几乎很少超过30分钟)。 人们在围着共享的建模工具(例如白板),一起去探索直到他们满意的理解这个问题,接下来他们继续工作(经常是coding.

     Analysis Model Storming

       你将用model storm去分析需求。For example 一个项目相关人员可能告诉你你要构建的这个系统必须能够编辑学生的信息(译者:够俗的例子)。和组员们一起建立了草图,在屏幕上可以看到,see Figure 1。画了很多示例直到你们都理解了什么事你们需要构建的。这种草图是一种inclusive models 因为你们用了简单的工具和建模技术, 这将允许项目相关人员的参与敏捷建模实践。

Figure 1. Screen sketches.

 

Design Model Storming

敏捷开发者,包括XPer。当他们一旦选择了一个需求去完成,一般并不直接去编码(与敏捷开发的诋毁者告诉你的相反,:外国人也勾心斗角)。这是因为model storming对于架构和设计也很常用。java程序员在编写复杂的代码之前经常草草绘制一张UML sequence图(见Figure 2),XPer将建立CRC cardsClass Responsibility Collaborator )在索引卡片上(见Figure 3)用来揭示结构设计的一些细节问题, VB程序员可能选择画流程图(Flow charts)来为一个复杂的业务规则建模(见Figure 4)。无论你建立的是哪种模型,你一直在model storming

Figure 2. Service-level sequence diagram.

 

Figure 3. Hand-drawn CRC Cards.Figure 3. Hand-drawn CRC Cards.

 

 

Figure 4. Flowchart for enrolling in the University.

有一点很重要你必须理解,model storm并不一定必须是在白板上,你只需要一个共享的、包容性的工具(inclusive tool) 可以令人们在一起容易工作。举个例子,CRC卡片(Figure 3 被写到索引卡片上而不是白板上。

Why Dose This Work? (为什么这样做)

为什么model storming这种实时的工作比试图事前设计好所有的一切要好(model everything up front?

有很多原因:

1.       无论我们喜不喜欢,在整个项目过程中需求总是变化的。

2.       等到需要时再随即分析细节,比在项目一开始就做这些你有了更多的领域知识。举个例子,如果一个需求要加入在项目中并在三个月内实现,对于研究一些需求的细节如果你有了三个月的领域知识会多于在项目开始,因此你能提出更多睿智的问题。

3.       如果你已经经常性的交付你的软件,那么项目相关者就会有三个月的对系统使用的经验。话句话说,他们可以给你更好的建议。

4.       事先设计细节常常会出现一个巨大浪费的结果。是的,尽管在敏捷开发中,在第0次迭代你想去做一些初始化需求的猜想和一些初始化架构的猜想,但是他们并不意味着你需要跳入细节的沼泽中。

话虽如此,当在为复杂的需求建模,或者为遗留下来的系统(legacy)建模的时候,有时你还是需要事先实现一些设计。这种情况实际上很少发生(不管传统的建模者可能对这种事情的期望),但是偶尔也会有。(This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often.)

Adopting Model Storming

在你的工作环境中如何去推荐model storming呢?首先,越多的白板空间越好。一些公司不愿意去放置白板,很显然他们更关心内部的装饰,比如一个吸引人的打印出来的东西在墙上,这比起另软件开发团队更有效率的工作来讲对他们更重要。我的建议是不但要有很多的白板可供人使用,并且你还需要确定当他们背对着工作区的时候是否能看见,这可以令他们可以使用白板更easy的工作。

       你可能需要为使用白板制定一种协议,特别当要擦掉一些东西的时候。你的团队文化同样对你的成功有着举足轻重的作用,团队必须可以接受其他人要求帮助,并且可以让其他人一起建模。你需要认识到这是正常的并且是有效的工作方式。我不能记得我们不用model storm时的项目,同样我也不能记起关于这个技术的很多细节的读书或者文章。如果it产业开始谈论我们在实践中实际做了什么而不是我们想我们应该做事情 不会更精彩么?

                                         

                                翻译的水平很有限,有不当的地方请指正,转载请注明译者:李鑫

 

没有更多推荐了,返回首页