Your SlideShare is downloading. ×
Xp祭り2013
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Xp祭り2013

504
views

Published on

XP祭り2013での発表資料です。

XP祭り2013での発表資料です。

Published in: Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
504
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 1 モデリングからはじめる アジャイルへの第一歩 UMLモデリング推進協議会(UMTP) アジャイル開発部会 ネットイヤーグループ㈱ 小倉 英一郎 中菱エンジニアリング㈱ 古川 剛啓
  • 2. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 2 目次 • UMTP紹介 • なれる!アジャイルなエンジニア モデリングで始められる!? (もっと)アジャイルなチームづくり (ガイドライン紹介) • 要求導出へのモデリング技術とアジャイル プラクティスの適用 (ガイドライン紹介)
  • 3. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved UMTP/Japanとは • Consortium for UML based Modeling Technologies Promotion Japan (会長 上野南海雄 ジャパンシステム(株)監査役) • 2003年5月19日設立、NPO法人 • 設立発起人:21団体個人: IBM-japan、HITACHI、FUJITSU、NEC、TOSHIBA、NEXS,NTT Data、Suntory 、Oracle-japan、 Sunmoretec、CATS、Technologic Arts、Toyo Technica、Unisys-japan、Rational Software-japan、 NRI 、Mamezou、Aithent Inc. Japan.、Learning Architecture研究所、Horiuchi(Tokyo International University)、OGIS-RI • 会員数:38団体・個人(2013年8月現在) • 目的(事業) * モデリング技術の研究活動 * モデリング技術の普及 * 認定事業:技術者認定試験、コンテンツの認定 * アジアを中心とした国際連携 3
  • 4. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 活動内容 • UML用語集の策定 Eng/Chn/Jpn • UML技能認定試験 • 書籍、トレーニングテキストの認定 • モデリング技術の開発 オフショア開発へのUML適用、 組込モデリングカタログの作成、 アジャイル開発とモデリング、etc. • モデリングフォーラム 東京 , 2004 ~ • 各種セミナーの開催: • 国際連携:セミナー開催、認定試験 0 5000 10000 15000 20000 25000 30000 35000 0 100 200 300 400 500 600 700 800 04/04 04/07 04/10 05/01 05/04 05/07 05/10 06/01 06/04 06/07 06/10 07/01 07/04 07/07 07/10 08/01 08/04 08/07 08/10 09/01 09/04 09/07 09/10 10/01 10/04 10/07 10/10 11/01 11/04 11/07 11/10 12/01 12/04 12/07 12/10 13/01 13/04 受験者数累計 月間受験者数 UMTP認定試験受験者数 4
  • 5. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 5 アジャイル開発+UMLの事例セミナーの様子 2012年3月28日 ㈱チェンジビジョン 平鍋氏
  • 6. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 6 2012年11月29日 楽天㈱ 藤原氏 2013年2月25日 NECビッグローブ㈱ 松浦氏 6 アジャイル開発+UMLの事例セミナーの様子
  • 7. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 7 2013年8月27日 合同会社カルチャーワークス 本橋氏 他団体(IPA)との交流(セミナー)の様子
  • 8. なれる!アジャイルなエンジニア モデリングで始められる!? (もっと)アジャイルなチームづくり (ガイドラインの紹介) Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 9. UMTP-L3 OCUP Advanced Scrum Product Owner Information Security Specialist Eiichiro Ogura Technologist Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 10. ウォーターフォールと アジャイル Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 11. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ウォーターフォール開発 細かく全てを事前に決定していく
  • 12. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ウォーターフォール開発 手戻り… 最初から
  • 13. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ウォーターフォール開発 むりやり仕様変更… がっかり品質
  • 14. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved アジャイルなソフトウェア開発 イテレーション単位でビジネス価値を届ける
  • 15. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved アジャイルなソフトウェア開発 遠いものは粗々でも大丈夫
  • 16. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved アジャイルなソフトウェア開発 まだ作ってないものは変えても大丈夫
  • 17. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 違いがたくさんある… • 作る順番 • 何がプロセスを駆動するか • 成功の定義 • 変更がプロセスに与える影響 など
  • 18. モデリングで取り扱う概念 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 19. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 粒度 取り扱う事物には大きさがある Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 20. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 複雑さ / 簡潔さ 適宜まとめなおすことで簡潔に取り扱う
  • 21. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 静的 / 動的 構造と相互作用を区別する
  • 22. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 静的 / 動的 構造と相互作用を区別する
  • 23. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 抽象 / 具象 具体的なものの背後にある抽象性を取り扱う アルコール カクテル 容器 グラス ボトル
  • 24. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 抽象 / 具象 具体的なものの背後にある抽象性を取り扱う 【容器】 カクテルグラス 【カクテル】 グラスホッパー クレームドカカオ ホワイト ミント リキュール 生クリーム
  • 25. なぜモデリングスキルが重要? Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 26. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。
  • 27. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 著者 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
  • 28. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 彼らが提唱・利用していたもの • オブジェクトモデリングを全面的に組み込んだ開発プロセス Steve Mellor / Shlaer-Mellor method Jon Kern / Coad/Yourdon method Robert C. Martin / Booch method • インクリメンタルで変化を受け入れる開発プロセス Arie van Bennekum / DSDM Jim Highsmith / ASD Alistair Cockburn / Crystal Clear Ken Schwaber & Jeff Sutherland & Mike Beedle/ SCRUM • パターンを用いたオブジェクトモデリング Ward Cunningham & Kent Beck / Using Pattern Languages for Object-Oriented Programs Martin Fowler / Analysis Pattern
  • 29. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved アジャイルとモデリングの関係 • アジャイルソフトウェア開発宣言の著者らのベ ーススキルとして、オブジェクト指向(を用いた モデリング)やインクリメンタルな開発プロセスが ある • アジャイルソフトウェア開発宣言のベースライン としてオブジェクト指向やモデリングがある • モデリングを理解することで、アジャイルなソフト ウェア開発を円滑に進めることができる
  • 30. アジャイルなソフトウェア開発 パターン Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 31. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved パターン名 フォース 解決 コンテキスト 問題
  • 32. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved パターン名 フォース 解決 コンテキスト 問題
  • 33. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 後から設計する 設計について知っているので、 改善できることを知っている。 設計に対する知見があること で、実装中も常に設計を改善 することができる。実装しなが ら設計を改善することで、コー ドの一貫性を維持し、モデルを 明快に保つことができる。 設計はほどほどにして、動くコ ードを作り始めた。 コピペやトランザクションスクリ プトで実現している機能がたく さんある。
  • 34. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 必要最小限のドキュメント 成果物の中に設計文書が定 義されていないため、作る理 由がない。 ドキュメントを省いて、開発が 難しくなるのであればそれは本 末転倒。プレーンテキストや写 真でよいので、チームにとって 有益なドキュメントやモデルを 作り共有する。 アジャイルなソフトウェア開発 プロセスを採用しており、全員 コードを書いている。 ドキュメントがないせいで、逆に 開発がやりにくい。
  • 35. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ほどほど 全ての情報が事前に手に入る わけではない。先のことは誰に も分からない。 分からないものを頭で考え抜 いても、それが正しいか分から ない。分かるところまではしっ かりと考えるが、そこから先は ざっくりとしか見通さない。 ソフトウェアアーキテクチャに関 係する事柄なので、ある程度 しっかりと考えて作りたい。 どこまで作るべきなのか分から ない。
  • 36. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 2段階の開発 作るものが事前に明らかにな っている部分があり、そこは変 更を前提にする必要がない。 何を作るのかが事前に明らか であれば、そこはウォーターフ ォールで作る。出来上がった 成果物を利用し、残りをアジャ イルで完成させる。 システム全体で使う共通的な モジュールがあり、その上にビ ジネスモデルを構築する。 共通モジュールをアジャイル で作るのはかえって効率が悪 いような気がする…
  • 37. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 失敗とは書かない 失敗には区別がなく、すべから く悪い失敗であると認識される 文化がある。どんなことであれ 、失敗だと表現することが不利 益になる。 Problemに失敗したことは書か ない。理由や原因だけを書き 、成功か失敗かは文面からは 読み取れないようにする。 KPT(Keep, Problem, Try)を使 って振り返りをしている。 Problem(問題)に失敗したこと を書きたくない。
  • 38. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 今日はここまで パターンの残りを含めた、ガイドラインの全文は 来年3月に公開予定です。
  • 39. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ご清聴ありがとうございました
  • 40. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 40 要求導出へのモデリング技術と アジャイルプラクティスの適用 (ガイドラインの紹介) Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 41. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 41 自己紹介 ふるかわ よしひろ 古川 剛啓 中菱エンジニアリング㈱ UMTP L3モデラー OMG Advanced 認定スクラムマスター UMTP アジャイル開発部会メンバ 名古屋アジャイル勉強会スタッフ
  • 42. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 42  昨今、ソフトウェア開発に携わる人々の間で 「アジャイル」というキーワードがよく聞かれるように なっている。  特にアイデアを素早く形にし、市場に提供すること がより利益を生むようなサービス業ではこの傾向が より顕著に表れている。  組み込みソフトウェア業界では、アジャイル ソフトウェア開発の需要が低い状況にある。 まえがき
  • 43. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 43  組み込みソフトウェアはUMLと親和性が高い。 クラス図は、ハードウェアとソフトウェアの境界を明確にし、 ハードウェアとソフトウェアの結合を疎にすることが容易 ステートマシン図 は、イベント駆動型プログラムの動作を 記述するのに最適 等  UML等を活用したモデル駆動開発は、以下の特徴がある。 ユースケース単位で開発することができる モデルを繰り返し検討することでより洗練された高品質な ソフトウェアが製作可能  この様な背景から、ガイドラインは組み込みソフトウェアの技 術者を対象とした。 まえがき
  • 44. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 44  抽象度の高いモデルと具象度の高いアジャイルプラクティスを組み 合わせることにより、高いレベルで開発者間の意識共有がされると 共に、スプリント毎に妥当性確認がされるスピーディーで確実な開 発を行うことを目指す。 • Scrumでは規定されていないプロダクトバックログアイテムの 発見手法を説明 • プロダクトバックログにユースケース図を使用することを提案 • ユースケース図の説明にアジャイルプラクティスを使用 UMLやアジャイル関連書籍とどこが違うのか http://www.scrumalliance.org/why-scrum この辺が対象 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 45. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 45 マインドマップを使って要求を聞き取る ユーザ要求聞き取り テンプレート 何を管理したいですか どんな場面で使用しますか 宿題 誰が使用しますか 誰が恩恵を受けますか 動機は何ですか 2012年3月28日セミナー ㈱チェンジビジョン 平鍋氏 講演資料より テンプレート化されたマインドマップを足掛かりにユーザの要求を見える化していく
  • 46. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 46 マインドマップからユースケース図を作成する 求聞き取り ート どんな場面で使用しますか 誰が使用しますか 誰が恩恵を受けますか 動機は何ですか ユースケース図の モデル要素 ユースケース( ) アクター( )
  • 47. ユースケース図(例) アクター (人や外部システム) システムバウンダリ (開発対象システムと外との境界) ユースケース (開発対象機能) 47 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 48. ユースケース図を作成する際のポイント (教科書的に) ユースケースの粒度を揃える ⇒ 見積りの精度向上のため ユースケース毎にユースケース仕様書を書く ⇒ ユースケースの仕様を明確にする アクターは「役割」を表す ⇒ 同じ人でも役割によって使用する機能が 異なる 48 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 49. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ユースケースの粒度が細かくなりすぎる ユースケース仕様書を書くのに時間が掛かる ユースケースを捨てられない システムやアクターはそれ程分析されない 実際にやってみると・・・ http://www.flickr.com/photos/genbug/3424589979/49 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 50. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ユースケースの規模を相対サイズで見積る そもそも粒度は揃わない アジャイルではフィーチャーは相対サイズで 見積るため粒度は気にしていない 50 http://www.flickr.com/photos/adambindslev/4639871328/ ならば、アジャイルプラクティスに倣って ユースケースの規模を相対サイズで見積ればいい Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 51. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 51 先ずはユーザーストーリーを使う ユーザーストーリーとは、実現したい と思っているフィーチャーを簡潔に示 したもので、短い文章として表したも の メリット 作成に時間が掛からない フィーチャーの本質を捉える事ができる ユースケースの粒度によらない http://www.flickr.com/photos/psd/8591351239/ ユースケース仕様書は適切なタイミングで必要な量だけ書く
  • 52. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved ペルソナを使ってアクターを定義する http://www.flickr.com/photos/campusparty/4837562909 「役割」だけだと「どんな人」が使うことを想定 しているか曖昧 52 ペルソナによりアクターを詳細に定義し、 想定ユーザを明確にする Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 53. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 53 エレベータピッチを使ってシステムを説明する http://www.flickr.com/photos/european_parliament/4767798097 ユースケース図に於いて「システム」は単なる「枠」 描かれない場合もある エレベータピッチ(システムの本質を表す短い 文章)を使いどんなものを作るかを明確に 定義する53 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 54. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 54 ユースケースの優先順位を決める ユースケースの価値から優先順位 を決める •ユーザーストーリーマッピング •狩野モデル ユースケースの関連を考慮する •ユースケース図 技術的リスクを考慮する •開発チームの意見 http://www.flickr.com/photos/mrsj1/4441258474 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 55. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved http://www.flickr.com/photos/49942291@N06/6271934371/ ユーザーが体験するタスクの順番毎 (ワークフロー)にユースケースをマッピング 最小の価値を有する製品(MVP)を構成する ユースケースから優先順位を決定する ユーザー (アクター) ユーザーストーリーマッピング 55 Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 56. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 56 狩野モデル ユースケースをカテゴリー分けし、優先順位を決定する ① 当たり前、または必須のユースケース ⇒ 製品に欠かせない ② 線形、一元的なユースケース ⇒ あればある程良い ③ 魅力的な、わくわくするユースケース ⇒ 大きな満足をもたらす 以上のカテゴリーを基に価値を考えると・・・ 当たり前のユースケースは全て備える 線形のユースケースをできる限り多く備える ① ③ ② ユースケース量 満 足 度
  • 57. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 57 ユースケース間の依存を考慮する UC_1 UC_2 ≪include≫ UC_3 ≪extend≫ UC_1は、UC_2を包含する UC_4は、UC_3を拡張する 従って、優先順位は UC_2 > UC_1 UC_3 > UC_4 だが UC_1とUC_4は別の観点での優先順位付けが必要 UC_4
  • 58. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 技術的リスクは付きもの 技術的リスクは早期に解消する 技術的リスクを把握しているのは開発チーム 技術リスクを考慮する 58 要求元と開発チームが協力しリスク解消の 優先順位を決定する http://www.flickr.com/photos/purecaffeine/4325390829/ Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
  • 59. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 59 1 356 245 3 2高 低 中 高低 中 価 値 を 基 に し た 順 位 技術的リスクを基にした順位 マスの中の数字は優先度を表す 数字が小さいほど優先度が高い 価値を基にした順位と技術的リスクをマッピングする
  • 60. Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved 60 本日説明したガイドラインは来年3月に リリース予定です。 最後に
  • 61. ご清聴ありがとうございました。