20170617_retrospective_agilejapankyoto
差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
20170617_retrospective_agilejapankyoto [2017-06-17 15:06] – tosihisa@netfort.gr.jp | 20170617_retrospective_agilejapankyoto [2017-06-18 00:40] (現在) – tosihisa@netfort.gr.jp | ||
---|---|---|---|
行 6: | 行 6: | ||
アジャイルは,振返りが大切だと思いますので,私なりにこのイベントに参加して感じたことなどを振り返ってみます. | アジャイルは,振返りが大切だと思いますので,私なりにこのイベントに参加して感じたことなどを振り返ってみます. | ||
+ | なるべく正確に書いているつもりですが,思い出しながらですので漏れや間違いがあるかも知れません. | ||
+ | この記事で何か FeedBack があれば, | ||
* 【成果】セッション1: | * 【成果】セッション1: | ||
行 20: | 行 22: | ||
落ちないバーンダウンチャートのメトリクスで見えてきた,特定のメンバーにレビューが偏る傾向は,深く共感出来る内容でした. | 落ちないバーンダウンチャートのメトリクスで見えてきた,特定のメンバーにレビューが偏る傾向は,深く共感出来る内容でした. | ||
- | 私は,一度職場でコミットログから何人がどれくらいのペースでコミットしているかを調べたことが過去にあるのですが,数十名のプロジェクトで,特定の2名がソースコード全体の40%近くをコミットしていることを見つけたことがあります. | ||
- | パレートの法則は,ソースコードのコミットだけでなく,レビューにも当てはまるのかも知れません. | + | 私は,過去に,コミットログから何人がどれくらいのペースでコミットしているかを調べたことがあるのですが,数十名のプログラマが参画するプロジェクトで,特定の2名がソースコード全体の40%近くをコミットしていることを見つけたことがあります. |
+ | |||
+ | パレートの法則にあるようなバラつき(偏り)は,ソースコードのコミットだけでなく,レビューにも当てはまるのかも知れません. | ||
続いて「メトリクスの工夫や活用で、 状況を「見える化」 してみよう。」のお題でワークショップです. | 続いて「メトリクスの工夫や活用で、 状況を「見える化」 してみよう。」のお題でワークショップです. | ||
行 44: | 行 47: | ||
「片付け」について,どの様にメトリクスを取るか,メンバー皆さんで議論しました. | 「片付け」について,どの様にメトリクスを取るか,メンバー皆さんで議論しました. | ||
- | メンバーの方でカラーペンを持参されてきた方がいました.また積極的に筆記頂き,とても助かりました. | + | メンバーの方でカラーペンを持参されてきた方がいました.この様なワークショップでは,文字を色分け出来るのはとても助かります.また積極的に筆記頂き,本当に助かりました. |
以下,五月雨ですが議論した内容を覚えている範囲で書きます. | 以下,五月雨ですが議論した内容を覚えている範囲で書きます. | ||
行 61: | 行 64: | ||
* グループ分けは,何か判断指標を設ける?→(マネージャとしては)開発者の主観で良いと思います. | * グループ分けは,何か判断指標を設ける?→(マネージャとしては)開発者の主観で良いと思います. | ||
* ある特定のモノが片付けにくいか片付けやすいかは,やはり現場のメンバーが一番良く分かると思うからです. | * ある特定のモノが片付けにくいか片付けやすいかは,やはり現場のメンバーが一番良く分かると思うからです. | ||
+ | |||
+ | 議論はよい感じに進んでいたのですが,タイムリミットの少し前まで__チーム名を決めるのを忘れていた!__ので,急遽チーム名を決める事にしました. | ||
+ | |||
+ | * 片付けチーム?→ルンバ?→ルンバいいかも→アジャイルなルンバ?→アジャイルンバ!? | ||
+ | |||
+ | と言うようなノリです.アジャイルな片付け(自動化?)と言う意味でアジャイルンバと言うのは面白いかもという感じです. | ||
+ | |||
+ | ==== Sprint 3: トレードショー ==== | ||
+ | |||
+ | トレードショーでは,他の席の課題を見て,FeedBackをする(受ける)と言うものです.色々 FeedBack を頂きました. | ||
+ | |||
+ | ==== Sprint 4: 改善(検査と適応) | ||
+ | |||
+ | FeedBackで頂いたコメントに,「片付ける理由にメイワク度によってポイントするとか」と頂き,これは確かに観点として抜けていました. | ||
+ | |||
+ | それと,ココで「片付け(度合い)」の具体的な算出方法について,詰まってしまいました.算出(数値化)するとして,どの様な要素で数値化すれば良いのかです. | ||
+ | 片付けやすいもの,片付けにくいもの,メイワク度でのポイント化は算出するための要素にはなり得ると思いますが,それで良いのかどうかです. | ||
+ | |||
+ | メンバーで色々ディスカッション行くうちに,「時間」と「人数」の面積表現が良いのかな?と思うようになりました.下記のようなものです. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | 片付けるには,「時間」と言う要素は必要ですし,一人で片付けられるものもあれば,片付けに複数名が必要な物もあります.この二つの要素で面積を作ると言うものです. | ||
+ | |||
+ | チームが片付けられるキャパシティは,時間とメンバー人数の面積で表現でき,片付けるモノも,同じく時間と片付けに必要な人数の面積で表現する.と言うものです. | ||
+ | |||
+ | ただ,面積で表現した場合,片付け前後(片付け中)の変化をどの様に掴むか.と言う点が課題になります. | ||
+ | |||
+ | グラフは変化(傾向)を見るには向いていますが,この様に面積で図示すると,片付け前後での変化が分かりにくくなります. | ||
+ | |||
+ | ここで,伊藤さん(講師)から「(変化は)目grepが良いのでは?」とアドバイス. | ||
+ | あ,なるほど...と言うところで,この面積を,定期的に写真でカシャカシャ撮って,動画にすると,面積の動きが動画で見えてくるようになるかな?と言うアイデアがメンバーから自然に出て,「面積の動画でマネジメントすると良くね?」と言う感じになりました. | ||
+ | |||
+ | ==== Sprint 5: はっぴょう! ==== | ||
+ | |||
+ | 発表時間は2分で,少しキョドったかもしれませんが,何とか発表は出来ました. | ||
+ | |||
+ | ===== Retrospective ===== | ||
+ | |||
+ | ざっと振り返ると,テーマは良いのですが,メトリクスの論点が理路整然としていないかなぁ〜と言う感じですね. | ||
+ | |||
+ | 出席されたみなさんの自己組織力は高く,私のマネジメントが至らなかったかなと思います. | ||
+ | |||
+ | 自己組織力が高いみなさんと議論をさせて頂いた結果,「イノベーション」と評価を頂けたのは,今後の励みになります. | ||
+ | |||
+ | メトリクスの実践としては,面積的な表現について,現場で実践できるように考えようと思います. | ||
+ | |||
+ | ありがとうございます.マスター.自分でもよく考えてみます. | ||
20170617_retrospective_agilejapankyoto.1497711973.txt.gz · 最終更新: 2017-06-17 15:06 by tosihisa@netfort.gr.jp