酒と泪とRubyとRailsと

Ruby on Rails と Objective-C は酒の肴です!

アジャイルサムライ-達人開発者への道- 書籍レビュー 初心者にも優しく実践的な内容

アジャイルサムライ-達人開発者への道-』を読んだので、この記事でまとめ兼レビューを書きます。この本を読んだ動機は、再来週くらいからアジャイル開発に初めて挑戦することになったので、その前に予備知識を少しでも得たいというのが理由です。

読んだ感想としては、「初心者に優しい、実践的な内容!」の一言につきます。アジャイルにこれから挑戦する人や、単純に興味がある人に特にオススメな一品です!

Included file ‘custom/google_ads_yoko_naga.html’ not found in _includes directory

原則:動くプロダクトを顧客に見せてフィードバックを受ける

アジャイルの原則は『顧客に動くプロダクトをできるだけ早く見せて、フィードバックを貰うこと』です。そうすることで、顧客側はプロダクトが狙い通りか否かを早い段階で確認することができます。また、開発側も開発コストの低い状態で顧客のプロダクトへの反応を確認できます。

この考え方の前提条件は次の2つです。

(1) プロジェクト開始時に全ての要求を集めることはできない。集めても変わる
(2) やるべきことはいつでも与えられた時間と資金よりも多い

この内容はウォーターフォール型でいつも感じていた問題なので、すごく納得できる内容です。

チームメンバーがアジャイル・プロジェクトに合わせる

アジャイル・プロジェクトにおいて、次の2点が関係者全員に求められるマインドだと思います。

(1) 小さなベンチャー企業に入ったように、肩書も役割に関係なく、プロジェクトの成功に貢献できることなら何でも協力するというマインドを持つ。

(2) 『アジャイル・プロジェクト特有の性質である曖昧さ』を理解して、『個人が得意な領域に固執しないこと』に務める。そして、アジャイルが『役割ごとに求める行動』を各人が自分で考えて実践する。

上の2つのマインドは一見すると矛盾しているようにみえます。ですが、この矛盾したかのようなマインドこそが、メンバー1人ひとりがアジャイルに適合するために必要なことと考えます。

プロジェクトのゴール、ビジョン、状況や背景をチームで共有

プロジェクトのゴール、ビジョン、状況や背景をチームで完全に共有することで、メンバー各人の状況に応じた判断の妥当性を高めることができます。そのためのフレームワークの一つ『インセプションデッキ』を紹介します。このフレームワークでは次のような内容を実施します。

(1)  「なぜ」プロジェクトが始まったのか?顧客はだれか?を共有する
(2)  短い言葉でプロジェクトをアピールするための言葉を決める
(3)  顧客の視点で、プロダクトが欲しいと思うような広告を作る
(4)  プロジェクトのスコープを狭めるために、やらないことをリストにする
(5)  プロジェクトの関係者を幅広く集めて、信頼関係の第一歩を築く
(6)  概念的なプロダクトの設計図を作り、チーム内での解決策を一致させる
(7)  プロジェクトに対するリスクを洗い出し、チームで取り組むべきリスクを決める
(8)  最も重要なリソースの一つである時間を管理するために、期間を見積もる
(9)  『期間・スコープ・予算・品質』についてのトレードオフを考える
(10) プロジェクトを実現するための『期間・コスト・人員』を見積もる 

アジャイル開発では『ソフトウエア開発の曖昧さ』を認めながら、ソフトウェア開発を成功させるための『リソースの見積もり』を徹底し、プロジェクトの成功確率を高めようとしていると感じました。

プロダクトのスコープ・リソースは異なりますが、ゆーすけべーさん著『Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ(自作のまとめ記事)』にもコレに通じるポリシーがあり、改めて納得出来ました。

ユーザーの要求をユーザーと意思疎通しやすい形式にまとめる

ユーザーストーリーでは、顧客の要求を『誰のために・何のために・それを実現するのか』を関係者がいつでも思い出せるように複数の小さなカードに書いて表現します。

このカードを書く上で、顧客側・開発者側の双方が意識すべき点は次の通りです。

顧客側 :ビジネスの観点から評価できるように書き、状況に応じた取捨選択できるようにする
開発者側:テストができるように書き、作業範囲と仕事の完了基準を明確にする

ユーザーストーリーを書くためのプロセスは次の通り。

(1) 顔を突き合わせてワークショップ形式で話せる場所に集まる
(2) フローチャート・ペーパープロトタイプなどの図を沢山書く
(3) ユーザーストーリーを沢山書く
(4) 図で表せない要素をブレーンストーミングしてカードに書き出す
(5) ユーザーストーリーの重複を省き、全員にわかりやすく、テストできるように書く

アジャイルにおける計画作り方

アジャイル開発では『ソフトウエア開発の曖昧さや、開発者の見積もりの精度は低いこと』の前提の中で、計画の作成に最善を尽くします。計画において大切なことは次の点だと考えます。

