學校課程/敏捷方法

敏捷方法 - 學習 (Agile Method)

contents

  1. 1. 敏捷開發
    1. 1.1. 重點筆記
      1. 1.1.1. XP 極限開發
        1. 1.1.1.1. 簡介
        2. 1.1.1.2. 行動
      2. 1.1.2. Lean Development 精實開發
      3. 1.1.3. SCRUM
        1. 1.1.3.1. Role 主要角色
        2. 1.1.3.2. Meeting 會議形式
        3. 1.1.3.3. Artifacts 神器
    2. 1.2. 期中考古題
  2. 2. Reference
    1. 2.1. Websites
    2. 2.2. Friends

敏捷開發

重點筆記

XP 極限開發

簡介

溝通為其特色，某方面來講有過於親密的傾向。
如果程序猿們按照 Pair Programming 的方式運行，被當成基佬們也不意外。

1. Fine scale feedback  細部回授
    * TestDrivenDevelopment via ProgrammerTests and CustomerTests (were UnitTests & AcceptanceTests) 
    * PlanningGame 
    * WholeTeam (was OnsiteCustomer) 
    * PairProgramming 
2. Continuous process rather than batch  非批次流程
    * ContinuousIntegration 
    * DesignImprovement (was RefactorMercilessly) 
    * SmallReleases 
3. Shared understanding  分享所知
    * SimpleDesign (DoSimpleThings, YouArentGonnaNeedIt, OnceAndOnlyOnce, SimplifyVigorously) 
    * SystemMetaphor 
    * CollectiveCodeOwnership 
    * CodingStandard or CodingConventions 
4. Programmer welfare  員工福祉
    * SustainablePace (original name: FortyHourWeek)
  • 強調團隊溝通，確保每一步都是正確且穩定。
  • 強調個人思考，藉由溝通引出每個人的思考。
  • 測試驅動開發，先有測試資料，才開始撰寫。

對於台灣人

  • 強烈抨擊文件不是首要任務，英文不好，還不如不要用英文撰寫。
  • 英文文件能提高溝通力？請自行反思。

回過頭來，看待敏捷

  • 文件越簡單越好，花在寫文件的時間可能太多。
  • 同一室工作，最多 10 人一室，以免過度干擾。
    • 溝通滲透－簡單說就是偷聽長知識。
    • 惡性溝通滲透－聽到沒有用的資訊。
  • 駐點客戶的存在
    • 與工程師溝通，確保需求符合，常駐程序猿們的公司，改完馬上可以詢問滿意。
    • 通常專案的費用，額外含駐點客戶員工的薪水。(畢竟不常在原公司)
  • 定期交貨，一分錢一分貨
    • 功能做到哪就給多少錢，風險分散。
    • 如果做失敗，可以即早治療。
  • 程序自動化測試
    • 採用連續整合 (可以去 CI 網站 看看)
    • 每天修改的程序，隔天起來就能查錯。

行動

  • 請參閱考古題條目，將會給你更多的執行項目。

做了一點小修改，馬上就能得到回饋，所以能敏捷。
敏捷不是快速，敏捷不是力量。雖然有點慢，但是穩定運作，避開不好的危機。
我們不是工廠！不是重複做相同的事情。

Lean Development 精實開發

1. Eliminate waste 根除浪費
2. Amplify learning 大量學習
3. Decide as late as possible 盡晚決定
4. Deliver as fast as possible 盡早交貨
5. Empower the team 授權團隊
6. Build integrity in 整合思維
7. See the whole 眼觀全局
  • 另一種軟體開發方式
  • 敏捷開發－共同向善，督促所有人進步。
  • 精實開發－剔除累贅，改善開發。

WHEN YOU ARE AGILE, YOU GET LEAN. 敏捷之後 自然瘦身

SCRUM

用以輔助 XP 極限開發的一種敏捷管理法

Role 主要角色

  • Product Owner
    • 產品負責人，負責在有限的時間和預算將產品做到最好。
    • 下面的人全照他的想法建造產品。
  • The Team
    • 團隊必須有產品製造過程中的技術。
    • 在每一個 Sprint 中，產出或增加軟體潛力。
      • The Team Resource
        開發前先餵點飼料，給予團隊之後會需要的資源。
      • Manual
        每一次 Sprint，制定軟體確切的模式(樣貌)，這比寫文件更困難。
  • Scrum Master
    • 一個人管理和疏通所有程序猿、確認生存狀況以及環境障礙。
    • 程序猿通常有溝通上的障礙，需要有人引導。
    • 確認每一個人的進度，並且不會某些人有卡在相同問題(愚蠢狀況)。

