アジャイルなマインドで行こう! Web

1,573
-1

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,573
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

アジャイルなマインドで行こう! Web

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

    Clipping is a handy way to collect important slides you want to go back to later.

×