30년 전 기술 산업은 Lean 관행을 도입하려고 시도했지만 실패했습니다. "지속적인 개선" 대신 진행이 중단되었습니다. Agile은 UX 연구, 디자인 및 확장 가능한 개발과 호환되지 않습니다. 항상 그럴 것입니다. 새로운 운영 표준을 만들어야 할 때입니다.
신생 기업이 "운영 효율성"에 다시 초점을 맞추면서 효율성은 인력이 아니라 일하는 방식이라는 점을 강조합시다. 애자일 개발은 20년 이상 확인되지 않고 의문의 여지가 없는 최고의 기술 운영 원칙이었습니다. 그러나 그것은 우리를 계속 노려온 근본적인 결함을 가지고 있습니다.
결함 #1: 인간은 기계가 아닙니다.
결함 #2: 디자인은 인벤토리가 아닙니다.
결점 #3: 제품은 2주 스프린트에서 임의의 기술과 경험을 가진 임의의 수의 사람들이 달성할 수 있는 것으로 정의할 수 없습니다.
처음부터
이러한 훌륭한 시작은 제거에 중점을 두었습니다. 쓰레기, 불일치 및 너무 무거운 짐. 낭비 제거는 가장 철저하게 문서화되었습니다. 8가지 유형의 폐기물 중에서 가장 유해한 것은 완제품과 원자재, 유휴 기계 등 초과 재고였습니다. 즉, 당신이 돈을 버는 데 돈을 쓰지 않는 것입니다. Toyota의 솔루션은 본질적으로 물류적이었고 "적시 제조"로 알려지게 되었습니다.
"조립 라인에서 적시에 재료를 받아 완제품이 고객 요구를 충족할 수 있도록 적시에 처리합니다."
TPS(1960년대, 도요타 생산 시스템)의 탁월한 파트너는 "The Toyota Way"였습니다. 이 철학은 장기적인 비전을 향한 도전 극복, kaizen (운영 혁신), 그리고 개인적으로 좋아하는 genchi genbutsu를 포함하여 지속적인 개선을 요구했습니다. "실제 장소, 실제"를 의미하는 이 원칙은 "가서 직접 확인"하고 그에 따라 결정을 내리는 것을 의미했습니다. 또한 개선에 대한 상향식 접근 방식을 장려하여 직급에 관계없이 모든 직원으로부터 통찰력을 수집했습니다.
미국은 마법을 부려 도요타 방식을 컵 누들과 같은 것으로 바꾸었습니다. JIT(Just-In-Time) 제조는 잘 적용되었습니다. 1988년 기사 "린 생산 시스템의 승리(Triumph of the Lean Production System)"에서 린(Lean )으로 이름이 변경되었습니다.
Lean과 그 조상은 특히 확립된 시장과 성숙된 제품이 있을 때 물리적 제품의 제조에 완벽합니다. 수요와 공급망 모두의 예측 가능성에 의존합니다. 신제품을 만들 때 제조업체는 R&D 부서의 다양한 프로세스에 의존했습니다. Genentech가 합성 인슐린을 개발했든 Proctor & Gamble이 Swiffer를 개발했든 프로세스는 길고 상당히 직선적이었습니다. 여기에는 제품 개발에 앞서 심도 있는 연구 및 시장분석이 포함되었습니다.
폭포수 방법론(Waterfall)
급성장하는 소프트웨어 산업은 주로 이러한 프로세스를 따랐습니다. 디지털 제품에 적용되어 폭포수 방법론(Waterfall)으로 알려지게 되었습니다. Waterfall이라는 용어는 완전히 실현된 제품 릴리스로 끝나는 선형 개발 프로세스를 설명하는 포괄적인 용어가 되었습니다. 정당한 비판은 크고 비싼 제품 출시가 여전히 바보가 될 수 있다는 것입니다. 이와 같이 Waterfall은 반복, 테스트 및 시장에 대한 반응이 더 짧은 일정에 필요하다고 주장하는 포일로 사용됩니다.
1990년대에 기술 산업 종사자들은 Lean을 디지털 제품에 적용하는 방법을 모색했습니다. 불행히도 처음부터 문제를 잘못 진단했습니다. 시장 출시 시간은 중요하지만 특히 신생 기업의 경우 현금 흐름 관점에서 더 중요하다고 주장합니다. 스크럼과 애자일 문헌에서 연구나 전략에 대한 언급이 거의 또는 전혀 없다는 점에 유의하십시오. 디자인은 Waterfall의 긴 시간 낭비 단계로 나쁜 평가를 받았습니다. Lean 프레임워크는 모두 빌드 및 릴리스에 관한 것입니다.
이 무렵, Lean 지지자와 Waterfall 개발을 실천해 온 사람들 사이에 Kaiju 대 Mecha 스타일의 싸움이 있었습니다. 괴물과 로봇 모두 사용자의 요구를 고려하지 않고 대신 사용자를 짓밟고 세상을 파괴했습니다.
다이어그램만 — 조각을 나타내는 Agile, 전체를 나타내는 Waterfall.
시장에서 살아있는 제품을 반복하는 관행은 소프트웨어의 사치입니다. 업데이트는 언제든지 푸시할 수 있습니다. 조립 라인과 툴링을 개조할 필요가 없습니다. 모든 기술 제품은 단계적으로 구축되어야 하지만 최종 목표와 완전히 실현된 제품을 향해 구축되어야 합니다. 성공하려면 The Toyota Way가 의도한 대로 전략, 연구, 디자인, 현물이 필요합니다. Agile vs Waterfall 논쟁은 잘못된 이분법입니다. 회사는 장기적인 전략을 가지고 제품을 점진적으로 반복적으로 출시하면서 이를 수행할 수 있습니다.
30년 된 오류
제품 소유자와 엔지니어는 소프트웨어 개발에 Lean 제조 원칙을 적용하려고 시도하면서 조립 라인을 모방하는 방법을 찾았습니다. 요구 사항은 제 시간에 결정되고 교차 기능 팀은 작동하는 소프트웨어를 릴리스하기 위해 전력 질주합니다. 스크럼이라는 용어는 적절한 선택이었습니다. 그것은 럭비에서 유래했으며, 경기장을 가로질러 돌진하는 일렬의 친구들이 공을 앞뒤로 던지는 형태입니다. 소프트웨어 개발에 대한 접근 방식은 동일한 수준의 기교와 전략을 가지고 있습니다.
모두 스크럼을 다루어야 했습니다. 스크럼이 이렇게 된 이유는 다음과 같습니다.
- 소프트웨어가 "반복" 주기로 시장에 출시될 수 있도록 하기 위해 Sprint에 타임박스를 지정해야 합니다.
- 스프린트 계획은 스프린트 직전에 이루어집니다. 스프린트 직전에 무엇에 집중해야 하는지에 대한 최신 통찰력을 적시에 얻을 수 있기 때문입니다.
- 즉석에서 "운영 개선"을 할 수 있는 Daily Standup이 있습니다. (개발자만 발언이 가능하며 토론은 허용되지 않습니다. 기계가 유휴 상태가 되기 때문입니다.)
- 스프린트가 끝나면 작동하는 소프트웨어를 보고 완료되지 않은 항목이나 개선이 필요한 항목을 결정하는 검토가 있습니다.
- 또한 생산량을 늘리기 위해 잘 된 것과 잘 되지 않은 것을 논의하는 회고전이 있어야 합니다.
- 백로그는 스크럼 실행의 핵심이 아니며 스프린트 중에 버려지는 모든 것의 부수적 손상과 이물질의 인공물입니다.
Scrum이 이미 상당히 비논리적이라는 것을 알 수 있습니다. 하지만 훨씬 더 나빠집니다. 스크럼 창시자 몇 명이 다른 Lean 개발 사례를 함께 모은 더 많은 친구들과 모였습니다. 힘을 합쳐 애자일 소프트웨어 개발을 위한 선언문을 만들었습니다. 마르크스주의의 저조는 아마도 의도적일 것입니다. 그들은 노동자들이 생산 수단을 소유할 것이라고 말하고 있었습니다.
[Fr] Agile 선언문
선언문은 지금까지 만들어진 문서 중 하나입니다. 여기에는 4가지 "가치"와 12가지 "원칙"이 나열되어 있습니다. 처음에는 개발자를 기계의 톱니바퀴가 아닌 인간으로 대하려는 의도가 좋았을지 모르지만 이제 우리는 완전한 원을 그리게 되었습니다. 이러한 원칙은 조직에 가성적인 것으로 발전했습니다. 지금 보면 스크럼 포드가 책임을 면할 수 있는 방법에 대한 주제의 변형입니다.
하이라이트:
- 프로세스 및 도구를 통한 개인 및 상호 작용. (예, 우리는 우리가 원하는 대로 할 것입니다).
- 늦은 개발에서도 변화하는 요구 사항을 환영합니다. (우리는 또한 언제든지 마음을 바꿀 수 있습니다).
- 프로젝트는 신뢰할 수 있는 동기 부여된 개인을 중심으로 구축됩니다. (우리를 내버려 두고 당신이 얻는 것을 가져가십시오).).
- 작동하는 소프트웨어는 진행 상황의 주요 척도입니다. (우리가 무엇인가를 생산했다는 사실이 중요한 전부입니다).
- 완료되지 않은 작업량을 최대화하는 기술인 단순성이 필수적입니다. (우리는 가능한 한 적게 할 것입니다).
- 최고의 아키텍처, 요구 사항 및 설계는 자체 구성 팀에서 나옵니다. (우리에게 무엇을 해야 할지 말하지 마십시오).
이제 이것은 엔지니어 친구에 대한 공격이 아닙니다. 나와 함께 일하는 대부분의 개발자는 일을 잘하는 데 열정적이며 스프린트 일정과 약속된 결과물을 기반으로 수준 이하의 작업을 생성해야 한다는 제약을 느낍니다. 그럼에도 불구하고 애자일 컬트에 세뇌된 일부 기술 리더는 위의 원칙을 따를 자유가 있다고 생각합니다. 요구 사항은 규칙보다 제안에 가깝고, 디자인은 해석의 여지가 있으며, 최종 결과가 여전히 "작동"하는 경우 무엇이든 잘라내는 것이 공정한 게임입니다.
애자일 원칙과 스크럼 관행의 조합은 신생 기업에 재앙입니다. 이들은 경영진의 운영 지침입니다. 디자이너, PM 및 엔지니어는 자기 조직화하지 않고 이러한 방식으로 작업을 선택합니다. 이 모든 것이 "MVP"라는 이름과 시장 출시 시간에 달려 있습니다. 연구 및 설계는 고객 문제에 대한 솔루션을 생성하지만 구축되는 것은 항상 비교 대상이 되지 않습니다. 제품 관리자는 로드맵에서 다음번 빛나는 개체를 만들기 위해 서둘러야 합니다. 엔지니어는 조립 라인의 기계처럼 취급되며 항상 생산 및 납품을 기대하고 작업을 "완료"하기 위해 절차를 생략하도록 장려됩니다.
리더십은 제품이 왜 그렇게 불안정하고 비효율적인지 머리를 긁적입니다. 쓰레기, 불일치 및 너무 무거운 짐을 제거하는 것과는 거리가 먼 애자일과 스크럼은 낭비만 만듭니다. 소진, 기술 부채, 디자인 부채, 급증하는 백로그, 하드 코딩된 프런트 엔드 로직, 완전한 리팩토링의 항상 존재하는 위협의 진흙탕입니다. 어떻게 벗어날 수 있습니까?
그냥 멈춰.
고객 중심 솔루션을 스프린트에 집어넣을 수는 없습니다.
- 무엇을 구축해야 하는지 결정합니다.
- 확장성 및 미래 대비를 위해 구축하는 최선의 방법을 결정합니다.
- 그런 다음 시간이 오래 걸리더라도 구축하십시오. (2년이 걸리지는 않겠지만 2주도 걸리지 않을 것입니다. 제품이 사양에 맞게 구축되는 한 릴리스는 쪼개질 수 있습니다.)
- 코너 절단이 아닌 탁월함을 장려하십시오.
- 미래의 노력이 더 효율적일 수 있도록 디자인 시스템 및 깨끗한 기술 스택과 같은 근본적인 노력에 투자하십시오.
- UX에 투자하고 기능 세트의 폭보다 깊이를 더하십시오.
- 인력을 줄이고 동일한 양의 출력을 기대하는 대신 올바른 방식으로 운영 효율성에 투자하십시오.
The age of Agile must end
30 years ago the technology industry attempted to import Lean practices — it failed. Instead of “continuous improvement,” progress halted…
uxdesign.cc
번역된 내용으로 의역이나 오역이 있을 수 있습니다. 자세한 내용은 원문을 확인하시기 바랍니다.
'Topic' 카테고리의 다른 글
| 사용자 중심 인공지능, 인간과 AI가 협력하는 방법 (0) | 2023.10.18 |
|---|---|
| 문명의 충돌, 메타버스와 블록체인 (0) | 2022.09.05 |
| '웹 3.0' 개념을 무시해도 좋은 이유 (0) | 2022.06.09 |