敏捷開發大家談（三）

（三） Crystal

Crystal是Alistair Cockburn提出的一組開發方法，分為Crystal Clear,Crystal Yellow, Crystal Orange和Crystal Red分別適用於不同的專案。專案可以按照參加的人員和重要性劃分。重要性根據專案中的錯誤引發的後果分為：
C Loss of comfort （某些不舒適）
D Loss of discretionary money (經濟損失)
E Loss of Essential Money (嚴重經濟損失)
L Life Critical (生命危險)
一個專案稱為C6說明參加人員在6人以下，重要性是C級，D20說明人員在6-20人，重要性是D級。

Crystal Clear適用於 C6,D6專案
Crystal Yellow適用於 C20,D20,E20專案
Crystal Orange 適用於 C40,D40,E40專案
Crystal Red 適用於 C80,D80,E80專案

Crystal Clear

適用於一個辦公室內的一個小組

角色有： sponsor發起人，任務下達者
Senior Designer-Programmer 高階設計開發人員
Designer-Programmer 設計開發人員
User 使用者
其中一個人是專案協調者(Project Coordinator)。Senior Designer-Programmer是關鍵人員

策略：
1 軟體的開發採用有規則的週期性遞增方法，每2-3個月提交（deliver）一個版本
2 使用里程碑(milestone)跟蹤進度（包括delvier和開發期間的重大決定）
3 自動迴歸測試（automated regression test）
4 使用者直接參與
5 每個release有兩個user viewings(使用者稽核?)
6 在上一個步驟足夠穩定（stable enough to review）時立即開始下一個步驟，儘量並行開發
7 在每個週期的開始和中間進行產品和過程調整

過程產品（指整個過程產生的所有產品，包括軟體和文件）
1 軟體釋放順序（release sequence）
2 使用者稽核的計劃
3 使用者案例（usecase）或需求描述
4 設計框架和必要的說明
5 介面草圖
6 基本的物件模型
7 執行程式碼
8 migration code
9 測試用例
10 使用者手冊
11 local matters有專案組決定：
上述product的摸班
編碼和使用者介面的標準
迴歸測試的標準和細節
其他文件
需要的工具：
版本控制工具
白板（最好可列印）


Crystal Orange

角色：sponsor 發起人
business export/usage export 業務專家
technical facilitator 技術專家
business analyst/designer 業務分析和設計人員
project manager 專案管理員
architect 系統架構人員
Design Mentor 設計指導人員
Lead Designer-Programmer 主要設計編碼人員、
Other Designer-Programmer設計編碼人員
UI Designer 使用者介面設計人員
Writer 文件寫作人員
Tester 測試人員

策略：
同Crystal Clear (週期可以為3-4個月)
過程產品：
需求文件
計劃
狀態報告

基本物件模型
外部介面標準
使用者手冊
原始碼
測試用例
migration code
local matters 同Crystal Clear


（四） The Agile Alliance

敏捷聯盟是17位不同敏捷開發方法的提倡者共同成立的，目的是推進敏捷開發方法的研究和應用，他們並不要求強制使用某種開發方法，而是提出了敏捷開發的幾個核心價值和基本原則：
core value:

Individuals and interactions over processes and tools
個人和交流重於過程和工具
Working software over comprehensive documentation
正在執行的軟體本身重於複雜的文件
Customer collaboration over contract negotiation
與客戶的溝通和交流重於使用合同約束客戶
Responding to change over following a plan
對變化的快速響應重於跟隨計劃

principles

1 最高目標是通過快速的和經常的釋出軟體滿足客戶的需要
2 提交軟體的週期為幾個星期到幾個月
3 產生正確的軟體是衡量進度的首要標準
4 主動接受需求的改變而不是拒絕
5 商務人員和開發人員工作在一起
6 個人必須有動力，要創造環境支援他們的要求，信任他們
7 最有效的交流方法是面對面的交流
8 最好的結構，需求和設計來自於自組織的團隊（self-organizing team），允許任何人提出想法和建議
9 持續改進設計和編碼
10 鼓勵正常工作，減少長時間加班
11 保持簡單，減少不必要的部分，認識到簡單的設計比複雜的設計更難（simple design is harder to produce）
12 定期調整過程，獲得更高效率

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-269188/，如需轉載，請註明出處，否則將追究法律責任。