敏捷开发日常跟进系列
这个系列将涉及燃尽图(Burndown Chart)、故事板(看板)、每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目经理的各种活动,大约包含10篇文章。
火星人陈勇
火星人,敏捷开发咨询师,早期软件成本估算咨询师,资深程序员
展开
-
敏捷开发日常跟进系列之六:开发与跟进
这是敏捷开发日常跟进系列的第六篇。 (栏目目录) 产品负责人常常被描述成在计划会前准备好用户故事,在计划会上讲解并帮助开发团队估算后就万事大吉,只等月底接收“可工作软件”的样子,其实如果真的这样,很容易出问题。需求精化这是发生在迭代周期中间的常规活动,产品负责人会与团队密切接触(确切说如果能经常坐在一起更好),在每个故事开发的前夜或中间,将之前讲解过的用户故事更详细地描述一番(有时候是在看到开发一原创 2011-10-25 21:03:15 · 6329 阅读 · 0 评论 -
敏捷开发日常跟进系列之六:验收标准
这是敏捷开发日常跟进系列的第六篇。 (栏目目录) 要想不在评审会上得到“惊喜”,Product Owner最好提前约定好用户故事的验收标准,而且每个用户故事可能各不相同。面向客户价值设定验收标准简单说,就是客户看到说“完成了”,才算完成了。从这一点上说,用户眼中的“可工作软件”和我们认为“可以运行,自动化测试了的,没有缺陷的”软件还是有差别的。用户拿到软件,是要使用从而获得价值的,这常常需要多个功原创 2011-10-25 18:29:30 · 7903 阅读 · 2 评论 -
敏捷开发日常跟进系列之五:用户故事与MVC
这是敏捷开发日常跟进系列的第五篇。 (栏目目录) 用户故事和MVC没有关系,因为MVC是实现方法,因此在思考用户故事的时候,不要一下就想到实现方法,很容易把故事写坏。但是MVC和用户故事有很大的关系,如果用户故事写好了,做MVC的时候,一定要记得参考用户故事。本人在C++的年代用过MVC,但那个时候MVC还只是一种编程思想,说用了也行,说没用也行。但到了C#之后,就出现了正牌的自称是MVC的东西(原创 2011-10-12 23:45:45 · 7145 阅读 · 5 评论 -
敏捷开发日常跟进系列之四:跟进表
这是敏捷开发日常跟进系列的第四篇。 (栏目目录)跟进表是大型敏捷团队的一种实践。在一个80多人的网络游戏团队中,他们为了清晰地显示整个团队的运作方式,使用了这种方法。跟进表以上面的网络游戏团队为例,说明一下跟进表上的信息:1. 哪些故事完成了在故事板中也能表达,但缺少结构性。故事板中的故事都是平等的,较难显示大小、父子包含关系等。2. 谁在跟进案例中这个人一般是策划人员,故事的创建者和验收者。3.原创 2012-03-10 12:08:57 · 10849 阅读 · 6 评论 -
敏捷开发日常跟进系列之三:故事板,看板
这是敏捷开发日常跟进系列的第三篇。 (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致相同。故事板简单说,故事板是展示迭代中的用户故事和任务的方法,在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板:一般故事板分为三列:To Do还没做的, D原创 2012-03-05 20:15:53 · 19126 阅读 · 5 评论 -
敏捷开发日常跟进系列之二:燃尽图(中)
这是敏捷开发日常跟进系列的第二篇(栏目目录)。迭代及燃尽图的目标燃尽图的目标是完成迭代的目标,迭代的目标是什么呢?1. 按产品经理的要求,交付计划会中计划的用户故事2. 尽量完成1之后还会看到,这个定义还有狭隘之处,在系列后面的文章中会提到。为什么燃尽图不能直接地达成这个目标?潜在的问题包括:1. 如果燃尽图按时完成,有可能是为了按时完成,同时牺牲了所有故事(重要和不重要的)的质量,换取了进度。2原创 2012-02-29 10:46:30 · 12784 阅读 · 3 评论 -
敏捷开发日常跟进系列之一:燃尽图(上)
这是敏捷开发日常跟进系列的第一篇(栏目目录)。这个系列将涉及燃尽图(Burndown Chart)、故事板(看板)、每日立会等内容,描述在计划会之后,评审会之前,敏捷开发团队内部产出与产品经理和项目经理的各种活动。日常跟进中的某些内容比如团队工作模型、预估会议、用户故事跟进等在之前的松结对编程、团队管理、用户故事、产品管理等系列中有所描述。在这个系列之前,还应该有一个敏捷计划系列,描述敏捷开发的从原创 2012-02-29 09:04:09 · 22158 阅读 · 3 评论