SuperSonicAgile

SuperSonicAgile

Transcript

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. 12 COPYRIGHTS 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生産性の２倍を目標とする • 業界標準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. 生産性２倍（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. 21 COPYRIGHTS 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のような要件分析と開発が同時並行に行わ れる場合には、要件分析のモデルとソースコードが １対１に対応付くことは最重要である（逆に言えば、 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. 25 COPYRIGHTS 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. ビジネスモデル 28 COPYRIGHTS 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 ※ユースケースによっては非常に難易度が高い可能性がある。それらの場合、例外的にユースケース定額 が適用されないケースはありえる。バッチも同様にユースケース分析をすることを想定しているが、バッ チによっては１つのユースケースでも難易度が高い可能性がある。複雑な集計処理や、ビッグ・データを 扱う場合などである。これらは、顧客への説明、提案書や契約書などに記載する
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. 32 COPYRIGHTS S.YOSHIHRA Summary
33. まとめ • Supersonic Agile Developmentとは – Agile+Usecase+MDA+DDDの超音速開発 – 成果型SIモデル • サービス（価値）は – ユースケース定額 – 生産性2倍（2x Speed） – 品質保証 • MDAツールで装備 • メトリクス（生産性、品質）を常に共有 • Cloudで開発環境を提供 COPYRIGHTS S.YOSHIHRA 33 ※具体的な生産性を謳うのは他にない
34. 34 COPYRIGHTS 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