Agile vs Scrum vs Kanban vs Lean vs Waterfall – 어떤 접근 방식이 적합합니까?

안녕하세요, Family Feud의 다른 에피소드에 오신 것을 환영합니다. 저는 Steve Harvey입니다. 이 작업을 진행해 보겠습니다.

우리는 100명에게 "프로젝트 관리에서 가장 좋아하는 접근 방식은 무엇입니까?"라고 물었습니다.

Agile – 목록에 있습니다!

스크럼 – 다시 말하지만 목록에 있습니다!

칸반 - 딩!

린 – 한 번 더 가야 합니다!

폭포 – 브라보, 수고하셨습니다!

당신은 그들 모두를 알고있는 것처럼 보이지만 어느 것을 선택해야하는지 알고 있습니까?

또는 Agile vs. Waterfall vs. Scrum의 차이점은 무엇입니까?

괜찮아요.

저는 스티브 하비입니다.

진지하게 말하면 저는 스티브 하비가 아닙니다. 저는 스티브 하비 역을 맡은 작가일 뿐입니다.

이 모든 이름은 무엇을 의미합니까?

기본 사항부터 시작하여 집합적으로 의미하는 바를 정의할 수 있습니다. 이 5가지 모델은 모든 프로젝트 관리 프로세스, 특히 소프트웨어 개발에서 가장 많이 사용되는 모델입니다. 그들은 시간을 어떻게 사용하는지, 역할이 있는지 여부, 실수를 수정해야 할 때 등을 알려줍니다.

이제 우리가 그들에 대해 이야기하고 장단점을 보여줄 때가 되었습니다.

폭포 접근

Waterfall Approach 또는 model 은 순서대로 작동하는 개발 모델입니다. 개발의 모든 단계를 정의하고 이전 단계를 완료하지 않고는 다음 개발 단계로 넘어갈 수 없습니다. 1970년에 Winston Royce에 의해 설립된 이 방법의 각 단계는 작업을 위해 특별히 설계되었습니다.

폭포 접근의 단계

무대가 궁금하세요? 당연히! 그럼 배워봅시다.

• 수집 단계: 필요한 세부 정보를 얻거나 설정하는 단계입니다.
• 설계 단계: 프로그래밍 언어, 사용할 데이터베이스를 선택하고 훌륭한 기술 세부 사항을 계획하는 단계입니다.
• 구축 단계: 단순히 코딩만 하면 됩니다. 많은 코딩이 필요합니다.
• 테스트 단계: 이제 이 프로그램을 사용할 사람들에게 이 프로그램을 보여주고 요구 사항을 충족하는지 확인합니다.
• 배포 단계: 요청한 환경에서 프로그램을 시작합니다.
• 유지 관리 단계: 고객의 요구 사항이나 대상에 따라 프로그램을 변경하고 개선합니다.

다음은 폭포 접근 방식의 6단계입니다. 아주 간단하죠?

누가 이 방법을 효과적으로 사용할 수 있습니까?

이 개발 방법을 사용하면 추가 작업이 거의 또는 전혀 필요하지 않은 프로젝트에서 작업할 수 있습니다. 환경이 안정적이고 모든 요구 사항이 설정 및 완료되고 프로젝트가 짧고 모두가 자신이 무엇을 하고 있는지 알고 있다면 이것이 선택 사항입니다.

폭포수 방식의 장단점

Waterfall Method가 가장 많이 사용되는 이유는 무엇입니까? 물론 장점이 있어야 합니다. 이것들은;

• 선형성. 이 방법으로 모든 단계를 완료해야 나중에 문제가 발생하지 않습니다.
• 소규모 프로젝트에 적합합니다. 프로젝트에 시간이 너무 많이 걸리지 않는다면 이 방법이 가장 효과적입니다.
• 검증 및 검증. 각 단계 전에 품질 테스트를 실행합니다.
• 정교한 문서. 이런 식으로 모든 단계를 추적할 수 있습니다.
• 최소한의 클라이언트 개입. 수행하는 프로젝트는 팀에 크게 의존합니다.
• 필요한 모든 변경 사항 은 개발 단계에서 수행되며 출시 후 불쾌한 놀라움이 없습니다.

그렇다면 사람들은 왜 다른 옵션을 선택하는 것일까요? 그렇기 때문에;

