InfoQ ホームページ Agile in the Enterprise に関するすべてのコンテンツ
-
アジャイルのリスク管理
リスク管理は、リスクを判断し、軽減し、監視することに向けて行われる活動だ。多くのアジャイル実践者は、アジャイルプロジェクトのリスク管理のプロセスが従来のプロジェクトとそれほど異なっていないと確信している。
-
タスクに費やした時間ではなく開発速度をトラッキングする
エンジニアがタスクに費やす実際の時間のトラッキング方法とこの方法が速度というアジャイルの概念にどのように関係するかについて、新しいアジャイルチームのメンバがScrum Developmentグループに尋ねた。
-
実例駆動受け入れテスト
テストは、開発において不可欠な部分だと考えられる。コードとテストケースは、アジャイルプロジェクトの重要な成果物だ。しかしながら、多くのアジャイルチームにおいてユニットテストと統合テストが受け入れテストよりも注目を集めている。Gojko Adzic氏とLisa Crispin氏が、開発の一環として効率的に受け入れテストを含めるアプローチを提案する。
-
オーバーコミット対オーバーデリバリ
スプリント計画の主要な目的は、スプリントの終わりまでに「何をデリバリするつもりか」をコミットすることである。一度コミットされると、チームは目標を達成するために一丸となって働く。スクラムマスタは、チームのスピードを落とすであろう、あらゆる障害を取り除く。理想を言えば、チームはコミットしたことを守らなければならないが、もしチームが絶えずオーバーコミットしているか、あるいはオーバーデリバリしている場合は、心配の種がある。
-
-
内部リリースと外部リリースの違い
昔からソフトウェアリリースはエンジニアリングとビジネスが手を握ることだと考えられている。エンジニアリングはテストしたコードをビジネスに渡し、次にビジネスがそれを市場に普及させることでサイクルが完成する。しかしながら、アジャイルではソフトウェアリリースは内部リリースと外部リリースの2つのカテゴリに入れられる。これは2つの間に緩い結合を作るのに役立つ。
-
パネル： BayAPLNアジャイルエキスパートパネル
QCon San Francisco 2008の期間中、Agile Project Leadership Network (APLN)のローカルグループであるBayAPLNとInfoQは、アジャイルの専門家で構成さ���るパネルを組織し、聴衆からのさまざまな質問に回答した。パネリストは、David Chilcott氏、モデレータ、Polyanna Pixton氏、David Hussman氏、Sue Mckinney氏、Pat Reed氏であった。
-
スクラムのスクラム - 問題と価値
Agile Estimating and Planningの著者のMike Cohn氏が「スクラムを大きなプロジェクトチームに適用させるのに重要な技術」と説明しているのが、スクラムのスクラムミーティング(the Scrum of Scrums)である。
-
開発の分散は品質の問題が生じるだろう
「ロケーション間でのスキルレベルの違いによるソフトウェアの品質の問題」は世論調査結果からわかった最も興味深いことの一つであるが、この調査は2008年9月のReg読者調査で行われたものである。この調査の回答者は369人で、その内80%は分散ソフトウェア開発を直接経験していた。地理的には44%が英国、36%が米国、そして他の場所が20%に分かれていた。
-
スクラム導入時の課題
新しいソフトウェア開発手法を導入することは、「変化を受け入れたがらない」といったものから「誤った導入方法」ようなものまで幅広く、いくつもの失敗へと繋がる課題がある。Cesario Ramo氏とEelco Gravendeel氏は、アジャイルジャーナルの連載記事の中で、スクラムで仕事をしている時であったり、さまざまな組織にスクラムを導入した時に気付いた課題について語っている。
-
スクラムのスクラムをせずにスクラムをスケールする
スクラムは、開発チームのメンバ間のコミュニケーション促進において効果的であることを証明してきた。この高帯域のコミュニケーションを、特に大きな組織において、どのようにしてチームを越えてスケールするかという問題は、活発に調査・議論される領域に残っている。
-
Brain Marick氏「アジャイルマニフェストに足りないもの」
Brain Marick氏は、Agile Development Practicesカンファレンスの基調講演の中で、アジャイルマニフェストに足りていない価値について説明した。氏によれば、アジャイルマニフェストは本来マーケティング用の文章であって、アジャイルが日の目を見るように、ビジネスとして成立させるという目的があったと言う。
-
Article: 事例研究：Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
-
James Shore氏「アジャイルの衰退と凋落」
James Shore氏はアジャイルは衰退していくと断じている。多くのチームが、長期間にわたって高品質なソフトウェアを生産するために必要とされる技術的なプラクティスを適用することなく、「スプリント」と朝会だけ行っていることを例に挙げている。
-
インフラがアジャイルソフトウェアチームを楽にする
アジャイルマニフェストは「プロセスとツールよりも個人と相互作用」を尊重する。しかしながら、ツールとプロセスをうまく混ぜ合わせるとアジャイルチームの成功の触媒の役割を果たすことがよく起こる。アジャイルの導入が増え、多くのチームが分散環境で働くという事実の中で、適切なインフラを持つことがアジャイルチームの成功の重要な要因となっている。