チームでさまざまな開発スタイル（トップダウンとボトムアップ）に対処する方法は？

たとえば、{現在は比較的小さいが、将来的には大きくなる可能性がある}プロジェクトで、非常に小さなチームで作業を始めたばかりだとしましょう。これは、実際の世界の他の開発者が使用することを目的とした実際のプロジェクトであり、学期の終わりに廃棄されることを意図した学術プロジェクトではないことに注意してください。
ただし、コードはまだ他の人にリリースされていないため、まだ決定が確定していません。

方法論

コーディングを開始して、すべてのコンポーネントがどのように正確に相互作用するかを明確に理解する前に、ピースを一緒に合わせることが好きです（ボトムアップ設計）。もう1人は、最初に設計全体を行い、ソリューションをコーディングする前にすべてのコンポーネントと通信の詳細を特定することを好みます。

既存のシステムを模倣するのではなく、新しいシステムで作業しているため、適切な最終設計がどのように見えるかが必ずしも明らかではないと想定します。そのため、チームでは、チームメンバーごとに、最終製品にどのような要件が必要であるかについてのアイデアが異なることがあります。

ボトムアップ開発者がいくつかのコードを書くとき、トップダウン開発者は、コードが手元の問題を解決するかもしれないという事実にもかかわらず、設計で想定される潜在的な将来の問題のためにそれを拒否します。問題の解決策をコーディングする前に。

トップダウン開発者がコードを書き始める前に完全な設計と想定される問題を解決しようとすると、ボトムアップ開発者は実際に問題の一部が実際に発生するとは思わないため、ボトムアップ開発者はそれを拒否します、および要件と制約がより明確になったときに、設計を将来変更する必要があるかもしれないと考えています。

問題

これにより、ボトムアップ開発者は設計上の欠陥のためにボトムアップ開発者が書いたソリューションを廃棄すべきであると頻繁に判断するため、ボトムアップ開発者が時間を無駄にしてしまうという問題があります。 -コードを記述します。

トップダウン開発者は、作業を並列化する代わりに、ボトムアップ開発者と正しい設計を行うために頻繁に座って、2つをより速くなる可能性があるまで直列化するため、時間が無駄になります1人が2人よりも仕事をする。

両方の開発者は協力を続けたいと考えていますが、実際にこの組み合わせが実際にどちらかを支援しているようには見えません。

目標

共通の目標は、明らかにコーディングの効果を最大化する（つまり、時間の浪費を最小化する）ことと、有用なソフトウェアを書くことです。

質問

簡単に言えば、どのようにこの問題を解決し、この状況に対処しますか？

時間を無駄にしないと考えることができる唯一の効率的なソリューションは、各開発者が自分のデザインのスタイルに従うようにすることです。しかし、これは、コードをレビューして、お互いの変更を実際に承認する必要があるとき、および他の人が使用するための一貫したフレームワークを設計しようとしているときに聞こえるよりも困難です。

もっと良い方法はありますか？

明らかに両方とも間違っています。

ボトムアップの人はコードをハッキングして、それがするはずのことをすることは決してありません-未知の要件が決定されるにつれて、それは絶え間なく変化します。

トップダウンの男は、建築ビジョンに同じくらいの時間を費やすことができ、生産的なことも何もできません。

ただし、中盤が理想的です-あなたが目指している目標（幅広い設計作業から得られる）を知っていて、それをコーディングする（詳細な計画なしで）ことができれば、システムの報酬を得ることができます組織的かつ効率的に開発されました。

ちなみにアジャイルと呼ばれます（作業ソフトウェアよりも手順が重要な場合に実践する一部の人々が使用するアジャイルのBSバージョンではありません）が、一般的に説明され理解されている最終目標に向かって進む真のアジャイルです。

ここで問題を修正するには、アジャイルアプローチ（かんばんがおそらく最良）を試してみてください。これは、トップダウンの人に何らかの仕事をさせ、ボトムアップの人に彼が達成しようとしていることを計画させることです。

2人の開発者は、お互いの相互尊重を維持する必要があります。

トップダウンの人は、ボトムアップの人が実際に働くものを思いついたかもしれないという事実を尊重する必要があります。私の「クオント」教授の一人が私に言ったように、「実用的なモデルは1000の推測に値する」。その場合、トップダウンの人は、ボトムアップの人の仕事に対応するために「デザイン」をやり直すことを検討する必要があります。

また、ボトムアップの人はトップダウンの人の「フレームワーク」を尊重し、無駄な努力を避けたり、間違った問題を解決したり、トピックから外れたりするのに適していることを理解する必要があります。人物トップダウンがされてしようとしてフレームワークで表現されるよう、やって、そのアドレスに、少なくともトップダウナーの懸念を試してみてください。ボトムアップがフレームワーク自体の一部に同意しなかったとしても、それは真実です。

大きなタスクを複数の小さくてより集中的なタスクに分割する場合、各開発者が費やす時間の損失を最小限に抑えることができます。両者が密接に連携するようにして、どちらも先に進みすぎないようにします。短いスプリントと小さな成果物は大いに役立ちます。大きな間違いよりも小さな間違いを修正する方が簡単です。

