
5つのコンフィグレーション管理ベストプラクティス
この記事では、コンフィグレーション管理を楽にするため、そして、アプリケーションを運営、管理する必要のある人たちを楽にするために、コード内からできることについて調べたものだ。これらのパターンはThoughtWorksのプロジェクトで何度も使ってきて、その価値が証明されているものだ。

この記事では、コンフィグレーション管理を楽にするため、そして、アプリケーションを運営、管理する必要のある人たちを楽にするために、コード内からできることについて調べたものだ。これらのパターンはThoughtWorksのプロジェクトで何度も使ってきて、その価値が証明されているものだ。
プランニングポーカーの間、製品オーナーは、各ストーリーを明確にする責任があるが、しかし、オーナーは、開発チームの見積りに不当な影響を及ぼそうとしては、ならない。
多くのアジャイルチームが、ストーリーポイント(Story points)とコンプレキシティポイント(Complexity points)という用語を交換可能なものとして使っている。そして、アジャイルチームは、これらが複雑さや相対的な大きさに基づいているというだけで、時間よりもすぐれていると思い込んでいる。Mike Cohn氏は、あるフィーチャー(機能)を開発する際に、ストーリーポイントを複雑さを表すのに使うのは間違っており、それらはすべて労力に関係するものだと述べている。
Michael de la Maza氏は、ストーリーポイントとは厳密には何なのか?という疑問を投げかけている。彼が答えを探したところ、「ストーリーポイントとは漠然とした時間単位を表すものだ」や「ストーリーポイントはスクラムチームが使っている任意の測定基準であり、1つのストーリーを実装するのに必要な労力を測るために使われる」など、いろいろな意見があることがわかった。
従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装する。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。Pascal Van Cauwenberghe 氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。
スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて,決着の付かない議論が長く続いている。Mike Cohn 氏がユーザストーリーをタスクに分割して時間見積を行う方法を推せば,Jeff Sutherland 氏が自身の関わった最高のチームでのストーリーポイントを使ったバーンダウンの例をあげてみせる,といった具合だ。
Valtech Technologies社のアジャイルコーチであるDave Nicolette氏は、短いイテレーションは長いものよりも良いのかという質問に、取り組んでいる。Dave氏は、短いイテレーションは、変更に対しより素早く対応し、より多く問題を発見し、修正する機会があることをデモしている。また、短いイテレーションがバーンアウトや他の問題を招きかねない懸念材料についても対処している。

コンサルタントとして働くことの最大の喜びの一つはいろいろなアイディアを試してみてからことが上手くいくように自分が一番好きな方法を適用することができることです。この記事では私が効果的だと思うユーザ・ストーリーの(開発工数)見積もりテクニックの詳細について述べています。

アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。