Agile2010で一番面白かったセッション。
スクラムの効果測定方法について具体的に話されていた。
スコット・ダウニーさんが話し、ジェフ・サザーランドさんがフォローする形。

• 資料とRoboCoach（今はRoboScrumらしい）はhttp://rapidscrum.com/RoboScrum/index.phpからダウンロード可能

Youtube（音声なしなのが残念）

*

• スコットさんはNapsterでコーチングをされている
• 68チームでScrum導入によって600%成長した
• イテレーションは4?5Weekに設定

コーチングのゴールはINVEST

• Immediately Actionable – すぐに行動
• Negotiable – 交渉できること
• Valuable – 価値があること
• Estimable – 見積もれること
• Sized to fit – フィットするサイジング
• Testable – テスト可能なこと

ストーリーの扱い方。

• まずは適度なサイズをみつける
• 大きければ適度なサイズにチャンク化すべし
• 適度なサイズになったときにスプリントバックログにつっこむ
• キーとなるストーリーを見つけておく
• ストーリーは人によって考え方が異なる
• 困ったときはスクラムマスターにレビューしてもらう

デイリースクラムでの3つの質問は有名だが、それをさらに改良しているという。
これについては、Agile2010 – デイリースクラムの4つ目の質問にまとめた。

ここからが本題。

彼は、スクラムの効果測定として、様々な公式を作り、マクロでそれを実装したという。こういうマネージャがいるとチームは楽をできるだろう。

公式の例として以下がある。

Focus Factor = Velocity（予想） % Work Capacity（実績）

見積もったVelocityを実際のVelocityで割って、「焦点となる係数」を洗い出す。数値化は限界があるが、指標としてこういう数字をまとめておき、それぞれが何を意味するかを定義するのは重要。

これらをまとめたのがロボコーチと呼ばれるExcel。Jeffさんのページからダウンロードすれば使えるが、結構新しいOfficeを使っているので、開けない人はPower Point Viewerをダウンロードすれば見ることができるはず。

「バトルフィールドだと！」ということで参加したんだけど、Agile（だけじゃなくてもいける）を武器に組織の中でどのように戦っていくか？についてのセッション。

• Agile2009の資料は、こちらのページからユーザ登録すれば見れそう

 

写真がなかったので昼食のビュッフェ映像を御覧ください。スワン＆ドルフィンのご飯はほんとうに美味しい。

*

• みんな苦しんでいる階層構造
• みんな苦しんでいる社員の報酬制度
• みんな苦しんでいる方法論
• みんな苦しんでいるCragilist（Crap Agilist：うんこアジャイラー）

Agileプロジェクトが成功したとしても、効果がでなかったり、スクラムマスターの残業でなんとかなってしまったりしていないか？なぜ努力に失敗するのか？

• あまりにも多いプラクティス問題
• それぞれのプラクティスだけでは十分でなかったりする
• コントロールではなく、影響をあたえるのが重要 ＞ アークランプのゆーすけさんの話に似ている
• Agile導入の戦略を立てたとしても、それは戦争になってしまう！

というわけで、組織の戦場MAPを作ってみましょう。
前に、「社内を三国志に例えるなら？」「社内を日本戦国時代に例えるなら？」というのをチーム内でやったことがあり、これをUSミリタリーテイストでやるセッションです。

*

やりかた

• プロジェクトで作る
• ステークホルダーを見つける
• 自分のボスを忘れずに
• マネージャと自分のチームも忘れずに
• 円と線で影響を書き込む

こんな感じ。
これらで問題点を見つけることができる。そして、これらはパターン化されている。

*

こういうゲームはなかなか面白い。（チーム内でしかできないけど）
自分の状況を確認し、攻撃を仕掛けてくるところを以下に回避してうまくもっていくか。
Agile2010のOrganization部分は、組織論が多かった気がする。

Robin Dymond , Jurgen De Smet.
ヨーロッパで開催されたAgileイベントの映像を発見。＞映像はこちら

 

シチューみたいになっちゃっているシステムを改善した時の話。

• バリューストリームマップなしでLeanはありえないので、マップを作った
• 13年もののレガシーコードで460人規模の開発者。5ロケーション、26チーム、リファクタリングなし。テストももちろんなし。ビルドに5時間という地獄絵図だった
• この複雑さを、組織構造とR&Dで改善した
• このセッションでは、「開発部」を「R&D」と表現していて、すべての案件は、沢山のチームから依頼が来るが、結局R&Dセクションに集まってくる組織構造にしていた
• 改善が理解されないのはあたりまえだったが、それでも改善
• 中でも複雑だったバージョニングを簡易化することが大きかった
• 問題点として、1つのリストにたくさんのバックログ
• 問題点として、プライオリティが決めにくいこと
• 問題点として、みんなを納得させること

