BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース ThoughtworksのTechnology Radar 2012年3月版

ThoughtworksのTechnology Radar 2012年3月版

ブックマーク

原文(投稿日:2012/03/22)へのリンク

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

「Techniques」「Platforms」「Tools」「Languages」の4つの領域に分けて、各アイテムの現状のポジションが示されている。

    • Adopt: 私たちはこれらのアイテムを導入すべきだと強く感じています。私たちのプロジェクトでも適切なときに使っています。
    • Trial: 動向を追いかける価値があります。どう活用できるか理解しておくことが重要です。うまくリスクをハンドリングできるプロジェクトの中で試してみるべきです。
    • Assess: どう影響するか理解するために、調べる価値があります。
    • Hold: 注意しはじめましょう。

「Techniques」領域では、創発デザインと進化的アーキテクチャがAdoptレベルの端に置かれた。

創発デザインには少なくとも2つの面があります。最終責任時点のリーンソフトウェア原則、これは主に未開発のプロジェクトに適用されます。慣習的パターンの発見と収穫、これは既存のプロジェクトに適用できます。私たちは進化的アーキテクチャを伝統的な事前の重量級のエンタープライズアーキテクチャ設計の代わりに採用することを推奨します。

予想通り、DevOpsと継続的デプロイメントもAdoptレベルに置かれており、Assessレベルに置かれたエクスペリエンスデザイン(XD)といったテクニックを促進しているようだ。

エクスペリエンスデザイン(XD)というのは、アジャイルが実世界の制約に適応するよう進化した一例です。伝統的な事前のエクササイズのようなものを継続的デリバリーのようなプラクティスに組み込む革新的な方法を見つけることに常に関心をもっています。XDはすばらしい研究領域です。

AsessおよびTrialレベルにあるテクニックは、コミュニティにおける継続的デリバリーへの注目によって促進されている。これにはシングルコマンドデプロイや、プロダクション免疫システム、開発ワークステーションのインフラ自動化、Windowsインフラ自動化(PowerShellPuppetChefといったツールにフォーカスしている)が含まれる。

テストの観点からは、適正レベルでテストすることが、コミュニティにおける高度なブラウザベースのテストへの注目を反映して、Adoptレベルに登場した。これに関連して、テストレコーダーもHoldレベルに登場した。User journeyはTrialレベルの高い位置へと移動している。

User journeyとは、... ユーザストーリーをユーザとビジネスの両方に価値を提供するユーザインタラクションの集合にグルーピングしたものです。これをまとめて自動化することは、長期にわたって意図を保ったテストへとつながります。こうしたテストに失敗することは、アプリケーションがユーザに具体的な価値を届けられていないことを明らかにしてくれます。

反復的データウェアハウスはこのバージョンで消えたが、Trialレベルにあるアジャイル分析に置き換えられた。Scrum認定は引き続きHoldレベルを維持している。

「Tools」領域では、引き続きインフラをコードとして扱うこと(Infrastructure as code)とバージョン管理ツールGitとGithubがAdoptレベルに置かれている。Java界で人気のあるビルドツール MavenはHoldレベルに置かれた。

Mavenは長い間Javaにおけるビルド自動化の要になってきました。しかし、柔軟性と自動化、特に継続的デリバリードメインのベストプラクティスに欠けていることを考慮すると、Gradleのような代替案も検討すべきです。

「Platforms」領域で重要なもののひとつに、このバージョンでAdoptレベルに置かれた、ハードウェアチームとソフトウェアチームのコミュニケーションがある。

よく見かけるけれども高くつく壊れたフィードバックループというのは、ハードウェアに責任のある人とソフトウェアに責任がある人のコミュニケーション不足です。最終成果物はコストがかかるのに価値のないものになります。あなたはアーキテクチャを全体的な視点で見なければなりません。ハードウェア視点だけ、ソフトウェア視点だけでは不十分です。単独でうまくいくことはありません。

「Languages」領域では、Adaptレベルにある言語に注意しよう。

現在の選択に残されたライフタイムを見積もりながら、あなたの組織を助ける言語を評価すべきときです... 伝統的な個別のサポートチームがある構造化された組織ではスキル選択を強いられると思うかもしれません。DevOpsが道を提供してくれます。

Technology Radarのフルバージョン(過去のレポートも含む)はThoughtWorksのWebサイトから入手できる。あなたの組織やチームは自分のレポートを作っているだろうか?(Trialレベルのテクニックとして推奨されている) このレポートの最新版について、何か驚きや抜けはあるだろうか?

この記事に星をつける

おすすめ度
スタイル

BT