スクラムプロジェクト準備(公開用) No.31

2,064 views

Published on

スクラムプロジェクトをはじめるための準備についてみんなと考えてみようというセッションです。

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,064
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • すくすく始めての人?\n数回ぐらいの人?\nたくさんの人\nアジャイルやってる人?\n\n
  • 今日はクリエイティブにいろいろ遊んでみましょう。\nどんな人がきてるの?\n スクラムをよくわかている方、わかっていなかた、\n \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 効果的:Effective\n非効果的:Ineffective\n
  • 相手の向こう側にどういう背景があるのかを、知ることで「理解」がうまれる。\n固定的な赤コミュニケーションが問題。 一時的なものは健康的なぶつかりあい。\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • だれが偉いというのはないと思うんです。\n講師がえらい?参加者が偉い?\n
  • \n
  • \n
  •   ・事前準備どうやって現場でやっているかを出してもらう(ポストイット)\n  ・ふりかえって、どう改善できたかを考えて出してもらう\n  ・お題のプロジェクトを出して、それに対しての準備をグループでやってもらう\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Agile2009でのセッション\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 言語がかわったり、実装方針、コンポーネント分け方の方針、フレームワークの選択\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • なんでもかんでもやらない。 コンテクストにあわせてあるていどプラクティスを選択する。\n
  • \n
  • \n
  • \n
  • アジャイルPJにはプロジェクト自体をつくるというメタプロジェクトの側面がある。準備は前後関係の依存が強い。\n
  • アジャイルPJにはプロジェクト自体をつくるというメタプロジェクトの側面がある。準備は前後関係の依存が強い。\n
  • アジャイルPJにはプロジェクト自体をつくるというメタプロジェクトの側面がある。準備は前後関係の依存が強い。\n
  • \n
  • \n
  • どんなに良くできたメソッドでも、誤用可能だということ。 悪意的に見ようとすればどんなメソッドも悪く解釈することが可能だ。コンテクストに合わせて、うまく使おうという動機なしでは成功率は下がる。\n
  • \n
  • \n
  •   ・話を聞いた後でお題プロジェクトの内容で改善すべき点が無いかグループで議論して頂く\n
  •   ・話を聞いた後でお題プロジェクトの内容で改善すべき点が無いかグループで議論して頂く\n
  •   ・話を聞いた後でお題プロジェクトの内容で改善すべき点が無いかグループで議論して頂く\n
  • 制約のないところでアイディアを考えたあとに、制約にあわせてどうするかを考えた方が、よいアイディアがでる。\n
  •   ・グループ単位で発表して頂く\n
  • \n
  • スクラムプロジェクト準備(公開用) No.31

    1. 1. No.31すくすくスクラムセントラルソフト株式会社 事業推進部 課長 スプリントぜろ!
    2. 2. クリエイティブな仕事したい人? 2
    3. 3. 自己紹介 3
    4. 4. 自己紹介•楽器メーカーで開発業務 5年•陶磁器の卸 父の会社を継ぐ 2年•鉄道関係の研究開発 2年•シンセサイザーオペレータ 1年•ネットワーク保守業務 1年•現職 ただいま15年目ぐらい 3
    5. 5. やってきたもの(開発)
    6. 6. やってきたもの(開発)• 電子楽器の開発 • ドラムマシン、エフェクター、カラオケアンプ• 鉄道関連 • デジタルATS、リニアモーターカー運行システム• フレームワークの開発 • IOCコンテナをベースとしたJavaとVBをシームレスにつなくコン ポーネントフレームワーク• 業務アプリ • 大規模基幹業務開発、標準化、方式設計 • 大規模基幹業務向けEJBフレームワークの開発 • 物流系、薬局関連、製造業関係• 音響制御系 • サラウンドミキサー装置 →愛地球博NHKパビリオンで上映
    7. 7. 現在• 教育プランニング、受託開発• スクラム導入支援、コーチング技術を使ったトレーニング• すくすく・スクラム スタッフ• NLP認定プラクティショナー• 認定スクラムマスター、プロダクトオーナー• 要求開発アライアンスコアメンバー• DCFA認定ドラムサークルファシリテーター MOTO$$ Beat$of$Success• BOSサポートメンバー(トレーニングビート) Beat$of$Success T.G.P.% http://www.bos1.org• Cloudera Hadoop認定デベロッパー• BCB認定ファシリテーター
    8. 8. トロントAgile 2008(ドラムサークル) EM ZERO Vol.2 XP祭り 2009 (リズムと朝会)XP祭り 2008 Thanks チームの皆へ 送り出してくれた人達へ(リズムとファシリテーター育成)今日聞いてくれた人達へ (撮影KKD)要求開発アライアンス DevLove TFPモデリングスペキュレーション 2007年 人とのつながりの奇跡に感謝(2008 LT) 要求開発マスター認定制度への提案 2008年 すくすく・スクラム スクラム基礎+朝会ワークショップ スクラムと要求開発 2011/05オブラブ 自己組織化ワークショップ ドラムサークルとプロジェクトファシリテーション(2007/06LT) ウォーターフォールとアジャイル 短期に低価格で持ち家建設を行うためのパターンランゲージ(2009/01 LT) リズムと朝会( 名古屋) スクラム入門、ドラムサークルチームビルディングセッション(2010/07) スクラム入門、朝会ワーク(大阪)マイクロソフト TechEdDay 振り返りの基礎はこれだ スクラム導入どたばた事例  2010/08 振り返りってなんだ( 岡山)マイクロソフト AgileDay4 モチベーションマネジメント入門 自己組織化のためのNLPをつかったコミュニケーションワークスクラム道 ファシリテーション入門だ! スプリント0探求ワークショップ(2011/02) 心理学を使ったスクラムチームのコミュニケーションパターン分析ワークスクラムギャザリング東京 ショップ(XP祭り2011) スクラムの心 ワークショップ(2011/10) タスクカンバンはこれだ!(2011/10) 同再演 2011/12
    9. 9. 現在心理学手法を使ったアジャイル導入プログラムを鋭意開発中!【アジャイル導入プログラムの開発メンバー】(五十音順) • 牛尾 剛さん (シンプルアーキテクト 代表) • 梅本 和比己さん (株式会社チーム医療 代表取締役、 NLPトレー ナ) • 大久保 透さん (株式会社チーム医療 NLPトレーナー) • 林 栄一さん (セントラルソフト株式会社) • 本橋 正成さん (合同会社カルチャーワークス) • 吉羽 龍太郎さん (株式会社ICI)
    10. 10.  自我状態 ∼自己の行動を理解する∼ 周囲に厳しく/厳格/責任感/けじめ /偏見/圧力 C   P  P 親の自我周囲に優しく/保護的/思いやり/配慮/ NP心づかい冷静/客観的/合理的計画的/役割的 A A 大人の自我 NC感情的/明るい/直感的/行動的/自由天真爛漫 LP CC C 子供の自我 RC 感情的/暗い/内省的/従順/消極的 感情的/反抗的/破壊的/衝動的9 BCBトレーナー大久保氏の資料より一部抜粋
    11. 11. ユーザー プロダクトオーナー スクラムマスター チーム ファシリテート ファシリテート お願い 自己組織・振り返り ヒアリング 要求 デモ A バックログ ヒアリング 励まし・巻き込み 自己組織・振り返り 連帯 信頼 連帯 連帯 まだまだ、たくさん線 を引くことができます。 10
    12. 12. ニューロロジカルレベル スピリチャリティー アイデンティティ―   価値観 信念 能力 行動 環境
    13. 13. すくすく・スクラム2009年4月から東京で始まった。月に1回、関連講演者やスタッフがリード4ヶ月に1回振り返り月参加費無料すくすくスクラム瀬戸内 2010年2月開始 すくすくスクラム大阪 2010年6月開始20回の勉強会を実施スクラムアライアンス登録ユーザーグループ  12
    14. 14. すくすく・スクラムイベント実績 すくすくスクラム2009年 – 4月23日 第1回 クリエイティブ朝会 林栄一(東京都) – 5月28日 第2回 スクラム基礎、開発者兼経営者     林栄一氏、エマーソンミルズ氏(東京都) – 6月25日 第3回 自己組織化ワーク 林栄一(東京都) – 7月23日 第4回 カンバンゲーム 安井力氏(東京都) – 9月16日 第5回  壁はスクラムで乗り越えろ     榎本氏(東京都) – 10月21日 第6回  デザイナー気分でAgileUX     加納氏(東京都) – 11月25日 第7回  チームとは何だ?!     エマーソンミルズ氏(東京都) – 12月19日 "TDD" Boot Camp  "TDD" をつかめ!    Lasse Koskela氏、和田卓人氏(東京都)• XP祭り – 9月19日 Lets クリエイティブ朝会ワークショップ 林栄一氏 (東京都) 13
    15. 15. すくすく・スクラムイベント実績 すくすくスクラム2010年 – 1月25日 第8回  1人1人がリーダーだ! 今村氏(東京都) – 2月4日  第9回 IN広島Catch The Scrum エマーソンミルズ氏(広島県) – 2月7日  第10回  in 名古屋 朝会を極めろ 林栄一氏(愛知県) – 2月25日 第11回 ユーザーストーリーはこう書け! 角 征典 氏(東京都) – 3月24日 第12回 PFとは何だ?! PFを体感しよう! 松本潤二氏(東京都) – 4月25日 第13回 IN大阪スクラムを体感しよう第一弾 江端一将氏(大阪府) – 5月27日 第14回  スクラムの落とし穴はどこだ?! 西村氏、安井氏(東京都) – 5月29日 第15回 IN大阪第2弾スクラムを体感しよう 江端一将氏(大阪府) – 6月21日 第16回  これが、ユーザ行動モデリングだ!  本徹也氏(東京都) – 7月28日 第17回 ふりかえりの基礎はコレだ! 林栄一(東京都) – 9月29日 第18回 私がみたAgile2010はコレだ!? 細澤あゆみ氏(東京都) – 10月25 日 第19回 Scrum &kanban 江端一将氏 – 11月29日 第20回 事例から探求する改善への一歩 豊田氏• オブジェクト倶楽部 夏イベント – 7月16日 スクラムワークショップ 今村哲也、川口恭伸、林栄一 14
    16. 16. すくすく・スクラムイベント実績すくすくスクラム2011年– 1月28日 第21回 ほいほいモチベーションアップ! 林 栄一(東京都)– 2月18日∼19日 デベロッパーサミット ブース出展– 2月21日 第22回 ここから始めるImpediment探求 zuisener氏(東京都)– 5月27日 第23回 ゲームで学ぶスクラムの概要 海江田氏(東京都)– 6月25日 勉強会カンファレンスブース出典、パネル出演– 第24回 ファシリテーション入門だ! (林 栄一)– 第25回 プロダクトオーナー探求(ユッカ氏)– 第26回 みんなで朝会をより良くしよう!(スタッフ一同)– 第27回 タスクカンバンはこれだ! (スタッフ一同)– 第28回 振り返り探求(スタッフ有志)すくすくスクラム2012年– 第29回 プロジェクト逆計画ゲーム (安井 力氏)– 第30回 Head First インセプションデッキ(西村 直人氏) 15
    17. 17. すくすく・スクラムイベント実績すくすくスクラム大阪 2010 年 6 月 16 日 第1回 ∼スクラム基礎理論∼ 林栄一 (大阪府)すくすくスクラム瀬戸内 2010 年 2 月 5 日 第1回 ソフトウェア開発の3つの嘘  江端一将氏、今村氏、林栄一、 エマーソン ミルズ氏 4 月 24 日 第2回 身体でおぼえるスクラム  エマーソン ミルズ氏 12月25日 第3回 振り返りワークショップ(年末振り返り特別版)    林 栄一すくすくスクラム瀬戸内 2011 年 4月15日 Agile Japan 2011 岡山サテライト 安井力氏他すくすくスクラム仙台 2011 年 ファシリテーション超入門 7/27 江端氏 みんなで朝会をより良くしよう! 10/7 16
    18. 18. 勉強会?みんなが集う場所 お互いを知りあう知識を共有
    19. 19. 演目起 承 転 
    20. 20. 心得全員が価値を得られるようお互いをサポート新しい知見やアイディアを創りだすこと参加者が現場に帰って行動する勇気を得ること
    21. 21.
    22. 22. グループワーク ココに模造紙 書く 参加の目的 他のメンバーの人 は、共感できることが あったらその横に★印 を書いてください
    23. 23. 事前準備どうやって現場 でやっている?
    24. 24. ・業務運用管理,利用部門支援,システム運用,運用管理,システム保守の方法を確認。ステム運用・保守 OM ・トラブル・Q/A対応,ネットワーク,ハードウェア,ソフトウェア,アプリケーショ の変更管理を実施し,改善計画を立案。 富士通のSDEM 運用・ 保守 企画プロセス 開発プロセス プロセス 工程 情報化 システム システム ユーザインタ システム プログラム プログラ プログラ 結合 システム 運用 システム 構想立案 企画 方式設計 フェース設計 構造設計 構造設計 ミ ング ムテスト テスト テスト テスト 運用・ 保守 カテゴリ VP SP SA UI SS PS PG PT I T ST OT OM 企業 企業 業務 業 務 業 務 利用者による妥当性確認 業 務 設計者による検証 業務 システム システム システム ・ ・ 開発者による検証 ・ プロセス プロセス 分解の過程 プログラム 統合の過程 (設計) ( テスト) モジュール 図-2 品質保証のV字モデル Fig.2-V model for quality assurance.
    25. 25. 表-1 工程の定義 情報化構想立案 VP ・情報化戦略を策定し,実行の優先順位を決め,中長期計画を策定。企画 システム企画 SP ・業務システムの現状分析と要件定義を行い,投資効果を評価し,開発の意思決定。 ・システム化に対する要件を確認し,業務分析によりシステム化の範囲を確定。 システム方式設計 SA ・システム方式設計と実現性の検討を行い,プロジェクト開発計画を立案し,プロジェクト運営の ための管理方法を準備。 ・業務システム仕様(プロセス機能,データ構造,画面,帳票)を設計。 設 ユーザ UI ・システム方式設計の詳細化,および運用・移行方法を設計。 計 インタフェース設計 ・全体テスト計画を立案。 ・プロセスをプログラムに分割し,システムの内部構造を確定し,共通プログラムを設計。 システム構造設計 SS ・運用管理システム,セキュリティシステム,移行ツールを設計。 ・システムテスト計画,運用テスト計画を立案。 プログラム構造設計 PS ・プログラムの構造を決め,ロジックを定義。開発 製 プログラミング PG ・プログラム構造設計に従ってプログラムを作成し,動作を確認。 造 プログラムテスト PT ・プログラムテスト仕様に従ってテストを実施し,品質を検証。 ・プログラムを結合して,プロセス単位のテストを実施し,品質を検証。 結合テスト IT ・外部システムとのインタフェースを含むすべてのプロセス間のインタフェーステストを実施。 ・必要に応じて結合レベルや処理形態例(オン/バッチ)でIT工程を分割。 テ ・実機上で業務システム機能をテスト。 ス システムテスト ST ト ・性能,信頼性,運用性,セキュリティなど,システム全体の検証を実施。 ・実機,実環境,本番データで,利用者による仮運用を実施。 運用テスト OT ・業務システム機能,性能,信頼性,運用性,セキュリティなどの妥当性を確認。 ・本稼働への移行の意思決定を行い,業務を移行。 ・業務運用管理,利用部門支援,システム運用,運用管理,システム保守の方法を確認。運用・ システム運用・保守 OM ・トラブル・Q/A対応,ネットワーク,ハードウェア,ソフトウェア,アプリケーション使用など保守 の変更管理を実施し,改善計画を立案。 運用・ 保守
    26. 26. 要求開発(OPENTHOLOGY) 要求の4象限 戦略 オペレーションビジネス ビジネス ビジネス戦略 オペレーション 表(価値) 裏(実現) 表(価値) 裏(実現)システム システム要求 システム設計 表(価値) 裏(実現)
    27. 27. 開発プロセスオーバービュー 要求開発(OPENTHOLOGY)  広義の要求開発(要求定義) 狭義の要求定義 BDA 経営分析 要求開発 広義のシステム開発 ビジョン、ミッションの 確立 問題点分析 準備 立案 デザイン 移行 ビジネスゴール設定 狭義のシステム開発 ビジネスユースケース システム開発 システム化範囲の導出 財務的解決やマーケ 業務フロー(As-Is、To-Be) 方向付け 推敲     構築      移行 ティング的解決で終わ ロードマップ作成 業務レベルの概念モデル る課題もある システムユースケースの 抽出と個別プロジェクト へのブレークダウン 第1 プロジェクト 方向付け 推敲     構築      移行 ビジネス戦略の見 える化、プロジェク トスコープとリソー 業務要求の獲得 スを確定しゴール とプロセスの見え 第2 プロジェクト を明確化。 る化、ITの基本要 方向付け 推敲     構築      移行 求の獲得。 狭義のプロジェクト 第3 プロジェクト 広義のプロジェクト
    28. 28. 要求開発(OPENTHOLOGY)  モデルの役割(Ver1.0)観点の ビジネス課題 ビジネス・オペレーション システム要求 システム設計 流れ 業務プロセスからIT要求へ プロセスモデル サービスモデル ・業務フロー ・システムユース  ケース 戦略モデル サービスモデル アーキテクチャモデル ・BSC戦略 ・ビジネス  マップ  ・ERD/DB設計  ユースケース ・IT貢献度  マップ 情報モデル  ・アーキテクチャモデル ・プロジェクト  ゴール記述書 TFP分割手法  ・SOAモデル  ・Thing図  ・Function図  ・Place図 ビジネス概念からITアーキテクチャへ要求開発フェーズ 準備 立案 デザイン シフト システム開発フェーズ
    29. 29. グループワーク模造紙 参加の目的 ココに 書く うまく行かなかったPJ 他のメンバーの人 は、共感できることが あったらその横に★印 を書いてください
    30. 30. 事前準備どうしておけば よかった?
    31. 31. グループワーク ココに模造紙 書く 参加の目的 どんな準備しておけばよかっ た?プロジェクト準備? 他のメンバーの人 は、共感できることが あったらその横に★印 を書いてください
    32. 32.
    33. 33. スプリント0とはリリースバーンダウン 100 75 50 25 0 SP0 SP1 SP2 SP3 SP4
    34. 34. http://www.infoq.com/jp/articles/skills-for-scrum-agile-teams コーディングを開始し、チームの 作業を統合するために、スプリン ト0では、開発者に必要な環境構 築に関することはどんな小さなこ とでもすべて文書化する必要があ ります。
    35. 35. http://www.infoq.com/jp/news/2008/09/sprint_zeroスプリント0の是非
    36. 36. http://www.infoq.com/jp/news/2008/09/sprint_zeroDanubeのシニアコーチであるDan Rawsthorne氏はチームを始動させる方法として使っている。1.プロダクトバックログで項目をいくつか選ぶ。2.品質を満たすコードの記述を可能にする最低限の環境 を提供する。3.いかに小さくとも、実コードを記述する。ただし、できるだけ期間を短く。一週間を推奨。
    37. 37. http://www.infoq.com/jp/news/2008/09/sprint_zeroMark Woyna氏は、スパイクとしてスプリント0を使用する。以下を計画に関するスプリント0の成果とする。1.予測付きのすべての優先度づけされたストーリー2.ストーリーをスプリントに割り当てるリリース計画3.高水準アプリケーションアーキテクチャ 機能が実装、変更しやすい方法を選択可能なはず
    38. 38. http://www.infoq.com/jp/news/2008/09/sprint_zero「スプリント0は、最初のスプリントに先立って発生する計画を説明するときに、誤使用されるフレーズとなった」 Ken Schawber氏 @kawaguti 作
    39. 39. http://www.infoq.com/jp/news/2008/09/sprint_zero「スプリント0などない!」 Jim Coplien氏
    40. 40. ジェフサザーランドのCSPO(研修)での準備完了の条件 • ステークホルダが明確 • ステークホルダの目標が明確 • ビジネス状況が把握できている • 成功の基準が明確 Discovery flow Product Owner “Re + Vision Discovery Sessions Product Backlog items ~3 days to 3 weeks created Product Backlog Prioritised and “ready” Who the • 実装戦略ができている Brings in the Who, why, what Cross-functional Team Wha Estimated by the team Product Owner `````````````````` 1 2 3 Wha E S 4 UR AT 5 FE You 6 7 Release plan created 8 esti • PBLの粒度が適切 9 10 11 12 min Product Backlog 93 Q1 Q2 Q3 93 発見の流れ • PBLは価値最大、リスク最小で優先づけ プロダクトオーナー + ビジョン 発見セッション 3日間以下∼3週間 プロダクトバックログ項目 の作成完了 プロダクトバックログの優 先度付け完了と 準備完了 準 利害 状況 クロスファンクショナル だれが, なぜ, なにを どう チームに引き渡す チームによる見積もり プロダクトオーナー `````````````````` 1 2 実装 3 E S 4 UR プロ AT 5 • PBL=プロダクトバックログ FE 6 価値 7 リリースプランの作成完了 8 9 いま 10 11 12 プロダクト バックログ 94 第1四半期 第2四半期 第3四半期 94
    41. 41. xUNIT TEST Patterns の著者Gerard Meszaros氏From Concept to Product Backlog What Do You Need to Get StartedConcept Backlog Story User Tests ??? Stories Iteration Budget 1 Plan Tech Staffing Business StaffingMuchAdo2010 Tutorial 20 Copyright 2008-2010 Gerard Meszaros
    42. 42. From Concept to Product Backlog What We Needed to Get StartedConcept Backlog Product Product Project Envisioning Planning Execution Risks Release Story Major Plan User Tests Features Benefits Stories Product Iteration Design Budget 1 Plan Effort Cost Product Estimate Estimate Tech Arch. Staffing Skills Business Test List Staffing Strategy An incomplete set; you may need other things too!MuchAdo2010 Tutorial 21 Copyright 2008-2010 Gerard Meszaros
    43. 43. Beyond Sprint Prioritize possible outcomes, not output Zero Product Goals ?51-2"@,//*A,0*B6")0,7;<4" (Name desired =15<,60C"4,")/*-":21/" outcomes) )0,D<45 User Constituencies Targetpeople that will to maximize (The solution outcome, business output not use some solution to meet goals) !"#$%&() :21/)0,7;<4=512-9<,> DE*+,-F*<>9,02 Activities & 481+0G""D(E*+,- Tasks !"#$$%"&(")*+,-."*//"012345"05067."8889:21/)0,7;<4=512-9<,> H (performed by users using software) !"#$$%"&(")*+,-."*//"012345"05067."8889:21/)0,7;<4=512-9<,> ?@!"#$$%"&(")*+,-."*//"012345"05067."8889:21/)0,7;<4=512-9<,> ??
    44. 44. インセプションデッキワークショップ形式でチームとユーザーと一緒に作る意識付け、動機づけ、チームビルディングができる隠れた意図を引き出すコミュニケーションツールコンセプトの共有方向性を明確にする
    45. 45. プロジェクト憲章(PMBOK)・顧客やステークホルダからの要求事項・プロジェクトの目的・プロジェクトの成果物・スケジュールの概要・予算の概要・主要ステークホルダの関与とその影響・プロジェクトを遂行する上での前提条件・制約条件
    46. 46. それぞれの位置 目的 いつ? 誰インセプション PJ全体像、方向性 チームの開発が ユーザー、チー デッキ を明確にする スタートする前 ム、PO,SMプロジェクト憲 目的を明確にし認 PJが正式開始す 営業、PL 章 可してもらう る前 要求を見える化し システム化プラ ユーザー、コン 要求開発 開発する ンを作るまで サル
    47. 47. アジャイルがうまくいく のは?
    48. 48. スイートスポット7 - 15 人 1 か所に所在専任社会-技術的システム → 人間とシステムが密に相互作用するシステム安定したソフトウェアアーキテクチャ安全性への要求が低から中上の人たちとの友好的な環境新規開発 フィリップ・クルーシュテン博士の「アジャイ ルは単に廃れつつある流行語なのか ? 」セミナー 2009/12/12
    49. 49. アーキテクチャジャンプ 酷いときは言語がかわったり、実装方針やコン ポーネント分け方の方針が変わったり、フレームワークが変 わったり
    50. 50. アーキテクチャジャンプ利点欠点
    51. 51. アーキテクチャジャンプ システムが進化する 規模大きくなってもシンプルさを利点 維持できる 最適なアーキテクチャを探索欠点
    52. 52. アーキテクチャジャンプ システムが進化する 規模大きくなってもシンプルさを利点 維持できる 最適なアーキテクチャを探索 作り直しのリスク欠点 一時的に価値を提供できなくなる
    53. 53. アーキテクチャジャンプ許せるレベル、ゆるせないレベルがあるのではないか?許せる規模、時期、その判断基準は?ジャンプ発生がなるべくリスクにならないようにベースアーキテクチャや実装戦略を設計できるか?
    54. 54. シンプルデザインとリファクタリ • リファクタリングによって機能密度が上 がる アーキテクチャ・ジャンプ LOC = コード行数 FD = 機能密度 = (functionality/LOC) FD = 1行あたりの機能量 リファクタリングが 有効に作用しているLOC 時間,機能 2001/3/22 ©2001, Kenji HIRANABE 51
    55. 55. リファクタリングと勇気 • アーキテクチャ・ジャンプには勇気が必 要 局所解 コンテキスト アーキテクチャ・リファクタリング ジャンプ 原子のエネルギーエネルギー 準位のようにギャップがある。 一つ上のレベルに行くにはリファクタリングコストがかかる。 2001/3/22 ©2001, Kenji HIRANABE 52
    56. 56. 林がSP0として決めたことアーキテクチャジャンプのリスクを最小にする環境の準備を完了する基本的なトレーニングを完了するビジネス価値を提供しないスプリント大まかにプラクティスを選択しプロセスを設計するプロジェクトをとりまく状況を、アプリレベルとプロジェクトそのものレベルでモデル化し見えるようにする
    57. 57. メタプロジェクト体制を定義
    58. 58. メタプロジェクト定義
    59. 59. スプリント0
    60. 60. プロジェクト自体の要求分析ツリー SP0は順番の依存高
    61. 61. プロジェクト自体の要求分析ツリー スプリント0 SP0は順番の依存高
    62. 62. プロジェクト自体の要求分析ツリー スプリント0 スプリント1..* SP0は順番の依存高
    63. 63. プロジェクト自体の要求分析ツリー PJ振り返り スプリント0 スプリント1..* ゴール評価 SP0は順番の依存高
    64. 64. プロジェクトの要求をとりまく状況をモデル化全員が直感的に把握出来る状態に
    65. 65. プロジェクトの課題を課題分析ツリーで分析 課題 解決案 リスク
    66. 66. 時間割カンバン ワーク ショップや勉強会を1日 3コマの時間割で管理
    67. 67. コンテクスト 規模 計画ゲーム 深刻度 スプリント期間 実リリース頻度 変化率 DOD システムの寿命 選択 バックログ ビジネスモデル 調整 CI ドキュメントどこまで アーキテクチャの安定度 適合 品質 統率 訓練 デイリースクラム ロール設計 組織の理解 TDD チームの経験度 ペアプロ オフィス環境 見える化モノフィリップ・クルーシュテン博士の「アジャイ ルは単に廃れつつある流行語なのか ? 」セミナー 2009/12/12 から加筆
    68. 68. 観点アーキテクチャジャンプのリスクDODをいつどうやって決めるかプロセスや役割をどう決めるか環境やツールの選定や準備ビジネス価値を提供しないスプリントの是非チームビルディング目的、コンセプトの共有要求の正当性
    69. 69.
    70. 70. 準備に1ヶ月もらえるとしたら?
    71. 71. 観点チームビルディングトレーニングアーキテクチャプラクティスプロセス開発環境等、、、
    72. 72. グループワーク ココに模造紙 書く 参加の目的 どんな準備しておけばよかっ た? 準備に1ヶ月もらえるとしたプロジェクト準備? ら?
    73. 73.
    74. 74. 結論的ななにかどんなに良くできた手法も、誤用可能。悪意的に見ればどんな手法も悪く解釈することが可能。コンテクストに合わせて、うまく使おう

    ×