Soumettre la recherche
Mettre en ligne
Supersonic agile
•
Télécharger en tant que PPTX, PDF
•
1 j'aime
•
693 vues
Shozaburo Yoshihara
Suivre
Signaler
Partager
Signaler
Partager
1 sur 35
Télécharger maintenant
Recommandé
小さいカイゼンをまぁまぁうまく回しているチームとツールの紹介
小さいカイゼンをまぁまぁうまく回しているチームとツールの紹介
Akiyah
connpass特徴と開発の流れ
connpass特徴と開発の流れ
Ikeda Yosuke
スクラム開発について
スクラム開発について
Akio Terayama
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
Yusuke Suzuki
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
アジャイル入門
アジャイル入門
Kenji Morita
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
Recommandé
小さいカイゼンをまぁまぁうまく回しているチームとツールの紹介
小さいカイゼンをまぁまぁうまく回しているチームとツールの紹介
Akiyah
connpass特徴と開発の流れ
connpass特徴と開発の流れ
Ikeda Yosuke
スクラム開発について
スクラム開発について
Akio Terayama
CEDEC2015講演 チーム開発をスムーズにするために
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
Yusuke Suzuki
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
アジャイル入門
アジャイル入門
Kenji Morita
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
Takafumi Ikeda
Dev love kansai
Dev love kansai
Takafumi Ikeda
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
Yusuke Suzuki
マイクロサービスとそれを支えるアーキテクチャー
マイクロサービスとそれを支えるアーキテクチャー
Tsukasa Kato
「チーム開発実践入門」勉強会
「チーム開発実践入門」勉強会
Yu Ishikawa
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Miho Nagase
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
Techlion vol8 yusuke #techlion
Techlion vol8 yusuke #techlion
Yusuke Yamamoto
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
kiita312
クラウド鎖国からクラウド維新へ
クラウド鎖国からクラウド維新へ
Cybozucommunity
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Yusuke Suzuki
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
Yusuke Suzuki
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
デブサミ2010 これからのアーキテクチャを見通す
デブサミ2010 これからのアーキテクチャを見通す
Yusuke Suzuki
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
Yasui Tsutomu
「エンジニアはハードウェアビジネスをどうやって立ち上げればよいですか」問題
「エンジニアはハードウェアビジネスをどうやって立ち上げればよいですか」問題
Yasunori Okajima
スクラム再入門
スクラム再入門
Minoru Yokomichi
Agile Software Development for Newbies
Agile Software Development for Newbies
Naoto Nishimura
Ulsアジャイル推進室 エンタープライズアジャイルがやってくる! 20160312
Ulsアジャイル推進室 エンタープライズアジャイルがやってくる! 20160312
Shozaburo Yoshihara
知働化フォーラム2015 0305
知働化フォーラム2015 0305
ITinnovation
Contenu connexe
Tendances
チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
Takafumi Ikeda
Dev love kansai
Dev love kansai
Takafumi Ikeda
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
Yusuke Suzuki
マイクロサービスとそれを支えるアーキテクチャー
マイクロサービスとそれを支えるアーキテクチャー
Tsukasa Kato
「チーム開発実践入門」勉強会
「チーム開発実践入門」勉強会
Yu Ishikawa
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Miho Nagase
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
Techlion vol8 yusuke #techlion
Techlion vol8 yusuke #techlion
Yusuke Yamamoto
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
kiita312
クラウド鎖国からクラウド維新へ
クラウド鎖国からクラウド維新へ
Cybozucommunity
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Yusuke Suzuki
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
Yusuke Suzuki
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
デブサミ2010 これからのアーキテクチャを見通す
デブサミ2010 これからのアーキテクチャを見通す
Yusuke Suzuki
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
Yasui Tsutomu
「エンジニアはハードウェアビジネスをどうやって立ち上げればよいですか」問題
「エンジニアはハードウェアビジネスをどうやって立ち上げればよいですか」問題
Yasunori Okajima
スクラム再入門
スクラム再入門
Minoru Yokomichi
Agile Software Development for Newbies
Agile Software Development for Newbies
Naoto Nishimura
Tendances
(20)
チーム開発をスムーズにするために何ができるか
チーム開発をスムーズにするために何ができるか
Dev love kansai
Dev love kansai
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
マイクロサービスとそれを支えるアーキテクチャー
マイクロサービスとそれを支えるアーキテクチャー
「チーム開発実践入門」勉強会
「チーム開発実践入門」勉強会
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Techlion vol8 yusuke #techlion
Techlion vol8 yusuke #techlion
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
クラウド鎖国からクラウド維新へ
クラウド鎖国からクラウド維新へ
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
デブサミ2010 これからのアーキテクチャを見通す
デブサミ2010 これからのアーキテクチャを見通す
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
「エンジニアはハードウェアビジネスをどうやって立ち上げればよいですか」問題
「エンジニアはハードウェアビジネスをどうやって立ち上げればよいですか」問題
スクラム再入門
スクラム再入門
Agile Software Development for Newbies
Agile Software Development for Newbies
En vedette
Ulsアジャイル推進室 エンタープライズアジャイルがやってくる! 20160312
Ulsアジャイル推進室 エンタープライズアジャイルがやってくる! 20160312
Shozaburo Yoshihara
知働化フォーラム2015 0305
知働化フォーラム2015 0305
ITinnovation
150318 次世代itアーキテクトの本質と育成
150318 次世代itアーキテクトの本質と育成
ITinnovation
ULSアジャイル推進室 基幹系システムの再構築におけるDDD事例 20160312
ULSアジャイル推進室 基幹系システムの再構築におけるDDD事例 20160312
Yuki Tagami
Bitbucketを活用したコードレビュー改善事例
Bitbucketを活用したコードレビュー改善事例
Kosuke Ito
アジャイル事例紹介
アジャイル事例紹介
hiko99
アジャイルをシミュレーションで理解する
アジャイルをシミュレーションで理解する
Akiyah
Reエンタープライズへのアジャイル開発の導入事例 20161119
Reエンタープライズへのアジャイル開発の導入事例 20161119
Shozaburo Yoshihara
いまさらアジャイル巡業 In Tokyo アジャイルモデリング
いまさらアジャイル巡業 In Tokyo アジャイルモデリング
Yuki Tagami
複雑さに挑む!カンバンによるプロジェクト マネジメント
複雑さに挑む!カンバンによるプロジェクト マネジメント
智治 長沢
ETWest2009講演資料「TestLinkでアジャイルにテストする」
ETWest2009講演資料「TestLinkでアジャイルにテストする」
akipii ogaoga
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
「実践ドメイン駆動設計」社内読書会まとめ ~IDDD本難民に捧げる1章から7章~
「実践ドメイン駆動設計」社内読書会まとめ ~IDDD本難民に捧げる1章から7章~
A AOKI
En vedette
(13)
Ulsアジャイル推進室 エンタープライズアジャイルがやってくる! 20160312
Ulsアジャイル推進室 エンタープライズアジャイルがやってくる! 20160312
知働化フォーラム2015 0305
知働化フォーラム2015 0305
150318 次世代itアーキテクトの本質と育成
150318 次世代itアーキテクトの本質と育成
ULSアジャイル推進室 基幹系システムの再構築におけるDDD事例 20160312
ULSアジャイル推進室 基幹系システムの再構築におけるDDD事例 20160312
Bitbucketを活用したコードレビュー改善事例
Bitbucketを活用したコードレビュー改善事例
アジャイル事例紹介
アジャイル事例紹介
アジャイルをシミュレーションで理解する
アジャイルをシミュレーションで理解する
Reエンタープライズへのアジャイル開発の導入事例 20161119
Reエンタープライズへのアジャイル開発の導入事例 20161119
いまさらアジャイル巡業 In Tokyo アジャイルモデリング
いまさらアジャイル巡業 In Tokyo アジャイルモデリング
複雑さに挑む!カンバンによるプロジェクト マネジメント
複雑さに挑む!カンバンによるプロジェクト マネジメント
ETWest2009講演資料「TestLinkでアジャイルにテストする」
ETWest2009講演資料「TestLinkでアジャイルにテストする」
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
「実践ドメイン駆動設計」社内読書会まとめ ~IDDD本難民に捧げる1章から7章~
「実践ドメイン駆動設計」社内読書会まとめ ~IDDD本難民に捧げる1章から7章~
Similaire à Supersonic agile
Scrum
Scrum
Kakigi Katuyuki
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理
You&I
はじめてのスクラム開発
はじめてのスクラム開発
ai oshiumi
Intalio japan special cloud workshop
Intalio japan special cloud workshop
Daisuke Sugai
Scrum
Scrum
Takahiro Tachiki
Scrum"再"入門
Scrum"再"入門
You&I
20160409_Validating Product Ideas_yukio yoshida_cp04
20160409_Validating Product Ideas_yukio yoshida_cp04
Japan Culture Creation
Google Product
Google Product
Daisuke Sugai
20121017_アプリ制作勉強会@GMO Yours
20121017_アプリ制作勉強会@GMO Yours
Yozo SATO
アジャイルと私
アジャイルと私
Hajime Yanagawa
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
You&I
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Yusuke Suzuki
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
CASAREAL, Inc.
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Yusuke Suzuki
Scrum体験スパルタワークショップ
Scrum体験スパルタワークショップ
You&I
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現する
Makoto SAKAI
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
Yoichi Tamamaki
Similaire à Supersonic agile
(20)
Scrum
Scrum
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理
はじめてのスクラム開発
はじめてのスクラム開発
Intalio japan special cloud workshop
Intalio japan special cloud workshop
Scrum
Scrum
Scrum"再"入門
Scrum"再"入門
20160409_Validating Product Ideas_yukio yoshida_cp04
20160409_Validating Product Ideas_yukio yoshida_cp04
Google Product
Google Product
20121017_アプリ制作勉強会@GMO Yours
20121017_アプリ制作勉強会@GMO Yours
アジャイルと私
アジャイルと私
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Scrum体験スパルタワークショップ
Scrum体験スパルタワークショップ
アジャイル風の開発で集中を実現する
アジャイル風の開発で集中を実現する
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
Supersonic agile
1.
Supersonic Agile Development 1 S.
Yoshihara 2013/3/13 2x Speed
2.
Agile is so
fast, but・・・ • アジャイル開発はプラクティスを効果的に組み合わせる ことによって、開発チームの生産性を最大限に引き上げ ることができる • しかし、要件を決める側にはこれとったプラクティスは なく、アジャイルのスピードにあわせて忙しなく重要な 要件も決める必要がある。複雑なシステムになれば、ス トーリーや画面だけでは仕様の是非を判断できない • つまり、開発は超高速で走っているが、要件は目先の判 断になってしまい、全体俯瞰では見当違いな方向に走っ ている可能性があるということである COPYRIGHTS S.YOSHIHRA 2
3.
Agile+Usecase • まず、要件分析を全体俯瞰で体系的に行うために ユースケース分析を行う。ただし、アジャイルとは スピードが違うので非同期にタスクが組めるように する COPYRIGHTS S.YOSHIHRA
3 ユースケース分析要件分析 アジャイル 開発 ユースケース分析が終わったものからアジャイル開発を行う。 ユースケース分析とアジャイル開発は非同期に行えるように別チー ムとする ユースケース分析はユースケース一覧の優先度が高いものから行 う。ユースケース分析が終わったものからアジャイル開発を行う ユースケース分析ではユースケース図ではなくユースケース記述 を使う
4.
Agile+MDA+DDD=“Supersonic speed” • MDA(Model
Driven Architecture)ツール – 要件分析のモデルをアジャイル開発まで確実に伝達 し、速やかに開発を行うためには支援ツール群が必 要である。MDAの考え方はそれを実現するためのも のである。生産性を向上させるためにMDAも適用す る – ただし、ビヘイビア(Behavior)はプログラミングす る方が効率が良いので扱わない • DDD(Domain Driven Design)のコンセプト – DDDを全面的に適用するのではなく、モデルをそのま ま実装に繋げるコンセプトを、MDAツールと組み合 わせて利用する COPYRIGHTS S.YOSHIHRA 4
5.
• Tech Features –
Agile – Usecase – MDA (Model Driven Architecture) – DDD (Domain Driven Design) • “Supersonic Agile Development” – 上記の高度な技術を最適に組み合わせにすることで、 超高生産性なシステム開発を実現する – この技術を使いこなすためには、必要なスキルと ツールを備えた専門チームが必要である Supersonic Agile Developement COPYRIGHTS S.YOSHIHRA 5
6.
Overview COPYRIGHTS S.YOSHIHRA 6 ユースケース一覧 MDAツール モデルとソースコード の差分抽出と同期支援 アジャイル開発 (実装+単体テス ト) システムテスト リリース イテレーション (スプリント) 要件分析 ユースケース分析 ドメインモデル (DDD)優先度の高い ものから分析 分析済で、優先度 の高いものから開 発 開発済のものが、 リリースできる単 位になった場合 セキュリティ、負 荷、障害テストな ども行う 要件分析チーム 開発チーム プロダクトオーナー ユースケースの分析済、開発済 などのステータスを管理する。 更に、ユースケースに優先度を 付けることで計画、スコープ管 理に使う(プロダクトバックロ グ相当)
7.
サービス • ユースケース定額(Pay per
usecase) – 生産性の責任は開発側が負担すべきと考え、ユース ケース当たりの価格は定額とする。計画よりも生産 性が低かった場合でも追加料金は請求しない – 開発総額はユースケース数に固定単価を掛けあわせ て算出する。開発中にユースケースが増えた場合は 追加料金が発生する – 契約形態は請負・準委任ともに可能とする。どちら もユースケース一覧を作成して見積りをする。請負 ではユースケース数を先に決め、開発途中で未開発 のユースケースは入れ替えることができる – ユースケース定額にすればアジャイル開発でも請負 (事前にコストを決めるという意味で)が可能にな る COPYRIGHTS S.YOSHIHRA 7
8.
サービス • 生産性2倍(2x Speed) –
業界標準のメトリクスをもとに独自に調査した標準 的な生産性を基に、2倍の生産性を基準とする – 基準生産性に達成しなくても、ユースケース定額な ので追加料金は発生しない。その分、期間バッファ は適切に設定する • 品質保証 – 不可能なものを除いて全てのモジュールはテスト自 動化を行う(更にテスト観点によって手動によるテ ストも行う) – 開発費用に定率を上乗せすることで、瑕疵担保期間 を延長することができる COPYRIGHTS S.YOSHIHRA 8
9.
サービス • メンバー保証 – Supersonicを習熟したメンバーだけで編成する。安い だけのオフショアなどはもっての外である •
まる見え保証 – 進捗、課題、生産性、品質指標は全て見える化する。 当然、これらのデータは顧客企業と開発側で全く同 じものを参照する COPYRIGHTS S.YOSHIHRA 9
10.
仕様変更の考え方 (Q)ユースケースAを開発したが、顧客企業の判断で ユースケースの内容はそのままで画面だけを変更し たい。画面を改修するためのコストはどうなるの か? (A)開発済のユースケースの画面を変更する場合に は追加料金は発生する。多少の変更であれば0.5UC単 価とする (Q)ユースケースAを開発したが、顧客企業の判断で ユースケースの内容を変更してA`にした場合、A` に改修するためのコストはどうなるのか? (A)基本的にユースケースが変更されれば追加料金は 発生する。多少の変更であれば0.5UC単価とする COPYRIGHTS S.YOSHIHRA 10
11.
• ユースケース数が100個のプロジェクトを想定する – Supersonic
Agile Development • 総開発工数:79人月 – 従来型(ウォーターフォール) • 総開発工数:129人月 要件定義 : 14MM 工数を小さく、期間は短く COPYRIGHTS S.YOSHIHRA 11 ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 ※一般的に、人員は同時投入する程、生産性は落ちるため、上の例では無理なく人員を投入した場合を想定し ている
12.
12COPYRIGHTS S.YOSHIHRA Agile+Usecase 技術詳細
13.
ユースケース分析 • ユースケース分析では、ユースケース図ではなく、 ユースケース記述を作成する • ユースケース記述とは別カタログとしてビジネス ルールを定義する。ビジネスルールはユースケース 横断的に参照されることになる COPYRIGHTS
S.YOSHIHRA 13 ユースケース UC001 ユースケース UC002 ユースケース UC003 ビジネスルール BR100 ビジネスルール BR101 ビジネスルール BR102
14.
ユースケース一覧(Product Backlog) • 要件分析とアジャイル開発を非同期に並行して行う ために、ユースケース一覧がバックログの役割を果 たす •
要件分析がボトルネックにならないように生産性と 担当数を最適化しなければならないCOPYRIGHTS S.YOSHIHRA 14 ユースケース分析要件分析 アジャイル開 発 ユースケース一覧ユースケース ユースケース 未分析なものを、ユー スケース分析する ユースケース分析が終わっ たものは分析済にする 未分析 分析済 優先度に応じて、ユース ケース分析やアジャイル開 発するユースケースを選択 する ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース 分析済のものをア ジャイル開発する 開発済
15.
ユースケース標準FP • トランザクションファンクション – 仮に、平均的なユースケースに4~8のシナリオのステップ があるとすれば、その半数程度がシステムが行うステップ である –
システムが行うステップではアクターとの何らかの相互作 用が発生していると考えられる。FPでいうEI/EO/EQの何れ かである • データファンクション – ユースケースあたり、0.6個のILFがあると仮定する – ユースケースあたり、0.3個のEIFがあると仮定する • ユースケース標準FP – 上記の前提で、NESMA概算法を使って計算すると14.7~ 22.7FPとなる – 標準FPは、1UC=20FPとする COPYRIGHTS S.YOSHIHRA 15
16.
開発目標生産性 • 業界標準FP生産性の2倍を目標とする • 業界標準FP生産性 –
20FP/MM(基本設計~ 結合テスト) • Supersonicの開発目標生産性 40FP/MM COPYRIGHTS S.YOSHIHRA 16 •15FP/MM(基本設計~総合テスト) (出典: SEC:ソフトウェア開発データ白書2012-2013) 上記の業界標準FP生産性では総合テストまで含まれている が、Supersonicのアジャイル開発は結合テストまでである。 よって、業界標準FP生産性から総合テストを除いた生産性 を仮定する
17.
要件分析生産性と担当数比率 • 要件分析生産性 – 7UC/MM
(過去の経験より) • 開発目標生産性 ※前述 – ユースケース規模を1UC = 20FPと仮定する – 40FP/MM = 2UC/MM • 要件分析・開発担当数比率 3.5 ≧ 開発担当数/要件分析担当数 ※つまり、開発よりも要件分析の生産性を高めにする ことでボトルネックを回避する COPYRIGHTS S.YOSHIHRA 17
18.
チーム制 • Supersonicは専門チームのみが提供できるサービス である。専門チームの基本構成は次にように決める – Supersonicチーム(10名) •
マネージャ: 1名 (兹プロダクトオーナー支援) • 要件分析チーム:3名 (ドメインモデラー1名含む) • 開発チーム: 5名 • アーキテクト: 1名 ※プロジェクト特性に応じてサポートが追加になることはある (例えば、最近だとHadoopのようなスペシャリストが必要 な分野) • プロジェクトの規模に応じて、n個のチームを組み 合わせる(例えば、20人が必要なら、2チーム編成 とする) COPYRIGHTS S.YOSHIHRA 18
19.
アジャイル開発 • スクラムベースのアジャイル開発を行う • スプリントは2週間を単位とする。標準編成のチー ムには開発者は5名なので、1スプリントあたり、 5UCが完成することになる •
スプリント計画では、ユースケース一覧から分析済 の5UCを優先度に従って選択する(大きすぎるユー スケースが無いことを開発チームで確認する) • 他、アジャイルプラクティスを実践する COPYRIGHTS S.YOSHIHRA 19 1週目 2週目 1 スプリント 1ユースケース 1週目 2週目 1 スプリント 1ユースケース スプリント ▼計画 スプリント ▼計画
20.
生産性2倍(2x Speed) • 標準FPと開発目標生産性から40FP/MM
= 2UC/MMと なり、2週間で1ユースケースを作成することになる • 1ユースケース当たり2~4画面だと仮定すれば、 MDAツールなどの支援があれば実現可能な生産性で ある • 想定スケジュール – 1人日=スプリント計画、要件分析インプット – 2人日=HTML作成(3画面) – 2人日=画面開発 – 2人日=ビジネスロジック&DB開発 – 2人日=テスト(単体+結合) – 1人日=レトロスペクティブ ※都度、顧客企業へのフィードバックを行うCOPYRIGHTS S.YOSHIHRA 20
21.
21COPYRIGHTS S.YOSHIHRA Agile+MDA+DDD 技術詳細
22.
MDA(Model Driven Architecture) •
一般的なMDAと同じように、要件分析で作成したモデル からソースコードを出力し、ソースコードに実装するま でをシームレスに行えるようにする • 最新のモデルがソースコードに反映されては困るケース もあるので、スプリント毎のブランチ管理をMDAツール が行う • モデリングツール(astahやEA)のプラグイン、開発環境 (eclipse)のプラグインを用意する COPYRIGHTS S.YOSHIHRA 22 ユース ケース ビジネス ルール ドメイン モデル モデリングツール MDA ツー ル ソースコード (開発中) 開発環境 リポジト リ
23.
DDD(Domain Driven Design) •
DDDの必要性 – Supersonicのような要件分析と開発が同時並行に行わ れる場合には、要件分析のモデルとソースコードが 1対1に対応付くことは最重要である(逆に言えば、 TransactionScriptは採用できない) • EvansのDDD – Eric EvansのDDDは名著である。扱われている話題も広 範囲に渡る。最も重要なのは、ドメインに業務知識 が適切に表現されていて、そのままコードに定義さ れることである – 業務知識であるビジネスロジックをエンティティに 定義することで、ビジネスロジックをDRYに保てる COPYRIGHTS S.YOSHIHRA 23
24.
DDDのポイント • ビジネスロジックをSQLで書いてはいけない? – ビジネスロジックをドメインが隠蔽していれば、そ のロジックがJavaなのかSQLなのかはクライアントに は関係ない –
ドメインレイヤーとインフラストラクチャレイヤー の境界が、教科書的見地から曖昧になるのは大きな 問題ではない – 躊躇せず、SQLを利用すべきである • JOINはタブーなのか? – JOINの是非は、DDDの目的である業務知識の適切な実 装ということと無関係である – JOINのロジックをドメインが隠蔽し、JOINの結果をバ リューオブジェクトで返せば良い(何の遠慮がある ものか) COPYRIGHTS S.YOSHIHRA 24
25.
25COPYRIGHTS S.YOSHIHRA その他 技術詳細
26.
メトリクス • 生産性 – スプリント完了時にリポジトリにコミットしたソー スコードから半自動的にFPを計測する –
生産性は、スプリント毎、開発者毎に全て計測する。 スプリントによる生産性の傾向と予測まで行う – ユースケースのシナリオ数、ビジネスルール数、画 面数などと生産性との相関も全て自動的に計測する • 品質指標 – 全モジュールのカバレッジを計測する – 全ての自動テストの結果を集計する – システムテストのバグ傾向分析や、ユースケース単 位のバグ傾向分析を行い、レポートする COPYRIGHTS S.YOSHIHRA 26
27.
DevCloud • リポジトリ、ビルドサーバ(CI)とテストサーバ、 バグトラッキングなどの開発環境はクラウドを使う。 これらのツール群はSupersonic向けに最適化された 標準構成のものを利用する(定額課金) • クラウドでテストされたものは、顧客企業のオンプ レミスなどに移行するか、顧客企業が望めばクラウ ドのままサービスインすることも出来る •
クラウドの開発環境はリリース後も顧客企業は利用 し続けることもできる COPYRIGHTS S.YOSHIHRA 27 Repository Build(CI) Bug Track Test Server Cloud
28.
ビジネスモデル 28COPYRIGHTS S.YOSHIHRA
29.
成果型SIモデル • ユースケース定額は成果型SI – ユースケース数に定額単価を掛けて課金する –
よって、人月型SIではなく、成果型SIである。よって、 技術革新によって生産性を向上すれば、その分の原 価を減らし、粗利を増やすことができる • ユースケース定額単価は、競合他社に対して競争力 のある価格とする(高生産性であるから実現でき る) COPYRIGHTS S.YOSHIHRA 29 要件定義 開発 システムテスト 要件分析 アジャイル開発 システムテスト 競合他社 Supersonic
30.
ユースケース定額 • 競合他社のモデル価格 – 業界標準FP生産性(20FP/MM)だと、要件定義を含 めて1UC=200万円程度になる •
ユースケース定額単価 – 1UC = 180万円 ※競合よりも割安 – Supersonic開発目標FP生産性(40FP/MM)だと、要件 分析も含めて105万円程度になるが、バッファとして 75万円を乗せる COPYRIGHTS S.YOSHIHRA 30 ※ユースケースによっては非常に難易度が高い可能性がある。それらの場合、例外的にユースケース定額 が適用されないケースはありえる。バッチも同様にユースケース分析をすることを想定しているが、バッ チによっては1つのユースケースでも難易度が高い可能性がある。複雑な集計処理や、ビッグ・データを 扱う場合などである。これらは、顧客への説明、提案書や契約書などに記載する
31.
• ユースケース数が100個のプロジェクトを想定する – Supersonic
Agile Development • 総開発工数:79人月 = 開発総額1.8億円 – 従来型(ウォーターフォール) • 総開発工数:129人月 = 開発総額1.94億円 総額でも割安で、期間は短く COPYRIGHTS S.YOSHIHRA 31 要件定義 : 14MM ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 1.8億 1.94億
32.
32COPYRIGHTS S.YOSHIHRA Summary
33.
まとめ • Supersonic Agile
Developmentとは – Agile+Usecase+MDA+DDDの超音速開発 – 成果型SIモデル • サービス(価値)は – ユースケース定額 – 生産性2倍(2x Speed) – 品質保証 • MDAツールで装備 • メトリクス(生産性、品質)を常に共有 • Cloudで開発環境を提供 COPYRIGHTS S.YOSHIHRA 33 ※具体的な生産性を謳うのは他にない
34.
34COPYRIGHTS S.YOSHIHRA Give us
carrots!
35.
Incentive novelty goods •
“1.5x Speed”を達成したら – Supersonic Towel • “2.0x Speed”を達成したら – Supersonic T-shirt • 更に、“3.0x Speed “を達成したら – Supersonic Character-Figure (その前にキャラクターを決めなきゃ) COPYRIGHTS S.YOSHIHRA 35
Télécharger maintenant