改變工作習慣真難
Anthony Tsai
下面是我的工作現況。自從上了您的課後，我一直覺得有必要再深入探索及學習。以期待未來我是個小主管後，能真正run一個敏捷的團隊。下一個工作我應該
會特別注意團隊的開發方法，以期待有更多實際的體驗來印證及傳播老師的工法。
目前在一家系統整合廠商服務，我所在的部門是負責資訊系統開發，共有1位主管、1位管理師、8位工程師。部門主要是解決客戶內部流程電子化所產生的客製
化需求、內部人員使用產品管理系統時的五花八門需求。
從User 所描述的 Scenarios 中主管會和包含我在內的5位PG進行討論，之後便各自為自己的任務進行探索、開發並完成任務。每週開會報告
進度及問題，以便讓主管掌握進度。
然而如同一般團隊的問題：上線時程、人力分配、開發方法、組織文化等等在我們的團隊中也都會發生。
目前的團隊主要的開發語言是Java，物件導向的開發方法已經使用在我們的團隊中。所有的團隊成員雖然都是處理同一個領域的問題，但各自處理自己的問
題，也因此就失去了團隊合作及很難進行Code review，因為每個人都在忙，根本沒時間來做這個動作。當然在甚少團隊合作的動作下，就會忽略軟體
開發中除了完成功能設計外，功能內聚、模組藕合的重要性。
在敏捷方法的學習中，我們知道溝通、以及程式碼(產品)產出的品質重要性; 而團隊中的人數、案件規模大小及成員的程度等等都很適合使用敏捷方法，因此
我曾向主管建議採取敏捷方法開發、維護我們的資訊系統。最後討論的結果仍然因為廠內辨公硬體設施的規劃設計並不允許我們進行頻繁溝通、敏捷方法並沒有所
謂的操作手冊、標準流程不容易讓守舊不變的資深成員接受以及敏捷方法取決專案的特性再予以調整步驟的彈性，因此蹤然知道有很多好處也是沒被主管接納。其
主要的原因就是：沒辨法輕易的讓團隊成員使用敏捷方法取代習以為常的慣用方法或開發流程中。
綜合上述，我認為要改變現在的體制、作法，除了要公司硬體環境支援外，若能有短期Workshop的實作可以體驗會更好。一般來說新的建置從無到有最
難，唯有展示更多團隊從無到有轉型成功的例子才能漸漸讓不願改變的人放下懷疑。
duncan