BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Retrospectives に関するすべてのコンテンツ

  • チームの腐ったリンゴを扱う

    ここ数日間、Scrum Development Yahoo Groupでチームの1人の「働きが少ない」場合に何をするかについてとても活発な議論がなされている。Rotten apple in Scrum team(スクラムチームの腐ったリンゴ) の130以上のレスポンスの中で、最初の質問へのアドバイスから、チームのやる気や誰がそれを管理するかという話、個人を計測する昔からの論争、チームが本当に「チーム」であるかどうか見分けることなどへ議論が及んだ。

  • 2009年のSOA予測

    一年のこの時期になると、業界は過去12ヵ月を振り返り、先行きを予測しようとする傾向にある。たとえば、Eric Roch氏は2009年のトップ10を予測している。

  • ふりかえりを改善するための秘訣

    「Agile Retrospectives: Making Good Teams Great(邦訳:アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き)」の共著者であるEsther Derby氏は先ごろ、ふりかえりを改善するためのテクニックについて書いた。

  • Snake On The Wall : 壁に並べた付箋紙を使って障害を把握する

    Kevin Schlabach氏が、最近「Snake On The Wall」を使うことについてAgile Commentaryブログに投稿した。「Snake On The Wall」とは、開発プロセスを遅らせるものをチームで把握するのに役立つSchlabach氏が使っていた手軽なアプローチである。

  • パフォーマンスレビューの追放

    Wall Street Journal紙で、執筆者でありUCLAの経営の教授であるSam Culbert氏は、年1回のパフォーマンスと給料のレビューは最悪の機能不全に陥っていると主張した。彼はそれらの主要な目的が、「上司の権威と権限の優位性を保つことを目的とした脅迫」であると考えている。

  • レトロスペクティブの変化を曲げない

    アジャイルチームは、しばしばレトロスぺクティブの間は変化について話すのは簡単だと思っているが、レトロスペクティブ後に実際にその変化をもたらすのは必ずしもそう簡単なことではない。ソフトウェア開発の人的側面に関してよく知られたソートリーダーであり、Agile Retrospectives: Making Good Teams Greatなどの書物の共著者であるEsther Derby氏が、改善に向けた個人的な取り組みから得た経験を詳述し、変化をもたらすにはどのようにするとうまくいくのかについていくつか提案している。

  • 個人のふりかえり -- あなたの「ウェットウェア」を進化させよ

    先日のAndy Hunt氏のインタビューは、達人プログラマからアジャイルな開発、そして彼の最新の関心である実践的なウェットウェアまで、彼の変化について話している。人がどのように学習し改善するかを理解するということは、アジャイラーの道具箱を補強する重要な要素だ。

  • レトロスペクティブ(ふりかえり)の失敗とその回避方法

    アジャイルのレトロスペクティブ(ふりかえり)について書いた文章の多くは、どのようにそれらを実行し、どのような形式を使用できるかに関する基礎に重点を置いている。

  • Article: レトロスペクティブのプライムディレクティブに対する問い

    この記事の始まりは、知的で思慮深い人たちの魅力的なグループが食事会を終えて話をしているところです。話はレトロスペクティブ(振り返り)プロセスの要であるプライムディレクティブ(最初の指示)に及んでいます。

  • バリューストリームの妨げとなるもの

    スクラムでは「より生産的であろうとすることを妨げる何らかのもの」を障害として定義している。チームができるだけ継続的に、障害を取り除く手段を確立することを、スクラムでははっきりと重視している。Joe Little 氏は、障害のスコープについて、「組織が価値を提供することを妨げる何らかのもの」とした方がよいのではないか、と提案している。

  • Article: 高い生産性を生み出すソフトウェア開発の秘伝

    何について学ぶのか?お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。

  • レトロスペクティブの第一(忘れられた?)ルール:やり遂げること

    非常に経験の浅いアジャイルチームでさえ、「Retrospective」という言葉を明確に理解している。しかし、悲しいことに、チームが実際に最後までやり遂げるような改善をおこなうために使用されないと、レトロスペクティブは無駄な努力になる可能性があることが、多くの場合見落とされている。 Gordon Pask Awardの受賞歴のあるJim Shore氏が、レトロスペクティブを最大限に活用する方法についてアドバイスをし、アジャイルハートビートでのアクティビティーの究極の場所を教えている。

  • 「ふりかえり最優先条項」についての議論

    ある夜の夕食のときに、ベテランの実践者たちのグループは、自分たちがチームで「ふりかえり最優先条項」をどのように使用するか(あるいは使用しないか)に関して意見を交換した。

  • 50人の開発者に聞きました: アジャイルについて、あなたのCIOに知ってもらいたいこと

    あなたは自社のCIO(情報システム担当役員)へ、アジャイルソフトウェア開発の利点を説明しようとしているところだろうか?あなたの上司は第三者によるアジャイルの有効性の証明を求めているだろうか?そうだとしたら、CIOマガジンのEsther Schindler氏があなたのためにその大仕事をやってくれている。50人以上のアジャイル開発者へ彼女はひとつの質問をした。

  • 開発のスピードとは本当に素晴らしい「ものさし」なのだろうか?

    近い将来を予測する能力以外に開発のスピードを測定することによって、どんな価値が得られるのだろうか?J.B.Rainsberger氏は速度を追求する時間を削減し、また削除することによって最大の益がもたらされるような、チームに無駄な労力を使わせている領域が何なのか特定する事を推奨している。

BT