• 오류를 수정할 추가 시간이 없습니다. 개발하는 동안 오류를 수정해야 합니다.
• 변경할 여지가 없습니다. 요구 사항이 자주 변경되면 이 방법으로 프로젝트를 수행할 수 없습니다.
• 테스트 시간입니다. 테스트 단계는 개발 과정에서 상대적으로 늦습니다.
• 문서화에 시간이 너무 많이 걸립니다. 개발자와 직원은 문서화에 시간을 할애해야 합니다.
• 클라이언트 피드백이 거의 또는 전혀 없습니다. 클라이언트의 통찰력이 유용할 수 있지만 이 방법에서는 혼자입니다.
• 오류 후. 그들은 당신의 프로젝트에 너무 많은 문제를 일으킬 수 있습니다.

그래서 설명하는 폭포수법입니다. 이제 다음으로 넘어갑시다.

애자일 접근

기본적으로 Agile 접근 방식 에서는 점진적으로 작업해야 합니다. 이것은 스프린트 계획 주기에서 발생합니다. 첫 번째 주기를 마친 후에는 프로젝트를 테스트한 다음 모든 것이 필요에 따라 선택적으로 배포됩니다.

누가 애자일 방법을 사용해야 합니까?

변경하기 쉬운 환경에서 작업하거나 생각날 때마다 프로젝트에 새로운 아이디어를 가져오고 싶다면 Agile Method가 올바른 선택입니다. 그것은 당신에게 매우 귀중한 자유를 줍니다.

애자일 방법의 장단점

다음 프로젝트 또는 현재 프로젝트에서 이 방법을 사용하려면 이 방법의 장단점을 알아야 합니다.

먼저 전문가부터 시작할 수 있습니다. 그들은;

• 고객 만족. 지속적으로 "최종 결과"를 제시하기 때문에 고객은 개선 사항을 볼 수 있습니다.
• 사람 중심. 이 방법의 주요 동기는 도구 및 기타 프로세스 대신 프로젝트를 수행하는 사람들입니다.
• 빈도. 짧은 시간에 작동하는 소프트웨어를 볼 수 있습니다.
• 적응. 상황이 바뀌더라도 쉽게 적응할 수 있습니다.
• 의사소통. 사람과 고객은 즉시 상호 작용할 수 있습니다.
• 변화의 여지가 있습니다. 프로젝트를 배포한 후에도 쉽게 변경할 수 있습니다.

완벽한 것은 없으며 이 방법도 없습니다. 그래서 여기에 단점이 있습니다.

• 노동의 평가. 다소 큰 프로젝트를 진행하는 경우 주기에 필요한 시간과 노력을 평가하지 못할 가능성이 있습니다.
• 문서화 및 디자인에 대한 강조가 적습니다. 이는 프로젝트에서 수행된 작업을 추적하는 데 방해가 될 수 있습니다.
• 고객. 명확하지 않고 무엇을 해야 할지 모르는 경우 프로젝트가 다른 것으로 끝날 수 있습니다.
• 경험과 출처. 일부 결정은 선임 프로그래머가 내려야 합니다. 그렇지 않으면 초보자를 위한 소스가 필요합니다.

보시다시피 Agile Method는 자유와 소통을 사랑하고 안절부절 못하는 사람들을 위한 것입니다. 이 방법은 그런 팀이 있는 경우 유용합니다.

칸반 접근

Kanban 접근법 ... 일본어처럼 들리지 않습니까? 일본어로 '보이는 카드'이기 때문입니다. 40년대 도요타가 처음 사용했을 때부터 사용했습니다. 이 방법에서는 작업을 카드나 스티커로 시각화합니다. 이러한 방식으로 효율성을 극대화하고 지속적으로 개선하는 것을 목표로 합니다.

이 5가지 중 Kanban Method는 원칙이 돋보입니다. 이제 그들을 볼 시간입니다.

칸반 방식의 원리

Kanban Method에는 총 6가지 원칙이 있습니다. 두 그룹으로 나열될 수 있습니다. 첫 번째 원칙 그룹을 변경 관리라고 합니다. 이 그룹의 원칙은 다음과 같습니다.

• 정기적으로 하는 일부터 시작하세요. Kanban 방법은 유연성을 제공합니다. 따라서 기존 워크플로에 Kanban 방식을 구현할 수 있으며 시간이 지나면 중요한 문제를 해결할 수 있습니다.
• 증분 변경. 이 방법은 어느 정도 진화와 유사한 변화를 좋아합니다. 즉, 하룻밤 사이에 큰 변화가 없습니다. 천천히 그곳을 통과해야 합니다.
• 모든 수준의 리더십. 이런 식으로 사람들은 다른 사람들의 통찰력을 통해 배우고 더 잘 일할 수 있습니다.

