“我是 David G。我目前負責軟體工程。我在兩家不同的公司經歷過方法論的變化。 “當我讀到他的故事時，我很想分享David G.的經歷，或者一個充滿善意的人遇到一個不願改變心態的故事。因此，在他的前雇主（一家服務公司）中，他尋求改變開發方法，並考慮到向極限編程的過渡。「這家公司已有十年歷史。順序法已經使用了很多年，據管理層稱，該公司表現非常好。”，他斷言，開發商對工程品質差、條件差、不遵守最後期限的爭論只會導致他的上級做出簡潔而無關緊要的回應：“是的，我知道。”儘管如此，大衛還是決定與同事一起開發一個整合迭代方法和極限程式設計元素的框架：最令人煩惱的是透明度。無法要求客戶派代表到生產現場。官方說法：這就像要求他自己做這項工作一樣。「事實上，最令人不安的是客戶一直在場，他可以看到整個生產過程。這很可怕，尤其是當你將完成一個專案的實際工日數乘以三時。從商業角度來看，這代表著一種危險。關於成本的銷售謊言更加困難。你如何讓客戶在現場時相信需要三週，而看到需要十天？儘管對一個項目進行了結論性測試，但蛋黃醬卻出現了其他問題，例如：” 如何將迭代融入規範？ “或者「我們應該在多大程度上結對工作？ “今天，大衛已經累積了經驗。他當然離開了這家沒有為他帶來任何好處的公司，甚至在另一家公司經歷了開發方法的成功變革。如果這個故事發生在一家服務公司，那麼它很可能發生在一個大型IT 部門。的人一起工作。下一篇專欄將於 9 月 10 日星期一
