お昼休みに書いてみたシリーズ
逆説的、スケジュールを中途半端にしない、中途半端の感覚
この記事の概要
プロジェクトを進めるやり方で、「スクラム」というプロジェクトの進め方があり、
そこで行われるレビューの失敗から、学んだことを、まとめる記事です。
誤字脱字は、ごめんなさい。
グタグタな、レビューを防ぎたい
スプリントのレビューで、ぐだぐたに、なっているチームは多いのではなかろうかと思う。
中途半端な物では、レビューできない。
もっとわるいのは、レビュー当日の朝まで、修正して、レビュー準備ゼロとかである、
その原因で、身近にあった事例を思い出しながら記事を書いてみたいと思います。
見積を正確にする
見積で中途半端にしないところは、
・既存の処理があって、流用できるかどうか判断していること。
・作業分担したときに、ぶれないように、変数名が明確になっていること
ここまで、やるべきだとおもいます。
中途半端でいいかなとおもうのは、
意味がわかるレベルの誤字脱字やスペースや、レイアウト、を気にするよりは、作業スピードを
優先にしたほうがいいとおもいます。
たとえば、APIを作る場合、
工数を２時間前後のタスクで分けてみると、APIをつくるときの
パターンがみえてきます。なので、テンプレート化してしまえば、ある程度の見積項目作成は自動になるので、
誤字脱字もなくなります。
正確に見積もってないメンバーの見つけ方
こまるのは、バーンダウンが落ちているのをみて安心していて、
レビュー直前に、「じつは、この見積があまくて、作業量はｘ倍であることがわかりました。」
と、報告を受けることがあった。レビュー直前が近くなると、なにも手をうてない。
スプリント開始時点で、できないもの、むりなものを、明らかにしたほうが、手をうてる。
だいたいこういうメンバーのバーンダウンは、最初のバーンダウンの落ち方がスマートになって、後半
グダグダになるのである。
なので、見つけ方は、見積をみて、内容が文章化されているかどうか、をみないといけない。
作業の間隔
作業を行う上で中途半端にできないもの
全部のタスクをやりきることが重要
作業で中途半端にするのは、ある程度の見切り
作業には、時間の制約があるので、クオリティがある程度であればよしとしなくてはならない
こんな感じのことをおもいました。
よんだくださってありがとうございます。