スクラムの嗅覚 Mike Cohn スクラムは失敗することが出来ます。熱心なスクラムマスターは、常にプロジェクトを注意深く観察し、大問題 になる前に、問題が小さい（簡単に解決できる）状態で気付く責任があります。Refactoring という本（［和 書］リファクタリング―プログラムの体質改善テクニック）で、Martin Fowler さんは、たぶん正しくなくと嗅 覚で感じる言葉について言及しました。疑わしいというだけで問題ではありません。とはいえ、詳細な調査が 必要です。この記事は、スクラムの嗅覚を集める第一歩です。つまり、これらはスクラムプロジェクトに関する 欠陥のサインです。 リズムの損失 症状：スプリントの期間が（常に）異なる 考察：スクラムプロジェクトの経験があるチームは、自然なリズムを確立します。スプリントの期間は（常に） 同じです。スプリントは、要求の議論をするスプリント計画とスプリントの計画から始めます。スプリントは、 出荷可能な製品の漸進を実際に確認するスプリントレビューで終えます。スプリント中は、デイリースクラムに よってプロジェクトのリズムをつくります。 スプリントが２週間だったり４週間だったりすると、自然なリズムは決して確立されません。スプリントは、 チームの総合的な生産性を高める計画よりもチーム外の圧力（おそらく、政治もしくは対抗意識）による勝手 な期間設定に従い始めます。スプリント期間を変更する場合、チームは正しい仕事量を判断し、スプリントバッ クログを作るのに苦労します。その結果、チームはスプリントで公約した項目を完成させる事ができなくります。 ニワトリについて 症状：デイリースクラムに参加するニワトリは、質問や監視する 考察：デイリースクラムで話すことができる唯一の関係者は（プロジェクトに尽力する）ブタです。（関与する だけの）ニワトリは、参加できるかもしれないが、話す事はできません。ニワトリが会話をするのを許容する のは危険な傾向です。ニワトリの（役に立つ）コメントを許したら、（役に立たない）コメントをどのように防 ぎますか。 数ヶ月前、私は若い娘を地元の市場に連れて行きました。乗車場に通じる短い階段がありました。誰も階段に 座ることは許されていません。しかし、若い子供達は電車を待っている間、座りたがっていました。しかし、車 掌はそのルールを子供達に守らせました。車掌は、「私があなたを最初に座らせると、次々に座るでしょ う。」と言いました。明らかに最初に座るのは危険ではないでしょう。しかし、車掌は規則の説明に階段を利 用しました。ニワトリがデイリースクラムで話すのを禁止するのは、スクラムの（簡単な）規則の１つです。勿 論、ニワトリの全てのコメントに害がある訳ではありません。ですが、他の（害がある）コメントを誘発し、簡 単に境界線をひくことができなくなります。 不参加なブタ 症状：デイリースクラムに全てのブタが参加しない 考察：私が就業した時には、“フレックスタイム” はありませんでした。全ての会社には始業時間がありました。 全社員が、その時間に仕事を始めていました。多くのソフトウェア開発者の夜行性の習慣に合わせたフレックス タイムは、チームメンバー数名の１１時もしくはそれ以降の出社を許容します。私は、“キャプテン・ミッドナ イト” というニックネームをもった文字通り毎日、真夜中に出勤するプログラマーがいる、あるチームと働きま した。 © 2003, Mike Cohn © 2010 Kaoru Nakamura, Kazumasa EBATA 1 しかし、毎日、同じ時間、同じ場所で打ち合せを行ったのは、プロジェクトのリズムを確立、維持に役立ちま した。あまりに多くのブタがデイリースクラムに欠席すれば、おそらく打ち合せは、長時間におよぶか標準の３ つの質問から逸脱します。良いデイリースクラムは、１５分を超えませんし、常に各ブタにとって価値がありま す。時々、急な締め切りに間に合わせる時、デイリースクラムを省略したくなりますが、さほど悪いことではあ りません。状況が習慣的になったり、多くのブタが打ち合せを欠席するような状況になったら、疑い始めます。 持続的な特徴 症状：初期スプリントから継続してバーンダウンチャートが激しい変動を見せる 考察：Agile Software Development with Scrum という本（［和書］アジャイルソフトウェア開発スクラム） で、Ken Schwaber さんと Mike Beedle さんは、多くのチームは、最初のスプリントでは多くの仕事を入れ、 次は、仕事を少なくする等のユニークな特徴を持ったチームを紹介しました。しかし、チームが過去のスプリ ントから学ぶことは重要です。例えば、５人のチームが、約６００時間の仕事（バーンダウンチャートの開始 点）を見積り、前スプリントを開始したとします。スプリントの途中で、彼らは（仕事量が）多いと気付き、１ ００時間の仕事を削る相談をプロダクトオーナーにします。次のスプリント計画で、チームは再び６００時間の 仕事を見積ろうとしています。チームは、前スプリントで仕事が多く達成できなかった場合、このスプリントで 約６００時間の仕事を達成できる理由を説明しなければなりません。 徐々にチームが自分達とプロジェクト等を学ぶのは、スプリントバーンダウンチャートにおいて、初期スプリン トで生じた激しい変化の失敗から、理想線に近づけなければいけません。こうした傾向がみられない場合、 チームは自らの能力を学ぶ良い機会を逃しています。 スクラムマスターが仕事を割り当てる 症状：開発者が自発的に仕事を決めるのではなく、スクラムマスターが仕事を割り当てる 考察：自己組織化は、スクラムの基本的な原則の１つです。スクラムマスターが仕事を割り当てるのは、目標達 成すべく自己組織化しているチームの責任意識を弱体化させ、多くの損害を与え（身に迫るほど）危険です。 チームは、自ら仕事を完全に管理する意識がなければなりません。 スクラムマスターのためのデイリースクラム 症状：デイリースクラムが、スクラムマスターへの進捗報告になっている 考察：しばしば、デイリースクラムが、スクラムマスターのために行われているような気がします。スクラムマ スターが “猛烈に誰がどの仕事に公約し、達成しなかったタスクの理由等” をノートに走り書きしているのを目 撃するかもしれません。デイリースクラムは、開発工程の状態を確認する打ち合せです。 デイリースクラムには主に２つの目的があり、どちらにも、スクラムマスターへの進捗報告をふくんでいません。 デイリースクラムの１つの目的は、プロジェクトメンバー間の調整です。１日に１度、全員の状況把握するのは、 とても役立つことがあります。理想的ですが、勤務中は廊下等で様々な会話をしますが、チーム全員はそろって いません。デイリースクラムの間、全員で協力していると認識します。 デイリースクラムのもう１つの目的は、各チームメンバーが仲間に公約することです。開発者が「今日、何をし ますか。」という質問の回答は、スクラムマスターではなく仲間に公約します。翌日のデイリースクラムで、も し公約を達成していなければ、スクラムマスターは「チェッ、チェッ、ルーシー、昨日は完了すると公約しただ ろう」と言います。もし、ルーシーが完了していないと言ったら、恐らくとても気分を害します。彼女は、仲間 に公約した事を覚えています。また、不運、努力不足、タスクの複雑さを見誤った、もしくは、他の多様な理由 で完了できなかった事を把握しています。 © 2003, Mike Cohn © 2010 Kaoru Nakamura, Kazumasa EBATA 2 専門化した仕事 症状：チームが、アーキテクト、デザイナー、データベース管理者、テスター等の高い専門職で構成される 考察：スクラムチームは、“全員が一緒に働く姿勢（意識）” が必要です。チームが専門職で構成されている場 合、この姿勢（意識）を害すことがあります。例えば、チームに熱心な “テスター” がいたら、他のメンバーの テストに対する責任意識が薄れるかもしれません。 今日、世界的に非常に複雑な技術はデータベース管理であり、サーバサイド J2EE や .NET コードは誰にでも書 けると思うのは、安易過ぎます。成功するスクラムチームは、万能なメンバーで構成されているわけではありま せん。しかし、専門家チームが成功するには、各専門家がシステム全体に対し責任を持たなければいけません。 プロジェクトで最も複雑な “オラクル問題” の解決策を知らないかもしれませんが、支援できることは何でもし ます。それは、複雑な問題を解決するために、データベース管理者の他の作業を引き受けることもあるかもしれ ません。 Note：訳者（ebacky）より読者の皆様へ 中村薫（@kaoru55）さんに翻訳のご協力を頂きました。惜しみない協力を頂いた中村さんに感謝いたします。 Mike Cohn さんが原本を作成されたのは 2003 年です。翻訳した 2010 年現在も変わらず、私達は本資料の（類 似した）問題に遭遇します。スクラムは、銀の弾丸ではなく薄くて強固なフレームワークです。色々な問題を痛 いくらい表面化してくれます。ですが、問題の解決策は教えてくれません。 本当の問題解決とは、“自ら知恵を絞らなければ本当の解決は出来ない” Mike Cohn, Kazumasa EBATA © 2003, Mike Cohn © 2010 Kaoru Nakamura, Kazumasa EBATA 3
© Copyright 2024 Paperzz
