团队交付【译】敏捷 vs 伪敏捷

在写这篇文章之前，xxx已经写过了几篇关于改团队交付主题的文章,想要解了的朋友可以去翻一下之前的文章

    在2001年2月11日至13日，在犹他州Wasatch山脉中雪鸟滑雪胜地的小屋中，17个人聚在起一流交，滑雪，松放，并实验找到独特点。从本次议会上告竣的是一个有所与参者签订的

    迅速软件发开宣言

    ：

    体个和互动

 高于 程流和具工

    作工的软件

 高于 详实的档文

    客户协作

 高于 合同判谈

    响应化变

 高于 循遵划计

    

    伪迅速宣言

    

    

    交付的速度

    

     高于 交付的品质

    它的作工原理是这样的？用户故事积存在务任表列(Backlog)里并排上优先级，但特定的用户故事累积表列有一个目标布发日期，这意味着他们都将被起一布发， 而不是单独布发。采用冲刺(Sprint)管理发开进程中计设，编码和单元测试阶段， 另在布发之前安排一个集成统系测试，测试“在围范内的”用户故事有所已实现的功能。

    逐日一道理
即使青春是一枝娇艳的花，但我明确，一枝独放永远不是春天，春天该是万紫千红的世界。 即使青春是一株大地伟岸的树，但我明确，一株独秀永远不是挺拔，成行成排的林木，才是遮风挡沙的绿色长城。即使青春是一叶大海孤高的帆，但我明确，一叶孤帆很难远航，千帆竞发才是大海的壮观。

    (It works like this. User stories are prioritized into a backlog but there is a targeted released date for a cumulative list of specific user stories, meaning they'll all be released together instead of individually. Sprints are then employed for the design, code and unit test phases of development but an integrated system test is performed prior to the release of all the completed features for the "in-scope" user stories.)

    瀑布地规划和布发间时表，迅速 / Scrum地计设和发开。

    (It's waterfall planning and release schedules with agile/scrum design and development.)

    

译者注：

    迅速是一个热门、有争议的题问，文中观点仅为原文作者观点（当然不除排我的错误解理）。去年看到这篇好文，一直想翻译下，跟大家起一分享分享，由于种种原因，直到今天才搞定，虽然很晚了，也算了却一桩心愿。

    此文源来一个PDF，格式自己用HTML实现，可能会有些题问。如果现发请大胆指出来。翻译得欠好地方，也请指正。

    原PDF上的间时: 10/2/2012

    原文连接：http://www.softwaretestpro.com/Item/5727/Session-404-Agile-vs-Fragile-A-Disciplined-Approach-or-an-Excuse-for-Chaos---Brian-Copeland/Software-Test-Professionals-Conference

文章结束给大家分享下程序员的一些笑话语录： 问：你觉得让你女朋友（或者任何一个女的）从你和李彦宏之间选一个，你觉得她会选谁？　　
　　答：因为李艳红这种败类，所以我没女友！