Release Choo Choo  

发布火车呜呜

在LAFABLE项目中,发布火车呜呜是在规划阶段启动的。

Planning                  

架构师

在LAFABLE中,架构师身处象牙塔上,无须担心编写代码这种卑微小事会弄脏他们高贵的手,不管团队是否需要,他们只负责提出大量不切实际的建议。如果一个项目出现了任何问题,LAFABLE要求架构师与产品拥有者和巡游主管站在一起,并坚信只要团队构建了要求的内容,项目一定会取得成功。

产品拥有者

在LAFABLE中, 产品拥有者决定产品功能。为了有效地实现这一点,产品拥有者必须拥有项目中涉及的一切资源——不但包括人力资源,还有其他一切!

巡游大师

巡游大师充当团队的教练,从不放过任何一个大喊大叫和斥责团队的机会。优秀的巡游主管总是着眼于团队的持续改进,为团队成员找到无数改进的方法,并且毫不吝惜地分享给团队。一个顶尖的团队通过都配有顶尖的巡游大师,参加为期两天的魔鬼训练营课程即可获得巡游大师认证证书。

开发和测试人员

怎么也得有几名开发和测试人员围绕在产品拥有者和巡游大师的身边,让他们有当老板的感觉。

待办列表的待办列表

在LAFABLE里有太多的待办列表了,团队维护待办列表的待办列表只是为了让工作清晰一点。

产品待办列表

产品待办列表中包含了产品拥有者对该产品的所有需求。如果某个功能不在产品待办列表中,根据LAFABLE的规则,产品拥有者不能因为没有获得该功能而对团队大呼小叫。幸运的是,根据LAFABLE的另一条规则,产品拥有者可以随时向产品待办列表中添加内容,哪怕是在对团队大呼小叫之前。

团队交付日期估算

团队会拍脑袋估计一个大致的产品交付日期,编造这个数字完全是为了取悦利益相关者和外部管理人员,没有人会真正关心。

口头支持

虽然口头上答应让团队评估他们自己的工作,但是业务方会根据自己对功能的期待,心血来潮并不切实际地地确定一个交付日期。考虑到开发和测试人员时间的宝贵,最终确定的交付日期也不必征询他们的意见。

最后期限

项目的最后期限公布了。在LAFABLE中,通常是先将团队的预期完成时间砍掉一半,再缩小度量单位来得到最后期限。这样,一个预期4个月内完成的任务,团队将获得2周的交货期限。

Strolling                

发布火车呜呜

在项目巡游阶段,发布火车呜呜忙得不可开交,一路高歌猛进。

团队待办列表

团队待办列表中包含了巡游过程中所有必须完成的内容。团队待办列表是由项目的技术主管创建的,他将任务分配给其他团队成员,同时,自己保留最好、最有意思的任务。

个人待办列表

为了避免对共同责任的管理困难,每个团队成员都拥有个人待办列表,里面都是他/她自己负责的任务。如果某个团队成员没有完成自己的个人待办列表中的所有内容,那么他/她不要奢望可以从其他人那里获得帮助,因为其他团队成员会被要求提前开始下一次巡游。

结对管理

基于结对编程的成功,LAFABLE引入了结对管理,每个开发或测试人员都由两名经理监控着。每项任务都有两双眼睛盯着,每一个微观管理的机会都绝对不会被忽视。

『差不多可以开始』的定义

每一个团队都建立了『差不多可以开始』的定义。任何任务在满足这个定义之前,都不能被称为已开始。典型的定义内容包括:

  • 开发人员早上已经喝过咖啡了
  • 开发人员已经阅读过最爱看的早间新闻
  • 开发人员听说过这个任务

一旦这些事情都完成了,开发人员就可以在每日站会上报告这项任务已经开始了。

『在我的设备上已完成』的定义

一旦开发人员看到某个功能在他/她自己的设备上运行了一次,这个特性就可以被汇报『在我的设备上已完成』。在LAFABLE中,资深开发人员需要遵守更高的标准,只有某个特性在他们的设备上运行过多次,才能被称为『在我的设备上已完成』。

『差不多完成』的定义

为了避免沟通问题,在LAFABLE中,团队会建立一个『差不多完成』的定义。一旦一项需求差不多完成了,就会被部署到生产环境中。这样会让用户参与到测试过程。这让用户觉得参与到产品开发过程中比拿到高质量的功能更重要,这样产品可以早早地交付给他们。

『这次我们真的认为完成了』的定义

终于,功能达到了团队真的认为完成了的状态,真的,他们做到了。只是测试人员还没有看到这个功能,测试是稳定阶段才会发生的事。

Stabilization          

测试人员初次接触系统

所有的巡游都结束了,是时候让测试人员参与进来了!在LAFABLE中,所有的测试工作都是在漫长的稳定阶段进行的。不过别担心,也不是很漫长。根据LAFABLE的规则,团队花费的测试时间不能超过发现和修复所有缺陷所花时间的一半,从而确保您可以使用一个低质量的发布版本在市场上击败竞争对手。

产品拥有者的隐藏待办列表

在LAFABLE中,团队被要求“拥抱变化”。产品拥有者通过故意将一些需求拖到项目后期才引入,来确保团队具备“拥抱变化”的能力。通过在项目后期引入重要的功能和实施架构上的变更,产品拥有者确保团队可以随时应对变更。

拳击手套

在LAFABLE中,所有的沟通都是书面的,所有书面文档都需要进行解释,因此,产品拥有者、巡游主管和其他团队成员陷入了三方战斗。这场斗争关系到书面文档中各种形式陈述的最终解释权,因此,无论谁赢得了这场战斗并拥有了最终解释权,都可以对其他人说:“好吧,我知道你是怎样解读这种需求的,但我向你保证,那不是他真正的含义!”

快速砍需求阶段

对于LAFABLE项目来说,最重要也是最后的阶段是,将那些不能给团队提供足够时间进行交付的功能快速移除出项目范围。

发布火车呜呜

在稳固阶段,发布火车呜呜其实是一列失事的火车。

火车失事啦!所有人在现实中惊醒,发布火车呜呜早已偏离了产品待办列表的轨道