読者です 読者をやめる 読者になる 読者になる

メソッド屋のブログ

米マイクロソフト DevOps エバンジェリスト 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

Agile2011レポート2〜セッションまとめ続き〜

次の日はコレだけです。


というのも、この期間中、毎日プレゼン練習や修正に明け暮れていたから、、、とても気さくに昨晩話しかけてくれた彼のセッションに出る事にしました。

8/9

Coaching at the Enterprise Level - Introducing the Agile Cafe: Joe Fecarotta

Agile2011: Schedule

仲良くしてくれたから、行ったのでそんなに期待していませんでしたが、とても良かったです。他にもこのセッションはTalkのセッションでハードルが高かったのですが、平鍋さんに教えてもらったメソッドで、最初に「わしは英語不得意やけど、参加していい?」てな事を言うと皆とても楽しく教えてくれました。


 彼はボーイングに勤めていて、大きなプロジェクトのマネジメントを経験しています。彼は組織的にAgileを広めるときに、Agile Cafeという手法を使っていました。これはWorld Cafeをもう少しオーガナイズしたものでよく考えられており、とてもよいと思ったのが、それをAgileを広げるための体系の一部として組み入れていた点です。
 アジャイルのインストールの体系として、彼は最初に経営層とかに「アジャイルの教育」「アジャイルコーチング」「アジャイルのxx(何か忘れました)」の3つの要素をつなぐものとしてこのAgile Cafeを実践しています。期間は、半期とかクオーターに一度といった頻度で実施するそうです。
 彼のプレゼンテーションは、Zenスタイルではないですし、ダウンロードできるようにするとも言っていたので、ダウンロードできないかチェックしてみてください。やり方とか、さっきの3つの要素の図も乗っているはずです。



8/10


Tell Me Why -- 'The Golden Circle' of Agile Transformation: Jean Tabaka


Agile2011: Schedule

 前日の夜お話して、ムーンウォークをレクチャした彼女のセッションに再チャレンジ。実は前日に私は考えを変えました。Agile2003に言ったときは帰った後「なんで折角アメリカにいったのに、もっと彼らとしゃべらなかったんだろう、何で勇気を持てなかったんだろう」ととても後悔しました。だから、自分の行動の判断基準をこのときから「自分がそうしなかったら後悔するか否か?」という基準で決める事にしました。だから、初日全然わからんかったけど、彼女のセッションに出る事にしました。しかもワークショップやから相当ハードル高いはず。これに出ると安藤さんもいました。彼は本当に勇気のある人で、何事も恐れません。見習いたいと本当に思いました。


 さて、彼女のセッションですが、これまたとても良かったです。


 ゴールデンサークルのやり方はカンタンで、こんな感じ。例えばアジャイルをインストールしている組織の中で、様々なメンバが、アジャイルについて学び、自分の持っていない情報をもらったり、情報を交換し合ったり、いろいろな気づきを得る事が目的です。



1. Howを出す

 自分たちがやっているプラクティスをカードに書いて並べます。例えばテスト駆動開発とか。


2. Whatを出す

 そのHowのわの中に、プリンシプルを出して行きます。例えば 包括的なドキュメントより、コミュニケーションを重視するとかです。
 これもいろいろ出しています。


3. Whyを出す

 その組織が何故アジャイルを導入しているか?という根本的な目的を考えて共有します。例えば「Time to marketの短縮」などです。



特にいいな、とおもったのが3です。3.の視点は忘れられがちですし、2.の視点を出す事も、通常はプラクティスベースに目がいくはずですので、それが何のためにやるかを意識することで、応用が利くようになります。そしてそもそもの目的を意識することで、アジャイルにこだわらない広い視野を持つためのヒントになります。これはとてもいいやり方だと思いました。


また、彼女のセッションで面白かったのは、アジャイルにどんなプリンシプルがあるか?を述べたところで、これからのアジャイルコーチは、次の素養を勉強しとけばいいよというヒントになると思います。

