エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。 ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとか
段取りとマイクロマネジメントとスクラム - yigarashiのブログ
仕事ができるエンジニアはだいたい段取りがうまい。達成したいゴールがあるときに、AとBとCをやる必要があって、Bはわからないことが多いから先にやろうとか、AとCは並行してできるからCを誰かにお願いしようとか、とにかく目標を達成するための道のりをうまく計画できる人が多い。こういう作業をそつなくこなせるかが、ジュニアと一人前を区別する重要な指標のひとつと言える。そしてこの段取りをうまくできない人に対して、細かい計画を立ててあげて指示をするのがマイクロマネジメントだと思う。 スクラムにおけるスプリントプランニングは、この段取りをチームでやると思うとよく腹落ちする。達成したいゴールとしていくつかのプロダクトバックログアイテムを置いて、その達成に必要な作業を半日から1日で終わるサイズのタスクにみんなで分解して、不明点を一緒に洗い出して、どういう順番でやっていくか計画を立てる。まさに段取りだ。これがスク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