* 限られたリソースの中で、ビジネスの価値を高めるために最善を尽くす
* プロジェクトの状況に応じて、柔軟に対応する
* 顧客にとってわかりやすく、状況に応じた選択肢を示せること

短い期間ごとに反復して顧客に動くソフトウェアを提供する

アジャイル開発では短い期間ごとに反復して、顧客に動くソフトウェアを提供します。この開発サイクルのことを「イーテレーション」と呼びます。このイーテレーションは次の3つのステップによって構成されます。

* ユーザーストーリーを分解して画面の設計やタスクの詳細化、テスト項目を洗い出す
* リリース可能な、動くソフトウエアを実装する。顧客が語る言葉に合わせたコードにする
* 自動化したテストを実施すると共に、顧客にデモ操作をやってもらう(受け入れテスト)

このイーテレーション内でのグッド・プラクティスは次の通りです。

* デイリースタンドアップ:毎日チーム内で『自分のやること、チームで調整すること、課題』を共有
* ストーリーボード:開発の進捗状況がチーム全員にわかるような形式で、ユーザーストーリーをまとめる
* バグ管理:プロジェクトの初日からバグを監視・追跡する。一定の割合で技術的負債する時間をとる
* プロジェクト全体:プロジェクトの性質に合わせて仕事の進め方や成果物の残し方を変えていく

アジャイルなプログラミング

アジャイル開発において重要なエンジニア・プラクティスは次の4点。

ユニットテスト

ユニットテストとは個々のモジュールを対象とする小さな粒度のテスト。ユニットテストの利点は、コード変更に対して素早いフィードバックを繰り返し貰うことができたり、ヒューマンエラーの一定の防止ができることなどです。

リファクタリング

リファクタリングとはコードをわかりやすくして、変更しやすくなるように設計を改善することです。リファクタリングの利点は、コードの分かりやすさと変更のしやすさを保つことで『ソフトウェアの規模』が大きくなっても開発速度の低下を防ぐことができる点です。小さなリファクタリングはコードの変更を加える度に継続的に行い、大きなリファクタリングは規模に応じたリソースをきちんと当てることが重要です。

テスト駆動開発

テスト駆動開発(TDD)はソフトウェア開発の手法の一つです。ごく短いサイクルを繰り返しながら、ソフトウェアを設計していきます。テスト駆動開発の利点は、複雑な問題を小さく分解することで難易度を下げ、最善の解決策へ至る道を着実に進めることです。

継続的インテグレーション・継続的デリバリー

継続的インテグレーションとはビルドやテスト、インスペクションなどをJenkinsなどを使って継続的に実行していくことです。継続的インテグレーションの利点は本番にリリースできるプロダクトに対しての変更をより実践しやすくなる点です。

また、継続的インテグレーションでテストしたコードの中から、望むバージョンを選んでテスト・本番環境へのデプロイするプロセスを自動化することを『継続的デリバリー』といいます。これもグッド・プラクティスの一つです。

参考サイト

jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー

Included file ‘custom/google_ads_yoko_naga.html’ not found in _includes directory

アジャイル特有の用語集

エクストリーム・プログラミング(XP)

アジャイルに欠かせないベスト・プラクティスをまとめたもの。重視する要素は、『コミュニケーション・シンプル・フィードバック・勇気・尊重』。まとめられているプラクティスは次の項目。

# 開発の技術的なプラクティス
* テスト駆動開発
* ペアプログラミング
* リファクタリング
* 継続的インテグレーション

# プロジェクト全体に対するプラクティス
* 短期的に動くソフトウェアをリリースすること
* 開発チームはだれでもソースコードを修正できるようにすること
* 顧客の分かる言葉で『求める機能』を決めて、顧客・開発チーム側で合意すること
* 開発チーム全体でリリースの計画を立てること

スクラム

アジャイルにおけるプロジェクト・マネージメント手法の一つ。要求仕様を簡単に動くコードに変換することを目的としています。中身は、チーム論や顧客の要求管理、開発工程管理、テクニック(テスト駆動開発、受け入れテスト、リファクタリング、継続的インテグレーションなど)等々。

プロダクト・バックログ

機能や技術的改善要素を優先順位をつけて記述したもの。顧客・開発チームなど関係者全員がプロダクトの状況を把握できるようにする必要があります。

参考サイト

5分で分かる、「スクラム」の基本まとめ

リーン開発

能率を上げることをとことん追い求めるための手法。リーンの原則は『無駄をなくす、品質を作りこむ、早く提供する、人のモチベーションを重視する、全体を最適化する、ビジネスとしての視点で考える』など。

参考サイト

『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。:An Agile Way:ITmedia オルタナティブ・ブログ

「アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から - Publickey

変更来歴

(08/26 10:50) 継続的デリバリーの説明を追加

おすすめの書籍