お客様の信号を迅速にテストするコストと適切な事前設計を比較するコストをどのように比較すればよいですか？
開発スタイルが大きく異なる2人のエンジニアがいます。
エンジニアAは、事前の計画と設計を高度に行うことを好み、長所/短所を計画して、すべての可能なオプションを考慮します。エンジニアBは、テストする最短のパスを見つけることを好みます。
私たちはskunkworksチームであり、たくさんの新しいアイデアをテストする責任があります。したがって、エンジニアBは正しい道を進んでいるようです。一方、エンジニアAの理論的根拠は、もし何かがうまくいけば、私たちがしたことの多くを捨てて、それを「正しく」構築しなければならないということです。つまり、「ゆっくり行くから速く行く」という考え方です。
私は必死にこのチームの技術リーダーを雇おうとしていますが、その間に私が担当していて、技術的な背景の欠如が明らかになり始めています。何かアドバイスがあったり、私を正しい方向に向けたりすることも役に立ちます！
これらのものには明らかにスライド式のスケールがありますが、あなたへの私の一番のアドバイスは、「適切な計画」または「速いvs遅い」などの感情的に読み込まれた用語の使用をやめることです。
技術要件を明確にし、明記されていない隠れた要件がないことを確認してください。 （言うより簡単だ）
これにより、開発者は機能をスキップして高速化するのか、それとも見逃せない機能を追加するのかを評価できます。
次に、チームの戦略目標を明確にします。つまり第3四半期までに10個のデモプロジェクトを完了してください。
これにより、開発者は、個々のプロジェクトに費やす時間を判断することができます。
第三に。顧客を考慮に入れてください。一部の人々hate不完全な製品を見る "もちろん、私は私の会社の設計ガイドに従って完全にスタイルを付けたいです！完成したら見せてください！"要件を前もって尋ねられるのが嫌いな人もいます。「ボタンが表示されるまで、どこにボタンを配置するかはわかりません。何かを見せれば、さらに詳しく説明します。」
私たちは...たくさんの新しいアイデアをテストする責任があります。
次に、最小実行可能製品に焦点を当てる必要があります。基本的に、私はBに同意します。早期のフィードバックと反復を取得すると、より強力な結果の製品が得られますユーザーの観点から。それは粗末なエンジニアリングを意味するわけではありませんが、 [〜＃〜] yagni [〜＃〜] に大きく依存することを意味し、確かに、事前設計に多くの時間を費やすことは、悪いアイデア。 Aは、最初はこれがイライラすることに気づくでしょうが、うまくいけば、製品がユーザーに合うように成長するのを見て、その価値がわかるでしょう。
次のように見てください。Aは、やり直す必要があると心配しています。しかし、ユーザーが不人気だったり、以前のアプローチと互換性のない新しい要件が発生したりするため、どちらのパスをたどっても最終的には再構築されます。古い問題の完璧なソリューションを設計するために何週間も費やしていた場合、これは非常にイライラします。あなたがそれに何日も費やしただけなら、それほどではありません。 Pragmatic Programmerは トレーサーの箇条書き について話し、あなたがターゲットにどれだけ近いかについてのライブフィードバックを取得します（特に、移動するターゲット、またはそれがどこにあるかまだわからない場合）。
また、成功した場合に何が起こるかについて考えます。あなたがスカンクワークであり、何かが役に立つと判明した場合、それはあなたの手から取り出され、他の誰かに与えられますか？洗練された製品を作成することで、より広範な組織に実際に価値を提供していますか、それとも、チームが製品のコアバリューを実証し、それに基づいて構築またはリエンジニアリングするチームに適合させると、誰もが良い結果を出すでしょうか？彼らは便利な顧客情報の束、実用的なプロトタイプ、そして自分たちのやり方で再構築するときに再利用できるコア機能に関するいくつかのエンドツーエンドのテストで幸せかもしれません。
それで、あなたはそれについて何ができますか？まず、チームの目標が何であるか、チームとその製品の成功がどのように測定されるかを明確にします。小さなチームと短いタイムスケールで試してみる新しいアイデアがたくさんある場合は、cannotすべてを完全に作成します（「完全に」とは何かを理解できる場合でも、それだけで十分です他の答え）、それで、彼らがより少ない基準をより高い基準に、またはより高い基準に優先して構築すべきかどうかについて明確にしてください。結果を測定および比較するためのフレームワークを提供することにより、彼らができない技術的な決定を行うのを支援します。
次に、2人が緊密に協力すること、またはプログラムをペアにすることを奨励します。傾向の異なる他のエンジニアとペアを組むことは、私たちの長所と短所のバランスをとるのに良い方法であることがわかりました。 BはAに早期のフィードバックの価値を見てゴールドプレートへの傾向を落とすように促すことができ、Aは全体像を考える傾向を利用して、チームの開発を続ける能力に反する「行き止まり」の決定を回避することができます。新しい要件が発生したときのアプリ。
事前のアーキテクチャと設計の大きな支持者として、私はしぶしぶこのエンジニアのBがこの特定のシナリオで正しいことに同意する必要があります。
チームの主な責任は非常に具体的な製品を作成しないことであるかのように聞こえますが、プロトタイプを開発することで、将来の製品のインキュベーターのように聞こえます。特定の状況では、プロトタイプを作成し、それを別のチームに引き渡して適切な製品に改良することに集中することをお勧めします。その時点で、適切なアーキテクチャと事前設計を行う必要があると主張します。これは、お客様の システム品質 の重要な技術的非機能要件を特定するのに役立ちます。
他のチームは、適切なパスがプロトタイプの大部分をリファクタリングしていることに気付くかもしれませんが、これは予想されることです。リワークは、市場や生産に遅れるよりもはるかに安価な場合があります。 Twitterの初期を見てください。 RAD技術とRubyテクノロジーを組み合わせた手法を使用して、基本的に迅速に開発されました。Twitterが普及すると、これはすぐに拡大されず、大部分が書き直されましたJavaで。
以上のことをすべて述べた上で、先行設計であっても、設計成果物は技術的アイデアを伝達または伝達する手段としてのみ役立つことに留意してください。アーキテクチャがどれだけ十分であるかについての本当に良い本がここにあります... Just Enough Software Architecture、A Risk Driven Approach 。
彼らにそれをうまく働かせます。
彼らがあなたのところに来て、意見の違いで同点を破るなら、あなたがそうしないときにあなたがよりよく知っているふりをしないでください。何かがあなたを間違っていると思ったとしても、その理由を明確に説明することができない限り、そう言ってはいけません。知らないときは投票しないでください。あなたが知識を提供することができるならそれで結構です。彼らがバランスの取れた妥協案に到達することを望まない場合、引き分けの最終的な権威はコインです。