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名義的）錯誤的建議
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=385849
文章來源于領測軟件測試網 http://www.kjueaiud.com/
