タグ

ブックマーク / sakaba.cocolog-nifty.com (5)

  • アジャイル開発の理解に必要な3つの視点 - ソフトウェアさかば

    先日公開された、JEITAの企業ITに関する日米調査の記事を見ていると、日ITのマーケットを開発する意欲に欠けている事がよくわかります。これは、諸外国ではITでマーケットを開拓する方法としてアジャイル開発が常識であるのに対して、日ではアジャイル開発に対する理解が不十分([#Agile] アジャイル開発の課題と対策 その1)なためにこのような状況になっているのだと思います。 アジャイル開発はすでにアーリーアダプタの技術ではなく、一般的な技術としてCMMIやPMBOKでもアジャイル開発について書かれています。このような普及の理由は、XPなどのプラクティスの技術的側面やアジャイル宣言に見られるマインドなどの単純な視点では説明できません。開発、プロセスのルーツ、ビジネスの3つの視点が必要です。 【開発の視点】 開発の視点でアジャイル開発をみると、オブジェクト指向の流れを汲む最新の考え方や技術

    アジャイル開発の理解に必要な3つの視点 - ソフトウェアさかば
    sugimori
    sugimori 2014/05/09
  • ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 - - ソフトウェアさかば

    ドメイン駆動設計(DDD)とはなにか? それを知るには「ドメイン」という言葉の定義を知る必要があります。一般にドメインエキスパートが出てくる文脈でドメインというと業務ドメインを指しています。そして業務ドメインというと業務分析の対象になっています。 しかし、今回の関西IT勉強宴会 ドメイン駆動設計を知ろうの議論を通じて、 ドメイン駆動設計でいうドメインと業務分析でいうドメインが異なっている事がわかりました(参考: 2013-12-13(金)第28回関西IT勉強宴会 ドメイン駆動設計を知ろう(関西IT勉強宴会のブログです)、ドメイン駆動設計に出てくる「モデル」とは何ですか?(プログラマの思索))。 業務分析の対象となるドメイン 議論中の言葉をお借りすると、DOAで行う業務分析では、管理レベルからドメインを見ます。ユースケースによってシステムの内側と外側の境界を定めて、その内部を開発します。 I

    ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 - - ソフトウェアさかば
    sugimori
    sugimori 2014/04/23
    DOAとの違いがわからんかった
  • [#Agile] アジャイル開発の課題と対策 その1 - ソフトウェアさかば

    アジャイル開発が日で知られるようになって10年以上経ちました。去年、あるいは一昨年からアジャイル開発2次ブームになって、大手ベンダーが取り組みを始めるようになりました。たぶん、今回は一定の広がりを見せると思います。 しかし気になるのは「なぜ、普及が遅れたか?」です。アジャイル開発の特長は数多くありますが、コード優先の繰り返し、テスト自動化、 現場能力発揮、顧客優先、いずれも大きな障害と考えにくく、 そのいずれを考えても遅れた説明がつきにくいと思っています。 関連する文献 そこで思い出したのは、児玉さんの「UMLモデリングの質」に書かれた一文でした。 1990年代に入って、世界では構造化分析/設計手法がオブジェクト指向分析/設計手法に取り込まれました<中略>。一方、日では、情報システムをWebアプリケーションで作成する事が主流になる2000年までは、DOA型の構造化分析/設計手法が依然

    [#Agile] アジャイル開発の課題と対策 その1 - ソフトウェアさかば
    sugimori
    sugimori 2013/08/22
    『 DOA型の構造化分析/設計手法が依然として優勢であり、オブジェクト指向への取り組みが進みませんでした。』なるほど。今でもあるかも。
  • [#TiDD] アジャイル開発が注目される理由 - ソフトウェアさかば

    最近、大手ベンダーのアジャイル開発への取り組みがニュースになっています。アジャイル開発がいよいよ普及期に入ってきたという印象を受けました。それと共に、それがこれまでのアジャイルコミュニティの言っていたアジャイルと同じものなのか、あるいは別のものなのか、とても気になるところです。それはそれで大切ですが、ここでは、なぜ大手ベンダーがアジャイル開発に取り組もうとしているかを考えてみたいと思います。 従来の開発法 いわゆるウォーターフォール開発では、あらかじめ要件となる仕様を確定して、そのシステムの実現を請け負う方法です。「不確実コーン」(リンク先はAct as Professional)で考えていただければわかりますが、これはリスクの高い方法です。 リスクの高い場合には、保険のビジネスが成り立ちます。大きな問題の起きる可能性のある場合には、個別のリスクを抱える顧客に対して平均的なリスク(発生確率

    [#TiDD] アジャイル開発が注目される理由 - ソフトウェアさかば
    sugimori
    sugimori 2012/04/24
    アジャイル開発はリスクマネジメントという言葉を思い出した。ここをもっと掘り下げるといろんな人に説明しやすくなるかな。
  • [#TiDD] ツールでできること - ソフトウェアさかば

    チケット駆動開発を検討されてる方にお話をした際に、あまりにも積極的な方に 「チケット駆動開発で解決できる問題がない場合や、イメージできない場合は失敗するのでやめてください。まずは障害管理から始めてください。」 とお話をしたことがあります。チケット駆動開発は、単に「BTSを入れれば開発が楽になる」といった類のものではありません。BTSを導入した上で、その機能を生かしてチケット駆動開発を実践し、プロジェクトの問題を解決しなければ、効果は得られません。 もちろんチケット駆動開発で解決できる問題が、存在していなければ効果はありませんし、よくわからないままプロジェクトに導入しても、改善できたかどうか、たぶんわからないでしょう。幸いなことに、もし障害管理ツールを初めて導入されるなら、それだけでも情報の一元化や情報共有、履歴の保存、構成管理ツールとの連携など、様々なメリットがあります。まずは障害管理ツー

    [#TiDD] ツールでできること - ソフトウェアさかば
    sugimori
    sugimori 2011/09/01
    ツールを導入することが目的になりがちですよね。
  • 1