MyTiDD & MyScrum

Team

タスクをJIRAのチケットで管理しつつのScrum。TiDD=Ticket Driven Developmentね。
我流す。まぁ誰かの何かの参考にでもなれば。

ユーザーストーリー

  1. ユーザーストーリーをチケット化(PO,SM)
    • 目的: 何をやるのかということをチームとPOで認識を揃えるため
    • ユーザーストーリーはユーザーにとって価値のある単位ね。「在庫管理システムのためのDB設計をする」とかじゃなくて「ユーザーは商品の在庫を確認できる」て感じで。
    • チーム側で追加したいもの(リファクタリング、あとで気づいたことなど)は、チームチケットとして追加。チームチケットはストーリーポイントをもたない。毎スプリント混ぜ込んどいたらベロシティも落ち着くし。
    • f:id:bufferings:20130818113231p:plain
  2. ストーリーポイントをつける(チーム)
    • 目的: ざっくりした見積もりを短時間でつけるため
    • プランニングポーカーとかでさくっとつける。時間かけてもしょうがない。
    • チームはいつでもストーリーポイントを見なおして良い。やっぱむずそうとか。あれやったからこれやることなくなったでとか。
    • f:id:bufferings:20130818113252p:plain
  3. 優先順に並び替える(PO,チーム)
    • 目的: この順番で開発していくよ
    • 開発の前後依存などもあるのでチームはPOに説明して順番を変えたりする。
    • f:id:bufferings:20130818113306p:plain
  4. ロードマップ作る(SM)
    • 目的: プロジェクト全体の着地予測を立てるため
    • 数スプリント経験するとベロシティが見えてくるのでそれを元に3ヶ月くらいの計画をたてる。
    • 着地する確率であることを認識しておく。何がなんでもこの通りに終わらせますというコミットメントなんかじゃない。
    • この辺の見せ方がむずいけど。
    • スプリントの実績に基づいて着地予測も変わる。割り込みストーリーや。発見されたチームチケットにも影響される。
    • f:id:bufferings:20130818113316p:plain

スプリントプランニング

  1. バックログに積まれているストーリーチケットを上から順番にとる。
  2. ストーリーをタスクに分割してそのストーリーチケットの子チケットとして登録。
    • タスクの粒度はペアで1日くらい
    • 1日で終わるくらいの大きさが、達成感あるのと、進捗が把握しやすいのと。
  3. タスクチケットには時間見積もりを入れておく(Hours Burn Down Chart利用のため)
    • 1人あたり5h/dayくらいで考えるので1タスクあたり10hくらいを目安にする
    • 1日が5hなのは、メンバー同士で相談したり、他のメンバーに技術的なことを教えてあげたり、会議だったりの時間を考慮
    • ドキュメントを書くのもストーリーのタスクとして登録すべし。ドキュメントを書くまでがストーリーです( ｰ`дｰ´)ｷﾘｯ
  4. スプリント内でできそうな量でストーリー打ち切り。
    • 「できそうな量」は数スプリント回したら実績として分かるす。

f:id:bufferings:20130818113333p:plain

スプリントの日々

  1. 朝会
    • 今日やるタスクをDoingステータスに置いとく
      • 目的:今誰が何をやってるのかを共有するため
    • タスクはペアで担当する
      • 目的:クオリティ、アラート上げやすくする、暗黙知の共有
    • バーンダウンチャートを使用して、メンバーの感覚ではなく数字として進捗を確認する
      • 目的:メンバーがわざわざ意識していなくても状況が見えるようにしておく
      • おわんねーなーってときはPOに早めに報告しておく。次スプリントのPO的なプランがあるし。
  2. 開発ごりごり
    • コードのコミットにはJIRAのチケットIDをつけてVCSを自動リンクさせる
      • 目的:全てのコミットは対応するチケットを持つのや！
    • タスク漏れがあったわ！ってときは素直にタスクチケットを追加する。
    • このタスク、思ったよりも時間がかかりそうだわ、ってときも素直にその時間を書く。チケットが大きくなりそうだったら分割する。
      • そうしておくと常にバーンダウンがチームの状態を素直に示してくれる
      • 大切なのは「約束」や「理想」よりも「現実」ですしすし
  3. 帰るとき
    • 「作業した時間」「残り時間」をチケットにログ
      • 目的:これで予実管理できる。
      • あ、でも予実はずれてて当然で合わせようなんて思ってなくて、振り返りのため(後述
      • それとここに7時間とかついてたら残業よね。とか把握。
    • 触ったチケットは終わってても終わってなくてもReviewステータスに置いて帰る。
  4. 次の日の朝会
    1. Reviewステータスのを読み合わせしてDoneにするかDoingに戻す(目的:昨日何やってどうなったかの共有
    2. 今日のタスクを決める(目的:昨日の結果を踏まえて、チームとしてどうやれば一番いいかをメンバー自身が考えてアサイン

振り返り

  1. 振り返りでタスクの予定と実績を見て話し合う
    • どんなタスクを見落としてたのか
    • どんなスキルがあればよりよいものが作れるか
  2. リリースしたストーリーチケットはリリースノートとして利用する

ポイント

  • チケットにはストーリーやタスクのゴールを書いておく(Doneの定義)
    • そしとくと、このタスクチケットではこれやるんじゃないの？えー、それはそっちのチケットやろ？とかが減る。
  • チケットはタスクの管理だけにしておいて。残しておきたい情報はチケットではなくWikiに残しておく。
  • ストーリーポイントはざっくり2,3ヶ月の計画用に。時間見積もりはスプリント9日間の計画用に。それぞれ使う。


はい。こんな感じ。
あれやな、絵にでもした方が分かり良いね。描いてみて！