I'm CaLendarW Blog

公司呢排有計劃要封鎖 Instant Messenger, 主要係 MSN, 而個計劃都差不多要實行, 但大部份既同事們亦已整裝待發地尋找其他辦法, 對我黎講, 無左 MSN 的確係有 d 唔方便, 而封鎖 MSN 亦都不是一個最佳既辦法. 自己覺得, 對運作既部門黎講, 封鎖 IM 的而且確係可以提高生產力, 但對開發團隊我又未必同意, 因為開發同運作唔同, 所以我唔讚成 block IM.

可能因為呢排日日返工放工都睇住本 Art of Agile Development 既關係, 諗既野都會由 Agile 方面出發. 而其中一個最好既解決 IM 方法係 – Pair Programming, 只要兩個人一齊, 不必要既活動就會減少, 而因為 Pair 既時間係 Design, Coding 同 Testing, 咁只要完成晒手頭上既工作, 咁員工喜歡做什麼就應該比佢自由. Pair Programming 既好處有很多, 例如: 提高生產力, 提高質量, 提高可用度, 監察及教育等.

因為 Pair Programming 有監察既用途, 在生產過程中不必要既 “工作障礙” 亦會減少, 而因為兩個人一起 Design 同寫 Code, 只要兩個人用心去寫, 質量就會提高, 而且有時候有些地方表面上好似做完, 但多個人諗下就可能會發現唔完善, 加上兩個人諗既野, 多個意見, 可以提高軟件既簡潔性, 對軟件既質量有十分好既改善, 而且 Agile 講求既係溝通, 經過兩個人溝通後所創既成果就會愈來愈好.

在教學方面, 因為係兩個人一起 Design 同 Code, Detail of Content 做既乜兩個人一定會知, 這樣就算其中一個人去左第二 team 度做野, 都有一個人可以問. 另一方面, 一個人寫 Code 同跟人地 d Code 時好多時下意識都會出現因為無同類經驗而創造了 Stovepipe system, 這會產生很多無謂既重複, 做了相重既東西, 所以 Pair 可以解決到呢方面既問題, 而且當兩個人分開後再跟其他人實行 Pair, 做到似曾相識既問題時就會諗起重用某些 Code, 就可以大大提高系統既可重用性及減少不必要既重複, 從而提高生產力.

不過, 另一方面, 要實行 Pair Programming 亦有一定既難度, 正如 Agile 係 base on 好多十分良好既理念一樣, 以我這半年在公司入面既觀察, 公司未必有足夠能力去 apply agile development, 例如公司無一個良好既 Continuous integration(CI) practice, 而 CI 同 agile 一樣, 都要有一個良好既 version control practice (唔係就咁 commit/update 咁簡單, 詳情請看 Pragmatic Version Control with Subversion), 良好既 test-driven 環境及智識 (而點解要 Test 就詳見舊 Post – Why Automate Test), 以及 programmer 要有良好既 refactoring skill, 軟件要 Design for Test 等等. 除此之外, 公司因為有很多不同既 project, 加上好多時要 on-site 工作, 而令到公司既 programmer 只得好少既溝通機會, 加上高層對 agile development 同 software configuration management 都好似唔太熟, 表現上好自由地比 Developer Implement Project, 但實際上就因為沒有溝通技巧而造成各自為政, 員工經驗得不到分享, 減慢了開發進度.

要係公司 Apply Agile, 詳見 Art of Agile Development 既 Adopt XP 一節, 因為解決人既問題始終難過選擇用邊個軟件做 Version Control, 點起 CI Server, 點學寫 Test Case 同邊度上 Agile 既研討會等, 書中有一大篇不同層面人事既應對方案, 所以都唔想多講 (無理由 copy 人地 d 野出黎架麻).

雖然現在自己未有最好既軟件開發環境, 但希望未來幾年可以不斷地進步, 直至令環境追上國際水平!!~

Last night, I went to join the meeting of Agile Hong Kong, the topic is Acceptance Test-Driven Development(ATDD), presented by Steven Mark, which look-like great, user friendly, and example-driven concept to improve the software quality and meet the customer expectation, the different between TDD and ATDD is that the TDD is more focus on unit testing, test case written by developer and ATDD is focus on the customer example, test case written by user in readable format, one of practice is customer/business analyst provide html “table” of example using wiki and let the FIT or Robot framework read the html “table” and provide test result.

ATDD is great, but currently I still need a time to pickup the current unit testing with NUnit, lack of experience and no partnership in agile development is my weakness, and I need more time to train up my experience. I hope that I have opportunity to apply agile in future although current environment seen doesn’t permit.

Another good thing in this meeting is meeting with Rex, who is the Ruby developer and IT company owner, we have similar idea of Hong Kong IT Event Calendar before and he did better than me. Also, in this meeting, free pizza was good, and small gift (should be the score card) was offered.