두 번째 원칙 그룹은 서비스 제공이라고 합니다. 다음으로 구성됩니다.

• 고객의 말에 귀를 기울이십시오. 고객의 요구와 기대에 초점을 맞추는 것이 주요 목표가 되어야 합니다. 이렇게 하면 제품이 고객의 관심을 끌 수 있습니다.
• 작업을 관리합니다. 이 원칙 덕분에 사소한 소음에도 방해받지 않고 진행 중인 일에 집중할 수 있습니다.
• 개선하다. 프로젝트를 배포한 후에는 리뷰와 불만 사항을 주시해야 합니다. 프로젝트의 품질을 유지해야 합니다.

누가 칸반 방법을 사용해야 합니까?

Kanban 방식에서는 워크플로가 가장 중요할 수 있습니다. 원하는 경우 이 방법을 워크플로에 구현할 수 있습니다. 또한 지속적으로 일할 의향이 있는 한 Kanban을 사용할 수 있습니다. 마지막으로, 귀하와 귀하의 팀이 회의에 너무 많은 시간을 할애하고 싶지 않다면 귀하를 위한 최선의 선택입니다.

칸반 방식의 장단점

이제 40대에 시작된 공법을 고급 와인처럼 만든 이유를 살펴보자.

• 유연한. Kanban은 개발 단계를 제한하지 않습니다. 따라서 최선을 다해 업무를 수행할 수 있는 시간과 공간이 있습니다.
• 연속성. Kanban을 사용하면 프로젝트의 작은 부분을 지속적으로 제공할 수 있습니다. 따라서 변경 사항에 적응할 수 있는 여지가 생깁니다.
• 효율적인. 프로젝트의 주요 측면에 집중하고 중요한 세부 사항에 대해 작업하므로 시간 낭비가 없습니다.
• 응답 시간이 짧습니다. 팀은 단계가 끝나면 메모를 다시 정렬할 수 있습니다. 이렇게 하면 직원이 즉시 다음 작업을 수행할 수 있습니다.

좋아, 무엇이 칸반을 ​​우유처럼 늙게 만들었는지 볼 시간이다.

• 의존. Kanban을 사용하려면 다른 프레임워크를 올바르게 사용해야 합니다. 자율 연결이 불가능합니다.
• 역 동성. Kanban은 여전히 ​​특정 안정적인 지점이 있다고 가정합니다. 환경이 매우 동적이면 문제가 됩니다.
• 반복. 그들은 Kanban 프로세스 내부에 있지 않습니다. 별도로 처리해야 합니다.
• 타이밍. 어떤 사람들에게는 타이밍에 대한 정의가 문제가 될 수 없습니다.

프로젝트를 수행하는 가장 오래된 방법 중 하나입니다. 그러나 늙었다고 해서 쓸모가 없는 것은 아닙니다. 시간에 대한 내구성은 Kanban 방법이 여전히 작동한다는 증거 중 하나입니다. 그러나 작업을 망칠 수 있는 단점에 주의해야 합니다.

린 접근 방식

린 은 제품에 고객이 정의한 가치를 추가하여 낭비를 최소화하려는 사고 방식과 일련의 도구를 중심으로 하는 접근 방식입니다. 따라서 프로젝트 관리에 대한 최소한의 접근 방식으로 정의할 수 있습니다.

이 접근 방식은 또한 8가지 유형의 폐기물을 정의합니다.

이것들은;

• Motion : 직원 및 장비의 불필요한 움직임.
• 운송 : 필요하지 않은 물품을 해당 장소까지 운송합니다.
• Waiting : 필요한 일이 오기만을 기다리며 시간을 허비함.
• 과잉 생산 : 필요한 것보다 더 많이 생산하는 것.
• 결함 : 소스를 수정해야 하는 결함 제품
• Inventory : 잘못된 의사 소통으로 인해 더 많은 정보 또는 인벤토리가 가득 찬 것을 저장합니다.
• 인정받지 못한 인재 : 직원의 재능을 이해하지 못함
• 추가 처리 : 필요하지 않거나 가치가 없는 활동.

린 방식은 기본적으로 이러한 낭비를 없애려고 합니다.

누가 린 방식을 사용해야 합니까?

