InfoQ ホームページ プランニング に関するすべてのコンテンツ
-
プロジェクトマネージャによるアジャイルチーム管理
組織がアジャイルを導入すれば，プロジェクトマネージャの役割や行動に影響があるのが普通だ。スクラムは，プロジェクトマネージャをスクラムマスタや，あるいはプロダクトオーナにするかも知れない。プロジェクトマネージャの方もまた，その仕事の仕方や内容を，スクラムマスタやアジャルチームに合ったものに変えることは可能だ。
-
アジャイルチームでソフトウェア品質を改善する
アジャイルチームが納品するソフトウェアの品質は、労働時間の長さや納期、チームのプレッシャーによって、強い影響を受けることがある。ソフトウェアの品質がこれらのことに影響されずに、チームがソフトウェアの品質を向上させるにはどうすればよいだろうか? 私からの提案は、作業範囲と納期に余裕を持たせ、プルシステムを採用し、チームメンバがあせらずに、ゆっくりと眠れるようにすることだ。
-
-
スプリント計画ゲーム "Rocket to Mars"
"ほとんどのチームとそのプロダクトオーナは，より多くのストーリポイントを達成することがチームの唯一の責務だと信じています。しかしこれは，チームとプロダクトオーナの関係を完全に誤解したものだ，と私たちは考えます。" こう語るのはDamien Thouvenin氏とPierrick Revol氏だ。氏らはストーリの創出や問題の調査，技術的負債の削減，およびそれらをトレーニングするための時間的投資を題材としたスプリント計画ゲームを実施した。
-
アジャイル手法は個人の作業にも適用可能か
アジャイルへの移行は，チーム全体，プロジェクト，あるいは組織単位で行うのが普通である。アジャイルはチームを主体とするアプローチだからだ。ところが，個人でアジャイルプラクティスの利用を始めたり，ワン・パーソン・チームとしてアジャイルを実践しているプロフェッショナルが存在するのだ。どうすれば個人でアジャイルを採用できるのだろう，そして，どのようなメリットがあるのだろう？
-
アジャイルの柔軟性 : 短所か長所か
“計画に従うのではなく変化に対応する”ことは実践では役に立たないアジャイルの強みなのだろうか。例えば、過度の柔軟性を期待する顧客と変化を管理しなければならないプロジェクトの難しさはどうだろう。アジャイルは期待される効果を発揮できないのだろうか。それとも、チームや組織がアジャイルを導入する方法に問題があるのだろうか。
-
スクラムのプロジェクト管理プラクティスによるCMMI支援
CMMI-DEV(Capability Maturity Model Integration for Development，開発のための能力成熟度モデル統合)のプロジェクト管理プロセス領域とスクラムとの関連性について検討する。
-
プロダクトバックログのためのプロセスマップとストーリマップ
もし多数のユーザストーリを抱えた大規模なバックログがあるのならば，ストーリマップやプロセスマップによってプロダクトバックログを体系化する方法が，概要の把握と全体像の理解に役立つだろう。
-
-
アジャイルチームで割り込みを扱う7つのオプション
割り込みはどのチームでも扱わなければならないものであり、扱い方が適切でなければ、納品する能力に不利益をもたらす可能性がある。Agile Adviceブログの最近の投稿で、スクラムや繰り返されるアジャイルアプローチを使っている場合に、チームがどのように割り込みに対処するかについて考慮すべき7つのオプションについて、Mishkin Berteig氏が述べている。
-
製品オーナーは、プラニング ポーカーの場に、どのように参加すべきか？
プランニングポーカーの間、製品オーナーは、各ストーリーを明確にする責任があるが、しかし、オーナーは、開発チームの見積りに不当な影響を及ぼそうとしては、ならない。
-
ストーリーポイントは複雑さや時間と関係があるか？
多くのアジャイルチームが、ストーリーポイント（Story points）とコンプレキシティポイント（Complexity points）という用語を交換可能なものとして使っている。そして、アジャイルチームは、これらが複雑さや相対的な大きさに基づいているというだけで、時間よりもすぐれていると思い込んでいる。Mike Cohn氏は、あるフィーチャー（機能）を開発する際に、ストーリーポイントを複雑さを表すのに使うのは間違っており、それらはすべて労力に関係するものだと述べている。
-
ストーリーポイントとは何か？必要ものなのか？
Michael de la Maza氏は、ストーリーポイントとは厳密には何なのか？という疑問を投げかけている。彼が答えを探したところ、「ストーリーポイントとは漠然とした時間単位を表すものだ」や「ストーリーポイントはスクラムチームが使っている任意の測定基準であり、1つのストーリーを実装するのに必要な労力を測るために使われる」など、いろいろな意見があることがわかった。
-
ビジネス価値を見積もる
従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装する。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。Pascal Van Cauwenberghe 氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。
-
スプリント計画：ストーリーポイント VS 作業時間
スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて，決着の付かない議論が長く続いている。Mike Cohn 氏がユーザストーリーをタスクに分割して時間見積を行う方法を推せば，Jeff Sutherland 氏が自身の関わった最高のチームでのストーリーポイントを使ったバーンダウンの例をあげてみせる，といった具合だ。