Adam Smithとフルスタック開発者-DevOpsの生産性？

Adam Smithによると、労働部門は240倍の効率化を実現できます（18の手順でピンを生産するピンファクトリーの例）。

では、実際に生産性が低下するのにマルチスキルの役割が非常に需要があるのはなぜですか、またはスミスが間違っていたのはなぜですか？

「フルスタック開発者」の検索はまだGoogleで傾向がありますが、明らかに2年前より遅くなっています。

=====

要約すると、フルスタックの開発者は、事実上すべてのバリューチェーンを実行できます（間違っている場合は修正してください）。

• 顧客と話し合い、仕事の彼の部分のために実行可能なアジャイル要件を洗練する
• どのアーキテクチャ、ツール、およびコンポーネントを選択するかを決定します-彼にノートを渡すだけです
• フロントエンド、バックエンド、ingrationのコードを書く
• データのプロファイリングとスケープ、高度な機能にはCloud AI / ML APIを使用
• 必要なIaCコードとロールアウトを作成する
• エラーまたは販売プロセスが発生した場合に電話をかける
• セキュリティ関連の設計、全体的なパッチ適用、移行、最新化に注意する
• 雇用主の請求書発行を容易にするための精査された方法での口座タイムテーブル
• ...何か忘れましたか？

UPD - 「私たちは専門の生産性を必要とするが、我々はの島世界観たくない『労働者の極端な分裂を』（DevOpsチームみんな、。DevOpsチーム、アダム・スミスとジェネラリストの伝説『』、2013年から2016年）

作業には2つのタイプがあります。

1. 悪用 -明確に定義された作業は、明確に定義された段階に簡単に分割できます。各段階を独自に学習および習得でき、段階間のハンドオーバーには通信は必要ありません。

2. 探索 -各ステージを達成するために学習と実験を必要とし、ステージ間の引き継ぎを必要とする未定義の作業には、プロジェクトのすべての学習とステータスに関する大量のコミュニケーションが必要です。

アダム・スミスは、探究にまったく関わらず、搾取に全面的に関心を持っています。業界の研究開発部門で行われている作業は、その定義上、ほとんどが探査であるため、アダムスミスは一切カバーしていません。

しかし、部分的に搾取的な作業である後の継続的な改善段階では、CI / CDの適用により生産性が同様に向上する可能性があります。

Adam Smithは、ある段階から別の段階への情報の受け渡しを考慮する必要がありませんでした。これは重要なITプロジェクトの重要な部分です。したがって、フルスタック開発者には次の重要な利点があります。

• 彼らは物事を成し遂げるために別の部門の誰かと話す必要はありません
• 彼らは他の人々がそれに近づくのを待つ必要はありません
• ある層と別の層との間の翻訳で何かが失われる可能性ははるかに少ない

ITプロジェクトで渡される情報の重要性については、Fred BrookのMythical Man Monthを参照してください。

私見では、答えは規模とリソースの可用性に大きく関係しています。

アダム・スミスの理論は、大規模な場合にしか適用できないと考えています-元のコンテキストで国/経済全体、またはSW開発のコンテキストで-大規模な開発チーム。

実際、大規模なチームでは、より専門的な人材を採用する方が効率的です。

• 彼らはロックスターではありません-多くの場合、このような大規模な組織では危険の兆候と見なされます
• それらは通常、見つけやすく、専門知識の範囲が広い人よりも安価です
• 彼らは通常、離職のリスクを引き起こしません-例えば、彼らは自分のスキルのサブセットしか使用しないので不幸になりません。
• （おそらく奇妙な）デボプシーの比較では、「牛とペット」の原則をそのような大規模な組織に適用することができますが、その理由はまったく同じです。これらの専門的なリソースは、ビジネスの観点から、文字通り人的資源プールの1人であり、そのサイズは必要に応じて、通常は雇用/解雇によって迅速に調整できます。

ああ、そのようなチームは、製品を専門のリソースで対処できるより小さな専門のタスクに分割するために必要な高品質のアーキテクトリソースによって補完される場合にのみ機能します。

小規模のチームまたは一人のチーム（通常はスタートアップ、または大規模な組織の孤立した小規模なチーム）でさえ、そのようなリソースを使用して仕事を遂行することは非効率的または不可能ですらあります。

