敏捷品質管理：笨蛋！問題不在是否能做到「零瑕疵」，而是在「看待瑕疵的態度」

日前於敏捷課堂上，有學員問到，應不應把瑕疵（以下簡稱 bug ）列為用戶故事來處理？ 這個問題，其實可以分為好幾個層次來探討，我們就先從根源來談起吧！ 瑕疵該發生嗎？是理所當然的嗎？瑕疵可以放任多久再處理？瑕疵該以用戶故事紀錄、跟催嗎？

敏捷開發就是不用寫文件？該怎樣取捨？優缺如何？

敏捷開發中要不要寫文件是一個問題。該寫多少內容？該寫多深？這類文件製作「質」與「量」的問題，都應該回歸到該文件的原始初衷是什麼來思考。

誰能救救敏捷開發團隊裡的菜鳥？

「如果敏捷團隊中有菜鳥，是不是時間就會估不準？進度就會被延誤？」這個是課堂上常被提問的熱門議題。原因多半是提問者對「菜鳥是否有能力參與好這兩種活動」心存疑慮！現在我們就來看看，Scrum 敏捷式團隊合作方法有哪些設計可以解除或舒緩這種疑慮。

為什麼 Scrum 敏捷方法倡導「專職專注在一個專案上」

有位學員在課程的中場休息時間跑來問我 :「老師，我們公司都是一個人要同時負責好幾個案子的，你講的『專職專注在一個專案上』，根本就不可能實現的啊？那是不是我們公司就無法使用敏捷方法了？」 說實話，這兩個問題不只一個人問過，我相信，這必定也是許多對敏捷方法有興趣的人心中的疑惑。既然如此，我們就先來聊聊「一人專職專注在一個專案上」這個主題好了

被溝通工具疲勞轟炸? 讓敏捷方法拯救你的團隊效能

有了 email 、 Line 之後，大家用電話分機溝通的頻率就少得多了，同事之間面對面討論事情的機會也變得越來越少！而那些還喜歡用分機或是直接找人開會討論事情的，就算時間都控制得宜，似乎還是會不太受人歡迎。這到底是為什麼？為什麼大家總喜歡在 email 上你一嘴、我一句地，回過來又回過去，結果造成同一主題的 email 討論串愈來愈長，而每個收件人都變成是這一大群 email 轟炸的受害者......

什麼是「忙而不急」的上乘職場功夫？跟敏捷方法又有什麼關係？

我們之所以把專案團隊關在大會議室裡一起近距合作，目的就是希望專案團隊表現得像是「一個人」那樣，1 + 1 > 2，沒有多餘的內耗，就像上面武俠小說裡閉關練功的掌門人一樣。閉關中的敏捷團隊（掌門人）需要有能專注、不被任意打擾的環境，才能展現出超高的效率（練成蓋世神功）。 然而，組織當中一定會有許多意外事件或是新專案欠缺人力等事情發生（邪教來踢館），這些都會讓組織的中高階主管們想伸手去調動閉關中的團隊成員來因應，要他們同時兼顧兩三個專案（出關救門派）。雖然這是常見的兩難，但請務必深思這樣做的長期利弊與得失，會不會變成「賠了夫人又折兵」的窘境呢（掌門人

想導入Scrum 敏捷式方法，我該跟老闆溝通什麼？

導入Scrum 敏捷式方法，絕對會有痛苦，組織的病灶越嚴重，就該越痛！如果沒有感受到什麼掙扎，那麼，一定是在導入時出了錯！我認為，和老闆溝通，如何成功導入敏捷的兩大重點如下：