Agile2013の歩き方

第4回Agile2013 2日目レポート「Agile Requirements & Product Management」

自分の発表が終わったので、今日は7時半に起きて朝風呂入ってから朝食に向かいました。そこで知ったのは、米Manning社の電子書籍が44%値引きで購入できることです。

画像

ATDD、BDD、そしてHDD

今日、朝一番に参加したセッションは、David Bulkin氏による「Beyond Stories, an Intro to ATDD, BDD & HDD」です。部屋は丸テーブルがある狭い部屋でしたが、ほぼ満員でした。

David Bulkin氏は専門コンサルタントなので話はとても上手です。まず簡単な紹介から。ATDD(Acceptance Test Driven Development:受け入れテスト駆動開発)とは、プログラマがビジネスニーズを想定して開発を進めるもので、BDD(Behavior Driven Development:振る舞い駆動開発)は、開発者がビジネスに要求を聞いてから開発を進める方法です。

またHDD(Hypothesis Driven Development:仮説駆動開発)とは、ビジネスでも完全に要求を理解を理解していないことを前提にしています。ビジネスを成功させることができるソフトウェアを開発することが目的であって、仕様通りに正しく動作するプログラムを作成することではないということです。

次に、ワークショップスタイルでTDD、BDD、HDDを体験しました。TDDの例では、簡単な電卓のテストケースを作成しました。BDDではDan Northのブログで紹介されたATMからお金を引き出す例を利用しました。HDDでは入場券販売を例にして、売り上げをどのようにしたら上げることができるか皆で議論しました。予定していた人数が来なかった場合や、思ったよりも原価が高かった場合などにどのように対応するかの話で盛り上がりました。

良い成果物より良い結果を ─アジャイルの使い方

10:45~12:00は、Jeff Patton氏の「Agile Requirements & Product Management」を聞きに行きました。講演用の大部屋でしたが、ほぼ満員でした。やはり有名人だけあって集客力がすごいです。

画像

セッションは、まず自己紹介から始まりました。芸術学校を中退してソフトウェア会社に就職したPatton氏はプログラマになりたかったのですが、技術力が足りないのと、ドメイン知識を活かせると言われてプロダクトマネージャにされたそうです。

そして前日のマイク・コーン氏の講演で間違っていた点を訂正しました。ソフトウェアは世の中を変えるために作成するものです。またソフトウェアは人を幸せにするために作成します。やりたいことができなかったり、混乱している人たちの考えをまとめて、ソフトウェアを開発してその人たちに提供することによって幸せにするものです。

画像

ソフトウェア開発者の役目は、できる限りソフトウェア開発の労力を最小にし、ユーザへ提供するメリットを最大にすることです。

製品とプロジェクトとは異なります。プロジェクトは成果物を出荷したら成功となりますが、製品は出荷した後から価値が出ます。スケジュール通りかつ予算内にプロジェクトを完了させても、できた製品のメリットがユーザにとって低い場合もあります。それを避けるために、ユーザと開発者が共通した認識を持つ必要があります。

ドキュメントを共有しても共通認識をもつとは限りません。そのため、ドキュメントではなくストーリーを共有します。ストーリーとは書かれた文章というよりも、利用者と開発者が共通認識をもつためのツールです。そのために文字に限らずお互いの理解が共通に得られるような道具を使います。また、よく会話をしてすれ違いが無いように確認をします。重要なのは書かれた仕様書ではなく、共通した認識です。

成果物(output)と結果(outcome)も異なります。たとえば、スキーを習い始めた人にはパワープラウ(いわゆる⁠ボーゲン⁠⁠)の仕方を教えます。しかしパワープラウが上手になることが目的ではありません。どれだけパワープラウが上手になったしてもスキーが上手になったとは言えません。オリンピックにパワープラウと言う種目はありません。

アジャイル開発は、良い成果物よりも良い結果を出すために使います。その時のユーザの考えていることを完璧に把握するよりも、実際に動くソフトウェアを提供して使ってもらえるようにすることを優先します。使っていただくことにより、ビジネスでどのように使えるかを確認して、全員で学びながらよいビジネス結果へ向かいます。

ストーリーとは岩のようです。以前「アステロイド」というゲームがありましたが、このゲームのコツは、大きい岩を1つずつ砕くことです。砕いて小さくなった岩はばら撒かれるだけではなく、スピードも速くなります。ストーリーも同じように1つずつ細かく砕いていった方が良いと言います。また、ストーリーの「正しい粒度」というものはありません。会話をしながら、お互い共通した認識が持てる粒度が最適です。その人とのその時の関係で粒度が変わります。また、ソフトウェアの要求は供給より多いので、要求は絞る必要があります。

