碼農的辦公室日常

近幾年軟體業界對於敏捷開發 (Agile) 是蠻推崇的，因此大概從碼農我的第二份工作開始，幾乎都是走這樣的方式。 不過即使都叫做 Agile，各公司執行的方式似乎也都不太一樣。在 D 公司的時候，公司的一個開發週期是一個月，但在 R 公司的時候，一個週期則是兩週。不過基本上在我經歷的敏捷開發文化裡面，都還是有以下的幾個特徵。 開發流程 Development Process 需求 Requirement 這是最重要的一環，如果需求不清楚的話，也真的不知道要做什麼產品。因此，最好在這時候要有所謂的目標客戶，讓他們確定產品的方向跟用途，這樣才不會讓開發出來的東西不符合他們的期待。 不過也不用期待他們一次把所有的產品方向制定完成，因為這就又回到以往瀑布式開發的舊觀念思維。反而是讓他們把他們想要解決的問題拋出來，讓我們站在他們的立場，從他們想要解決的問題著手，開始跟他們一起討論，一起參與產品的制定。這樣是更有效的。 另外，通常在這階段，設計師(Designer)與系統分析師(System Analyst)也會間接參與，一起把使用者故事(User Story)撰寫出來，好估計整個專案的時程。 設計 Design 當客戶一起參與了你的產品，這時候就會開始衍生出各種設計的問題。界面的設計、用途的設計、使用體驗的設計，技術面的設計。粗略會分成以下兩種設計。 使用界面 / 使用體驗設計 UI/UX Design 產品要做出來，在需求大致確定之後，就會開始著手外觀的設計、使用體驗的設計。這時候設計師會更多跟客戶溝通，討論明確的需求。系統分析師也會開始看著界面的設計，構想大概有哪些技術面的需求，把這些需求轉化成後面技術設計的要點。 技術設計 Technical Design 在界面逐漸確定的同時，技術方面的分析也要進場，開始把一個一個的功能需求丟出來。這時候，系統架構師(System Architect)也要參與技術設計的討論，確保將來實做這些功能的時候，不會打壞原本的系統架構。把所有將來程式要實做的內容，撰寫成一份份的規格(Design Spec)，讓接下來的開發時程，可以直接照著文件開發即可。 開發 Implementation 開發的時間就是寫程式的時間了。如果時間安排得宜的話，在上一個設計的階段，有經驗的工程師可能就會先

最近剛好看到這位 YouTuber 的短片，雖然標題是學好英文，但其實「觀察與模仿」這方法也適用在其他情境裡面。 依稀記得以前在研究所時期，都要修「書報討論」這門課。學校會邀請一些在業界或學界的名人來演講，我們就乖乖地在演講廳裡面聽講。但畢竟演講是一門藝術也是一門專業，不見得每個人都能說得這麼好，因此很多時候我們學生會蹺課，除了對講者不太禮貌之外，學校也有點頭痛。 當時我們實驗室的指導教授，把我們聚集起來，跟我們講了以下的話： 『也許台上的講者所講述的內容或是他表達的方式你不喜歡，但我還是希望你們能在那個空間當中。觀察看看，他是哪個部份讓你覺得枯燥、乏味。學習不見得只是看到對方好的地方而模仿，如果你看到了他不足的地方，進而也改正你自己，那也是值得了。』 工作幾年下來，我發現這段話其實在不知不覺當中影響我很深。 經歷許多工作轉換，人來人往，總是會看到形形色色的人。不管同事也好，主管也好，總有你喜歡的，也有你不喜歡的。小時候看到一些討厭的大人時，似乎也曾許下願望，不希望自己長大後成為那種自己不喜歡的大人。 為了真正讓自己不成為自己討厭的人，透過觀察，發現自己欣賞與不欣賞之處，接著透過模仿或自省，讓自己能把該學習的部份學習並內話成為自己的，如此不斷修正自己，讓自己持續成為你喜歡的自己。若非得要引述個古語，大概也就是「見賢思齊、見不賢而內自省」的意思了。 因此，工作上也是，先從自己開始改變，讓自己成為不被同事討厭的人，接著等哪天當上了小主管，看到同事好的特質時，不吝惜地讚美；或看到同時不好的特質時，間接給予引導讓他改變。逐漸地讓整個團隊的氣氛變得更好吧！ ​