莊周夢蝶

    我們現在做的項目是典型的小型項目，整個組也就4、5個人，一個迭代周期基本在兩周左右。盡管沒有明確有“迭代”這么說法，卻是以業務人員的策劃案做分期實現。這個分期，按我的理解其實就是迭代。最近發現的一個問題是，在迭代開始后，業務人員卻沒有辦法保證需求在這個迭代周期完成前的穩定性，甚至在各個模塊集成之前，大家就提出N多意見，并且這些意見很多時候都是前后矛盾的。特別是在客戶端的開發上，顯然，客戶端UI和操作習慣方面是最多變的地方。可憐我們公司唯一的MM程序員快陷入變更頻繁的泥潭了，改過去改回來是家常便飯。其實也是她過于老實，要我來說，你們要改，可以，但是我要向業務人員確認，他是我唯一的變更來源，你們有什么需求向他反應，他來收集和甄別。在《敏捷軟件開發》中說到，迭代開始后，客戶就同意不再更改當次迭代中的素材的定義和優先級別，可惜這一點貌似很難做到了，業務人員經常屈從于管理層或者其他小組意見的壓力。在我看來，在當次迭代完成前的所有建議或者說需求，都可以收集起來，由業務人員負責收集、甄別和決定，放入下一個迭代版本的開發，因為我們的迭代周期一般也在兩周左右，這個周期足夠辨別這些需求的合理性和響應需求的及時性，而不是像現在這樣大家七嘴八舌地提意見，技術人員疲于奔命，乃至于發脾氣（入夏真是脾氣壞的季節）；系統各部分遲遲無法進行集成測試，造成新的修改意見沒有做完，預定的迭代版本的更無法按時完成的局面。