agile day アジャイル開発まずは社内の誤解に立ち向かえ

アジャイル開発　まずは社内の誤解に立ち向かえ

2010/1/22 Ryutaro “Ryuzee” YOSHIBA.

2010/1/22 Agile Day copyright(c)2010

Ryuzee 2

自己紹介

Ryuzee( りゅー爺 ) / Ryutaro YOSHIBA.ブログ　 http://www.ryuzee.comTwitter ryuzee

TIS 、野村総合研究所を経て、スピンアウト専門はアジャイル教育、アジャイル導入支援、

組織の生産性向上、 Web システム開発Certified Scrum Masterオープンソースプロダクト開発者

http://www.ryuzee.com/

http://twitter.com/ryuzee

3

Disclaimer

本プレゼンテーションに記載した内容は発表者本人の経験、見解によるもので、本人が所属する（した）組織、団体の意見を代表するものではありません。

本プレゼンテーションの内容を用いた結果発生したいかなる事象について、発表者はなんら責任を負いませんのでご注意ください。（例：上司のアジャイルに対する誤解を解こうとして色々やったら嫌われたとか）


Ryuzee

4

はじめに

「アジャイル」という言葉が開発現場の上位層まで認知されてきましたが、表面的な理解、誤解をされているケースが多々あります。

本プレゼンテーションでは、経営者やマネージャ等の方の誤解しやすい点について列挙し、それに対する反論の根拠を示したいと思います。


Ryuzee

5

「アジャイルだから計画立てないんだよね？」

むしろアジャイルの方が計画的です！

アジャイルは最初に長期にわたる 100% の計画をたてることは不可能であると考え、制御可能なタイムボックスに分割します。

要求には優先順位がつけられ、規模も相対的に算出されています。

タイムボックスの中のタスクは制御可能な単位まで落とし込まれ、自分たちの生産性と照らし合わせながら実現を積み上げていきます。

WF で怪しいプロマネが適当に線表を引いて、それが顧客まで独り歩きして・・・という状況とは大きく違います。2010/1/22 Agile Day copyright(c)2010

Ryuzee

6

「アジャイルだからドキュメント不要でしょ？」

ちがいます！アジャイルでもドキュメントを用意します

アジャイルマニフェストでは

「動作するソフトウェア＞ドキュメント」

という価値観を言っているだけで、ドキュメント無しで良いとは一言も言っていません。


Ryuzee

7

「ウォーターフォールより早く終わるよね？」

「終わる」の定義次第です！

そもそも「プロジェクトが終わる」の定義って何でしょうか？

チームの生産性、プロダクトオーナーのプロジェクトへの協力など変数が一杯ある中で、どうやって保証しますか？はっきり言えるのは「 WF はリスクがプロジェクトの後半に集中しますが、アジャイルはリスクが一定だ」ということです。

完全に同一の成果物を作ろうとするわけではないことに注意2010/1/22 Agile Day copyright(c)2010

Ryuzee

8

「ウォーターフォールより安くできるよな？」

前ページで話したようにプロジェクト完了の条件次第です。

WF では要求事項が固定になりますが、アジャイルでは時間とリソースを固定にするのがベストなためです。


Ryuzee

出典： Mapping the PMBOK Knowledge Areas to Agile Practices By Michele Sliger

9

「アジャイルだから仕様変更は自由だよね？」

完全に自由な訳ではありません！

現在のスプリントで実装中のストーリーの変更とスプリント内で実装する機能の（チームの意にそぐわない）追加は NG です。

それ以外のストーリーの追加は歓迎しますが、変更や追加を行えば行うほど費用がかかるか、優先度の低いストーリーとの入れ替えになります。

無制限・無費用な変更ということはあり得ません。


Ryuzee

10

「アジャイルだから画面から決めるんだよね？」

ちがいます！

何を表示したいか、何をさせたいかは決めますが、コテコテに画面遷移や UI から決める必要はありません（してはいけません）。

UI の層は一番変更かけやすく、終わりが明確でありません。 UI がビジネス上の大きな価値を持つので無い限り、UI の細かい調整は後回し。

UI から設計を進めると、モデルや状態遷移が分かりにくく、顧客も UI の話にフォーカスをあてがちになるため、肝心の要件の漏れが生まれやすくなります。


Ryuzee

11

「同時並行で複数の案件できるよね？」

生産性が高くなるという理解からの誤解だと思われますが、ちがいます！

同時に複数の仕事をやると、スイッチングのオーバーヘッドもあって生産性が落ちるだけです。

スクラムマスターが他の仕事を一杯抱えているチームは危険信号。目が届かなくなり始めたら一気に崩れる可能性あり。


Ryuzee

12

「一人で全部やるんでしょ？」

ちがいます！

一人じゃなくてチームです。たとえ一人プロジェクトでもチーム。ゴールを目指せるチームを作れば良くて、個人の能力のバラつきや得意不得意は当然あります。技術的なレイヤーで分業して人の範囲に口を出さない、というような縦割りではなく、人のタスクも把握する、口を出す、助ける、一緒にやるというのが大事。


Ryuzee

13

「たまに朝会でるから状況教えてよ！」

出るのは良いですが、発言権はありませんし、あなたへの報告会でもありません！

よくある NGパターンは管理職がふらっとやってきて、言いたいことだけ言ったり、ダメ出しだけしていくパターン。

チームの自律性に任せることが必要。チームは全員でプロジェクトの成功の責任を担って行動

しています。


Ryuzee

14

ご清聴ありがとうございました。

※ここまでたどり着いたか？


Ryuzee

agile day アジャイル開発 まずは社内の誤解に立ち向かえ

Technology

agile day アジャイル開発まずは社内の誤解に立ち向かえ