アジャイル開発は本当に必要なのか、何を解決するのか | AWS Dev Day 2023 Tokyo

アジャイルとは

• 下記の状態を指す

  • 変化に柔軟に対応する

  • 動くソフトウェアを重視する

    

    

タックマンモデル

• チームの成長プロセスの例
  • チームは機能期（アジャイルな状態）になるまでに、ずっと右肩上がりではない。混乱期などを経て成長していく。

ウォーターフォールと本来のアジャイルと現実のアジャイル

• ウォーターフォールとアジャイルは比較するものではない

  • ウォーターフォール

    • 期限（リリース）を目的に進む

  • アジャイル

    • チームを強化しながら生産性をあげ、プロダクトを強化していく

    

  • 現実のアジャイル（なんちゃってアジャイル）

    • ウォーターフォールの開発部分だけをアジャイルっぽく進める
    • 混乱期のまま、この開発期間のみを経験してしまい、アジャイルに対して嫌悪感を抱きがち（すぐにアジリティは上がらないという前提を理解しないまま）

    

理想のアジャイルに近づけるためには

• 企画・要件定義のフェーズは完全に無くすことは極めて難しい
  • 人をアサインする上で、設計をして（何を作る上でどんな人がどのくらい必要なのか？など）社内承認を通さないと、そもそも開発をスタートさせること自体が難しいケースが多いため
  • 完全に無くすことはできないため、短くする努力をする
• 中長期を見越して、運用を意識して設計すること
• リリース日をずらすのではなく、スコープを変更すること（変更できる前提で調整しておくこと）

開発生産性の測り方（生産性を向上させるには）

• 生産性そのもの自体を測れないとしても、何かを代用することで測ることはできるかもしれない

• 5つの指標例

  

• 開発生産性を測ることができると

  • チームの成長（アジャイルに近づいているかどうか）を定量的に評価できる

  • 指標を目安に、説明することでリファクタリングの承認を得やすくなる