---
# System prepended metadata

title: 軟體開發要點 敏捷
tags: [軟體開發, 敏捷, 團隊]

---

軟體開發要點 敏捷
======

###### tags: `敏捷` `軟體開發` `團隊`

- 2021/11/24 **專案重做的限制理論與刻意發現 (Ruddy 老師)** https://www.youtube.com/watch?v=API3pxBo3tM
    - 專案開始之初, 首重看見全貌
    - 當你把眼光投注在某個要項時, 實際上你就只看的到那一部分
    - 你的思緒被那部份給牽動, 很難再看見其它事情... 所以我們要退後一步
    - **不, 有時要退後很多步....**
    - 敏捷的素養與程式寫的好壞有關係嗎?
        - 敏捷的素養: 是帶來正確的方向, 產品比較容易走向對的方向. 因為需求方向可能是錯的, 所以用**小增量多迭代來提早發現**.
        - 寫程式的素養: 是正確的重構, 因程式不可能會一次到位. 所以即是: **做重構且一次次速度越來越快, 品質越來越好**
        - 專案常常再重做, 這裡的重做不是重構. 而是整個重新來, 比如說 專案A 完成了, 專案 B 啟動了.
    - 這裡就有個問題, 專案從做會怎麼樣? 經驗有累積嗎? 知識有累積嗎?
    - 客戶的需求訪談與確認 通常會**不知道方向錯誤**或者**領域知識不足**, 導致需求調整或做出來的功能不適合客戶
        - 所以一次一次一點交付. 能夠及時修正方向給出更好品質的功能.
        - 敏捷的核心就是把專案切成很多迭代, 進而**讓未知的部分盡早出現(刻意發先無知)**.
    - 影響地圖 (面對無知時的策略)
        - PO常常困擾於不知道要怎樣設計衝刺的增量才能符合敏捷開發所謂的小增量、多迭代的開發方式。影響地圖(Impact Mapping) 這個工具正可以協助你運用目標導向方式來規劃你的增量。
    - 約有 1/4 ~ 1/2 的專案從做時, 專案完成的速度是不變的. Why?
        - 通常表現在較複雜的專案
        - 知識沒有累積
        - 有問題沒有發現
        - 慣性用相同方法

- 2021/11/26 **91APP的軟體開發之道—從20人到200人的組織發展旅程** https://happylee.blog/91appway/
    - 敏捷開發是不錯, 但不要忘記初衷
    - 敏捷的核心其中一項, 是團隊裡每個人**賦予同樣的責任**
        - 如果使用敏捷, 卻還是使用以前用 PM 在主導每個任務中的實作細節, 那不稱為敏捷.
        - 因為身為主管所以事事都想干涉，一直嘗試想安排每一件事（上帝之手一直收不回來），而忽視了「團隊自主」是敏捷裡面很重要的精神。
        - 團隊有自己自主的權利，相對就有責任。團隊要為自己的決定負責，團隊有團隊的責任感，對自己的責任範圍的產品的成敗負責。
        - 賦予權力讓團隊成員對團隊的認同感強，向心力也強，團隊內會形成很亢奮的工作氛圍
        - 91APP 是以 Domain knowhow 去切分團隊 => 金流、電商、會員
    - **把 agile team 變成部門, 賦予實權**
        - 想想以前公司的部門, 沒分那麼細. 大概就是 PM/SA、工程師、美工
        - 以91APP來看, 以前是以軟體職責去切分部門 => PM、UX、RD、QA 四個部門
        - 所以以前的敏捷團隊, 是跨部門的同仁組成. 但是變成同仁同時要看 **團隊方向** 跟 **部門方向**, 可能有時候還有衝突呢
        - 91APP 還有設計領頭羊的 One Team, 概念上是制定產品方向與策略. **讓各敏捷團隊有方向可以遵循**

- Agile 核心思想:
    - 【增加團隊價值交付的系統化思考】
    - 【識別產品交付的不確定性與複雜性】
    - 【自我管理團成長所需的能力與協助】
    - 【服務團隊的領導角色與思考方式】