SCRUM BOOT CAMP THE BOOK

[matzryo]

予断

スクラムとは、アジャイル実践のためのフレームワーク。

朝一番に立ってするミーティングが有名。

書いてあることは具体的。簡単に見えるが、実践すると、自分たちの未熟さが暴かれる。

[matzryo]

鵜呑みにするなとか、怖いんだけど

[matzryo]

ソフトウェアを作るのは簡単ではない うんうん

ころころ変わるのを受け入れる。 当初の予定通りやることより、便利に使ってもらうのが大事。

[matzryo]

頻繁に確認して、フィードバックを得て、調整する。 ぜんぜん違う、とならないように。

[matzryo]

アジャイルでは、重要なもの、リスクの高いものを先に作り、要求の分析や設計に必要以上の時間をかけないようにする。

そうなんだ。心情的には、全部の設計の見通しを持っておきたい。

[matzryo]

すり合わせが大事って、日本ぽいな。

[matzryo]

プロダクトバックログの項目はらすべて見積もられている必要がある。

あー、重要度が低いのは見積もらないというわけではないのか。ポイントで見積もっておく。ざっくりでいいのかな。

[matzryo]

プロダクトオーナーは、tkrさんが適任じゃないかな。

[matzryo]

なんで機能横断的なチームがいいんだろ？分業したほうが効率がいい面もあるよな。

[matzryo]

スプリントがうちには無いな。

[matzryo]

プロダクト・バックログと、スプリント・バックログがある。 前者はプロジェクト全体、後者は一回のスプリントが対象

[matzryo]

ログの粒度が違うのか。たしかに、これなら分析、設計を最初にすべてやらない動きになるな。

[matzryo]

リリース判断条件を決める。 コードレビュー、テスト、カバレージ、ドキュメント、性能など。 これいいね。

[matzryo]

うちでやってるのは、デイリースクラムか。 デイリースクラムは、開発チーム内での会議。誰かへの報告ではない。また、問題解決の場でもない。解決は別途必要なメンバーで行う。全員の時間を奪わない。

[matzryo]

デイリースクラムしておいて、プロダクトオーナーに報告しようと思えばできる状況にしておく。

[matzryo]

プロダクトオーナーが、スプリントの最後に、レビューする。

うちは最後だったのがよくない。それはこないだの振り返りでも出た。 そして、プロダクトオーナーはデイリースクラムには要らない。

[matzryo]

レビューに使える時間、スプリントに対応した時間。そこまで決められてるんだな。

[matzryo]

振り返りも同様。 うん、これやりたかった

[matzryo]

スクラムマスター、いればいいけど、そんな余裕あるか？兼業するのかな

[matzryo]

実践編

予断

実際すすめるといろいろ迷う。そのたび解決していく

[matzryo]

Redmineってスクラムやりやすいっけ。

[matzryo]

2014年秋〜翌春に、アジャイルサムライ勉強会へ通っている。

[matzryo]

兼任もいいけど、スクラムマスターとプロダクトオーナーの兼任はおすすめしない。相反する性質があるから。

[matzryo]

プロダクトオーナー ゴール、要求・仕様、リリース計画

スクラムマスター スクラムサポート

[matzryo]

scene no.02

どんなプロジェクト？

予断

プロジェクト開始時にするべきことの説明 ユーザーストーリー、スプリント期間を決める

[matzryo]

ゴールとミッション。ミッションがもうちょっと具体例が欲しい。

[matzryo]

インセプションデッキテンプレート

https://github.com/agile-samurai-ja/support/blob/master/blank-inception-deck/blank-inception-deck1-ja.cacoo.md

[matzryo]

scene no.03 いつごろおわるんだい?

予断

見積もり技法。ポイントで見積もる。ベロシティをもとに期間を算出する。

[matzryo]

redmine プラグイン https://github.com/backlogs/redmine_backlogs

[matzryo]

プロダクトバックログは、プロジェクト開始後も追加可能。でも、追加しすぎると破綻するので、最初にしっかり洗い出したほうがいい。

[matzryo]

重要度４段階くらいのざっくりしたものでもいい。また、ユーザーから見て重要科だけでなく、開発者にとって重要かどうかでも見る。管理画面など。

[matzryo]

見積もり。 ざっくりとした段階でストーリーを分類する。

[matzryo]

仕様をまとめるのも開発チームが行うのか！

[matzryo]

リリースに合わせてベロシティを設定するのは、希望的観測だ。ベロシティは、決めるものではなく測るもの。

[matzryo]

ストーリーはわりとざっくりとした単位。 各スプリント開始時に、スプリント計画ミーティングをおこな。 ここの第二部で開発チームが詳細な分析をする。

この段階では、時間でみつもる。理想時間。 一日の理想時間は５〜６時間。 以上で決まったことをスプリントバックログという形でまとめる。

不確実性の小さい直近は、詳細な計画をつくる。ほかはざっくり。どうせ不確実だし。

[matzryo]

スプリントのゴールがわかっていれば、細かい設計もやりやすい。

[matzryo]

終わりの条件を明確化しておくこと。 たとえばデモ手順を決める。「このボタンを押せば、こうなる。」 あるいは受け入れ基準を決める。「１００件のデータが１秒以内に処理できる」

ここ、見落とすと手戻りが発生しそうだな。

[matzryo]

このまえ開発チーム全員で半日話したのは、あるいみスプリント計画ミーティングだったな。スプリントが全期間だけど。

[matzryo]

毎日のスクラム。

[matzryo]

デイリースクラムは進捗報告ではない！すごくそうなりがちだけど。 進捗の不安な点を言う会。スプリントを達成するための障害に対処する会。

[matzryo]

レビューで気づいた点は、プロダクトバックログに追加する。 完了の承認条件は、あくまで最初にきめたこと。

完了の定義は、ビジネス、開発、複数のレイヤーにまたがって用意する。テスト、デモ、デプロイなど。

[matzryo]

ホワイトボードに付箋でタスクを見えるかする手法も人気。これをスプリントバックログに使うチームも存在する。

スプリントバーンダウンチャートも使える。そうか、スクラムは短いスパンだけ不確実性に対処するんだな。長期のバーンダウンチャートは作らない。

と思ったら、リリースバーンダウンチャートもあるのか。

[matzryo]

スプリントn週間のとき

スプリント計画ミーティングは2n時間まで スプリントレビューは1n時間まで スプリントレトロスペクティブは1n時間まで

[matzryo]

スプリント期間は、初心者だと、２〜３週間にすることが多い・ No. 1416/2759

[matzryo]

スプリントのタスクは、調整のために分割してもよい。

[matzryo]

ベロシティは安定性が大事。 長期的に実力に伴って上がるもの。 急がされると、上げるために無意識にずるをしがちなので、注意。

[matzryo]

ベロシティは結果。しかも指標のひとつ。

[matzryo]

ユーザーストーリーの形式で、プロダクトバックログを書くと、意図が伝わりやすい

[matzryo]

短く書いて、あとは対面コミュニケーションで伝える。

（文書化したほうがよくない？）

[matzryo]

技術的負債を追わなくて済むようにスプリントを決める。