タグ

KPTに関するtm2002のブックマーク (11)

  • Amazon.com: Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers): Derby, Esther, Larsen, Diana, Schwaber, Ken: Books

    Amazon.com: Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers): Derby, Esther, Larsen, Diana, Schwaber, Ken: Books
  • プロジェクトファシリテーション実践編:ふりかえりガイド

    ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか? 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを100%以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション(PF)」です。 プロジェクトマネジメント(PM)が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド・コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム

    tm2002
    tm2002 2006/09/25
  • kzy is not kozy... KPT法とToDo管理

    僕自身、まだ大して使ってもいない手法なのですが、KPT法という興味深いツールがあります。 KPTとはKeep/Problem/Tryのそれぞれの頭文字から取ったものです。 Keepは、やってみて良かったことで今後も続けようと思ったこと、Problemは、失敗したことや問題のあったことについて、Tryは、今回やらなかったけど次にやってみたいこと、です。 たとえばあるプロジェクトが終了したときなど、ホワイトボードに線を引き、3つの領域をします表を作ります。そのプロジェクトに参加した人が、プロジェクトを終えて、気がついた点を書き込みます。 過去の経験からするといわゆる「反省会」というと、「悪かった点」が主になりがちであったり、今後の反省をどうやって生かすか、とか、問題を整理しにくい点があったように思います。しかしこのように、書き込む時点でこの3つに分類されていると反省点が明確になり、今後に生かし

    kzy is not kozy... KPT法とToDo管理
    tm2002
    tm2002 2006/09/25
  • 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】デブサミいよいよ今週です! ┣【PF】ふりかえりガイド[3] - KPTによるふりかえり ┣【PF】アジャツール - Agileなツール紹介[8] ┗【アンケート】気になるシステム業界 ホントのところ 〇━━━━━━━━━━━━━━━━━━━━━━

  • 2005-11-06

    消化器の様子がおかしくて、消化のいいものばかり選んでべていたのですが、あまりよくなりません。埒が明かないので、ステーキべてビールを飲んだら、だいぶよくなりました。というか、気にならなくなったのかな。 もはや旧聞に属する話ですが・・・ KPTを使ったプロセス改善(2):An Agile Way:オルタナティブ・ブログ で、拡張KPTが紹介されています。そういや以前、id:t-wadaさんが「けぷたーく」とか言ってるのを耳にしましたがスルーしてました。 で、フォーマットの例が紹介されているのですが、私もちょっと書き方を考えたので載せてみます。 Riskは、具現化するとProblemになる。(具現化しなければ消滅する) Keepが結晶化するとKnowledgeになる。 Problem質化するとIssueになる。 という関係のあるもの同士が隣になるようにしてみました。線で結んだり中間地点に

    2005-11-06
  • 「見える化」でソフトウェア開発! 〜オブジェクト指向 実践者の集い(第 3 弾) 参加レポート〜 sooey

    [レポート] 「見える化」でソフトウェア開発! ~オブジェクト指向実践者の集い(第 3 弾) 参加レポート~ 1.はじめに 昨年の 12 月 9 日、オブジェクト倶楽部主催によるイベント「オブジェクト指向実践者の集い」が行われました。「オブジェクト指向実践者の集い」はオブジェクト指向を現場で実践している、あるいは実践しようとしているエンジニアに役立つよう「現実的なオブジェクト指向とは何か」、「オブジェクト指向を見直してみよう」をテーマとしています。今回で、このイベントは 3 回目となりました。 クリスマス企画という事で会場にはツリーが置いてあったり、スタッフのみなさんがサンタクロースの帽子をかぶっていたりで、和やかな雰囲気でした。 今回のテーマは「見える化」です。ソフトウェアの世界は見えないものが非常に多いです。そして「見えない」ことにより、ソフトウェア開発では様々な問題が出てきます。例え

    「見える化」でソフトウェア開発! 〜オブジェクト指向 実践者の集い(第 3 弾) 参加レポート〜 sooey
  • http://mugiwara.jp/ki/?200511a

  • KPT法

    ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと(Keep)、問題だったので次はやめたいこと(Problem)、次にやってみたいこと(Try)の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「いつき」が良いようで、次々と利用者が

    KPT法
  • すごいKPT事後評価セッション

    すごいKPT事後評価セッション 先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。 招待状 参加者には、以下の事前準備をメールでリクエストしておいた。 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流) 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」) スコープ、スケジュール、リソース、欠陥レベル プロジェクト運営 コラボレーション (スタッフ間) 個人・チームとして学習した点 その他 (開発手法など) 問題点については「どのようにすれば〜(だろうか)

    すごいKPT事後評価セッション
  • KPTを使ったプロセス改善(2):An Agile Way:オルタナティブ・ブログ

    Issue … Problem質化。問題を見つめ、質的「課題」としたもの。「5回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK(ケプターク)と言う名前でKPTの拡張として、Alistairに提案したところ、「日人はカイゼン慣れしてるな~」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl

    KPTを使ったプロセス改善(2):An Agile Way:オルタナティブ・ブログ
  • KPTを使ったプロセス改善:An Agile Way:オルタナティブ・ブログ

    ソフトウェア開発の繰り返し単位(イテレーション)ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる(ぼくは「ふりかえり」という言葉が好きだ)。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT(ケプト)と呼ぶ(Keep/Problem/Try)。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが3つのセクションに分かれており、Keep(このまま続けること)、Problem(問題点)、Try(次に試してみたいこと)と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ

    KPTを使ったプロセス改善:An Agile Way:オルタナティブ・ブログ
  • 1