公司已經踐行了一段時間的敏捷開發，作為質量管理經理，我被老板指定為敏捷轉型的負責人。但是因為之前一直做的是瀑布模式，敏捷也是看了一些書和視頻后自己摸著石頭過河，所以現在有幾個問題希望能和大家一起交流一下
1、敏捷開發是否可以不寫檔案？
敏捷更提倡采用面對面交流的方式來代替傳統的全面的檔案
誠然，用嘴說當然比寫下來更快，效率更“高”，但是在實際使用中，我們發現采用面對面交流的方法，有時候“說”的人不一定能完整地闡述自己的意思，“聽”的人也不一定能夠完整地理解說的人想要表達的意思。資訊在口頭傳遞的程序中很容易失真，而萬一不巧發生了問題，又缺少記錄在佐證自己前期的觀點。
其次，在瀑布里面那種大而全的檔案或許拖累了當前的專案進度，但是當專案組涉及人員變更的時候，完善的檔案將是一個很好的知識傳遞工具，否則對于一些專案成員變更頻繁的團隊，作業的交接會是一場災難。
我認為檔案也是組織資產的一種沉淀和積累，目前我個人的實踐模式是讓大家在一輪sprint完成后，留一部分間隔時間讓大家專門去補檔案，但是我發現這種事后補出來的檔案往往質量不高，一些程序中的問題沒有得到完整的描述，從開發角度來說，一份事后補齊的檔案往往對公司有用但是對個人作用不大，因此也不太愿意花費太大的心思去保證質量。再加上為了“敏捷”起來，我目前要求的檔案是在瀑布的基礎上做了較大的“閹割”形成的，因此目前公司的檔案庫感徑訓累了一堆很尷尬的東西在那兒。
2、測驗提前介入，究竟需要怎么介入？
我不知道別的公司是怎么樣，但是就我們公司目前所處的條件來說，在拆分story的時候是很難保證獨立性的，我們公司沒有那種能夠前后端通吃的人，因此一個完整的story往往需要拆分成前端、后臺、甚至資料中臺三個task，而story與story之間也很難保證低耦合性，這就導致了我感覺很難實作那種完成一個story，提測一個story，測驗立即就某個story開展測驗
實踐程序中，我發現如果硬推所謂的“測驗提前介入”，開發往往會辯解到這個問題是因為xxx沒有開發完成導致的，或者開發在提測之前就會直接指明當前這個story雖然開發完成了，但是其中的xx功能、xx功能是不可用的，因為他們依賴于另外一個待開發或者開發中的story
這樣就很容易導致測驗作業的混亂，甚至發現了bug也不知道是否應該在bug系統上向開發提出，即使提出bug，開發也不管不顧，或許在幾個story都提測以后，bug自然就消失了，開發再將bug打回，白白浪費了人員成本
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/56965.html
標籤：敏捷開發