敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？

綜合本系列之前的文章，Scrum 其實就是一個小團隊（約5-9人），利用一個個固定短週期的衝刺（Sprint），跟客戶一同逐步漸進地，完成一個產品，而這個產品的功能，就是由一個個，由客戶主導、撰寫的用戶故事（User Story）來呈現需求的（關於用戶故事的簡要陳述，有興趣的朋友可以先參考一下《能讓需求簡化，還能更省時、更省錢，提供更多價值》這篇短文，容日後有空再專文細述之）。

敏捷方法的成功密技（八）：Scrum 的衝刺時間長短怎麼訂？

一個衝刺（Sprint）的時間長短到底應該是多少才是最好的呢？如果衝刺的時間設定得太長，那麼，應變的彈性就會變得比較小，而如果衝刺的時間設定得太短，那麼，又容易讓開發團隊能產出的成果出問題。怎麼說呢？

敏捷方法的成功密技（七之二）：Scrum 的夢幻開發團隊該怎麼來建置？

接續上一篇文章《敏捷方法的成功密技（七之一）》，除了新領域、新團隊，最有機會嚐試新作法之外，我們也談到了，只要開發團隊夠紮實，產品的開發就能夠打帶跑，因為品質才能夠被掌控得好。怎麼說呢？  

從PM的角度淺談test case的應用

在PMBOK（註1）的定義裡，完整的品質管理計畫包含「品質保證」（Quality Assurance, QA，中文簡稱「品保」）與「品質管制」（Quality Control, QC，中文簡稱「品管」）兩個面向，其中，品保的目的是確保產品交付的品質，例如軟體開發專案中，交付的軟體是否能符合規格文件內所定義的功能。在編制完整的組織內，也可能會有QA這樣的角色（Quality Assurance engineer，即品質保證工程師），協助PM檢驗產品品質。

敏捷方法的成功密技（七之一）：Scrum 的夢幻開發團隊該怎麼來建置？

在上一篇文章〈敏捷方法的成功密技（六）：Scrum Master  並非你想像的那般卑賤！〉中，我們談到了 Scrum Master 這個角色，其實最好是由一位開發和管理經驗豐富的人來擔任，工作經歷不足的菜鳥，是很難勝任得好，更很難以服眾的。接下來我們就來看一下，為什麼 Scrum 又要特別定義出「開發團隊（Development Team）」這個角色呢？

讀《沒有Email的世界》：少了Email之後，工作會變得更高效嗎？

你對 Email 有什麼看法？一項調查顯示，人們對 Email 的感受是「我討厭自己永遠都無法『離線』」、「我疲憊不堪，只是勉強跟上」、「有了它，我在工作日變得更孤立……我不喜歡這樣」、「我無法克制時常要檢查它，它讓我變得低落、焦慮、沮喪」。這個曾經方便又快速的數位工具，到底出了什麼問題？

《關鍵突破》選摘：利器四──訓練自己的「修補」能力和思維

「如何管理人生」是每個人一生必學的功課，從面對人生中大大小小的困難開始，學習如何調整心態，探究問題的本質，最後透過「解決之道突破問題的關鍵」，順利解決問題，讓人生更進一步。這個「突破關鍵」的過程，就是看懂局之後的破局之道。我們特地挑選了吳靜思撰寫的《關鍵突破》這本書，她藉由眾多頂尖人士的故事，解析出如何看懂局，以及如何培養解決問題的「利器」，分享給你，希望對你有所啟發。