Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 十二月 2016

從敏捷建模看Google Sprint

leave a comment »

.

現代的工程師寫程式的方式太隨性了! 不禁讓人有些懷念那種命令式的開發方式;它硬性的規定你一定要先作完這個才能進行下一步(其實這一點,還蠻適合一些自主性差或太衝動愛自幹的工程師)。但在敏捷當道的時代,人們太容易在還沒有弄清楚要做什麼之前,團隊裡就已經有工程師自以為是的偷偷起跑了,後遺症當然是返工跟無形間所增加的溝通成本。這一點;會讓人懷疑起,是不是所有的工程師都適合採用敏捷開發呢?

 .

我想說的是,建模優先: 談一下「敏捷建模」

我習慣在動手寫程式之前先畫張草圖,在草圖上嘗試著對相關的功能元件進行命名,然後試著標示它們的輸入及輸出屬性,接著再把它們串起來,然後進行修修改改的補強動作,最後在劃一個大框框把它們通通包起來。在隨後的程式撰寫中,這張圖示將一直映射在我的腦海裡,我會隨興的在程式碼中修正它,但通常不會再回去修改圖了,而最後在終於能夠成功通過測試之後,它便成了最終的模型了。如果有機會在Demo meeting時作展示的話,它會進一步成為powerpoint的產物,然後就成了可以交付與公開展示的文件了。

.

FullSizeRender.jpg

手繪程式功能模型草圖

.

敏捷化的建模,可以是一張草圖,一些描述恰恰好的使用者故事伴隨著淺顯易懂的示意圖。

.

一個感想,為了敏捷而過度的忽略了一些好的開發行為

Modeling「建模」這個字言似乎成了軟體世界的禁忌辭彙,有一段時間沒聽人提起它了。即便聽到有人說到建模時,也總是語帶保留戰戰兢兢的作了一堆附帶的說明,深怕被誤會要大張旗鼓的製作文件或花上很多時間來建立模型。這可能是敏捷初期大家害怕被誤解為又要來CMMI這一套複雜的開發作業所致吧!但老實說;在開發作業前的建模是讓大家能有一致認知的一種重要行為,是非常有價值的動作,只是要能兼具模型的價值與平衡花多少時間來建立模型的投資時間,它是否值得這麼做呢? 則是依你自己如何來實行所造成的(敏捷是一種在務實不過的精神了,減少不必要的浪費經常是第一考量)。

【 對 Modeling 的一些誤解

  • 模型 = 文件

  • 可以在一開始就把什麼都想清楚

  • 建模意味著重量級的軟體開發過程

  • 必須凍結需求

  • 設計是刻在石頭裡的

  • 必須使用Case 工具

  • 建模是浪費時間

  • 世界繞著數據建模轉

  • 開發人員都知道怎麼建模

》參考自《敏捷建模》原書的 第九章 培養敏捷文化。(原本想一一做說明的,但怕見文章變得臭又長,就刪掉了)

.

Google sprint 就是快速建模

年前看了Google為創投所作的五日 Sprint(書名: Google創投認證!SPRINT衝刺計畫,這一陣子Google開發團隊出了一系列的好書,幾乎都可成為教材,感恩了!), 這五天是: 第天,以終為始,確定明確目標。第天,檢視舊點子,畫出方案草圖。第天,決定,選擇最佳方案。第天,模擬,只需要做出逼真的外觀,作原型。第天,回饋,小數據,詢問五個人,問對問題吸取教訓。巨觀的來看它,在這五日裡,團隊只有一天是花在實作上,其他時間都只是在建模!我想這可稱它為精實建模或是敏捷建模呢?!

於是就上網尋找了一下,結果找到的是《敏捷建模:极限编程和统一过程的有效实践

.

book.png

Scott W. Ambler 2002, March

.

原文: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process 2002年三月出版的老書(簡體版已經買不到了)。這是一本唯一掛上敏捷字眼,然後大談建模的書了,書中提到:當一個模型能夠滿足以下條件時,它就是足夠好的:

  •  滿足了創建者的目的

  • 易於理解的

  • 足夠精確的

  • 有足夠的一致性

  • 是足夠詳細的

  • 提供專業的價值

  • 是盡可能簡單的