よくありがちな問題。彼らは何をしたか？

• エンタープライズレベルのバックログを作る
• そのためには、不確実性の少ないものをプロダクトバックログの優先度で高くして対策
• そのためには、ジャストインタイムで要件を分解して対策
• そのためには、プライオリティ変更がシステムに与える影響を考えるようにする

これらによってマネジメントは理解を始める。

• なんといってもCIは重要。
• CIは少ないコストで品質を高めることができる
• デモMTGや計画MTGで、ロケーションの違いを埋める努力をする
• 動いているものはやっぱり強い

テクニカル的には

• 開発インフラの複雑さを解消させる
• アーキテクチャ依存の構造をなくす

キーとなる要素は

• 教育はキーとなる
• 継続して学ぶ組織構造

Agile2010とはなんだったのか？でお話させていただきました。

• Ustream ： http://www.ustream.tv/recorded/8997811
• Togetter ： http://togetter.com/li/43116

@kawagutiさんからのお誘いで、参加させていただきました。
予定より多くの方にきていただいたことと、運営を手伝っていただいた方に感謝いたします。

川口さんの資料は以下。

ざっくりとした感想ですが。

• 50人ぐらいの方がいらっしゃったので、みんなお小遣いを貯めて来年一緒に行きましょう。
• 一緒に行った仲間2人の発表を聞いたけど、それぞれ持って帰る物があったんだなぁと思った。よかった。
• @kawagutiのモチベーションの高さはすごい。かえってすぐ発表には参ったw
• びっくりするぐらい「Agile2010とはなんだったか」がテーマじゃないwww
• 次はXP祭り2010に参加予定です

詳細は@masayangさんのAgile2010 Day Twoがすばらしいです。
僕のは「適当に解釈」しています。

*

 
Dave Thomasさんによる「The Last 10 Years of Agile, a Retrospective」。「Agileの10年をふりかえる」がKeynoteでした。1000人規模の振り返りですね。@kuranukiさんが、今年、弊社で離してくださった内容にとても似ています。
アウトラインは以下。

• 10年を振り返ってみましょう
• The Grand Legacy Challenge
• Lean Zen
• Enterprise Agile – Agile in the large.
• Beyond Agile 2010

10年を振り返ってみよう ＆ The Grand Legacy Challenge

• 2008年から2010年でアジャイルはキャズムを超えた
• Agileツールが増えてきた
• 職人主義に戻りつつある
• 養成重要

重要と考えられる視点

• ナレッジの共有
• リスクを減らすこと
• ストレスを減らすこと
• 欠陥を防ぐ

これらのために、レビュー、インスペクション、ペアプログラミングという方法が使われているはず。

予測可能性（predictability）を成長させるために必要な要素は以下。

• シンプルなワークフロー
• 短いイテレーション
• 協調的な見積り
• シンプルで分かりやすい進捗管理

品質を上げるための要素は以下。

• コミュニケーション
• CI
• TDD
• まとまったチーム

生まれつきのリーダーシップ。

• 自己組織化
• リーダーシップ重要

生産性（productivity）。

• MTGへらせー
• 残業を減らす
• コミュニケーション
• ストレスを減らす

Lean thinkjing – The Zen of Agile

• Leanはトップダウンアプローチ
• 管理はバーンダウンチャート、UnitTestやストーリーの消化具合、ふりかえりレポートを利用
• Testingはバグの欠如を知らせてくれるはず
• テストをすることはお金の面でも経済的
• ツールやメソッド以前にプラクティス ＝ プラクティスファーストであるべき
• Enterprise toolingではスケーラビリティが必要になってくる

Enterprise Agile – Agile in the large

組織構造の図が興味深い。
Management Leadership側は、従来の組織イメージに見えるけど、
Technical Leadership部分が重要になってきそう。これがクラフトマンシップ？

• 大規模への移行
• アセスメント重要
• 現実的な予想をしていく
• システム変更計画ももりこんでいく
• ガバナンス・キャリアもそろえていく
• 基準の受け入れを考える
• 大規模での見積り ＄ & days
• アーキテクチャはロールやプラクティスであって職業ではない
• インタフェースを設定する（APIやサービス化）

