読者です 読者をやめる 読者になる 読者になる

アジャイルサムライのメモ。

ch6.ユーザーストーリーを集める

  • よくかけているユーザーストーリー

    • 顧客にとって 何かしらの価値が書かれていること。

      • お客さんが対価を払ってもいいと思うもの

      • ビジネスの観点から評価できるもの

    • エンドツーエンドである

    • 独立している

    • 交渉の余地がある。

    • テストできる

      • ここは自分の考え方になかった部分だ…

      • 完了の基準が明確になっている。

    • 小さい、見積もれる

      • ストーリーを1〜5日で完了できるサイズに
  • デイブの話

    • さくさくとかかっこよくとかでもいいんだ。「制約」。
  • ユーザーストーリーのテンプレート

<ユーザの種類> として <達成したいゴール>をしたい なぜなら<理由>だから

  • ユーザーストーリーのワークショップ
    • 実践してみたいなぁ。

ch7. 見積もり:当てずっぽうの奥義

  • 概算見積もりなんて当てずっぽう。

  • ほしいのはこのプロジェクトを与えられた期間とリソースでやり遂げられるのか。

    • 今後の計画を立てられる

    • 見積りは当てずっぽうである前提を持ってる。

    • ソフトウェアの複雑さを認めている。

  • 相対サイズで見る。

    • どうやって相対化するんだろう。

      • お互いがお互いに対してどれくらいの大きさなのかを相対的に見積もる。

      • 自分たちの開発チームがどれくらいの速度で仕事を進められるかを計測する。

        • 個人で言うと、ポモドーロの実施してチェック入れていって1日で振り返りするみたいな感じかな。

        • でも一番最初って自分の感覚なんてつかめないよなぁ…。

        • あ、最初っから完璧にしようとしてはいけないのか。

  • 相対見積もりは1営業日ではない

  • ポイント。

    • 1pt : 楽勝。 3pt : やれないことはない。 5pt : ちょっと大変
  • 見積もりの技法

    • 三角測量。基準になるストーリーとの相対サイズを見極める。

      • 基準になるストーリーの選び方。

        • 論理的なグループ分けができそうなものはなにか

        • エンドツーエンドになっているストーリーはあるか

        • プロジェクトを象徴するような代表的なストーリーはどれか。

      • 見積もりの再定義は起こりえる。

    • プランニングポーカー

      • 見積もりゲーム

ch8 アジャイルな計画づくり:現実と向き合う

  • 慣れてもらうしかない。

  • 計画の立て方の4つの基準

    • 顧客にとって価値ある聖歌を届けられる計画

    • わかりやすくありのままを伝える、誠実な計画

    • 約束したことを守り続けられる計画

    • 必要に応じて変更できる計画

      • 見た感じ、最後の2つとか両立するんだろうかと思う。
  • アジャイルな計画づくりとは

    • チームの開発速度を計測して、その速度をもとにプロジェクトの完了時期を見通せるようにすること。
  • マスターストーリーリスト

    • 顧客がソフトウェアで実現したいと思っているありとあらゆるフィーチャが並んでいるリスト
  • ベロシティ

    • ユーザーストーリーを動くソフトウェアに変換する速度のこと。
  • イテレーション

    • 1~ 2 week
  • 最初から厳格なコミットメントとして扱うと、プロジェクトは始まる前から死ぬ。

  • やるべきことが多すぎる場合はやることを減らす。

    • 何を基準にやめていくかを考えるんだろう。
  • やってほしいストーリーを追加するときは、既存のストーリーを削ること。

  • マスターストーリーの長さを一定にする。

    • 個人で言えば、ToDoリスト(ポモドーロでいうところの在庫アクティビティ)を一定にするってことか

    • 僕自身、どうしてもやることを増やしてしまいがちになるからなぁ。もっと、やらないことに対して厳しくいくべきだと思うわ…。

  • 初回の計画づくり

    • ステップ1:マスターストーリーリストを作る

      • いつだって与えられた期間や資金よりもやるべきことは多い

      • リリース

        • MMF

          • Minimal : 最初のリリースに含めるフィーチャは、最も価値の高いものだけにしておくのがいいだろう

          • Marketable : お客さんにとって価値があるか。

      • 最小で市場価値があることが大きな柱になる。

      • あとで自分で試す。

      • シンプルさ(ムダなく作れる量を最大限にすること)がアジャイルの本質。

    • ステップ2:プロジェクトの規模を見極める。

      • 三角測量・プランニングポーカー
    • ステップ3:優先順位をつける

    • ステップ4:チームのベロシティを見積もる

      • チームのベロシティ = 完了させたストーリーポイントの合計 / イテレーション

      • フィーチャを届ける ⇛ コーディング+分析+テスト+設計

      • 積極日間な見積りにしすぎないこと。

        • うわーこれやってるわぁ…orz
    • ステップ5:期日を仮決めする。

      • 期日の固定 = 「プロダクトはこの日が来たら何がなんでもリリースする」と宣言するのと同義。

      • フィーチャセット固定。中核をなすフィーチャのまとまりをすべて完成させるまでは作業を続ける。

    • バーンダウンチャート

      • Pivotal Trackerでも表示されてたやつだ。
    • 実践したくなってきた。Pivotal Trackerでやってみよ。この章を読んだ後に…。

    • プロジェクトを途中からアジャイルにしていく

      • 今やってる開発がうまくいっていない / とにかく早く、何らかの成果をあげなきゃいけない。のどちらかに当てはまる?

        • 僕は後者かなぁ…
      • インセプションデッキを作ってみる。

        • ふむふむ。みどころスマホインセプションデッキ作りながら見積もりまでいけそうだ。

        • このプロジェクトにいるのはなぜ?

        • 成し遂げようとしていることは何?

        • 顧客は誰か

        • 解決すべき主要な課題

        • 最終判断を下すのは誰か

      • とにかく早く、何らかの成果をあげなきゃいけないの場合は、今のプロジェクト計画を捨てる。

        • うおおおお。捨てよう。捨てよう。

        • これまでのやつをしっかりやっていく。

