はじめに
最近は、ソフトウェア開発・プロジェクト管理に関して、
自身が持たなければいけない責任もより大きくなってきた部分があるので、
「任せっぱなしではなく、そろそろちゃんと勉強しなくちゃなー」と感じている次第でございます。
個人的なメモ感覚で、”これは役に立ったな”と言う知見・資料をJOTTING感覚で書き溜めていこうと思い、今回をきっかけに随時更新していこうと考えています。
初心者や非ITエンジニア向けのスクラム概要
ざっくりと概要見返したい時におすすめのスライドです。
アジャイルやスクラムに関するQ&A集
カンペ的にも使えて便利です。
タスク管理
タスクを分割しないデメリット
作業内容の認識が合わせ辛い
大きいタスクの中で問題が発生すると、サイズが大きすぎて、全体としてどの程度影響が出るかわからない
作業が予定より遅延しているかどうかが判断し辛い
タスクを分割するメリット
作業内容の認識が合わせやすい
問題が発生しても、問題が局所化しやすい
タスクごとに遅延が検知でき、他タスクも同様に遅延した最悪の場合の見積もりがしやすい
チケットの書き方
最低限、下記の項目があると良さそう。
・取り組みの背景（本当に取り組むべきなのかの問いかけ・全社視点を忘れない）
・具体的なアクション（工数の可視化とチームへの共有・思わぬ落とし穴/死角がないように補完し合う）
・やること
・所要時間
・何を達成したらゴールか（ゴールの定義・完成像の齟齬/ズレをなくす）
・期限（不明であれば依頼元に確認）
・その他共有すべき資料の添付
・ソース
・参考資料
・議事録
・etc
本記事を含めたドキュメント更新の方針
基本的には、下記の３項目は必ず記載すると良いと考えています。
・決定事項
・決定の背景
・いつ決定されたか（タイムスタンプ）
参考：https://kakehashi-dev.hatenablog.com/entry/2023/10/16/100000
おわりに
まだまだスクラムペーペーなので、スクラムマスターに近づけるよう努力したいと思います。
本記事はアドベントカレンダー用のメモです。
下記にて、随時更新していく予定です。
http://sokka-tech.com/2023/12/16/%e3%82%bd%e3%83%95%e3%83%88%e3%82%a6%e3%82%a7%e3%82%a2%e9%96%8b%e7%99%ba%e3%81%8a%e3%82%88%e3%81%b3%e3%83%97%e3%83%ad%e3%82%b8%e3%82%a7%e3%82%af%e3%83%88%e7%ae%a1%e7%90%86%e3%81%ab%e9%96%a2%e3%81%99/