振り返りはKPT法より『KWT法』がオススメ｜栗原康太
チームや個人の振り返りを、Keep・Problem・Tryの頭文字から取ったKPT法ではなく、Keep・Wakattakoto・Tryの頭文字から取ったKWT法でやっているのだけど、多くの会社・チーム・個人におすすめしたい。 KPT法の弊害KPT法は優れた手法で、僕も数年間やっていたけど、デメリットとして、 ・チームでやると、どうしてもProblemで他者攻撃になりやすい ・Problemの時間が辛くなる ・結果、チームに定着しづらい というのがあった。毎週末に個人で、KPT法をやっていたときも、Problemの部分には、自己嫌悪や内罰的な表現が並んで、正直やってて辛くなるときがある（笑） ※先日、コーポレートメディアで書いた『「ありえないミスをする人」の脳内では、何が起きているのか。』の、セルフ1からセルフ2の攻撃を毎週末、わざわざ時間を取ってやってた感もあるｗ KWT法の良いところそん
ある改善、プラクティスやTryをいつやめるのか。もしくは5000枚のKPTの理由。 #scrumosaka #rsgt2019 - うさぎ組
先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。 きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか？ これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと チームにできるプラクティスは残るし、できないプラクティスは残らない。 というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 で
あなたの開発チームには、チームワークがあふれていますか？
23. DevQA 💫 ( ) http://www.slideshare.net/POStudy/devqa-qa-postudy
ふりかえりにつかうレイアウト「4G」を考えた - Holidays in the Sun
チームのふりかえりにつかうホワイトボードのレイアウトをかんがえました。 なぜ？ 「役割を考えてチームの体制をつくる」というふりかえりミーティングのファシリテーションをする予定がありました。 お互いの思っていることを言い合うプロセスは必要（というか大事）なんだけども、なるだけ早めにチームとして機能する状態にしたい。そのうえ、開発業務とちがって「どういう役割が必要なのかあまり想像つかないぞ….」と思ってたわけです。 チームのふりかえりではKPTをよく使うんですけど、今回のケースだとTRYとして体制まで考えるのは結構大変で、もう一歩踏み込んだやり方を「ホワイトボードのレイアウトを上手く使ってとれないか？」とかんがえたんです。 どうやって使うの？ 何らかのチーム作業を（スプリント０）一度経験しておく。 チームの目指す目標は最初にかいておく。 ひととおり矢印の順番にすすめる。 詳しくは以下スライドを
本当はすごいKPTで強いチームを作る for エンジニア - Qiita
この通り、KPTはみんなでやるデバッグ作業です Problem -> Try -> Keepと全てはつながっています 繋がっていないKeepは？ ナレッジ共有と捉えると良いと思います ただ、その場合もはじめに何かしらの問題があって〜からスタートすることが多いのではないでしょうか KPTすごい これで何となく伝わりますかね？ KPTが毎週上手く回っている ＝ 毎週バグを潰している １年続けると KPTが回っている → テスト53回、デバッグ53回行って、チケット消化しつづけ改善してる状態 KPTが回っていない → テスト0、デバッグ0、チケット消化数0 KPTを上手く回すには 伝わったとしたら幸いです それでは次にKPTを上手く回すことを目標にします そもそも上手く回ってる、良い状態ってどんな感じでしょうか？ 良いKPT＝良いデバッグ エンジニアならもう既にわかるはずです 良いProblem
ベロシティを目標にする危険性について学んだことをアジャイルサムライ風に振り返ってみた - Grooves開発ブログ
こんにちは、Forkwell事業部の中の人です。 本日は、つい最近 Forkwell Jobs の開発現場で起きたエピソードについてご紹介します。 きっかけはあるメンバーの一言でした。 「複数メンバーの加入から1ヶ月以上がたった、ベロシティもかなり安定してきた。よし、ここらでおれたちのベロシティをあげて、ビジネスサイドの連中をあっと言わせてやろうぜ！」 この一言で息巻いた我々は、ベロシティをあげることを目標に設定し、ビジネスサイドのホワイトボードに ◯pt / 10pt のような数字を書き加えました。 しかし、すぐに色々な現場を経験してきた他事業部のエンジニアの面々から、ベロシティをあげることを目標にすることには弊害があることを教わることになりました… ベロシティを目標にする弊害 目先のポイントを増やすためにとりあえずリリースして残タスクを先に積む事案が発生、後々の作業が滞る 目先のポイン
ふりかえりで初心者が陥りやすい落とし穴 〜 性格も実力も急に変えられないが行動は改善できる | Social Change!
私たちソニックガーデンでは、現場での人材育成の手段として個人の「ふりかえり」と、そのレビューを行っています。それを「ワークレビュー」と呼んでいますが、仕事の進めかたや、仕事に対する姿勢についてふりかえった内容を、メンターがレビューすることで行動の改善と成長を促します。 進めかたとしては、まずは対象者が一人で良かったこと（Keep）や問題（Problem）について洗い出しを行うのですが、ふりかえりに慣れていない初心者がつまづいてしまう様子を何度か見てきました。この記事では「ふりかえり」で、よく陥りやすいパターンと、その解消法について書きました。 自分の内面のことを問題にしてしまう ふりかえりをして問題を洗い出すときに、慣れていないと、ついやってしまうのが自分の内面や性格のことを問題としてあげるケースです。 たとえば、思っているよりも成果を出せていない、それは躓いたときに先輩に相談できてないか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
