InfoQ ホームページ Agile に関するすべてのコンテンツ
-
イテレーションやスプリントはアジャイルチームにとって無駄か、有用か
アジャイルなソフトウェア開発を行う上で、イテレーションは基本的な特徴であると考える人は多いが、中には、果たして重要なのか、アジャイル方式に価値を加えているのか、余分ではないのか、はたまた無駄ではないかとさえ疑う者もいる。イテレーションがアジャイルチームにとって重要か否かの決定に役立ててもらおうと、InfoQではこの問題の論点を総括した。
-
イディオムやパラダイムの選択を通じたインテントの通信
イディオムやプログラミングの決まりごとを信号として使用して、さらに理解しやすく、表現に富んだものにするのはどうか?これこそまさにReg Braithwaite氏が唱えているもので、構文やパラダイムの選択さえもインテントを通信する手段になり得ると示唆している。
-
オピニオン: スタイルを強制するのはプログラミング言語ではなくチームであるべき
大規模なマニュアルにはプログラミングに関する問題を解決するために従うべきシンプルなルールが必ず書かれていると信じている人たちがいる。これはウォーターフォール型の開発手法ではよくある考え方だろう。XP だと、安全な構造とクリーンなスタイルを開発者に強制するプログラミング言語を求める人がいる。Reg Braithwaite 氏はこの信念を批判している。
-
「完了」は「シップ可能」ということか？
「完了」と「シップ可能」との相違について、アジャイルに関するさまざまなフォーラムやブログで活発な討論が起こっている。両者は同じことを意味するような気がするが、リストやさまざまなブログ上での討論が提言するのは、この2つはいまなお広範囲にわたって誤解されており、誤使用されている用語であるということである。これは「完了」の取り扱い方についての提案をまとめたものである。
-
議論：Mavenはビルドに適したツールか？
最近、Mavenの実用性についてたくさんの論議がなされている。MavenとはJavaベースの依存性管理ツールのことで、多くのプロジェクトで利用されている。InfoQは、問題の争点が何であるか、またどういった結果をもたらすのかを理解するために、この議論をより詳しく調査した。
-
職場を越えたアジャイル
この業界のわれわれの多くは、作業慣行が自身の家庭生活に影響を与えている－しばしば良い意味で。人によっては、毎日の生活の中でスケジュールを立てたり、優先事項を決めたり、日々の仕事を家族と話し合ったりする際にインデックスカードを使用する。Peter Abilla氏は、彼の子供たちに教えるためにどのようにしてジョブチャート(情報ラジエータの一種)を使用するのかをブログに記した。
-
Ivy 2.0: Apacheプロジェクトとしてリリース
Ivyは、プロジェクトの依存性を管理 (記録、追跡、解決、および報告) するツールであり、Apache Antと密接に統合されている。これの2.0ベータバ��ジョンがリリースされた。これは、Apacheプロジェクトとして初のリリースであり、Maven 2リポジトリとの強力な互換性が導入され、並行性サポートも強化された。さらに、いくつかの大きな変更点もある。
-
プラットフォームの知識ではなくて、多様なデザインスキルを好む
Martin Fowler氏は自身の最新の記事において、チームの構築において一番大切なのは経験でも特定のプラットフォームとビジネスドメインに関する完全なる知識ではなく、むしろ高品質なソフトウェア、また価値をもたらすことができる多様なスキルであると述べている。
-
アジャイル開発者の責任
顧客が間に合わせのソリューションを求める場合、開発者の責任は何か? 結局は顧客が支払いをするのだから、顧客の言うことを聞いて近道をすべきか? それとも、開発者は自分の考えで技術的に「最適な」選択肢であることを常に行うべきか? それとも、中間の妥協点があるだろうか?
-
Mike Cohn氏がAgile採用の新たなパターンを提供
Agileアライアンスの創設メンバーであり、コンサルタント、また著者であるMike Cohn氏は、最近Agileトランジションを発足する際にチームが使用できる、Agile採用の三つの中核パターンについて語っている。
-
開発のスピードとは本当に素晴らしい「ものさし」なのだろうか？
近い将来を予測する能力以外に開発のスピードを測定することによって、どんな価値が得られるのだろうか？J.B.Rainsberger氏は速度を追求する時間を削減し、また削除することによって最大の益がもたらされるような、チームに無駄な労力を使わせている領域が何なのか特定する事を推奨している。
-
成功するコラボレーションには偶然などない
パートナーシップコーチのMichael Spayd氏は契約社員と正社員は両方ともプロジェクトに取り掛かる際にコンサルタントとしての役割を果たすことができ、またクライアントとコンサルティング系統の契約を発展させていくという提案を記した記事をInfoQに提供した。これは通常の”契約”という用語とは異なる意味を持っている。サービスプロバイダとクライアント間の法的な決まりごとである。彼の"Designed Partnership Contract"は金銭の交換に関するものではなく、”コンサルタント”がコミュニケートし、自身達の価値観と嗜好を大切にするのを可能にする一方、より良いクライアントとのコラボレーションを成すために使用されるものである。
-
より優れたメトリクスの創出
エコノミスト誌の最近の記事では、ここ2世紀の間の最も素晴らしい図表の3点に敬意を表している。フローレンス・ナイチンゲールが作成したクリミア戦争中の疾病の影響を表す図、ナポレオンの失敗に終わったロシア侵攻を表したシャルル・ジョゼフ・ミナールの表、そしてウィリアム・プレイフェアの、250年以上にわたり小麦の価格と「優秀な機械工の週給」とを比較したグラフの3点である。統計情報を表すのに図表を使うことを最初に考案したのはプレイフェアであった。
-
私は自信がない。あなたの聞いたことが、私が言ったと思っていることかどうか。
コミュニケーションそれ自身は難しくも何ともない、と言わんばかりに、私たちの職場は専門用語であふれている - ビジネスドメイン用語、製品用語、開発者用語など。そのため私たちはそこにコミュニケーションがある、と言われても驚きはしない - しかし私たちは、目をぐるぐる回したりマーフィーの法則を引用したりする代わりに、それを捉え、対処することができているのだろうか？
-
オピニオン: リファクタリングは必要な無駄
リファクタリングは、アジャイル開発者のツールキットにおいて、キーとなる技術的なプラクティスの一つだ。リファクタリングはまた、顧客にとっての価値としては目立ったものではない。それはまさしく、リファクタリングの定義自体によるものだ - 振舞いを変えずに、構造 (設計) の変更を行う、と言うものだ。リーン・ソフトウェア開発の世界では、顧客にとっての価値を持たないものは全て無駄であり、そして、顧客は振舞い/機能だけを知覚する。構造ではない。