초기에 보이는 것보다 더 효과적이기를 열망하는 소규모 팀이라면 린 방식이 적합할 수 있습니다. 또한 단기 프로젝트를 위한 훌륭한 방법론입니다.

린 방식의 장단점

린 방식에는 기댈 수 있는 몇 가지 기능이 있습니다. 죄송합니다. 그렇게 해야 했습니다. 이것들은;

• 낭비 제거 . 위에서 언급했듯이 이 방법의 주요 초점은 낭비를 제거하는 방법입니다.
• 직원을 만족시키십시오 . 폐기물 관리 프로세스에 직원을 포함시켜야 하므로 직원들이 감사할 것입니다.
• 제 시간에 . 필요할 때 재료를 구입하고 가져오세요.
• 경쟁 우위 . 지금 저축하고 있는 장소나 돈은 다른 프로젝트에 사용할 수 있습니다.

모든 것에는 적어도 하나의 단점이 있기 때문에 단점이 있어야 합니다. 이것들은;

• 남용 . 이 방법을 과도하게 적용하면 새로운 비효율에 직면할 수 있습니다.
• 제 시간에 . 이것은 당신의 저주가 될 수도 있습니다. 오류가 발생할 여지가 거의 없습니다. 시간 관리 문제의 경우 크게 실패합니다.
• 직원 불만. 다시 말하지만, 과도하게 지원하는 경우 직원들은 모든 것을 절약하는 방법에 좌절감을 느끼기 시작할 수 있습니다.

린 방법은 깨끗합니다. 낭비할 여지가 없고 개선할 여지가 많습니다. 그러나 신중하게 적용해야 하는 방법입니다. 그렇지 않으면 결과가 가혹할 것입니다.

스크럼 접근

마지막으로 Scrum Method 가 있습니다. 스크럼을 애자일 방법의 개선으로 생각하십시오. 대부분의 애자일 원칙은 이 방법에서도 유효합니다. 그러나 Scrum은 더 계획적이며 프로젝트 진행 방식을 안내하는 역할이 있습니다.

이러한 역할은 다음과 같습니다.

• 제품 소유자(PO): 고객과 이해 관계자를 대표하고 비즈니스 부품 및 투자 수익에 중점을 둡니다.
• 스크럼 마스터: 팀이 스크럼의 기준을 준수하도록 안내하고 PO와 협력하여 ROI를 극대화합니다.
• 팀: 프로젝트를 수행하는 전문가 그룹.

이 방법은 Agile과 매우 유사하기 때문에 서로 다른 장단점만 제시하면 충분합니다.

회의는 가장 먼저 지적해야 할 사항입니다. 하루가 끝나면 회의가 열립니다. 이러한 회의는 다른 역할이 프로젝트 진행 상황을 확인하는 데 도움이 될 수 있습니다. 그러나 장기적으로 보면 성가실 수 있습니다.

두 번째는 고객의 참여입니다. PO로부터 즉각적인 피드백을 받는 것은 매우 통찰력이 있습니다. 반면에 협조적이지 않으면 프로젝트를 완료하는 데 많은 시간이 걸릴 수 있습니다.

Scrum 대 Waterfall 은 일반적으로 모든 곳에서 발생하는 비교입니다. 스크럼 방법은 현대와 바쁜 삶에 적응합니다. 역할과 회의는 또한 큰 이점을 제공할 뿐만 아니라 해로울 수 있습니다.

마지막으로, 당신은 당신의 대답이 무엇을 의미하는지 압니다. Steve Harvey는 자랑스러워 할 것입니다. 지금해야 할 일은 상황을 자세히 설명하고 전문 지식 수준, 팀 규모 및 출처에 맞는 최상의 상황을 찾는 것입니다.

자주 묻는 질문

린과 애자일은 같은 것인가?

아니요, 린과 애자일은 동일하지 않습니다. Lean은 낭비를 최소화해야 한다는 사실에 초점을 맞추는 반면 Agile의 주요 초점은 점진적으로 개발하는 것입니다.

스크럼은 애자일인가, 폭포인가?

스크럼은 애자일 방식을 개선한 것입니다. Agile과 달리 Scrum에는 역할, 회의 및 고객 대표가 있습니다.

Kanban은 애자일입니까 아니면 린(Lean)입니까?

Kanban은 Lean 방식으로 간주됩니다. 둘 다 워크플로와 효율성의 중요성을 지적한다는 공통점이 있습니다.