精實軟體開發是根據精實原則所產生的, 因此你必須先了解什麼是精實原則, 才能知道精實軟體開發重點放在哪裡. 在 Lean Software Development: An Agile Toolkit 一書中, Mary 整理出了以下原則:

 

can-stock-photo_csp11263618  


1. 消除浪費 (Eliminate Waste)
在這篇文章中描述了軟體開發中常見的浪費是什麼
http://kojenchieh.pixnet.net/blog/post/331346645

 

2. 增強學習 (Amplify Learning)
所謂增強學習是指, 讓開發團隊能快速學習要開發的系統和需求是什麼. 在這個原則下, 常見的做法有:

(1) 較短的循環: 這樣我們就可很快知道我們做得好不好, 對不對, 依據所學到的來調整產品方向, 或是開發手法. Scrum 是採取這個做法來實踐精實的, 但是 Kanban 並不強調這點.
(2) 使用一些輕量級的 prototyping: wireframe 或是 paper prototyping 都是很好的做法, 讓你花較少的時間和精力, 就可以跟相關的利害人, 開始討論系統的需求.
(3) 及早測試,使用TDD/unittesting搭配CI: TDD 和 CI 會即時給開發人員回饋, 讓他了解他的程式是否實作正確, 是否影響別人. 


3. 盡量推遲決策 (Decideas Late asPossible)
精實建議晚點才做出決定. 等到要做決策所需的資訊已經有了, 所做出的判斷會比較正確. 在早期資訊不清楚的狀況下, 就作出決定, 或是進行評估, 這會是一種浪費, 因為會很多東西之後要修改, 或是重做.

像敏捷的評估方法, 6 個月或是一年的計劃, 評估的時候就會比較粗略. 但是如果是未來 2 周或是一個月內的計劃, 就要很精細. 因為你馬上要做的東西, 是優先順序最高的, 應該要最清楚, 所以才會花時間去做詳細的規劃. 如果是比較後面的東西, 就等到後面比較確定後才做.


4. 盡快交付 (Deliveras Fast asPossible)
客戶都希望能儘快拿到手, 讓他們可以開始試用, 或者因此有機會澄清他們自己想要的是什麼. 並且, 有時候客戶也常常不懂為何要做這麼久, 如果我們能儘快讓他們拿到一部份的東西, 也會增加客戶對我們的信心, 進而凸顯我們的專業性.

對開發團隊來說, 盡快交付可以帶來以下好處
(1) 每次開發範圍較小的功能, 所以產生的錯誤會比較少點
(2) 能夠及早得到意見, 然後及早調整
(3) 儘快交付會讓客戶沒有太多時間改變心意, 否則一邊做一邊聽到需求變動, 是會很痛苦的. 做完後至少可以凹說這是你當初說要的, 要改要加錢 XDD


5. 授權團隊 (EmpowertheTeam)
傳統都是經理決定後,告訴屬下怎麼做. 在精實的想法中, 會是鼓勵授權, 讓團隊成員下決定, 對專案有自己的見解, 並對經理提出做法或是改善方案. 因此如何激勵人心, 會是這個準則重要的關鍵.


6. 著眼整體 (SeetheWhole)
開發團隊需要著重全局, 局部最佳化不會是最後的答案. 例如, 在工作流程上我們就會看到, 大家如果只是在乎自己的部分, 但是不關心最後這個功能是否是客戶要的, 是否能及時交付給客戶, 那你就會發現某些角色堆積了很多工作, 可是他的上游還是塞東西給他做. 然後還會說, 他的部分我不會, 無法幫他加速...

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()