Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SuperSonicAgile

 SuperSonicAgile

SuperSonicAgile

shoyoshi

March 13, 2013
Tweet

More Decks by shoyoshi

Other Decks in Technology

Transcript

  1. Agile is so fast, but・・・ • アジャイル開発はプラクティスを効果的に組み合わせる ことによって、開発チームの生産性を最大限に引き上げ ることができる •

    しかし、要件を決める側にはこれとったプラクティスは なく、アジャイルのスピードにあわせて忙しなく重要な 要件も決める必要がある。複雑なシステムになれば、ス トーリーや画面だけでは仕様の是非を判断できない • つまり、開発は超高速で走っているが、要件は目先の判 断になってしまい、全体俯瞰では見当違いな方向に走っ ている可能性があるということである COPYRIGHTS S.YOSHIHRA 2
  2. Agile+Usecase • まず、要件分析を全体俯瞰で体系的に行うために ユースケース分析を行う。ただし、アジャイルとは スピードが違うので非同期にタスクが組めるように する COPYRIGHTS S.YOSHIHRA 3 ユースケース分析

    要件分析 アジャイル 開発 ユースケース分析が終わったものからアジャイル開発を行う。 ユースケース分析とアジャイル開発は非同期に行えるように別チー ムとする ユースケース分析はユースケース一覧の優先度が高いものから行 う。ユースケース分析が終わったものからアジャイル開発を行う ユースケース分析ではユースケース図ではなくユースケース記述 を使う
  3. Agile+MDA+DDD=“Supersonic speed” • MDA(Model Driven Architecture)ツール – 要件分析のモデルをアジャイル開発まで確実に伝達 し、速やかに開発を行うためには支援ツール群が必 要である。MDAの考え方はそれを実現するためのも

    のである。生産性を向上させるためにMDAも適用す る – ただし、ビヘイビア(Behavior)はプログラミングす る方が効率が良いので扱わない • DDD(Domain Driven Design)のコンセプト – DDDを全面的に適用するのではなく、モデルをそのま ま実装に繋げるコンセプトを、MDAツールと組み合 わせて利用する COPYRIGHTS S.YOSHIHRA 4
  4. • Tech Features – Agile – Usecase – MDA (Model

    Driven Architecture) – DDD (Domain Driven Design) • “Supersonic Agile Development” – 上記の高度な技術を最適に組み合わせにすることで、 超高生産性なシステム開発を実現する – この技術を使いこなすためには、必要なスキルと ツールを備えた専門チームが必要である Supersonic Agile Developement COPYRIGHTS S.YOSHIHRA 5
  5. Overview COPYRIGHTS S.YOSHIHRA 6 ユースケース一覧 MDAツール モデルとソースコード の差分抽出と同期支援 アジャイル開発 (実装+単体テス

    ト) システムテスト リリース イテレーション (スプリント) 要件分析 ユースケース分析 ドメインモデル (DDD) 優先度の高い ものから分析 分析済で、優先度 の高いものから開 発 開発済のものが、 リリースできる単 位になった場合 セキュリティ、負 荷、障害テストな ども行う 要件分析チーム 開発チーム プロダクトオーナー ユースケースの分析済、開発済 などのステータスを管理する。 更に、ユースケースに優先度を 付けることで計画、スコープ管 理に使う(プロダクトバックロ グ相当)
  6. サービス • ユースケース定額(Pay per usecase) – 生産性の責任は開発側が負担すべきと考え、ユース ケース当たりの価格は定額とする。計画よりも生産 性が低かった場合でも追加料金は請求しない –

    開発総額はユースケース数に固定単価を掛けあわせ て算出する。開発中にユースケースが増えた場合は 追加料金が発生する – 契約形態は請負・準委任ともに可能とする。どちら もユースケース一覧を作成して見積りをする。請負 ではユースケース数を先に決め、開発途中で未開発 のユースケースは入れ替えることができる – ユースケース定額にすればアジャイル開発でも請負 (事前にコストを決めるという意味で)が可能にな る COPYRIGHTS S.YOSHIHRA 7
  7. サービス • 生産性2倍(2x Speed) – 業界標準のメトリクスをもとに独自に調査した標準 的な生産性を基に、2倍の生産性を基準とする – 基準生産性に達成しなくても、ユースケース定額な ので追加料金は発生しない。その分、期間バッファ

    は適切に設定する • 品質保証 – 不可能なものを除いて全てのモジュールはテスト自 動化を行う(更にテスト観点によって手動によるテ ストも行う) – 開発費用に定率を上乗せすることで、瑕疵担保期間 を延長することができる COPYRIGHTS S.YOSHIHRA 8
  8. • ユースケース数が100個のプロジェクトを想定する – Supersonic Agile Development • 総開発工数:79人月 – 従来型(ウォーターフォール)

    • 総開発工数:129人月 要件定義 : 14MM 工数を小さく、期間は短く COPYRIGHTS S.YOSHIHRA 11 ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 ※一般的に、人員は同時投入する程、生産性は落ちるため、上の例では無理なく人員を投入した場合を想定し ている
  9. ユースケース一覧(Product Backlog) • 要件分析とアジャイル開発を非同期に並行して行う ために、ユースケース一覧がバックログの役割を果 たす • 要件分析がボトルネックにならないように生産性と 担当数を最適化しなければならない COPYRIGHTS

    S.YOSHIHRA 14 ユースケース分析 要件分析 アジャイル開 発 ユースケース一覧 ユースケース ユースケース 未分析なものを、ユー スケース分析する ユースケース分析が終わっ たものは分析済にする 未分析 分析済 優先度に応じて、ユース ケース分析やアジャイル開 発するユースケースを選択 する ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース ユースケース 分析済のものをア ジャイル開発する 開発済
  10. ユースケース標準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
  11. 開発目標生産性 • 業界標準FP生産性の2倍を目標とする • 業界標準FP生産性 – 20FP/MM(基本設計~ 結合テスト) • Supersonicの開発目標生産性

    40FP/MM COPYRIGHTS S.YOSHIHRA 16 •15FP/MM(基本設計~総合テスト) (出典: SEC:ソフトウェア開発データ白書2012-2013) 上記の業界標準FP生産性では総合テストまで含まれている が、Supersonicのアジャイル開発は結合テストまでである。 よって、業界標準FP生産性から総合テストを除いた生産性 を仮定する
  12. 要件分析生産性と担当数比率 • 要件分析生産性 – 7UC/MM (過去の経験より) • 開発目標生産性 ※前述 –

    ユースケース規模を1UC = 20FPと仮定する – 40FP/MM = 2UC/MM • 要件分析・開発担当数比率 3.5 ≧ 開発担当数/要件分析担当数 ※つまり、開発よりも要件分析の生産性を高めにする ことでボトルネックを回避する COPYRIGHTS S.YOSHIHRA 17
  13. チーム制 • Supersonicは専門チームのみが提供できるサービス である。専門チームの基本構成は次にように決める – Supersonicチーム(10名) • マネージャ: 1名 (兹プロダクトオーナー支援)

    • 要件分析チーム:3名 (ドメインモデラー1名含む) • 開発チーム: 5名 • アーキテクト: 1名 ※プロジェクト特性に応じてサポートが追加になることはある (例えば、最近だとHadoopのようなスペシャリストが必要 な分野) • プロジェクトの規模に応じて、n個のチームを組み 合わせる(例えば、20人が必要なら、2チーム編成 とする) COPYRIGHTS S.YOSHIHRA 18
  14. アジャイル開発 • スクラムベースのアジャイル開発を行う • スプリントは2週間を単位とする。標準編成のチー ムには開発者は5名なので、1スプリントあたり、 5UCが完成することになる • スプリント計画では、ユースケース一覧から分析済 の5UCを優先度に従って選択する(大きすぎるユー

    スケースが無いことを開発チームで確認する) • 他、アジャイルプラクティスを実践する COPYRIGHTS S.YOSHIHRA 19 1週目 2週目 1 スプリント 1ユースケース 1週目 2週目 1 スプリント 1ユースケース スプリント ▼計画 スプリント ▼計画
  15. 生産性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
  16. MDA(Model Driven Architecture) • 一般的なMDAと同じように、要件分析で作成したモデル からソースコードを出力し、ソースコードに実装するま でをシームレスに行えるようにする • 最新のモデルがソースコードに反映されては困るケース もあるので、スプリント毎のブランチ管理をMDAツール

    が行う • モデリングツール(astahやEA)のプラグイン、開発環境 (eclipse)のプラグインを用意する COPYRIGHTS S.YOSHIHRA 22 ユース ケース ビジネス ルール ドメイン モデル モデリングツール MDA ツー ル ソースコード (開発中) 開発環境 リポジト リ
  17. DDD(Domain Driven Design) • DDDの必要性 – Supersonicのような要件分析と開発が同時並行に行わ れる場合には、要件分析のモデルとソースコードが 1対1に対応付くことは最重要である(逆に言えば、 TransactionScriptは採用できない)

    • EvansのDDD – Eric EvansのDDDは名著である。扱われている話題も広 範囲に渡る。最も重要なのは、ドメインに業務知識 が適切に表現されていて、そのままコードに定義さ れることである – 業務知識であるビジネスロジックをエンティティに 定義することで、ビジネスロジックをDRYに保てる COPYRIGHTS S.YOSHIHRA 23
  18. DDDのポイント • ビジネスロジックをSQLで書いてはいけない? – ビジネスロジックをドメインが隠蔽していれば、そ のロジックがJavaなのかSQLなのかはクライアントに は関係ない – ドメインレイヤーとインフラストラクチャレイヤー の境界が、教科書的見地から曖昧になるのは大きな

    問題ではない – 躊躇せず、SQLを利用すべきである • JOINはタブーなのか? – JOINの是非は、DDDの目的である業務知識の適切な実 装ということと無関係である – JOINのロジックをドメインが隠蔽し、JOINの結果をバ リューオブジェクトで返せば良い(何の遠慮がある ものか) COPYRIGHTS S.YOSHIHRA 24
  19. メトリクス • 生産性 – スプリント完了時にリポジトリにコミットしたソー スコードから半自動的にFPを計測する – 生産性は、スプリント毎、開発者毎に全て計測する。 スプリントによる生産性の傾向と予測まで行う –

    ユースケースのシナリオ数、ビジネスルール数、画 面数などと生産性との相関も全て自動的に計測する • 品質指標 – 全モジュールのカバレッジを計測する – 全ての自動テストの結果を集計する – システムテストのバグ傾向分析や、ユースケース単 位のバグ傾向分析を行い、レポートする COPYRIGHTS S.YOSHIHRA 26
  20. 成果型SIモデル • ユースケース定額は成果型SI – ユースケース数に定額単価を掛けて課金する – よって、人月型SIではなく、成果型SIである。よって、 技術革新によって生産性を向上すれば、その分の原 価を減らし、粗利を増やすことができる •

    ユースケース定額単価は、競合他社に対して競争力 のある価格とする(高生産性であるから実現でき る) COPYRIGHTS S.YOSHIHRA 29 要件定義 開発 システムテスト 要件分析 アジャイル開発 システムテスト 競合他社 Supersonic
  21. ユースケース定額 • 競合他社のモデル価格 – 業界標準FP生産性(20FP/MM)だと、要件定義を含 めて1UC=200万円程度になる • ユースケース定額単価 – 1UC

    = 180万円 ※競合よりも割安 – Supersonic開発目標FP生産性(40FP/MM)だと、要件 分析も含めて105万円程度になるが、バッファとして 75万円を乗せる COPYRIGHTS S.YOSHIHRA 30 ※ユースケースによっては非常に難易度が高い可能性がある。それらの場合、例外的にユースケース定額 が適用されないケースはありえる。バッチも同様にユースケース分析をすることを想定しているが、バッ チによっては1つのユースケースでも難易度が高い可能性がある。複雑な集計処理や、ビッグ・データを 扱う場合などである。これらは、顧客への説明、提案書や契約書などに記載する
  22. • ユースケース数が100個のプロジェクトを想定する – Supersonic Agile Development • 総開発工数:79人月 = 開発総額1.8億円

    – 従来型(ウォーターフォール) • 総開発工数:129人月 = 開発総額1.94億円 総額でも割安で、期間は短く COPYRIGHTS S.YOSHIHRA 31 要件定義 : 14MM ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 1.8億 1.94億
  23. まとめ • Supersonic Agile Developmentとは – Agile+Usecase+MDA+DDDの超音速開発 – 成果型SIモデル •

    サービス(価値)は – ユースケース定額 – 生産性2倍(2x Speed) – 品質保証 • MDAツールで装備 • メトリクス(生産性、品質)を常に共有 • Cloudで開発環境を提供 COPYRIGHTS S.YOSHIHRA 33 ※具体的な生産性を謳うのは他にない
  24. Incentive novelty goods • “1.5x Speed”を達成したら – Supersonic Towel •

    “2.0x Speed”を達成したら – Supersonic T-shirt • 更に、“3.0x Speed “を達成したら – Supersonic Character-Figure (その前にキャラクターを決めなきゃ) COPYRIGHTS S.YOSHIHRA 35