演讲主题：那是鸟，还是飞机？不，那是超人！/ It's a Bird; It's a Plane; No, It's Superman!
地点：宴会厅
时间：9月12日（星期六），9:00～9:50
简介：
这是20世纪50年代电视剧《超人》的片头口号，反而让我们想起了今天的敏捷运动。无论是程序员还是高管，人们都把目光投向了敏捷，而是试图理解其神奇效果背后的推动原因。在这个演讲中，我们将会揭示敏捷的一些外在因素，并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看，我们认为：工具不能让你变得敏捷（尽管有所帮助），管理体系也不能让你变得敏捷（也会有所帮助）。敏捷的成功，植根于士气高涨、充分授权的工作者身上，他们能够以不同以往的方式思考问题。
我们的讨论内容会涵盖创建上述环境所遇到的挑战，还有敏捷实践如何强化这样的环境并创建可持续的生产力改进。我们还会讨论从工作职位到团队角色发生的转变、向个人分配工作遇到的两难困境、“教练”角色的失败，以及项目经理职责的根本性转变。与以往不同的程序员工作衡量指标，以及这对于项目规划和风险管理带来的对应潜在影响，这也将是我们讨论的话题。
最后，我们将会宣布：敏捷不是从有序转向混乱，实际上，它是40年来最为严格的开发方法论。我们将使用从真实项目中收集的实际管理度量数据，以之证明敏捷之严格性。
This opening slogan from the 1950's TV show reminds us of the Agile movement today. From programmers to executives, people are pointing to Agile and trying to understand what is creating those amazing results. In this talk, we will expose the aspects of Agile that are the superficial aspects, and focus on the underlying reasons for success. Drawing from case studies and real project experiences, we claim it is not the tools that make Agile (although they are different); it is not the management system (again different). Rather Agile success is rooted in motivated, empowered workers thinking about problems differently.
We discuss the challenges in creating that environment, and how the Agile practices reinforce the environment and create sustained productivity improvements. We will discuss the shift from job titles to team roles; the paradox of making assignments to individuals; the failure of the "coach" role; and the radical shift of responsibilities for a project manager. We will discuss a different taxonomy of measuring programmers, and the corresponding implications on project planning and risk management.
Finally, we will claim that Agile is a move from order to chaos; rather, it is the most rigorous development methodology of the last 40 years. This rigor will be demonstrated by actual management metrics collected from real projects.
演讲主题：成功敏捷背后的隐秘设想
地点：房间待定
时间：9月12日（星期六），13:10～14:00
简介：
自打20世纪70年代以来，人们普遍认为：在开发阶段后期发现一个bug的成本，将会十倍乃至百倍于在早期发现该bug的成本。基于这种看法，人们创建了与架构和设计相关的体系，同时附有大量文档；代码复查被普遍使用，还配备了专职测试团队。可敏捷似乎对这些需求视而不见；实际上，敏捷声称要推迟决策，从而避免招致十倍乃至百倍的惩罚。
有一个常犯的错误，即使是敏捷的实践者也不能避免，就是认为自动化测试套件可以起到重要作用。敏捷要想取得真正的成功，测试是很重要的因素。但我们认为测试并不足以保证敏捷之成功。实际上，敏捷成功的真正原因，在于它能够让人们以支持变化的代码风格进行开发。这才是不为人道的、成功敏捷背后的隐秘设想。
我们的行业中还存在另一个悖论，认为要想编写易于变更的代码，最好的方式就是抛弃许多习惯用法。我们会检视这些习惯用法，看看它们如何破坏你的软件资产，再一起看看有哪些不破坏现有代码灵活性的变通做法。十多年前，人们制定出一些课程用以传授上述风格，这将是我们最终讨论的话题。
Conventional wisdom from the 1970's held that the cost of finding a defect late in development would be 10- or 100-times the cost of finding it early. Based on this wisdom, systems for architecture and design were created with associated documentation; code reviews were introduced; dedicated testing teams were put into place. Agile seems to ignore these needs; indeed, Agile claims to be able to defer decisions without incurring the 10- or 100-times penalties.
A common mistake (even among practitioners of Agile) is that the suites of automated tests make the difference. Tests are an artifact of the real reason for the success of Agile. We will argue that tests are not sufficient to ensure success. Rather, the real reason for Agile success is that code is written in a style that supports change. This is the secret assumption of Agile that is rarely articulated.
In another of the paradoxes of the industry, the best way to write code that is easy to change is to throw out many common idioms. We will review these idioms, how they destroy your software assets, and the alternatives that don't compromise the flexibility of the code base. Finally, we will discuss the curriculum developed over 10 years ago to teach this style.
-----------------------------
InfoQ中文站上的相关内容：
1、切分Backlog，产生最大效益
2、使用投标申请书（RFP）聘雇敏捷团队
3、欢迎提名2009年度Gordon Pask奖项获得者
4、环境无关的环境
5、《架构师》创刊号
>> 更多内容，请移步InfoQ中文站敏捷社区。