Adam Smith so với các nhà phát triển fullstack - và năng suất trong DevOps?

Bởi Adam Smith, bộ phận lao động có thể giúp bạn hiệu quả gấp 240 lần (ví dụ như một nhà máy sản xuất ghim sản xuất ghim trong 18 bước).

Tại sao sau đó các vai trò đa kỹ năng lại được yêu cầu như vậy nếu điều này thực sự làm giảm năng suất - hoặc Smith chỉ sai, tại sao sau đó?

Tìm kiếm cho "nhà phát triển fullstack" vẫn là xu hướng trên Google, tuy nhiên dường như chậm hơn hai năm trước:

=====

Tóm lại, một nhà phát triển ngăn xếp đầy đủ sẽ có thể thực hiện hầu như tất cả các chuỗi giá trị (sửa tôi nếu tôi sai):

• Thảo luận với khách hàng và tinh chỉnh các yêu cầu nhanh nhẹn khả thi cho phần công việc của mình
• Quyết định kiến ​​trúc, dụng cụ và linh kiện nào - chỉ cần đưa cho anh ấy một cuốn sổ tay
• Viết mã cho frontend, backend, ingration, là thiết bị chéo có thể biên dịch được và không yêu cầu nhiều thử nghiệm, hoặc bao gồm nó
• Hồ sơ và dữ liệu scape, sử dụng API Cloud AI / ML cho các tính năng nâng cao
• Viết mã IaC cần thiết và triển khai
• Hãy gọi trong trường hợp có lỗi hoặc quá trình bán hàng
• Hãy nhận biết về thiết kế liên quan đến bảo mật, vá tổng thể, di chuyển và hiện đại hóa
• Bảng thời gian tài khoản theo cách được kiểm tra kỹ lưỡng để dễ dàng lập hóa đơn của nhà tuyển dụng
• ... tôi có quên gì không?

CẬP NHẬT - " chúng tôi cần năng suất của chuyên môn hóa nhưng chúng tôi không muốn thế giới quan sâu sắc của bộ phận lao động cực đoan . (DevOps Guys, " DevOps, Adam Smith và huyền thoại của Tướng quân " , 2013-2016)

Có hai loại công việc:

1. Khai thác - Công việc được xác định rõ có thể dễ dàng phân chia thành các giai đoạn được xác định rõ ràng, trong đó mỗi giai đoạn có thể được học và thành thạo và việc chuyển giao giữa các giai đoạn không cần giao tiếp.

2. Thăm dò - Công việc không xác định, đòi hỏi phải học hỏi và thử nghiệm để hoàn thành từng giai đoạn và chuyển giao giữa các giai đoạn đòi hỏi một lượng lớn giao tiếp của tất cả việc học và tình trạng của dự án.

Adam Smith quan tâm đến bản thân hoàn toàn với việc khai thác và hoàn toàn không phải với sự khám phá. Công việc được thực hiện trong các bộ phận Nghiên cứu & Phát triển của ngành là theo định nghĩa của nó chủ yếu là thăm dò và do đó, nó không được Adam Smith đề cập dưới bất kỳ hình thức nào.

Nhưng chúng ta đã thấy rằng trong các giai đoạn cải tiến liên tục sau này, là một công việc khai thác một phần, việc áp dụng CI / CD có thể mang lại hiệu quả tương tự về năng suất, theo một cách nào đó có thể được Adam Smith tưởng tượng ra.

Adam Smith không cần xem xét việc chuyển thông tin từ giai đoạn này sang giai đoạn khác. Đây là một phần quan trọng của bất kỳ dự án CNTT quan trọng nào. Vì vậy, một nhà phát triển fullstack có những lợi thế đáng kể rằng:

• họ không phải nói chuyện với bất cứ ai ở bộ phận khác để hoàn thành công việc
• họ không phải đợi những người khác đến đó
• có rất ít khả năng một cái gì đó sẽ bị mất trong bản dịch giữa lớp này và lớp khác

Để biết thêm về tầm quan trọng của thông tin trong các dự án CNTT, hãy xem Tháng huyền thoại của Fred Brook .

IMHO câu trả lời có liên quan nhiều đến quy mô và nguồn lực sẵn có.

