InfoQ ホームページ Assessment に関するすべてのコンテンツ
-
レトロスペクティブ（ふりかえり）の失敗とその回避方法
アジャイルのレトロスペクティブ（ふりかえり）について書いた文章の多くは、どのようにそれらを実行し、どのような形式を使用できるかに関する基礎に重点を置いている。
-
Article: レトロスペクティブのプライムディレクティブに対する問い
この記事の始まりは、知的で思慮深い人たちの魅力的なグループが食事会を終えて話をしているところです。話はレトロスペクティブ（振り返り）プロセスの要であるプライムディレクティブ（最初の指示）に及んでいます。
-
バリューストリームの妨げとなるもの
スクラムでは「より生産的であろうとすることを妨げる何らかのもの」を障害として定義している。チームができるだけ継続的に、障害を取り除く手段を確立することを、スクラムでははっきりと重視している。Joe Little 氏は、障害のスコープについて、「組織が価値を提供することを妨げる何らかのもの」とした方がよいのではないか、と提案している。
-
Article: 高い生産性を生み出すソフトウェア開発の秘伝
何について学ぶのか？お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。
-
レトロスペクティブの第一(忘れられた?)ルール：やり遂げること
非常に経験の浅いアジャイルチームでさえ、「Retrospective」という言葉を明確に理解している。しかし、悲しいことに、チームが実際に最後までやり遂げるような改善をおこなうために使用されないと、レトロスペクティブは無駄な努力になる可能性があることが、多くの場合見落とされている。 Gordon Pask Awardの受賞歴のあるJim Shore氏が、レトロスペクティブを最大限に活用する方法についてアドバイスをし、アジャイルハートビートでのアクティビティーの究極の場所を教えている。
-
「ふりかえり最優先条項」についての議論
ある夜の夕食のときに、ベテランの実践者たちのグループは、自分たちがチームで「ふりかえり最優先条項」をどのように使用するか(あるいは使用しないか)に関して意見を交換した。
-
50人の開発者に聞きました: アジャイルについて、あなたのCIOに知ってもらいたいこと
あなたは自社のCIO(情報システム担当役員)へ、アジャイルソフトウェア開発の利点を説明しようとしているところだろうか?あなたの上司は���三者によるアジャイルの有効性の証明を求めているだろうか?そうだとしたら、CIOマガジンのEsther Schindler氏があなたのためにその大仕事をやってくれている。50人以上のアジャイル開発者へ彼女はひとつの質問をした。
-
開発のスピードとは本当に素晴らしい「ものさし」なのだろうか？
近い将来を予測する能力以外に開発のスピードを測定することによって、どんな価値が得られるのだろうか？J.B.Rainsberger氏は速度を追求する時間を削減し、また削除することによって最大の益がもたらされるような、チームに無駄な労力を使わせている領域が何なのか特定する事を推奨している。
-
どれくらい「ふりかえり」を行うか？
Norm Kerth氏が提案した「ふりかえり(retrospective)」の最初の定義は、3日間のオフサイトミーティングだった。それ以来、アジャイルコミュニティはあらゆるイテレーションにそのプラクティスを適用してきた。ただ、多くのチームは、「ふりかえり」を最小限の時間(せいぜい15分程度)しか行わない傾向がある。どれくらい「ふりかえり」を行うのが効率的なのだろうか？