そういえば、Agile2010ではあまりアーキテクチャの話を聞かなかった気がする。テクニカルなセッションではかたられていたのかな？

Beyond Agile 2010

いよいよAgile2010の次を考えます。

• 職人！
• 教育とそのサポートが重要になってくる
• ハイレベル言語をもっと表現豊かに利用する必要が出てくる
• 変化のための設計 たとえばMore Data Drivenなど
• リーダーシップと規律

*

キーになるノートというよりは、ふりかえりをもとに話をされているので、「じゃ次は？」というところがあまり見えてきてないです。Agile2010のTalkセッション全般に言えるのですが、事例紹介が元になっているため、それを持って返って自分なりに考えろということでしょうか？

午後はチュートリアルでありながらディスカッションしてみましょうという
「エンタープライズアジャイルの青写真」というタイトルのセッションです。

Blueprint for an Agile Enterprise – Michael Spayd

エンタープライズレベルのアジャイルに対する質問。まずはこれについて考えてみてください。

Organization

• What is trying to happen?
• どんな企業文化を持っていますか？
• アジャイルにフォーカスしていますか？普及していますか？

Leadership

• あなたのリーダシップを展開していますか？他の人達によって使われていますか？こじんまりとなっていませんか？

Business

• どうやってビジネスに最適化していますか？

Program

• どのように製品に価値をつけていますか？私たちのプロセスにどんな調和が必要ですか？

Management

• 自己組織化されたチームにどのように価値を追加することができますか？

Individual

• 責任をどうもちますか？

これらの答えから、４つの文化タイプにわけることができるという。

• 協調
• 管理
• 教育
• 能力

例えば、協調ならば「和」の文化があり、管理ならばミリタリー的な階層分化。教育（教養）は価値重視で夢をかなえていく文化。能力だとエリート主義。

つぎに、自分のチームはどの位置にいるかをこの4つの観点から考えてみる。

隣の人に「管理が強いな！」と言われたけれど、Agileに開発するために、今は管理と教育段階なんだと説明。彼の表を見てみると、教育と協調がとても強くなっており、Agileに開発ができている会社にみえました。
ディスカッションでも、（早口であまりわからなかったが）彼の会社の紹介をするたびに、「すげー」「うらやましー」という声が上がっていました。

上の図がAgileな文化の形だそうです。協調だけではなく、プラクティスを学ぼうとする教育（cultivation:養成とかのほうがいいかも）を重要視すべきとのこと。

これをふまえ、

• アジャイルプラクティスは、悪しき方法論から人々を磨いてくれること
• アジャイルプラクティスは、開発者にフィットし、サポートし、活気づけてくれること
• アジャイルプラクティスは、IT部門に近い他のドメインに進んでいくこと

を見つけ出し、

• 戦略や文化、リーダシップを整理
• 戦略や戦術の採用としての意識的な決断
• アジャイルにふさわしい文化づくり戦略
• 手の届かないような文化の変化は押し付けない

ことが重要になります。

リーダシップとしては、

• リーダーシップやコーチングを行う者同士のリーダー同盟
• リーダーシップアジリティに対する360度評価
• リーダーがなんでもしてくれるとおもうべからず

という考え方をもつべきではないか？とのことです。アジャイルチームに対する評価は、やっぱり360度評価になってしまう気がする。

そして、組織の中での役割は以下のレベルに分類できます。

• Expert・・・技術や問題解決能力にすぐれている。Expertは権力や専門知識によって、尊敬され、かつフォローされている状態。Agileでの役割は？？？
• Achiever・・・戦略的成果志向。Achieverは、大きな目的に対してのチャレンジや満足によって、他のメンバーを刺激する。Agileでの役割はAgile Managerになる
• Catalyst・・・ビジョンや、促進にたいする姿勢を持っている。Catalystは革新的・直感的ビジョンを明確に示し、共通のビジョンを持ち、現実に落としこむ。他のメンバーを勇気づけ、彼らの開発をささえる。Agileでの役割は、Agile Executive。

次に、「自分のチーム」「他のチーム」で実際にどの位置にいるのかを上のマトリクスで考えてみます。
これをもとに、以下の中から自分のチームにマッチした「What to do」が選択できるはずです。

• 自己組織化されたチームを選択する
• チーム内で発見となる勉強会を行う
• チーム文化やチームルールから、パートナーシップ連合を結成する
• 定期的なチームの健康診断
• コーチとなる人物を呼ぶ

