InfoQ ホームページ Agileの採用 に関するすべてのコンテンツ
-
アジャイル文化への転換は容易ではない
多くの評論家が、組織のアジャイル文化への転換に関する課題について執筆してきた。Ken Schwaber氏は、スクラム実践の75%では期待する利益を実現できないと予想していた。本稿では、その原因の一部と成功率向上のためにすべきことに着目する。
-
Agile In a Flash（速解アジャイル）
多くの人々が冗談半分に３×５のインデックスカードを「アジャイリストのバッチ」と認めている。しかし、色々な意味でこれは不正確でも不適切でもない。山積みされたインデックスカードを見ていくことが、実際に多くのアジャイル的活動に対する品質保証になり得るのだ。しかし、インデックスカードを使ってアジャイルを学び、覚えるというのはどうだろうか？「Agile In a Flash」プロジェクトにおいて、Tim Ottinger氏とJeff Langr氏はまさにそういった人々の手助けをしようとしている。
-
進化論から見たソフトウエア開発
ミームとは、もとはRichard Dawkins氏の著書"利己的な遺伝子"で提示された概念で、遺伝子を使って文化を考えるためのものだ。ミームは人々の間に広がり、思考や行動に影響を与える。Julian Everett氏の考えでは、ソフトウエア開発の方法論や概念や文化はミームの集合と見なすことができるのではないか、ということだ。そしてそのように考えることで、方法論の効果とその理由はまったく逆になる。
-
アジャイルプロジェクトにおけるリソースマネジメント
アジャイルプロジェクトは急激な変化という問題を解決するものとして知られている。これらは市場要因やシステム要件、実装技術における変化かもしれない。こうした変化の1つに、プロジェクトに取り組む人員の頻繁な変化があるが、これはアジャイルプロジェクトとは相性がわるい。このアイデアは、成果を上げているチームを乱さないようにすることで、高いベロシティを実現し続けることができるというものだ。
-
アジャイル組織は何を重視すべきか?
アジャイルを採用することは簡単ではない。多くの組織は、スクラムやXPのプラクティスを自分たちのやり方に無理やり当てはめようとして苦労する。そのような組織に対して、"どのように"アジャイルを行うかということを重視しすぎるのは誤ったアプローチかもしれないとMike Cottmeyer氏は助言する
-
受入テストの自動化 - 理論にすぎないのか、それとも実践的なのか
要件を受入テストとして記述し、それを自動化することに成功したという報告がこれまでも時折見られている。しかし、これを実践しているのはコミュニティの中の少数派でしかない。各イテレーションの最初に自動化された受入テストを書くという主張は理論的なものに過ぎず、適用事例が少ないということが非効率であることの証明になっているのだろうか。
-
ハイパフォーマンスチーム - チーム殺しを避けるには
ハイパフォーマンスチームは職場にあるチームの2％にすぎないが、アジャイルプロセスはこうしたチーム作りを促しているように見える。この記事では、こうしたチームがどのようにして職場にはぐくまれるのか、Steve Denning氏の考え方について解説する。また、ハイパフォーマンスチーム作りのための選抜や採用の方法について、Ominlab MediaのStefan Gillard氏による最近の講演についても取り上げる。
-
James Shore氏に聞くアジャイルの現状
このインタビューでは、InfoQはJames氏が最近よく話題にしている、彼の著書「Art Of Agile(訳注:邦訳「アート・オブ・アジャイルデベロップメント――組織を成功に導くエクストリームプログラミング」)」という本のこと、昨今のアジャイルが骨抜きになっている傾向について、そしてカンバン方式が全体像というものをいかに欠いているかということ、こういったいくつかのことについて話を聞いた。
-
機敏さ、職人的技能、そして成功の評価
Scott Ambler氏、Ross Pettit氏らがアジャイル・プロセス成熟度モデルの作成を続けている一方で、David Starr氏は組織が評価を望むであろう項目について、その方法と理由に目を向けた。機敏さ、職人的技能、そして組織的成功。彼は、職人的技能を評価することは比較的簡単だが、機敏さを適切に評価することは非常に難しい、という結論に達した。
-
アジャイルへの移行を正当化するコスト
「金を見せてもらえないことには…」――アジャイル・マイグレーションの正当化コストは争点の多い問題である。アジャイル・アプローチのほうが成功しており、より迅速に価値を提供し、より良い品質の製品を製造する。だがそれをいかにして��明するか？この記事ではその測定について説明し、アジャイル・メソッド採用の正当化に寄与する結果を提示する。
-
良いベロシティ
Buddha Buck氏は、最近、Extreme Programmingのメーリングリストにおいて、2週間のイテレーションを行っている7人程のチームにとって「良い」と考えられるベロシティの範囲があるかどうかを尋ねた。Buck氏は、ベロシティが8以下の場合、チームのストーリーが大きすぎるのではないかと考えた。議論の結果、この質問の答えと、質問の裏にある別の質問が得られた。
-
かんばんとスクラムの比較
開発組織がアジャイルを実践する有効な手段として、かんばんには大きな関心が寄せられている。このため、多くの者が「かんばんとスクラムはどのように比較するのか？」という疑問を抱いており、Henrik Kniberg氏は、この疑問に答えようとしてきた。
-
散らかった製品チームを構造化する
Cory Foy氏は、買収やちょっとした怪物への進化によって成長した既存の組織に取り組んでいる。チームメンバーは、世界中に散らばっており、場合によっては同じタイムゾーンでもない。製品のリリースには12～18ヶ月を必要とした。
-
Scott Ambler氏がアジャイル・プロセス成熟度モデルを再考する
以前「Has Hell Frozen Over? An Agile Maturity Model?」を執筆したScott Ambler氏が、アジャイル・プロセス成熟度モデルと称するものを書き始めた。Scott氏のモデルに関するディスカッションでは、同一名称による別モデルを明らかにし、アジャイルの成熟度モデルの有効性に関する議論を一新してきた。
-
ソフトウェア開発に適用されるリーンの「標準化」
トヨタ生産方式の構成要素の一つに、標準化という考え方がある。Kanban Developmentのリストに寄せられた最近の投稿に、トヨタ生産方式とリーン生産方式がソフトウェア プロジェクトに適用された場合、この考え方は引き継がれるのかといった質問があった。これに対し回答者たちは、ソフトウェア開発は実際には製造業でないにもかかわらず、開発に「標準化」という考え方を適用することに価値を見出した。