hiroportation

ITの話だったり、音楽の話、便利なガジェットの話題などを発信しています

アジャイル開発の進め方

私が経験したアジャイル開発手法(スクラム)の進め方についてまとめてみました。
基本的に上から読み進めれば、アジャイル開発の流れを理解できるように書いています。
一部自己解釈が含まれている可能性があるためご了承ください。


1. そもそもアジャイル開発とは?

  • 設計は最初からガッチリさせず、小さな単位で開発とテストを繰り返し、少しずつ不明点を解消しながら全体を明確にする感じと思っている
  • アジャイルとは「素早い」という意味ですが、必ずしも最短で開発を完了させる、ということではないです
  • 早い段階で開発フェーズを始められるため、やってみてわかるエラーや不明確部分などの想定外に早期対応でき、大きな手戻りを減らせます
  • 徐々に仕様を固めていくため突如の仕様変更などにも応えやすい


2. 用語解説

用語 説明
スプリントmtg 前スプリント期間での反省や次スプリント期間でのやることなどを決めるためのmtgです。1週間〜2週間の期間を設けることが多いです。
デイリースクラム 進捗状況を確認するためのmtgです。毎日メンバーが集まれる時間に実施します。メンバに遅延が発生していないか、共有事項等はないかなどを確認します。
ストーリー ユーザーストーリーとも呼び、「要求事項」のようなものです。開発者はこの要求事項を元に開発に必要なタスクを決めていきます。
ストーリーポイント ストーリーを解決するための工数で、基準ストーリーから相対的に決めていく。
基準ストーリー ストーリーポイントを決めるために使用する基準で、大抵は単純な作業に設定します。
スクラムマスター スプリントmtgスクラムmtgでの司会を務める人物を指します。
アクティブバックログ スプリント内でやるべきストーリー群のこと。
ベロシティ 開発、作業スピードのこと。


3. アジャイル開発のやり始め

  • まず抽出した要件定義からどれくらいの期間がかかるか予測する
    • プロジェクトに必要なトータルストーリーポイントをあらかじめ予想して算出する(これが大変だと思う)
      • ベロシティを考慮していないため、何人かでポイント数については議論しておいた方が良いと思います
    • トータルストーリーポイントから何スプリントでプロジェクトが完了できるかを見積もる
    • 規模によりますが、2、3スプリントくらいはバッファを積んでおいた方が良いかも
    • このとき、1スプリントのストーリーポイントも算出しておいて、後々のスプリントmtgで遅延予測などに使用しましょう
    • 以下のようなイメージですね(やっぱり図にした方がわかりやすい)

規模を見積り、ベロシティを計測して、期間を予測する - YouTube

  • アジャイル開発のルールを決める
    • チケットシステムは何を使うか?(Jira?Redmine?など)
    • スプリント単位はどうするか?(何日?何週間?)  * スプリント中はmtgで決めた目標に向かってチームで最大限に動く期間とする感じ
      • つまり仕様変更や開発が活発な場合は、定期的なスプリントmtgを増やすためスプリント単位を小さくすると良い
    • スプリントmtgはいつ何時にやるのか?何を話すのか?
    • デイリースクラムは何時にやるか?何を話すのか?
    • チケットには何を書くのか、どう運用するのか?
    • スクラムマスターは誰が担当するのか?
  • 決めたらチーム内でルールについて議論をし合う
  • チケットシステムを準備しておく


4. プロジェクトを進めてみる

日常のプロジェクト内では毎日デイリースクラムで進捗確認をし、一定期間毎にスプリントmtgで開発等に関する反省や次スプリントでやること等を考えます。
全体としては以下のような流れです。

f:id:thelarklife1021:20211201024520p:plain:h300


4.1. スプリントmtg前にやること

  • 要件事項や、やりたいことをにもとにしてストーリーチケットを作成しておく
  • ストーリーチケットには具体的にやることを記載する
    • チケットの内容を抽象的なままで先に進めてしまうと、後々のストーリーポイント決めがブレるし作業遅延の原因になる
    • やることが不明確なタスクは、調査ストーリー又は調査タスクとして扱い、優先的に解決させましょう


