Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SuperSonicAgile
Search
shoyoshi
March 13, 2013
Technology
0
26
SuperSonicAgile
SuperSonicAgile
shoyoshi
March 13, 2013
Tweet
Share
More Decks by shoyoshi
See All by shoyoshi
組織再生とアジャイル
shoyoshi
1
600
Re:エンタープライズへのアジャイル開発の導入事例
shoyoshi
0
27
エンタープライズへのアジャイル開発の導入事例
shoyoshi
0
65
エンタープライズアジャイルがやってくる!
shoyoshi
0
22
Other Decks in Technology
See All in Technology
Oracle Database で機械学習を始めよう! Oracle Machine Learning
oracle4engineer
PRO
1
140
LLM + RAG を使った SORACOM Support Bot の裏側の歴史
soracom
PRO
1
630
バッチ処理のSLOをどう設計するか
rynsuke
7
540
期待しすぎずに取り組む両面 TypeScript
shozawa
2
280
XRミーティング 2024-03-20
1ftseabass
PRO
0
100
単回帰分析について数式を追いながら実装してみた
kentaitakura
0
490
#51 “Empowering Azure Storage with RDMA”
cafenero_777
3
210
技術イベントはなんとかひねり出す 日経の技術広報の取り組み/techpr3
nishiuma
0
220
Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善
10xinc
6
1.4k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
11
3k
Cloud Friendly(?) Jenkins. How we failed to make Jenkins cloud native and what we learned?
onenashev
PRO
0
110
KubeCon EU: Unlocking new Platform Experiences with Open Interfaces
salaboy
1
360
Featured
See All Featured
In The Pink: A Labor of Love
frogandcode
137
21k
The Art of Programming - Codeland 2020
erikaheidi
40
12k
For a Future-Friendly Web
brad_frost
170
8.9k
Why You Should Never Use an ORM
jnunemaker
PRO
50
8.6k
RailsConf 2023
tenderlove
0
510
Creatively Recalculating Your Daily Design Routine
revolveconf
209
11k
A designer walks into a library…
pauljervisheath
199
23k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
111
35k
Six Lessons from altMBA
skipperchong
19
2.9k
No one is an island. Learnings from fostering a developers community.
thoeni
14
2k
Robots, Beer and Maslow
schacon
PRO
154
7.9k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
178
11k
Transcript
Supersonic Agile Development 1 S. Yoshihara 2013/3/13 2x Speed
Agile is so fast, but・・・ • アジャイル開発はプラクティスを効果的に組み合わせる ことによって、開発チームの生産性を最大限に引き上げ ることができる •
しかし、要件を決める側にはこれとったプラクティスは なく、アジャイルのスピードにあわせて忙しなく重要な 要件も決める必要がある。複雑なシステムになれば、ス トーリーや画面だけでは仕様の是非を判断できない • つまり、開発は超高速で走っているが、要件は目先の判 断になってしまい、全体俯瞰では見当違いな方向に走っ ている可能性があるということである COPYRIGHTS S.YOSHIHRA 2
Agile+Usecase • まず、要件分析を全体俯瞰で体系的に行うために ユースケース分析を行う。ただし、アジャイルとは スピードが違うので非同期にタスクが組めるように する COPYRIGHTS S.YOSHIHRA 3 ユースケース分析
要件分析 アジャイル 開発 ユースケース分析が終わったものからアジャイル開発を行う。 ユースケース分析とアジャイル開発は非同期に行えるように別チー ムとする ユースケース分析はユースケース一覧の優先度が高いものから行 う。ユースケース分析が終わったものからアジャイル開発を行う ユースケース分析ではユースケース図ではなくユースケース記述 を使う
Agile+MDA+DDD=“Supersonic speed” • MDA(Model Driven Architecture)ツール – 要件分析のモデルをアジャイル開発まで確実に伝達 し、速やかに開発を行うためには支援ツール群が必 要である。MDAの考え方はそれを実現するためのも
のである。生産性を向上させるためにMDAも適用す る – ただし、ビヘイビア(Behavior)はプログラミングす る方が効率が良いので扱わない • DDD(Domain Driven Design)のコンセプト – DDDを全面的に適用するのではなく、モデルをそのま ま実装に繋げるコンセプトを、MDAツールと組み合 わせて利用する COPYRIGHTS S.YOSHIHRA 4
• Tech Features – Agile – Usecase – MDA (Model
Driven Architecture) – DDD (Domain Driven Design) • “Supersonic Agile Development” – 上記の高度な技術を最適に組み合わせにすることで、 超高生産性なシステム開発を実現する – この技術を使いこなすためには、必要なスキルと ツールを備えた専門チームが必要である Supersonic Agile Developement COPYRIGHTS S.YOSHIHRA 5
Overview COPYRIGHTS S.YOSHIHRA 6 ユースケース一覧 MDAツール モデルとソースコード の差分抽出と同期支援 アジャイル開発 (実装+単体テス
ト) システムテスト リリース イテレーション (スプリント) 要件分析 ユースケース分析 ドメインモデル (DDD) 優先度の高い ものから分析 分析済で、優先度 の高いものから開 発 開発済のものが、 リリースできる単 位になった場合 セキュリティ、負 荷、障害テストな ども行う 要件分析チーム 開発チーム プロダクトオーナー ユースケースの分析済、開発済 などのステータスを管理する。 更に、ユースケースに優先度を 付けることで計画、スコープ管 理に使う(プロダクトバックロ グ相当)
サービス • ユースケース定額(Pay per usecase) – 生産性の責任は開発側が負担すべきと考え、ユース ケース当たりの価格は定額とする。計画よりも生産 性が低かった場合でも追加料金は請求しない –
開発総額はユースケース数に固定単価を掛けあわせ て算出する。開発中にユースケースが増えた場合は 追加料金が発生する – 契約形態は請負・準委任ともに可能とする。どちら もユースケース一覧を作成して見積りをする。請負 ではユースケース数を先に決め、開発途中で未開発 のユースケースは入れ替えることができる – ユースケース定額にすればアジャイル開発でも請負 (事前にコストを決めるという意味で)が可能にな る COPYRIGHTS S.YOSHIHRA 7
サービス • 生産性2倍(2x Speed) – 業界標準のメトリクスをもとに独自に調査した標準 的な生産性を基に、2倍の生産性を基準とする – 基準生産性に達成しなくても、ユースケース定額な ので追加料金は発生しない。その分、期間バッファ
は適切に設定する • 品質保証 – 不可能なものを除いて全てのモジュールはテスト自 動化を行う(更にテスト観点によって手動によるテ ストも行う) – 開発費用に定率を上乗せすることで、瑕疵担保期間 を延長することができる COPYRIGHTS S.YOSHIHRA 8
サービス • メンバー保証 – Supersonicを習熟したメンバーだけで編成する。安い だけのオフショアなどはもっての外である • まる見え保証 – 進捗、課題、生産性、品質指標は全て見える化する。
当然、これらのデータは顧客企業と開発側で全く同 じものを参照する COPYRIGHTS S.YOSHIHRA 9
仕様変更の考え方 (Q)ユースケースAを開発したが、顧客企業の判断で ユースケースの内容はそのままで画面だけを変更し たい。画面を改修するためのコストはどうなるの か? (A)開発済のユースケースの画面を変更する場合に は追加料金は発生する。多少の変更であれば0.5UC単 価とする (Q)ユースケースAを開発したが、顧客企業の判断で ユースケースの内容を変更してA`にした場合、A`
に改修するためのコストはどうなるのか? (A)基本的にユースケースが変更されれば追加料金は 発生する。多少の変更であれば0.5UC単価とする COPYRIGHTS S.YOSHIHRA 10
• ユースケース数が100個のプロジェクトを想定する – Supersonic Agile Development • 総開発工数:79人月 – 従来型(ウォーターフォール)
• 総開発工数:129人月 要件定義 : 14MM 工数を小さく、期間は短く COPYRIGHTS S.YOSHIHRA 11 ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 ※一般的に、人員は同時投入する程、生産性は落ちるため、上の例では無理なく人員を投入した場合を想定し ている
12 COPYRIGHTS S.YOSHIHRA Agile+Usecase 技術詳細
ユースケース分析 • ユースケース分析では、ユースケース図ではなく、 ユースケース記述を作成する • ユースケース記述とは別カタログとしてビジネス ルールを定義する。ビジネスルールはユースケース 横断的に参照されることになる COPYRIGHTS S.YOSHIHRA
13 ユースケース UC001 ユースケース UC002 ユースケース UC003 ビジネスルール BR100 ビジネスルール BR101 ビジネスルール BR102
ユースケース一覧(Product Backlog) • 要件分析とアジャイル開発を非同期に並行して行う ために、ユースケース一覧がバックログの役割を果 たす • 要件分析がボトルネックにならないように生産性と 担当数を最適化しなければならない COPYRIGHTS
S.YOSHIHRA 14 ユースケース分析 要件分析 アジャイル開 発 ユースケース一覧 ユースケース ユースケース 未分析なものを、ユー スケース分析する ユースケース分析が終わっ たものは分析済にする 未分析 分析済 優先度に応じて、ユース ケース分析やアジャイル開 発するユースケースを選択 する ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース 分析済のものをア ジャイル開発する 開発済
ユースケース標準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
開発目標生産性 • 業界標準FP生産性の2倍を目標とする • 業界標準FP生産性 – 20FP/MM(基本設計~ 結合テスト) • Supersonicの開発目標生産性
40FP/MM COPYRIGHTS S.YOSHIHRA 16 •15FP/MM(基本設計~総合テスト) (出典: SEC:ソフトウェア開発データ白書2012-2013) 上記の業界標準FP生産性では総合テストまで含まれている が、Supersonicのアジャイル開発は結合テストまでである。 よって、業界標準FP生産性から総合テストを除いた生産性 を仮定する
要件分析生産性と担当数比率 • 要件分析生産性 – 7UC/MM (過去の経験より) • 開発目標生産性 ※前述 –
ユースケース規模を1UC = 20FPと仮定する – 40FP/MM = 2UC/MM • 要件分析・開発担当数比率 3.5 ≧ 開発担当数/要件分析担当数 ※つまり、開発よりも要件分析の生産性を高めにする ことでボトルネックを回避する COPYRIGHTS S.YOSHIHRA 17
チーム制 • Supersonicは専門チームのみが提供できるサービス である。専門チームの基本構成は次にように決める – Supersonicチーム(10名) • マネージャ: 1名 (兹プロダクトオーナー支援)
• 要件分析チーム:3名 (ドメインモデラー1名含む) • 開発チーム: 5名 • アーキテクト: 1名 ※プロジェクト特性に応じてサポートが追加になることはある (例えば、最近だとHadoopのようなスペシャリストが必要 な分野) • プロジェクトの規模に応じて、n個のチームを組み 合わせる(例えば、20人が必要なら、2チーム編成 とする) COPYRIGHTS S.YOSHIHRA 18
アジャイル開発 • スクラムベースのアジャイル開発を行う • スプリントは2週間を単位とする。標準編成のチー ムには開発者は5名なので、1スプリントあたり、 5UCが完成することになる • スプリント計画では、ユースケース一覧から分析済 の5UCを優先度に従って選択する(大きすぎるユー
スケースが無いことを開発チームで確認する) • 他、アジャイルプラクティスを実践する COPYRIGHTS S.YOSHIHRA 19 1週目 2週目 1 スプリント 1ユースケース 1週目 2週目 1 スプリント 1ユースケース スプリント ▼計画 スプリント ▼計画
生産性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 COPYRIGHTS S.YOSHIHRA Agile+MDA+DDD 技術詳細
MDA(Model Driven Architecture) • 一般的なMDAと同じように、要件分析で作成したモデル からソースコードを出力し、ソースコードに実装するま でをシームレスに行えるようにする • 最新のモデルがソースコードに反映されては困るケース もあるので、スプリント毎のブランチ管理をMDAツール
が行う • モデリングツール(astahやEA)のプラグイン、開発環境 (eclipse)のプラグインを用意する COPYRIGHTS S.YOSHIHRA 22 ユース ケース ビジネス ルール ドメイン モデル モデリングツール MDA ツー ル ソースコード (開発中) 開発環境 リポジト リ
DDD(Domain Driven Design) • DDDの必要性 – Supersonicのような要件分析と開発が同時並行に行わ れる場合には、要件分析のモデルとソースコードが 1対1に対応付くことは最重要である(逆に言えば、 TransactionScriptは採用できない)
• EvansのDDD – Eric EvansのDDDは名著である。扱われている話題も広 範囲に渡る。最も重要なのは、ドメインに業務知識 が適切に表現されていて、そのままコードに定義さ れることである – 業務知識であるビジネスロジックをエンティティに 定義することで、ビジネスロジックをDRYに保てる COPYRIGHTS S.YOSHIHRA 23
DDDのポイント • ビジネスロジックをSQLで書いてはいけない? – ビジネスロジックをドメインが隠蔽していれば、そ のロジックがJavaなのかSQLなのかはクライアントに は関係ない – ドメインレイヤーとインフラストラクチャレイヤー の境界が、教科書的見地から曖昧になるのは大きな
問題ではない – 躊躇せず、SQLを利用すべきである • JOINはタブーなのか? – JOINの是非は、DDDの目的である業務知識の適切な実 装ということと無関係である – JOINのロジックをドメインが隠蔽し、JOINの結果をバ リューオブジェクトで返せば良い(何の遠慮がある ものか) COPYRIGHTS S.YOSHIHRA 24
25 COPYRIGHTS S.YOSHIHRA その他 技術詳細
メトリクス • 生産性 – スプリント完了時にリポジトリにコミットしたソー スコードから半自動的にFPを計測する – 生産性は、スプリント毎、開発者毎に全て計測する。 スプリントによる生産性の傾向と予測まで行う –
ユースケースのシナリオ数、ビジネスルール数、画 面数などと生産性との相関も全て自動的に計測する • 品質指標 – 全モジュールのカバレッジを計測する – 全ての自動テストの結果を集計する – システムテストのバグ傾向分析や、ユースケース単 位のバグ傾向分析を行い、レポートする COPYRIGHTS S.YOSHIHRA 26
DevCloud • リポジトリ、ビルドサーバ(CI)とテストサーバ、 バグトラッキングなどの開発環境はクラウドを使う。 これらのツール群はSupersonic向けに最適化された 標準構成のものを利用する(定額課金) • クラウドでテストされたものは、顧客企業のオンプ レミスなどに移行するか、顧客企業が望めばクラウ ドのままサービスインすることも出来る
• クラウドの開発環境はリリース後も顧客企業は利用 し続けることもできる COPYRIGHTS S.YOSHIHRA 27 Repository Build(CI) Bug Track Test Server Cloud
ビジネスモデル 28 COPYRIGHTS S.YOSHIHRA
成果型SIモデル • ユースケース定額は成果型SI – ユースケース数に定額単価を掛けて課金する – よって、人月型SIではなく、成果型SIである。よって、 技術革新によって生産性を向上すれば、その分の原 価を減らし、粗利を増やすことができる •
ユースケース定額単価は、競合他社に対して競争力 のある価格とする(高生産性であるから実現でき る) COPYRIGHTS S.YOSHIHRA 29 要件定義 開発 システムテスト 要件分析 アジャイル開発 システムテスト 競合他社 Supersonic
ユースケース定額 • 競合他社のモデル価格 – 業界標準FP生産性(20FP/MM)だと、要件定義を含 めて1UC=200万円程度になる • ユースケース定額単価 – 1UC
= 180万円 ※競合よりも割安 – Supersonic開発目標FP生産性(40FP/MM)だと、要件 分析も含めて105万円程度になるが、バッファとして 75万円を乗せる COPYRIGHTS S.YOSHIHRA 30 ※ユースケースによっては非常に難易度が高い可能性がある。それらの場合、例外的にユースケース定額 が適用されないケースはありえる。バッチも同様にユースケース分析をすることを想定しているが、バッ チによっては1つのユースケースでも難易度が高い可能性がある。複雑な集計処理や、ビッグ・データを 扱う場合などである。これらは、顧客への説明、提案書や契約書などに記載する
• ユースケース数が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 COPYRIGHTS S.YOSHIHRA Summary
まとめ • Supersonic Agile Developmentとは – Agile+Usecase+MDA+DDDの超音速開発 – 成果型SIモデル •
サービス(価値)は – ユースケース定額 – 生産性2倍(2x Speed) – 品質保証 • MDAツールで装備 • メトリクス(生産性、品質)を常に共有 • Cloudで開発環境を提供 COPYRIGHTS S.YOSHIHRA 33 ※具体的な生産性を謳うのは他にない
34 COPYRIGHTS S.YOSHIHRA Give us carrots!
Incentive novelty goods • “1.5x Speed”を達成したら – Supersonic Towel •
“2.0x Speed”を達成したら – Supersonic T-shirt • 更に、“3.0x Speed “を達成したら – Supersonic Character-Figure (その前にキャラクターを決めなきゃ) COPYRIGHTS S.YOSHIHRA 35