InfoQ ホームページ Agile に関するすべてのコンテンツ
-
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
デザインとコードレビューに関する興味深い記事でKirk Knoernschild氏は、レビューを行うということは、ソフトウェアの品質を改善することを約束し、基準の順守を保証し、そして価値ある開発者の教育ツールとなると述べている。しかしながら、レビューの実施方法にその効果は左右される。レビューは、ある組織ではソフトウェア開発工程で本当に意味のあるものであるかもしれないが、その一方で別の組織では形式的なお役所仕事の一部となってしまっているかも知れない。
-
Article: ３つのM - リーンの３要素
リーン主義をソフトウェア開発に適用することについての議論では、主にムダ（無駄：Muda）なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ（無理：Muri）とムラ（ばらつき：Mura）を削除することも目指しています。
-
拡張照会機能およびユーザ文書を備えたDbFit 1.0
近ごろGojko Adzic氏がDbFitのバージョン1.0のリリースを発表した。それは、データベースコード上でTDDを実行する際に使用されるFIT/FitNesse拡張機能である。
-
Article: XMLをユニットテストする
XMLUnitはBSDライセンスの下で認可されたオープンソースプロジェクトです。XMLUnitは相関クラ��の小さなライブラリを提供しますが、それは、前のセクションで概説された幾つかのXMLをテストする異なった方法のそれぞれを簡素化します。
-
テストと復元性をめぐる議論: オブジェクト指向 vs. 関数型プログラミング言語
Michael Feathers氏の最新の投稿をめぐり、ブログのコミュニティ上で活発な議論が行われた。Feathers氏は、オブジェクト指向プログラミング言語に組み込まれた機能を使うと、テストが容易に行うことができ、コードの復元性を簡単に高めることができると主張した。
-
ベッドタイムユーザストーリー: カウボーイとおとぎ話
「ソフトウェアエコノミストで国際的なコンサルタント」を自称するDavid Longstreet氏が、昨年、アジャイルソフトウェア開発はおとぎ話で、ただ「カウボーイ」開発を正当化しようとしているだけだと主張する論文を発表した。
-
Cockburn氏テスティングを語る: 本物のプログラマにはガッツ(GUTs)がある
Alistair Cockburn氏は、InfoQのビデオ記事「Coplien and Martin Debate TDD, CDD and Professionalism」に対するフォローアップ記事を自身のブログへ投稿した。その中で氏は、いかに多くの人たちがTDDを誤解しているかについて言及している。
-
プラグマティックが止まらない ――「現実駆動開発」のススメ
ソフトウェアアーキテクトであるGustavo Duarte氏が、物理学者Richard Feynman氏によるスペースシャトル・チャレンジャーの爆発事故に関する調査結果について、優れたソフトウェアの工学的側面との関連を論じたところ、そのことが物議をかもした。
-
BPTrendsおよびBEAの調査が「The State of BPM in 2008」を検討
数週間前、BPTrendsおよびBEAによって「The State of BPM in 2008」に関する2件の重大な報告書が発表された。その報告書は、主要なSOAインフラストラクチャーベンダー主導の急成長市場、BPMNの導入の大幅な伸び、およびBPELの安定した成長についてまとめている。BPMアプローチ導入の要因は、コストのセーブからエンタープライズアプリケーションで、なくなった機能性の相殺に及ぶ。
-
スクラムマスターがブロッカーとなるのは、守るべきパターンか、それとも避けたほうが良さそうか？
あなたは開発チームの一員で、そのチームではアジャイルを採用しているか、その方向に向かおうとしている。あなたはおそらく、スクラムか、その他のアジャイル手法のいずれか、あるいは独自に組み合わせたものを考えているだろう。もしアジャイルを小さく始めるのだとしたら、おそらくあなたは組織の体質に逆らって仕事をしているのだろう。
-
-
クランチモードがスーパースターを平凡に
James Golick氏とReg Braithwaite氏は最近の一連の投稿で、チームを「クランチモード」（開発チームに追い込みをかけて高負荷状態で仕事をすること）に入れることが、実際にどれだけの *望ましくない* 結果を生じるかについて議論している。
-
-
理想的なアーキテクチャが理想的な��術であるとは限らない
一般的に認められた定義によれば、ソフトウェア設計者の役割は「利害関係者からの入力に基づいたシステムのマクロ面」を定義することである。これは、技術的問題点だけでは設計者を動かすことができないことを示す。設計者は、技術やアーキテクチャ設計の選択にしばしば制約を受ける、異なる利害関係者の要件を念頭に置く必要がある。
-
Article: 事例研究：合併後の統合アーキテクチャへの新しいアプローチをLawsonに見る
本事例研究では、Lawson Software, Inc.がIntentia International ABと合併した際に開発担当者が直面した課題に対するアプローチを研究するとともに、ソリューションとシステム全体のアーキテクチャに関するいくつかの興味深い面を技術的な観点から詳細に見ていきます。