こちらの本を読んだ
やっていることだったのでわかりやすかった。
少しだけメモ
人
プロダクトオーナー
＜スクラムチーム＞
スクラムマスター
開発チーム
作るもの
プロダクトバックログ
スプリントバッグログ
スプリントの長さ １週間から１か月
スプリントの中でやること
スプリント計画
デイリー
スプリントレビュー
振り返り（改善）
プロダクトバッグログの更新
その他用語
絶対に必要な項目の見積もり合計/ベロシティ＝が必要なスプリント数
妨害リスト
ベロシティ
バーンダウン
ユーザーストーリー
見積もりのポイント
バックログにつけるポイントってフィボナッチ数列の数だったんだ。
最初に分かりやすい機能を基準にしてそれに数字を付ける（３とか）
それを基準にしてどれくらい
その他
終わらなそうだったら、プロダクトバッグログの中身を見直して、簡単に実装する方法に変えるなどする。それが一番チーム外とのやり取りも少なく、自分たちで調整しやすい。（期限を変えたり人を増やすのに比べて）
スキルマップ
プロジェクトに必要なスキルや知識を書き出す
開発環境、言語、スクラム知識、社内調整など
それぞれのメンバーが「得意、経験あり、未経験」を書き込む
みんなで協力する作業もある。「ここしか担当しない」っていうのはよくない
未経験でも
コミットメント
責任を伴う約束。表明したらほかの人が口をはさんではいけない。
リリーススプリント
リリースする直前は普段のスプリントとは違う作業があるから、別途作業を洗い出す。
本番環境ではイレギュラーなこともあるから、本当は日々のスプリントの中で本番環境でできたほうがいい。
最後に
漫画のメンバーがみんな若くて親近感が湧いた。
スクラムチームの成熟度モデルに関する基準の例がCCライセンスで公開されていたので、日本語化したものを共有します。元ネタは、https://t.co/lFsD9KDUf1 pic.twitter.com/v1HlDK3z1k
— Ryutaro YOSHIBA (@ryuzee) August 21, 2019
アジャイル
昔も調べたけど、アジャイルとスクラムの違いというか、アジャイルが含む大きさがわからん。
別にわからなくてもいいのかもしれないけど、スッキリしない。
www.nec-solutioninnovators.co.jp
スクラムがアジャイルという考え方の手法の一つというのはわかった。
アジャイルは「変化に迅速に対応することを目指した軽い開発手法」
その中にスクラムとかLeanとかカンバンとかXPがあるらしい。
アジャイルの広さを知るにはLeanとかカンバンとかの他の手法をしればいいかも。
Leanは顧客開発だって
スクラムは動くものを短いサイクルで作っていく。
まあ少しだけわかった
