レイオフ後にアジャイルを行う

作者 Mark Levison , 翻訳者 沼田 暁子 投稿日 2009年1月19日

セクション

プロセス/プラクティス

トピック

Agile in the Enterprise ,

Agile ,

変化

タグ

Scrum

Adrian Carr氏(リンク)は、レイオフ後に自分のチームでのスクラムのインプリメンテーションを適合させることについて書いている。当初チームは、開発者が４人とテスター、プロダクトオーナー、そしてスクラムマスタのグループであった。人員削減後、チームは４人のメンバに縮小され、Adrian氏は非常勤のスクラムマスタとなり、専門のプロダクトオーナーはいなくなった。ビジネスユニットも開発グループと同じようにスタッフの配置に関する問題を抱えており、「ビジネスを理解していてプロジェクトについて決定する権限を与えられた、経験豊富な連絡先となる人」を提供することだけができる。そこで彼が持ちつづけた疑問は、スクラムのどの部分を続けるべきか？ということである。Adrian氏が最初の段階で行ったことには次のものが含まれた。

• スクラムの中で、小さなグループでも意味のあることだけを続ける：デイリースタンドアップ、短いスプリント、レビュー、ふりかえり、可視化されたプロジェクトのバーンダウン。
• チームのみんながプロダクトオーナーの役割の一部について責任を負い、ステークホルダやエンドユーザ等と打ち合わせを行うが、Adrian氏がプロダクトバックログを整備し、最終決定を下したりするだろう。
• 無駄を無くす。
• 物事をできるだけシンプルに保つ。
• 製品にデプロイされる機能だけに向けられたストーリーを評価する。これは、チームがもっと小さく扱いやすい機能を作成せざるをえなくなることを期待している。こうすることによってサイクル時間は削減に向かい、もっと多くのフィードバックを提供するはずである。
• 作業を少しずつ - 同時に２～３の項目のみ - 行う。
• 最も価値の高い項目を最初にデリバリすることに集中する。
• 誰のためにそのソフトウェアを開発しているのかを知る。彼らの名前、役割、そして彼らがそのことを行っている理由を知る。
• チームのスピードを鈍化させる外的要因に目を光らせ、こつこつ取り組む。

Innovel社のRobin Dymond氏(リンク)には、ひとつ大きな懸案事項がある：専門のプロダクトオーナーがいないことである。開発者がその役割を果たすためにはビジネスの主題の専門家になる必要があるだろうが、開発をしなければならない時間が減る、と彼は述べている。そのかわり、彼は次のことを薦めている。

もしも顧客が時間に追われているのであれば、開発チームは頻繁に短い打ち合わせを行います。そうすることによって、彼らはそれを書くのとは対照的に、受け入れ基準を承認することができ、優先事項に集中することができます。しかしながら、彼らは役割を果たし、責任を負う必要があります。チームは、彼らのためにこれを負うことができません。チームは必然的に物事に対して違った解釈し、異なる優先度を選び、ビジネスとは異なる決定をすることがよくあるからです。

Mary Poppendieck's氏(リンク)（Implementing Lean Software Developmentの著者）の意見では、プロダクトオーナーは必ずしも必要であったり望ましいわけではない。なぜなら彼女は、開発者が顧客の要求を理解している場合は、プロダクトオーナーは別のレイヤーを追加し、伝達したせいで情報が失われる可能性があると考えるからである。Mary氏にとって、鍵となるのは、皆が目標として同意できるような優れたシンプルな測定をすることである。そうすれば、この目標のために提供する価値に対して、全ての機能を測ることが出来る。

Ron Jeffries氏(リンク)はチームとプロダクトオーナー、そしてビジネスユニットの明確さが無くなる可能性について警告している。もし製品が顧客の要求にぴったりのものでないことが判明した場合、ビジネスは意見を変えて開発チームの決定を非難する可能性がある。Ron氏は、従来のプロダクトオーナー/カスタマーの役割りのメリットの１つは、もしも製品がエンドユーザの期待に沿わなくても、ビジネスユニットにとって自分達以外に非難する相手がいないことである、と指摘している。

 

原文はこちらです：http://www.infoq.com/news/2009/01/agile-layoffs

• 次へ >