Blog.XDite.net

有朋友希望分享一下我過去怎麼管 Team。所以這邊分享一下過去我寫的 General Policy。（有中文版與英文版）

其實我認為這一份已經是正常的 Work Ethics（職業道德與工作完成標準了）

中文版

計畫階段

• 如果你認為在哪個項目比較在行，但是票卻被指給其他同事。或者是你認為現在手邊哪一些工作，在這週對整體工作進度來說是比較重要的。請先提出來。
• 團隊重視結果（是否能「幫助公司」或是「幫助同事效率」）高於實作品質或開發速度。
• 交出成果前，請先找一個比較資深的人幫你看過給意見。

在實際投入工作之前

• 在打開編輯器實際寫出第一行程式碼前，先問清楚：「為什麼我們要開發這個功能」？
• 先確定手上這件工作的「死線」以及「重要性」
• 與你的 stakeholder 時常溝通，取得 feedback 以及修正方向。
• 如果現有的系統裡面已經有相似的功能時，請先問週遭的同事，是否我們應該針對類似的例子設計一套 pattern 。

在工作的時候

• 先設計一套能動的東西，讓大家能夠測試。（在進入 Review 以及上線階段前，確定你沒有完全搞錯方向）
• 在開發的時候，把所有相關的文件以及筆記，記在 Redmine 上，方便同事幫助你時可以找到相關資料。（包括 bug 的 log、資料連結、測試成果）
• 盡量把 Task 拆細去實作。而不是一次 commit 一大包

完成工作後

• 如果你感到你完成工作的方式太 Hack。請多開一張 Ticket for Refactoring。然後放在下個 Sprint。
• 如果你在系統內引入了一套「新的外來技術」（比如說 gem , framework, js plugin 等等）。請在 Redmine 的 wiki 上記載以下相關資訊
  • 這是什麼東西？
  • 基本使用指南
  • 如何讓他跑起來
  • 你認為這套技術 API / 架構中，重要的部分
• 如果你在系統內開發了一套「新的架構」（如 Service Object, Pusher..等等。請在 Redmine 上記載以下資訊：
  • 為什麼我們需要這套架構，去改良現有的系統
  • 基本的架構運作原理
• 如果你正在「Refactor」，請記得在票上附上過程。（如 SQL tunning 或演算法變更）、並貼上 bechmark 成果或是截圖。
• 在將 code merge 之前，請先找一個資深工程師看過，且簽名。

你該記得的基本原則

你蓋的任何東西，應該同時滿足以下幾個條件：

• 能夠幫助公司
• 能夠幫助同事把事情做得更好更有效率
• 幫助自己成長
• 常問問題並不可恥（別擔心，你不是在浪費同事時間）。沒有什麼比不問問題更糟糕的了。
• 你蓋的東西，是會被「真的人」使用，而會會影響到「真的使用者」。
• 為自己的作品自豪

＝＝＝＝＝＝===

英文版

Genernal Policy

Sprint Planning

• If you feel you are good at something but it's wrongly assigned to another colleague or you think something is important that you want to finish in this sprint, please let us know
• We think highly of results (helping the company or helping colleagues ) much more than ticket quantity or development speed
• Have your architecture reviewed by a senior engineer

Before starting to code

• Ask "why are we doing this?" before opening your editor
• Ask about the deadline & priority
• Communicate with your stakeholder often
• If there's something similar already in the system, please ask around whether we should we build a pattern/work on the architecture

During Coding

• Build a prototype first to test drive (Before entering the review phase, ensure you are not building something completely wrong)
• Document everything related in Redmine (including bugs, links, test results)
• Break your task into smaller ones

After Coding

• If you feel your way is too hacky, please create a separate ticket for "Refactoring" then put in next sprint
• If you introduce a "new" technology in a ticket (gem, framework, js, etc.), write a Redmine wiki about it and inform the team
• What is this?
• How to use?
• Basic Setup
• The API and architecture you think it's important.
• If you introduce a "new" design pattern in a ticket (Service Object, Pusher, ..etc), write a Redmine wiki about it and inform the team Why we need this approach?

Basic Structure

• If you are doing refactor work, like "sql tuning" or "algorithm tuning", please attach benchmark results or screenshot
• Before committing your code, have it reviewed by a senior engineer

Things to remember

What you must meet

• Help company
• Help colleagues do things more efficiently
• Help yourself grow
• There's no shame in asking colleagues for advice or seeking help (don't worry, you are not wasting their time). There's more shame in not asking.

The things you are building will affect and be used by "actual human beings". Be proud of your craft.