SCRUM BOOT CAMP｜23場工作現場的敏捷實戰演練

SCRUM BOOT CAMP｜23場工作現場的敏捷實戰演練
SCRUM BOOT CAMP THE BOOK

作者：西村直人, 永瀬美穂, 吉羽龍太郎

譯者：

游子賢

書號： ACL061400

出版日： 2022/03/15

ISBN： 9786263240889

EAN： 9786263240889

紙本書價格： 500

附件：無

電子書：

已出版

試讀

博客來

金石堂

天瓏

MOMO

Google Play

博客來

團體購書

回頁首

以通俗易懂的方式，幫助您了解Scrum實際運作的樣貌
Scrum是一種敏捷的軟體開發方式，已廣為大家接受。它總結了一些要點，包括該如何充分利用開發現場的人員能力，並將重點放在大家如何合作，所以非常簡單且容易導入。

實境模擬秀，幫助您了解如何應對與排除問題
本書除了說明Scrum的整體樣貌之外，更模擬工作現場的實際情境，以擬真的案例解說如何進行Scrum，以及如何應對及處理進行過程中所發生的種種問題。

以生動的方式詮釋「Scrum指南」
本書以「Scrum指南」為基礎，生動了詮釋Scrum的理論與價值觀。除了解釋基本規則之外，更詳細解說為什麼要遵守這些規則，能夠幫助您對Scrum有更加具體的體會與理解。

專家推薦
「書中針對許多敏捷相關的常見疑問，提出了解答。從前因到後果，都有著相當完整的說明。對於初次踏入敏捷的新手們，不失為一個不錯的指引。」
- 董大偉，微軟技術社群區域總監

「對於新手來說，本書生動的故事和插畫，可以讓你快速入門。至於Scrum的熟手，書中各式各樣的狀況題，可讓你借鏡別的人作法，使你的解法更完善。你還在等什麼，快點來帶一本走。」
- 敏捷三叔公柯仁傑，台灣敏捷社群創始人

回頁首

西村直人
2005年開始實踐敏捷軟體開發。自從接觸極限程式設計以及在永和系統管理公司開發以來，抱持著「想增加更多優良團隊，讓大家能透過敏捷開發為公司業務做出貢獻」的想法在努力，持續支援「Scrum Boot Camp Premium」培訓和活動。

永瀨美穗
株式会社アトラクタ（Attractor Inc.）創辦人兼品牌官／敏捷教練。在委託開發現場擔任軟體工程師，擔任組織管理者，導入並實踐敏捷。除了敏捷開發導入支援、教育培訓、輔導等，還致力於大學教育和社群活動。

吉羽龍太郎
株式会社アトラクタ（Attractor Inc.）創辦人兼技術長／敏捷教練。從事顧問與培訓，主要領域為敏捷開發、DevOps、雲端計算。曾任職於野村綜合研究所及Amazon Web Services。

回頁首

建構軟體並非易事。雖然一開始就想好要做什麼，但真的開始動工後，可能中途需求就改變了，還會
出現各種新的要求。建構軟體可能會花很長的時間，甚至會造成失去其原本意義，而花費了龐大費
用，得到的成品也不見得能達到期望。

在建構軟體時，真正重要的是什麼？就是實際使用軟體成品解決客戶和使用者的問題，賺取回報，也就是取得實際成果。建構軟體本身不是目的，而是取得成果的手段。因此，需要弄清楚為何要建構軟體，並時常確認目前所為是否真能達成其效果。在此過程中，如果想到了比先前更好的點子，那就接受並改變建構的東西，這樣做能將成果最大化。

什麼是敏捷開發？
那麼，為了達成目的並最大化成果，該怎麼進行呢？可以採用以下的方式。
● 所有相關人員彼此合作實現目標
● 分段實作產品，而不是所有功能同時完成，從早期就提供能正常運作的軟體，並持續反覆評估
● 持續從使用者或相關人員獲得回饋，並調整計劃

