수동 소득 아이디어 2023
집을 짓는 것이 복잡합니까? 소프트웨어 개발은 더 복잡합니다. 적어도 대부분. 이는 수많은 인터페이스, 다양한 최종 장치 및 다양한 이해 관계자의 요구 사항을 고려해야 한다는 사실 때문만은 아닙니다. 무엇보다도 이 모든 것이 끊임없이 변화하고 있으며 고전적으로 개발된 많은 소프트웨어 프로젝트가 출시 시점에서 이미 시대에 뒤떨어진 속도로 변화하고 있습니다. 또는 13년의 개발 끝에 2006년에 취소되어야 했던 과세당국의 대규모 FISCUS 프로젝트와 같이 전혀 완료되지 않았습니다. 애자일 소프트웨어 개발은 최근 몇 년 동안 이 문제에 대한 해답으로 자리 잡았습니다. 개발 초기에 긴 개념 단계와 두꺼운 요구 사항 및 기능 사양을 배치하는 고전적인 폭포수 방법과 달리 민첩한 소프트웨어 개발은 관리 가능하고 잘 정의되고 신속하게 구현 가능한 구성 요소를 식별하고 계획하는 반복 단계에서 유연하게 작동합니다. . 이러한 구분을 바탕으로 이 단기 계획에 초점을 맞추고 여기에서 매우 좁은 모델을 도출하는 민첩한 방법이 최근 기업 실무에서 특히 인기를 얻고 있습니다. 바로 스크럼입니다.
스크럼 및 애자일 소프트웨어 개발: 동일한가요?
명확한 답변: 아니요.
1990년대에 개발된 스크럼 모델은 17명의 개발자가 2001년 유타 산맥에 있는 스키 호텔에서 애자일 선언문을 작성하여 소프트웨어 개발의 새로운 방식에 이름을 붙이기 오래 전에 있었습니다. 익스트림 프로그래밍, 실용 프로그래밍 또는 DSDM 외에도 Scrum은 애자일 소프트웨어 개발의 기본 원칙을 파생시킨 풍부한 경험의 방법 중 하나였습니다. 이러한 기본 원칙에는 변화에 대한 대응뿐만 아니라 고객과의 긴밀한 협력 및 사람들 간의 상호 작용이 포함됩니다. 이 모든 것이 방향을 제시하는 가치이자 원칙입니다. 반면 스크럼은 상당히 고정된 모델을 기반으로 합니다. 이것이 아마도 많은 회사에서 스크럼이 애자일 소프트웨어 개발의 동의어가 된 주된 이유일 것입니다. 추상적인 값을 구현하는 것보다 구체적인 모델 사양을 고수하는 것이 종종 더 쉽기 때문입니다.
그렇다면 민첩한 소프트웨어 개발이란 무엇입니까?
애자일 소프트웨어 개발의 핵심은 실제로 빌딩 블록이자 영감의 원천입니다. 그것의 원칙은 당신이 논의 없이 쓰라린 끝까지 택한 길을 추구하지 말고 정기적으로 질문하고 필요하다면 적응하도록 격려합니다. 그러나 이것은 기능적 소프트웨어 요구 사항이나 그 이면의 코드뿐만 아니라 방법, 계약 및 책임에도 적용됩니다. 따라서 민첩한 소프트웨어 개발은 명확하게 정의된 방법이 아니라 일련의 가치와 매우 기본적인 개념입니다.
Scrum이 애자일 소프트웨어 개발의 가치에 전혀 부합합니까?
올바르게 사용하면 Scrum은 복잡한 소프트웨어 프로젝트를 성공적으로 관리하는 데 매우 적합한 방법입니다. 문제가 발생하더라도 실제 사용으로 인한 것은 모델 자체가 아닙니다. Scrum 개념의 모델 특성을 감안할 때 많은 회사에서 쉽게 잊는 것은 민첩한 소프트웨어 개발이 유연성 없이는 작동하지 않는다는 것입니다. 그리고 진정으로 민첩한 프로세스를 구축하는 것이 목표라면 이러한 유연성을 스크럼 모델에도 적용해야 합니다. 고전적인 부서 구조에 엄격한 스크럼 모델을 적용해도 문제가 해결되지 않습니다. 최악의 경우 더 커지기도 합니다. Scrum은 소프트웨어 개발 및 관련 역할이 주제별로 구성되어 있다고 가정합니다. 예를 들어 온라인 상점에서는 제품 페이지와 결제 프로세스를 구분할 수 있습니다. 그러나 많은 조직에서 제품 관리자와 같은 기술적인 문제를 담당하는 사람들은 주제별로(수직적으로) 구성되어 있지만 다른 역할은 기술적 측면(예: UX, UI, 프런트 엔드)에 따라 “수평적으로” 분산되어 있는 경우가 많습니다. 그리고 백엔드). 이것은 필연적으로 마찰과 효율성 손실로 이어집니다.
애자일 소프트웨어 개발이 실제로 무엇을 의미하는지 이해하려면 위에서 언급한 애자일 선언문을 다시 살펴보는 것이 좋습니다. 저자가 애자일 조직의 주요 특성을 매우 정확하게 요약했기 때문입니다.
개인 및 상호 작용(프로세스 및 도구 이전)
애자일 소프트웨어 개발의 초점은 소프트웨어가 아니라 사람입니다. 상호 지원, 공동 지식 구축 및 투명한 커뮤니케이션은 민첩한 팀의 기반을 형성합니다. 페어 프로그래밍과 같은 방법과 공통 코딩 및 문서화 표준에 대한 명확한 약속을 통해 개인 기반이 아닌 팀 기반으로 책임을 정의할 수 있으므로 개별 팀 구성원의 부담을 덜 수 있습니다. 이렇게 하면 몸이 아프거나 휴가를 가더라도 어려운 상황도 잘 극복할 수 있습니다.
작업 소프트웨어(광범위한 문서화 전)
물론 모든 팀 구성원이 이해하고 액세스할 수 있도록 애자일 소프트웨어 프로젝트도 문서화됩니다. 그러나 작동하는 소프트웨어는 대부분 이론적인 요구 사항만 깔끔하게 문서화되어 있는 두꺼운 사양 시트보다 더 중요합니다. 따라서 애자일 소프트웨어 프로젝트는 짧은 시간 후에 테스트할 수 있고 직접 사용할 수도 있는 작은 구성 요소로 나뉩니다. 예를 들어 최종 고객 제품은 첫 번째 버전의 공급자를 위한 효율적인 관리 인터페이스가 항상 필요한 것은 아니므로 이 구성 요소는 두 번째 단계에서 구현할 수 있습니다. 이러한 방식으로 개별 구성 요소에 대한 요구 사항이 올바르게 구현되었는지 여부와 결과가 실제로 작동하는지 여부가 프로젝트 초기에 명확해집니다.
고객과의 협력 (계약 협상 전)
진정한 애자일 소프트웨어 개발은 고객에게 더 많은 것을 요구하기 때문에 때때로 고객에게 인기가 없습니다. 더 많이 생각하고, 더 많이 재고하고, 마지막으로 중요한 것은 더 많은 시간을 할애하는 것입니다. 애자일 소프트웨어 개발은 고객이 처음에 자신의 요구 사항을 기록한 다음 IT 서비스 제공업체에 프로젝트를 넘기는 기존의 폭포수 방식과 달리 전체 개발 프로세스에 고객이 참여하기 때문입니다. 이 접근 방식이 더 많은 노력을 기울이는 것처럼 보이더라도 시장에서 실용적인 솔루션을 훨씬 더 잘 받아들이고 결과가 고객이 실제로 필요로 하는 것과 더 가깝기 때문에 항상 보상을 받습니다. 고객은 일반적으로 IT 전문가가 아닙니다. 비용 효율적이고 맞춤형이며 사용하기 효율적인 것이 무엇인지 함께 찾아야 합니다. 내부 상품 관리는 온라인 상점과는 완전히 다른 검색 기능이 필요할 수 있습니다. 그리고 21세기에도 많은 입력이 필요하고 소규모 사용자 그룹이 응용 프로그램을 집중적으로 사용하는 경우 키보드 작업에 응용 프로그램을 최적화할 가치가 있습니다. 만능 솔루션은 없습니다. 모든 프로젝트는 고유합니다.
변화에 대응(계획을 따르기 전)
계획은 좋다. 그러나 현실과 일치하는 한. 시장 또는 경쟁 조건이 바뀌거나 새로운 기술이 등장하거나 고객이 갑자기 완전히 새로운 기대치를 가지게 되면 너무 경직된 계획은 성공에 큰 장애물이 될 수 있습니다. 민첩한 소프트웨어 개발은 변화에 유연하게 대응할 수 있다는 특징이 있습니다. 예를 들어 개발 중에 새로운 종속성 또는 기타 기술 요구 사항이 발생하는 경우 외부에서 왔는지 내부에서 왔는지에 관계없이 가능합니다. 몇 년에 걸쳐 이전에 정의된 목표를 향해 작업하는 소프트웨어 프로젝트는 거의 불가피하게 현실을 무시합니다. 왜냐하면 세상은 계속 돌아가고 요구 사항은 그에 따라 변하기 때문입니다.
그래서 모든 것이 우연입니까?
물론 아닙니다. 내가 말했듯이 계획은 좋습니다. 그리고 바로 프로그래밍하는 것만으로 아주 드문 경우에만 성공할 수 있습니다. 경험상 중기 계획은 애자일 소프트웨어 프로젝트에 가장 적합합니다. 스크럼 가이드가 2주 스프린트로 고정하도록 하면 너무 꽉 조이는 코르셋처럼 빠르게 느껴질 수 있습니다. 3개월에서 최대 6개월 동안 실행되고 마지막에 MVP(최소 실행 가능한 제품), 즉 제품의 최소 변형이 있는 소규모 프로젝트를 정의하는 것은 개발 경험에서 매우 효율적인 것으로 입증되었습니다. 이것은 고객이 3개월 동안 우리의 소식을 듣지 않는다는 것을 의미하지 않습니다. 물론 그는 임시 상태에 포함되며 일반적으로 미세 조정이 시작되기 2개월 전에 거의 모든 것을 보았습니다.
기간이 짧은 이러한 개별 프로젝트의 가장 큰 장점은 위험이 적고 관리 가능한 투자로 빠른 결과를 가져오므로 신속하게 관리할 수 있다는 것입니다.
황금률
민첩한 소프트웨어 개발 방법을 사용하면 복잡한 소프트웨어 프로젝트도 매우 잘 처리할 수 있습니다. 그러나 민첩하게 작업하는 것이 현재의 스크럼 과대 광고가 너무 세부적인 개념으로 강제된다는 것을 의미할 필요는 없습니다. 스크럼을 도그마가 아니라 영감을 주는 가능성의 키트로 본다면 애자일 작업의 모든 이점을 실제로 활용하고 단점 없이도 할 수 있습니다. 그러면 애자일 방법을 통해 소프트웨어 개발이 실제로 더 좋아질 것입니다. 즉, 직원들에게 더 많은 동기를 부여하고 고객에게 더 성공적이며 결과적으로 더 효율적일 것입니다. 흔히 그렇듯이 행복은 행복한 매체에 있습니다. 스크럼에서 영감을 받은 프로젝트를 작은 단계로 유연하게 계획한 다음 이러한 방식으로 해결된 기초 위에 점진적으로 구축하는 것은 우리의 실천에서 그 자체로 입증되었습니다. 경험에 따르면 3개월 주기는 관련된 모든 사람이 자신의 아이디어에 따라 정확하게 기여할 수 있도록 정확히 올바른 프레임워크를 제공합니다. 경영진은 많은 세부 사항을 다루지 않고도 방향을 설정할 수 있습니다. 제품 관리자는 주기 내에서 직접 제어하고 결정을 내릴 수 있는 기회가 있습니다. 그리고 서비스 제공자로서 우리는 제품 관리자와 함께 세부 사항을 설계하는 노하우와 경험을 제공할 수 있습니다.
이러한 방식으로 여러 수준에서 불필요한 조정으로 낭비되는 시간을 모든 프로젝트 참가자의 기술이 가장 효율적인 곳에서 건설적으로 사용할 수 있습니다. 이러한 방식으로 광범위한 개발 마라톤도 기록적인 시간을 설정하고 행복하고 균형 잡힌 팀과 함께 결승선을 통과할 수 있습니다.