Tôi tin rằng lý thuyết của Adam Smith chỉ có thể được áp dụng ở quy mô lớn - toàn bộ các quốc gia / nền kinh tế trong bối cảnh ban đầu, hoặc, trong bối cảnh phát triển SW - các nhóm phát triển lớn.

Trong một đội ngũ lớn, thực sự, hiệu quả hơn là thuê nhiều nhân lực chuyên ngành hơn:

• họ không phải là những ngôi sao nhạc rock - thường được coi là một dấu hiệu nguy hiểm trong các tổ chức lớn như vậy
• Chúng thường dễ tìm hơn, rẻ hơn so với những người có phổ chuyên môn rộng hơn
• họ thường không làm tăng rủi ro tiêu hao - ví dụ họ sẽ không vui vì họ chỉ sử dụng một tập hợp con các kỹ năng của họ.
• trong một so sánh sai lệch (có thể kỳ lạ), nguyên tắc "gia súc và vật nuôi" có thể được áp dụng trong các tổ chức lớn hơn như vậy, và vì những lý do khá giống nhau. Các tài nguyên chuyên ngành này, từ quan điểm kinh doanh, theo nghĩa đen chỉ là đầu người trong nhóm nguồn nhân lực, có kích thước có thể được điều chỉnh nhanh chóng khi cần, thường là bằng cách thuê / sa thải.

Ồ, và các nhóm như vậy chỉ có thể hoạt động nếu chúng được bổ sung bởi các tài nguyên kiến ​​trúc chất lượng cao, cần thiết để phân chia sản phẩm trong các nhiệm vụ nhỏ hơn, chuyên biệt có thể được giải quyết bằng các tài nguyên chuyên ngành.

Ở quy mô nhỏ hơn hoặc thậm chí các nhóm một người (thường là các công ty mới thành lập hoặc thậm chí cô lập các nhóm nhỏ hơn trong các tổ chức lớn hơn), việc sử dụng các tài nguyên đó không hiệu quả hoặc thậm chí không thể thực hiện được:

• họ chỉ đơn giản là không có ngân sách / tài nguyên để thuê nhiều tài nguyên chuyên ngành khác nhau cần thiết để chi trả cho toàn bộ quá trình phát triển sản phẩm
• họ thực sự tìm kiếm / đánh giá cao những ngôi sao nhạc rock có thể đội nhiều mũ và ngay lập tức chuyển đổi vai trò rất linh hoạt, mà không phải chịu sự chậm trễ và chi phí nhân sự bổ sung

Tôi coi mình là một nhà phát triển fullstack trên cơ sở kết hợp các trách nhiệm sau:

Lập trình mặt trước và mặt sau

Tôi có thể thay đổi UI cho đến một mức độ nào đó: viết html, css (với tư cách là nhà phát triển web) và mặt khác, trong một số phần mở rộng cung cấp dữ liệu cho UI từ cơ sở dữ liệu, cung cấp nó trong một dịch vụ, v.v.

Tôi để thử nghiệm, kiến ​​trúc và những người sang một bên, gặp gỡ khách hàng có thể được thêm vào mô tả làm việc.

Đối diện

Quan điểm ngược lại với quan điểm của tôi sẽ là vai trò nghiêm ngặt của những người làm UI và những người ở phía sau.

Kết luận

Tôi không thấy toàn bộ thực sự đầy đủ như bạn đã đề cập, giống như một biểu thức ưa thích như nhanh nhẹn hoặc đám mây mà trong một số điều kiện nhất định phải được đề cập để thu hút sự chú ý của mọi người và việc triển khai thực sự có thể thay đổi lớn. Ít nhất là về scrum và nhanh nhẹn tôi đã thấy rất nhiều biến thể mà các thuật ngữ đã hết nghĩa.

Nói tóm lại, tôi không nghĩ Adam Smith đã sai, nhưng tôi nghĩ có một số khác biệt nghiêm trọng giữa mô hình phân công lao động của anh ấy trong sản xuất và silo trong phát triển phần mềm.

Đầu tiên, ví dụ về nhà máy sản xuất pin (theo như tôi biết) chỉ là giả thuyết; Mặc dù hầu hết các nhà máy sản xuất hiện đại có thể truy nguyên nguồn gốc của sự phân công lao động này, tôi không biết về bất kỳ nghiên cứu nào thực sự đã thử nghiệm một cách khoa học giả thuyết này.

