[#Agile] アジャイル開発の課題と対策 その2
前回の続きです。対策を考えるとどのようになるか考えます。
以下の図ではDBとUIとしていますが、基盤部とUIでも構いませんし、全く異なる切り分けでも構いません。順序に関する制約があるなら、同じようなことを検討すると思います。
前回の復習
アジャイル開発の普及が遅れている理由として、以下の3点をあげました。
- 日本では データが変わると大変なことになる」と考えている DOAが普及している
- ビジネスを重視するRADが普及しなかった
- ルールの明確で複雑な基幹業務が多い
これらによって、逐次開発する事に対する危機感はある反面、必然性がなかった事になります。
そこで、解決策として、ベーム氏の「アジャイルと規律」から
- リーンやFDDなどのリスクベースのアジャイル手法と計画駆動を組み合わせる
- アーキテクチャ設計を予め行う
- 開発内容にあわせて計画駆動のチームとアジャイル開発のチームに分ける
の3つを取り上げ、さらに
- ビジネスの視点でアーキテクチャを考える
という提案をしました。
開発イメージ
今回は、アーキテクチャ設計後の開発をどのように行うかを考えてみます。
まずは基本イメージを見てみましょう。
WF(ウォーターフォール)は予めDB設計を行った上で、UIなど他の部分を開発するでしょう。アジャイル開発はDBとUIの開発を並行して行います。単純に考えるとこのようなイメージですが、実際はもう少し工夫しているでしょう。
現実のWFでは、DB設計が終わるまでにプロトタイプを開発しています。開発者を早めに投入する事でコミュニケーションを容易にし、DB設計が終わった後にすぐにUIの開発ができるようにします。
プロトタイプは性能などの評価、操作性の検討、 HTML作成(MayaaやWicketのようにHTMLがそのまま使えるフレームワークもありますね)、 横展開のひな形、部分的な本格実装、などが考えられます。WFなのでこの期間には各種設計書も書かれるでしょう。
現実のアジャイル開発では、ストーリ単位で開発されますので、DB設計とUI設計が交互に行われるでしょう。ある程度仕様が固まるまでDBは構築せず、モックで開発を進めるかもしれません。
アジャイル開発では単純に優先度の高い順に開発すると思われるかもしれませんが、手戻りのリスクも考える必要があります。早く実装するとリスクの下がるものと上がるものがありますので、リスクを考慮して開発順序を決めます。
チームに分ける場合は、WFとアジャイル開発を組み合せます。粗な関係で分離できるなら、インタフェースだけを決めておいて単純な組合せで独立して開発できるかもしれません。
もし、開発法で分けられないなら、DBチームとUIチームに分ける方法もあります。UIは共通処理の開発やモックによる開発などをすすめ、DBは早めに決めるべき所から設計します。チームは厳密に分けてしまうと、作業の融通が利かなくなりますので注意してください(多能工ではなくなりますので、アジャイル開発のアンチパターンですね)。
まとめ
この他にも色々な組合せがあると思います。単純にこの方法が良いというものではなく、ベーム氏の5つの重要要因にあるように、開発対象の業務や規模、メンバーのスキルなども考慮すべきだと思います。
物事を2元論的に捉えると、違いが明確になってわかりやすいという効果があります。しかし、ソフトウェア開発は複雑な作業の組合せであるほか、業務と直結していますので、「試してみる」ということはなかなかできません。
プロジェクトを成功させるには「xxと言われているから」ではなく、具体的なイメージができる程度には理解が必要です。なぜそのようになるかを理解し、チームの能力を最大限に生かすべく、様々な工夫を凝らす事が、大切だと思います。(続く)
« [#Agile] アジャイル開発の課題と対策 その1 | トップページ | [#Agile] アジャイル開発の課題と対策 その3 - チケットコミュニケーション - #TiDD »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
コメント
この記事へのコメントは終了しました。
« [#Agile] アジャイル開発の課題と対策 その1 | トップページ | [#Agile] アジャイル開発の課題と対策 その3 - チケットコミュニケーション - #TiDD »
事実はそんなに高尚ではないのではないですか?
一括請負型のSI受注が開発工数が見積もり時に決定できない多くのアジャイル手法を嫌い、従来型に固執した原因だと思いますよ。
近年、SI案件が大幅に減少していると聞きます。そこでSIベンダは一定の人を顧客に買い取らせる契約として、アジャイル型という契約形態を持ち出してきたのだと考えています。
それと、昔は強かったシステム部が解体してしまって、いまや自分たちの作りたいシステムの案件もまとめられなくなっていると聴きますので、その点でも一括受注はしたくないのでしょう。
また、昔に戻りましたね。
投稿: おおの | 2013年8月 1日 (木) 14時34分
コメントありがとうございます。
以下にも書きましたが、私もそのように見ています。
ビジネスだけではなく、技術的にどうするかが大切なのだと思います。
[#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう
http://sakaba.cocolog-nifty.com/sakaba/2012/12/tidd-74ba.html
[#TiDD] アジャイル開発が注目される理由
http://sakaba.cocolog-nifty.com/sakaba/2012/04/tidd-788b.html
投稿: さかば(阪井) | 2013年8月 1日 (木) 17時45分