InfoQ ホームページ Agile in the Enterprise に関するすべてのコンテンツ
-
適応型再利用 - 土木工学に学ぶ
直線的な開発プロセスは土木工学の中核であると信じられているものだが、「なぜ橋を建てるのと同じようにソフトウェアを構築できないのか」というソフトウェア開発に対して時折向けられる批判に対する反応として、ソフトウェアエンジニアはこのような直線的な開発プロセスに対して異を唱えてきた。しかし実は、土木プロジェクトもアジャイル主義者が認めるような方法をしばしば採用しているのである。
-
本日のアジャイル レトロフレクション
レトロフレクションは自らを環境に置き換える概念である。例えば、他人にしたいことや他人にしてもらいたいことを自らに行う。内省（イントロスペクション）は、病気か健康となり得るレトロフレクションの一種である。同様の考えに基づき、は本日のアジャイル レトロフレクション プロジェクトを始めた。
-
オピニオン: アジャイルが成功するかはアジャイルテクニックに依存しない
過去、現在、そして将来も、アジャイルチームが驚くべき成功を収めているのは事実だ。しかし、失敗に終わることがあるのもまた事実だ。導入が「不十分」であったり、「イヤなものを削って」導入してしまったり。他にも、アジャイルチームがすばらしいソフトウェアを作れず、また全体として組織に影響を与えられなかったりすることは数多くある。これは解決できて「修正」できるものなのだろうか？ あるいは、アジャイル開発は一部のチームにだけ役に立つものなのだろうか？
-
安定化スプリント - 必要悪か、それとも純粋な無駄か？
安定化スプリント（"Stabilization Sprint"）とは、製品をリリースする前、通常の開発サイクルの最後に付け加えられる付加的なスプリントである。名前が示している通り、このスプリントは通常プロダクトを最後にもう一度叩き、最後のバグを出すためのものである。これはアジャイルに属するものなのか？それとも「完了」すれば充分なのか？
-
アジャイルプロジェクトが遅れる理由
一般的に言えば、遅延とは作業の実施が予定よりも後になることであり、それによって不満や作業が苦しみが生まれ、関係者に迷惑をかける。同じように、アジャイルプロジェクトでも遅延という言葉は無駄と考えられている。遅延はプロジェクトの流れを断絶してしまうので、再学習やタスクの変更などの更なる無駄を生み出す。何人かのアジャイル実践者が一般的な遅延とその対処法について議論している。
-
-
社会的契約によってチームのコミットメントを促す
正式な社会的契約によって組織的な変更に関する恐れ、不確実性、疑いなどを減らす手助けとなるための構造が与えられ、アジャイルへの移行がより円滑に行われる。 Israel Gat氏がBMP Softwareで利用した社会的契約の例を示す。
-
スクラムマスタが障害になるとき...
スクラムマスタという名前が表すのは、この役割はスクラムプロセスの守り神だということだ。彼は変革者としてチームを支援し、組織の中でスクラムを構築する。障害をなくし、外部の邪魔からチームを守ることでチームが滞りなく機能するようにするのが彼の仕事だ。しかし、スクラムマスタ自身が最大の障害になっているとチームが感じる時もある。
-
ティーチングゲーム－遊びか、まじめなビジネスか？
Tasty Cupcakesティーチングゲーム・ウェブサイトの創始者であるMichael McCullough氏とDon McGreal氏が「楽しみ駆動開発（"Fun Driven Development"）」に関する記事を公開した。景気は低迷しているが、こういったゲームがトレーニングプログラムから締め出されることはなく、実際、ティーチングゲームはアジャイル実践者が集まって考えを交換する上でのかすがいとなっている。ここではその歴史と、チームにおいてゲームを用いる上でのスタート地点を紹介する。
-
アジャイルの成功が結局は失敗になるとき
パイロットアジャイルチームが成功すると、アジャイル導入のプロセスが正しい方向に向いていると思い込みがちだ。Dave Nicolette氏が、試験的な試みが大成功した後で、導入に失敗した状況について興味深い洞察を示す。
-
"アジャイルチームリード"は必要か
Patrick Wilson-Welsh氏、Chris Beale氏、Gary Baker氏、 John Huston氏、Daryl Kulak氏らが新しい役割の概念を広めようとしている。その概念は、"アジャイルチームリード"というものだ。 目的は、アジャイルチームやその周辺にある従来のリーダーシップの概念を置き換えるためだ。
-
アジャイルの衰退と凋落を止めるために内側を見つめる
アジャイルの「衰退と凋落」に関する議論は、AgileQや一般的なコミュニティにおいて、何度も繰り返されるテーマだ。人々がアジャイルを効果的に導入しておらず、間違った方法でアジャイルを台無しにするという意見が集まっているのだ。Kevin Schlabach氏は、新しいリーダーを育てていないアジャイルコミュニティ自体が原因だという考えを示す。
-
アジャイルを導入するパイロットプロジェクトの選び方
アジャイルの導入を成功させる最も重要な要因の1つは、アジャイルをパイロットプロジェクトに適用することで学んだことだ。ここで学んだことが、今後アジャイルを推進するのか、それとも従来のプロセスに戻すのか、組織に大きな影響を及ぼすことになる。パイロットプロジェクトに適していないプロジェクトを選んでしまうと、アジャイルという新しいプロセスをうまく宣伝できずに、失敗に終わるだろう。
-
アジャイルはマイクロマネジメント
マイクロマネジメントは通常、あまり良い意味で使われない。このマネジメント方法は、マネージャが部下や社員の近くで仕事について細部まで指示する方法だ。普通、アジャイル開発とマイクロマネジメントは正反対の手法と考えられがちだか、表面上の違い以上に強く関連している。
-
よいアジャイルなメトリクスとは何か?
適切でアジャイルな計測とは何だろうか?もし伝統的な計測方法である、アーンドバリュー、労働時間、コード行数、テストによるコードカバレッジがアジャイルなプロジェクトにはあまり適さないのであれば、どういう方法があるのだろうか?よりよいアジャイルなメトリクスを選ぶ上で助けとなる、私たちが決められるルールは何だろうか?