Download to read offline
Supersonic agile
- 1. Supersonic Agile Development 1 S.Yoshihara 2013/3/13 2x Speed
- 2. Agile is sofast, but・・・ • アジャイル開発はプラクティスを効果的に組み合わせる ことによって、開発チームの生産性を最大限に引き上げ ることができる • しかし、要件を決める側にはこれとったプラクティスは なく、アジャイルのスピードにあわせて忙しなく重要な 要件も決める必要がある。複雑なシステムになれば、ス トーリーや画面だけでは仕様の是非を判断できない • つまり、開発は超高速で走っているが、要件は目先の判 断になってしまい、全体俯瞰では見当違いな方向に走っ ている可能性があるということである COPYRIGHTS S.YOSHIHRA 2
- 3. Agile+Usecase • まず、要件分析を全体俯瞰で体系的に行うために ユースケース分析を行う。ただし、アジャイルとは スピードが違うので非同期にタスクが組めるように する COPYRIGHTS S.YOSHIHRA3 ユースケース分析要件分析 アジャイル 開発 ユースケース分析が終わったものからアジャイル開発を行う。 ユースケース分析とアジャイル開発は非同期に行えるように別チー ムとする ユースケース分析はユースケース一覧の優先度が高いものから行 う。ユースケース分析が終わったものからアジャイル開発を行う ユースケース分析ではユースケース図ではなくユースケース記述 を使う
- 4. Agile+MDA+DDD=“Supersonic speed” • MDA（ModelDriven 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.
- 7. サービス • ユースケース定額（Pay perusecase） – 生産性の責任は開発側が負担すべきと考え、ユース ケース当たりの価格は定額とする。計画よりも生産 性が低かった場合でも追加料金は請求しない – 開発総額はユースケース数に固定単価を掛けあわせ て算出する。開発中にユースケースが増えた場合は 追加料金が発生する – 契約形態は請負・準委任ともに可能とする。どちら もユースケース一覧を作成して見積りをする。請負 ではユースケース数を先に決め、開発途中で未開発 のユースケースは入れ替えることができる – ユースケース定額にすればアジャイル開発でも請負 （事前にコストを決めるという意味で）が可能にな る COPYRIGHTS S.YOSHIHRA 7
- 8. サービス • 生産性2倍（2x Speed） –業界標準のメトリクスをもとに独自に調査した標準 的な生産性を基に、2倍の生産性を基準とする – 基準生産性に達成しなくても、ユースケース定額な ので追加料金は発生しない。その分、期間バッファ は適切に設定する • 品質保証 – 不可能なものを除いて全てのモジュールはテスト自 動化を行う（更にテスト観点によって手動によるテ ストも行う） – 開発費用に定率を上乗せすることで、瑕疵担保期間 を延長することができる COPYRIGHTS S.YOSHIHRA 8
- 9. サービス • メンバー保証 – Supersonicを習熟したメンバーだけで編成する。安い だけのオフショアなどはもっての外である •まる見え保証 – 進捗、課題、生産性、品質指標は全て見える化する。 当然、これらのデータは顧客企業と開発側で全く同 じものを参照する COPYRIGHTS S.YOSHIHRA 9
- 10.
- 11. • ユースケース数が100個のプロジェクトを想定する – SupersonicAgile Development • 総開発工数：79人月 – 従来型（ウォーターフォール） • 総開発工数：129人月 要件定義 : 14MM 工数を小さく、期間は短く COPYRIGHTS S.YOSHIHRA 11 ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 ※一般的に、人員は同時投入する程、生産性は落ちるため、上の例では無理なく人員を投入した場合を想定し ている
- 12.
- 13. ユースケース分析 • ユースケース分析では、ユースケース図ではなく、 ユースケース記述を作成する • ユースケース記述とは別カタログとしてビジネス ルールを定義する。ビジネスルールはユースケース 横断的に参照されることになる COPYRIGHTSS.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.
- 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.
- 26. メトリクス • 生産性 – スプリント完了時にリポジトリにコミットしたソー スコードから半自動的にFPを計測する –生産性は、スプリント毎、開発者毎に全て計測する。 スプリントによる生産性の傾向と予測まで行う – ユースケースのシナリオ数、ビジネスルール数、画 面数などと生産性との相関も全て自動的に計測する • 品質指標 – 全モジュールのカバレッジを計測する – 全ての自動テストの結果を集計する – システムテストのバグ傾向分析や、ユースケース単 位のバグ傾向分析を行い、レポートする COPYRIGHTS S.YOSHIHRA 26
- 27. DevCloud • リポジトリ、ビルドサーバ（CI）とテストサーバ、 バグトラッキングなどの開発環境はクラウドを使う。 これらのツール群はSupersonic向けに最適化された 標準構成のものを利用する（定額課金） • クラウドでテストされたものは、顧客企業のオンプ レミスなどに移行するか、顧客企業が望めばクラウ ドのままサービスインすることも出来る •クラウドの開発環境はリリース後も顧客企業は利用 し続けることもできる COPYRIGHTS S.YOSHIHRA 27 Repository Build(CI) Bug Track Test Server Cloud
- 28.
- 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個のプロジェクトを想定する – SupersonicAgile Development • 総開発工数：79人月 = 開発総額1.8億円 – 従来型（ウォーターフォール） • 総開発工数：129人月 = 開発総額1.94億円 総額でも割安で、期間は短く COPYRIGHTS S.YOSHIHRA 31 要件定義 : 14MM ユースケース分析 : 14MM アジャイル開発 : 50MM システムテス ト 15MM 開発 : 100MM システムテス ト 15MM 期間短縮 1.8億 1.94億
- 32.
- 33. まとめ • Supersonic AgileDevelopmentとは – Agile+Usecase+MDA+DDDの超音速開発 – 成果型SIモデル • サービス（価値）は – ユースケース定額 – 生産性2倍（2x Speed） – 品質保証 • MDAツールで装備 • メトリクス（生産性、品質）を常に共有 • Cloudで開発環境を提供 COPYRIGHTS S.YOSHIHRA 33 ※具体的な生産性を謳うのは他にない
- 34. 34COPYRIGHTS S.YOSHIHRA Give uscarrots!
- 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