アジャイル開発のタスク見積もりでやりがちなミス - HOW TO GO
アジャイル開発、主にスクラムをやっている人にとってタスクの見積りは悩ましいところかと思います。 個人的な備忘録も兼ねてよくあるミスをまとめてみます。 ここでのタスクの見積もりとはスクラムガイドにあるスプリント計画ミーティング第２部のことです。念のため。 ①見積りポーカーで時間がかかりすぎる 見積りポーカーを用いて見積りをするのはよい方法なんですが、いかんせん時間がかかりすぎる場合が多いと感じています。 みんな様子を伺っていてこれといった決め手がないままダラダラと議論してしまう 逆に好き勝手に話をしてもよいと思うメンバーがいて、決め手がないまま話が長くなってしまう。 見積りポーカーをやる理由は「タスク量の認識ズレをなくすこと」です。 認識ズレがないようなら見積りポーカーは必要ないはずです。そもそも別の方法でもよいかもしれません。 対策 認識ズレがありそうなタスクに対してのみ見積もりポーカーを
個人のせいにする前にプロセスやシステムを疑え - HOW TO GO
最近いくつかのプロジェクトで同じことが起きてます。 「何か問題があると個人の問題にする」という現象です。 「個人の問題」 例えば品質問題。 ある個人のコードの質が悪かったんです。たまたま結合試験で気づきました。試験担当者がたまたまコードを見ながら試験したから気がついたんです。 「あいつの書くコードはちょっとなぁ…」という意見が複数出ました。 例えば生産性。（生産性って言葉はあまり好きじゃないのですが、プロジェクトではこの言葉を使っていました。技術力と同じような意味なんですが） ある個人のスキルがあまり高くなく、コードを書くのに時間が掛かります。システム開発の経験も少ないのでプログラム言語、業務仕様の理解も他のメンバーより時間が掛かります。 チームとしても顧客の求める計画を達成できていませんでした。 「あいつがチームの生産性を落としてるから計画通り進んでないんだ」とマネージャーは言いました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
