揭秘敏捷精髓:消除浪費 走向精益
揭秘敏捷精髓:消除浪費 走向精益[@more@]來自:CSDN
2006年的世界財富500強列表中,豐田汽車排名第八,其營業收入高達185,805萬美元,與全球汽車工業老大——通用汽車——只有6799萬美元差距。然而,作為管理人員,除了關注這份值得讓人深思的名單以外,更重要的是豐田汽車強大的管理思想。它被稱之為“精益”(lean)。多年後在總結“精益製造”這一思想時,豐田喜一郎指出:精益的核心在於消除浪費。正是因為致力於在全企業範圍內消除浪費,才能讓豐田敢與通用一決高下。
在軟體行業也有一家企業,像當年的豐田一樣致力於消除軟體開發中的浪費。這家公司的名字叫ThoughtWorks,他們採用的方法叫“敏捷”(agile)。
提到“消除浪費”這個話題,ThoughtWorks中國公司技術總監Michael Robinson的話匣子立即被開啟了。“軟體開發中一個巨大的浪費源頭就是低質量導致的返工,”Michael Robinson說道,“人們常常為了追趕工期而降低對質量的要求,殊不知這會帶來更大的損失。任何一本軟體工程教材都會告訴你:假設在分析階段找到並解決一個錯誤的成本為1,在設計階段解決同一個錯誤的成本就變成10,在實現階段就變成100,在維護階段就變成1000。敏捷軟體開發中的眾多實踐正是為了避免低質量和返工的浪費。儘管它們一開始看起來似乎有些麻煩,但它們帶來的收益是實實在在的。”
其實敏捷軟體開發並不是新鮮事物。它早在上世紀90年代末就已經被正式提出,Kent Beck、Martin Fowler等一組軟體方法學專家於2001年共同提出了“敏捷宣言”。隨後的幾年中,以XP、Scrum為代表的各種敏捷方法開始在全世界範圍內流行。很多技術人員青睞敏捷方法的原因是它強調個人在團隊中的價值、提倡人性化的工作環境。而在ThoughtWorks中國公司總經理郭曉的眼裡,“讓開發者更舒服地工作”只是一種手段,更重要的是讓他們更有效率地工作。“豐田汽車的生產線上有很多紅燈,”郭曉給記者講起了故事,“一旦紅燈閃爍,就說明某個環節出現了問題,這時整條生產線都必須停下來,等質量問題解決之後才能恢復生產,從而避免劣質品流入後續環節而造成更大的浪費。ThoughtWorks在軟體開發中提出了‘持續整合’的理念,並開發了開源的CruiseControl來為持續整合提供支援。CruiseControl就像是軟體開發流水線上的紅燈,它隨時確保專案的質量健康,有效地消除返工造成的浪費。”
(連結:持續整合實踐案例解析)
除了對質量的高度重視以外,準時化(Just In Time)也在豐田的生產和製造當中扮演了非常重要的角色。在汽車工業的流水線上,由於預測錯誤而浪費的資源是致命的:如果不能儘快被組裝成汽車銷售出去,每一個零件在倉庫當中都以每天百分之幾的速度貶值。如何在正確的時間做出決策,儘量減少預測錯誤的浪費,是創業者豐田喜一郎提出的創想。多年後,他的後人實現了這個創想,也開創了豐田的“精確製造”方法。而在軟體行業裡,需求的變化更加劇烈,因此預測出錯的機率也更高。如何在這種環境下正確決策、消除預測錯誤的浪費?答案仍然是“敏捷”。
“敏捷不僅僅是一組軟體開發的方法,還是一套工作的方式。它不僅僅在技術層面有用,在專案管理甚至企業管理的層面同樣有用。”郭曉這樣說道,“避免預測錯誤的根本辦法就是推遲決策:決策下得越晚,就越不容易因為預測失準而造成浪費。當然也不能晚到錯過了時機、耽誤了工作才下決策,這就像豐田製造的Just In Time,決策也要Just In Time。過早的、含有太多預測成分的決策也會造成浪費,其危害絲毫不亞於過晚的決策。”
但要做到“Just In Time”地下決策,這決不是一件容易的事。郭曉認為這需要兩方面的支撐:首先,決策者要能夠獲得豐富而及時的資訊,這樣才能判斷什麼時候能夠決策、什麼時候必須決策;另外,整個專案必須擁有相當高的質量,才能做到即時響應決策。盲目推遲決策會帶來巨大的風險,而缺乏響應能力則讓“Just In Time”變成一句空話。“所以這又回到了我們一開始說的敏捷實踐,”郭曉總結說,“敏捷實踐的目標是消除浪費;而消除浪費又離不開這些實踐和工具的支援。沒有最佳實踐和工具的支援,再好的理念也是空談。例如ThoughtWorks最近釋出的敏捷專案管理工具Mingle,其中就融入了 ThoughtWorks十年來從事敏捷軟體開發的經驗,它對於軟體企業改進自己的工作方式和流程可以起到立竿見影的效果。”
(連結:敏捷專案管理工具Mingle)
自從進入中國以來,ThoughtWorks一直致力於將敏捷軟體開發的思想分享給中國軟體企業和軟體開發者。在2007年的7月14日, ThoughtWorks中國公司將聯合CSDN網站共同主辦第二屆“敏捷中國”軟體技術大會,與中國的軟體從業者共享實施敏捷專案、建立敏捷企業的經驗心得。CSDN網站將對本次大會進行全程追蹤報導,敬請關注。
2006年的世界財富500強列表中,豐田汽車排名第八,其營業收入高達185,805萬美元,與全球汽車工業老大——通用汽車——只有6799萬美元差距。然而,作為管理人員,除了關注這份值得讓人深思的名單以外,更重要的是豐田汽車強大的管理思想。它被稱之為“精益”(lean)。多年後在總結“精益製造”這一思想時,豐田喜一郎指出:精益的核心在於消除浪費。正是因為致力於在全企業範圍內消除浪費,才能讓豐田敢與通用一決高下。
在軟體行業也有一家企業,像當年的豐田一樣致力於消除軟體開發中的浪費。這家公司的名字叫ThoughtWorks,他們採用的方法叫“敏捷”(agile)。
提到“消除浪費”這個話題,ThoughtWorks中國公司技術總監Michael Robinson的話匣子立即被開啟了。“軟體開發中一個巨大的浪費源頭就是低質量導致的返工,”Michael Robinson說道,“人們常常為了追趕工期而降低對質量的要求,殊不知這會帶來更大的損失。任何一本軟體工程教材都會告訴你:假設在分析階段找到並解決一個錯誤的成本為1,在設計階段解決同一個錯誤的成本就變成10,在實現階段就變成100,在維護階段就變成1000。敏捷軟體開發中的眾多實踐正是為了避免低質量和返工的浪費。儘管它們一開始看起來似乎有些麻煩,但它們帶來的收益是實實在在的。”
其實敏捷軟體開發並不是新鮮事物。它早在上世紀90年代末就已經被正式提出,Kent Beck、Martin Fowler等一組軟體方法學專家於2001年共同提出了“敏捷宣言”。隨後的幾年中,以XP、Scrum為代表的各種敏捷方法開始在全世界範圍內流行。很多技術人員青睞敏捷方法的原因是它強調個人在團隊中的價值、提倡人性化的工作環境。而在ThoughtWorks中國公司總經理郭曉的眼裡,“讓開發者更舒服地工作”只是一種手段,更重要的是讓他們更有效率地工作。“豐田汽車的生產線上有很多紅燈,”郭曉給記者講起了故事,“一旦紅燈閃爍,就說明某個環節出現了問題,這時整條生產線都必須停下來,等質量問題解決之後才能恢復生產,從而避免劣質品流入後續環節而造成更大的浪費。ThoughtWorks在軟體開發中提出了‘持續整合’的理念,並開發了開源的CruiseControl來為持續整合提供支援。CruiseControl就像是軟體開發流水線上的紅燈,它隨時確保專案的質量健康,有效地消除返工造成的浪費。”
(連結:持續整合實踐案例解析)
除了對質量的高度重視以外,準時化(Just In Time)也在豐田的生產和製造當中扮演了非常重要的角色。在汽車工業的流水線上,由於預測錯誤而浪費的資源是致命的:如果不能儘快被組裝成汽車銷售出去,每一個零件在倉庫當中都以每天百分之幾的速度貶值。如何在正確的時間做出決策,儘量減少預測錯誤的浪費,是創業者豐田喜一郎提出的創想。多年後,他的後人實現了這個創想,也開創了豐田的“精確製造”方法。而在軟體行業裡,需求的變化更加劇烈,因此預測出錯的機率也更高。如何在這種環境下正確決策、消除預測錯誤的浪費?答案仍然是“敏捷”。
“敏捷不僅僅是一組軟體開發的方法,還是一套工作的方式。它不僅僅在技術層面有用,在專案管理甚至企業管理的層面同樣有用。”郭曉這樣說道,“避免預測錯誤的根本辦法就是推遲決策:決策下得越晚,就越不容易因為預測失準而造成浪費。當然也不能晚到錯過了時機、耽誤了工作才下決策,這就像豐田製造的Just In Time,決策也要Just In Time。過早的、含有太多預測成分的決策也會造成浪費,其危害絲毫不亞於過晚的決策。”
但要做到“Just In Time”地下決策,這決不是一件容易的事。郭曉認為這需要兩方面的支撐:首先,決策者要能夠獲得豐富而及時的資訊,這樣才能判斷什麼時候能夠決策、什麼時候必須決策;另外,整個專案必須擁有相當高的質量,才能做到即時響應決策。盲目推遲決策會帶來巨大的風險,而缺乏響應能力則讓“Just In Time”變成一句空話。“所以這又回到了我們一開始說的敏捷實踐,”郭曉總結說,“敏捷實踐的目標是消除浪費;而消除浪費又離不開這些實踐和工具的支援。沒有最佳實踐和工具的支援,再好的理念也是空談。例如ThoughtWorks最近釋出的敏捷專案管理工具Mingle,其中就融入了 ThoughtWorks十年來從事敏捷軟體開發的經驗,它對於軟體企業改進自己的工作方式和流程可以起到立竿見影的效果。”
(連結:敏捷專案管理工具Mingle)
自從進入中國以來,ThoughtWorks一直致力於將敏捷軟體開發的思想分享給中國軟體企業和軟體開發者。在2007年的7月14日, ThoughtWorks中國公司將聯合CSDN網站共同主辦第二屆“敏捷中國”軟體技術大會,與中國的軟體從業者共享實施敏捷專案、建立敏捷企業的經驗心得。CSDN網站將對本次大會進行全程追蹤報導,敬請關注。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10172717/viewspace-972110/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 敏捷的核心:消除浪費,走向精益敏捷
- 從客戶需求拉動到不斷消除源頭浪費,精益生產佈局有多重要?
- 精益生產培訓如何讓全體員工養成消除浪費和持續改進意識?
- 【精益生產】為什麼都說庫存引起的浪費最大?
- 精益工廠佈局的精髓是什麼?
- 京東精益敏捷教練分享:敏捷助力產品創新!敏捷
- 藉助精益找回敏捷的質量敏捷
- 精益看板管理和敏捷軟體開發敏捷
- 真北敏捷八月小結:入精益敏捷的廳堂敏捷
- 軟體開發中的精益和敏捷 - Aram Koukia敏捷
- 為什麼“敏捷”會浪費這麼多時間? - Reddit敏捷
- 精益敏捷萬法歸宗:把有意義的事,做到敏捷
- Fowler:敏捷還是精益?——毫無意義的問題敏捷
- 【精益生產】精益知識大全
- 華為精益敏捷專家:DevOps轉型中的那些坑敏捷dev
- 幽默:瀑布、敏捷、看板和Scrum以及精益等工程方法比較敏捷Scrum
- 訪談《敏捷和精益專案集管理》的作者Johanna Rothman敏捷
- 將看板應用於軟體開發:從敏捷到精益敏捷
- 精益化設計:把敏捷方法和Lean UX相結合敏捷UX
- 【精益生產】精益改善乏力,看新型精益體系模式如何構建模式
- 書籍:精益架構(敏捷架構 瘦架構 Lean Architecture)架構敏捷
- 如何用敏捷消除專案風險?敏捷
- 【精益生產】詳解精益物流改善方法
- Mike Cohn的“走向敏捷”三模式敏捷模式
- 影響地圖 -- 敏捷需求和精益創業的重要落地實踐地圖敏捷創業
- 真北敏捷 | 精益學問體系:思想、方法論、解決方案(模式)、工具敏捷模式
- AI如何走向精智慧之路?AI
- 精益創業分享創業
- 優思學院|精益(Lean)和敏捷(Agile)有什麼關係和區別?敏捷
- 優思學院|精益生產和精益管理的區別
- 估算實踐是浪費嗎?
- iOS 精益程式設計iOS程式設計
- 看《精益創業》作者埃裡克•萊斯評價《精益創業實戰》創業
- 專案微管理46 - 精益
- 精益IT的作用是什麼?
- 精益生產經驗分享
- 科技愛好者週刊(第 270 期):"精益開發"的精益是什麼?
- 【精益生產】精益六西格瑪質量管理執行體系推進案例