SCRUM BOOT CAMP アジャイル開発 メモ
ステークホルダー
プロダクトの利用者、出資者、管理者などの利害関係者
インセプションデッキ
新規開発前の話し合いを整理するのに役立つ
スライドのテンプレート集
アジャイル開発を実施するかに関わらず導入できる
プロダクトバックログの見積もり
作業量で考えるのが一般的
何か1つの課題を用を基準にする
その課題と相対的に比較して見積もる
相対値に使う数値にはフィボナッチ数を用いることがある、ポイントという名前で
素早く見積もるのが大事、実際に開発を開始すれば変更が必要になることもある
見積もりに長く時間をかけてしまうとそうなった時に無駄になってしまう
開発チームが見積もりを行う
実際に開発にあったって必要なことが専門的に考えられるのが開発チームなため
デイリースクラム
1日1時間、同じ時間に同じ場所で毎日開催
スプリントの状況を把握する、スプリントゴールを達成できるか、再計画が必要か検査する
目的は進捗報告ではないということ、報告の場になると問題を見つけるのが難しくなる
問題の解決自体はデイリースクラムではやらない
感想
手法を取り入れることはできなくとも、
チームの一員としての心がけを意識する機会になって良いと思った
スプリントレビューは、スプリントで完成したものと今後について明らかにしていくイベント。
スプリントレトロスペクティブは、スプリントでの作業の進め方を確認して、次のスプリントをよりうまく進めていくために用意されている。ふりかえり。
スプリントレビュー
デモの準備は万全にしておく
確実に完成させて進む
コードの品質などプロダクトオーナーと開発チームでプロダクトの完成度の認識が異なったりと、認識は人によって違うため、完成の定期を用意しておくと良い、何が完成したかを明らかにするのが大事
完成の定義の例
・でも手順の通りに動作する
・メソッドのテストコードがある
・使用がwikiにまとめてある
など..
完成の定義の決め方
プロダクトオーナーがスプリントで何がどこまでできていて欲しい華を伝える、
開発チームがどんな基準を設けるかを話し合う、実力に見合ったもので
最後のにプロダクトオーナーが判断、達成すべきことが十分か、そもそも達成可能かなど
スクラムチームで合意する
タイムボックスは守る、たとえ作業が中途半端で完了していなくとも
先のことを具体的に予測するためにはタイムボックスが不可欠
参考
・スプリントの期間は1ヶ月以内
・デイリースクラムは15分以内
・スプリントプランニングは8時間まで(スプリント期間が1ヶ月の場合)
・スプリントレビューは4時間まで(スプリント期間が1ヶ月の場合)
・スプリントレトロスペクティブは3時間まで(スプリントの期間が1ヶ月の場合)
スプリントの期間は短い方が予測が立てやすくて良い
タイムボックスに入るようにしていく、チームの実つ力でこなせる量にしていくのが重要
スクラムイベントはあるが、
必要に応じて自分たちでルールを追加しても良い
デイリースクラムに出られない人がいたら、夕方追加で報告する場を開催
15分悩んだら誰かに相談
等..
特に直近のスプリントは曖昧さを減らす
曖昧なまま着手するとベロシティ等諸々悪影響
具体的にはペーパープロトタイプやスケッチを作成したり