チームでさまざまな開発スタイル（トップダウンとボトムアップ）に対処するにはどうすればよいですか？
非常に小さなチームで{現在は比較的小規模ですが、後で大きくなる可能性がある}プロジェクトの作業を始めたとします。これは、現実の世界の他の開発者が使用することを意図した実際のプロジェクトであり、学期の終わりに破棄されることを意図したいくつかの学術プロジェクトではないことに注意してください。
しかし、コードはまだ他の人にリリースされていないため、決定はまだ確定されていません。
方法論
すべてのコンポーネントがどのように相互作用するかを明確に理解する前に、コーディングを開始し、各要素を組み合わせていくのが好きな方もいます（ボトムアップ設計）。もう1人は、最初に設計全体を行い、ソリューションをコーディングする前にすべてのコンポーネントと通信の詳細を確認することを好みます。
既存のシステムを模倣するのではなくnewシステムで作業していると仮定します。したがって、適切な最終設計がどのように見えるかが必ずしも明確ではありません。そのため、チームのメンバーによっては、最終的な製品に必要な要件さえも、場合によっては設計の進め方についても、異なるアイデアを持っていることがあります。
ボトムアップ開発者がいくつかのコードを書くとき、トップダウン開発者は、コードが目前の問題を解決するかもしれないという事実にもかかわらず、デザインで予想される将来の問題のため、それを拒否します。問題の解決策をコーディングする前に。
トップダウン開発者がコードの記述を開始する前に完全な設計と想定される問題を解決しようとすると、ボトムアップ開発者は実際に問題の一部が発生するとは考えていないため、それを拒否します。 、および要件と制約が明らかになったときに、設計を将来変更する必要があると考えています。
問題
これがもたらした問題は、ボトムアップ開発者が設計ミスのためにボトムアップ開発者が作成したソリューションを廃棄する必要があると頻繁に決定するため、ボトムアップ開発者が時間を浪費してしまい、結果として再作成が必要になることです。 -コードを記述します。
トップダウン開発者は、作業を並列化する代わりに、多くの場合、ボトムアップ開発者と一緒に正しいデザインを作成するために座り、2つをさらに高速化できるポイントまでシリアル化するため、時間を無駄にしてしまいます。 2人より1人で作業を行います。
どちらの開発者も一緒に仕事を続けたいと思っていますが、実際にはどちらの開発者もこの組み合わせが役立っているようには見えません。
目標
共通の目標は、コーディングの効果を最大化する（つまり、時間の浪費を最小限に抑える）ことと、有用なソフトウェアを作成することです。
質問
簡単に言えば、この問題をどのように解決し、この状況に対処しますか？
時間を無駄にしないと考えることができる唯一の効率的な解決策は、各開発者にデザインの独自のスタイルを実行させることです。しかし、コードレビューを行って実際にお互いの変更を承認する必要がある場合や、他のユーザーが使用する一貫したフレームワークを設計しようとしている場合は、これは想像以上に難しいものです。
もっと良い方法はありますか？
明らかに、どちらも間違っています。
ボトムアップの男はコードをハッキングしており、想定されていることを実行する何かを生成することは決してありません-未知の要件が決定されると、それは継続的なチャーンになります。
トップダウンの人は、アーキテクチャのビジョンと同じくらい長い時間を費やすことができ、生産的なことも何もできません。
ただし、中途半端が理想的です。目標とする目標（大規模な設計作業から得たもの）がわかっていて、それを（詳細な計画なしで）コーディングすると、システムのメリットを享受できます。組織化され、効率的に開発されました。
ちなみにアジャイルと呼ばれ（BSバージョンのアジャイルではなく、ソフトウェアが機能することよりも手順が重要な場合に実践されます）、一般的に説明され、理解されている最終目標に向かって取り組む真のアジャイルです。
ここで問題を解決するには、アジャイルアプローチを試してください（かんばんがおそらく最良です）。これは、トップダウンの男にいくつかの作業を強制し、ボトムアップの男に彼が達成しようとしていることを計画させることを強制します。
2人の開発者は、相互にrespectを維持する必要があります。
トップダウンの人は、ボトムアップの人が実際に機能する何かを考え出したかもしれないという事実を尊重する必要があります。私の「量的」教授の1人が私に言ったように、「実際のモデルは1000推測の価値があります」。その場合、トップダウンの人は、ボトムアップの人の仕事に対応するために「デザイン」をやり直すことを検討する必要があります。
ボトムアップの人はまた、トップダウンの人の「フレームワーク」を尊重し、無駄な努力を避けたり、間違った問題を解決したり、トピックから外れたりするのに適していることを理解する必要があります。ボトムアップコーダーは、少なくともトップダウンの人は、やってみようであり、フレームワークで表現されているように、少なくともトップダウンの懸念に対処しようとします。下から上の方がフレームワーク自体の一部に同意しなかったとしても、それは真実です。
大きなタスクを複数のより小さく集中したタスクに分割すると、各開発者が費やす時間の損失を最小限に抑えることができます。お互いに近づきすぎないようにしてください。短いスプリントと小さな成果物は長い道のりです。大きな間違いよりも小さな間違いを修正する方が簡単です。
それはあなたの目標に直感的に反するように見えるかもしれませんが、ペアプログラミングは機能します。自分ではすぐに理解できないことがあり、場合によっては数時間または数日かかることもあります。一緒にタスクに直接取り組むことが問題ではない場合は、週を通してより頻繁にコードのレビュー/スタンドアップを試してください。
全員に情報を提供してください！
開発者が自分の世界にいないためにコードをスローするのを見ている場合は、競合をできるだけ迅速かつ効率的にキャッチして調整する必要があります。あなたの上司はそれを高く評価し、チームは他の男が何をしていたのかわからなかったので、一週間の仕事を捨てる必要がないことを高く評価するでしょう。
それらが祝福として一緒に働いているのを見るべきです。彼らが一緒に働いて、彼らの行っている間違いを修正しているという事実は良い兆候です。私はあなたの投稿の途中で「この2人は恐らくお互いを憎んでいる...」と思っていましたが、驚いたことに、彼らは一緒に働き続けたいと言っていました。
この引用はあなたのシナリオを考えると適切だと思います。
「2人がすべてに同意する場合、そのうちの1人は不要です。」 〜老人
これは実際には私にとって理想的なシナリオのように聞こえます。繰り返しますが、私はam両方の開発者を同時にサポートします。私は、「全体像」をメモ形式で作成し、最終的には問題トラッカーにたどり着きます。次に、実装の詳細についてボトムアップで考え始めます。ピースがどのように組み合わされるかをよりよく理解するにつれて全体像が進化し、要件が変化して新しいアイデアを得るにつれてピースが進化します。
多分それは複数の頭脳のためのよいモデルです。
私の意見では、これらは補完的なプロファイルであり、非常にうまく機能する可能性があります。コーディングとデザインの両方がプログラミングに必要なフェーズであり、誰もXをやりたくないチームに行きたくないので、必要なのはorganizationのビットだけです（大胆にできます）。言葉も！）
これは、他の人が指摘するように監督を通じて行うことができますが、設計するタイミングとコーディングするタイミングの反復スケジュールを相互に合意し、一般に現在設計中のものをコーディングすることを避けることで、さらに改善できます。
ボーナスポイントは、プロジェクトが小さなモジュールでスプラットされるとすぐに、トップダウンプログラマーはボトムアッププログラマーが現在取り組んでいないものを設計できるため、両方が好きなように機能するフェーズになります。ただし、これは、すべてを組み合わせるときが来たときに必要な調整を行う両方の能力を意味します。
注：あなたは言った
既存のシステムを模倣するのではなく、新しいシステムで作業していると想定します。したがって、適切な最終設計がどのように見えるかが必ずしも明確ではありません。
これは問題の一部です：既に解決済みの問題の小さなプロジェクトで作業しているのでない限り、実際には正しい設計ではありません 。可能なデザインはたくさんあります。コードの美しさが原因でエゴブーストのためにこれを実行しているのでない限り、最終目標は動作するアプリであることを覚えておいてください。それでおしまい。あなたがそこに到達する方法は無関係であり、これらの2つを速く進めるための最良の方法は、補完的な方法でそれらを一緒に動作させることです。
他の人が言ったように、両方の見方は特定の方法で正しい場合があります。特に設計および開発プロセスと同じくらい主観的なものについては、2人の開発者が実践について意見を異にすることは珍しいことではありません。ここには、彼らの仕事に情熱を持ち、それをどのように行うかに精通している2人がいます。それを受け入れてください！
ここには、両方のユーザーが独自の方法で作業できるようにしながらも、部分を一致させて動作するアプリケーションを取得できる大きな可能性があります。
私は2人に座って話し合ってもらい、相手の視点から見られるように促します。
その議論の後、計画について話し始めることができます。これはチームとして行う必要があります。どちらも他方に「合意」する必要はないが、妥協する必要があることを理解してください。コードベースのアーキテクチャを計画する方法はたくさんあります。これにより、大量のコードを追加しなくても、後で簡単に拡張できるようになります。
あなたが彼らをある種の休戦に参加させることができたら、彼らを暴走させましょう！高レベルのアーキテクチャ、インターフェイス、階層などを計画する「トップダウンガイ」を推進しましょう。「ボトムアップガイ」にジャンプして、いくつかのモジュールが計画されたらコードを書き始めましょう。プロジェクト全体に対して他のメソッドを適切に受け入れることに正式に同意してもらいます：将来の変更を容易にするための計画は良いですが、すぐにコーディングする必要はありません。インターフェースを作成し、スタブアウトしますコードの構造を取得し、将来のためのコードのかなりの部分が実際に必要になるまで書き込まれないことを受け入れるメソッド。
設計とコードの両方を頻繁に一緒にレビューしてもらいます。アーキテクチャーのいくつかのセグメントに深く入り込み、より詳細に計画し、それらの部分を作成するサイクルを繰り返します。
これはおそらく最も重要なポイントです：彼らが行われている作業ではなく、プロセスのみについて話しているサイクルのポイントを促進します。構築されている動的なものを反映します。私たちが続けなければならないことは何がうまくいきましたか？やめるべきことは何がうまくいかなかったのでしょうか。何が欠けていますか？足りないものに対して何ができるでしょうか？
これにはいくつかの作業が必要になります。独自の方法で一緒に作業することに同意してもらう必要があります。一部の人にとって、物事を行うための単一の正しい方法がないことを認めるのは簡単ではありません。重要なことは、どのように作業するか、またはコードが最終的にどのように見えるかではありません。 重要なことは、これらの2人の熟練した知識のある人々が一緒に最高の仕事をする方法を学ぶということです。それはあなたが彼らに伝えることができるだけのものではありません。あなたができることは、彼ら自身でそれを行う方法を学ぶプロセスを通して彼らを導くことです。ちょうど適切なデザインがないように、人々が働くための正しい方法もありません。
一般に、私のキャリアの経験では、前もって不十分デザインがあります。そして、前もって行われるデザインは低品質です。これは悪いです。ほとんどの場合、結果は（多かれ少なかれ）壁に泥を投げ、何が付着しているのかを確認するためです。技術的負債は、最初から組み込まれています。
トップダウンは通常、ボトムアップにsuperiorです。ボトムアップを完全に排除するわけではありませんが。この理由は、トップダウンでは、問題をより広く考えて、より良い質問を尋ねる必要があるためです。これは上記の最初のポイントを補強します...より高品質の設計につながり、通常は低レベルの作業の多くに大きな影響を与えます。これにより、下位レベルのコンポーネントを最初に作成する場合に必要となることが多い、かなりの再作業が削減されます。
ボトムアップコンポーネントが最初に構築された場合、開発のプレッシャーは、設計されたコンポーネントに対するビジネス要件を形成しようとするという重要なリスクがあります。これも悪いです。ビジネス要件が設計を推進し、それが実装を推進するはずです。逆の方向に進むと、結果が悪くなります。
どちらのアプローチも十分ではありません。それらのそれぞれは、他のアプローチの欠点を理解するのに十分なほど巧妙または経験豊富であるようです（多分、彼らはやけどを負ったのでしょうか？）が、彼ら自身が選択したアプローチの欠点を見逃しています...
真実は、混合アプローチが必要です：
- 「正しい」デザインを事前に思いつくことはほとんど不可能です。ペインポイント、ボトルネックなどを特定するにはある程度の実験が必要です...（ヒント：それらは、あなたがどこにあると思うところには決してありません）
- 単に「行く」だけでどこにでも行くことはほぼ不可能であり、あなたは何よりも、行きたくない場所、または単に輪になって走る場所で終わる可能性が高いです。
ただし、両方を混在させることはできます。
- 方向性とインフラストラクチャのスケルトンを示す大まかなスケッチがある
- このビジョンに合ったコンポーネントの開発
この目的を満たす既存のシステムは存在しないため、次のことを事前に認識することが重要です。
- 実験/プロトタイピングが必要になります
- したがって、反復が必要になります
したがって、コーナーケースなどを無視することを意味する場合でも、できるだけ早く「機能する」システムに到達することに重点を置く必要があります。これは、「薄い垂直スライス」の概念です。家の基礎を構築する代わりに、次に壁、次に屋根構造、そして最後に使用できるものだけを取得します（または取得しないか、実際には使用できない）...代わりに完全な装備を構築することをお勧めします部屋最初に、バスルームのように。すぐに使用でき、フィードバックの収集に使用できます。
ただし、フィードバックを価値あるものにするためには、最初にコアパーツに取り組むのが最善です。
それで、あなたの同僚はどうですか？
まず最初に、両者がコラボレーションの必要性と前進の方法について合意する必要性を理解する必要があるということです。彼らのように絶えず嫌がらせを受けることは、自分の神経に乗り、自分のモチベーションに影響を与えます。複数のプロジェクトで実際にうまく機能することがわかったものを上に示しましたが、それを提案として使用できます。
次に、誰が何をするかについて合意する必要があります。上記で下線を引いた中立的なアプローチでは、どちらも彼らが感謝する細かい作業をするべきであることに注意してください。
スケルトンの構築とブリックの構築の両方が段階的に行われるのが最善であることに注意してください。
- どちらもスケルトンの大まかなスケッチを取得してから、最初にどの「薄いスライス」に焦点を合わせるかを一緒に決定します
- ボトムアップの男は、「薄いスライス」の最もよく理解された部分に取り組み始める必要があります
- トップダウンの男はスケルトンを肉付けし始め、理想的には最もブロックしている部分に最初に取り組むスライスを完成させるため
すすぎ、スライスが機能するまで繰り返します。必要に応じて、Tweakへの途中でフィードバックを蓄積します。
注意：これはプロトタイプです。どちらも破棄する準備ができている必要があり、まったく異なるデザインでゼロから始める必要があります。
必要なのは、ソフトウェア開発を理解し、プロジェクトで使用するアプローチを決定するリーダー（またはスーパーバイザー）です。必要に応じて、リーダーdirects開発者は、個人的な好みに関係なく、特定の方法で作業します。
時間を無駄にしないと考えることができる唯一の効率的なソリューションは、各開発者に設計の独自のスタイルを実行させることです。
実際には、それはできません非常に非効率的です...多くの競合とやり直しがある可能性があるためです。さらに悪いことに、プロジェクト全体が失敗する可能性があります。