Meeting 會議形式

  • Sprint Meeting
    • 產品負責人將會釋放出新的功能項目。
    • 團隊要根據技術去完成它們。
    • 在會議結束後，確定每個程序猿都知道如何去實作。
    • 會議兩周一次。
  • Sprint Demo
    • 開會期間，展示上次 Sprint 要求完成後的結果。
    • 同時檢查是否合乎預期，以及當初是為了造什麼來的。(工作不飽和，可能造出非物。)
  • Sprint Retrospective
    • 回顧和檢討，改善開發環境，可能是採用開發工具替換。
    • 或者是會議、討論形式的改善。
    • 最後同意並確定檢討後遵守的條目。
  • Daily SCRUM
    • 每個程序猿簡單報告這兩個星期做了什麼、中間遇到什麼問題、下次要完成什麼。
    • 如果遇到的問題可以自行解決，也可以協助或告知其他程序猿。
    • 這些技術或者是其他問題將要在 Daily SCRUM 後被解決。

Retrospective - 中文意思: 回顧
Sprint - 中文意思: 衝刺
Scrum - 中文意思: 爭球

Artifacts 神器

  • Increment 增量
    • 每次 Sprint，將軟體潛力增加，藉由當初定義 ‘完成(done)’ 為標竿。
    • 完成(down)
      每況愈下，完成的定義越來越嚴苛。最後如下定義：
      1.    All the PO’s defined acceptance tests run,
2.    The system is fully integrated and running on the production servers,
3.    All the manual pages are up to date,
4.    The code is clean and well-factored,
5.    All the programmer tests are running green.
    • 由於 ‘完成’ 定義嚴苛，即使有缺陷 (Bug)，也能在短時間內修復。
    • 小檢查、小修復比起改造整個產品成本更低。
  • Product Backlog 產品待辦
    有序地完成需求項目，產品負責人和團隊要一致認可。
  • Sprint Backlog 衝刺待辦
    確認每一個 ‘done’ 的完成，看得到完成進度。

期中考古題

以下內容為本人網路搜索的轉換，如有錯誤請多多指教

  • 1 張氏軟體公司有張一張二張三張四等四位工程師及客戶公司派來的駐點使用專家王五， 另聘工讀生工一工二兩位。

    • 1.1 公司現場應如何佈置
      Answer. 
1. 分 Common 及 Cave 兩區、和四周的 White Board(白版)
    **Common 區**: 兩人一組，在一台大尺寸螢幕前工作 (pair programming)                  各組可目視、交談、溝通
    **Cave 區**: 個人處理 e-mail，電話，閱讀資料等
    **White Board**: 供討論用
