ベロシティを"安定させる" の代わりに "制御する" といいたい - noy72.com
典型的なスクラムではない開発プロセスでベロシティの安定化に取り組んで、「安定させることそのもの」に集中するのはそれほど意味がないな、と感じたので言語化した。 自分が経験している開発プロセスについて フレームワーク タイムボックスが変動するスクラムで開発している。具体的には 新規事業×生成 AI の不確実性を乗り越える開発プロセス - Speaker Deck を参照。 ベロシティの計測方法 1 週間ごとに完了した PBI の pt の合計をベロシティとしている。つまり、ベロシティの計測の頻度とタイムボックスの期間は必ずしも一致しない。 「安定」についての誤解 「安定させる」は簡単そうに見える。ベロシティを上げるわけでもないので、今まで通り毎日決められた分の仕事をすれば良いだけである。だが、実際はそんな簡単な話ではないと思い始めている。 例えるなら、「散らかった部屋を片付ける・散らからないよ
1on1 をメンティーが主体的に進める - noy72.com
最近 1on1 の進め方に少し変えて、自分がたくさん話すようにしている。 1on1 の進め方を変えたきっかけは『エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング：書籍案内｜技術評論社』に載っている「他者説得」と「自己説得」の話である。 メンタリングでは、他者説得よりも自己説得を重視し、その獲得を促します。(p.86) とあり、メンターもそうやって自己説得を狙っているのかな～と思った。 自分はメンティーの立場でしか 1on1 をやったことがないので、メンタリングする方法については「そうなんだ～」という感じで読んでいた。 ただ、メンティーが「自己説得されやすい振る舞いをする」ことはできるのではと思って、1on1 の進め方を少し変えた。 自分が主体となって問題を解決する 「どうすればいいですか」という問いは解決法を提示してもらうことになるので、自己説得にはならなさ
どこから手をつけたらよいかわからない仕事をどう進めるか - noy72.com
要件を整理して具体的なやることまで落とし込むことができないのでどうやったらよいか相談してもらった。 達成したいことはなんとなくわかっているが、具体的に何をどう進めていくかわからない仕事があったとき、自分には手に負えないなと思ってしまう。実際にやってみると、何かするけどあんまり進んでないという状態になる。 こういう仕事をどんなふうに進めるかについて教えてもらっているので、その内容をまとめてみる。 本文でいう「仕事」は PBI とかストーリーとか実現したいこととかを意味している。 流れ ゴールを決める 関係者を洗い出す ゴールの達成のために何をしなければならないかを明らかにする 何をするか決まったら、それを実現する方法を考えて決定する 実現する方法について、技術やリリースの段取りなど、詳細を検討する。タスクを分解する 実際にタスクをこなす 細かい説明 ゴールを明らかにする 仕事で達成したいこと
小さく始めてコントロールできる範囲で問題を起こす - noy72.com
スクラムに関係した話第二弾。 前回書いた記事と似た話。 よりぬきスクラム（問題は起こる） 以下の記事を読んだ。 本稿では、開発業務以外にスクラムの要素を採り入れるために、私たちが行ってきたことをお伝えします。 スクラムのプラクティスを一部導入したという内容で、プラクティスをすべて実践するのではなく、意図的に一部分だけ実践しているらしい。 スクラムは「理解は容易、習得は困難」と表現されるように、そのフレームワークをまるごときちんと実践するのはとても困難です。また、いきなりスクラムをまるごと導入し、それがチームにフィットしなければ形骸化してしまう可能性もあります。ですから、まずは「できそうなこと、効果がありそうなこと」にしぼり、スクラムを「ひとまず、小さく始めてみる」のが重要だと考えています。 この部分はまさにその通りな気がする。実際、スクラムを導入しようにもいきなりすべてのプラクティスを導入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテナ技術に入門した - noy72.com
