差分

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

--- 20170617_retrospective_agilejapankyoto [2017-06-17 15:40] – tosihisa@netfort.gr.jp
+++ 20170617_retrospective_agilejapankyoto [2017-06-18 00:40] (現在) – tosihisa@netfort.gr.jp
@@ 行 6: / 行 6: @@
 アジャイルは，振返りが大切だと思いますので，私なりにこのイベントに参加して感じたことなどを振り返ってみます．
+なるべく正確に書いているつもりですが，思い出しながらですので漏れや間違いがあるかも知れません．
+この記事で何か FeedBack があれば，  https://twitter.com/tosihisa 宛にお知らせいただけたらと思います．
   * 【成果】セッション1:「メトリクスによる「見える化」のススメ： No 見える化、No 改善」ワークショップでは，講師からイノベーションと評価を頂きました．
@@ 行 20: / 行 22: @@
 落ちないバーンダウンチャートのメトリクスで見えてきた，特定のメンバーにレビューが偏る傾向は，深く共感出来る内容でした．
-私は，一度職場でコミットログから何人がどれくらいのペースでコミットしているかを調べたことが過去にあるのですが，数十名のプロジェクトで，特定の2名がソースコード全体の40％近くをコミットしていることを見つけたことがあります．
-パレートの法則は，ソースコードのコミットだけでなく，レビューにも当てはまるのかも知れません．
+私は，過去に，コミットログから何人がどれくらいのペースでコミットしているかを調べたことがあるのですが，数十名のプログラマが参画するプロジェクトで，特定の2名がソースコード全体の40％近くをコミットしていることを見つけたことがあります．
+パレートの法則にあるようなバラつき(偏り)は，ソースコードのコミットだけでなく，レビューにも当てはまるのかも知れません．
 続いて「メトリクスの工夫や活用で、 状況を「見える化」 してみよう。」のお題でワークショップです．
@@ 行 87: / 行 90: @@
 チームが片付けられるキャパシティは，時間とメンバー人数の面積で表現でき，片付けるモノも，同じく時間と片付けに必要な人数の面積で表現する．と言うものです．
-ただ，面積で表現した場合，変化をどの様に掴むか．と言う点が課題になります．
+ただ，面積で表現した場合，片付け前後（片付け中）の変化をどの様に掴むか．と言う点が課題になります．
 グラフは変化（傾向）を見るには向いていますが，この様に面積で図示すると，片付け前後での変化が分かりにくくなります．
+ここで，伊藤さん（講師）から「(変化は)目grepが良いのでは？」とアドバイス．
+あ，なるほど．．．と言うところで，この面積を，定期的に写真でカシャカシャ撮って，動画にすると，面積の動きが動画で見えてくるようになるかな？と言うアイデアがメンバーから自然に出て，「面積の動画でマネジメントすると良くね？」と言う感じになりました．
+==== Sprint 5: はっぴょう！ ====
+発表時間は2分で，少しキョドったかもしれませんが，何とか発表は出来ました．
+===== Retrospective =====
+ざっと振り返ると，テーマは良いのですが，メトリクスの論点が理路整然としていないかなぁ〜と言う感じですね．
+出席されたみなさんの自己組織力は高く，私のマネジメントが至らなかったかなと思います．
+自己組織力が高いみなさんと議論をさせて頂いた結果，「イノベーション」と評価を頂けたのは，今後の励みになります．
+メトリクスの実践としては，面積的な表現について，現場で実践できるように考えようと思います．
+ありがとうございます．マスター．自分でもよく考えてみます．