スクラム

項目内容
スクラム現状を把握するための手法
 現状を把握することで、結果として開発しやすい状況が整えられることが多い
 実際に、プロダクトの品質や生産性の向上などができるかは、チーム次第となる
 個人ではなく、チームとして、プロダクトをより良くしていくことが求められる
概要固定期間(1~4週間)毎に、設計、開発、試験、リリース、振り返りの全てを行う
 固定期間のことをスプリントと呼び、毎回ユーザやステークホルダーに価値を提供し続ける
 個人的には1週間スプリントを推奨する
 短期間で素早くサイクルを回すことにより、どんどんより良い状態に改善できるため
 また、スクラムでない組織に導入する場合、少しずつ要素を取り入れていくと、反発が減る
役割スクラムチーム
  プロダクトオーナー、スクラムマスター、スクラム開発者で構成される
  対応できる人数は3~11人
  それ以上の人数の場合、LeSSなどの大規模アジャイル手法が必要となる
 プロダクトオーナー
  必ず1人、プロダクトバックログの優先順位を決める製品の責任者
 スクラムマスター
  必ず1人、スクラムが正しく実践されるように促す責任者
  スクラムに関しては何でも知ってますよ、という態度を貫き続けるのが大事
  そうしないと、言葉に説得力が生まれなくなってしまうことが多いため
  実際には、わからないことや判断に困ることばかりだが、
  そのスタンスだけは守るようにすると、上手く開発が回りやすい印象がある
 スクラム開発者
  1~9人、企画・制作・FE・BE・QAなどリリースに必要な複数メンバ
  推奨人数は上記通りだが、実際にはリリースに必要なメンバを少人数で集めるのは難しい
  そのため、少人数が望ましいが、集められない場合は、大人数になることを許容して良い
  リリースに必要な人材が1つのチームに集い、価値を提供し続けられる状態が大切なため
  最初は大人数でも、チームが成長していけば、少人数の複数チームに分割可能となる
  なお、大人数のチームの場合、時間短縮のため、朝会や振り返りは無作為に分割して行う
振り返りKPT:Keep良い点・Problem悪い点・Try改善点を列挙して状態を改善する
 タイムラインで、良い点・悪い点などを列挙して、時系列で振り返る手法も存在する
 他にも多数の手法が存在するが、チームがより良い開発ができる可能性があれば何でも良い