4.2. 最初のスプリントmtg

  • 各メンバーはスプリント期間中の稼働時間を提示する
  • 作成したストーリーチケットを元にチームで必要なタスクが十分かを確認する

  • 基準ストーリーを決めておく

    • メンバー全員が理解できる単純な作業が良いと思います
  • ストーリーポイントを決める
    • 1スプリント内で実施できそうな分のストーリーポイントを以下の流れで決めていきます
    • 各メンバーは基準ストーリーから相対的にポイントがいくつになるのかを決める
    • メンバー全員で一斉にポイントを出し合う(やり方は自由)
    • ポイントがバラけた場合は高く設定した人のポイントを採用する
      • ただしポイントの低い人と高い人に大きな開きがある場合はその場でお互いの認識を話し合ってポイントをどっちに寄せるのかを決める
    • 詳細不明なタスクはストーリーポイントが不透明になるため、調査タスクとしておき、ポイント見積りはしないようにする
      • 調査タスクはボリュームが不透明なためなるべく優先させて解決させましょう
      • また、あとで完了した調査タスクはスプリントmtg前までに対応者がおおよそのストーリーポイントを設定しておきましょう
  • ストーリーで優先したいものはアクティブバックログバックログの上部に持っていきましょう
  • 各ストーリーの担当はmtg内で決めても良いですし、各々でやりたいストーリーチケットを決めても良いですが優先順位は意識しましょう


4.3. スプリントmtg後にやること

  • 各メンバーは担当するストーリーチケットのやることを元に子チケットを作成してから作業を開始する
    • なるべくストーリーに書いたやることを、そのまま子チケット名として作成するとわかりやすい
    • 着手するタイミングで考えられる子チケットは全て作成しておき、後付けがなるべく発生しないようにする
    • 該当子チケットを開始するタイミングでステータスを開始に変更する
  • チケットのステータス更新は毎日行うようにする
    • 毎日進捗を可視化できる状態にしておく
    • 1日で終わらなかった子チケット(タスク)は分割して、1日でどれだけ進んだのかをわかるようにする
      • これをしないと進捗が不透明になってしまうので、めんどくさがらずやる習慣をつけましょう


4.4. デイリースクラム

  • 各自のスプリントの進捗を確認し、抱えている問題や、自分が解決したこと等を共有し、必要に応じてスプリントバックログを見直します。
  • デイリースクラムでの話す内容
    • 今日やった事の進捗 *「予定通り」か「遅れているか」を話し合う
      • 逆にそれ以外のことはなるべく当事者同士で話し合い、他の人の時間を奪わないように意識する
      • 遅れている場合はスプリント内に追われそうかを軸に報告する
    • 明日やる事
    • 共有するべきこと
  • スプリント内での解決が難しい場合は作業分担をして、最悪次スプリントに伸ばすかどうかも検討してください


4.5. 2回目以降のスプリントmtg

  • 調査タスクなどのストーリーポイントが更新されていることを確認する
  • 2回目以降は前スプリントの反省をして次スプリントに活かしましょう
    • 設定したストーリーが終わり切らなかったのはなぜか?
      • 追加業務が発生してしまった
      • 想定外のエラーが発生してしまった
      • ストーリーポイント低く設定してしまった
      • など
    • ベロシティが大きく変動したのはなぜか?
      • ベロシティが正確ではないから
      • チームで良い開発手法を活用していたから
      • まだチームで開発し始めたばかりだから
      • など
    • ベロシティを求めてチームのパフォーマンスを理解する
      • スプリント内で完了した合計ストーリーポイントとメンバーの合計稼働からベロシティを求める(=実績)
      • 次に、求めたベロシティと次スプリントの稼働予測から次スプリントにおけるストーリーポイントを決めます(=予測)
      • 計算方法は以下です
