forked from mebusw/lafable-cn
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.html
More file actions
346 lines (302 loc) · 23.2 KB
/
index.html
File metadata and controls
346 lines (302 loc) · 23.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
<!DOCTYPE html>
<html class="no-js">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>LAFABLE - Large Agile Framework Appropriate for Big, Lumbering Enterprises - 适合重型企业的大型敏捷框架</title>
<meta name="description" content="">
<link href='//fonts.googleapis.com/css?family=Open+Sans+Condensed:700|Open+Sans:400,300,700' rel='stylesheet' type='text/css'>
<link rel="stylesheet" href="stylesheets/main.css">
<link rel="stylesheet" href="//cdn.bootcss.com/tooltipster/3.3.0/css/tooltipster.min.css">
<link rel="stylesheet" href="//cdn.bootcss.com/remodal/1.1.1/remodal.min.css">
<link rel="stylesheet" href="//cdn.bootcss.com/remodal/1.1.1/remodal-default-theme.min.css">
</head>
<body>
<div class="container remodal-bg">
<header role="banner">
<h1>适合重型企业的大型敏捷框架 LAFABLE</h1>
<h2>Large Agile Framework Appropriate for Big, Lumbering Enterprises</h2>
</header>
<main role="main">
<section class="train">
<img src="images/train-1.png" alt="Release Choo Choo">
<i class="diagram-marker" data-tt="bp1" style="top: 20px; left: 217px"> </i>
<div id="bp1" class="diagram-tt">
<h2>发布火车呜呜</h2>
<p>在LAFABLE项目中,发布火车呜呜是在规划阶段启动的。</p>
<!--
<h2>Release Choo Choo</h2>
<p>On a LAFABLE project, the Release Choo Choo is set in motion during the Planning Phase.</p>
-->
</div>
</section>
<section class="planning">
<img src="images/planning-train-cn.png" alt="Planning">
<i class="diagram-marker" data-tt="pl0" style="top: 285px; left: 165px"> </i>
<i class="diagram-marker" data-tt="pl1" style="top: 335px; left: 230px"> </i>
<i class="diagram-marker" data-tt="pl2" style="top: 345px; left: 100px"> </i>
<i class="diagram-marker" data-tt="pl3" style="top: 160px; left: 80px"> </i>
<i class="diagram-marker" data-tt="pl4" style="top: 160px; left: 360px"> </i>
<i class="diagram-marker" data-tt="pl5" style="top: 160px; left: 480px"> </i>
<i class="diagram-marker" data-tt="pl6" style="top: 160px; left: 615px"> </i>
<i class="diagram-marker" data-tt="pl7" style="top: 200px; left: 750px"> </i>
<i class="diagram-marker" data-tt="pl8" style="top: 200px; left: 880px"> </i>
<div id="pl0" class="diagram-tt">
<h2>架构师</h2>
<p>在LAFABLE中,架构师身处象牙塔上,无须担心编写代码这种卑微小事会弄脏他们高贵的手,不管团队是否需要,他们只负责提出大量不切实际的建议。如果一个项目出现了任何问题,LAFABLE要求架构师与产品拥有者和巡游主管站在一起,并坚信只要团队构建了要求的内容,项目一定会取得成功。</p>
<!--
<h2>Architect</h2>
<p>Residing in an ivory tower, positioned well away from the need to dirty his or her hands with code, a LAFABLE project architect is responsible for giving the team lots of unsolicited advice. If anything goes wrong on a project, the Architect is required by LAFABLE to side with the product owner and Stroll Master in insisting that if the team had just built what was specified, the project would have been a success.</p>
-->
</div>
<div id="pl1" class="diagram-tt">
<h2>产品拥有者</h2>
<p>在LAFABLE中, 产品拥有者决定产品功能。为了有效地实现这一点,产品拥有者必须拥有项目中涉及的一切资源——不但包括人力资源,还有其他一切!</p>
<!--
<h2>Product Owner</h2>
<p>In LAFABLE, the product owner is responsible for making all decisions about the functionality of the product. To do that effectively, it is important for the product owner to own all the resources involved in the project—human and other. </p>
-->
</div>
<div id="pl2" class="diagram-tt">
<h2>巡游大师</h2>
<p>巡游大师充当团队的教练,从不放过任何一个大喊大叫和斥责团队的机会。优秀的巡游主管总是着眼于团队的持续改进,为团队成员找到无数改进的方法,并且毫不吝惜地分享给团队。一个顶尖的团队通过都配有顶尖的巡游大师,参加为期两天的魔鬼训练营课程即可获得巡游大师认证证书。</p>
<!--
<h2>Stroll Master</h2>
<p>A team’s Stroll Master acts as a coach for the team—yelling and berating the team at every opportunity. Always acting with an eye toward continuous improvement, a good Stroll Master can find innumerable ways for team members to improve and is not shy about sharing these with them. The best teams are staffed by a Certified StrollMaster who participated in a grueling two-day course to earn that certification.</p>
-->
</div>
<div id="pl3" class="diagram-tt">
<h2>开发和测试人员</h2>
<p>怎么也得有几名开发和测试人员围绕在产品拥有者和巡游大师的身边,让他们有当老板的感觉。</p>
<!--
<h2>Developers and Testers</h2>
<p>It is good to have at least a few developers and testers around so that the Product Owner and Stroll Master have people to boss around. </p>
-->
</div>
<div id="pl4" class="diagram-tt">
<h2>待办列表的待办列表</h2>
<p>在LAFABLE里有太多的待办列表了,团队维护待办列表的待办列表只是为了让工作清晰一点。</p>
<!--
<h2>Backlog of Backlogs</h2>
<p>There are so many backlogs in LAFABLE that the team maintains a backlog of backlogs just to keep things straight.</p>
-->
</div>
<div id="pl5" class="diagram-tt">
<h2>产品待办列表</h2>
<p>产品待办列表中包含了产品拥有者对该产品的所有需求。如果某个功能不在产品待办列表中,根据LAFABLE的规则,产品拥有者不能因为没有获得该功能而对团队大呼小叫。幸运的是,根据LAFABLE的另一条规则,产品拥有者可以随时向产品待办列表中添加内容,哪怕是在对团队大呼小叫之前。</p>
<!--
<h2>Product Backlog</h2>
<p>The product backlog contains everything the product owner demands be in the product. If a feature is not in the product backlog, LAFABLE rules prevent the product owner from yelling at the team about not getting that feature. Fortunately, another LAFABLE rule allows the product owner to add to the product backlog at any time, including right before yelling at the team.</p>
-->
</div>
<div id="pl6" class="diagram-tt">
<h2>团队交付日期估算</h2>
<p>团队会拍脑袋估计一个大致的产品交付日期,编造这个数字完全是为了取悦利益相关者和外部管理人员,没有人会真正关心。</p>
<!--
<h2>Team’s Delivery Date Estimate</h2>
<p>The team produces a date estimate range of when the product will be finished. This estimate is produced solely for the amusement of stakeholders and external management. No one pays any attention to it.</p>
-->
</div>
<div id="pl7" class="diagram-tt">
<h2>口头支持</h2>
<p>虽然口头上答应让团队评估他们自己的工作,但是业务方会根据自己对功能的期待,心血来潮并不切实际地地确定一个交付日期。考虑到开发和测试人员时间的宝贵,最终确定的交付日期也不必征询他们的意见。</p>
<!--
<h2>Lip Service</h2>
<p>While paying lip service to having the team estimate their own work, the business stakeholders lock down a due date based on desired functionality, whim, and a disconnect from reality. Out of respect for developers’ and testers’ time, they are not consulted to create this estimate.</p>
-->
</div>
<div id="pl8" class="diagram-tt">
<h2>最后期限</h2>
<p>项目的最后期限公布了。在LAFABLE中,通常是先将团队的预期完成时间砍掉一半,再缩小度量单位来得到最后期限。这样,一个预期4个月内完成的任务,团队将获得2周的交货期限。</p>
<!--
<h2>Deadline</h2>
<p>A deadline for the project is published. Deadlines in LAFABLE are most commonly selected by taking the team’s expected finish date, halving it, and decreasing the unit of measure. In that way, a team that expects to finish in 4 months will be given a deadline of two weeks. </p>
-->
</div>
</section>
<section class="strolling">
<img src="images/strolling-train-cn.png" alt="Strolling">
<i class="diagram-marker" data-tt="st0" style="top: 245px; left: 40px"> </i>
<i class="diagram-marker" data-tt="st1" style="top: 245px; left: 330px"> </i>
<i class="diagram-marker" data-tt="st2" style="top: 245px; left: 430px"> </i>
<i class="diagram-marker" data-tt="st3" style="top: 355px; left: 580px"> </i>
<i class="diagram-marker" data-tt="st4" style="top: 218px; left: 865px"> </i>
<i class="diagram-marker" data-tt="st5" style="top: 278px; left: 905px"> </i>
<i class="diagram-marker" data-tt="st6" style="top: 343px; left: 860px"> </i>
<i class="diagram-marker" data-tt="st7" style="top: 418px; left: 880px"> </i>
<div id="st0" class="diagram-tt">
<h2>发布火车呜呜</h2>
<p>在项目巡游阶段,发布火车呜呜忙得不可开交,一路高歌猛进。</p>
<!--
<h2>Release Choo Choo</h2>
<p>During a project’s strolls, the Release Choo Choo is picking up steam and rumbling down the tracks.</p>
-->
</div>
<div id="st1" class="diagram-tt">
<h2>团队待办列表</h2>
<p>团队待办列表中包含了巡游过程中所有必须完成的内容。团队待办列表是由项目的技术主管创建的,他将任务分配给其他团队成员,同时,自己保留最好、最有意思的任务。</p>
<!--
<h2>Team Backlog</h2>
<p>The Team Backlog contains all the items that must be finished during the Stroll. A Team Backlog is created by the project’s Tech Lead who assigns tasks out to other team members while personally retaining the best, most enjoyable tasks. </p>
-->
</div>
<div id="st2" class="diagram-tt">
<h2>个人待办列表</h2>
<p>为了避免对共同责任的管理困难,每个团队成员都拥有个人待办列表,里面都是他/她自己负责的任务。如果某个团队成员没有完成自己的个人待办列表中的所有内容,那么他/她不要奢望可以从其他人那里获得帮助,因为其他团队成员会被要求提前开始下一次巡游。</p>
<!--
<h2>Personal Backlog</h2>
<p>To avoid difficult to manage shared responsibility, each team member has a Personal Backlog of tasks that he or she is personally responsible for. If a team member does not finish all items on his or her Personal Backlog, the team member should not expect help from other team members who are expected to instead jump ahead to work for the next Stroll.</p>
-->
</div>
<div id="st3" class="diagram-tt">
<h2>结对管理</h2>
<p>基于结对编程的成功,LAFABLE引入了结对管理,每个开发或测试人员都由两名经理监控着。每项任务都有两双眼睛盯着,每一个微观管理的机会都绝对不会被忽视。</p>
<!--
<h2>Pair Managing</h2>
<p>Building on the success of pair programming, LAFABLE incorporates pair managing, in which each developer or tester is watched by two managers. With two pairs of eyes on each task, it becomes extremely unlikely that an opportunity for micromanagement will go unnoticed. </p>
-->
</div>
<div id="st4" class="diagram-tt">
<h2>『差不多可以开始』的定义</h2>
<p>每一个团队都建立了『差不多可以开始』的定义。任何任务在满足这个定义之前,都不能被称为已开始。典型的定义内容包括:</p>
<ul>
<li>开发人员早上已经喝过咖啡了</li>
<li>开发人员已经阅读过最爱看的早间新闻</li>
<li>开发人员听说过这个任务</li>
</ul>
<p>一旦这些事情都完成了,开发人员就可以在每日站会上报告这项任务已经开始了。</p>
<!--
<h2>Definition of Mostly Begun</h2>
<p>Each team establishes a Definition of Mostly Begun. A task cannot be said to have begun until it complies with this definition. A typical definition of mostly begun includes:</p>
<ul>
<li>Developer has had morning caffeinated drink</li>
<li>Developer has read favorite internet morning news site</li>
<li>Developer has heard of the task</li>
</ul>
<p>Once these things are complete, the developer is able to report in a daily standup that work on the task has begun.</p>
-->
</div>
<div id="st5" class="diagram-tt">
<h2>『在我的设备上已完成』的定义</h2>
<p>一旦开发人员看到某个功能在他/她自己的设备上运行了一次,这个特性就可以被汇报『在我的设备上已完成』。在LAFABLE中,资深开发人员需要遵守更高的标准,只有某个特性在他们的设备上运行过多次,才能被称为『在我的设备上已完成』。</p>
<!--
<h2>Definition of Done on My Machine</h2>
<p>Once a developer has seen a feature work even once on his or her own machine that feature may be reported as “Done on My Machine.” In LAFABLE, senior developers are held to a higher standard and cannot report something as Done on My Machine unless it has worked multiple times on their machines.</p>
-->
</div>
<div id="st6" class="diagram-tt">
<h2>『差不多完成』的定义</h2>
<p>为了避免沟通问题,在LAFABLE中,团队会建立一个『差不多完成』的定义。一旦一项需求差不多完成了,就会被部署到生产环境中。这样会让用户参与到测试过程。这让用户觉得参与到产品开发过程中比拿到高质量的功能更重要,这样产品可以早早地交付给他们。</p>
<!--
<h2>Definition of Mostly Done</h2>
<p>In order to avoid communication problems, LAFABLE teams establish a Definition of Mostly Done. Once an item is Mostly Done, it is often deployed into production use. Doing so engages users in the testing process. Making users feel a part of the process is more important than giving them high quality features and so the product is delivered to them well before it should be.</p>
-->
</div>
<div id="st7" class="diagram-tt">
<h2>『这次我们真的认为完成了』的定义</h2>
<p>终于,功能达到了团队真的认为完成了的状态,真的,他们做到了。只是测试人员还没有看到这个功能,测试是稳定阶段才会发生的事。</p>
<!--
<h2>Definition of We Really Mean It’s Done This Time</h2>
<p>Finally, functionality reaches a state where the team really means it’s done this time. Really. They do. Except the testers have not touched it yet. That happens in Stabilization.</p>
-->
</div>
</section>
<section class="stabilization">
<img src="images/stabilization-train-cn.png" alt="Stabilization">
<i class="diagram-marker" data-tt="sb1" style="top: 155px; left: 380px"> </i>
<i class="diagram-marker" data-tt="sb2" style="top: 105px; left: 530px"> </i>
<i class="diagram-marker" data-tt="sb3" style="top: 125px; left: 700px"> </i>
<i class="diagram-marker" data-tt="sb4" style="top: 125px; left: 873px"> </i>
<i class="diagram-marker" data-tt="sb5" style="top: 370px; left: 760px"> </i>
<div id="sb1" class="diagram-tt">
<h2>测试人员初次接触系统</h2>
<p>所有的巡游都结束了,是时候让测试人员参与进来了!在LAFABLE中,所有的测试工作都是在漫长的稳定阶段进行的。不过别担心,也不是很漫长。根据LAFABLE的规则,团队花费的测试时间不能超过发现和修复所有缺陷所花时间的一半,从而确保您可以使用一个低质量的发布版本在市场上击败竞争对手。</p>
<!--
<h2>Testers Get First Look at the System</h2>
<p>After all Strolls are complete, it is time to involve the testers. In LAFABLE, all testing is done during a lengthy Stabilization phase. Don’t worry, though, it’s not that lengthy. LAFABLE rules dictate that teams spend no more than half the time required to find and fix all defects, ensuring you beat your competitors to market with a low-quality release.</p>
-->
</div>
<div id="sb2" class="diagram-tt">
<h2>产品拥有者的隐藏待办列表</h2>
<p>在LAFABLE中,团队被要求“拥抱变化”。产品拥有者通过故意将一些需求拖到项目后期才引入,来确保团队具备“拥抱变化”的能力。通过在项目后期引入重要的功能和实施架构上的变更,产品拥有者确保团队可以随时应对变更。</p>
<!--
<h2>Product Owner’s Hidden Agenda Backlog</h2>
<p>LAFABLE teams are told to “embrace change.” A product owner ensures a team’s ability to do this by deliberately holding some requirements back to be introduced later in the project. By introducing important functionality and architectural changes late in a project, a product owner can keep a team prepared for change at any time.</p>
-->
</div>
<div id="sb3" class="diagram-tt">
<h2>拳击手套</h2>
<p>在LAFABLE中,所有的沟通都是书面的,所有书面文档都需要进行解释,因此,产品拥有者、巡游主管和其他团队成员陷入了三方战斗。这场斗争关系到书面文档中各种形式陈述的最终解释权,因此,无论谁赢得了这场战斗并拥有了最终解释权,都可以对其他人说:“好吧,我知道你是怎样解读这种需求的,但我向你保证,那不是他真正的含义!”</p>
<!--
<h2>Boxing Gloves</h2>
<p>Because the written word is subject to interpretation and because all communication on LAFABLE projects is written, the product owner, Stroll Master and team members engage in a three-way battle. At stake is ownership of the intent of various statements in a document. Whichever group wins this battle and owns the intent will be able to say to others, “Well, I see how you could interpret this requirement that way, but let me assure you that isn’t what it means.”</p>
-->
</div>
<div id="sb4" class="diagram-tt">
<h2>快速砍需求阶段</h2>
<p>对于LAFABLE项目来说,最重要也是最后的阶段是,将那些不能给团队提供足够时间进行交付的功能快速移除出项目范围。</p>
<!--
<h2>Rapid Descoping Phase</h2>
<p>The important, final phase on a LAFABLE project is the rapid descoping of all features that could not be delivered in the ample time provided to the team.</p>
-->
</div>
<div id="sb5" class="diagram-tt">
<h2>发布火车呜呜</h2>
<p>在稳固阶段,发布火车呜呜其实是一列失事的火车。</p>
<p>火车失事啦!所有人在现实中惊醒,发布火车呜呜早已偏离了产品待办列表的轨道</p>
<!--
<h2>Release Choo Choo</h2>
<p>During the Stabilization phase, the Release Choo Choo is shown to be a train wreck.</p>
<p>Train wreck! The Release Choo Choo goes off track, sliding off the top of the product backlog and crashing into reality.</p>
-->
</div>
</section>
</main>
<footer role="contentinfo">
<p><a href="#who">Who’s Behind This?</a></p>
</footer>
</div>
<div class="remodal" data-remodal-id="who">
<a href="http://www.uperform.cn" class="mgs-logo"><img src="https://www.uperform.cn/wp-content/uploads/2019/08/logo-cr2.png" alt="UPerform Agile Academy"></a>
<p>LAFABLE.com is brought to you by Mike Cohn of <a href="http://www.mountaingoatsoftware.com">Mountain Goat Software</a>. On past April Fool’s Days, we’ve introduced you to:</p>
<ul>
<li><a href="http://www.waterfall2006.com">The Waterfall 2006 Conference</a></li>
<li><a href="http://www.scrummaster-fragrance.com/">ScrumMaster - The Fragrance</a></li>
<li><a href="http://www.cashforclunkerpcs.com/">Cash for Clunker PCs</a></li>
</ul>
</div>
<script src="//cdn.bootcss.com/jquery/1.11.0/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="javascripts/vendor/jquery-1.11.0.min.js"><\/script>')</script>
<script src="//cdn.bootcss.com/tooltipster/3.3.0/js/jquery.tooltipster.min.js"></script>
<script src="//cdn.bootcss.com/remodal/1.1.1/remodal.min.js"></script>
<script src="javascripts/main.js"></script>
<script>
var phoneWidth = parseInt(window.screen.width);
var phoneHeight = parseInt(window.screen.height);
var phoneScale = phoneWidth/980;//除以的值按手机的物理分辨率
var ua = navigator.userAgent;
if (/Android (\d+\.\d+)/.test(ua)) {
var version = parseFloat(RegExp.$1);
// andriod 2.3
if (version > 2.3) {
document.write('<meta name="viewport" content="width=device-width,initial-scale='+phoneScale+',minimum-scale='+phoneScale+',maximum-scale='+phoneScale+',user-scalable=no">');
// andriod 2.3以上
} else {
document.write('<meta name="viewport" content="width=device-width,user-scalable=no">');
}
} else { // 其他系统
document.write('<meta name="viewport" content="width=device-width, initial-scale='+phoneScale+',minimum-scale='+phoneScale+',maximum-scale ='+phoneScale +',user-scalable=no,">');
}
</script>
<!-- Google Analytics: change UA-XXXXX-X to be your site's ID. -->
<!--<script>
(function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new Date;
e=o.createElement(i);r=o.getElementsByTagName(i)[0];
e.src='//www.google-analytics.com/analytics.js';
r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
ga('create','UA-XXXXX-X');ga('send','pageview');
</script>-->
<script type="text/javascript">var cnzz_protocol = (("https:" == document.location.protocol) ? "https://" : "http://");document.write(unescape("%3Cspan id='cnzz_stat_icon_1253167390'%3E%3C/span%3E%3Cscript src='" + cnzz_protocol + "s95.cnzz.com/z_stat.php%3Fid%3D1253167390%26show%3Dpic1' type='text/javascript'%3E%3C/script%3E"));</script>
</body>
</html>