レゴを使用してソフトウェア開発へのアジャイルアプローチの利点を示す

Zoneのクライアント制作ディレクターであるTobyDykesは、インフラストラクチャのない村とたくさんのレゴという2つの志望デザイナーチームを使用して、アジャイルのメリットを示しています…

はじめに

ソフトウェア開発プロジェクトにアジャイルアプローチを採用する理由はたくさんあります e ntプロジェクトですが、おそらくこれらの最も基本的なものは、イニシアチブを減らすことができます。皮肉なことに、代理店内では、これは販売プロセス中に見落とされることが多い要因です。これは、プロジェクトの最後に(理論的には)何が提供されるかを前もって正確に合意する方が本質的に安全だと感じているためだと思います。そして、クライアントは、彼らが望むものを正確に詳述する文書を約束されているという事実に安心することが想定されています。不便な真実を除いて、それは次のとおりです。

a)彼らが望むものは彼らが必要とするものではないかもしれません

b)彼らが望んでいることは、彼らのニーズを満たすための最も効率的でも費用効果的な解決策でもないかもしれません

c)彼らが望んでいることは、利用可能な時間と予算の範囲内で達成できない可能性があります。

私はこの機会を利用して、今年のゾーンエージェンシーデーでこれを実際に実証しようとしました。その一部は、さまざまなトピックに関する一連のマスタークラスで構成されています。私はクラスを7人ずつの2つのチームに分け、市民はたくさんいるがインフラがない村の市長の役割を引き受けることを伝えました。チームの仕事は、次の90分間で、私の人々のために村を設計して建設することでした。村を2回建設しました。最初はウォーターフォールアプローチを使用し、次にアジャイルの原則を採用しました。

私は各チームのメンバーを彼らのビジネスアナリストとして志願しました。彼らは私の要件を尋ねてくれました。これらは、私の村のインフラストラクチャの欠如に対するかなり簡単な解決策でした:

・傾斜屋根の赤い家

・スライドとブランコのある遊び場

・学校

・お店

・施設間を移動するために私の人々が使用する道路網

次に、各チームに5分間かけて村のデザインを依頼し、お気に入りのデザインを作成したチームに契約を結びました。演習には競争力のある要素があることを知っていたので、彼らは創造的なビジョンの詳細と複雑さで私を驚かせようとしました。

お気に入りを選んだら、チームに両方契約が交わされ、この勝利のデザインに対抗するためにすぐに取り組む予定であることを伝えました。村を建設するのに20分かかり、その後5分間のユーザー受け入れテストと市長のフィードバックがあり、さらに5分間で、テストプロセス中に発生した問題を解決します。その時だけ、私はレゴの山をそれぞれの机に傾けたときに、私の村が作られる材料をチームに知らせました。チームは、色が間違っていて、必要な傾斜屋根がないにもかかわらず、作業を開始し、適度に印象的な構造を構築しました。

ユーザーテスト期間の20分後、私はチームをユーザーに紹介しました…デュプロの人々は、初心者にとっては、レゴの人々の約2倍のサイズです。これは彼らが家の中に収まらないことを意味しました。また、チームが私の要件を満たせず、言い訳に興味がなかったことを強調する建設的なフィードバックをチームに提供しました(「しかし、十分な赤レンガがありません!」「レゴからスイングを構築することはできません!」 」)。

その後の5分間は、チームが(より大きな)家を一から再建し、車が収まるように道路を広げようとしたが、一般的にはお互いに、そして私と議論を始めた。

まさに私が望んでいたことでした。実際、それよりも、チームメンバーの1人が「私はとても怒っている…」とつぶやくのを聞いた。私は彼女に詳しく説明するように頼んだ。彼女はブリーフが間違っていて、彼らは、構築に必要な材料を知っていました。

多くの人は、レゴブロックがソフトウェアエンジニアリングの世界における技術者の知識を表していることを認識しているでしょう。そして、このプロセスは、(少なくとも)開発者とテスターを最初からソリューションの形成に関与させない限り、ビルドプロセスは非常に非効率的であることを示していました。

アジャイル

次に、アジャイルについて簡単に紹介し、チームに再開するように伝えましたが、3つの重要な違いがあります。まず、要件をソリューションではなく目的として説明します。第二に、私は彼らに手の込んだデザインを作成するように頼むつもりはありませんが、ソリューションが構築されているときにソリューションをデザインすることを彼らに信頼します。そして最後に、村の建物を5つの短い「スプリント」に分割し、ユーザー受け入れテストと市長のフィードバックを各スプリントの最後に簡単に行いました。

私の目的は次のとおりです。

・村人に安全で乾燥し、プライバシーの要素を持たせることができる場所を作ってほしい

・子供たちが遊べる場所が欲しい

・子供たちがどこかで学べるようにしたい

・村人が物を買う場所が欲しい

・村人が施設間を移動するために使用するネットワークが欲しい

今回、私はチームにデュプロのレンガを渡し、5分後に彼らは再びいくつかの印象的な構造を構築しました。チームAは適度に大きな家を建てましたが、目的に基づいた要件により、チームBは大きな共同スペースを選択したため、慣例による制約が少なくなったようです。次に、(比較的小さい)レゴフィギュアであるユーザーにチームを紹介しました。チームAは、そのような大きな家を作る必要がなくなったことに気づきました。チームBも、それほど重要な建物は必要ないことに気づきましたが、もっと重大な問題があることを伝えました。村人は安全で乾燥していましたが、プライバシーはまったくありませんでした。彼らは失敗した。しかし…彼らは早い段階で失敗し、状況を是正するために5分間のスプリントを4回行いました。