画像

反復型開発にはインクリメンタル型開発とイテレーティブ型開発法があります。インクリメンタル型開発とは、機能を分けてその機能ごとに完成させていくことです。イテレーティブ型開発法とは、すべての機能を同時に開発しますが、最初からは完成させないことです。芸術家が絵の下書きをして、それを徐々に完成させていくのと似ています。

話の最後に次のようなスライドを見せて、話の内容をまとめました。

画像

午後のセッション ─アジャイルのスケールアップ、マインドセット、世界的なアジャイルの普及度

昼を挟んで、14:00~15:15の間はDean Leffingwell氏の「Be Agile. Scale Up. Stay Lean.」を聞きに行きました。この講演も人気度が高く、大部屋なのにほぼ満席でした。

画像

エンタープライズアジャイルを行う場合、Scrum、XP、Kanbanなどでは道具が足りないのでSAFeを作成しました。さらに必要に応じて随時に機能を追加しているとのことです。

ニュージーランド・ラブビーチーム・オールブラックスがハカを踊っているビデオを見せられました。このようにチームスピリットと闘志感を高めるのが良いという意味のようです。

15:45~17:00はLinda Rising氏の「The Agile Mindset - Your Questions, Comments, Thoughts?」に参加しました。大部屋でしたが、参加者が少なかったです。昨日、同じテーマで講演されたからかも知れません。このセッションは参加者がLinda氏と並んでソファーに座って質問する形式です。

画像

質問を受ける前に簡単にマインドセットの考え方について説明されました。人間関係は完全ではありません。完全だと勘違いすると、少しでも不完全だとわかると諦めてしまいます。たとえば、男女がお互いに好き合って、自分たちの愛は完全だと信じてしまう場合があります。そうすると、少しでも問題が発生すると相手を嫌になってしまう傾向があるそうです。

報酬がどのようにマインドセットに影響するか、どのように優先順位を付けるか、⁠正しい」アジャイルのやり方を主張して他人の意見を聞かない人、情報を共有しない組織でアジャイルは可能か、組織にアジャイルマインドセットの導入するいろいろなやり方などに付いての質問がされました。

17:30~18:30はパネルディスカッションがありました。Chris Rommel(VDC社⁠⁠、Melinda Ballou(IDC社⁠⁠、Thomas Murphy(Gartner社⁠⁠、Tom Grant(Forrester社)がパネラーとして並びました。

多くの質問がありましたが、印象的だったのは、日本だけではなく、アジア全体がアジャイルに関して遅れていると言われたことです。まずThomas Murphy氏がアジアは欧米に比べて5年ぐらい遅れていると言ったのに対して、Melinda Ballou氏はシンガポールに行ってみた経験から、5年よりはもう少し短いと言いました。また遅れている理由は、コマンドを無くしたくない傾向が強いからでは、とのことでした。

では米国ではいずれの形でもアジャイルを使っていない会社はあるのか、という問いには、どのパネラーもすぐに回答できませんでしたが、やや間を置いてから、ウォーターフォールで満足している会社もまだあるとの回答がありました。

ナイトセッション ─コーディングDojo

夜になって「コーディングDojo」が開かれました。1台のコンピュータを使い、数人で1つのプログラムを開発していきます。1人がコンピュータの前に座って入力担当になります。もう一人が何を入力するかの指示を与えます。時間を設定して、数人で役目を順番に交換して開発を進めます。

画像

初心者に一歩的に教えるだけではなく、指示を出させる役に立たせるのがポイントのように思えました。また入力担当は入力に専念して、指示者からの指示に反対しないこともポイントです。ただし、見ている周りの人たちは指示者に意見や支援を行うことが推奨されています。また、一度入力されたコードを削除して書き直すことは禁じられています。

このやり方では時間が無駄になるように見えますが、お互いに会話をすることで、全員の技術力が上がるのと、全員がコードを理解できるので、1ヵ月後にはチーム全体の生産性が上がるそうです。参加されていた方の会社では、3人でこの方法を使って実際のプログラムを開発されているそうです。

画像

見ていて、本当にどの程度の効果があるのか自分でも試してみたくなりました。

なお、運営員会からAgile2013のハッシュタグを使ってのスパムが多くなったので、利用を中止したというメッセージが届きました。利用者が多くなるとこのように悪用する人が現れてくるのは残念なことです。

おすすめ記事

記事・ニュース一覧