InfoQ ホームページ Agile に関するすべてのコンテンツ
-
Opinion: アジャイルを採用することとアジャイルを習慣にすることは別の話だ
アジャイルプラクティスを有効に使うことはアジャイルプラクティスにはどんなものがあるかを知っていることほど簡単ではありません。テスト駆動開発を有効に活用することは、「レッド―グリーン―リファクタリング」というステップを繰り返すべきだということを知っているのとは異なります。どうすれば「アジャイルというのはなかなかよさそうな考え方ですね」という段階から「私たちはアジャイルプラクティスを活用して自分たちの組織にもたらす価値を著しく改善しています」という段階に辿り着けるのでしょうか？
-
SaaSアーキテクチャ成熟度モデル
Software as a Service (SaaS)がますます主流となるにつれて、製品の裏側にあるアーキテクチャに関する議論が活発になっている。Dharmesh Shah氏がSaaSアーキテクチャ成熟度モデルの経済的意味について著した。
-
問題を抱えたプロジェクトの舵取り：まず酸素マスクを確保せよ
Fiona Charles氏によるStickyMindsでの最近の記事は、問題を抱えたプロジェクトの舵取りについて触れている。「前進のための融通の利かないプロセスのための時間ではない」と強調し、プロジェクトを好転させるのに役立つ貴重な洞察を提供している。
-
TDD/BDDは不完全なユニットテストを招くか？
Peter Ritchie氏は、TDDやBDDにこだわることで、良いユニットテストを書かなくなる傾向があるのではないか、という懸念を表明した。特に「インタラクションテスト(interaction testing)」というマントラは、不完全なユニットテスト、すなわち、どのような条件下で利用されても稼働するユニット(オブジェクト)である、という証明ができていないテストをもたらすと述べている。Peter氏の考えで最も興味深いのは、TDDとBDDのそもそもの意図に対する反対意見と受け取れるところだ。
-
機能テストの今後
ここ最近、開発主導型の機能テストの分野において活発な動きがある。Jennitta Andrea氏とWard Cunningham氏が、「機能テストツールの次世代を予想」というテーマでウェブ放送を開催した。また、Thoughtworksがこの分野において製品を発表する意向を示した。
-
Review Board - コードレビューをオンラインで
コードレビューは品質を高め、情報共有とメンターシップの優れた方法となる。 残念なことにこれまではサポートツールの準備に手間がかかったりそもそも準備されなかったせいでコードレビューは後回しにされることが多かった。Review Boardはコードレビューのプロセスをサポートするアプリケーションによってこの状況を変えようとしている。このアプリケーションのいくつかの機能をあげよう。
-
継続的リリースは、さらなるアジャイルさを与えてくれるか？
StelligentのPaul Duvall氏は最近の記事で、継続的インテグレーションを継続的リリース(Continuous Production)に成長させるために必要なアクティビティについて書いている。継続的リリースとはまとめてリリースする代わりに、絶えずソフトウェアをリリースし続けるプラクティスのことである。
-
ユーザストーリーの適正サイズ
経験豊富なアジャイル開発実践者なら誰もが知っていることだが、適正なストーリーを引き出してまとめるのは、もっとも難しい作業のひとつだ。Pat Kua氏は最近自分の記事で、次の重要な問いかけをした。ストーリーはどれくらい詳細にすべきだろうか？
-
議論: アジャイルプロジェクトの成功を顧客視点で測定する
最近、Scrum開発のユーザグループで、「顧客はアジャイルプロジェクトの成功をどのように測定するか」という問いに答えようとする興味深い議論があった。ここで重要なのは、「測定する」ということだ。この議論では、顧客の観点からの成功を測定することは重要であり、その実施にはさまざまな方法があるということで意見の一致が得られているようだ。最も良い測定方法は、状況と顧客によって異なるだろう。
-
責任、個人のアジャイル性、その他の親密なコミュニケーションのアイデア
うまくいっているアジャイルなチームの特徴は、プラクティスではなく主に文化にある。この考えは多く（ほとんどと言ってもいいかもしれない）のアジャイルな分野で当てはまるように思われる。組織的変革の世界で有名になった Christopher Avery 氏は Responsibility という言葉を再定義し、その考え方を人々に伝えるという作業に取り組み、その成果をアジャイルプラクティスに注いでいる。個人のアジャイル性はアジャイル導入のカギなのだろうか？
-
イテレーションやスプリントはアジャイルチームにとって無駄か、有用か
アジャイルなソフトウェア開発を行う上で、イテレーションは基本的な特徴であると考える人は多いが、中には、果たして重要なのか、アジャイル方式に価値を加えているのか、余分ではないのか、はたまた無駄ではないかとさえ疑う者もいる。イテレーションがアジャイルチームにとって重要か否かの決定に役立ててもらおうと、InfoQではこの問題の論点を総括した。
-
イディオムやパラダイムの選択を通じたインテントの通信
イディオムやプログラミングの決まりごとを信号として使用して、さらに理解しやすく、表現に富んだものにするのはどうか?これこそまさにReg Braithwaite氏が唱えているもので、構文やパラダイムの選択さえもインテントを通信する手段になり得ると示唆している。
-
オピニオン: スタイルを強制するのはプログラミング言語ではなくチームであるべき
大規模なマニュアルにはプログラミングに関する問題を解決するために従うべきシンプルなルールが必ず書かれていると信じている人たちがいる。これはウォーターフォール型の開発手法ではよくある考え方だろう���XP だと、安全な構造とクリーンなスタイルを開発者に強制するプログラミング言語を求める人がいる。Reg Braithwaite 氏はこの信念を批判している。
-
「完了」は「シップ可能」ということか？
「完了」と「シップ可能」との相違について、アジャイルに関するさまざまなフォーラムやブログで活発な討論が起こっている。両者は同じことを意味するような気がするが、リストやさまざまなブログ上での討論が提言するのは、この2つはいまなお広範囲にわたって誤解されており、誤使用されている用語であるということである。これは「完了」の取り扱い方についての提案をまとめたものである。
-
議論：Mavenはビルドに適したツールか？
最近、Mavenの実用性についてたくさんの論議がなされている。MavenとはJavaベースの依存性管理ツールのことで、多くのプロジェクトで利用されている。InfoQは、問題の争点が何であるか、またどういった結果をもたらすのかを理解するために、この議論をより詳しく調査した。