実績:pt / bd = pt/bd
予測:pt/bd * bd = pt

pt:合計ストーリーポイント(道のり)
bd:全メンバーの稼働時間(時間(日単位))
pt/bd:ベロシティ(速度)
  • 算出した実績ベロシティ(pt/bd)についてチームで分析し意見を言い合う
    • ベロシティの値が予想より大きい場合に考えられること
      • チームが開発について習熟し始めてる
      • 開発に便利なツール類を導入した
      • ストーリーポイントの付け方が甘い
      • など
    • ベロシティの値が予想より小さい場合に考えられること
      • 具体的にタスクが整理できていない
      • 急遽休むメンバーがいた
      • 開発の仕方に問題がある
        • チームで情報共有ができていない
        • メンバーにやる気がない
      • ストーリーポイントの付け方が厳しい
      • など
    • ベロシティの値が予想値に近いまたは等しい
      • ベロシティが連続で予想値に近似しているとチームの開発速度が実際に見えてきていることになるので良い傾向
      • その状態で次スプリントは、少し多めのベロシティを設定してチーム力を上げていきましょう
  • 算出した実績ベロシティから次スプリントで完了できそうな量のストーリーポイント(pt)の予測を算出します
  • 算出したストーリーポイントから実際にプロジェクトがあらかじめ算出した予測期間が完了できそうかを確認しておきます
    • トータルストーリーポイントから分割したストーリポイントよりもかなり低い場合
      • 開発期間延長を検討
      • メンバーの追加アサインを検討
      • プロジェクト内で開発するコンポーネント等を削る
        • 意外とこれが大事な気がする
        • 完成形を最初から作らず最低限のものを作ることに努める
  • 予想したストーリーポイント分、次スプリントで実施するストーリーとそのポイントを決めていきます
    • やり方は1回目と同じです


5. スクラムマスターがやること

  • スプリントmtg
    • チケットが最新であることの確認
    • スプリントmtgの進行
  • デイリースクラム
    • デイリースクラムの進行
    • 進捗していないタスクはその理由を確認する
    • ある人のタスクを別の人がブロックしていないか確認する
  • あとは経験!


6. アジャイル開発の目的を再認識しましょう

  • 手戻りを徹底的に無くしたい

    • チケットは具体的に書いて、チーム内のコミュニケーションミスを極力無くすように努力する
    • スプリント期間が長くなり過ぎないように気をつける
  • プロジェクトを順調に進めるため、毎スプリントのストーリーは全て完了させたい

    • ベロシティから最適な人数、開発期間を早めに算出するようにする
    • ストーリーチケットのやることは具体的に書くようにし、わからないことは人に聞き、生産性を最大限にあげよう
  • ベロシティは実体と合っているのか

    • ベロシティ値は高ければ良いというわけではなく逆に大きく予測よりも高く達成した場合は、ストーリーポイントの見積もりが甘い可能性がある
    • ベロシティはチームの開発スピードを指すので、チームみんなが正直な気持ちでストーリポイントの算出をすることが大事
    • 前スプリントと比較してベロシティ値を無理に高く設定するのはやめた方が良い
  • プロジェクトゴールに向けて気づいた追加タスクややりたい事はチケット化して忘れない内にバックログに溜めておきましょう


7. Q&A

  • ストーリーポイント決めで高めに設定した人の方を採用する理由は?

    • 低いポイントを採用してしまうと対応するメンバーによってはストーリーを予定期間に解決できない可能性が出てくるから
  • チケットは具体的にどこまで書くのが良いのか?

    • 最善はチームメンバー全員が背景からやることまでを全て具体的にイメージできるようになることです
    • これができていないとストーリーポイントがブレたり、メンバーによっては想定以上にタスク完了までの時間がかかってしまう恐れがあります
    • よく手を抜いて省略してしまうことが多いですが、間違って作業して手戻りが発生するよりは遥かにマシなので、やることは具体的に記載し、わからないところは調査タスクとして分割するようにしましょう


以上