Adam Smith vs. 풀 스택 개발자-DevOps의 생산성?

아담 스미스 (Adam Smith)는 노동 부문을 통해 240 배 더 효율적으로 작업 할 수 있습니다 (예 : 핀 공장에서 핀을 18 단계로 생산하는 경우).

그렇다면 실제로 생산성을 떨어 뜨리거나 스미스가 잘못한 경우, 여러 기술을 갖춘 역할이 요구되는 이유는 무엇입니까?

"풀 스택 개발자"에 대한 검색은 여전히 ​​Google에서 추세이지만 2 년 전보다 훨씬 느립니다.

=====

요약하면 풀 스택 개발자 는 사실상 모든 가치 사슬을 수행 할 수 있습니다 (잘못되면 정정하십시오).

• 고객과 논의하고 직무에 필요한 실행 가능한 민첩한 요구 사항을 수정하십시오.
• 어떤 아키텍처, 툴링 및 컴포넌트를 선택할지 결정하십시오.
• 프론트 엔드, 백엔드, ingration을위한 코드 작성
• 고급 기능을 위해 Cloud AI / ML API를 사용하여 프로파일 링 및 데이터
• 필요한 IaC 코드 및 롤아웃 작성
• 오류 또는 영업 프로세스가 발생할 경우 전화
• 보안 관련 디자인, 전반적인 패치 적용, 마이그레이션 및 현대화에주의
• 고용주의 인보이스 발행을 용이하게하기 위해 계획된 방식으로 계정 시간표
• ... 내가 아무것도 잊었습니까?

UPD- " 우리는 전문성의 생산성이 필요하지만"극단적 인 노동 분업 " 에 대한 세계관을 원치 않습니다 . (DevOps Guys, "DevOps, Adam Smith 및 Generalist의 전설 " , 2013-2016)

두 가지 유형의 작업이 있습니다.

1. 착취 -잘 정의 된 단계로 쉽게 나눌 수있는 잘 정의 된 작업. 각 단계를 자체적으로 익히고 숙달 할 수 있으며 단계 간 핸드 오버는 의사 소통이 필요하지 않습니다.

2. 탐색 -정의되지 않은 작업, 각 단계를 달성하기 위해 학습 및 실험이 필요하며 단계 간 핸드 오버는 프로젝트의 모든 학습 및 상태에 대한 많은 양의 커뮤니케이션이 필요합니다.

아담 스미스는 탐사에 전혀 관심이없고 탐사에 전혀 관심이 없다. 업계의 연구 개발 부서 에서 수행 한 작업 은 그 정의에 따라 주로 탐색되므로 Adam Smith는 어떤 식으로도 다루지 않습니다.

그러나 우리는 부분적으로 착취적인 작업 인 후기의 지속적인 개선 단계에서 CI / CD의 적용이 비슷한 생산성 향상을 가져올 수 있다는 것을 보았습니다. 이는 아마도 어떤 방식 으로든 매우 상상력이있는 누군가에 의해 Adam Smith에게 추적 될 수 있습니다.

Adam Smith는 정보를 한 단계에서 다른 단계로 전달하는 것을 고려할 필요가 없었습니다. 이것은 중요한 IT 프로젝트의 중요한 부분입니다. 따라서 풀 스택 개발자는 다음과 같은 중요한 이점이 있습니다.

• 그들은 일을 끝내기 위해 다른 부서의 누군가와 대화 할 필요가 없습니다
• 그들은 다른 사람들이 그 주변을 돌아 다닐 때까지 기다릴 필요가 없습니다
• 한 레이어와 다른 레이어 사이의 번역에서 무언가가 손실 될 가능성은 훨씬 적습니다.

IT 프로젝트에서 전달되는 정보의 중요성에 대한 자세한 내용은 Fred Brook의 Mythical Man Month를 참조하십시오 .

IMHO의 대답은 규모 및 리소스 가용성과 관련이 있습니다.

아담 스미스의 이론은 원래의 맥락에서, 또는 SW 개발 상황에서 대규모 개발팀으로 대규모 국가에만 적용 할 수 있다고 생각합니다.

대규모 팀에서는 실제로보다 전문화 된 인력을 고용하는 것이 더 효율적입니다.

• 그들은 록 스타가 아닙니다-종종 그러한 큰 조직에서 위험 신호로 간주됩니다
• 전문 지식 범위가 넓은 사람들보다 일반적으로 찾기 쉽고 저렴합니다.
• 그들은 일반적으로 감손 위험을 높이 지 않습니다. 예를 들어 그들은 기술의 일부만 사용하기 때문에 불행하지 않습니다.
• (아마도 이상한) 변덕 비교에서 "가축 대 애완 동물" 원칙은 그러한 더 큰 조직에 적용될 수 있으며, 매우 유사한 이유가 있습니다. 이러한 전문화 된 자원은 비즈니스 관점에서 말 그대로 인적 자원 풀의 1 인당 자본이며, 필요에 따라 일반적으로 고용 / 소성에 의해 신속하게 조정할 수있는 규모입니다.

아, 그리고 이러한 팀은 전문화 된 자원으로 해결할 수있는 더 작고 전문화 된 작업으로 제품을 분할하는 데 필요한 고품질 설계자 자원으로 보완 된 경우에만 기능적 일 수 있습니다.

소규모 또는 1 인 팀 (일반적으로 스타트 업 또는 대규모 조직의 격리 된 소규모 팀)에서는 이러한 리소스를 사용하는 것이 비효율적이거나 불가능합니다.