2. 採用 Central Desk (相較於 U-pod) 配置，可以相互看到對方的工作區。
3. 細節補充:
    1. 勿用需工人搬動的傢俱，用簡單桌子即可
    2. 電源線，網路線走底下或頭上，易接到桌子
    3. 椅子勿節省，有人因背痛要跪姿椅或升降桌
    4. 白板要很多，含輪子白板，相機白板，動態顯示板(連接投影機,如顯示 build 狀況)
    5. 見下圖 Central Desk 有 eye contact，U-Pod 則有 ear contact 且易看別組螢幕

    • 1.2 探索需求 誰做 何處做 產生何文件

      Answer. 客戶公司兩位資深人員做需求分析，在客戶公司做，產出功能清單及相關特性、限制、偏好。
    分析工作如下：
    1. 列出使用者名單
    2. 選取使用者樣本 
    3. 觀察、訪談(2)，與之開會 
    4. 開會要充份討論 
    5. 會後得到功能清單，及相關特性、限制、偏好 
    6. 功能分次開發後，做喜好度調查
    最後派遣一位當作駐點客戶給開發團隊即可。

    對於顧客
    * 顧客不明白他自己需要什麼
    * 顧客不願將他們的需要固定在一系列寫在紙上的條例中
    * 在價格和時間確定後，顧客堅持要求新的需要
    * 分析者與顧客的通訊太緩慢
    * 顧客不參加回顧或無法參加回顧
    * 顧客缺乏技術上的知識
    * 顧客缺乏對軟體開發的知識
    ----
    對於分析師
    * 是否可行
    * 是否在規定的時間裡可以完成
    * 價格上是否負擔得起
    * 是否合法
    * 是否符合道德
    • 1.3 Scenario 誰做 文件為何
      Answer. 駐點客戶說明，並寫出 Scenario 和 User Story 文件。
    * 寫使用情節 (Scenarios) 並與開發者確認使用畫面，
    * 撰寫方式：由簡而繁、由正常到異常
    • 1.4 Acceptance Test Case 誰做 文件為何
      Answer. 駐點客戶寫，並且產出 驗收案例文件。
    * 由使用情節寫驗收測試(需準備大量 data )
    * 驗收測試應在程序員寫代碼之前就寫好。
    * 根據使用使用操作，會產生何種操種介面或者是輸出。

    • 1.5 CRC session 誰做 文件為何

      Answer. 工程師五人以內圍坐，產出 Class Diagram, Sequence Diagram 等設計圖文件
    * 群體智慧，設計出好的程式架構
    * 切割類別(C)、每個類別自己要做什麼(R)以及類別的合作類別(C)

    架構設計會議，準備 CRC Card (Class-Responsibility-Collaborator cards) 
    以下為 CRC Card 的欄位項目 (相當於 O-O 架構的設計)
    * 資訊保持者(information holder) ─ 知道或提供資訊，也就是說保持事實，例如郵件地址，帳號，交易記錄等；
    * 結構者(structurer) ─ 保養物件間的關聯以及與這些關聯相關的資訊，例如檔案系統的folder；
    * 服務提供者(service provider) ─ 執行工作，一般來說提供運算服務，例如信用授權；
    * 協調者(coordinator) ─ 委託工作，例如交通號誌燈，文字處理器的字體管理；
    * 管制者(controller) ─ 決定並指揮它物的行動，例如交通指揮員；
    * 介面者(interfacer) ─ 支持系統內外各部門的間通訊，例如ATM的金錢出口。

    決定以上內容後
    * 可以撰寫 Class header 和 Method header 的簡單說明。
    * Class header 由其下 Method header 匯集篩選而成。
    • 1.6 Dispatching and Scheduling 誰做 文件為何
      開發條目
      Answer. 工程師們根據自己的狀況，將認領的類別 Class 估算工作天數。產出每個人要在這段期間內完成那些功能項目的文件。
    Dispatching - 派工 (有人可能完成不了某些項目，著手工作分配)
    Scheduling - 時程 (功能所需完成時間進行分配)
    * 每一回合 - 平均三周，做一次派工和時程規劃 (工作分配，時間分配)
    * 每三回合 - 平均兩個月，交貨給客戶
    • 1.7 Unit test planning 誰做 文件為何
      Answer. 由工程師撰寫對於每個類別 Class method 的測試代碼 (根據之前 CRC 的討論)，產出 Unit test code
    * 這玩意必須在程式撰寫前開始，而且通常比源代碼還長。
    * Test code 又稱 Test-First Development。
    * 不知道算不算 **測試驅動開發** 前置作業
    * 每一個 method 根據參數、環境做預期結果的測試。
    • 1.8 Data structure design 誰做 文件為何
      Answer. 工程師，產生數據結構的 Class。
    * 除了工程師外，沒人辦得到。
    * 高級數據結構比一般數據結構好用，而且擴充性和彈性較強。
    * 通常內建標準函數庫就很好用
    * C++: #include <stack>, #include <queue>, ...
    * Java Collections Framework: ArrayList, Vector, Stack ...
    • 1.9 Algorithm design 誰做 文件為何
      Answer. 工程師，產出虛擬碼 pseudo code、設計草圖 design sketch
    * 虛擬碼不說自明，設計草圖就是圖形化的想法來源
    * 根據數據結構也有所不同。
    * 演算法也是有抽象層次 Abstraction levels，相互調用什麼的。
    * 要做 Trace test code 來 Debug。
    * 要做時間複雜度分析。
    * 同時簡化到可以在白板上，讓團隊審查 Group review。
    • 1.10 Coding 誰做 文件為何
      Answer. 工程師，產出源代碼 source code
    * 終於開始工作，還會一直被 Unit test code 
    * 程式易於閱讀、了解、維修，才是 **活著**
    * 強調重複利用別人代碼 (因為通常已經通過測試，不用 Debug)
    • 1.11 Unit testing 誰做 使用何文件
      Answer. 工程師使用測試軟件運行 Unit test code，產出測試結果。
    * 如 Java unit test，產出測試記錄檔，表示哪些 method test case 通過。
    • 1.12 Acceptance testing 誰做 使用何文件
      Answer. 駐點客戶手動測試，使用驗收案例文件，產出測試結果。
    * 手動操作所有驗收案例
    * 如果驗收案例太多，那也是駐點客戶疲累的地方。
    * 測試文檔，不外乎就是哪些連續動作 (Action) 通過或者是不通過
    • 1.13 Reverse Engineering Tool 何工序後可使用
      Answer. 在架構設計 (CRC) 後，便啟動這類型逆向工具。
    * 利用逆向工程工具 如 eUML2、AgileJ。
    * 工具將動態產生 Class diagram, Sequence diagram ... 等。
    * 協助設計草圖不偏離，同時能了解設計樣貌，幫助維護和修改。
    • 1.14 此軟體的需求有七個功能( user story ) 駐點使用專家規劃為三次交貨( release )工程師們規劃用兩個回合( iteration )完成第一次交貨的功能
      • 1.14.1 派工 (dispatching) 如何做
        Answer. 在 CRC 工作結束後，每個成員認領一項類別 Class 進行開發。而在每回合微調工作分配。
      • 1.14.2 時程 (scheduling) 的時間單位為何
        Answer. 平均 2-3 週
      • 1.14.3 工作中客戶公司會不會來催進度為什麼
        Answer. 定期交貨，以執行力達成承諾取信客戶，客戶只需固定時程檢驗進度。
  1. 因有 Continuous Integration(CI) 使 Agile method 不須 integration testing. Explain it.
    Answer. 連續整合採用自動化的方式進行，每一天或者是固定時間，便會將團隊開發、撰寫立刻回饋分析結果，如此一來不用人工繁瑣的整合測試程序。
    * 這問題相當奇怪，因為連續整合也算是整合測試 ?
    * 連續整合不用人工測試，可以降低風險。
    * 連續整合隨時都有可以發布的版本。
    * 增加系統透明度。也就是說可以追蹤或者是預測發展趨勢。
  2. Test-driven development 的 development, test 及 drive分別是什麼
    Answer. 因為在源代碼 source code 撰寫開始前，必須先把所有測試項目撰寫成 test code 或者是人工驗收的案例，
