March 11 12:36~13:47
▲Ada：我有問題！
可是思維
成立泰迪軟體這些年，教過的學員也有數幾千人次。Teddy很歡迎學員發問，從問題中可以了解學員的困難以及學習狀況，也可以檢驗自己的知識是否足以回答問題，並刺激自己思考的角度。
但有一種學員的反應讓Teddy很無言，Teddy稱之為可是學員，他們總是在聽了你的建議之後，經常使用可是作為拒絕改變的藉口。
***
可是學員：我們軟體的bug很多，有沒有什麼做法可以改善這個問題？
Teddy：你們有寫單元測試嗎？
可是學員：沒有。
Teddy：是不是可以考慮先從寫單元測試開始，至少可以確定基本軟體元件的正確性。
可是學員：可是我們工程師都沒時間啊，程式就寫不完了不可能要求他們寫單元測試。而且他們也不知道怎麼寫，專案時程那麼趕也沒時間讓他們學。要讓他們寫單元測試這不可能啦。
Teddy：Code review呢？
可是學員：可是我們工程師程度都不好，沒有能力review別人的程式。
Teddy：難道都沒有資深工程師嗎？
可是學員：是有幾位資深工程師，可是他們覺得code review很浪費時間，沒人想做。
Teddy：是不是可以跟團隊成員溝通，透過code review可以協助資淺人員能力成長，改善產品品質，提升整個團隊的能力？
可是學員：可是公司也不想浪費資深人員的時間，畢竟他們的薪水比較高。公司希望他們專心開發核心程式，而不是花時間去幫其他人做code review。
Teddy內心獨白： （我的棍子放在哪裡！）
Teddy：有試過Pair Programming嗎？
可是學員：我在社群活動中有聽過Pair Programming介紹，可是公司一定不會同意。專案那麼趕怎麼可能讓兩個人一起寫程式，這不可能，打死都不可能。
Teddy：那……找QA或工讀生，用人工測試呢？
可是學員：可是公司根本沒有QA部門，也不可能撥預算找工讀生來測試。
Teddy：那還有一招，外包給客戶，請客戶幫你們測了。
可是學員：我們現在就是這樣啊。
***
挑戰現況
凡事把可是兩字掛在嘴邊，很可能是一種不思改變只想找藉口拒絕改變的反射性動作。如果只是朋友之間互相訴苦，並不是真的想解決問題，那倒也無妨。但若是工作上遇到問題也抱持著這種心態，就無法突破現況並有所改善。
軟體工程，特別是敏捷實務做法，並不是什麼艱深理論，都是經過多年、多人、多團隊、多公司的實務經驗。也許這些經驗與你自己目前狀況不符，但也不要立刻否定，先把它當成一種假設，然後思考要做出何種改變、要如何努力，才有可能讓假設成真。
學員：我們軟體的bug很多，有沒有什麼做法可以改善這個問題？
Teddy：你們有寫單元測試嗎？
學員：沒有。
Teddy：是不是可以考慮先從寫單元測試開始，至少可以確定基本軟體元件的正確性。
學員：我們工程師都忙到沒時間，程式寫不完了要如何讓他們願意寫單元測試？
Teddy：你們應該是把寫production code和test code 看作是兩件事，而工作上只有要求完成production code即可，才會有這種「程式都寫不完了哪有時間寫測試」的想法。
學員：對啊，不都是這樣嗎？
Teddy：我認為單元測試是開發不可分割的一部分，所以做完的定義不是只有production code寫好就可以，應該也要包含足夠的單元測試。這在敏捷開發（Scrum）裡面叫做DoD—Definition of Done。藉由調整DoD（逐步增強），可以改善團隊的產品品質。
學員：聽起來滿有趣的，但我們團隊目前都沒有這樣的觀念，還是停留在犧牲品質以便趕上進度的狀況。短期間或許可以交差，但是對公司來說中長期發展會受到傷害。像最近客戶對於品質不良的抱怨聲音就很大，而且團隊成員工作也沒有成就感，流動率很高。
Teddy：解決方法不一定只有或只是單元測試，還有很多種解決方案，依據你們專案的情境（Context）可以選擇不同的方式。
學員：我回去跟我老闆討論一下，看看有沒有可能找一個新的小專案來試看看，做出一些改變。
***
想解決問題但卻不想做出任何改變，只想從別人口中聽到「你好辛苦」、「你好委屈」、「你好棒棒」、「公司好爛」、「同事好混」這類的話，那還是不要開口問Teddy問題好了。
***
友藏內心獨白：這樣不就不溫柔了XD。
