本來是想再整理整理, 但就還是先寫出來好了. 那天在 MOPCON 晚宴中討論的內容.

本來是想再整理整理, 但就還是先寫出來好了. 那天在 MOPCON 晚宴中討論的內容. 這三年來, 可能再加上之前那一年帶實習跟團隊成員時的經驗, 其實在自己帶 team 上我一直在調整. 因為二十幾個人以上, 坦白說我跟大家一樣一天就二十四小時, 說真的權力也得有時間盯才叫權力, 盯不到的都是放任. 所以怎麼運用自己的時間成為了這兩三年來, 我最大的挑戰. 你做為主管你要把時間放在哪, 你的決定要決定什麼, 你的團隊就會往哪走. 然後我這兩年體認到一個重要的事情, 那就是不要追逐完美團隊. (但如果人是人才, 還是得排出物盡其用的局) 那天剛好同桌兩個都有 agile 經驗, 大家在聊 agile. 我嚴格來說不算是個 agile 的信徒, 我跑 iteration, 控 test , 控 requirement. 我深信只要能掌握 requirement 的發展, 就是最強大的開發管理. 我推 short-living feature branch , 我推 issue tracking, 我推分工流程調整. 致力降低溝通成本. 在討論 agile 的時候萬年亙古不變的廢話就是, 要排出 priority . 要 fix iteration , 要 freeze requirement. 會說是廢話是因為大家都知道要念這個經, 但真的要念得好卻沒有方法論可以決定. 即使大家很認真的排出 story point , backlog , iteration. 只要權力跟權衡沒有捍衛制度, 或是捍衛後沒有獲得如期成果. 這個方法論就很容易破碎跟變成替死鬼. 那天我提出的精神是, 共責. 我們不要期望每個人可以完全 take over 他們身上的工作, 他們只需要探索他們的工作, 並且盡力達成目標. 在無法攻克的領域插上此次探勘的成績跟旗子, (寫 //TODO: & //Note: ) , 讓下次走到這裡的戰友還有 reviewer 知道你的足跡即可. 面對中型專案, 你幾乎不可能憑藉一人之力組織完所有程式碼流程, 你需要很多軌跡協助你判讀, 但在程式碼世界裡遊走時, 最可怕的是沒有預警的 概念借用 (這變數在這裡是A意義,在下一段是B意義), 沒有思考過的複製加上後續的演化史. (兩個看起來90%像 10% 不像的東西是最可怕的, 你不知道為什麼會出現 90% 像, 這個像到底是真正語意上的像, 還是只是形狀上的像. ) 所以每個人能夠在自己能力範圍內去探勘, 註記, 就是所有問題的基礎. 如果每個 coder 都認真的去跟程式碼對話, 這種效果就是跨越時空的 pair, 在這種模式底下才有機會共同去探索出一個更適合的方針. 當然回到原本的問題, 要解決一個需求/一個系統狀態, 你需要的是規劃/執行, 這件事情本身就是吃能力的. 但如何在一個團隊裡面, 盡可能使用最大的能力完成任務. 我們得讓所有人的焦點放回程式碼, 放回目標, 然後回到協做這件事情本身, 而不是想著卸責, 想著推時間, 想著 delay 的罪惡感. 其實意境在於心, 不在於器.

原始 Facebook 貼文