Ruddy Lee 分享空間

Emergent Design 演化設計

活文件 Living Document

leave a comment »

只要你開始在意你所製作的文件是否是正確的時候,你就已經朝向活文件前進了一大步。

.

agile development

敏捷文件的製作範圍,就是跟上圖中有關的所有事項

.

敏捷開發的文件需求 — 以文件的正確性為前提

敏捷開發為了早期推廣時,刻意與大量文件製作的傳統開發方法作明顯的區隔,因此並未對文件的製作提出明確的需求,但是這並不表示它不重視文件,「要求文件的正確性」是敏捷最基本的精神之一。一般而言敏捷開發至少需要三種基本必備的文件:1.需求說明文件: 作需求說明使用。2.系統概述文件: 便利系統維護、運作採用。3.活文件: 協助程式運作並提供便利維護及自動化測試的基礎文件。其中的1、2 項都是屬於概述型的文件,也就是屬於較少做細節描述的文件,比較不怕失去正確性。但第三項的活文件是甚麼呢? 其實是因為程式設計師很少有人會因為修改了程式,就跟著去修改相關的文件的習慣,這一點造成了文件的正確性遭受到質疑,因此在設計上便有了會自動更新或要求必須同步的文件誕生了,這種會持續更新型態的文件就被稱為「活文件」,請看以下的說明。

.

有關活文件的參考資料如下:

  1. Specification by Example 中文版:團隊如何交付正確的軟體, By: Gojko Adzic 所著。
  2. Executable Specifications with Scrum: A Practical Guide to Agile Requirements Discovery , By: Mario Cardinal 所著。
  3. Fit for Developing Software: Framework for Integrated Tests ,By: Ward Cunningham
  4. Agile Documentation By: Andreas Rüping
  5. Slide for Agile documentation

.

在政治上;所謂的活文件 Living Document意思是說,對基本法的理解,應隨着時間及處境而變化,不應拘泥於「原意」或「文字」的表面意思。意思是指對文字的詮釋是隨著時間、處境而跟著改變的。

.

在軟體上;一份活的文件或動態文件就是一份不斷修改和更新的文件。

A living document or dynamic document is a document that is continually edited and updated.  (wiki)

.

運用活的資料檔 Living Data解決重複或複雜的架構問題

程式與資料本來就是一體的,只有當資料是正確的時候,程式才可能完成它的任務。架構師尤其以歡正確的去運用資料結構,因為它常常可以大量減輕程式邏輯的複雜性。為此我們常常稱這種可供動態運用的資料為活資料Living data

記得許多年以前在做程式架構設計時,我們經常運用活的資料檔(Living Data,它不只是Configure 或 Setup 的資料檔,通常它還會包括一堆欄位定義、功能呼叫、欄位檢核程式甚至是動態功能呼叫之類的規範)用來做為程式執行時的規則依據。這麼做除了可以降低程式普遍的複雜性之外,也能讓維護作業變得簡單些(其中尤以Silverlight 可能是最經典的範例,它的架構非常適合做動態程式碼的呼叫;因此一直到現在還在許多地方被持續運用著)。

而這類程式架構的設計方式,並沒有一個特定的名稱,一般我們都會稱之為Wizard Style 或是 Code Gen 的架構設計方式。例如: 運用在設計銀行的分行交易,就是針對某一類相似性較高又量大的重複設計時,我們經常就會這麼設計。它們的效果好得很,可以大量的減少了維護時的負荷。

.

儲存在Excel 的工作表裡  — 活文件 Living Document

許多程式設計師喜歡把應用程式的欄位資料或檢核程式儲存在Excel 的工作表單裡,用來提供主程式運行時能夠即時動態載入的彈性運作方式,然後在離線時再另外用其他程式來維護它。這種做法好處多多,讓程式的維護作業更明確化許多。而且可以適當的降低交接資料或新人銜接工作時的門檻,是一種對付銀子彈(專案來不及時增加人手反而增加負荷)的好方法之一。我非常推廣這種作法,如果運用敏捷的觀點來看它,則可以產生所謂的「活文件」,也就是讓程式與文件同步的一種工作方式。

但是你會懷疑,這份活文件到底是不是真正正確的文件,這也就是後來大家都把測試給加進來的原因。讓測試與文件綁在一起,自然能夠保證程式與文件的同步性了。這一類型的作法大致可分成二個門派,一個是由Ward Cunningham領軍的古老 FIT Framework Integrated Test ,另一個則是BDD: Behaviour Driven Development 。採用哪一種方法都成,但這二種方法也都有它的適應性跟缺點,當用得太深了的時候,都可能會因為增加的大量(文件)維護作業而容易發生越俎代庖的現象。

.

未來對需求的描述將變得更重要

無疑的在雲端的時代裡,對需求的正確描述將變得更重要。但不可諱言的是,雖然我們都努力地想把需求直接就變成可執行的程式碼(所以上面那幾本參考書籍才會那麼命名),但老實說;還是有蠻長的距離,還有很多地方可以再繼續努力的。而對於現在而言,至少我們可以藉著活文件的運用,朝著讓程式碼變得更簡單的方向去努力。

.

簡潔才是王道

Code Simplicity 的作者Max Kanat-Alexander曾經寫道,軟體設計的三大誤區:

1.  編寫不必要的程式碼。 2. 程式碼難以修改。 3. 過分追求通用。

其中第三點是採用活文件作架構設計時最容易犯的毛病。設計師往往一頭熱,常常盲目的擴充一些好用的架構或框架,而忘了適用就好的準則,過分追求通用而忘了軟體很少會有所謂的「放之四海皆準」的原則。

.

結論

如果你準備要製作活文件的話, 首先;跟開發專案一樣,先設定範圍。針對明顯而有限的範圍製作活文件是獲取成功的基礎條件(對程式設計人員;我會由Living Data開始。測試人員由測試案例開始,非程式設計人員由業務需求概述開始…)。然後試著找到核心點,由核心點開始往外擴張是避免失去焦點的好方法,就從這裡開始吧!

但是不要只顧著作文件,千萬不要忘記:  為何要製作文件呢?其實最根本的問題是溝通,而不是文件。

The fundamental issue is communication, not documentation.

– Agile/Lean Documentation

.

0 communication

@「 溝通 」是團隊戰力能否發揮的基礎條件

.

廣告

Written by ruddyllee

2015 年 07 月 05 日 於 17:29:34

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: