敏捷式專案管理課程心得
相關書籍早在之前看了不少，但第一次有機會可以實戰上課學習更深入的東西，也趁此把我自己的疑惑給弄清楚，實在是收穫不少。這邊就稍微筆記心得一下，畢竟敏捷相關的資料網路隨便一查實在很多，應該也不用我多做說明了。
導入敏捷真的比較好嗎？
先說結論，要做敏捷專案沒有想像中得這麼簡單，因為導入敏捷並不會因此比較省事，相對的可能要付出的時間跟心力可能更多，但好處是你會減少後續很多的風險成本。
若你不是軟體系統開發公司而是要在一般企業內導入的話，你首先會面臨到很大的挑戰就是人的問題 (但就算是軟體公司好像也是多數都是人的問題 XD)，由於敏捷是一種短期不斷衝刺、改善的一種流程作業，因此每個人每1-2週就要做一次product demo、review，在每個人的工作會增加很大的壓力，試想原本做好在demo就好，現在變成做好一小部分就要demo一次，然後有問題就要改，應該沒人喜歡這樣才是 XD
但這也就是敏捷的精神，敏捷就是一種思維、一種習慣並且不斷的改善的流程。
我可以從什麼地方開始著手？
若你們想要開始嘗鮮導入敏捷，我個人覺得比較好的方式有兩個
- daily meeting
- user story
在敏捷裡面這個daily meeting是整個團隊每日早上花大約15min時間進行會議，由開發團隊每人逐一報告昨天的工作進度 (所以沒進度的人應該會覺得很丟臉，透過這樣的方式可以讓成員相互激勵)，但報告過程中S.M、P.O甚至其它團隊都不能打斷插嘴，其目的就是讓每一成員把工作進度讓團隊其它成員知道，若成員遇到任何問題則由S.M (Scrum Master)負責記錄並找機會協助解決。
雖然daily meeting在敏捷裡面是在sprint meeting裡面才做，但我覺得這東西應該是最好入門的地方，另外一個則是user story。
一般我們在開發系統過程中，不外乎就是制訂好系統規格在請程式設計師依據此規格開發系統，但很有可能這個窗口在制訂規格時誤解了使用者需求，而或者後端的程式開發人員若是可以知道使用者實際使用的環境、狀況或是時機，說不定他會有很多更好的想法，也因此若是可以透過User Story的方式來呈現交付給程式開發人員，也可以避免很多無意義的浪費。
一張便利貼三行就可以寫完這個user story，而在背後則是寫下驗收條件規則，非常的容易上手及方便。
結論
雖然不見得人人公司都有開發環境，但我覺得敏捷精神其實可以用在其它地方，包含你的工作進度報告、團隊合作等都很有空間可以導入使用，畢竟敏捷的精神之一就是不斷的在期初就調整修正成實際的真正需求，以避免後續產出成真正產品後的修改浪費，但專案除了技術系統外的問題，另外一個則是人的問題，團隊、客戶之間的溝通也是潛在的問題之一，甚至我覺得與人的溝通問題才是第一位，有時候不管是哪一種技術其實都好，只要人搞定了其它都不是問題，你說是嗎？