薄薄一本書，但許多章節都讓人產生共鳴，
大師果然是大師，位在頂端的視野，
描述一路走來的困境與對應方法，
即使方法不一定正確，但能讓一個人成為大師，
我想這些方法也不會差到哪去。
非常值得一看，這邊列出幾個闔上書之後還印相深刻的重點。
團隊合作
在看這本書之前，
我就對於公司內部的團隊配置頗有意見，
現況是一件專案來了，專案負責人變會開始去找他想配合的成員，
來完成這項專案，專案一結束，這些人員很大機會被分配至其他專案，
無法同一批人再繼續合作進行下一個專案，甚至很大的機會是一人專案。
這樣會導致什麼問題？
當專案結束後，原本建立起來的團隊默契，無法再度被利用，
實在非常可惜，例如我在apple專案與A工程師搭檔，
我們互相配合，了解彼此之間的介面如何定義，
甚至也彼此了解軟體架構的習慣，因此如果軟體執行有bug時，
問題馬上可以釐清再誰負責的部分，假使是A工程師負責的，
也不需要把A工程師叫來身邊找問題，
自己也能夠依照彼此的默契與習慣大略知道問題在哪，再提出修改建議給A工程師，
不會因為不是自己的負責範圍，而讓進度延遲。
效率大大的提升，配合越久，效率越高。
從專案角度來看，如果團隊之間成員沒有彼此了解負責的業務(可透過codeReview建立)，
都只專注在自己的部分，長期下來，團隊成員便無法互相成長，
其中如果有成員離職、請長假，而該業務範圍又出狀況，也沒人可以應付。
團隊的好處有太多，完全在第十三章被描述出來，
好希望主管單位能夠看到書中這第十三章進而修改團隊執行模式，
但會被寫在書上的，往往都是最理想、也最不可能被實現的部分吧。
職場應對的建議
書中其他章節也提供了非常有用的建議，
如何say no , say yes，
如何判斷時程，
如何做出承諾等等，
都是在描述一個理念，
「態度必須堅定，回答任何問題都不能有模糊空間，必須相信自己的專業」。
而這些如何實踐?
基礎都在於讓你的程式碼非常有說服力，
而產生說服力的方法，就是透過"測試"。
有效率的專心方法
另一個我印象非常深刻的建議，
則是作者不建議我們進入心流，
一開始我很訝異，進入心流狀態不是效率最高，生產力最好的時候嗎？
但他便舉了例子，說明這樣的狀態的確讓生產力達到高峰，
但也很容易進入盲區，關注的範圍便少了，導致要考慮的層面也變少了，
寫出來的作品往往還需要再大量修改，
克服這種情況最好的方法就是 – 結對設計 ( Pair Programing)。
但如果沒人可以陪你一起寫程式怎辦？
我自己的習慣則是選擇回覆訊息，你可能會認為同時在兩件事情穿插不是很沒效率嗎？
但我自己的經驗來說，這樣反而讓我效率更好，思考層面也更廣，
讓另一件不需要花太多腦力的事情協助你保持專注力的廣度，我想應該不會造成太大的負擔。
輔助工具
作者列了許多輔助工具，
其中測試工具佔了大多數，我把他列出來，讓自己一項一項的去學習與摸索，
如同大師提到的學徒時期(剛踏入工作階段)與熟練工時期(約五年經驗)，
我在學徒時期沒有人來引導，現實壓力也不大，導致學習態度較散漫，
如今感受到了現實生活的壓力，再慢慢進度熟練工時期後，
必須開始把學徒時期該會的工具給熟悉起來，
並以目前熟悉的工具，擴展學習其他工具，讓自己更全面。
會議
最後一個印象深刻的建議，
便是作者建議不要參與太多會議，盡量縮短再10分鐘以內，
和我認知的敏捷開發內的會議模式一樣，講重點，讓大家有更多時間做該做的事，
可惜事與願違，會議動輒兩三小時，
如同我在上面說的，書上提到的建議，
往往就是現實面最難達成的部分。
結論
作者不斷地提倡 TDD 與 Pair Programing ，
很可惜現實不容易達成，而我也努力改變公司環境，
推動工具的使用，與主管建議合適的團隊模式，
希望能慢慢走向大師建議的路，並奔跑起來。
=========================
[持續建置工具]
Jenkins
[單元測試工具]
JUnit [JAVA]
NUnit [.Net]
Midje [Clojure]
C/C++ [CppUTest]
[元件測試工具]
FITNESSE
RobotFX
Green Pepper
JBehave
Cucumber
[GUI的測試工具] [作者不建議透過GUI進行測試，但還是有一些測試必須經由GUI來完成]
Seleium
Watir
[UML/MDA]
沒有留言:
張貼留言