.

基本上;《Google Sprint》完全符合上述的條件,因此可說成是一種敏捷建模,一種MVP式的敏捷建模。

.

敏捷模型的定義

敏捷建模是一個達到了它的目的而且僅此而已的模型。它能夠被所針對的聽眾理解,它簡單、足夠精確、一致和詳細,對創建和維護敏捷模型所做的投資提供了職級的價值。

.

這是Scott Ambler 對敏捷建模的定義詮釋,真是低調了,其實程式碼本身就是模型,程式設計人員在開始 coding 的時候模型就在持續地累積,由糢糊到逐漸清晰,由一個功能的完成到驗證,這就是在建模啊,他依循著程式設計師對問題的認識,然後再逐步的把解題方法實作出來,這幾個實踐的步驟,無一不是依靠自己對問題的認知與腦筋裡的解題模型一步一步來達成。因此,模式是解題前的基礎,這一點一直是敏捷開發乏人問津的一塊,或許是擔心又走回 CMMI 的長時間文書作業的惡夢,但這回精實創業的開發方法,所謂的 MVP 或是 Google Sprint 的做法,正好可以讓大家把注意力又拉回運用建模來解題的基礎上。敏捷開發在需求的描述上使用者故事,基本上也是一種建模,而且他兼具了足夠的抽象度,是一種絕佳的建模,只是少了圖形化的全貌視角,這一點幸好可以用使用者故事地圖(User story mapping)的技巧來補足它。

.

小結

逐步漸進、小增量的建模是敏捷化團隊不可或缺的行為,一張圖成就了溝通時的最佳利器。它既可讓創意者將腦子裡較凌散的觀念塑造成一個較完整的雛型,又可以讓團隊透過視覺化來迅速理解,進一步開啟討論的空間,實質的提供了快速的形成共識的機會。要敏捷化;怎能不做呢?!

建模的目的是為了能夠提高開發的品質和速度,同時能夠避免過度簡化和不切實際的期望,最後造成了過多的返工。尤其是進行團隊協作時,一個圖形模式可以迅速地造成大家一致的認識,是絕對有價值的。敏捷建模(Agile Modeling,簡寫程 AM) AM是有效的,而且在這個精創時代也又開始實行起來了(Google Sprint就是一個好例子)。AM告訴你:要使你的專案的投資最大化;應當有清晰的目的以及需要提供團隊在需要時要建立模型或文件(它可能是少數提到敏捷文件的地方,註1);運用合適的方式(工具)來記錄手頭的情形;不論何時都盡可能創建 簡單的模型。敏捷很好但千萬不要忽略了建模。寫程式不可缺少的建模行為。

.

解題之前請先建模

今天的模式早以被定位成溝通的中介質,但如果工程師只有一個人的時候,建模的價值,便成了對問題的更深入的認知了。

.

註1 敏捷文件 (Agile Documentation)

Agile 對文件的要求是一句 Just Enough 就好了。但是在實作時,工程師總是急著向前衝,大家總把作文件當成是停下來的行為,因此就是跑了一段很長的路程,然後沒有留下多少紀錄,這是最糟糕不過的。因此有很多團隊就開始把測試案例轉換成基本文件規範(這是好的一種現象),但其實筆記才是重點,一種紀錄開發過程重要事實的筆記紀錄,可以讓我們清晰看到或迅速回憶的筆記可能是最務實的做法,因為3個月以後第一個回過頭來看程式的人員,可能就是程式設計師自己了。所以一份讓自己迅速回憶相關知識的筆記可能才是文件記錄的真正重點,例如: 視覺圖像紀錄(Sketchnote)應該是這個時代的脈動之一吧?! (參考: Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects,2003)

.

上課時,老師發現有

同學在筆記本上進行塗鴉時,應該制止嗎?

.

廣告

Written by ruddyllee

2016 年 12 月 12 日 at 11:54:41