イテレーションの運営

  • 1 week ~ 2 week

  • ステップ1:分析と設計

    • 1ページぐらいにまとめる。

      • 説明

      • タスク

      • テスト条件

    • 必要な分だけ、必要なときに掘り下げて分析する

    • ストーリーの実装を予定しているイテレーションの1つ前のイテレーションで分析する。

    • フローチャートを書いてみる。

    • ペルソナ

      • ソフトウェアのユーザを役割ごとに簡単に説明したり、典型的な姿として書いたもの

        • どこまで掘り下げておくべきなんだろう。

        • 例を見た感じだと

          • 役割名

          • 役割の説明

          • 役割がどんな機能をもっているのかを作るソフトウェアの目線で書く。

    • ペーパープロトタイピング

    • 受け入れテスト

      • このストーリーが完成したことを確認できそうなことを3つ書く。

      • 好きなだけ詳細に踏み込んでもいい。

      • しっかりと把握できるまでどんどん質問していく。

  • ステップ2:開発:作業する。

  • ステップ3:テスト:作業の結果を確認する

    • 受け入れテスト:”受け入れテストはシステムが正しく作られているかではなく、業務に使えるかの確認が中心" http://www.itmedia.co.jp/im/articles/1111/07/news124.html

    • カンバン

      • 仕事の流れをスムーズにする。

      • ストーリーボードとの違い

        • WIP:チームが同時に着手する作業数はこの制限を超えてはいけない。

          • どうやって決めるんかな?勝手に自分で?
      • 運用とかだったらカンパンがいいかもねーだって。

      • 実際のアジャイルの事例とかみておきたいなー。

アジャイルな意思疎通の作戦

  • イテレーションでやるべき4つのこと

  • ストーリー計画ミーティング

    • ストーリーの準備が整っているかを確認する。

      • 受け入れ条件テストのレビュー

      • 見積の数値を確認

      • 調査に漏れがないか

    • ストーリーが大きい場合は1回のイテレーションに収まるように分割して計画を更新する。

  • ショーケース

    • 成し遂げた成果を広めて、クライアントからフィードバックを得る
  • イテレーション計画ミーティング

    • プロジェクトの健康状態を確認するタイミング

    • バーンダウンチャートでプロジェクトの完了の見通しをする。

    • 悪いニュースは早めに

    • 「だけど」を避ける

  • ミニ振り返り

  • デイリースタンドアップ

    • 10分以内で自分のやることをまとめる。

      • これは個人だと、今日のTODOとしてreviewに書き出す感じにしてもいいかな。

      • やったこと・今日やること・開発を妨げそうなこと

      • 毎日コミットメントをすること。

        • ここなんか、週の最初は頑張るんだけど、後半から息切れしちゃうんだよなぁ…
  • 大事なのは勝ちにつながる習慣かどうか。

  • イテレーションで成果がでなくても、その価値が出なかったことを伝えること

    • ここは心が痛い…orz
  • プロジェクトの状況が芳しくないからといって、そこから目をそむけてはならない。その失敗を受け入れ、改善に取り組むこと。

ch11 現場の状況を見えるようにする。

  • インセプションデッキを見える位置にある。

  • リリースボード

    • チームがどこまで完了しているのかがひと目で分かる

      • イテレーションごとに分けられた完了したストーリー

      • 残っているストーリー

  • ストーリーボード

  • チームの約束

    • 現在のチームメンバーにとってはどんなチームなのかを言葉で表す
  • チームが大事にすること。

    • チームの約束よりももっと感覚的なもの。
  • DDD本は必読だって。

  • イテレーションの10%はバグを潰すことにあてて、技術負債を返済するのもいいだろう

ch12 ユニットテスト:動くことがわかる, ch13 リファクタリング, ch14 テスト駆動開発,

  • ユニットテスト:ビルドしたコードがちゃんと動くか

    • メソッドレベルの粒度で書く。
  • リファクタリング:コードをシンプル&クリーンで読みやすくする

  • TDD:複雑さに立ち向かうための設計手法

    • ルール1:失敗するテストを1つ書くまでは、新しいコードを一切書かない

    • ルール2:「危なっかしいところ」はすべてテストする。

      • ストーリーのテスト条件に照らし合わせる
    • テスト駆動開発入門をよもう。

    • The RSpec bookをよもう。

  • 継続的インテグレーション:決まった感覚で統合し、プロダクトをリリース可能を保つ仕組み。

    • リリースに備える。

      • あとで直すで逃げない。
    • 必要なツール

      • ソースコードリポジトリ

      • チェックイン手順

        • 最新のソースコードを取得

        • 変更を加える

        • テストを実行する

        • 作業中に発生した更新差分を取得

        • 再度テスト

        • チェックイン

      • ビルドの自動化

        • Jenkins
      • 作業単位を小さくする姿勢

        • 10~15分タイン位でインテグレーションする

アジャイルの道

  • 毎週、価値ある成果を提供しているか。

  • たゆまぬ改善の努力をしているか。

これから。