差分

このページの2つのバージョン間の差分を表示します。

--- 20170617_retrospective_agilejapankyoto [2017-06-17 22:51]
tosihisa@netfort.gr.jp
+++ 20170617_retrospective_agilejapankyoto [2017-06-18 09:40]
tosihisa@netfort.gr.jp
@@ 行 1: / 行 1: @@
 ====== Agile Japan 2017 京都サテライトの振返り ======
+#AgileJapanKyoto
 {{ :img_1684.jpg?400 |}}
 アジャイルは，振返りが大切だと思いますので，私なりにこのイベントに参加して感じたことなどを振り返ってみます．
+なるべく正確に書いているつもりですが，思い出しながらですので漏れや間違いがあるかも知れません．
+この記事で何か FeedBack があれば，  https://twitter.com/tosihisa 宛にお知らせいただけたらと思います．
-  * 【成果】「メトリクスによる「見える化」のススメ： No 見える化、No 改善」では，講師からイノベーションと評価を頂きました．
+  * 【成果】セッション1:「メトリクスによる「見える化」のススメ： No 見える化、No 改善」ワークショップでは，講師からイノベーションと評価を頂きました．
   * 【気付き】「見える化」は，数値化やグラフ化にこだわる必要は無いのかも知れません．
@@ 行 11: / 行 15: @@
   * https://connpass.com/event/55728/
-メトリクスによる「見える化」のススメ： No 見える化、No 改善：
+===== メトリクスによる「見える化」のススメ： No 見える化、No 改善 =====
   * https://www.slideshare.net/ssuser968fab/no-no-55603839
