Amazon.com: Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers): Derby, Esther, Larsen, Diana, Schwaber, Ken: Books
Article 132 at 06/02/08 13:03:44 From: editors@objectclub.jp Subject: 【オブジェクト倶楽部： 2006-05号】
Date: Wed, 08 Feb 2006 13:21:05 +0900 Subject: 【オブジェクト倶楽部： 2006-05号】 X-Mail-Count: 00132 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■ ┃ ■┃ ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃ ┃ ■ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛ No.126 2006/02/08 ■ I N D E X ┃ ┣【Topics】デブサミいよいよ今週です！ ┣【ＰＦ】ふりかえりガイド[3] - KPTによるふりかえり ┣【ＰＦ】アジャツール - Agileなツール紹介[8] ┗【アンケート】気になるシステム業界 ホントのところ 〇━━━━━━━━━━━━━━━━━━━━━━
2005-11-06
消化器の様子がおかしくて、消化のいいものばかり選んで食べていたのですが、あまりよくなりません。埒が明かないので、ステーキ食べてビールを飲んだら、だいぶよくなりました。というか、気にならなくなったのかな。 もはや旧聞に属する話ですが･･･ KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ で、拡張KPTが紹介されています。そういや以前、id:t-wadaさんが「けぷたーく」とか言ってるのを耳にしましたがスルーしてました。 で、フォーマットの例が紹介されているのですが、私もちょっと書き方を考えたので載せてみます。 Riskは、具現化するとProblemになる。（具現化しなければ消滅する） Keepが結晶化するとKnowledgeになる。 Problemを本質化するとIssueになる。 という関係のあるもの同士が隣になるようにしてみました。線で結んだり中間地点に
「見える化」でソフトウェア開発！ 〜オブジェクト指向 実践者の集い(第 3 弾) 参加レポート〜 sooey
［レポート］ 「見える化」でソフトウェア開発！ ～オブジェクト指向実践者の集い(第 3 弾) 参加レポート～ 1．はじめに 昨年の 12 月 9 日、オブジェクト倶楽部主催によるイベント「オブジェクト指向実践者の集い」が行われました。「オブジェクト指向実践者の集い」はオブジェクト指向を現場で実践している、あるいは実践しようとしているエンジニアに役立つよう「現実的なオブジェクト指向とは何か」、「オブジェクト指向を見直してみよう」をテーマとしています。今回で、このイベントは 3 回目となりました。 クリスマス企画という事で会場にはツリーが置いてあったり、スタッフのみなさんがサンタクロースの帽子をかぶっていたりで、和やかな雰囲気でした。 今回のテーマは「見える化」です。ソフトウェアの世界は見えないものが非常に多いです。そして「見えない」ことにより、ソフトウェア開発では様々な問題が出てきます。例え
KPT法
ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が
すごいKPT事後評価セッション
すごいKPT事後評価セッション 先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。 招待状 参加者には、以下の事前準備をメールでリクエストしておいた。 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流) 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」) スコープ、スケジュール、リソース、欠陥レベル プロジェクト運営 コラボレーション (スタッフ間) 個人・チームとして学習した点 その他 (開発手法など) 問題点については「どのようにすれば〜(だろうか)
KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ
Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://mugiwara.jp/ki/?200511a