當我們對敏捷團隊有一些概念後，我們還需要了解在敏捷開發中重要的幾個事件，以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。

職場產業

學習

投資理財

<p>當我們對敏捷團隊有一些概念後，我們還需要了解在敏捷開發中重要的幾個事件，以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。</p>
<h2>What 與 How</h2>
<p>在敏捷開發中，我們會有 What（為何）以及 How（如何）兩個不同的任務需要進行，從 What 開始了解使用者的需求、實現產品的目的，最後再由 How 的階段根據我們理解的知識，實現「必要」的功能。</p>
<blockquote>雖然課程中有許多「案例」然而我們還需要思考對於組織中，怎樣的 Scrum 才是我們所需要的，這也是一種 What 的應用。</blockquote>
<h2>敏捷流程</h2>
<p>敏捷開發大多是圍繞著衝刺（Sprint）所進行的，當我們從使用者收到各式各樣的需求後會放入 Product Backlog（產品積壓）之中，接著等待我們透過衝刺的方式進行消化。</p>
<h3>Sprint Planning 1</h3>
<p>開發產品並不是漫無目的的進行，因此衝刺的第一階段計畫是由 PO（Product Owner）以及團隊和使用者一起開會進行討論，目的是將 Product Backlog 中的 User Story（需求）轉變成一個項目（Item）並且釐清需求。</p>
<p>也因此，我們會先嘗試將這些需求拆分成足夠小的 PBI（Product Backlog Item）並且跟 PO 一起討論目的、實現範圍、無法確定的假設以及「關鍵案例（Key Examples）」來幫助我們理解這些需求想要解決怎樣的問題。</p>
<p>除此之外團隊也會給予 PO 一個估算（Estimate）來作為排序的參考之一，這個估算會結合過去的經驗與團隊的經驗提出，然而並不代表實際上花費的時間。</p>
<h3>Sprint Planning 2</h3>
<p>當我們對於功能有一個相對清晰的了解後，每個團隊會嘗試將認領到的 PBI 進行拆分，轉變為任務（Task）此時也比較容易對單一任務有一個相對具體的時間估算。</p>
<p>然而，我們很可能會需要跟其他團隊協力解決問題，也可能因為對 Domain（領域）的不熟悉，而無法順利完成 PBI 的項目，因此團隊會根據狀況退回或者追加項目來調整到能夠順利完成衝刺的狀態。</p>
<blockquote>在 Scrum 中，我們會不斷的嘗試以及和其他團隊合作、溝通，因此會互相依賴以及學習，並且也需要處理任務的衝突。</blockquote>
<p><br></p>
<p>封面圖片使用 <a href="https://unsplash.com/s/photos/minimal?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" target="_blank">Unsplash</a> 上 <a href="https://unsplash.com/@furtado?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Felipe Furtado</a> 的作品，<strong>這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神</strong>，看關於技術的主題可以到<a href="https://blog.aotoki.me/" target="_blank">弦而時習之</a>找找靈感。</p>
<p><br></p>

在敏捷開發中，我們會有 What（為何）以及 How（如何）兩個不同的任務需要進行，從 What 開始了解使用者的需求、實現產品的目的，最後再由 How 的階段根據我們理解的知識，實現「必要」的功能。

雖然課程中有許多「案例」然而我們還需要思考對於組織中，怎樣的 Scrum 才是我們所需要的，這也是一種 What 的應用。

敏捷開發大多是圍繞著衝刺（Sprint）所進行的，當我們從使用者收到各式各樣的需求後會放入 Product Backlog（產品積壓）之中，接著等待我們透過衝刺的方式進行消化。

開發產品並不是漫無目的的進行，因此衝刺的第一階段計畫是由 PO（Product Owner）以及團隊和使用者一起開會進行討論，目的是將 Product Backlog 中的 User Story（需求）轉變成一個項目（Item）並且釐清需求。

也因此，我們會先嘗試將這些需求拆分成足夠小的 PBI（Product Backlog Item）並且跟 PO 一起討論目的、實現範圍、無法確定的假設以及「關鍵案例（Key Examples）」來幫助我們理解這些需求想要解決怎樣的問題。

除此之外團隊也會給予 PO 一個估算（Estimate）來作為排序的參考之一，這個估算會結合過去的經驗與團隊的經驗提出，然而並不代表實際上花費的時間。

當我們對於功能有一個相對清晰的了解後，每個團隊會嘗試將認領到的 PBI 進行拆分，轉變為任務（Task）此時也比較容易對單一任務有一個相對具體的時間估算。

然而，我們很可能會需要跟其他團隊協力解決問題，也可能因為對 Domain（領域）的不熟悉，而無法順利完成 PBI 的項目，因此團隊會根據狀況退回或者追加項目來調整到能夠順利完成衝刺的狀態。

在 Scrum 中，我們會不斷的嘗試以及和其他團隊合作、溝通，因此會互相依賴以及學習，並且也需要處理任務的衝突。

封面圖片使用 Unsplash 上 Felipe Furtado 的作品，這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神，看關於技術的主題可以到弦而時習之找找靈感。

LeSS in Action - 學習敏捷（計畫）