LoginSignup
4
1

More than 5 years have passed since last update.

Backlogによるチーム開発提案

Last updated at Posted at 2016-10-05

※画像は全てbacklogのヘルプページから借用しました
(まもなくuiが変わるとの噂ですが・・)

Backlogを使う上での最低限のルール

見た目が直感的なので採用されたタスク管理ツール、backlogなのですが、どうしてもチーム開発をする上で守って欲しいことが出てきましたので下にまとめます

このルールを守ることで、以下の効果を期待しています
1. より早いタスクの完了(不要な待ちの発生しないスピード感を持った開発)
2. より納得感がある、共通認識としてのタスク優先度

絶対に守って欲しい3つのルール + 1

  1. 「担当者」を明示する image
  2. 「お知らせしたいユーザー」を忘れない image
  3. 自分の作業が終わったら「担当者」を変更する
  4. backlog以外での確認も行う

タスクに担当者を登録する

例えば、「サイトxxxをリニューアルする」とかいう案件があった場合に、一つタスクに必要事項を全て埋めていく方式と、担当者毎に子課題を作成するのと、2つのパターンが考えられます。

プロジェクト管理の原則としては、タスクを細かく分割して、期限の見積を行い開始日と完了日の制御を細かく行う事で、進捗率や予算消化傾向などが把握できるのですが、現状はそこまでは求めません。

では、最低限をどこにおくか。
* マネージャーなどが、現在会社が抱えているプロジェクトを俯瞰できること
* それぞれの仕事は誰がボールを握っているのか(誰が担当者なのか)
とします。

そのため、
* まずは、今抱えている仕事、誰かに依頼したい作業は「全てbacklogに上げる」
ことを徹底しましょう。

そして、

  • 各仕事について現在関わっている人を「担当者」としましょう

平行して複数の担当者が作業を行っている場合どうすればいいか?

  • 原則に立ち返って、担当者毎にタスクをわけましょう

お知らせユーザー

このやり方だと、毎日大量のタスク、およびその変更が発生します。その中で確実に相手に読んでほしいものについては
* 「コメントをお知らせしたいユーザー」にセットした上で
* skype, hangout, line、そして一番いいのは「口頭」で相手に確認する
* 皆さんは最低限「自分宛のお知らせ」を確認することは忘れずに。
→ ブラウザでbacklogを立ち上げて「数字」が上がっていたらそれを読みましょう!
image

できれば守って欲しい 5つのこと + 1

  1. 自分の作業でタスクの要求が満たされたら、状態を「処理済み」にし、担当者をタスク作成者に戻す (タスクの整理を効率的に行うために)
  2. タスクを作った人が、タスクの状態を見届けた後、タスクの状態を「完了」にする (タスクの整理を効率的に行うために)
  3. タスク作成時、もしくは担当者を変える際に「期限日」を設ける。できれば、主要なマイルストーンについてはタスクの「詳細」に記載する
  4. タスクの「詳細」には。「何が終わればタスクが完了するのか」明記をすること
  5. 仕様や主要なファイルのやりとりは全てタスク上にコメント・ファイルの添付などで残すこと。特に、機能開発時の仕様は「詳細」を編集する
  6. 「スター」は、「ご苦労様!」「ナイスジョブ!」と賞賛したい場合以外にも、コメントつけるまでも無いけど、「読んだよー」と自己主張したい場合に使えます

その他ローカルルール

  1. タスク完了後も、参照される可能性が高いことはWikiに残す(wikiの方にはタスクのURLを貼り付けるだけでも良い)
  2. タスクに伴うコードコミットは、コメントに貼り付ける(本当はbacklogのリポジトリ管理が使えればいいのだけど、bitbucketの利便性にはかなわない・・)
4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1