上次說到了我們在專案中「敏捷溝通」的實踐，順著再補充幾點專案過程中的敏捷實踐。
任務認領，我們沒有完全實施，現在是利用開發經理對工程師能力的了解安排任務。任務認領的假設是：每個人都是足夠聰明和職業的，應該被安排在最合適的工作上，所以最了解自己能力的就是自己，於是應該每個人制定自己的工作計畫，其他人幫著定都是不優的。相對而言，任務認領更適合工程師文化的特種部隊式團隊，比如google。
需求評審，有的團隊在需求評審會的時候，讓開發工程師來講述他要開發的那部分功能的prd（含uc），pd來提問。對比更經典的pd講述，開發提問的方式，這樣做有兩個好處：一是逼著開發認真看prd；二是可以省去設計評審，相對pd講述prd的傳統方式而言，開發講述的方式下，不做設計評審的風險降低。
結對程式設計，我們還沒魄力嘗試，相信國內也很少有團隊敢嘗試。一位開發經理對我說其本質是兩個人互相監督，沒法偷懶以提高效率，更重要的是，這種效率的提高還伴隨著**質量、可讀性的提高，從而完全可以抵消表面的「做事的人少一半」帶來的損失。
測試驅動，我們有很強很嚴謹的測試，會利用tc編寫、tc評審、甚至測試執行的過程來補充和細化需求，比如一些限制條件、異常流程等等，往往都是測試的同學提出來的。
冒煙測試，編碼完成後，測試的同學會馬上做冒煙測試，目的是確認產品基本功能正常，可以進行後續的正式測試，冒煙完成後立即進行產品演示會，叫上專案干係人來檢視產品是否符合期望，符合「盡早交付」的概念。
關於加班，我一直讓開發經理、測試經理評估資源的時候留一點餘量，甚至我在排專案計畫的時候會再留一點，但每次看上去仍然還是在加班，也許是大家不習慣一下班就走，反而喜歡上班時不時看會新聞，晚上時不時做點工作的方式吧，不管給多少時間，任務總是在最後一刻完成，呵呵。
你在的團隊有什麼好的實踐麼，不妨也說出來給大家看看。
產品設計體會（3014）敏捷實踐的一些過程項
上次說到了我們在 專案中 敏捷溝通 的實踐 順著再補充幾點專案過程中的敏捷實踐。任務認領，我們沒有完全實施，現在是利用開發經理對工程師能力的了解安排任務。任務認領的假設是 每個人都是足夠聰明和職業的，應該被安排在最合適的工作上，所以最 了解自己能力的就是自己，於是應該每個人制定自己的工作計畫，其他人...
敏捷實踐之敏捷與OKR的一些探索
敏捷落地在我們團隊落地已經接近五年了，作為乙個相對成熟的團隊，不少問題也浮現了出來，比如不少團隊成員對於未來缺乏長期規劃和工作上也相對的缺乏熱情和激情。團隊大多都忙於應對專案上的工作，對於個人自身的成長關注度不足，存在溫水煮青蛙的危險。最近一直在尋找合適的手段來幫助大家突破困局，再一次啟用團隊，發現...
css modules的一些實踐
本人使用vue引入css modules做實踐。vue文件檢視 以及 簡單的配置css loader 然後上新增module屬性，就自動生成乙個 style的計算屬性可以用了 template p class style.red span class style.redbg this should ...