Imagine
Imagine there's no requirements. It's easy if you try
Just a bunch of coders, reachin for the sky
Imagine all the people, coding for today
Imagine there's no schedules. It isn't hard to do
No silly project deadlines, no one supervising you
Imagine all the people, coding hand in hand
You may say I'm an extremer but I'm not the only one
I hope someday you'll join us and make coding lots more fun.
Imagine oral documentation. I wonder if you can
No need for UML diagrams. Just words passed, man to man
Imagine just refactoring, playing in the sand
You may say I'm an extremer, but I'm not the only one
I hope someday you'll join us and make coding lots more fun.
想象
想象如果没有需求。你的尝试就会觉得容易。
只要几行代码，你就能到达天空
想象所有的人们，为今天而编写代码
想象没有时间进度，做起来也不会太难
没有该死的项目截止日期，也没有人监督你
想象所有的人们，手牵手一起编写代码
你也许会说我是个极端分子，但我并不是唯一的一个
我希望有一天你能加入我们，充满乐趣编写许许多多的代码
想象一下口头文档，我怀疑你是否能做到
不需要UML 视图，只需要从一个人到另一个人的语言传递
想象只需要重构，如同在沙滩上玩耍
你也要说我是个极端分子，但我不是唯一的一个
我希望有一天你能加入我们，充满乐趣编写许许多多的代码
这是非程序员第49期的文章爱丽丝漫游用例奇境里引用的一段歌词，出处在Songs of the Extremos ,很有意思的软件之歌，如果知道原曲旋律，唱起来一定很爽口....比如> The Long and Winding Thread...
回到xProgrammer上，今天看了若干期，在差不多开始厌倦于那些枯燥，抽象，充斥各种莫名术语，行文干巴巴或纠缠不清的文案时，突然看到爱丽丝漫游用例奇境这一篇，妙趣横生，感觉蛮不错的。
爱丽丝说：“我无法断定哪种情况更加糟糕：陷于‘分析瘫痪’当中，还是在理解需求之前直接跳到编码部分。我多希望有一种介乎两者之间的简单方法啊。”
也许爱丽丝的问题并没有一个彻底的解决方法(没有银弹:P），或者没有人能将解决方法描述的尽善尽美，至少，在CMM/RUP...等貌似重型方法论大行其道，XP/“代码即设计”的极端回应之后，终于有人开始如何思考有效的缩短“做什么”和“怎么做”之间的间隙了。
PS:RUP是否重型方法论，其实也是有争议的。在xProgrammer的37期，有一篇七步搞死RUP,嘟嘟囔囔的痛斥瀑布，宣扬迭代，给RUP申冤，认为在RUP中引入瀑布思想，过度和不适当的设计，误解RUP，才使RUP冒出BAD SMELL。以下为搞死RUP七步简单笔记：
第一步:加入瀑布思想
有些东西应该象建造房屋那样去构建设,但软件不是
初始化阶段探索少量但重要的需求(10%)获得范围,风险尺度,
大部分需求是在细化阶段探索,此阶段迭代的构建体系结构和解决技术风险
迭代周期长度是2~6周.迭代方法允许我们边学边走.固定成本问题
第二步:将RUP作为重型的，预见性的过程去应用
重型过程的特征是刻板,繁琐,形式化而缺乏人性化
RUP并非重型和预见性的,其本意是使用轻量,敏捷和适应性的过程精神
适当创建RUP活动和工作
不存在所有迭代的详细计划
第三步 避开对象技术能力
对于技术领域来说,熟练的对象技术开发人员和采用RUP或者任何过程,后者是相对次要的因素
蓝领工人理论并非所有项目都通用
第四步:低估适应性迭代开发
应该在组织和项目层次上拥抱变化,
迭代开发的思想是要在只完成了部分需求和设计的时候,快速开始编程,这样做是为了得到实际的反馈
迭代开发的核心是基于反馈进行调整
开发者和客户是合作伙伴关系
开发人员不理解系统要做什么->加强需求管理
复杂的控制流或难以理解的行为->加强用例管理
技术方案是否新颖或复杂-> 进行体系结构优化设计
第五步避开深谙迭代开发的顾问（如果项目有顾问的话）
第六步:轰轰烈烈的采用RUP
形式主义，填鸭式的推行RUP
第七步采纳（以RUP名义的）错误的建议
