精益與敏捷開發

作者: Wu.Country@俠緣  來源: 博客園  發布時間: 2009-06-18 20:30  閱讀: 942 次  推薦: 0   原文鏈接   [收藏]  

  在幾年前,我就對軟件的敏捷開發有著很高的興趣的。一直覺得,程序員應該是最自由,最輕松的一種職業!而且我也一直在向這個方向努力!

  我們應該如何做呢?一說到程序員,大家就公認的是腦力民工!為什么?在程序員自己報怨開發環境不好,工作量大,任務重,壓力大的同時,有沒有想過,有些問題其實是程序員自己的原因造成的呢?

  我們來看一個流程的例子:

  從一個問題單開始,你要解決這個問題,首先得申請問題單的查看權限,花5分鐘填寫一個權限申請電子流,然后等1到2個小時生效。當然,如果你一次申請一個長久有的效的權限,第二次在解決問題單時就不須要了。

  然后閱讀問題單,重現問題,如果有不清楚的,可能還會咨詢測試人員。假設你在1個小時以內了解清楚了問題。
然后準備修改問題,得先申請代碼權限。填寫電子流也就幾分鐘,然后等待審批,可能得1到2上小時。如果幸運的話,是這樣的。

  然后是代碼的Checkin與Checkout,以及修改!

  然后是編譯,驗證。最后出版本!

  OK,這是一個比較簡單的流程,我們看看,其實有很多因素可能導致我們的開發流程是效率很低的。例如,在權限申請的等待過程!問題確認過程!電腦文件打開等待過程!網絡打開等待過程!等,一些不產生value的過程,都是精益開發中應該減少的。

  我們并不能指望效率會有多高(豐田的效率也只有40%左右,效率就是把一個流程中,產生value的時間除以整個流程的總時間),但在精益開發中,就是要在各個環節中找到影響效率的點,然后盡力的去減少它!

  例如,上面的例子中,當開發人員要確認問題時,應該直接找到測試人員,面對面的把問題搞清楚。而不是在郵件,或者電話中詢問題!再如,給開發人員配置更快的電腦,以減少打開文件的等待時間。當然,開發人員也應該自己優化自己的開發電腦。公司優化網絡等。

  當然,在整個流程中,要分清楚哪些工作是有效的,哪些是沒有效的,并不是件容易的事!一些非常明顯的事,如前面提到的等待,就不用說了。

  對于以下一些事件,哪些是有效的,哪些是無效的呢?
  需求分析
  需求設計
  編寫設計文檔
  測試設計
  編寫測試文檔
  編碼
  測試
  修改BUG
  技能提升

  呵呵,感覺全部是有效的工作!其實不是!

  從用戶角度來看,只有編碼一修改Bug是有效的,其它的一律無效!

  當然,這是從用戶角度來看。從我們開發人員來看,上面的也并不是全部有效的!

  例如:設計文檔,測試

  而技能提升是有效的。

  這里不去細致的討論哪些有效哪些無效,只要記住精益的思想:

  盡量發現開發流程中的無效工作,并盡量減少它!

  當然,精益開發也給我們提供了一些簡單的方法來判定有效工作與無效工作!

  這就是精益開發的第一條原則!而后面的所有原則就都是由它產生的!

  另一個就是敏捷開發!敏捷的第一條原則就是滿足客戶需求!

  第二原則就是適應變化!

  第一原則我覺得不用講,沒客戶你就無法生存!

  而第二原則,則相比之下會更重要!為什么,因為只有適應變化,才能不斷滿足客戶需求!而且變化是非常快的,如果軟件開發不能適應變化,客戶的滿意度也會下降。因此,我覺得,軟件開發能適應變化,快速反應用戶需求與變更,是敏捷開發的核心!

  如何做到這些呢!

  首先就是敏捷開發流程!它使用是迭代開發!

  有人不明白,為什么要用迭代開發。如果在已知用戶需求不會發生變化的時候,我們還要用迭代嗎,為什么不一次就把事情做好,交附給用戶!

  說到這一點,不得不提到精益開發里的一條:一個軟件真正有用的特性往往不足50%,而且經常使用的也只有20%左右。如果你覺得用戶的需求不會變化,然后一次給用戶把所有特性全部完成的話,你就會陷入到這個2-8理論中!

  敏捷的思想是怎樣的呢?我們喜歡變化,我們要適應變化,還要引導用戶變化!

  例如:在你收到用戶的10個特性時,經過分析,可能會發現有4個特性可以不要,或者可以用前面的特性取代!但這是用戶的特性,用戶就是上帝,你又不好直接回復用戶,說這個特性可以不要,只要用前面的特性1,稍微改一下用法就可以實現!
用戶可不吃你這一套!但如果我們先把一些基礎特性在前面的迭代中先完成,然后以體驗版的形式給用戶。一方面驗證一些特性,另一方面,也可以引導客戶,對后面的特性進行變化!

  這時,用戶很有可能對前面的一些特性有新的看法,會要求修改已經實現了的特性。然后對還沒有實現的特性可能會不太關心,或者,用戶在自己使用的時候,就已經意識到,后面的特性可以不要了!

  這樣,一方面我們要增加已經完成的特性,而另一方面就要刪除原來的特性需求,或者更改需求!這是好事還是不好呢?就不說了吧!

  如果我們在一開始就想著是這樣的發展過程的話,那是太好不過了!當然,如果你覺得用戶善變,那我也就無語了!那就還是走2-8理論吧!

  敏捷的核心,就是變化,適應變化!而在軟件的開發中,對代碼的變化是非常講究的,也有很多方法和工具。敏捷的迭代是從流程上來管理的,還有其它很多就不多說了。

  今天也就是從培訓中學習和了解一點,然后結合自己的想法寫了一點!

0
0
 
標簽:敏捷開發
 
 

文章列表

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()