はじめに
最近は、ソフトウェア開発・プロジェクト管理に関して、
自身が持たなければいけない責任もより大きくなってきた部分があるので、
「任せっぱなしではなく、そろそろちゃんと勉強しなくちゃなー」と感じている次第でございます。
個人的なメモ感覚で、”これは役に立ったな”と言う知見・資料をJOTTING感覚で書き溜めていこうと思い、今回をきっかけに随時更新していこうと考えています。
初心者や非ITエンジニア向けのスクラム概要
ざっくりと概要見返したい時におすすめのスライドです。
Scrumの概要
初心者や非ITエンジニア向けのスクラム概要資料です
slide.meguro.ryuzee.com
アジャイルやスクラムに関するQ&A集
カンペ的にも使えて便利です。
アジャイルFAQ | 株式会社アトラクタ
アジャイルコーチングや各種トレーニングの際によく聞かれる質問についてまとめました。 なお、内容については十分注意を払っておりますが、有効性等は状況によって変わります。お客様の自己責 …
www.attractor.co.jp
タスク管理
タスクを分割しないデメリット
- 作業内容の認識が合わせ辛い
- 大きいタスクの中で問題が発生すると、サイズが大きすぎて、全体としてどの程度影響が出るかわからない
- 作業が予定より遅延しているかどうかが判断し辛い
タスクを分割するメリット
- 作業内容の認識が合わせやすい
- 問題が発生しても、問題が局所化しやすい
- タスクごとに遅延が検知でき、他タスクも同様に遅延した最悪の場合の見積もりがしやすい
チケットの書き方
最低限、下記の項目があると良さそう。
- 取り組みの背景（本当に取り組むべきなのかの問いかけ・全社視点を忘れない）
- 具体的なアクション（工数の可視化とチームへの共有・思わぬ落とし穴/死角がないように補完し合う）
- やること
- 所要時間
- 何を達成したらゴールか（ゴールの定義・完成像の齟齬/ズレをなくす）
- 期限（不明であれば依頼元に確認）
- その他共有すべき資料の添付
- ソース
- 参考資料
- 議事録
- etc
参考資料
Amazon.co.jp
amzn.to
本記事を含めたドキュメント更新の方針
基本的には、下記の３項目は必ず記載すると良いと考えています。
- 決定事項
- 決定の背景
- タイムスタンプ
おわりに
まだまだスクラムペーペーなので、スクラムマスターに近づけるよう努力したいと思います。
本記事は随時更新していく予定です。
コメント