BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Agile-Architecture に関するすべてのコンテンツ

  • 関数型プログラミングによるレイトアーキテクチャ

    ソフトウェアアーキテクチャの多くのアプローチはアーキテクチャを最初に計画することを前提としている。残念ながら、この方法で計画されたアーキテクチャは、後で変更することが難しい。関数型プログラミングは、事前の計画を最小限にとどめ、アーキテクチャの決定を後から変更できる程度の疎結合を実現するのに役立つ。

  • システム設計はトップダウンかボトムアップか - Vaughn Vernon氏のMicroXchg Berlinでの講演より

    ソフトウェア設計は、トップダウン、ボトムアップ、どちらのアプローチで進めるべきだろうか?MicroXchg Berlinで行ったプレゼンテーションの中で、Vaughn Vernon氏はこのような質問をして、ソフトウェア設計におけるさまざまなアプローチ、アクタモデル、リアクティブなドメイン駆動設計、創発的アーキテクチャ(emergent architecture)などの重要性を論じた。

  • 包括的な視野を持ってJiraを効果的に利用する

    AtlassianのパートナであるDevInitのDzmitry Hryb</a>氏が先頃、Jiraのイシュー中心のモデルが結果として”マクロな視野”を欠いた近視眼的な見方をもたらしているとする,TechCrunchの主張に対する反論を公開した。アーキテクトのEltjo R. Poort氏とDevOpsリーダのMatt Saunders氏も先日,ビジョンとアーキテクチャの方向性を捉える上で最も適した他のツールとJiraを併用するためのパターンを紹介している。

  • Johanna Rothman氏 – アジャイルプロジェクトからプログラムへの拡張

    OnAgile 2016でのプレゼンテーションにて、Johanna Rothman氏は、既に組織にある非公式なコミュニケーションから作られる小規模な検討が、大きなプログラム運営への拡大に有効であると述べた。Rothman氏は、計画や設計、進捗測定のアドバイスを提供した。

  • どうアジャイルとアーキテクチャは袂を分かち、最後に友好関係を築いたか

    人々はアーキテクチャを定義すること、もしくはソフトウェア設計を行うことの必要性をアジャイル宣言の不正確な解釈のために止めてしまったと、Software Architecture for Developersの著者であるSimon Brown氏は主張した。多くのソフトウェア開発者はプラクティスの十分な工具箱を持っていると思っておらず、ソフトウェア業界にはソフトウェアアーキテクチャに対する十分な共通言語が欠落している。良いアーキテクチャはアジリティを高める。方向性を設定するための強固な基盤を構築するのに必要十分な事前設計が必要である。

  • 過剰なエンジニアリングを止めて、顧客が本当に必要とするものを作ろう

    多種多様なチームでの業務経験を経て、Greg Youngはプロジェクト内でチームはしばしば根本的に過剰なエンジニアリングを行うことを発見した。チームは9か月のプロジェクトを開始するが、異なる観点から問題を考えることにより95%の価値をほんの数週間で提供することが可能であるかもしれない、そうYoungはロンドンで最近開催されたDDD eXchangeの基調講演で主張した。

  • 進化的アーキテクチャの特徴

    進化的アーキテクチャの第一原則は非破壊的な変更をサポートすることだ。進化的アーキテクチャの特徴と原則についての記事でRebecca Parsons氏とNeal Ford氏はマイクロサービスアーキテクチャは、進化的アーキテクチャの優れた例になると書いている。彼らの考えではマイクロサービスはドメイン駆動設計(DDD)で言う境界付けられたコンテキストの原則に従うため、進化的アーキテクチャの原則に適う。

  • Spotifyにおけるマイクロサービス

    Kevin Goldsmith氏がGOTO Berlin 2015カンファレンスで,同社がマイクロサービスを使って達成したアーキテクチャ革新について講演した。モノシリックなアプリケーションと比べた場合,マイクロサービスはテストやデプロイ,監視が容易であると氏は主張する。製品間の依存性を可能な限り少なくする目標も持つSpotifyにとって,マイクロサービスは極めて有効なアーキテクチャだ。

  • 必要最小限のアーキテクチャとは

    この記事では,実行可能な最小限のアーキテクチャによる最小限の製品開発について,スタートアップ時のさまざまなフェーズでのアーキテクチャ仕様を含めて解説する。

  • アジャイルにおける計画作りの死

    企業がアジャイルを導入して、自己組織的なチームが生まれ始めると、マネジメントは制御を失ったと感じる可能性がある。アジャイルに移行すると、手続きやレビュー委員会、コンサルテーション委員会などが無駄になってしまう可能性がある。しかし、そのような立場になる人は無駄になってしまうことに気づかない、とMarcel Heijmans氏は言う。再び、制御を取り戻そうとすると、問題はもっと厄介になり、"プランニングの死"へと到る。

  • アジャイルでユースケースを利用する - ユースケース2.0,スライシング,ラミネーティング

    アジャイルソフトウェア開発を使って製品をインクリメンタルに開発し提供する場合,要件項目はプロダクトバックログに収集,整理される。ここで使用される要件定義テクニックはユースケースだ。アジャイルの製品要件管理でユースケースを利用するテクニックには,ユースケース2.0やスライシング,ラミネーティングなどがある。

  • Life PreserverとSpringを用いたヘキサゴナルアーキテクチャの実装

    Russ Miles氏は先日,システムにおける適用力の必要性と,それを達成する上で氏のヘキサゴナルアーキテクチャ実装が持つ有用性について,自身の意見と見解を発表した。さらにJavaとSpringベースのアプリケーションを用いて,そのようなシステムの実装方法の例証も行っている。

  • プロトタイプを捨てよう

    Udi Dahan氏は最近のブログ記事「捨てるものを作る」でソフトウェア開発者がよく直面する「ニワトリとタマゴ」の問題について議論している。顧客は必ず���も自分が求めているものを望んでおらず、ソフトウェアエンジニアと密にやりとりする必要がある一方で、このやりとりのために製品レベルのソリューションを構築するのはコストがかかる。

  • Grady Booch氏、英国コンピュータ協会より2012 Lovelace Medalを受賞

    英国コンピューター協会は「ソフトウェアアーキテクチャ、ソフトウェア工学、協調環境における革新的業績」によりGrady Booch氏にLovelace Medal 2012を授与した。

  • ThoughtworksのTechnology Radar 2012年3月版

    ThoughtWorksがTechnology Radarの最新版を公開した。このレポートはテクノロジーに関して意思決定する人が、ソフトウェア開発のテクニックやツール、言語、プラットフォームの新しいトレンドを理解するために作られている。アジャイルソフトウェア開発チームに対する関心について興味深い結果が示されている。

BT