1. Lean Principle


Directly Observe Work as Activities, Connections, and Flows 仕事を直接観察する。アクティビティ、コネクション、フローに注意して
Establish High Agreement of both What and How       What/Howで高い合意形成を行う
Systematic Waste Elimination システマティックな無駄取り
Systematic Problem Solving                 システマティックな問題解決(5つのなぜ?とかかな?)
Create a Learning Organization               学びの文化(組織)を作る


http://beyondlean.wordpress.com/2010/07/26/comparing-lean-principles-to-the-14-toyota-principles-part-1/



このブログ記事をみるとTOYOTAの14つのプリンシプルものっています。


Toyota Principle #1: Base Your Management Decisions on a Long-Term Philosophy, Even at the Expense of Short-Term Financial Goals.

長期視点にたったマネジメントの決断を基本とせよ。短期的な、財務的なゴールよりも。

Toyota Principle #2: Create Continuous Process Flow to Bring Problems to the Surface

継続的にプロセスフローをつくり出す事で、問題を表面化させよ

Toyota Principle #3: Use “Pull” Systems to Avoid Overproduction

プル型システムで、作り過ぎをさけよ

Toyota Principle #4: Level Out the Workload (Heijunka)

負荷の平準化

Toyota Principle #5: Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time

問題を修正するために、止める文化を創り、最初から品質を保つ

Toyota Principle #6: Standardized Tasks Are the Foundation for Continuous Improvement and Employee Empowerment

標準化されたタスクは、継続的改善と、社員のエンパワーメントの源、、、

、、、なんて書いている間によくよく考えるとこんなことわしがせんでも黒岩サンのプレゼンを見れば一撃と気づくのでここまで、


当然リーン三部作も読むといいでしょう。

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーンソフトウェア開発と組織改革

リーンソフトウェア開発と組織改革

リーン開発の本質

リーン開発の本質

2. Agile Manifest 12 Principle

Principles behind the Agile Manifesto


3. 複雑性の理論


以外と資料がない。昔ジムハイスミスさんの、アダプティブ、、、に記述があったような、、、、
いいのがあったら誰か教えて。

Complexity theory and organizations - Wikipedia, the free encyclopedia


4. システムシンキング


これはわかりやすい本があるよ

もっと使いこなす!「システム思考」教本

もっと使いこなす!「システム思考」教本

あと一応ワインバーグさん

ワインバーグのシステム思考法  ソフトウェア文化を創る〈1〉

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

5. デザインシンキング


読んだ事ないけど、これ?誰か知っている人教えて!

Design Thinking: Integrating Innovation, Customer Experience, and Brand Value

Design Thinking: Integrating Innovation, Customer Experience, and Brand Value

他のセッションでもいろいろあったようで、ここら辺を是非押さえておきましょう。という指針があるのはいいね!



Basic Principle of the TPS and its Practical Ideas for Agile Software Process!: Satoshi Kuroiwa, Kazumasa Ebata

Agile2011: Schedule


そして黒岩さんのセッション。エバッキーがいなくて残念だけど、それでもとても良かった。わしのチープな記事より本物をプレゼンから感じてほしい。Zenの真逆なので伝わるはず。
最初の方は知っている話しだったけど、後半はやっぱり来ている。ともかく、プレゼンテーションを見てほしい!

モノ作りはヒト作り! はやくダウンロードできないかなぁ、、、

Solving the 1-10-100 problem: Extending Continuous Delivery to QA and Ops: Ronen Rubinfeld, Mik Kersten

Agile2011: Schedule

Continuous Delivery周りのCI + QA + リリースまで含めた話しだったけど、正直そんなに印象的ではなかった。1-10-100 problemというのは、要求段階でバグ治すと1の労力やけど、開発だと10でリリース後だと100の労力がいるという話し。ALM系のお話です。

うーむ。今日はここまで。疲れた。