それはあなたの目標に直観に反しているように見えるかもしれませんが、ペアプログラミングは機能します。自分ではすぐにキャッチできないものがあります。時には数時間から数日かかることもあります。一緒にタスクに直接取り組むことが問題にならない場合は、1週間を通してコードのレビュー/スタンドアップをより頻繁に試してください。

みんなに知らせてください！

開発者が自分の世界でオフになっているためにコードをスローするのを見ている場合は、競合をキャッチし、可能な限り迅速かつ効率的に調整する必要があります。あなたの上司はそれを高く評価し、チームは他の男が何をしていたのかわからなかったので、1週間の仕事を捨てないことを高く評価します。

また、彼らが一緒に祝福として働いているのを見るべきです。彼らが一緒に働いて、彼らが行くように彼らの間違いを修正しているという事実は良い兆候です。私はあなたの投稿の途中で「これらの2人はおそらく互いに嫌いだ...」と考えており、驚いたことに彼らは一緒に働き続けたいと言っていました。

この引用はあなたのシナリオを考えると適切だと思います。

「2人がすべてに同意する場合、そのうちの1人は不要です。」〜Some Old Guy

これは実際、私にとって理想的なシナリオのように聞こえます。繰り返しますが、私は同時に両方の開発者でもあります。「全体像」をメモの形で起草し、最終的に課題追跡システムに持ち込むのが好きです。次に、実装の詳細についてボトムアップで考え始めます。全体像は、ピースがどのように組み合わされるかについての理解が深まるにつれて変化し、要件が変化し、新しいアイデアが得られるとピースが変化します。

多分それは複数の脳の良いモデルです。

私の意見では、それらは補完的なプロファイルであり、非常にうまくいくかもしれません。プログラミングではコーディングと設計の両方が必要なフェーズであり、Xをやりたくないチームになりたくないので、必要なのは少し編成するだけです（太字もできます！）。

これは、他の人が指摘したように監督を通じて行うことができますが、設計するタイミングとコーディングするタイミングの反復スケジュールを相互に合意し、現在設計中のものを一般的にコーディングすることを回避することでさらに良くなります。

ボーナスポイントは、プロジェクトがより小さなモジュールでスプラットになるとすぐに、トップダウンプログラマーはボトムアッププログラマーが現在取り組んでいないものを設計できるため、両方が好きなようになるフェーズになります。ただし、これは、すべてをまとめるときが来たときに、必要な調整を行うための両方の能力を意味します。

1つのメモ：あなたは言った

既存のシステムを模倣するのではなく、新しいシステムで作業しているため、適切な最終設計がどのように見えるかが必ずしも明らかではないと想定します。

これは問題の一部です。すでに解決された問題の小さなプロジェクトに取り組んでいない限り、実際には正しい設計はありません。考えられるデザインはたくさんあります。コードの美しさのためにエゴを高めるためにこれを行っていない限り、最終目標は機能するアプリであることを覚えておいてください。それでおしまい。どうやってそこにたどり着くかは関係ありませんが、これら2つを高速に進める最良の方法は、補完的に連携させることです。

他の人が言ったように、両方の見解は特定の方法で正しいことがあります。2人の開発者がプラクティス、特に設計および開発プロセスと同じくらい主観的なものに異議を唱えることは珍しいことではありません。ここには、彼らの仕事に情熱を持ち、それを行う方法に精通している2人の人々がいます。

ここでは、両方の人が独自の方法で作業できるようにし、作業アプリケーションを取得するためにピースを一致させる大きな可能性があります。

1. 二人に座って話し合い、相手の視点から見るように勧めます。

2. その議論の後、計画について話し始めることができます。これはチームとして行われるべきであり、どちらも相手に「認める」必要はありませんが、妥協が必要であると理解しています。コードベースのアーキテクチャを計画する多くの方法があり、大量の余分なコードを導入することなく、後で簡単に拡張することができます。

3. ある種の休戦に来ることができるようになったら、彼らを暴走させてください！「トップダウンガイ」が高レベルアーキテクチャ、インターフェイス、階層などの計画を推進します。「ボトムアップガイ」が飛び込み、いくつかのモジュールが計画されたらコードの記述を開始します。他の方法をプロジェクト全体にとって良いものとして受け入れることに正式に同意してもらいます。将来の変更を簡単に行えるように計画するのは良いことですが、すぐにコーディングする必要はありません。インターフェイスとスタブアウトメソッドを作成してコードの構造を取得し、将来のコードのかなりの部分が必要になるまで実際には書き込まれないことを受け入れます。

4. 設計とコードの両方を頻繁に一緒にレビューしてもらいます。サイクルを反復して、アーキテクチャのいくつかのセグメントを深く掘り下げ、より詳細に計画し、それらの部分を記述します。