+始めのお話は，開発者（報告する側）とマネージャ（報告を受ける側）のギャップについてのお話でした．
+落ちないバーンダウンチャートのメトリクスで見えてきた，特定のメンバーにレビューが偏る傾向は，深く共感出来る内容でした．
+私は，過去に，コミットログから何人がどれくらいのペースでコミットしているかを調べたことがあるのですが，数十名のプログラマが参画するプロジェクトで，特定の2名がソースコード全体の40％近くをコミットしていることを見つけたことがあります．
+パレートの法則にあるようなバラつき(偏り)は，ソースコードのコミットだけでなく，レビューにも当てはまるのかも知れません．
+続いて「メトリクスの工夫や活用で、 状況を「見える化」 してみよう。」のお題でワークショップです．
+==== Sprint 0: チームづくり ====
+各席に4名で，4名のうち1名はマネージャです．私は，管理職（と言っても下っ端ですけど．．．）ですので，マネージャと言う役割で参加しました．
+==== Sprint 1: 課題の共有 ====
+自己紹介と各自の課題の共有です．
+皆さん初めましてですが，付箋紙で即席名札を作ったのは良かったと思います．
+これは災害時のボランティア活動の経験でも同じことが言えるのですが，名乗るだけではなく，即席で名札を作るのは，コミュニケーションを取る上で良いと思います．
+課題の共有は，私を含め4名のメンバーのうち2名の方が「（部屋などの）片付け」を課題に感じておられたので，自然とテーマは「片付け」にまとまったと思います．
+==== Sprint 2: メトリクス案の検討 ====
+共通課題は，「片付け」で自然に決まりました．これは公私を問わず普遍的な課題と思います．
+「片付け」について，どの様にメトリクスを取るか，メンバー皆さんで議論しました．
+メンバーの方でカラーペンを持参されてきた方がいました．この様なワークショップでは，文字を色分け出来るのはとても助かります．また積極的に筆記頂き，本当に助かりました．
+以下，五月雨ですが議論した内容を覚えている範囲で書きます．
+  * 先に，「そのメトリクスは、マネージャ・開発者それぞれの 視点から嬉しいものになっていますか？」について議論をしました．
+    * 開発者視点だと，「（片付いていることは）気持ちがいい（嬉しい）」
+    * マネージャ視点だと，「（片付いていることは）ノイズがない（嬉しい）」
+      * 実際，職場でマネージャとしてメンバーから報告を受けるときや，作業依頼をする時，「ノイズ」が少なからず発生します．
+      * 例えば，あるタスクを進める（依頼する）には参考書籍が必要だけれど本棚がゴチャゴチャしていてパッと見で見当たらないとか，揃っているはずの開発機材がどうも全部揃って無さそうだと言うようなものです．
+      * これらは本来進めるべきタスクに対するノイズで，片付け（整理整頓）できていれば余計な作業依頼をせずに済みます．
+  * 「片付いた」の定義（ゴール）の共有が必要かな．
+  * 片付けるモノのグループ化が良いかな．
+  * 計測できるようにするには，「片付けにくいもの or 片付けたいもの」 と，「片付けやすいもの」でグループ分けすると良いかな．
+  * 「片付けにくいもの or 片付けたいもの」は，見積り的に言えば高ポイントになるのかも．
+  * 「片付けやすいもの」は，低ポイントになるのかも．
+  * これらの数（ポイント）を測ると，「片付け」が測定できるかも知れない．
+  * グループ分けは，何か判断指標を設ける？→（マネージャとしては）開発者の主観で良いと思います．
+    * ある特定のモノが片付けにくいか片付けやすいかは，やはり現場のメンバーが一番良く分かると思うからです．
+議論はよい感じに進んでいたのですが，タイムリミットの少し前まで__チーム名を決めるのを忘れていた！__ので，急遽チーム名を決める事にしました．
+  * 片付けチーム？→ルンバ？→ルンバいいかも→アジャイルなルンバ？→アジャイルンバ！？
+と言うようなノリです．アジャイルな片付け（自動化？）と言う意味でアジャイルンバと言うのは面白いかもという感じです．
+==== Sprint 3: トレードショー ====
+トレードショーでは，他の席の課題を見て，FeedBackをする（受ける）と言うものです．色々 FeedBack を頂きました．
+==== Sprint 4: 改善（検査と適応）  ====
+FeedBackで頂いたコメントに，「片付ける理由にメイワク度によってポイントするとか」と頂き，これは確かに観点として抜けていました．
+それと，ココで「片付け（度合い）」の具体的な算出方法について，詰まってしまいました．算出（数値化）するとして，どの様な要素で数値化すれば良いのかです．
+片付けやすいもの，片付けにくいもの，メイワク度でのポイント化は算出するための要素にはなり得ると思いますが，それで良いのかどうかです．
+メンバーで色々ディスカッション行くうちに，「時間」と「人数」の面積表現が良いのかな？と思うようになりました．下記のようなものです．
+{{ :img_1684_mini.png |}}
+片付けるには，「時間」と言う要素は必要ですし，一人で片付けられるものもあれば，片付けに複数名が必要な物もあります．この二つの要素で面積を作ると言うものです．
+チームが片付けられるキャパシティは，時間とメンバー人数の面積で表現でき，片付けるモノも，同じく時間と片付けに必要な人数の面積で表現する．と言うものです．
+ただ，面積で表現した場合，片付け前後（片付け中）の変化をどの様に掴むか．と言う点が課題になります．
+グラフは変化（傾向）を見るには向いていますが，この様に面積で図示すると，片付け前後での変化が分かりにくくなります．
+ここで，伊藤さん（講師）から「(変化は)目grepが良いのでは？」とアドバイス．
+あ，なるほど．．．と言うところで，この面積を，定期的に写真でカシャカシャ撮って，動画にすると，面積の動きが動画で見えてくるようになるかな？と言うアイデアがメンバーから自然に出て，「面積の動画でマネジメントすると良くね？」と言う感じになりました．
+==== Sprint 5: はっぴょう！ ====
+発表時間は2分で，少しキョドったかもしれませんが，何とか発表は出来ました．
+===== Retrospective =====
+ざっと振り返ると，テーマは良いのですが，メトリクスの論点が理路整然としていないかなぁ〜と言う感じですね．
+出席されたみなさんの自己組織力は高く，私のマネジメントが至らなかったかなと思います．
+自己組織力が高いみなさんと議論をさせて頂いた結果，「イノベーション」と評価を頂けたのは，今後の励みになります．
+メトリクスの実践としては，面積的な表現について，現場で実践できるように考えようと思います．
+ありがとうございます．マスター．自分でもよく考えてみます．

tosihisa's public notebook

ユーザ用ツール

サイト用ツール

差分

ページ用ツール