Category: Scrum

Scrum Framework

Scrum Introduction (4 hours) 090903

在开始之前,我绝没有想到过会用如此和往常不一样的方式来开展这一次的培训。我的讲解习惯、回答问题的方式和Scrum模拟练习的执行都和以往有不同,关键的是感觉不错,记下来备案。 预订中午1点开始的培训,一刻钟过去都没见人到齐,正好借机强调working agreement的重要性,“要靠谁的努力我们才能有一个有效的培训呢?”,当然要大家都认可才行。不过有点可惜,没到十分钟就有人破坏mute phone最后一条,说是有紧急的测试事件,大家提不出什么建设性意见,那就只好告诉他们我的倾向“有事情可以出去接电话,但不要在会议室里干扰其他同事。” 由于时间有限,能讲的内容不多,Expectation是个蛮好的方式来澄清,既然是介绍Scrum,就把Agile以及其在公司的应用之类的问题省略过,估计这也很大程度上导致一两位同事觉得内容讲得不够多吧。 讲到Scrum的大致过程时,感觉大家精神状态不咋地,(也许和座椅海拔太低、投影幕布却有点高高脱不了关系),需要吸引一下大家的注意力,我决定多走一走,多画一画,如果大家的眼球必须得跟着我移动,那一定会好一些。没有像往常一样展示ppt并通过语言解释,而是在空白的flipchart上开始介绍Scrum的三个角色、三个产物和三个仪式。附带着还在这张图上解释了“how Scrum changes work?”和“Scrum Master role in Scrum?”,结果弄得很凌乱。另一张图则是为了解释如何进行预先、持续的需求分析(backlog grooming,requirement analysis)。 这次培训最大的区别在于,在Scrum模拟中product owner的角色由我扮演,而大家分作我手下的两个团队。他们需要在planning meeting中确认能够完成的用户需求有多少,而我则非常吃惊地被告知大家可以实现所有的需求。。两个团队协作才能实现整个产品,这需要他们考虑如何整合彼此负责的片段,在日常工作中的配合等等一系列的问题。虽然两个团队都没有编制Sprint Backlog,但他们有少量使用index card来跟踪需求及其剩余工作量估计,结果也还不错,团队A放弃了第五个客户需求,其他的都完成的很不错。从一开始就在强调的“一体化的产品”,直到最后时刻都还需要我来提醒,他们才临时抱佛脚,结果页面顺序装订有错。。 Sprint Review之后就是retrospective,两个团队分别回顾总结了上个sprint。 最后,为了我自己的提高,请大家为培训写下自己的觉得做得不错和有待改进的地方,加上一个总体的分数评价。 可以看看这些学员完成的宣传册。               封面                                  封底 贴在A4纸上的报事贴其实是嵌入各个版面的广告,哈哈,这是我对大家的要求,用户需求列表中的一条就是广告,而我对其的解释是要求有针对性,而且嵌入式,不是专门某一页整页介绍广告,因为那样的话读者可以直接跳过或者撕掉(似乎有点过于恶毒了。。)。 注意在页面下方的报事贴,它超出了页面的下方边界,被我用来作为证据之一(整体格式,i.e.系统测试)指点大家还有很多需要注意的地方。除此之外,还包括:统一使用英文或中文,任意一种都可以,但不应同时使用;实际的工作中需要统一字体格式;等等。 如果仔细地看,会发现在所有的页面上都有西湖三潭映月的图案,这也是用户需求之一“旅行社标识”,哈哈~

Retrospective for one testing team

This testing team haven’t done retrospective before, and there’s no actions before too. They were in “Scrum” as said by organization Agile transformation even though they only do testing, and they were actually not a team, members were responsible for

时间盒与进度压力

传统组织向敏捷开发方式的迁移中,容易延续以往的行为模式, 例如对待进度压力的方式。 某大型企业,传统的发布周期为两年,采用的是瀑布模型。在实施Scrum的过程中,时间盒是争论的焦点之一,多数情况下,时间盒概念被漠视,产品负责人及若干利益相关人依然会迫于进度的压力,向开发团队施压,要求必须完成过量的特性开发,以及接受不完全满足Done Definition的特性。 类似的行为导致企业自认为在实施“Scrum”,其行为模式其实和过去一模一样,换汤不换药,无非是挂着自组织团队以及跨职能团队的旗号,进一步压榨开发团队的血汗而已。无助于达到企业实施敏捷迁移的初衷,更无法获取所期待的收益。 传统模式中,其发布被分割为需求分析、设计、开发、测试、系统测试,以及应用层的开发等阶段,每个阶段耗时以月计,例如某个模块的测试可能持续三个月之久。此时,进度可能出现的延迟、逐渐显露的风险等等问题,都在接近完成任务的预计日期时暴露出来。各个阶段的进度压力叠加到发布上,就更加难以解决,且也会在临近发布日期时达到最高点。管理者的应对手段无非是加人、加班、赶工降质量标准等等,幸运的是,往往还足以让可以接受。而之后客户发现的软件缺陷则被当做单独的处理,至于它们和那两年期间以及发布日期临近时的加班加点之间的联系,则已无人问津。 遗憾的是,采用Scrum的组织往往会发现,这种赶工现象有增无减。原因在于,以往要三个月或是一年之后才感受到的进度压力,如今每一个sprint都可以感受得无比真切。产品负责人或是具有实权的管理者若是延续过往思路,企图采取措施挽救进度危机,要求开发团队“使命必达”,“务必在某年某月某日前完成xxx一系列功能”。对进度的追求换来的是对质量的牺牲,以及欠下的技术债务。让形势变本加厉的恰恰是Scrum自身时间盒以及增量式的特点,每一个sprint,技术债务就累积一次,臭虫就多几个,开发就慢一些,进度就更紧一点。团队无法按期完成任务的表象,会侧面地验证自组织团队的荒谬性,传统思维管理者们会更自信项目需要他们的介入,从而引入更多的命令与控制。 时间盒与进度压力,你要哪一个?

