今日は朝から雷が鳴っていて大雨です。朝食をしていると今日のセッション表が掲示されました。
シナリオベースで開発するポイント
9:00～10:15はRichard Yu氏の「Fifty Shades of Behavior Driven Development」に参加しました。理由は、BDDについてもっと知りたかったです。Yu氏は最初の日に会って話した人です。私は自分の発表のことで頭が一杯だったので忘れていましたが、Yu氏の方で覚えていてくれて、少し早く行ったら話しかけて来ました。
講演の演習は十分に行っていると自信を持って言っていた通り、参加者を楽しませてくれるセッションでした。音楽に合わせて踊ったり、ビデオも数本流れました。
「Fifty Shades」というのは英国のポルノ本「Fifty Shades of Grey」から取ったものです。米国と英国ではベストセラーで知名度が高いようなのですが、残念ながら和訳されていないので日本で知っている人は少ないと思います。夜のパーティでこの題名の内容の関係を聞いたら、特に関係はないと言われました。このような題名の方が目立つので決めたとのことです。
発表の内容に戻ります。プロジェクトでよく発生する3つの問題点。
問題1：見積もり
シナリオを作成する見積もりです。時間、リソース、優先順位を考慮する必要があります。
問題2：始めること
まずどこから、どのように始めるかを決める必要があります。その他にテストと完了条件を決めます。
問題3：コミュニケーション
同じ文でも異なるように解釈されることがあります。
プロジェクトには4人のステークホルダーがいます。
プロダクトオーナー
アナリスト
開発者
テスター
この4人が共通した認識をもつ必要があります。
シナリオを文書にしてしまうと、開発者にはよく理解できない場合があります。文書に書かれた内容の解釈で間違いやすいからです。シナリオでは次の3つのことを明確にします。
Given：前提条件
When：条件
Then：結果
これらの頭文字を取って、これをGWTと呼びます。
子供は2～3歳にくらいから言葉を話せるようになります。しかし、複数のコンテキストを関連付けられるのは6歳になってからのようです。すなわち、単独したシナリオよりも、複数のシナリオのコンテキスト間の関連を把握させる方が間違いが多くなるので注意が必要です。
最後に、継続的に改善し、問題はすぐに修正して、全プロセスを見て、ゴミを出荷しないようにとの言葉で、発表を結びました。
最初に思っていた内容ではありませんでした。もう少し高度の話を期待していました。しかし、発表自体はとても楽しかったので、もしまた発表する機会がある際に参考にしたいと思いました。
自社開発でなければ先はない
早く終わってしまったので、Puppet-labの共同設立者のAndrew Clay Shafer氏の「Devops - What's Missing? What's Next」に参加しました。最後だけしか聞くことができませんでしたが、良い話をされていました。
自社で開発していなければ先は暗い。Amazonも自社でサービスで開発しています。
学習する組織を作っていなければ、競争力がありません。
アジャイルマニフェストにも書かれてあるように、実際に自分で「して」 、他人が「する」ことを支援することが大事です。
最後に自分風に修正したアジャイルマニフェストを見せてくれました。
スクラムの使いどころ
10:45～12:00は、スクラム（Scrum）を考案されたJeff Sutherland氏の「Simple Patterns That Avoid Common Pitfalls for Scrum Teams」に参加しました。質問がある参加者がJeff Sutherland氏と一緒にソファーに座って聞くことができます。質問が多かったので、質問者を課題ごとにまとめてソファーに呼ぶことになりました。
始める前に、Jeffから簡単に話がありました。アジャイルを使うと、従来方式で開発した場合よりも成功する確率が上がります。しかし、それでもまだ半分以上が失敗で終わっています。これらの失敗はアジャイルが悪いのではなく、「 悪いアジャイル」を使ったためです。
サッカーにはルールがありますが、試合の内容までの選手の動きまでは決められていません。同じようにスクラムもフレームワークは決めますが、プロジェクトで具体的にどのように実施するかについては決められていません。また、スクラムはソフト開発以外で使っても効果を出すことができます。
最近はベロシティが注目されていますが、重要なのは加速（acceleration）することです。スプリントを短くすることでより早く加速することができます。
その後、課題についての解説が始まりました。
課題1：スクラムに関係している組織が分裂し始めているように見えたら
スクラムに含まれていることは必須項目ではありません。状況に応じて利用してください。スクラムを考案したKenと私たちの考えを伝えることは重要だと思っています。
現在のスクラムと2.0の違いについてはビデオで述べていますが、主に6点あります。その中の5点は小さな修正です。最後の1つは重要な修正です。デイリーミーティングで行う3つの質問も内容を変えました。
デイリーミーティングはメンバーの状況を確認するために行うためのものではありません。メンバーがよりよく共同で作業を行えるために情報交換の場です。ただ「昨日は自分は何をした」「 今日は自分は何をする」を伝えるのではありません。「 チームの目標を達成するために」自分は昨日何をした、今日は自分は何をする、を他チームメンバーに伝えるのがデイリー ミーティングの目的です。
課題2：人とプロセス、ツールとは
個人とプロセスはアジャイルマニフェストにも書かれています。問題の80％はプロセスの問題です。人の問題は残りの20％に過ぎません。
「Scrumming the Scrum 」を行うことを推奨します。「 Scrumming the Scrum」とは、スクラムを改善していく仕組みです。実際の世の中には問題が多くあります。「 Scrumming the Scrum」はこれらの問題を解決するのを支援します。
最近、スクラムやアジャイルに関連したツールが多く出回っています。しかし、実際に有効なツールはポストイットと壁です。会話をして、その内容を確認するのはポストイットでも行うことができます。
スクラムが正しく使われるようになると、組織のピラミッドが横に倒れます。組織の構造を保つ必要はありません。マネージャはコーチングやファシリテーションの役に回ります。スクラムにはマネージャは不要なのです。その代わりにリーダーが必要になります。
課題3：チームのパフォーマンス・レビュー
調べによると、パフォーマンス・レビューはメンバーのモチベーションを下げるだけです。ただし、ボーナスを多く貰う理由作りのためにパフォーマンス・レビューを望むメンバーがいます。私の場合は、レビューをした後にメンバーがそのレビューに対して反論する機会を与えています。その際、以下のように点数を与えています。
5～6点：その人が、その人に期待していた以上の成果を上げた
7点：その人が所属するチームが期待していた以上の成果を上げた
8点：その人の上司の上司以上の人の期待していた以上の成果が上げた
9点：顧客から、期待していた以上の成果を与えられたと評価された
10点：社会で良いレビューを受けた
しかし、組織ピラミッドを横に倒した後にはパフォーマンス・レビューは不要です。各自が自分が行うことを他人が見える場に書き込んで、それを読んだ皆から評価されるようにします。
課題4：ハイパーパフォーマンス・チーム
スクラムマスターがチームをよりよくするための責任者です。パフォーマンスを上げるために、以下のことを推奨します。
Scrumming the Scrumを使ってスクラムを改善する
割り込みがあることを予想しておく方が良い
バッファーオーバーフローした場合は直ぐにスプリントを停止して、直してから再開する
課題5：プロダクトオーナなしのスクラム
スクラムマスター（SM）は注目されているが、プロダクトオーナー（PO）はあまり注目されず、POなしでスクラムを始めてしまうユーザがいます。しかし、しかしスクラムを行う目的はビジネスにあります。ビジネスの収益を考えて責任をもつのがPOです。POなしでスクラムを始めるのはビジネスの収益を高めようと思っていないことになります。
課題6：ソフトウェア開発以外での利用
スクラムをソフトウェア開発以外で使うこともできます。
最後に「良いスクラムマスターとはどのような人か？ という質問をときどきされますが、良いスクラムマスターとは、ベロシティを上げてメンバーを幸せにする人だと答えます」とセッションを結びました。
アジャイルを測定する“グッド”プラクティス
14:00～15:15はRally SoftwareのLarry Maccherone氏による「Seven Deadly Sins of Agile Measurement」に参加しました。Rally Software社はAgile2013のスポンサーです。アジャイルの効果についてのいろいろなデータも公開しています。
アジャイルを測定する「ベストプラクティス」はありませんが、コンテキストによっての「良い」（ Good）プラクティスはあります。
現在、アジャイルは以下の3つの目的に使われています。
スクラムのようなプラクティス
マインド設定、価値（Value）の設定
環境の変化
このセッションではアジャイルを上記3．の「環境の変化」として使います。アジャイルはプロセスのフィードバックではなく、製品（product）のフィードバックです。
そして測定に関するよくある間違いとして以下の7つを挙げました。
「間違い1」 、他人の行動を変えるために測定を使う人は以下の観点で測定を行います。
チームを改善するため
予測するため
診断するため
メンバーの行動を変えるため
しかし、アジャイルは人の行動を変えることではありません。自分のみの行動を変えます。自分の測定データを見て、自分を変えるのは良いです。他人を行動を変えようとするのは間違いです。
「間違い2」は、製品に望むことをバランスよく考えないために起こります。ただ早く完成させるだけではなく、品質や出荷時期（早くではなく、オンタイムに）も考慮する必要があります。
「間違い3」は考えずに測定データを使うこと。定性分析の裏づけとして定量データを使うことが必要です。
「間違い4」製品を開発するのはプログラマです。ソフトウェア開発で一番重要なのはプログラムの時間です。その時間を測定のために無駄にしないことです。たとえば、プログラマのプロジェクトコードや作業ごとに利用した工数を入力させるのは、プログラマの時間を無駄にしていることになります。入力する時間だけではなく、プログラム以外の作業をさせることで、割り込みが入ります。結果的にはモチベーションが下がる場合もあります。
「間違い5」はお手軽な計測に頼ること。Outcome, Decision, Insight, Measurement（頭文字からODIM）を考えて測定するメトリクスを考えることが重要です。
「間違い6」は、素人分析が原因で起こります。専門家を使って分析をした方が良いということです。
「間違い7」は、測定結果を鵜呑みにして判断してしまうことです。予測は確率であることを忘れないことが必要です。1つの結果を予測するのではなく、複数の異なる結果になる可能性があることを前提に考えなければなりません。
全体を通して
セッションに参加していると、内容よりも演出を重視しているように思えはじめました。参加者から良い評価を得るために、演出を重視して楽しませているような感じです。驚くような内容の発表は少ないです。また、演出が良いセッションの方に人が集まっています。しかし、セッションの中には本当に勉強になるものもあります。
4日経ってやっとわかってきましたが、自分に役立たないと思ったセッションだったら早く出て、別のセッションに参加した方が良いということです。後の方に重要なことを伝えると思って聞いていても、結局変わらない場合が多かったです。
また、参加する前に目的を明確にした方が良いと思います。学びたいのか、楽しく時間を過ごしたいので、それともただ有名人に会いたいのか。目的を明確にして行動することの大事さがわかりました。自分も含めて、発表者は参加者が途中から出て行っても特に嫌味を感じません。なぜなら、自分も他人のセッションの途中に出て行くことがあるからです。
さよならパーティ
Agile2013は明日（米国時間の9日）の午前で幕を閉じることになります。最後の夜ということで、パーティが開催されます。ナッシュビルだけあって、皆で音楽ステージがあるダウンタウンのバー（有名なWildhorse Saloon）を借り切って行うことになりました。今回は1,725人の参加者だったので、全員が参加しないとしてもホテルからナッシュビルへのバスの台数は半端ではありません。
ステージの上でライブバンドもあって、踊るスペースもあります。しかし、人が多いので、皆が合わせて踊るMob Danceです。
お店を出たら、もう暗くなっていました。8月なのにクリスマスツリーのように木は電球が飾られていました。