5. これはおそらく最も重要なポイントです。実行されている作業ではなく、プロセスのみについて話し合うサイクルのポイントを促進します。構築されているダイナミックを振り返る：尋ねるべき4つの質問があります。私たちがやるべきことは何がうまくいったのでしょうか？私たちがやめるべきことは何がうまくいかなかったのですか？何が欠けていますか？不足しているものについて何ができますか？

これにはいくつかの作業が必要になります。それぞれの方法で一緒に作業することに同意してもらう必要があります。一部の人々にとって、物事を行うための単一の正しい方法がないことを認めることは容易ではありません。重要なことは、どの方法で作業するか、または最終的にコードがどのように見えるかではありません。重要なことは、これらの2人の熟練した知識豊富な人々が、最高の連携方法を学ぶことです。ただ伝えることができるものではありません。できることは、自分でそれを行う方法を学習するプロセスをガイドすることだけです。正しいデザインが存在しないように、人々が働くための正しい方法は存在しません。

一般的に、私のキャリアにおける私の経験では、前もって不十分な設計があります。そして、前もって起こるデザインは低品質です。これは悪いです。ほとんどの場合、結果は（多かれ少なかれ）壁に泥を投げて、何が付着しているかを見るからです。技術的な負債は、手始めから焼き付けられます。

一般に、トップダウンはボトムアップよりも優れています。ボトムアップを完全に排除するわけではありませんが。この理由は、トップダウンにより、問題についてより広く考え、より良い質問をするように強制されるためです。これにより、上記の最初のポイントが強化されます。高品質の設計につながり、通常、低レベルの作業の多くに大きな影響を与えます。これにより、下位レベルのコンポーネントを最初に構築する場合に必要になることが多い再作業が削減されます。

ボトムアップコンポーネントが最初に構築された場合、開発の圧力が、設計されたコンポーネントにビジネス要件を形成しようとするという、取るに足らないリスクがあります。これも悪いです。ビジネス要件が設計を推進し、それが実装を推進するはずです。逆の方向に進むと、結果が悪化します。

どちらのアプローチも十分ではありません。それぞれが他のアプローチの短所を理解するのに十分賢いまたは経験豊富であるようです（おそらく彼らは火傷しましたか？）

真実は、混合アプローチが必要です：

• 「正しい」設計を事前に思いつくことはほぼ不可能です。痛みのポイント、ボトルネックなどを特定するためにある程度の実験が必要です...
• ただ「行く」だけでどこにでも行くことはほとんど不可能です。

ただし、両方を混在させると、次のことができます。

• インフラストラクチャの方向とスケルトンを提供する大まかなスケッチを持っている
• このビジョンに合ったコンポーネントの開発

この目的を満たす既存のシステムは存在しないため、次のことを事前に認識することが重要です。

• 実験/プロトタイピングが必要になります
• したがって、反復が必要になります

したがって、これはコーナーケースなどを無視することを意味する場合でも、できるだけ早く「作業」システムに到達することに重点を置く必要があります...これは「薄い垂直スライス」の概念です：家の基礎を構築する代わりに、次に壁、次に屋根の構造...そして最後に使用可能なもののみを取得します（または取得しない、または実際に使用できない）...代わりに完全に装備された部屋を最初に構築することをお勧めします、バスルームのような。すぐに使用でき、フィードバックを収集するために使用できます。

ただし、フィードバックを価値あるものにするためには、まず中核部分に取り組むことが最善です。

それでは、同僚とはどうしますか？

まず最初に、両者はコラボレーションの必要性と今後の道のりに同意する必要性を理解する必要があるということです：常にre責されることは、自分の神経を握り、モチベーションに影響を与えます。複数のプロジェクトで実際にうまく機能することがわかったものを上記に示しましたが、提案として使用できます。

次に、誰が何をするかについて合意する必要があります。上記の下線で示した中間的なアプローチでは、どちらも評価の高いタスクを行う必要があります。

スケルトンの構築とブリックの構築の両方に段階的にアプローチするのが最適であることに注意してください。

1. 両方ともスケルトンの大まかなスケッチを取得し、次に最初に焦点を合わせる「薄いスライス」を一緒に決定する必要があります
2. ボトムアップの人は、最もよく理解されている「薄いスライス」の部分で作業を開始する必要があります
3. トップダウンの男はスケルトンの肉付けを開始し、理想的にはスライスを完了するために最もブロックの多い部分に最初に取り組む必要があります

すすぎ、スライスが機能するまで繰り返します。必要に応じて微調整する途中でフィードバックを蓄積します。

注意：これはプロトタイプであり、完全に別の設計でそれを捨てる準備とゼロから始める必要があります。

必要なのは、ソフトウェア開発を理解し、プロジェクトでどのアプローチを使用するかを決定するリーダー（またはスーパーバイザー）です。必要に応じて、リーダーは開発者に個人的な好みに関係なく特定の方法で作業するよう指示します。

時間を無駄にしないと考えることができる唯一の効率的なソリューションは、各開発者が自分のデザインのスタイルに従うようにすることです。

実際には、非常に非効率的かもしれません...なぜなら、多くの衝突とやり直しが起こる可能性があるからです。さらに悪いことに、プロジェクト全体が失敗する可能性があります。