這種開發過程稱為敏捷開發。這個詞是在2001 年誕生的。為了解決傳統開發過程的繁重問題，經過各種試誤以及各種討論，有群人發現他們的基本想法有許多共通之處，提出了敏捷軟體開發宣言。換句話說，敏捷開發並不是指任何單一的開發方法，而是指類似的開發方法的共通價值觀與行為原則，而且有許多不同方法體現這些原則。主要的方法是Scrum、極限程式設計（Extreme Programming）和看板（Kanban）。各種敏捷開發方法的共通點是以「一切都無法事先準確預測及計劃」為前提。在傳統開發方法中，所有需求都是事先收集的，並估計所需時間、人力，以及成本。
而在敏捷開發中，是先決定在專案上要花的時間及人數，在其範圍內，從最重要的需求開始打造產品（產品是指敏捷開發的實際產品，主要指軟體，也包括必要的文件）。亦即會從重要、高風險的需求開始進行，其他放在後面，從而最大化成果。

什麼是Scrum？
如上所述，Scrum 是敏捷開發方法之一。
Scrum由Jeff Sutherland和Ken Schwaber在1990年代創立，是將野中郁次郎與竹內弘高在1986 年發表於《哈佛商業評論》之文章「新新產品開發遊戲」的內容，應用在軟體開發上，而Scrum這個名稱也是來自該文章。Scrum 具有以下特點。

● 依照價值、風險或必要程度，對需求進行排序，並依此順序建構產品，以達成成果最大化
● 在Scrum中進行作業時，將時間切分成固定且短的區間，固定的時間區間稱為時間盒
● 時常釐清目前狀況和問題，即所謂的透明
● 定期檢查進度，確認所製作的產品是否能得到預期的結果，以及工作方式是否存在問題，即所謂的檢驗
● 如果做法有問題，或是有能做得更好的方法，我們就改變做法，即所謂的調適

Scrum 適合處理未知多於已知的複雜問題，它由一套最基本的規則組成：五種事件（event，會議等）、三種角色（role，人的角色）和三個產出物（artifact）。因為只有最低限度的規則，所以我們必須自己找出如何應用這些規則。此外還要根據自己的情況，決定Scrum 中未定義部分的做法，像是如何撰寫程式碼，如何測試，這些都是建構產品所需的。因此它也可以說是一種架構（framework）。

Scrum的規則定義在《Scrum 指南》，第一版於2010 年發布，此後每隔1～2年就會有修訂內容，可以說《Scrum 指南》自己也是以反覆的檢驗和調適來更新的。本書以《Scrum 指南》2017年版為基礎進行解說，這是撰寫本書時的最新版本，而指南也仍會修訂，所以請視需要查詢最新版本

回頁首

基礎篇｜什麼是Scrum？
什麼是敏捷開發？
什麼是Scrum？
對功能和要求進行排序
誰是產品的負責人？
開發能用的產品
切成期間並重複
頻繁地計劃
完成每個Sprint
每天確認狀況
檢查成品
應該可以做得更好
幕後功臣
總結

實踐篇｜如何才能順利進行？
Scene No.00 開發產品概要及人物介紹
Scene No.01 將角色套用在工作現場
Scene No.02 了解目標所在
Scene No.03 建立產品待辦清單
Scene No.04 進行估算
Scene No.05 讓估算更可靠
Scene No.06 制定未來計劃
Scene No.07 制定詳細計劃
Scene No.08 迅速處理風險
Scene No.09 充分掌握狀況
Scene No.10 弄清楚完成了什麼
Scene No.11 讓預測未來更容易
Scene No.12 釐清下一步要做什麼
Scene No.13 敦促大家自律
Scene No.14 提高速率
Scene No.15 讓問題更容易發現
Scene No.16 事先釐清意圖
Scene No.17 支援Scrum團隊
Scene No.18 持續改善狀態
Scene No.19 始終清楚了解未來的情況
Scene No.20 消除重工
Scene No.21 逐漸接近目標
Scene No.22 應對各種情況
Scene No.23 做出更可靠的判斷

回頁首

鳳凰專案｜看IT部門如何讓公司從谷底翻身的傳奇故事 DevOps Handbook中文版｜打造世界級技術組織的實踐指南