また、マネージャとチームの関係も以下のパターンがあるのではないかとのこと。

アジャイルチームのマネジメントだと、チームに接するのがポイントのようです。これは、アジャイルでなくても、自己組織的なチームだと、こうならざるを得ないと思う。

最後は、最初の質問振り返り、それぞれに必要である優先順位の高い訓練方法をまとめていました。

Organization

• システムはモデルを変更する
• 核となる文化の標準を合わせること

Leadership

• リーダーシップアジリティ

Business

• ムダのないアジャイルビジネス

Program

• 信念を持ったPMO（プロジェクトマネジメント部隊）

Management

• アジャイルマネジャーとしての能力

Individual

• 自己的なリーダシップと責任能力

*
企業文化による分類から、組織の中の役割を定義し、マネージャとチームの関連性を整理するセッションなんでしょうかね。
とても分かりやすくブレークダウンされていたため、すんなり理解できました。

やっと1日目をまとめ終わりました。

http://agile2010.agilealliance.org/
Agile 2010に行ってきました。
会社の同僚2人と1週間のAgileまみれの旅。そんな思い出をまとめてみます。
*

今年はフロリダのオーランドでの開催。ホテルは、ディズニーワールド内にあるアンオフィシャルホテルWalt Disney World Swan and Dolphinになる。さすがにリゾートホテルだけあり、ホテルの人はとても親切。1週間、困ることなく過ごすことができました。
今回のイベントテーマは、3つのコミュニティとのコラボレートです。
* Business
* Leadership & Organization
* Technical Track
会場もテーマごとに分かれており、私は”Leadership & Organization”中心にセッションに参加しました。

ブースにはAgile関係の本がぎっしり。これを見ると、日本語訳されている本の少なさを知り、翻訳をがんばっている方に感謝の気持ちが生まれますね。

はじめのワークショップのときに火災警報器がなり、ホテルから退避！写真が曇っているのは、ホテル内が激寒く、外が激暑いからで、「こっちは暑いぜ！」って書いてあったので、短パンとTシャツしかもってきていない自分には苦痛だった。

変に時間が潰れたので、リサーチのセクションで話を聞いてきました。研究しながら仕事をしている人の発表です。

Reactive Variability Management Using Agile Software Development

変化しやすいソフトウェアを作るときに気をつけることについての紹介。


アーキテクチャ的にどう作るかと、どうFeatureを盛り込むかが説明されている。

An Iterative Approach for Development of Safety-Critical Software & Safety Arguments

ソフトウェアの品質と安全性の話。

品質が高くても安全ではない。品質を作り込むということが、アメリカでもあたりまえのように語られている印象を受けました。

ウォーターフォールの説明でもみる説明ですが、ここでは「どこに重点をおくか？」の説明として使われているみたいです。

Adopting Code Reviews for Agile Software Development

リサーチのセクションで一番面白かったのがAgile開発でのレビューの話。

ペアプロ無敵とはいえ、レビューによる共有ははずせないとおもうので、あらためてレビューの方法や、lightweightな方法の紹介がされていました。
バグを減らすためにレビューをしたいけど、時間がない場合がほとんど。従来のようなレビューでは時間がかかってしまうのが問題です。

彼はこの問題に対して、上記のような方法を提案しています。
* レビューを継続的な仕事にしてしまう
* レビューを小さなタスクに分割して実行する
* レビューのタスクが自動的に発生するようにチームでルールを決める
* 分散しがちなレビューをうまくまとめる
* IDEをつかえばもっと簡単になる

上記のように、ルールをある程度決めることで、「どこをどれまでレビューするか？」が明確になり、レビューのやり過ぎやレビューの欠如をならそうという作戦に見えます。
公共事業系の開発だと、こういったチェックリストがあったりしますね。ただ、lightweightではなかった。

小さく分けることにより、フィードバックと変更が早く実行され、時間の浪費を削減できそうです。

過去のやり方だと、レビューもAgileではなく、計画の一つになってしまっていました。しかし、テストを書く＞実装する＞レビューするというように、開発プロセスに小さく入れればいいんじゃないか？という提案です。


彼が使っているのはReviewClipseとMylyn。
Eclipseは成熟したソフトウェアになっているので、これらをつかうことで、開発とレビューとタスク管理などを統合的にまとめることができるのはたしかに魅力的です。
*

ランチはビュッフェ形式でした。それにしてもこのホテルの食事はいつもおいしかった。