チームAは次のスプリントを自信を持って小さな家を作成しましたが、これは目的に適していることがわかりました。これらは、少し広い場合でも目的に合った最初の大きな家の隣に誇らしげに立っていました(ただし、市長?)。しかし、チームBはすぐにコミューンを取り壊し、村人のために小さな家を建て始めました。

次のデモンストレーションははるかに成功し、チームは住居の正当性を検証するのではなく、潜在的な機能(「必要に応じてドアを作ることができますか?」)について私に尋ねる機会を得ました。その後のスプリント中に、彼らは私の他の目的に進むことができ、数分でこれを確認できることを知って、実行可能と思われるものを提供するアプローチを再び採用しました。

おそらくここでの最も良い例は子供の遊び場でした。技術的に複雑なスライドを作成する代わりに、指定された場所にレンガの山を置き、それが「子供たちが遊ぶ場所」という私の目的を達成できるかどうかを尋ねました。お父さんとして、私は子供たちが物事を優雅に滑り降りるのと同じように物事を離れて幸せになることを知っていたので、私はこの概念をすぐに承認しました。チームはここでかなりの時間を節約しました。同様に、私は彼らに解決策を処方するのではなく、使用する材料に関する知識に基づいて私の目的に効率的に解決策を提供することを彼らに信頼することによってそうすることを許可しました。

今、私は、プラスチック製のレンガの山を机の上に置いているチームにあまりにも多くの重要性を与えているように思えます。しかし、ソフトウェアエンジニアリングでは、規定の要件に取り組むときに、紹介で強調した3つの基本的な問題に遭遇します。 1つ目は、処方された解決策がより広い目的を満たさない可能性があることです(子供たちはスライドが好きですか?それとも単に大人の楽しみの解釈を表すだけですか?)。 2つ目は、処方された解決策が、根本的な目的を達成するための最も効率的なアプローチである可能性が低いことです(ブロックと比較して、スイングとスライドは構築が難しく、ブロックよりもはるかに楽しいものではありません)。そして最後に、そうでない場合でも(設計段階でスイングが描かれる可能性があるという理由だけで)、規定のソリューションが完全に提供される(そして実際にできる)ことを期待します。それは、許可された時間内にレゴで構築できることを意味しましたか?実際、私の市長の期待が設定され、子供たちがそれを望んでいるかどうかに関係なく、スイングだけが行うので、これはもはや問題ではありませんでした。

目的に焦点を合わせる

正確な要件に対応する負担から解放され、代わりに根本的な目的に焦点を当てれば、ソリューションの最初の実行可能な反復(たとえば、目的のソリューションの20%)を提供し、その程度を確認できます。目的を満たしています。ソリューションのこの20%が、たとえば目標の90%を満たしている場合、ソリューションの残りの80%(目標の残りの10%のみを獲得する)は優先度が低くなる可能性が高く、次に進むことができます。もっと重要な何か。そして、ソリューションの20%が目的の0%を満たしている場合、意図したソリューションが誤った前提に基づいている可能性があるという非常に貴重な早期の兆候があり、この前提を再検討するか、別のことに進む必要があります。

このアプローチの副産物は、特定の機能が要求される理由を質問することが推奨されることにも注意することが重要です。機能はレガシーソリューション内に存在するため(顧客が実際に気に入って使用しているかどうかを確認しましたか?使用している場合は改善できますか?)、または誰かが個人的に好きなものであるため、バニティプロジェクトとして要求されることがよくあります。 、しかしユーザーのニーズを満たしていません。

チームAの場合、私の市長の意見では、彼らはレンガの山で目的の約90%を達成しました。遊び場でスライドが利用できるようになると、子供たちは2回降りてから、物事から身をかがめる。そこで、彼らは学校の建設と道路網の描画に移りました。これは、テスト目的で定期的にアクセスできるレゴ車に十分な広さでした。彼らは箸で自転車道を作り(昼食が到着しました)、少し左のフィールドの解決策が適切かどうか私に尋ねるのを快適に感じました。実際、デモンストレーションはリラックスした楽しいセッションになり、私たち全員がアイデアや意見を交換しました。そして、チームBはそれほど遅れをとらず、完全ではありませんが居住可能な村を建設したため、2回目のスプリント以降に私に価値をもたらしました。

プロセス全体は、私が期待していたとおりに進みました。 OK、ウォーターフォールフェーズでは、傾斜屋根、スライド、技術的に不可能なスイングなど、明らかにブリックでないコンセプトを含め、チームがレゴで提供するのに苦労することを知っているという要件を意図的に述べました。しかし、私が予想していなかったのは、最終的なアジャイルビレッジは、率直に言って、修羅場だった最終的なウォーターフォールビレッジ自体よりも、ウォーターフォールビレッジのクリエイティブなデザインに非常に似ているということでした。

結論

最初は、演習からどのような教訓が得られるかはよくわかりませんでしたが、2つのアプローチの最も重要な違いは、反復の長さと、処方要件と目標設定の違いでした。

アジャイルアプローチに含まれる反復は明らかに改善されましたが、主にユーザーと市長からのフィードバックループが短縮されたため、チームはソリューションを早期に検証(または失敗して適応/ピボット)することができました。短い反復は明らかな改善のように思われるため、多くのソフトウェアエンジニアリングプロジェクトがこのアプローチを採用しています。反復で機能するという理由だけで、自分自身を「アジャイル」と呼ぶ人さえいます。ただし、規定の要件ではなく、目的に反して作業する相対的な自由をチームに契約上提供しない場合、提供されるフィードバックは、チームが所定の解決策をどの程度満たしているかに基づいて行われます。もちろん、これが技術的に効率的な解決策になる可能性は低く、最後に成功したかどうかだけがわかります。これは私にはかなり危険に思えます。