掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
以利為利:財政關系與地方政府行為
-
>
立足飯碗 藏糧于地——基于中國人均耕地警戒值的耕地保護視角
-
>
營銷管理
-
>
茶葉里的全球貿易史(精裝)
-
>
近代華商股票市場制度與實踐(1872—1937)
-
>
麥肯錫圖表工作法
-
>
海龜交易法則
買過本商品的人還買了
精益開發與看板方法 版權信息
- ISBN：9787302423560
- 條形碼：9787302423560 ; 978-7-302-42356-0
- 裝幀：暫無
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
精益開發與看板方法 本書特色
本書作者從事軟件開發多年，善于吸取敏捷和精益這兩種開發方法的精髓，對看板的理解和應用具有實用而豐富的經驗。他在本書中依托精益開發中的主流工具，介紹了看板的概念、遵循的基本原則、看板的適用范圍和具體使用等。 精益軟件開發是當下軟件開發項目的主流。看板可以使得精益理念落實并貫穿于整個開發流程，從而提高應變能力、減少無謂的資源及時間浪費、完全發揮團隊的開發效能。本書適合所有軟件從業人員（從項目經理到工程師）閱讀，可以幫助他們從容應對千變萬化的客戶需求。
精益開發與看板方法 內容簡介
本書作者從事軟件開發多年，善于吸取敏捷和精益這兩種開發方法的精髓，對看板的理解和應用具有實用而豐富的經驗。他在本書中依托精益開發中的主流工具，介紹了看板的概念、遵循的基本原則、看板的適用范圍和具體使用等。 精益軟件開發是當下軟件開發項目的主流。看板可以使得精益理念落實并貫穿于整個開發流程，從而提高應變能力、減少無謂的資源及時間浪費、完全發揮團隊的開發效能。本書適合所有軟件從業人員（從項目經理到工程師）閱讀，可以幫助他們從容應對千變萬化的客戶需求。
精益開發與看板方法 目錄
目 錄第1章 精益軟件開發 11-1 精益的由來 21-2 精益軟件開發 31-3 精益軟件開發七大原則 51-3-1 消除浪費（eliminate waste） 51-3-2 增強學習（amplify learning） 111-3-3 盡量延遲決策（decide as late as possible） 141-3-4 盡快交付（deliver as fast as possible） 171-3-5 授權團隊（empower the team） 201-3-6 嵌入完整性（build integrity in） 221-3-7 著眼整體（see the whole） 251-4 結論 27第2章 看板方法 292-1 看板的由來 302-2 何為“看板方法” 302-3 看板方法四大基本原則（foundational principles） 322-3-1 原則1：從既有的流程開始 322-3-2 原則2：同意持續增量、漸進的變化 342-3-3 原則3：尊重當前的流程、角色、職責和頭銜 362-3-4 原則4：鼓勵在各個層級上發揮務實性領導行為 372-3-5 四大基本原則的意義 382-4 為何要使用看板方法 392-5 哪些地方可以運用看板方法 452-6 結論 48第3章 看板方法的六大核心實踐 493-1 可視化目前的工作流程 503-2 限制半成品（wip）數量 583-2-1 利特爾法則 593-2-2 多任務是不好的？看板方法如何處理多任務 613-2-3 怎么樣的數值才會讓人滿意呢 633-2-4 根據請求的多寡分配產能 643-3 管理工作流程 653-4 讓規則明確 693-5 落實反饋循環 713-6 由協作改善，經實驗演進 723-7 結論 75第4章 如何實施看板方法 794-1 看板墻的設計 804-1-1 三個基本元素 804-1-2 順序處理狀態 vs. 并行處理狀態 814-1-3 工作項目的屬性 844-1-4 加入 wip 限額 864-2 scrum 運作模式的看板墻設計 914-2-1 將看板方法融入 scrum 的開發過程 914-2-2 在 scrum 中運用看板 924-3 看板一日游 944-3-1 看板一日游 1/12 說明 944-3-2 看板一日游 2/12 說明 964-3-3 看板一日游 3/12 說明 984-3-4 看板一日游 4/12 說明 994-3-5 看板一日游 5/12 說明 994-3-6 看板一日游 6/12 說明 1004-3-7 看板一日游 7/12 說明 1014-3-8 看板一日游 8/12 說明 1024-3-9 看板一日游 9/12 說明 1034-3-10 看板一日游 10/12 說明 1034-3-11 看板一日游 11/12 說明 1044-3-12 看板一日游 12/12 說明 1054-4 運行看板方法的簡單規范 1064-5 結論 111第5章 個人看板：類項目管理 1135-1 個人看板 1145-2 制作**個個人看板 1155-2-1 可視化 1165-2-2 設定 wip 限額 1195-2-3 看板管理：開始運行拉動系統 1205-3 個人看板與軟件開發：類項目管理 1245-3-1 項目的范圍 1245-3-2 建立個人看板 1255-3-3 個人看板一日游 1275-3-4 另類的個人看板 1375-4 結論 140第6章 個人看板與生活：讓生活與工作相得益彰 1436-1 開始使用看板 1446-2 生活與效能 1486-2-1 消除浪費 1496-2-2 夢想與目標 1506-3 個人看板進階 1566-4 結論 157第7章 預測未來：減少變異性，增加可預測度 1617-1 系統思考 1637-2 內部變異 1677-3 外部變異 1747-4 結論 177第8章 持續改進 1798-1 看板方法的問題管理 1818-2 運用看板方法自然形成簡單的團體規范 1838-3 沒有銀彈（no silver bullet） 186附錄 189附錄a 精益咖啡 190附錄b scrum but 和 kanban but 194附錄c 用戶故事圖譜：對付需求模糊的好幫手 199附錄d 敏捷開發需要哪些文件 203
展開全部
精益開發與看板方法 節選
第1章 精益軟件開發 1-1 精益的由來 “精益”（Lean）這個詞匯是約翰?克拉夫西克（John Krafcik）1988年在他的一篇文章 里率先提出來的，但他所稱的精益制造（Lean production），指的是制造業的精益理論，而軟件界的精益（Lean）則稱為精益軟件開發（Lean Software Development），它源自于波彭迪克夫婦（Mary Poppendieck 和 Tom Poppendieck）在 2003 年的著作《精益軟件開發工具》（Lean Software Development：An Agile Toolkit），書中闡述了精益軟件開發的七大原則，精益屬于敏捷開發的成員之一。 敏捷軟件開發（Agile software development）是從 1990 年代開始逐漸取代傳統開發方法的一些新型軟件開發方法，是一種應對快速變化需求的軟件開發能力。相對于傳統開發方法，敏捷軟件開發*大的差異在采用迭代式的開發模式，而不是一次定江山的瀑布式開發模式，以及接受客戶對需求合理的變更（讓客戶對需求做出不同優先等級的區分，并盡力去滿足它）。 敏捷（Agile）一詞起源于 2001 年初，敏捷方法發起者和實踐者在美國猶他州雪鳥滑雪圣地的一次聚會，有 17 位當代軟件代表人物共同簽署了敏捷宣言，并成立了敏捷聯盟。但在此之前，早在 1991 年麻省理工學院出版的“改變世界的機器”（The Machine That Changed the World）研究報告中，就已經把日本豐田公司的豐田生產方式系統（TPS）歸納成為一套精益生產（Lean Production）方法。 嚴格來說，精益（Lean）比敏捷（Agile）要早誕生許多年，但現在擁戴精益的人士也已經加入了敏捷聯盟的陣營（見圖1-1），雖然他們依然遵循著精益精神的七大原則而不是敏捷的四大宣言和十二項原則，但實質上他們都共同擁護敏捷式的開發方法及精益精神，二者并無抵觸。 圖1-1 敏捷傘下的兩大陣營 1-2 精益軟件開發 精益軟件開發并沒有具體的開發方法或步驟，而是一堆原則，原因是它認為沒有所謂的*佳實踐。“原則”具有較廣泛的普遍性，能指導對某一學科的思考和領悟，而“實踐”則是為執行原則而采取的實際措施，需要針對某一領域進行調整，尤其必須考慮到具體實施的環境。精益軟件開發是由軟件開發領導者，例如軟件開發部經理、項目經理和技術領導者，而不是一般程序開發人員所創設的思想工具。 因為精益軟件開發沒有具體的實行方法，這會讓你覺得它只是一些原則和教條，執行起來應該是*簡單的，影響也不大，即便做錯了也是無害。如果這么想的話就錯了，因為“原則”所影響的是企業的文化層面，比起單純的開發方法影響大得多了。 依照圖1-2的區分，右邊第二位隸屬于精益開發體系下的看板方法（Kanban），是距離胡作非為（Do Whatever，“胡來”，也就是完全沒有規范）*接近的敏捷開發方法。越往右側的開發方法就表示規范越少，我們稱為輕量級（light weight）的軟件開發方法，越往左邊的開發方法則是規范越多，相對于輕量級的開發方法有較多的約束，我們稱為重量級（heavy weight）的開發方法，例如RUP（Rational Unified Process，統一軟件開發過程）。 本章的主旨在于闡述如何將精益的精神由原則轉換為適用于特定環境下的敏捷實踐。說得更精確些，就是針對七大原則加以實踐的詮釋，目標是看板系統，尤其是依靠經驗法則換來的經驗知識 。 圖1-2 依照規范的多寡由左至右排列各種開發方法 圖1-3 在精益網絡的時代，充斥著各式各樣的對象 如圖1-3所示，在沒有使用過之前，實在很難判斷是不是用錯了組件？ 1-3 精益軟件開發七大原則 以下為精益軟件開發的七大原則： 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） 乍看之下，你可能覺得這些原則感覺上像口號一樣，真的有用嗎？讓我告訴你，當你在繪制看板時（也就是將你的工作流程放到看板上成為一個或多個垂直字段時），你所依據的便是對這幾條原則的了解程度。如果你覺得很陌生的話，下次改變看板外觀時，一邊看著這些行列一邊思索是否需要改善哪里？改的原因是什么？想達成哪一條原則？多練習幾次就熟了。記得一次只改善一個地方就好，這樣比較容易看出是哪個異動所造成的結果，這一點跟改 bug 是一樣的，一次同時修改好幾個地方，就搞不清楚誰才是真正的元兇！ 1-3-1 消除浪費（Eliminate waste） 何謂浪費？凡是對客戶或產品不具備提升任何價值的行為，基本上都是一種浪費！ Bug 是**大浪費 程序開發人員*大的浪費，便是在開發工作時制造一大堆 bug，然后再費盡心力把它解決掉。有趣的是，解決這些 bug 之后還能獲得相當的充實感！反倒是很少有人會回過頭來檢討這些 bug 實際上都是自己所造成的。會有這些 bug 產生，其實是軟件的復雜性所造成的，是我們把程序寫復雜了。而如何減少 bug 呢？就是想辦法把程序寫簡單一點，只有很簡單的程序，bug 才會相對減少。如果程序復雜了，*后便只能靠測試來守住質量，這一點也間接說明開發和測試實際上是一體兩面，開發者必須負起減少 bug 的**線任務，因為它才是*大的浪費。 現在的程序開發工作太復雜了 開發軟件*重要的是知道要做什么，然后去做，就這樣簡單！ 但經過歲月不斷的累積之后，我們把這個過程變復雜了。是那些有智慧的學者不斷地把經驗奉獻出來，針對各種不同問題提出解答（設計模式便是這樣誕生的），智者怕我們重蹈覆轍便想辦法把經驗積累下來，原意是為了照顧后進，結果卻是把開發工作越弄越復雜（HTML 的演進史就是這個縮影）。十年前的軟件開發項目，經過十年后規格并沒有太大改變，但我們卻可以把它弄得越來越有學問，看起來越專業，專業到必須有相當的學習過程才足以開發十年前就能做到的事！程序在執行速度上變快了，但是在質量這一點上卻始終沒有太大的提升，原因是我們把自己弄復雜了，我們一再地把開發程序的門檻弄高了，而復雜所帶來的*大罪惡便是浪費，所以消除浪費便成為近代工程師要學習的**要務。 “簡單”是對付 bug 的有效法則 想要減少 bug，就是把程序弄簡單些讓自己隨時都能看得懂。開發軟件時，bug 總是自動在過程中被隱含進來。通常，一知半解寫程序是制造bug的*大元兇，這種 bug *難以檢測出來，再來則是邏輯思維被打斷也是在寫程序時很容易產生bug的時候。所以在進行工作分解時，*重要的是“簡單化”，簡單是減少 bug 的*佳處方。話雖如此，但很多時候軟件開發就是這么復雜，該如何是好呢？ “錯誤的估算”便是一個簡單不下來的原因。千萬不要在沒有做適度的拆解問題（工作項目）下進行時程的預估，因為那完全是在猜猜看！猜是人類*糟糕的預估了，*少也要有參考依據（有參考依據可以讓預估準確許多，例如找到可以比較的案例），但是必須經過拆解成為較小的工作單元，參考才足以成立。所以在減少浪費的前提下，“先拆解再簡單化”是開工之前（或是進行工時預估前）的**動作，正確的拆解可以避開那些不必要的復雜性干擾。 項目經理（PM）習慣向開發人員要求預估需要多少開發時間，想借助工程師每個人的預估，然后合計起來，以得到團隊的整體開發時程（當然再加上一點自己習慣性的保險時間）。這是一種將項目分解成多個區塊，然后針對各個區塊進行預估的作法。這樣所估出來的工時乍看之下是會比較準確，但是卻忽略了工程師本身所估算的數據本來就是基于一種猜測得來的數值，根本上就已經不準確了。所以，雖然已經經過拆解，但這是基于工程師個人的猜測而來，當然就沒有太大的意義。 什么樣的估算才比較準確呢？老實說，只有進行一段時間，有更深一層的了解后再來估算自然會準確許多。這種較準確的估算通常發生在項目進行五分之一到三分之一之間，這是一件耐人尋味的事，此時工程師對項目的把握度就可以大幅提升，這個時候的預估就可以接近于“承諾”了。 工程師的承諾與預估 項目開始時工程師無從參考比較，此時的工時估算應該只能說是猜測；一旦項目開始進行后，隨著對項目的了解增加，通常工程師在開發工作進行到五分之一到三分之一之間，由于對任務越來越熟悉，自然就可以做比較有把握的預估，這個時候的估算就可以稱之為“承諾”。 寫程序想要減少 bug，專注（Focus）是*有效的良方。這里討論的專注是指“短時間”的專注，而不是廢寢忘食、長時間瘋狂做某一件事的專注。短時間指的是 25 分鐘的專心工作，這一點請參考蕃茄工作法 。 如何識別浪費？ 豐田生產系統的策劃人之一新鄉重夫（Shigeo Shingo），他首創制造業的七種浪費類型，而波彭迪克夫婦則將它轉換成軟件業的七大浪費類型，對照如下表所示。 制造業七大浪費 軟件業七大浪費 1 庫存 半成品、部分完成的工作（Partially Done Work） 2 額外過程 額外過程（Extra Processes） 3 生產過剩 多余功能（Extra Features） 4 運輸 任務調換（Task Switching） 5 等待 等待（Waiting） 6 移動 移動（Motion） 7 缺陷 缺陷（Defects） 判別是否浪費十分重要，它是你避免浪費的基礎。接下來的說明雖然看起來冗長，但請務必讀完，每個項目的*后會括號說明相對于看板方法的運用手法，譬如你不知道該如何建立看板的垂直字段或調整 WIP（半成品）值，即可參考以下的幾條原則，將它們作為依據。 ……
精益開發與看板方法 作者簡介
李智樺，在軟件開發領域已有多年的實踐經驗，他對信息及軟件應用開發的熱情和投入令人佩服，包括新興的行動及云端開發技術的研究，近年來投身于敏捷、精益及看板方法的推廣并擔任講師，本書可以讓更多人了解這些軟件開發及項目管理的實用方法并應用于工作領域之中，值得閱讀！ 擁有超過30年的軟件開發工作資歷。從早期的大型銀行系統到近年來專注于微軟各項新技術的研究，是微軟Windows Azure云端及其他新開發技術的指定講師，擔任多屆TechDay、TechED等大型研討會主場演講。過去是資深的開發人員、大型系統及企業的總架構師，有長期同時帶領多個團隊的ScrumMaster大型項目經驗。他對信息技術的熱誠及堅持，至今仍對新技術的動手實操不遺余力，是少數擁有如此豐富資歷、能講、能教、隨時能上手的信息界老兵。 李淳 Certified Scrum Master、Certified Scrum Product Owner，曾先后在用友、易車等公司任程序員、研發經理、架構師、產品經理，敏捷和精益倡導者，團隊敏捷轉型實踐者，公眾號“互聯網plus管理新范式”（iPlusLeadership）維護人。代表譯著有《軟件需求（第3版）》
書友推薦
- >
小考拉的故事-套裝共3冊
- >
二體千字文
- >
回憶愛瑪儂
- >
【精裝繪本】畫給孩子的中國神話
- >
莉莉和章魚
- >
自卑與超越
- >
唐代進士錄
- >
朝聞道
本類暢銷
