アジャイルなマインドで行こう! Web
Transcript of アジャイルなマインドで行こう! Web
アジャイルなマインドでいこう!
2009/06/27minamo
コントロール
本題に入る前に・・・
•みなさんの参加しているプロジェクトは、きちんとコントロールされていますか?
コントロールされていないプロジェクト
•コントロールされていないプロジェクトは・・・
Q:状況は?
A:(多分)納品日には(どの仕様が入るか判らないけど)間に合います(と思いたいです)
→とにかく頑張れ!
コントロールされたプロジェクト
•コントロールされたプロジェクトは・・・
Q:状況は?
A:計画から、3日遅れています。○ ○ ○ ○の実装は間に合いますが、 は難しいかもしれません。ただし、 × × をやめれば、両方入れられますが、いかがいたしましょうか?
コントロールされたプロジェクト
•たとえ状況が悪くなっても、対策を立てられる
•スタッフも、下手な不安・不満を抱かない
プロジェクトはコントロールするもの
ただし
≠コントロール 管理
管理ではない
•プロジェクトは管理するものじゃない
•プロジェクトはマネジメント/コントロールするもの
コントロールする方法
•プロジェクトをコントロールする方法が、
開発手法
プロジェクトマネジメント手法
主な開発手法
ウォーターフォール
プロトタイピング
スパイラル
XP
スクラム
リーンソフトウェア開発
アジャイル開発
主な開発手法
ウォーターフォール
プロトタイピング
スパイラル
XP
スクラム
リーンソフトウェア開発
今回はココ
アジャイル開発とは
•Agile 敏しょうな、素早い、機敏(きびん)な
アジャイル開発とは
< アジャイルソフトウェア開発宣言 >
•プロセスやツールよりも、個人と対話を優先す る
•包括的なドキュメントよりも、動作するソフトウェア を優先する
•契約の交渉よりも、顧客との協調 を優先する•計画に従うよりも、変化への対応を優先する
アジャイル開発とは
< アジャイルソフトウェア開発宣言 >
→プロセスやツール 個人と対話 →ドキュメント ソフトウェア→契約の交渉 顧客との協調 →計画に従う 変化への対応
アジャイル開発とは
•何かひとつの開発手法を指すのではなく、この思想に沿った手法全般を示す
•学問的な観点からではなく、現場から生まれた手法がほとんど
•ベストプラクティスの集まり
ゲーム業界でも増えてきた
•2007年くらいから、ゲーム開発でも欧米を中心に採用例を聞くようになってきた(2003年くらいから採用されてきたという話も)
•GDC2007「Game Design in Agile Development 」2009「Advanced Scrum and Agile Development」などなど
主なアジャイル開発手法
•XP(エクストリーム・プログラミング)
•スクラム
•リーンソフトウェア開発
今日話すこと!
重要視するプラクティス
アジャイル開発の共通項
•イテレーション駆動(反復型開発)
•仕様を進化させる
•フィードバック/ふりかえり
イテレーション駆動(反復型開発)
アジャイルなマインド その1
サイクルの単位
リリースα ・ β版など
イテレーション1週間~4週間
日付単位1にちごと
リリース単位
イテレーション単位
日付単位
イテレーションとは
•開発行程における1サイクル
•ほとんどのアジャイル系手法では、1週間~4週間に定めている
•イテレーションの終わりには、常に評価出来る形で動作するソフトウェアが存在する
PDCAサイクル
マネジメントの基本となる考え方。
•Plan(計画 )•Do(実行)•Check(評価)•Act(改善)
Planから Actまで順番に行い、再び Planに戻る。こうして、継続的にカイゼンしていく。
Plan
DoCheck
Act
それぞれに対してPDCAを回す
リリースα ・ β版など
イテレーション1週間~4週間
日付単位1にちごと
リリース単位
イテレーション単位
日付単位
PDCA
PDCA
PDCA
イテレーションのタイムボックス化
•遅れによってずるずると引き延ばされると、泥沼プロジェクトと化す
•イテレーションは基本的に延ばさない(タイムボックス化)
•期間を延ばすのではなく、仕様を区切る→メリハリが生まれる
計画し続ける手法
イテレーションごとにPDCA
↓
アジャイル開発とはプロジェクト全般にわたって計画し続ける手法だった!
フィードバックを受ける
•イテレーションごとに制作チーム外(プロデューサーとか)からのフィードバックを受ける
•目に見える成果としてモノがあるので、判断しやすい
•進捗に安心できる
不確実性のコーン
time×0.25
×4.00 最初の見積もりは最低と最高に10倍以上の開きがある
実際に信頼できる見積もりは、プロジェクト中盤にならないと出てこない
↑開発スタート時
↑イテレーションX
イテレーションの利点
•変化に対応する!
•進捗のトレースがしやすくなる(実装計画が立てやすい)
•目に見える形でプロジェクトが進む
•パーキンソンの法則(学生症候群)を利用する
仕様を進化させる
アジャイルなマインド その2
よく聞く言葉
•「最初に完璧な仕様書を書いてから、実装していけば最短で良い物が作れる!」
•「最初に書く仕様書は出来る限り詳細に! 未定部分があると後で苦労する」
そんな風に考えていた時期が、私にもありました。
仕様は変わる方が自然
仕様が変わるシチュエーション
• 現行案よりいい案が出た→ 出る方が自然。むしろ出ないのはおかしい。
• ムジュンが見つかった→ 無い方が良いが、完璧な人間などいない。
• 市場の状況が変わった→ 1年もすれば、色々変わる。
• 環境の制限が変わった→ 会社的、人員的、予算的状況は常に変化する。
特にゲーム開発は・・・
•特にゲーム開発は、途中でいい案が浮かぶことが多い
•実際にそれを入れた方が良くなるのだったら、入れるべき
•もちろん、状況を考えてから決定を下す必要はある
ゲームにおける一番の欠陥
•ゲームにおける、一番の欠陥は何か?
面白くないことが一番のバグだ!
ゲームを面白くする方法
•トライ&エラーの積み重ねが、ゲームを面白くしていく
•つまり、仕様を進化させていくことこそが、ゲームを面白くする方法だ!
•「また仕様変更かよ」とぼやいてるヒマはない。仕様を進化させろ!
これからは仕様変更をこう言おう
•「へへ、また仕様が進化したZE!」
そのためのイテレーション
イテレーションで区切られていれば・・・
•イテレーションの区切りが仕様を進化させるタイミング
•常に動くソフトウェアを見て、仕様を検討できる
ふりかえり
アジャイルなマインド その3
ゲーム開発は実に非効率だ
•多くのゲーム開発は、何もしないと非効率な進め方になる
•ジャンルや作品の特徴ごとに、創るものが違うのだから当然のこと
アジャイル的な考え方
•プロジェクトの最中に、人/チームは成長していく
知識には2種類ある
•基本知識/技術仕様書作成能力やプログラミング能力、グラフィックセンスなど
•プロジェクト知識/技術プロジェクトに関する知識、専用ツールの技術、今回のチームメンバーと上手く連携を取るノウハウ。
両方の成長が期待できる(するべき)が、ふりかえりを行うと特に後者が伸びる!
ふりかえり
•PDCAのなかで、Checkが一番出来ていない項目
•重要だと判っていても、やらずに終わってしまう
•プロジェクトを進めるのには必須ではないが、チームが成長するには必須!
反省ではなくふりかえり
•よくプロジェクト終了時に行われる反省会とはすこし違う
•行うのは、反省ではなくふりかえり
•いいことは保つ、悪いことはカイゼンする、試してみたいことにチャレンジする
ふりかえり手法 ~KPT~
•ふりかえり手法「KPT」
•Keep/Problem/Try
•一番手軽で強力なふりかえりフレームワーク
ふりかえり手法 ~KPT~
Keep
Problem
・タスク管理が上手くいった(佐々木)・グラフィックチームとの連携(本間)・差し入れが美味しかった(佐々木)・ムダのないミーティング(田切)
・休日出勤が多かった(佐々木)・仕様書の抜けが多すぎた(田切)・実装プライオリティを間違えた(本間)
保っていきたい点と問題があった点を書き出す
媒体はなんでもかまわないがホワイトボードや付箋を使うと便利
ふりかえり手法 ~KPT~
Keep
Problem
・タスク管理が上手くいった(佐々木)・グラフィックチームとの連携(本間)・差し入れが美味しかった(佐々木)・ムダのないミーティング(田切)
・休日出勤が多かった(佐々木)・仕様書の抜けが多すぎた(田切)・実装プライオリティを間違えた(本間)・そもそも、見積もりが甘かった(佐々木)
Try・知識共有のため、 社内勉強会を開く(佐々木)・新しいソフト「 XXX」を試してみる(田切)
・仕様書レビュー会をしっかり開く
・タスク管理の項目に、 プライオリティを追加する
・タスクの見積もり結果を、 一度全員に見せてコミットしてもらう
最後に、Tryから実際に何をやるか決める
ふりかえりをチームで行う利点
•抱え込んでいた不満点やアイディアを放出する場になる
•意見をぶつけ合うことが出来る
•良かった点と悪かった点を明確に意識/共有できる
プロジェクト中にふりかえることが大事
•プロジェクト知識・技術が溜まる
•プロジェクト中に振り返ることにより、Try項目をすぐに実行に移せる
•人/チームが進化していく!
アジャイルな考えはどこでも通用する
今回紹介したもの
•アジャイルの基盤イテレーション駆動
•面白さを生み出す進化する仕様
•チーム/人が成長するためのふりかえり
柔軟な思考を持つ
•プロジェクトは生もの
•柔軟な思考で対応する
•変化を受け入れる
アジャイル開発手法は使えない場合も
•XPやスクラムなどの開発手法は、プロジェクト/チームメンバーによっては適さない場合もある
•しかし、今回語った思想の部分は、どんなプロジェクトでも重要な役割を果たす
最後に・・・
Agileとは
そして、もう一つのAgile
•Agile イキイキとした
イキイキとしたクリエイティブライフを送りましょう!!