「塹壕よりScrumとXP」読書メモ (3)
前々回、前回 にひきつづき「塹壕よりScrumとXP」の読書メモです。自分用ですので全くまとまっていませんし、誤りがあるかもしれません。（まさかこんなに長くなるとは…）
スプリントバックログ（続き）
- スプリントを始めるたびにきれいなバックログが作られる（紙を張り替える）
- 重要度の高いストーリーを上に貼る
- バーンダウンチャート
- 縦軸にストーリポイント、横軸に日付を取った折れ線グラフ
- 危険な徴候
- トレーサビリティはどうなってるんだ！
- 毎日デジカメで撮る
- でも、そんなに重要じゃないはず
- 気になるならホントの価値を見積もってみよう
- 見積単位
- 1実効人日＝6実効人時
- (7や8じゃないし、ましてや10や13なんかじゃない!)
- ストーリーは時ではなく、日単位で見積もっている
- 0.5が最小
チームの部屋をどう改造するか
- 設計コーナー
- のびのびと設計できる（日本じゃ難しそうだ〜）
- 重要な設計ドキュメント、タスクボードなどを貼る
- チーム全員同席!!
- 席を移動するのはめんどい。でも、効果的なチームを作りたいなら他の選択肢はない
- 大事なこと：声の届きやすさ、目の届きやすさ、隔離されていること
- 専用の部屋があれば一番良い
- POはチームと同席すべきじゃない （近くにはいたほうがいい）？
- マネージャやコーチは、緊密に関わるべきだが、あるときは自律に任せること
どうやってデイリースクラムを実施するか
スプリントデモをどうやるか
- デモは、何があってもしなければならない。たとえできていなくても！
- 厳しいルールだが、得られるものは大きい
- 目標が毎週達成されるので士気があがる
- チーム外の人にも結果がわかる。チーム間のやりとりが発生する
- お客から生のフィードバックがある
- 確実に作業を「完了」できる (99%の未完より、少ない完了)
- チェックリスト
- 成果物がなにかを説明できてるか
- 準備に時間をかけすぎてないか（派手なプレゼンは不要）
- 美しくより、手際よく
- 技術より、ビジネス視点で
- できれば見ている人に触ってもらう
- あんまり細かすぎる話はしない
- 「10000ユーザの負荷テスト」みたいなデモできない話は、テスト結果レポートを見せて説明する、のでもよい
スプリントのふりかえりをどうやってするか
- 起こったことを明確にする。改善の大切な機会
- チームの外の部屋ではやらない
- PO＋チームで実施
- スプリントバックログを見ながら、できごとを一巡りする
- 見積と実際の速度がちがうところは、要因を分析してみる
- 次スプリントへむけてのブレスト。良かったこと、もっとよくできそうなもの、改善点 (KPT?)
- それらにチームで投票し、次にやることを決める
- チームが得たナレッジは他のチームにも共有した
- マネージャが非公式に動き、他のチームのふりかえりで広めたりした
- 問題を明確に認識さえすれば、それは自然と解決していく
- なにか不平を言うたびに新しいやり方を導入していると、みんな問題をあげるのが嫌になってしまう
- 典型的なふりかえり事項
- 「ストーリーをブレイクダウンする機会をもっと増やそう」
- 問題を認識したことで、次のスプリントでは皆がそう動く
- 繰り返し起こるならスプリントの期間を長くする
- 「外部の邪魔が多い」
- フォーカスファクタを低くする
- 邪魔する人をメモっておく
- スクラムマスタかPOを通すよういっておく
- 持ちまわりで「ゴールキーパ」を設定し、そこに全部の邪魔を流すようにする
- 「仕事抱えすぎた」
- 「作業環境がうるさい、汚い」
- 環境を改善するか、いっそ移動する。上位管理者への働きかけ
- （これは気にする人と気にしない人の同居がむしろ問題になったなー、自分の場合）
- 「ストーリーをブレイクダウンする機会をもっと増やそう」
スプリント中の休憩期間
- 休まないと死ぬる
- スプリント間に休憩期間がまったくないと、チームもPOも情報を整理する期間がなくなってしまう
- スプリント振り返りとスプリント計画はちがう日にする
- 「自由研究日」を設ける (Googleみたく)
リリースの計画と価格確定させた契約をどうするか
- この質問に答えるよう試みる：「この新しいリリースバージョン 1.0 を、最も遅い場合、いつ納品できるのか」
- 価格確定された契約の場合、最終的になにを納品すべきか判別するために、重要度に「しきい値」を設ける
- 例：重要度100以上のアイテムは1.0に含めないと死刑に処される。
- 例：50〜99は含めるべきだが、速やかな追加リリースでもいいかもしれない。
- 例：etc...
- 重要度の高いアイテムは、あらかじめ見積もっておく必要がある
- 正確さのため、チームに見積もらせること
- あまり時間をかけすぎないこと
- 見積は確定したものではないことを理解すること
- フォーカスファクタを決め、チームのスプリント速度を見積もる
- ここまでできたら、最終的な納品日までの期間に、ストーリーを重要度順におさめていく
- 現実はそのとおりにはいかない。スプリントごとにお客さんと調整しよう
- 真剣に学びたいなら「アジャイルな見積と計画づくり」を読もう (うう、買ったけど未読…)
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 74人 クリック: 764回
- この商品を含むブログ (225件) を見る
ScrumとXPの結合
- XPはプログラミングに、Scrumはマネジメントと組織に、それぞれフォーカスしている
- かぶってるプラクティスはScrumに従った
- ペアプログラミング
- コードの品質が高まる
- 相互チェック「おいおい、この機能はほんとにこのスプリントに必要かい？」
- 非常に疲れるので常にやるのは無理
- 知識がすごい早さで共有される
- ペアプロがあわない人もいる
- コードレビューも兼ねられる
- 強制はしないこと
- TDD
- インクリメンタルな設計
- 最初からぜんぶ設計するより、あとからリファクタリングする
- CI
- CIサーバは審判
- チェックイン→ビルド→失敗するとメールが来る
- 仕組みをつくるのは手間がかかるけど、その価値はある
- コードの共同所有
- 情報満載の仕事場
- コーディング規約
- 安定したペース、活気ある作業
- すぎた残業は、生産性と品質を犠牲にする
テスト
- 受け入れテストは避けられない!
- チームのコード品質をあげることで期間短縮はできる
- テスタをチームに入れる
- テスタは「完了」を通知してくれる。デモにも最適
- まだテストするものがないときは、環境づくりをする
- スプリントの作業量を減らし、受け入れテストサイクルを短くする
- 次のスプリントで、受け入れテストチームが発見した前のスプリントのリリースのバグを直すはめになる
- 混乱する
- うまい解決策はあるのか？
- １：古い機能が未完成であるうちは、新しい機能に手を付けない
- ２：新しい機能に手をつけてもいいが、古い未完成の機能を優先する
- スプリントの間に長さ不明なリリース期間を設けるのは、スプリントのリズムを崩すのでお薦めしない
- 受け入れテストから戻ってくるバグフィックスを考慮にいれてスプリント計画を立てる
- 良いテストツールや自動テストを使おう
複数のScrumチームを運営する
- 大きすぎる少数のチーム ＞ 小さな分割されたチーム
- バーチャルチームの存在
- チーム分割は本当に難しい
- 最適なチーム規模は 3-8 人
- 複数チームのスプリント期間は同期させたほうが効率的
- チーム割り当て
- 最初だけえらい人が決めて、あとは自律的な解決にまかせる
- コンポーネント（DB, フロント等) に特化したチームはうまくない
- チームを再編成するときは、それが一体化を壊す可能性を意識する
- 「一時的なチームメンバ」を入れることはよくない
- ("客先常駐"の商売とは相性が悪い考えですな)
- Scrum of Scrum
- (この項、あまり理解できていない)
- だいたいは報告の場になる。大抵の人は情報に飢えている
- デイリースクラムを同時に行わないことで、POやマネージャが参加しやすくする
- 火消しチームにScrumチームを守らせる
- 複数チームがいる場合も、POとバックログは１つ
地理的に離れたメンバーがいる場合
- Webカメラ、ヘッドセット、会議マイク、デスクトップ共有などのツールを駆使する
- 別の拠点につながる「遠隔ウィンドウ」をつくる
- 定期的にお互いを尋ねる（物理的に）
- オフショア開発
- 離れたチームではなく、離れたチームメンバからはじめた
- 最終的には、離れたチームに行き着くだろう
- (あまのりょーさんの MY JOB WENT TO VIETNAM? を思い出しました)
- 在宅勤務
Scrumマスタチェックリスト
ここまで。明日のCSMが楽しみ！
大切な事は、自分の仕事の現場で最良な方法をつねに模索し続けることだと理解しますた。
「塹壕よりScrumとXP」読書メモ (2)
昨日に引き続き「塹壕よりScrumとXP」の読書メモです。自分用なのでまとまっていません。かっこ内は自分の感想です。
スプリント間のコミュニケーションについて
- 「スプリント情報ページ」をつくり、何が起きているかを明らかにする
- URLをメールし、紙に書いて貼り出す
- デモの予定も知らせる
- 「何が起こっているかわからない」と言わせない
- (徹底した情報公開。エンジニアのマインドセットも変更が必要そう・・・)
スプリントバックログ
- スプリント計画ミーティングと、最初のデイリースクラムのあいだにScrum Masterが作成する
- (この日は遅くなるね！)
- スプリントバックログを書くには、壁のタスクボードがよい
- (Excelでいろいろ試したあとでの結論らしい)
- ホワイトボードは埋めないほうがよい
- 付箋はテープで貼らないと落ちる
- (これ、前に id:DiscoveryCoach さんに教えてもらった！)
- タスクボードの要素
- Not Checkout: スプリントの作業前ストーリと、そのタスク。
- Checkout: 作業中のタスク。
- Done: もはや誰の作業も不要なタスク。全タスクがDoneになったストーリーはDoneになる。
- Unplanned items: 計画外アイテム (?)
- Next: つぎのスプリントに含めるストーリー？
時間切れにて中途半端ですが、今日はここまで。
「塹壕よりScrumとXP」読書メモ (1)
こんど Henrik さんの CSM を受講するので「塹壕よりScrumとXP」をちゃんと読んだ。
はじめに
- Scrum はフレームワーク。どうやるかまでは教えてくれない。これはぼくの戦争体験談だ (!!)
プロダクトバックログ
スプリント計画ミーティング
- スコープ、重要度、見積もりという３つの変数について話しあう場
- POが参加してくれない問題をどう解決する？
- わかりやすく説明して説得する
- 代理人をたてる
- 参加できるまで延期する
- 内部品質と外部品質
- 外部品質はユーザにわかるもの。使いやすさ、操作性の良さなど
- 内部品質はユーザには見えない。コードの質、テスト結果など
- 外部品質はスコープとして扱える（＝交渉できる）が、内部品質はできない
- スコープとして扱うと、保守性が下がり、かえってコストが高くなる
- 例：「これ応急処置でやっちゃおう」
- POはこのことを学習してくれる
- ミーティングは短く終わらす。タイムボックスをからだで覚える
- スプリントの最適な長さはいろいろ試して決める
- 決まったら固定する
- 著者のチームでは3週間だった
- 長さが決まると快適になってくる。リリース日についても悩まない
- スプリントのゴールを決めるのはむずかしい
- でも、ないよりはまし
- 「どうしてこのスプリントを実施しているのか？」をつねに考える
- プロダクトバックログ→スプリントバックログ への移動
- ストーリーの大きさでスプリント中にやれる事が決まる
- だから相対見積もりがだいじ
- スプリントに含めるストーリーが何かはチームが決める
- POではない
- 含まれたストーリーが不服な場合、POは他のストーリーのスコープを変えたり、分割したりして調整できる
- (外部品質を別ストーリーに移したりってこともあるな)
- (ここが一番「これ応急処置でやっちゃおう」になりそうなので気を付けないと)
- 見積もりはどうやるか
- 小さいチームなら直感で決められる
- 見積速度：１スプリントで完了したストーリーの大きさ
- 稼働人日×フォーカスファクタ＝見積速度
- フォーカスファクタは前のスプリントを参考にして求められる
- コンピュータ上でストーリーの洗い出しをやっていると、問題点に気づきづらい
- PCをいじってる人以外は、自分が参加してるという意識を持ちづらくなる
- だからインデックスカードを使うお！！
- ストーリーごとに完了の定義をきめるのはだいじ
- 厳密なチェックリストより、直感を重視する
- プランニングポーカー
- チーム全員がストーリーを理解するのを助ける
- 相互協力できるようになる
- ストーリーを明確にする
- ストーリーに対する誤解を避けるには、ぜんぶのストーリーについてちゃんと(POのいる場で)話し合う
- (わかったふりして飛ばすとそこで躓くのは、よくありますね…)
- ストーリーが小さすぎたり、大きすぎるときは要注意
- タスク分割はWF的に感じられる場合もある？
- Techストーリーについて
- 直接顧客への価値にむすびつかないけど、やらないといけないこと。例えばCIサーバの構築とか
- 通常のストーリーに組み入れられないか検討してみる
- 無理そうならTechストーリーを作成。(POは編集できない)
- Techストーリーの実施によってどのようなメリットがあるのか、POにきちんと説明する
- POがTechストーリーの重要度を理解できるなら、判断してもらうのがベスト
うーん、盛りだくさんだー。（つづく）
超いまさらですが RubyKaigi2011 に１日だけ参加した感想です
超いまさらですが、下書きが発掘されたので。
今年の 7/16〜18に行われた RubyKaigi2011 に１日だけ参加しました。RubyKaigi にはずっと来たかったので、終わる前に来られてよかったです。
以下、個人的な感想ですが、メモがわりに残しておきます。
- SIerのなかのRubyistが考えるべきこと 素晴らしい講演。グッときました。
- アーロンさんの基調講演。境界についてのたくさんの問題提起。オープニングに相応しい引き込まれる内容でした。道場movieに大受け。
- 「アジャイルサムライ」買えた！「7つの言語、7つの世界」も。matz さんのサイン一番乗り。
- 地下の AgileUXD がとてもおもしろそうでした。試みも、作っているものも。
- 闇RubyKaigi では勢いあまってLTドタ応募してしかも gdgd でごめんなさい。
- 個人的にとても嬉しかったのは休憩時間にかくたにさんが 7月6日の DevLOVE の感想を述べてくださったことです。Rubyコミュニティにはああいった場は少ないから良かったと。ありがとうございます、励みになります。
- IRCでの同時通訳がすごかった。本当にすごかった。
- スタッフの皆様、お疲れ様でした。素敵なイベントを開催してくれてありがとうございました。
アジャイルサムライ読書会（湯島道場）に参加しました。
7月27日に湯島で行われた アジャイルサムライ読書会 湯島道場 に参加してきました。読書会の詳細については、リンク先にわかりやすい解説がありますのでぜひご覧ください。
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (254件) を見る
みんな悩んでいる
こうした道場に来る方々ですから皆さんアジャイル開発に興味を持たれているわけですが、やはり共通の悩みとは「どうやって導入するか」のようでした。お客さんを巻き込めない、まわりが無関心…
しかし、そんな中でも悩みを一人で抱え込まず、こうした場で共有することで第一歩が踏み出せるだろう、というお話がありました。たしかに、一人で悩んでいても始まりません。
悩みを共有できる、読書会のような場は貴重だと改めて感じさせられました。
懇親会でのお話
懇親会でもいろいろといいお話があったのですが、思い出せる限りで書いてみます。
まとめ（になってないまとめ）
アジャイルサムライ、まだ7章までしか読めていませんがとても良い本です。ふつうの本ではなかなかお目にかかれない「プロジェクトのはじめ方」をはじめ、ソフトウェア開発の奥義をとってもわかりやすくかつ濃い内容で説明してくれます。実践したくなるヒントが多く詰まっている本だけに、読書会の存在は重要だと感じました。
開催してくれた @ShiroKappa さんをはじめとするスタッフの皆様、ありがとうございました。次回は定刻に来る or 早めキャンセルを心がけます (滝汗)。
Manage It! 現場開発者のための達人式プロジェクトマネジメント
- 作者: Johanna Rothman,でびあんぐる
- 出版社/メーカー: オーム社
- 発売日: 2008/10/18
- メディア: 単行本（ソフトカバー）
- 購入: 15人 クリック: 145回
- この商品を含むブログ (50件) を見る
DevLOVE HangarFlight Ruby編「あなたの話が聞きたい。」のこと
きょうから RubyKaigi ですね。行かれる方はお気をつけて。
さて、去る7月6日に RubyKaigi Advent Calendar の一部として DevLOVE HangarFlight - Ruby編「あなたの話が聞きたい。」 を開催しました。詳細はリンク先の DevLOVE 公式ブログを見ていただくとして、ここでは開催に至るまでの経緯とかを書いてみようとおもいます。
はじまり
- 1月ごろに @bash0C7 さんから RubyKaigi Advent Calendar を DevLOVE でやりたい！というお話があった
- でも、@bash0C7 さんは RubyKaigi の準備でいそがしい
- DevLOVE の人だれかやらない？
- ・・・（手を挙げる）！
- それじゃ @kakutani さんに紹介するよ
という流れがあって、今年のデブサミでたどたどしい挨拶を @kakutani さんにしつつ、こんなことをやりたいですという話をしたような気がします。はっきりいって緊張しすぎて何を話したか覚えていないのですが、大筋では最終的なイベント内容とずれていなかったような気がします。
たぶん自分の思いとしては、好きな Ruby で 4tate した人の話が聞きたかったのでした。
わたわた
自分のはっきりしない思いが形になるまでは、わたしの力不足もあり、かなり時間がかかりました。なんとか最終的には extreme なダブルイベント開催となりましたが、6月に入るころは本当に開催できるのか、プレッシャーで気が気ではなかったのを覚えています。w
ダブルイベントの先輩はこちらです。DevLOVE Birthday! 〜RubyKaigiの帰り道に生まれしもの〜
わたしが余りにもワタワタしていたためか @DiscoveryCoach さんが会場やスピーカの手配、ダイアログファシリテーターとしてのご参加など大幅に手助けしてくださり、@bash0C7 さん、@papanda さんにも助けられつつなんとかアウトラインをつくっていけました。みなさん、ありがとうございます。わたしの人生のほとんどは他人の手助けでできています。
ただ、最初にこのイベントの開催でご相談させていただいた @yotii23 さんには、なかなかまとまらずご迷惑をかけてしまいました…。うまく進められなくてごめんなさい。
また、@changeworlds さんにはわたしが Redmine プラグインをつくったときの話が聞きたい！とお願いした際、いろいろと貴重なアドバイスをいただきました。それは彼の講演にもあった「非忠誠の誓い」にもつながる内容でした。あれがなかったら、いろいろな人の話を聞きたいというわたしの思いは折れていたかもしれません。大きな感謝を。
それから、懲りずに見守ってくれたわたしの家族に、最大の感謝をおくります。
かいさい
そんなわけで（どんなわけで）さまざまな方の手助けがあって無事に開催されたわけですが、もう録画の手配ができなかったことが残念でたまらないぐらい素晴らしい内容でした。こうなると、ビデオカメラが欲しくなりますね（！）。ぜんぶの方に謝辞を書きたいのですが時間が・・・！！ひとまず今日はここまで。
DevLOVE 我々は、現場から学ぶ。 〜パターンマイニングの実践〜 に参加してきました
6月23日に開催された「DevLOVE 我々は、現場から学ぶ。 〜パターンマイニングの実践〜」に参加してきました。
無数の開発プロジェクトがあるように、開発の現場にということで、鷲崎さん・羽生田さん・本橋さんによる、「パターンマイニング」実践ワークショップを通じてその方法を学ぼう、というのが本イベントの趣旨でした。
眠るノウハウや定石もまた、無数に存在するはずです。
これらの経験が、活かされることなく、プロジェクト完了とともに
埋葬されるに任せるのは、あまりにも甲斐の無い話だと思いませんか。
では、具体的にはどうすれば体験を活かすことが出来るのでしょうか。
ワークショップは「協調型マイニング」という手法で行われました。以下、個人的なメモです。誤り等ありましたらご指摘下さい。
パターンマイニングって？
- パターンとは、特定の状況で繰り返しおきる「問題＋解決」のこと
- パターンは名のない質（QWAN）を備えている
- パターンを知っていれば、同じことで何度も悩まなくてすむ（＝これ、前にもあった！）
- パターンマイニングとは「経験」を抽象化して、パターンを掘り出すこと
- パターンの効果範囲と効き目はトレードオフ。ある状況に特化しているほどよく効くが、適用できる状況は少なくなる
協調型マイニングとは？
- 数名一組でパターンマイニングを行う手法
- パターンを抽出するドメイン（特定の問題領域）を決める
- それぞれの成功体験を付箋に書く
- 書いた付箋を貼りながら他の人に説明する。このとき、似ている内容の付箋は近くに貼っていく
- 初期状況、アプローチ、結果
- 似ている付箋どうしからパターンを抽象化できないかみる。できそうなら付箋に書いて貼る
- 状況、問題、フォース、解決、結果
- パターン名をつけてまとめ、全員に発表！
最後の「フォース」というのはスターウォーズ用語で、パターンマイニングの肝となる部分だそうです。説明を聞いたときは正直よくわからなかったのですが、つぎのワークショップで明らかになりました。
協調型マイニングの実践
ここからは５人１組となって、実際にパターンマイニングをやってみました。
講師の鷲崎さんより「お題」がいくつか出され、グループごとにそれを選択します。このお題が前項でいう「ドメイン」となります。ちなみに、私のテーブルでのお題は「転職」でした。他にも「勉強の仕方」「通勤」「読書の仕方」などなど。
あとは前項の手順に従ってみんなでパターンを抽出していきます。
貼られた付箋のようす。みなさんの体験を聴くだけでも、かなり勉強になりますね。
スライド説明のときに謎だった「フォース」ですが、ワークショップでの説明によって「この状況、この問題で、なぜその解決を選んだかの理由」だとわかりました。そしてこのフォースを抽出することで、いっけん似ているパターンもさらにブレイクダウンできることが判明したりするのだそうです。
フォースの抽出によって、パターンが真に使えるものに変わるのだな、と感じました。
最後に、すべてのテーブルで結果発表。パターンの名前付けにも個性が。私たちのグループで導出されたパターンは以下のようなものでした。
- パターン名：めぐりあい
- ドメイン：転職
- 状況：自分の将来が不安
- 問題：新天地を見つけたい
- フォース：
- 社内では情報を得にくい
- 転職エージェントは堅い
- 社外ならざっくばらんに聞ける
- コミュニティのことは知っていた
- 解決：コミュニティで情報を集め、新天地を紹介してもらう
- 結果：新天地にめぐりあえた
感想
たいへん面白く、そして有益なワークショップでした。これを職場でやってみたらさぞ刺激的でしょう！欲を言えば、他のテーブルの結果が見られるとよいなと感じました。
講師のみなさん、DevLOVEスタッフのみなさん。ありがとうございました。
- 作者: 中谷多哉子,青山幹雄,佐藤啓太
- 出版社/メーカー: 共立出版
- 発売日: 2001/05/15
- メディア: 大型本
- クリック: 2回
- この商品を含むブログ (2件) を見る
