Readingagilesamuraiinchiba20120728

アジャイルサムライ読書会 千葉道場 第4回 議事録

参加者は、自由に編集してください。

アジャイルサムライ読書会 千葉道場 トップへ

■ 参加人数

• 2名

■ 実施範囲

• 第4部

■ サマリー

• 実施範囲について、解釈を加える

■ 「第9章 イテレーションの運営：実現させる」

• 肝に銘じておくこと！
  1. 文書をまとめる時間はない
     ⇒ 本当に必要な物だけを、必要なときにアウトプットする
     ⇒ 1イテレーションで必要な文書を対象とする
  2. 開発プラクティスをプロジェクトに根付かせる
     ⇒ 結合して、全体的に動作するようにしておく（結合したら動かない！てことがよくある）
     ⇒ デプロイ環境をさっさと用意しておく
  3. テストと開発は同時進行である
     ⇒ TDDの実践でもいいし、こまめにUnitTestを記述して実行する
     ⇒ プロジェクト初日から正しく動作するようにしておく
     これらを、イテレーションで遵守する

プロジェクト初日から、システム全体が適切に動作し続けなければならないだってー！？

ﾅ ﾅﾝﾀﾞｯﾃｰ!! Ω ΩΩ
ウォーターフォールみたく、最後にシステム全体を結合して動作確認をするっていう手法はダメ！
日々、エラーを出さず、動作するようにしておく
仮実装であっても、エラーを出さない
　⇒ 画面遷移とか、モックでも正しい遷移をする

ユーザーストーリーに対して行うこと

1. 分析して設計する（段取り）
   文書の作成粒度は、下記を目安に。

• 作業者が隣同士だったら
  どんな実装にするとか、必要なテストとか、会話した内容を文書にしておく
  図や画像で補足しておく
• 作業場所が離れた場所だったら
  ストーリーに対する、簡潔な概要を記述する（1ページ程度）
  ストーリーをタスクに分解する
  テストの一覧を記述する
  誤解の起きない内容にしておく

★納品レベルの文書は開発時は不要である
★チーム内での認識を合わせられる内容であれば良い

このような、必要な物を、必要なときにという手法を、
ジャストインタイム分析と呼ぶ。

ジャストインタイムのいいところ
* 最新かつ充実した情報で分析できる
* 顧客と学ぶ機会が増える、だから分析がうまくなる
* （いろいろと手をつけすぎて）手戻りが「大量」に発生するのを防ぐ

では分析するにあたり・・・
1. ストーリーからフローチャーを作成しよう！
* 業務フローが把握しやすい
2. ペルソナを作ろう！
* ペルソナとは、ユーザーの役割ごとの説明をするもの
* ペルソナは「課題を抱えている」
3. ペーパープロトを作ろう！
* システムに画面があれば、ペーパープロトをいろいろ作ってみる
4. 受け入れテストの条件を作ろう！
* お客さんと一緒に作る
* わからないことは、お客さんにどんどん訊く
* 実は不要な機能が判明するかも

ストーリーの中身は、開発が進むにつれて変わっていく可能性がある。

2. 開発する（作業）

   • 自動化テストを書こう
   • 設計を継続的に改善しよう
   • Jenkinsを使おう
   • 顧客がシステムについて語る言葉にあわせてコードを書こう（ちょっとよくわからなかった）

   イテレーション・ゼロの導入
   イテレーション・ゼロとは、「開発をはじめる」ための準備期間。
   例えば・・・
   * SCMはどうする？とか
   * ビルドのやり方はどうする？とか
   * 開発環境、デプロイ環境はどうする？とか

   開発が滞り無く進められるように、ひいてはこの章の冒頭にあった「肝に銘じておくこと」の「プロジェクト初日から正しく動作するようにしておく」を実践できるようにするためのもの。

3. テストする（結果確認）

   • いつでも受け入れテストができるようにしておこう これは、自分たちの成果に自信をもつため

   カンバンについては割愛。

■ 「第10章 アジャイルな意思疎通の作戦」

• イテレーションでやるべき4つのこと
  期待マネジメント、フィードバックループは、アジャイルプロセスに欠かせない。そこで、下記の4つのミーティングを行う。
  1. ストーリー計画ミーティング
  2. ショーケース（フィードバック）
  3. イテレーション計画ミーティング
  4. ふりかえり（改善）

1. ストーリー計画ミーティング

• これから始まるイテレーションで取り組む（分析済みの）ストーリーの「準備」が整っていることを確認する
  • 受け入れテストのレビューをお客様にしてもらう
  • 開発が見積もりの数値を確認する
  • 漏れていることがないか確認する

2. ショーケース

• お客さんに成果を見せて、フィードバックを得る
• デプロイした本物のコードを使って、成果を見せる
  • 図を見せたり、目論見を語る場ではない！
  • 完成していないものは見せてはダメ！

3. イテレーション計画ミーティング

• 開発側とお客様が一緒になって、次回のイテレーションを計画する
• 話し合っておきたい問題を話す（結果をチームで共有する）
• プロジェクトの状況を確認する

4. ふりかえり

• 犯人探しをする場ではない！
• KPTを利用するのもアリ
• メンバーのモチベーションがあがるらしい

■ 「第11章 現場の状況を目に見えるようにする」

フライト案内板はすごい！！

さて、携わっている案件が炎上しそうな状況になった・・・どうする？

• 経営者に状況を説明する
  • インセプションデッキを使う（プロジェクト全体）
  • リリースボードを使う（現在地点、どこまできたのか）
  • ストーリーボードを使う（着手中タスクの状況）
  • バーンダウンチャートを使う（完了時期）

上記を利用することで、逐次、状況を把握できる。

チームの意思を明確にする

1. チームの約束を決める
   • チームの目指す方向性
   • チームメンバーとして求められる条件
   • 特にお堅い内容じゃなくてOK
2. チームが大事にすること
   • 感覚的なものでいい
   • 手を抜かないとか
   • 異論を認めるとか

プロジェクト用語集を共有する

認識の齟齬が発生しないために用意する。

バグを監視する

イテレーションのうちの、何パーセントかをバグ退治にあてる。

以上。