概要
アジャイルでの開発が多くなってきて、アジャイル開発であったりスクラムが組まれるということも多くなってきたこともあり、ちゃんと学んだ方がいいなと感じたところが始まり。
アジャイル開発の中でさまざまな用語が飛び交うのと、その用語の持つ役割を適切に運用に回せるようになることを目的として、勉強を始めた。
実際今の現場でもスクラムを採用しているが、やはりどうしてもスクラムに定義されているようには適切に回すことができていないように思える。
一部難しい部分もあるとは思うが、まずは下地をということで、人気の高い当書を選んでみた。
スクラムはアジャイルの一つの具体的なフレームワーク
- 計画の立て方
- うまくいっている度合いを測る方法
- 3つの真実を受け入れることの効果
3つの真実
- プロジェクトの開始時点に全ての要求を集めることはできない
- 情報が出揃っていなくても進める必要がある
- 集めたところで、要求はどれも必ずといっていいほど変わる
- 起きた変化を受け入れ、変化に応じて計画を変える
- やるべきことはいつだって、与えられた時間と資金より多い
- やれることをやるだけ。与えられた時間とリソースを超えたToDoリストを前にしてもプレッシャーを感じなくなくなる。
やること
- 大きな問題は小さくする
- 大事なことに集中して、それ以外を忘れる
- ちゃんと動くソフトウェアを届ける
- フィードバックを求める
- 進路を変える
- 成果責任を果たす
アジャイルでは、開発工程が他の工程から独立して行われることはない
アジャイルでは、役割は分担されていない。プロジェクトの成功に寄与することはなんだって協力する。
人は自分の得意分野にこだわりすぎる傾向がある。そのため、細かい定義は容易しない。
そして、品質に責任を持つのはチーム。 not 品質保証部門。
そのため、メンバーは開発工程のそれぞれを密接に連携しながら、日々の作業を進めていく。
やるべきこと
- 同じ場所で働く
プロジェクトを始める段階でメンバー全員が集まれるだけの旅費と予算を確保し、たった数日でもその期間を用意すること。
最初が肝心。
これさえできれば、あとはオンラインでもなんでもなんとでもなる。
- 顧客の存在
積極的に関わってくれる顧客の存在が大事。
顧客が積極的に関わらないプロダクトは犯罪的と思って良い。
プロダクトにふさわしい人材が関わらないで、どうやってそのプロダクトを魅力的にしていけるのか。
積極的に関わってくれる顧客がいない場合
2週間で何かしらのお客様の課題を解決しますと宣言するところから始める。
あとは、どうやってその問題を解決したかを報告するかを考える。
これを繰り返すことで、3回、4回目くらいには自分の姿がお客様から見て変わっているものになっているだろう。
そうすると、頼り甲斐に感じてもらい、積極的に関わってもらいやすくなる。
いろんな理由で関わりたくないお客様は存在する。
しかし、お客様との信頼関係を築くことが大事になり、頼りにしてもらうことが近道なのだとしたら、信頼貯金を増やすところから始めるというのが一番良い方法になる。
自己組織化
アジャイルチームは、目標を与えられると、それをどうやって達成するかを一歩下がった視点からみんなで客観的に考える。
そのためには、自己組織化されていることが条件となる。
自己組織化とは、自らのエゴを押し出し過ぎないように気をつけながら、チームで力を合わせるということ。
そのとき、それぞれのチームの一員として(各人のスキルと情熱と資質を発揮しながら)、どう振る舞えば最善の成果をお客さんに届けられるかを考え抜く必要がある。
人に合わせて役割分担を決めていくことが重要で
テスターにプロジェクトマネジメントを期待するとか、開発者にデザイナーになれという話ではない。
自己組織化するには
- 自分達で計画を立てる。見積もりも自分達で作る。自分達のプロジェクトだという意識を持つ。
- テスト済みのちゃんと動くソフトウェアを提供し続けることにこそ心を砕く。
- 自分から動ける人を探す。自分の運命は自らの手で切り開こうとする人が良い。
成果主義と権限委譲
しかし、全員が全員自己組織に合わせた人間という訳ではない。
言われた事を淡々とこなしていくことの方が楽なのに、どうしてそんな自分から権限を委譲されにいくかと疑問に抱く人もいる。
それはそれで終わりかと言われれば、そうではなく
お客さんの前でデモをしてみせることで、自分たちのソフトウェアに期待している人が実在することに気づくことになる。
この実感による効果は非常に大きいものになる。
一度でもデモに失敗すると、ちゃんと次からは動くものを用意し、フィードバックを得る準備を整えられているかに気を配れるようになる。
職能横断型チーム(Cross-Functional Team)
顧客の要望に最初から最後まで応えられる開発チームのこと。
そのためには、開発チームに適切なスキルと専門知識が備わっていて、顧客が必要とするあらゆるフィーチャをきちんと届けられる必要がある。
一般的にはゼネラリストが望ましい。
役割分担
アジャイルチームにおける、メンバーに対して役割のようなものは存在しない。
その役割によって果たされる仕事が、チームの誰かによってちゃんとこなされるようになっているかどうかだけに気をかける必要がある。
アジャイルなアナリストは、フィーチャー実装にあたって、どうやって実現するかを誰かがしっかりと詳細まで調べ上げねばならない。
顧客の必要とするものを徹底的に洗い出し、実装に向けてプロトタイプやデモ、技術調査など、なんでもするような立ち位置。
アジャイルなプログラマは、質の高いソフトウェアを生み出すことに心血を注ぐプロフェッショナル。
テストやリファクタリング、CIなどを通して実現を行う。
何を作るかをはっきりさせ、できるだけシンプルに実現する。
アジャイルなプロジェクトマネージャは、プロジェクトを成功させる唯一の方法は、開発チームを成功させることだと心得ている。
断続的に計画を立てていくこと、立てた計画を見直す、必要ならプロジェクトの方向性を調整することも含む。
アジャイルな○○
アジャイルなプロジェクトマネージャ (p35)
開発チームの障害を取り除くためなら地の果てまでも行きかねない。
上位のプロジェクト関係者に、開発チームに期待できることをマネジメントするのもアジャイルマネージャの仕事。
ステークホルダーへ状況を報告し、社内の人間関係を円滑にする。
チームを外圧から守る盾となる。
アジャイルなUXデザイナー
UXはプロダクトの価値を顧客に届けることにおいて、分析やUXデザインの分野で腕を振るってくれる。
イテレーションを通じて少しずつ積み重ねていくことにためらいがない。
全てを作るのではなく、フィーチャを実装するタイミングに合わせて少しずつデザインしてくれる。
インセプションデッキ
プロジェクトがダメになる
スタート時点で、話し合うことすらやっていないため。
まずやるべきこと
- ゴールやビジョン、プロジェクトの状況や背景についてチームでよく話あっておくこと。そうすことで、チームは状況に応じて適切な判断を下せる。
- ステークホルダーに情報を提供すること。彼らにはプロジェクトを続けるかどうかを決断するための材料が必要。
手強い質問をする
初期であれば、間違っていろんな質問をする余地がある。
あけすけな質問をすることもできる。
例えば - どれくらい経験を積んでいるチームですか？ - では、あなた自身はこの手の仕事の経験はありますか？ - ご予算はどれくらいですか？ - このプロジェクトを統括するのはどなたですか？ などなど
この質問に答えるために、インセプションデッキがある。
インセプションデッキとは
プロジェクトを革新まで煮詰めて抽出した共通理解を、開発チームだけじゃなく、より広範囲なプロジェクト関係者全員（いわゆるプロジェクトコミュニティ）へ手軽に伝えるためのツールだ。
プロジェクトに関わる人は全員参加する資格がある。
インセプションデッキの課題の成果をパワポとかで出すと、このプロジェクトは何であって、何でないのか、価値を届けるためにどこに力を注ぐべきか。などなどがわかってくる。
そして、ステークホルダーを巻き込むことが重要になる。
インセプションデッキの課題一覧 - 我々はなぜここにいるのか？ - エレベーターピッチを作る - パッケージデザインを作る - やらないことリストを作る - ご近所さんを探せ - 解決案を描く - 夜も眠れなくなるような問題はなんだろう？ - 期間を見極める - 何を諦めるのかをはっきりさせる - 何がどれだけ必要なのか
エレベーターピッチ
エレベーターピッチの由来は
今まさに乗ろうとしているエレベータに一緒に乗ろうとしているのが、3ヶ月前からどうにかして会いたいと思っていたベンチャーキャピタルの関係者であったら、まさにその間の30秒の間に、新規事業について説明ができるかどうかで資金援助が決まってしまうという状態で、エレベーターに飛び乗るようなところから来ている。
つまり、短い時間でアイディアを伝えることが重要になってくるのだ。
そして、これは実際のエレベーターピッチのテンプレートにするとわずか2行になる。
主に以下の様な形で作られる。
・[潜在的なニーズを満たしたり、抱えている課題を解決したり]したい ・[対象顧客]向けの、 ・[プロダクト名]というプロダクトは、 ・[プロダクトのカテゴリー]である。 ・これは[重要な利点、対価に見合う説得力のある理由]ができ、 ・[代替手段の最右翼]とは違って、 ・[差別化の決定的な特徴]が備わっている。
というような形式で作られる。
この時の注意点が、基本的にこれは外部の人間、つまりプロダクトに詳しくない人間に向けて作られる言葉になる。
なので、フィーチャを想像して書くのではない。
効能を伝える必要がある。
つまり、エンジンのフィーチャを「245馬力エンジン」と伝えても響かない。
高速道路でも楽々追い越し などの言葉に言い換えることで相手は理解することができ、どこでそのプロダクトを使うことができるかイメージすることができるのだ。
建設現場のエレベーターピッチを作るとしたら以下のようになる。
・[建設現場の作業を把握]したい ・[現場責任者]向けの、 ・[CSWP]というプロダクトは、 ・[危険作業許可証発行システム]である。 ・これは[作業許可証を申請・追跡・監査する]ことができ、 ・[現行の紙ベースのシステム]とは違って、 ・[ウェブ経由で、いつでもどこからでも利用できる機能]が備わっている。
チームを選ぶことはアーキテクチャを選ぶこと
大きな金槌を持っていると、何もかもが釘に見える。
データベースに強いチームは重い処理をとにかくSQLに任せようとするもの。
オブジェクト指向に強いチームは、複雑だと感じた処理ならなんでもオブジェクト指向で解決したがる。
このように、チームの強みによって戦略が決まってきてしまう。
技術的な得意分野を早めに表明しておくのは大事なことである。
リスク
ブルームバーグによると、全てが順調にいくことなどありえない。完璧な計画などないというものである。
しかし、それにも慣れなければならない。
何が起きるかわかっているものもあれば、わからないものもある。
分からないものに対しては、起こってから対応するしかない。
そのため、リスクについて話す必要がある。
これは、人によっては臆病者に思われるので、飛ばして進めたくなる人も多い。
しかし、プロジェクトを成功させるために何が必要かをみんなが納得していくにあたって、とても大切なプロセスになる。
プロジェクトの重要要素
- 品質
- 時間
- スコープ
- 予算
対応策 - スコープを削る - もっと人を増やす - リリース日を延期する - 品質を犠牲にする
アジャイルサムライは
時間と予算を固定する。
時間は有限で、お客さんに届けられる価値が遅れれば遅れるほど、何も提供できなくなるという最悪の事態に陥る。
予算も有限であり、利用可能な資源が潤沢ということはないので、スポンサーから集めるしかない。しかし、気の進まぬ仕事ゆえ、この予算を固定に決めることで避けるようにする。
品質は、時間と引き換えに犠牲にしがちだが、それはお門違いになる。品質なくして成立するものはないからだ。
故に、アジャイルサムライは品質も固定として扱い、常に高い水準を保ち続けようとする。
スコープのみ、唯一動かすことができるものとして残る。
やることが多すぎる時、それを減らすということを行う。
アジャイルサムライは、計画を変え、現実を変えない。
ユーザーストーリー
ユーザーストーリーは、顧客がソフトウェアで実現したいと思っているフィーチャを完結に記述したもの。
インデックスカードと呼ばれる小さめのカードに書く。(何でもかんでも書き出そうとするのを抑制するため)
完結にしかインデックスカードにしか書かない。
これはチームへの戒めのために使う。
フィーチャーの本質を捉えるキーワードを書き留めておく。
書いた段階ではそれが本当に必要なものかまだ分からないためである。何ヶ月も先になったころにはソフトウェアも見間違えるほど変わってるかもしれない。
本当に必要になった時に、思い出せるほどのキーワードを書いておくだけで良い。
よく書けているユーザーストーリー
顧客にとって何かしらの価値が書かれていること。
どういうことか
ユーザーストーリーはビジネスの観点から評価できないといけない。
お客さんに理解できるシンプルな言葉づかいでユーザーストーリーを書くことを心がけるのもそのため。
例えば
データベースにコネクションプールを導入する
ではなく、
現状の10秒かかるページの読み込み速度を、2秒まで縮める
などなど。
end to endで書かれている事が必要とされる。
ユーザーストーリーを作るために
顧客へのインタビューで得られた情報を基に、必要なユーザーストーリーを作ってみる。
例えば次のようなものが期待される。
- 次回のセール品の一覧
- 地元のサーフィン大会の結果の掲載
- 今後のイベントやサーフィン大会の一覧
- ウェブカメラでビーチの様子を配信する
- サーフィンレッスンとその料金を表示する
- 中古のボードや装備の販売コーナー
- ウェブサイトはサクサク表示する
- デザインはかっこよく
この時、下２番のストーリについてはテストがしにくいものになる。
ではどうするか
- サイトのページはどれも2秒以内に読み込めること
などと置き換えてみる。
ユーザーストーリーを作るためのテンプレートは以下のようになる。
誰の ためのストーリーで
何を したいのか
なぜ そうしたいのか
アジャイルの進め方
- インセプションデッキを作る
- プロジェクトの最初の手強い質問をする
- プロジェクトの方向性をプロジェクトみんなで考える
- インセプションデッキによってスコープ設定やプロジェクトの期待マネジメントができる
- プロジェクトの基本的な考え方やスコープ、存在意義が変化したら、再びインセプションデッキを更新する。全員でチームの向いてる先と、プロジェクトの理解が揃っているかを確認する
見積もり
アジャイルにおける初期の見積もりは、ひどい当てずっぽうのようなもの
結論から言うと、前もって正確な見積もりなどは無理に等しい。
では、何を前もって得られるか
- 今後の計画を立てられる
- 見積もりは当てずっぽうだという前提を踏まえている
- ソフトウェア開発の複雑さを認めている
しかし、プロジェクト初期段階で予算を決めたりしなきゃいけない状況で、あまりにも当てずっぽうでは不都合が生じる。
そのため、
- ストーリーそれぞれを互いに相対的なサイズで見積もる
- ポイントをもとにして進捗を追跡する
を行う。
相対的にタスクの大きさを見て、ストーリーを見積もる。
クッキー1枚を食べるのに10分かかるというのを1というポイントとしたら、その2倍は20分かかりポイントは2になる。
と言ったふうに。
ここで重要なのは、1ポイントは1営業日と考えないということだ。
あくまで、目安の基準という考えで
あるタスクを3日と見積もっていたが、実際は4日かかったとなれば、全てのタスクを1.3倍しないといけないかというとそうではなく
あくまで基準なので、ポイントとして定義し絶対的なものではないという認識を持つ。
日数
ここで問題になるのは、ストーリーは日数ではないか？
「クッキーを1枚食べるのに10分かかる」 の10分は時間だから、どう扱えばいいの？という疑問が出る。
しかし、ここに関しては、人によって日数で見積もりをする人もいて、それが分かりやすいという人もいるが
実際には、例えば1日と見積もったが、それは8時間フルで集中できた時の見積もりだろうか？
実際にはミーティングが入ったり、集中できない日もある。
そう言った場合結局曖昧なものになってしまう。
それならポイントで見積もる方が、あなたの理想の100%集中できる日と隣の人の理想の100%集中できる日などで考える必要がないからだ。
見積もり技法
三角測量
代表的なストーリーをいくつか基準として選出して、残りのストーリーを、基準になるストーリーとの相対サイズで見積もるやり方。
そのためには、
- 論理的にまとめられるタスクがあるか
- エンドツーエンドになっているストーリーがあるか(アーキテクチャ検証に最適)
- プロジェクトを象徴するような代表的なストーリーがあるか
を確認する。
そうして、タスクに対してストーリーポイントをつけていく。
同じストーリーポイントだとしても、実際に実装してみると難易度が異なっていたということもありうる。
そうしたら再設定を行うのが良い。
しかし、相対的なサイズの定め型がそれなりに適切な場合だとすると、そのままにする方が良い。
毎回再見積もりをしていては、チームのベロシティを図ることが難しくなり、計画づくりがややこしくなるからだ。
そのため、未知なタスクが生まれてきた場合は、「スパイク」を用意すると良い
スパイク
未知のタスクに対して、調査などを行うためのタスク。
より見積もりを精密にすることを目的とするタスクになる。
プランニングポーカー
見積もりゲームと考えるとわかりやすい。
開発メンバーが、それぞれひとつひとつのストーリーをまず自分自身で見積もる。
そうしたら、メンバー同士で見せ合って、チームとして統一した見積もりを出す。
そこで一致すれば終わりだが、食い違いがあればその違いについて話し合ってメンバーそれぞれが再び見積もる。
合致するまでそれを繰り返す。
注意点として、投票システムではないということ。
3人の新米経験者の見積もりが、1人の熟練経験者の見積もりに「勝つ」仕組みではない。
ベロシティの測定
期日固定
リリース日を固定にして決定する。
チームにある程度の緊張感が生まれる。
リリースに間に合わせるためのスコープの調整を行う必要が出てくる可能性がある。
フィーチャーセット固定
フィーチャーを固定し、リリース日を調整するようにするやり方。
しかし、スコープを柔軟にしておくという考え方は依然として有効。
プロジェクトが進むことで新たにわかることがあるフィーチャーはあるからだ。
ただ、こうしておくとチームが届けなくてはいけないフィーチャーセットを意識することがしやすくなる。
そのため、可能な限り期日を調整することを行う。
バーンダウンチャート
チームがどれくらいの速度でストーリーを実装しているかをひと目でわかるようにした図のこと。
以下4つの視点からバーンダウンチャートは有効
- どれだけ仕事を完了させたのか
- どれだけ仕事が残っているのか
- チームのベロシティ
- いつ頃すべてを完了させられそうか
バーンダウンチャートの縦軸は残っている作業の総量になる。
横軸は時間を表す。
この時の線の傾き（イテレーションでチームが完了させた作業量）がチームのベロシティになる。
バーンアップチャート
基本はバーンダウンチャートと同じだが、上に向かって積み上がっていくところが異なる。
途中でスコープが広がってしまった場合には、それがすぐに分かるのが特徴。
バーンアップチャートの方がプロジェクト期間を通じたスコープの変動を追跡しやすい。
アジャイルを支える技術
それぞれ、細かく設計されていて、一つ一つが本になるボリュームなので、ここではサラッとだけ記載。
ユニットテスト
ビルドしたコードがちゃんと動くことを示す方法
リファクタリング
コードをシンプルでクリーンな状態に保ち、読みやすくするための技術
テスト駆動開発(TDD)
複雑さに立ちむあかうための設計技法
断続的インテグレーション
決まった間隔ですべてを統合し、プロダクトをリリース可能な状態を保ち続ける取り組み