• 그들은 전체 제품 개발을 포괄하는 데 필요한 다양한 전문 자원을 고용 할 예산 / 자원이 없습니다.
• 그들은 실제로 여러 개의 모자를 쓰고 지연과 추가 HR 비용을 발생시키지 않으면 서 큰 유연성으로 역할을 즉시 전환 할 수있는 록 스타를 찾고 감사합니다.

본인은 다음과 같은 책임 조합을 바탕으로 풀 스택 개발자로 생각합니다.

프론트 엔드 및 백엔드 프로그래밍

html, css (웹 개발자)를 작성하고 다른 한편으로는 데이터베이스에서 UI에 데이터를 제공하고 서비스 등을 제공하는 등 UI 범위를 어느 정도까지 변경할 수 있습니다.

테스트, 아키텍처 및 그 외에는 회의 고객이 작업 설명에 추가 될 수 있습니다.

반대말

내 관점의 반대는 UI 사람들과 백 엔드 사람들의 엄격한 역할입니다.

결론

나는 당신이 언급 한대로 전체 스택을 실제로 보지 못합니다. 애자일 또는 클라우드와 같은 멋진 표현과 같이 특정 조건에서 사람들의 관심을 끌기 위해 언급해야하며 실제 구현은 크게 다를 수 있습니다. 적어도 스크럼과 민첩성에 대해서는 용어가 의미를 잃을 정도로 많은 변형을 보았습니다.

요컨대, Adam Smith가 틀렸다고 생각하지는 않지만 제조 분야의 노동 부서 모델과 소프트웨어 개발의 사일로 사이에는 심각한 차이점이 있다고 생각합니다.

첫째, 핀 팩토리 예제 (내가 아는 한)는 단순한 가상 일뿐입니다. 대부분의 현대 제조 공장은이 노동 분업의 근원을 추적 할 수 있지만, 실제로이 가설을 과학적으로 테스트 한 모든 연구는 알지 못합니다.

둘째, Smith는 주로 재료 제품 제조에 관심이있었습니다. 소프트웨어 개발에 비슷한 아날로그가없는 재료 생산과 관련된 특정 유형의 산출물이 있습니다. 예를 들어, 핀 제작에서 물리적 치수는 기능적 요구 사항으로 중요합니다. 소프트웨어와는 분명히 비교할 수 없습니다. 유형의 객체는 정확한 반복을 통해 복제 될 수 있기 때문에 중요합니다. 소프트웨어 개발은 ​​결코 두 번 같은 문제가 아닙니다. 개발자는 예측 가능한 결과를 생성하는 일반적인 방법을 개발하지만 동일한 문제를 두 번 코딩하지는 않습니다. 스택에서 개발 된 모든 구성 요소는 물리적 구성 요소와 달리 복잡성이 있으며 이러한 복잡도는 유형 측정 (높이, 무게, 길이 등) 이상의 상호 작용을합니다. 핀 포인터는 와이어 커터의 작동 방식에 신경 쓰지 않습니다. 사양에 따라 와이어가 절단되는 한. 소프트웨어 개발에서그 경계는 결코 분명하지 않습니다 .

풀 스택 개발자는 모든 작업을 스스로 수행 할 필요는 없지만 (단일 핀 메이커가 아니어야 함) 스택의 모든 요소와 해당 요소의 상호 작용 방식을 이해할 수 있어야합니다. 풀 스택 팀은 하나 이상의 영역을 전문으로하지만 스펙트럼을 이해하는 (그리고 어느 정도 단계에 들어갈 수있는) T 자형 개인 으로 구성되어야합니다 .

소프트웨어 개발에서 Smith의 작업이 사실이라고 생각하는 곳은 컨텍스트 전환 (또는 멀티 태스킹 ) 영역입니다 . 단일 개발자가 모든 개발 영역을 담당하는 경우 책임에서 책임으로 전환하는 데 시간이 걸립니다. 규모에 따라 동일한 제품 팀에서 서로 다른 경험을 가진 팀 구성원 간의 협업은 컨텍스트 전환과 복잡한 상호 작용의 균형을 맞출 수 있습니다.

이해해야 할 중요한 점은 분업이 항상 단계마다 다른 사람을 의미하지는 않는다는 것입니다.

나는 자동차 공장에서 내 자신의 역사를 가지고 있었고, 나는 에어백, 가죽, 머리 받침 등으로 전체 좌석을 얻기 위해 좌석 조립 체인에 있었고 체인은 9 단계로 나뉘 었습니다. 우리는 9 명의 체인 작업을하고있었습니다. 각 사람은 한 번에 한 단계 만 수행했지만 매 시간마다 너무 많은 반복을 피하기 위해 다음 단계로 이동했습니다. 근무일은 8 시간으로 매일 각 단계에 오지 않았습니다.

이것은 정확히 한 번에 어셈블리의 한 단계 만 수행하는 노동 부서이므로 전체 어셈블리를 수행 할 수는 없습니다.

다른 답변에서 이미 언급했듯이 이것은 소프트웨어 개발과 약간 다르지만 풀 스택 개발자가 노동 부문과 상호 배타적이지 않은 이유를 밝히고 있다고 생각합니다. 응용 프로그램의 전체 수명주기를 처리 할 수있는 능력을 가진 사람은 그렇지 않습니다 항상해야합니다.

FullStack 개발자의 말을 들으면 일반적으로 Front and Back Dev와는 반대로 효율적인 백엔드와 멋진 UI를 동시에 코딩 할 수 있다고 생각합니다.