* development 開發方式，做事的風格
* test 測試，經由 test code, case, tool 產生預期結果和實際形況的差異分析。
* drive 驅動則是根據測試結果驅使源代碼的修正。
  3. 維修軟體時，應閱讀 sourse code 或 pseudo code? Why?
    Answer. Pseudo code，方便理解與快速找到要維修的地方。
    * 題目應為先讀哪一項，照理來講要先讀 pseudo code 再讀 source code。
  4. Pair programming 何以能提高軟體品質?
    Answer. 一人撰寫一人修正，分散思考壓力，同時可以激發出創意，可以降低錯誤率、提升除錯效率。
    * 主要是分散思考壓力、增加思考廣度。
    * 缺點是開發時間會稍慢，但是品質不錯。
    * 編程能力水準相當才能相互激發，否則是純教導或者是管理功用。
    * [搞笑影片](https://www.youtube.com/watch?v=dYBjVTMUQY0)
  5. Method interface 與 method header 有何相關舉例說明之。
    Answer. 
1. method interface 指的是關於這個 method 參數型態和意義、以及額外調用的 method 說明。
2. method header 指的是在 method 前面的說明，通常具有這個 method 如何快速簡易使用的說明。
        * 通常 method header 算是 method interface 的摘要，或者是組合使用的說明。
        * 因此 method interface 完成後，才會有完整的 method header。
        * method interface 指的並不是 java 的某種 interface 類別，而是類似 UML 有哪些 method 和 attribute，能提供做出什麼事情。
        * 別跟 class header 搞在一起，請弄清楚。
  6. Data structure design 與 Algorithm design 有何關係
    Answer. 演算法中會調用到資料結構，根據搭配的資料結構才能估算時間複雜度，以及支持效果。同時，演算法也能針對搭配資料結構做最佳化。
    * 面相來說，Data structure 是工具 Tool。
    * 怎麼最佳化使用工具就是演算法的事情。
    * 例如: 資料結構的幾種操作的複雜度不同，調用操作的比率將會是演算法的重點。

Reference

Websites

  1. 台灣敏捷苗圃
  2. BLOG - 輕鬆談軟工
  3. Wiki

Friends

  • Iris
  • 等待更多網友