如何做事(Scrum, Agile, Mode of Operation)

【在公司论坛上发的帖子,觉得蛮不错,也适合公开,自己博客上也放一份】 依稀记得小时候,我还长得蛮壮实,也算班级的体育尖子,当时也就铅球、垒球都很弱,怎么都扔不远,很多人都很奇怪,觉得我这么大个块头,胳膊肘也粗得很,咋就扔不动呢。我也很努力地在观察别人的东西,学习模仿,可就是没搞成,庆幸我仗着蛮力,反正能及格,也就不愿意多花时间去深究。 当然当时老师的教诲还是记得一点点,大致也就是用力的部位要吃准,好像是胳膊肘吧,然后出手的动作要ok,似乎是要有向上推的动作,不能是甩出去,等等好些注意事项。遗憾的是我要么没听进去,要么听懂了可做不到,或者习惯性的就甩手出球了。 渐渐的,经历了更多其他的事情,我理解到,要好好地做成一件事,需要很多。首先,要正确的理解这件事情;其次,要找对方法,以及理解方法怎么用;然后要切实到位地使用好这个方法;如果出了问题,要分辨清楚问题的原因究竟是什么:1:是错误的理解了问题域(要处理的事情)?2:还是对问题域理解正确,但选择错了方法?3:或者是都正确,但实施的过程出了问题?4:也或者因由其他因素导致力不从心、有心无力? 在帖子《Scrum在杭州不成功的实践》中,xdjm们贡献了很多自己所看到的事实(facts),那么从这些里面我们究竟可以得到什么结论,又可以如何为随后的改进提供参考,以及之后该怎么办呢? 我想我所能做的也就是分享我自己的思考路线,供大家参考。 Scrum是什么?http://www.scrumalliance.org/pages/what_is_scrum里有讲到,它就是三个仪式,三个角色,三个人造物件。套用Ken曾经在某处说过的一句话“scrum只是说要有product backlog,有估计、价值、优先级。是Mike Cohn等专家提出具体的建议如何创建product backlog,如何进行规划和估计等等实践。” Agile是什么?http://www.agilemanifesto.org/所提到的四个价值观和http://www.agilemanifesto.org/principles.html里的十二条原则就是Agile的全部含义。 Mode of Operation:它是xx(某研发部门)寻求转向为更敏捷的研发组织过程中所制定的运行模式。其使用了scrum框架来管理组织结构及团队,也使用了很多XP的实践(例如单元测试、持续集成等),也使用了backlog或是task board的实践。并不意味着IPA MoO包含了scrum或是Agile,更何况设计的和实际运行的IPA MoO自身也许就并不相同。 Generalizing Specialist:这里有比较不错的解释,http://www.agilemodeling.com/essays/generalizingSpecialists.htm。 【附上和外国同事讨论时想到的一个有趣比喻,如果我们驾驶的是一辆破车,狂踩油门不会让它跑得更快,只会换来漫天烟尘。它不能说明我们不该踩油门,只不过是告诉我们“该修车了”。敏捷迁移,也不过如此。】

0523 Scrum Chengdu Assembling

23th May 2009, we had "The First Assembling of Scrum Chengdu – Scrum Chengdu | Google Groups", our Nokia Siemens Networks and Cybercom sponsored this event. The poster can be found everywhere at Chengdu Tianfu Software Park. The place is

Scrum Forum 2009 @ Hangzhou.0516

At 16th May 2009, we had a small gathering of Scrum (~60 people). Participants come from companies of many different business, including subcontracting service, telecommunication, CAD supporting, subway system design and so on.   Perficient hosted this event, the place

Sprint Burndown Chart : hours left, but not burnt ones

  this is a burndown chart I found from our office. On this chart, everyday the numbers used are minused / burnt hours, instead of remaining hours. My first impression was surprising, quickly took a photo and planned to record

CSM Training By Michael James

Last two days I joined Michael James‘ CSM course at Shanghai, he gave it together with Bas Vodde. Two years ago, I attended Bas’ course and became a Certified Scrum Master. Michael’s course is so different from Bas’, even Bas

Quickly About Sprint Review

Today’s dinner, I asked Craig how to facilitate a sprint review. Craig said : first, sprint review is NOT demo, it’s all about conversation. Demo should be finished in minutes. Then PO and teams talk about the products, good and

Team, the capacity

A very brief thought about team & teamwork. Personnel’s technical skills are “operands”, then the ability of people’s teamwork skills is “operator”. Then teams differ according to their abilities in those aspects, and it may result in huge difference capabilities.

Top