Thứ hai, Smith chủ yếu quan tâm đến sản xuất hàng hóa vật chất; có một số kết quả đầu ra hữu hình liên quan đến sản xuất vật liệu không có các chất tương tự tương tự trong phát triển phần mềm. Ví dụ, trong chế tạo pin, kích thước vật lý là quan trọng như một yêu cầu chức năng; không có so sánh rõ ràng với phần mềm. Điều này rất quan trọng vì các đối tượng hữu hình có thể được nhân rộng thông qua sự lặp lại chính xác; phát triển phần mềm không bao giờ là vấn đề tương tự hai lần. Các nhà phát triển phát triển các phương pháp phổ biến để tạo ra kết quả có thể dự đoán được, nhưng bạn không bao giờ viết mã cho cùng một vấn đề hai lần. Bất kỳ thành phần nào được phát triển trong ngăn xếp đều có những điểm phức tạp không giống như các thành phần vật lý và những điểm phức tạp đó có các tương tác vượt quá phép đo hữu hình (chiều cao, cân nặng, chiều dài, v.v.). Một con trỏ pin không quan tâm đến cách thức hoạt động của máy cắt dây, miễn là dây được cắt theo thông số kỹ thuật. Trong phát triển phần mềm,các ranh giới không bao giờ hoàn toàn rõ ràng .

Các nhà phát triển ngăn xếp đầy đủ dự kiến ​​sẽ không tự mình thực hiện tất cả các công việc (họ không dự định là một nhà sản xuất pin duy nhất), nhưng họ được cho là có khả năng hiểu tất cả các yếu tố của ngăn xếp và cách các yếu tố đó tương tác. Một nhóm ngăn xếp đầy đủ phải bao gồm các cá nhân hình chữ T chuyên về một hoặc nhiều lĩnh vực, nhưng hiểu được phổ (và có thể có thể bước vào ở một mức độ nào đó).

Nơi tôi nghĩ công việc của Smith rất đúng trong phát triển phần mềm là trong lĩnh vực chuyển đổi ngữ cảnh (hoặc đa nhiệm ); nếu một nhà phát triển duy nhất chịu trách nhiệm cho tất cả các lĩnh vực phát triển, thì cần có thời gian để chuyển từ trách nhiệm sang trách nhiệm. Ở quy mô, sự hợp tác giữa các thành viên trong nhóm với các trải nghiệm khác nhau trong cùng một nhóm sản phẩm có thể cân bằng chuyển đổi ngữ cảnh và các tương tác phức tạp.

Một điểm quan trọng cần hiểu là phân công lao động không phải lúc nào cũng có nghĩa là một người khác nhau trên mỗi bước.

Tôi đã có lịch sử của riêng mình trong một nhà máy ô tô, tôi đã ở trong một chuỗi lắp ráp ghế ngồi, để có được một chỗ ngồi đầy đủ với túi khí, da, tựa đầu, vv chuỗi đã được chia thành 9 giai đoạn. Chúng tôi đã làm việc 9 trên chuỗi. Mỗi người chỉ làm một giai đoạn một lần, nhưng mỗi giờ chúng tôi lại chuyển sang giai đoạn tiếp theo để tránh quá nhiều sự lặp lại. Ngày làm việc dài 8h nên chúng tôi không lên sân khấu mỗi ngày.

Đây chính xác là một bộ phận lao động, nơi bạn chỉ thực hiện một bước lắp ráp tại một thời điểm nhất định, điều đó không ngăn cản bạn có thể thực hiện lắp ráp đầy đủ.

Như đã nói trong các câu trả lời khác, điều này hơi khác so với phát triển phần mềm nhưng tôi nghĩ điều này làm sáng tỏ lý do tại sao một nhà phát triển Full Stack không loại trừ lẫn nhau với phân công lao động, một người có khả năng xử lý toàn bộ vòng đời của một ứng dụng thì không bắt buộc phải làm điều đó mọi lúc

Nói chung, khi tôi nghe nhà phát triển FullStack, tôi nghĩ rằng nhiều người có thể viết mã back-end hiệu quả và giao diện người dùng tốt cùng một lúc, trái ngược với Front và Back Dev.