アジャイルカンファtokyoの共有

102
アジャイルカンファレンス tokyo 行ってきました 藤川 康之

Upload: yasuyuki-fujikawa

Post on 22-Jul-2015

610 views

Category:

Technology


3 download

TRANSCRIPT

アジャイルカンファレンス tokyo 行ってきました

藤川 康之

アジェンダ

アジャイルカンファレンス tokyoとは

21世紀のソフトウェアデザイン

21世紀型ポートフォリオ管理への変革

アジャイルカンファレンス tokyoとは

ThoughtWorks社、株式会社テクノロジックアート

21世紀のソフトウェアデザインマーティン・ファウラー氏(ThoughtWorks Inc.)

マーティン・ファウラー氏

マーティン・ファウラー氏

Wikipediaより

アジャイルの本質に立ち返る

アジャイルソフトウェア開発宣言から10年

当初の意味の希薄化(Semantic Diffusion)

起きてしまった

デリバリーまでに時間がかかりすぎる

意味のないシステムを作り上げる

品質の低いシステムとなったりする

すべてできて当たり前の状況であった

計画駆動型開発(Plan-Driven)      ※日本で一般的なウォーターフォール型も  この考え方に属する

CMM(Capability Maturity Model) ※能力成熟度モデル

アジャイル

適応的な計画(Adaptive Planning)

予測的な計画(Predictive Planning)

Agile Plan-Driven

人主導(People-first)

プロセス主導(Process-first)

適応的な計画(Adaptive Planning)

予測的な計画(Predictive Planning)

Agile Plan-Driven

人主導(People-first)

プロセス主導(Process-first)

よく失敗したプロジェクトの話

「管理者が無能で要件を固定できなかった」

「顧客がわがままで最後まで要件を決めてくれなかった」

計画駆動のソフトウェア開発では

成功のために要件をいかに

安定させるかということに力を注いでいた。

アジャイル開発では違うアプローチ

要件の安定に依存するのは健全ではない。

要件が不安定であっても

プロジェクトを前に進めていく

アジャイルの考え方とアプローチ

アジャイルの考え方

要件が

不安定であるということを認める

作業が進められるように計画を適応させる

アジャイルなアプローチ

少しだけ計画

そこから学習する

アジャイルの適応性を理解する

適応性外的な刺激や環境の変化に応じて,

それにふさわしいように自分を変えていく性質能力。

ユーザーも開発者も学びを続け

徐々にお互いが有効に機能する方向に収束していく

適応的な計画(Adaptive Planning)

予測的な計画(Predictive Planning)

Agile Plan-Driven

人主導(People-first)

プロセス主導(Process-first)

科学的管理法※労働者管理の方法論

プロセスがはっきりしている→プロセスに従って働く人

プロジェクトのチームに対して

この人はプログラマこの人はテスター

この人はアナリスト など

プロセスがいちばん重要

このやり方に疑問を持つ

優秀な人たちがよい関係で仕事をする

そうしなければ仕事は、うまくいかない

アジャイル開発では

優秀な人をさがし

チームとして協力できるかを見極める

自分たちでやりやすい環境や プロセスを作る

プロセスありきから、人ありきになる

もたらす結果

押し付けられていない

自分で選択しているというチームメンバーの考えが生まれ

自分で選択しているというチームメンバーの考えが生まれ

もっとプロセスを良くしようとしてプロセスが進化する

改善に熱意を燃やす

最後に

Perfect

名詞ではなく動詞

「完璧」なソフト

「完璧を目指して改善する」

適応的な計画(Adaptive Planning)

Agile

人主導(People-first)

21世紀型ポートフォリオ管理への変革David Joyce 氏(ThoughtWorks Inc.)

プロジェクトについて

プロジェクトが始まるときは、最終的な結果を考えて予算などが決められる。

スケジュールなどがちゃんとなっているかを「監視」している。

しかし、「価値」ということは見落としている。

古い考え方

1.ウィジェット工学

図を描いて、その図の通り作る

2.御用聞き体質

作れと言われたものを作る

3.機会の最大化

始まりが多ければ、終わりも多い

4.マイルストーンの制御

現在地が分からないのであれば、より詳しいデータが必要だ

5.丸一年のプロジェクトを計画できる

詳細な計画を立てれば、今年は必ず成功する

6.とにかくやる

合意された計画なのだから、実行する

こういうことを推奨しているヒーローに振り回され

残業残業ということになってしまう。

ガントチャート

1919年のガントチャートと同じ物が今でも使われている

21世紀ということで違う思考でソフトウェア開発をしてもよいのではないか?

「WFでうまくいっているであれば、それでいいじゃないか」という考え方もある。

一昔は、3年後ならというプランニングができた。しかし、今は3ヶ月となっている。

WFでは、今の時代の速さについていけない。

考え方を変える必要がある

真ん中の部分だけちょっとアジャイルを入れてみようという変化がある。

WF要件定義、設計

WF結合テスト etc

Agile製造、単体テスト

開発フロー

しかし、これではビジネスアジャリティ(俊敏性)

というのは「ない」

すべての開発フローをアジャイルにすること

詳細なビジネスケース&計画から研究、仮説、実験へ

作っているものは、コンスタントに確認していく。

プラン(計画)通り作成されていても

お客さまがその成果物で納得するかどうかは別問題

詳細な実行計画を作って実行を学習はできない。実験をしなければならない。

いきなり予算をボンッともらうわけではなくある小さなことを解決する予算をもらうようにする。

シードファンディングと呼んでいる。

少しずつ芽が出てきたら追加で予算をもらうようにする。

逆に芽が出なかったら別のことに使うということになる。

アジャイルという手法だから出来るやり方

大きなプロジェクトではこれができない

細かくやっていくことが大事。

優先度高