• 製品開発全体をカバーするために必要な多くの異なる専門的なリソースを雇うための予算/リソースがない
• 彼らは実際に複数の帽子をかぶることができ、遅延や追加の人件費を招くことなく、すぐに柔軟性の高い役割を切り替えることができるロックスターを探して/評価します

私は、以下の責任の組み合わせに基づいて、自分自身をフルスタック開発者と考えています。

フロントエンドとバックエンドのプログラミング

私はある程度までUIの変更を行うことができます：html、css（web開発者として）を書き、一方で、データベースからUIにデータを提供したり、サービスで提供したりします。

テスト、アーキテクチャ、およびそれらは別として、会議のお客様は作業説明に追加される場合があります。

反対

私の見方の反対は、UI担当者とバックエンド担当者の厳密な役割です。

結論

あなたが言ったようにフルスタックは本当にありません。アジャイルやクラウドのような派手な表現のように、特定の条件で人々の注意を引くために言及する必要があり、実際の実装は大きく異なります。少なくともスクラムとアジャイルについては、非常に多くのバリエーションがあるので、用語の意味がなくなっています。

要するに、私はアダム・スミスが間違っていたとは思わないが、私は彼の製造業の分業モデルとソフトウェア開発のサイロの間に重大な違いがあると思う。

まず、ピンファクトリの例（私の知る限り）は単なる仮説にすぎません。ほとんどの現代の製造工場は、この分業にそのルーツをたどることができますが、この仮説を科学的に実際にテストした研究は知りません。

第二に、スミスは主に材料製品の製造に関心がありました。素材の生産に関連する特定の具体的なアウトプットがありますが、ソフトウェア開発には類似の類似物はありません。たとえば、ピンの作成では、物理的な寸法が機能要件として重要です。ソフトウェアのそれと明確な比較はありません。これは重要です。なぜなら、有形のオブジェクトは正確な繰り返しによって複製できるからです。ソフトウェア開発が二度と同じ問題になることはありません。開発者は予測可能な結果を​​生成する一般的な方法を開発しますが、同じ問題を2回コーディングすることはありません。スタックで開発されたコンポーネントには、物理​​的なコンポーネントとは異なる複雑さがあり、それらの複雑さには、具体的な測定（高さ、重量、長さなど）を超える相互作用があります。ピンポインターはワイヤーカッターの動作を気にしませんが、ワイヤが仕様に従って切断される限り。ソフトウェア開発では、境界線は決してそれほど明確ではありません。

フルスタック開発者は、すべての作業を自分で行うことは期待されていません（単一のピンメーカーになることを意図していません）が、スタックのすべての要素とそれらの要素がどのように相互作用するかを理解できることが期待されます。フルスタックチームは、1つ以上の分野に特化したT字型の個人で構成されている必要がありますが、スペクトルを理解しています（ある程度のレベルで介入できる場合があります）。

スミスの仕事がソフトウェア開発で当てはまると思うのは、コンテキストスイッチング（またはマルチタスク）の分野です。単一の開発者が開発のすべての領域を担当している場合、責任から責任に移行するには時間がかかります。大規模な場合、同じ製品チームで異なる経験を持つチームメンバー間のコラボレーションにより、コンテキストスイッチングと複雑な相互作用のバランスを取ることができます。

理解すべき重要な点は、分業は必ずしもステップごとに異なる人を意味するわけではないということです。

私は自動車工場で自分の歴史を持ち、エアバッグ、革、ヘッドレストなどを備えたフルシートを得るために、シートアセンブリチェーンにいました。チェーンは9段階に分割されました。私たちはチェーンで作業していました。各人は一度に1つのステージしか実行していませんでしたが、あまりにも多くの繰り返しを避けるために、毎時間次のステージにシフトしていました。勤務時間は8時間でしたので、毎日各ステージに参加しませんでした。

これは、特定の時間にアセンブリの1つのステップのみを行う労働区分であり、完全なアセンブリの実行を妨げることはありません。

他の回答ですでに述べたように、これはソフトウェア開発とは少し異なりますが、フルスタック開発者が分業と相互に排他的ではない理由を明らかにすると思います。アプリケーションのライフサイクル全体を処理する能力を持つ人はそうではありません常にそれを行う必要がありました。

一般的に言えば、FullStack開発者の話を聞くと、Front DevとBack Devとは反対に、効率的なバックエンドと素晴らしいUIを同時にコーディングできる人が増えていると思います。