槓上敏捷宣言了！在推動敏捷過程中我們失去了軟體設計！ -zdnet

banq發表於2020-09-07
敏捷

根據設計倡導者西蒙·布朗（Simon Brown）的說法，軟體設計的過程通常始於混亂的白板上，這種白板無法使任何人做好任何準備。是時候進行更多的前瞻性思考了。（banq注：敏捷團隊圍著一張白板畫一些對業務粗淺理解，隨著自己認識加深，這個過程會反覆重來，學習理解業務的成本很高！成本高只好用加班時間抵充）
在敏捷時代，太多的軟體設計人員害怕過度設計其應用程式。結果，許多軟體團隊放棄了架構思想，前期設計，文件，圖表和建模。“在許多情況下，這是對過去繁重的流程臃腫的一種下意識的反應，而在其他情況下，則是對《敏捷宣言》的誤解和誤用。”
這就是開發人員軟體體系結構的作者西蒙·布朗的話，他在Yow的一次引人注目的演講中指出這點。在大會上，更多關於應用程式的思考被提升到軟體建立的白板階段。順便說一句，他還不認可白板，並指出白板經常導致混亂或難以理解的草圖。“作為一個行業，不幸的是，我們已經停止教授[軟體設計]。如果您去問團隊中的人'您如何設計軟體？'，他們會迷迷糊糊地說，'好吧。 ，我們使用白板。” 您是否從白板上獲得程式碼？您將白板用於什麼？他們會說，“我們正在繪製圖片，方框和線條。” 
Brown孜孜不倦地倡導更豐富的前期設計規劃，包括使用諸如採用統一建模語言（UML）之類的工具，這有助於為架構設計提供標準化和流程驅動的方法。他說：“更豐富的設計圖導致了更豐富的設計討論。” 團隊成員和業務合作伙伴不必問諸如“該箭頭是什麼意思？”之類的問題。“這是Java應用程式嗎？” 他說：“這是一個整體的應用程式還是一組微服務。” 相反，討論應該集中在交付給企業的功能和服務上。
布朗說：“沒有人談論的是您必須進行設計才能進入軟體版本1.0!” “您必須奠定一些基礎，以便為迭代提供足夠的起點，並在此之上發展。而這正是我們所缺少的。”
許多軟體設計團隊都將前期設計保持在最低限度，假設隨著事情的進展，細節將在敏捷過程中充實。布朗說這是錯位的思維，設計團隊應將更多資訊納入他們的前期設計中，包括所提議的技術型別和語言。
大多數有關敏捷的文獻說：沒有大設計！。但是人們會錯過'大'這個詞，不是沒有設計，而是沒有大的設計！
同樣重要的是：考慮到將敏捷宣言拼湊在一起的那些牛人（暗指Martin Fowler等敏捷宣言簽署者）當時已經有很多從業經驗，現在我們不可能擁有同樣經驗，環顧我們四周都是由相對年輕的人組成的團隊；如果我們將這些經驗豐富的敏捷宣言簽署這從軟體中剝離出去，帶入他們到他們不熟悉的一個行業（banq注：讓Martin fowler去做建築設計、或做時裝設計或做網頁設計），他們還會談論這些工作“只是實驗和重構？” 

參考：幽默：兩個小時事件風暴建模和兩個月編碼哪個更敏捷？

相關文章