上次說到了我們在 專案中「敏捷溝通」的實踐
，順著再補充幾點專案過程中的敏捷實踐。
任務認領， 我們沒有完全實施，現在是利用開發經理對工程師能力的了解安排任務。任務認領的假設是：每個人都是足夠聰明和職業的，應該被安排在最合適的工作上，所以最 了解自己能力的就是自己，於是應該每個人制定自己的工作計畫，其他人幫著定都是不優的。相對而言，任務認領更適合工程師文化的特種部隊式團隊，比如google 。
需求評審，有的團隊在需求評審會的時候，讓開發工程師來講述他要開發的那部分功能的prd （含uc ），pd 來提問。對比更經典的pd 講述，開發提問的方式，這樣做有兩個好處：一是逼著開發認真看prd ；二是可以省去設計評審，相對pd 講述prd 的傳統方式而言，開發講述的方式下，不做設計評審的風險降低。
結對程式設計，我們還沒魄力嘗試，相信國內也很少有團隊敢嘗試。一位開發經理對我說其本質是兩個人互相監督，沒法偷懶以提高效率，更重要的是，這種效率的提高還伴隨著**質量、可讀性的提高，從而完全可以抵消表面的「做事的人少一半」帶來的損失。
測試驅動，我們有很強很嚴謹的測試，會利用tc 編寫、tc 評審、甚至測試執行的過程來補充和細化需求，比如一些限制條件、異常流程等等，往往都是測試的同學提出來的。
冒煙測試，編碼完成後，測試的同學會馬上做 冒煙測試
，目的是確認產品基本功能正常，可以進行後續的正式測試，冒煙完成後立即進行產品演示會，叫上專案干係人來檢視產品是否符合期望，符合「盡早交付」的概念。
關於加班，我一直讓開發經理、測試經理評估資源的時候留一點餘量，甚至我在排專案計畫的時候會再留一點，但每次看上去仍然還是在加班，也許是大家不習慣一下班就走，反而喜歡上班時不時看會新聞，晚上時不時做點工作的方式吧，不管給多少時間，任務總是在最後一刻完成，呵呵。
你在的團隊有什麼好的實踐麼，不妨也說出來給大家看看。
產品設計體會（五一） 敏捷的估計與規劃
前段讀了 敏捷估計與規劃 這本書很適合開發經理看，我只是很快的瀏覽了一下，摘錄一些體會。敏捷的里程碑是功能驅動的，先完成可交付的最 重要 功能，重要取決於功能商業價值 生命週期 實現難度等綜合的結果。而傳統的瀑布模型的里程碑是任務階段驅動的，到了專案 50 的時間，可能進入 編碼 但對客戶來說，等於...
產品設計體會（五一） 敏捷的估計與規劃
前段讀了 敏捷估計與規劃 這本書很適合開發經理看，我只是很快的瀏覽了一下，摘錄一些體會。敏捷的里程碑是功能驅動的，先完成可交付的最 重要 功能，重要取決於功能商業價值 生命週期 實現難度等綜合的結果。而傳統的瀑布模型的里程碑是任務階段驅動的，到了專案 50 的時間，可能進入 編碼 但對客戶來說，等於...
產品設計體會（二九） 產品設計的五個層次
其實這篇是 使用者體驗的要素 的讀後感，其實讀了已經快2個月了，剛讀完寫讀後感會比較全面，而事隔一段時間再寫就能看出哪些是真正沉澱下來的要點了，也算是給自己找個偷懶的理由吧。大產品設計決定使用者體驗，而小產品設計又分為五層，帖一張業內著名了好幾年的圖。戰略層 明確商業目標和使用者目標，重點是解決兩者...