ch6.ユーザーストーリーを集める
よくかけているユーザーストーリー
顧客にとって 何かしらの価値が書かれていること。
お客さんが対価を払ってもいいと思うもの
ビジネスの観点から評価できるもの
エンドツーエンドである
- すべてのアーキテクチャを貫いていること。
独立している
交渉の余地がある。
テストできる
ここは自分の考え方になかった部分だ…
完了の基準が明確になっている。
小さい、見積もれる
- ストーリーを１〜５日で完了できるサイズに
デイブの話
- さくさくとかかっこよくとかでもいいんだ。「制約」。
ユーザーストーリーのテンプレート
<ユーザの種類> として <達成したいゴール>をしたい なぜなら<理由>だから
- ユーザーストーリーのワークショップ
- 実践してみたいなぁ。
ch7. 見積もり：当てずっぽうの奥義
概算見積もりなんて当てずっぽう。
ほしいのはこのプロジェクトを与えられた期間とリソースでやり遂げられるのか。
今後の計画を立てられる
見積りは当てずっぽうである前提を持ってる。
ソフトウェアの複雑さを認めている。
相対サイズで見る。
どうやって相対化するんだろう。
お互いがお互いに対してどれくらいの大きさなのかを相対的に見積もる。
自分たちの開発チームがどれくらいの速度で仕事を進められるかを計測する。
個人で言うと、ポモドーロの実施してチェック入れていって１日で振り返りするみたいな感じかな。
でも一番最初って自分の感覚なんてつかめないよなぁ…。
あ、最初っから完璧にしようとしてはいけないのか。
相対見積もりは１営業日ではない
ポイント。
- 1pt : 楽勝。 3pt : やれないことはない。 5pt : ちょっと大変
見積もりの技法
三角測量。基準になるストーリーとの相対サイズを見極める。
基準になるストーリーの選び方。
論理的なグループ分けができそうなものはなにか
エンドツーエンドになっているストーリーはあるか
プロジェクトを象徴するような代表的なストーリーはどれか。
見積もりの再定義は起こりえる。
プランニングポーカー
- 見積もりゲーム
ch8 アジャイルな計画づくり：現実と向き合う
慣れてもらうしかない。
計画の立て方の４つの基準
顧客にとって価値ある聖歌を届けられる計画
わかりやすくありのままを伝える、誠実な計画
約束したことを守り続けられる計画
必要に応じて変更できる計画
- 見た感じ、最後の２つとか両立するんだろうかと思う。
アジャイルな計画づくりとは
- チームの開発速度を計測して、その速度をもとにプロジェクトの完了時期を見通せるようにすること。
マスターストーリーリスト
- 顧客がソフトウェアで実現したいと思っているありとあらゆるフィーチャが並んでいるリスト
ベロシティ
- ユーザーストーリーを動くソフトウェアに変換する速度のこと。
-
- １~ 2 week
最初から厳格なコミットメントとして扱うと、プロジェクトは始まる前から死ぬ。
やるべきことが多すぎる場合はやることを減らす。
- 何を基準にやめていくかを考えるんだろう。
やってほしいストーリーを追加するときは、既存のストーリーを削ること。
マスターストーリーの長さを一定にする。
個人で言えば、ToDoリスト（ポモドーロでいうところの在庫アクティビティ）を一定にするってことか
僕自身、どうしてもやることを増やしてしまいがちになるからなぁ。もっと、やらないことに対して厳しくいくべきだと思うわ…。
初回の計画づくり
ステップ１：マスターストーリーリストを作る
ステップ２：プロジェクトの規模を見極める。
- 三角測量・プランニングポーカー
ステップ３：優先順位をつける
ステップ４：チームのベロシティを見積もる
チームのベロシティ = 完了させたストーリーポイントの合計 / イテレーション数
フィーチャを届ける ⇛ コーディング＋分析＋テスト＋設計
積極日間な見積りにしすぎないこと。
- うわーこれやってるわぁ…orz
ステップ５：期日を仮決めする。
期日の固定 = 「プロダクトはこの日が来たら何がなんでもリリースする」と宣言するのと同義。
フィーチャセット固定。中核をなすフィーチャのまとまりをすべて完成させるまでは作業を続ける。
バーンダウンチャート
- Pivotal Trackerでも表示されてたやつだ。
実践したくなってきた。Pivotal Trackerでやってみよ。この章を読んだ後に…。
プロジェクトを途中からアジャイルにしていく
イテレーションの運営
1 week ~ 2 week
ステップ１：分析と設計
1ページぐらいにまとめる。
説明
タスク
テスト条件
必要な分だけ、必要なときに掘り下げて分析する
フローチャートを書いてみる。
ペルソナ
ソフトウェアのユーザを役割ごとに簡単に説明したり、典型的な姿として書いたもの
どこまで掘り下げておくべきなんだろう。
例を見た感じだと
役割名
役割の説明
役割がどんな機能をもっているのかを作るソフトウェアの目線で書く。
ペーパープロトタイピング
受け入れテスト
このストーリーが完成したことを確認できそうなことを３つ書く。
好きなだけ詳細に踏み込んでもいい。
しっかりと把握できるまでどんどん質問していく。
ステップ２：開発：作業する。
ステップ３：テスト：作業の結果を確認する
受け入れテスト：”受け入れテストはシステムが正しく作られているかではなく、業務に使えるかの確認が中心" http://www.itmedia.co.jp/im/articles/1111/07/news124.html
カンバン
仕事の流れをスムーズにする。
ストーリーボードとの違い
WIP：チームが同時に着手する作業数はこの制限を超えてはいけない。
- どうやって決めるんかな？勝手に自分で？
運用とかだったらカンパンがいいかもねーだって。
実際のアジャイルの事例とかみておきたいなー。
アジャイルな意思疎通の作戦
イテレーションでやるべき４つのこと
ストーリー計画ミーティング
ストーリーの準備が整っているかを確認する。
受け入れ条件テストのレビュー
見積の数値を確認
調査に漏れがないか
ストーリーが大きい場合は１回のイテレーションに収まるように分割して計画を更新する。
ショーケース
- 成し遂げた成果を広めて、クライアントからフィードバックを得る
イテレーション計画ミーティング
プロジェクトの健康状態を確認するタイミング
バーンダウンチャートでプロジェクトの完了の見通しをする。
悪いニュースは早めに
「だけど」を避ける
ミニ振り返り
10分〜15分
うまくいったこと・もっとうまくやること
振り返りの方法教えて欲しいんだよなぁー。
デイリースタンドアップ
10分以内で自分のやることをまとめる。
これは個人だと、今日のTODOとしてreviewに書き出す感じにしてもいいかな。
やったこと・今日やること・開発を妨げそうなこと
毎日コミットメントをすること。
- ここなんか、週の最初は頑張るんだけど、後半から息切れしちゃうんだよなぁ…
大事なのは勝ちにつながる習慣かどうか。
イテレーションで成果がでなくても、その価値が出なかったことを伝えること
- ここは心が痛い…orz
プロジェクトの状況が芳しくないからといって、そこから目をそむけてはならない。その失敗を受け入れ、改善に取り組むこと。
ch11 現場の状況を見えるようにする。
インセプションデッキを見える位置にある。
リリースボード
チームがどこまで完了しているのかがひと目で分かる
イテレーションごとに分けられた完了したストーリー
残っているストーリー
ストーリーボード
- 現在のイテレーションで取り組んでいるフィーチャの状態
チームの約束
- 現在のチームメンバーにとってはどんなチームなのかを言葉で表す
チームが大事にすること。
- チームの約束よりももっと感覚的なもの。
DDD本は必読だって。
イテレーションの10％はバグを潰すことにあてて、技術負債を返済するのもいいだろう
ch12 ユニットテスト：動くことがわかる, ch13 リファクタリング, ch14 テスト駆動開発,
ユニットテスト：ビルドしたコードがちゃんと動くか
- メソッドレベルの粒度で書く。
リファクタリング：コードをシンプル＆クリーンで読みやすくする
TDD：複雑さに立ち向かうための設計手法
継続的インテグレーション：決まった感覚で統合し、プロダクトをリリース可能を保つ仕組み。
アジャイルの道
毎週、価値ある成果を提供しているか。
たゆまぬ改善の努力をしているか。
これから。
インセプションデッキの作成
ユーザーストーリーを作成。
