스프린트간에 작업을 빌드하는 것 이외의 민첩한 관행에 이점이 있습니까?

나는 최근에 소프트웨어 개발의 민첩한 관행에 관심을 가지게되었으므로이 관행이 전체 비용을 절감 할 수 있다는 많은 기사를 보았습니다.

그 뒤에 숨겨진 논리는 일반적으로 다음과 같습니다. 요구 사항이 변경되면 다음 스프린트 백 로그에이 변경 사항을 반영 할 수 있으며 이는 새로운 기능을 디자인하고 구현하는 데 시간이 걸리기 때문에 비용 절감으로 이어질 것입니다. 유명한 규칙에 따르면, 나중에 요구 사항을 변경해야할수록 그 요구 사항을 충족시키는 것이 더 비싸다는 유명한 규칙에 따라 비용이 줄어 듭니다.

그러나 중대형 소프트웨어 프로젝트는 복잡합니다. 요구 사항이 갑자기 변경되었다고해서 해당 요구 사항을 충족시키기 위해 시스템의 다른 부분을 만질 필요는 없습니다. 많은 경우 아키텍처를 매우 크게 수정해야하므로 이전 아키텍처에 의존했던 모든 기능을 다시 구현해야합니다. 따라서 비용 절감의 요점은 여기서 사라집니다. 물론 새로운 요구 사항이 시스템의 새로운 독립적 인 부분을 요구하는 경우 문제가되지 않고 기존 아키텍처가 커지면 다시 생각하거나 다시 구현할 필요가 없습니다.

그리고 그 반대입니다. 폭포를 사용하고 있고 새로운 요구 사항이 도입되어야한다는 사실을 갑자기 깨닫게되면 디자인을 변경할 수 있습니다. 기존 아키텍처를 변경해야하는 경우 다시 설계하십시오. 그것이 실제로 그것을 엉망으로 만들지 않고 시스템의 새로운 부분을 소개한다면, 모든 일을하고 문제없이 여기에서하십시오.

즉, 민첩한 개발이 가진 유일한 장점은 스프린트 사이에 기능을 완벽하게 구축하는 것 같습니다. 많은 사람들과 prjects에게는 이것이 중요하지 않습니다. 또한 애자일은 전체적으로 소프트웨어 아키텍처가 나빠지는 것처럼 보입니다. 기능이 서로 겹치기 때문에 애자일 팀은 기능이 작동하는 방식이 아니라 기능 만 관리하기 때문입니다. 시스템이 시간이 지남에 따라 복잡해지면 민첩한 개발 관행이 실제로 전체 제품 아키텍처에서 혼란을 증가시켜 결국 변경을 도입하기가 점점 더 어려워 지므로 더 높은 비용을 초래하는 반면 폭포는 아키텍처를 완벽하게 만들 수 있습니다 당신이 아무것도 풀기 전에.

분명히 많은 사람들이 프로덕션 환경에서 민첩성을 사용하므로 어딘가에 잘못해야하기 때문에 누군가 내가 여기서 잘못 가고 있다고 지적 해 줄 수 있습니까?

우선 "폭포"모델은 항상 소프트웨어 개발 프로젝트를 실행하지 않는 방법을 설명하는 짚맨이었습니다. 찾아 봐

어쨌든 대부분의 "폭포"SDLC 프로젝트는 사람들이 사양에 기록 된 가정이 더 이상 유효하지 않다는 것을 발견 할 때 "변경 관리"프로세스를 수반합니다 (이는 항상 대규모 복잡한 프로젝트에서 발생 함). 불행히도 변경 관리 프로세스는 예외 처리 수단으로 구축되었으며 어리석은 비용이 발생하여 프로젝트가 늦거나 품질이 떨어질 수 있습니다.

애자일 방법론의 기본 개념은 변화가 주어진다는 것입니다. 따라서 예외 처리가 아닌 "변경 관리"표준 작업을 수행해야합니다. 쉽지는 않지만 많은 훌륭한 디자인 방법을 사용하면 가능하다는 것을 알게되었습니다.

프런트로드 디자인의 또 다른 주요 문제는 요구 사항을 수집하고 디자인, 개발 및 테스트하는 데 많은 시간이 소요된다는 것입니다. 또한 테스트가 마지막 단계이고 심각한 문제가 발견되면 시간 내에 수정 될 가능성이 거의 없습니다.

아마도 애자일 접근 방식의 가장 좋은 기능 중 하나는 솔루션을 개발하는 팀과 솔루션을 필요로하는 고객 간의 지속적인 상호 작용 (즉, 실제 커뮤니케이션)이 필요하다는 것입니다. 우선 순위가 가장 높으므로 우선 순위가 가장 높은 항목이 먼저 수행됩니다 (시간이 지나면 우선 순위가 낮은 항목이 삭제됨). 피드백이 빨리 온다.

극적인 변화에 대한 질문으로 돌아가서 변화를 완화시키는 방법을 사용해야합니다. 우수한 SOLID OO 사용자는 소프트웨어를 회귀 테스트 할 수 있도록 견고한 자동 테스트 스위트를 구축 할 수 있으므로이 부분에서 큰 역할을 할 수 있습니다. 방법론에 관계없이 이러한 작업을 수행해야하지만 민첩하게 행동하려는 경우에는 반드시 필요합니다.

글쎄, 몇 가지 장점이 있습니다. 첫 번째는 고객이 사양 문서를 읽지 않는다는 것입니다. 이제까지. Waterfall은 모든 사람들이 처음에 사양에 동의 할 것이라고 가정하고 1 년 후 일치하는 사양에 소프트웨어를 고객에게 제공하면 만족할 것입니다. 실제로 고객은 실제로 필요한 모든 것을 발견하고 실제로는 필요하지 않으며 소프트웨어 자체를 적극적으로 사용할 때 실제로 다른 것이 필요합니다. 애자일은 고객에게 실용 프로토 타입을 제공하므로 이러한 연결 해제가 즉시 포착됩니다. 애자일은 변화하는 요구 사항에만 대응하는 것이 아닙니다. 또한 변경 비용이 높을 때 변경 비용이 낮을 때가 아니라 변경 비용이 일찍 발생하도록하는 것도 중요합니다.

두 번째 장점은 애자일이 가시적 인 결과물을 자주 볼 수 있기 때문에 프로젝트가 철로를 벗어날 가능성이 적다는 것입니다. 큰 Waterfall 프로젝트를 사용하면 실현하지 않고도 너무 쉽게 빠져 나갈 수 있습니다. 폭포는 프로젝트가 끝날 때 여러 달에 걸쳐 죽음을 행진합니다. Agile을 사용하면 몇 주마다 고객에게 제품을 제공하기 때문에 모든 사람이 프로젝트의 위치와 슬립을 신속하게 파악 (및 조정) 할 수 있습니다. 내 경험상, Waterfall은 마지막에 100 시간의 주 또는 몇 개월을 생산합니다. 민첩성은 스프린트가 끝난 후 12 시간 동안 며칠을 기다려야 할 수도 있음을 의미합니다.

세 번째 장점은 애자일 프로젝트가 더 동기 부여되는 경향이 있다는 것입니다. 사람들이 1 년 동안의 프로젝트에서 어떤 종류의 추진력을 갖는 것은 매우 어렵다. 마감일이 너무 멀어 보이고 즉시 성이 부족하다는 것은 사람들이 미루고 과도하게 디자인하는 경향이 있고 그렇지 않으면 매우 생산적으로 일하지 않는 것을 의미합니다. 스펙 문서와 같이 사람들이 원하지 않는 일에 초기 개월이 소비되기 때문에 특히 그렇습니다. 애자일은 항상 가까운 시일 내에 매우 즉각적이고 구체적인 마감일을 가지기 때문에 사람들은 더 동기를 부여하는 경향이 있습니다. 다음 주에 예정된 일련의 과제에 대해 구체적인 마감일을 미루는 것이 훨씬 어렵다.

반 민첩한 반대자들에 대한 근본적인 오해 인 질문의 인용에 응답하여

"... 폭포를 사용하면 아무 것도 해제하기 전에 아키텍처 를 완벽하게 만들 수 있습니다 ." 오류입니다. 문제를 해결하겠습니다. "... 폭포를 사용하면 아키텍처 를 완벽하게 만들 수 있으므로 아무 것도 해제 하지 않아도 됩니다. "

Waterfall이 어떻게 고품질 아키텍처를 제공하는지에 대한 암시는 근본적으로 거짓이며 경험적 역사적 증거에 의해 완전히 반증됩니다.

Facebook이 5 억 명의 사용자를 어렵고 빠른 요구 사항으로 폭포수 방식으로 설계하고 완벽하게 지원할 수있을 때까지 출시되지 않은 오늘날 아무도 그 소식을 듣지 못했습니다.

YouTube, Twitter 및 수많은 다른 회사와 동일합니다.

그들은 고객이 작업에 반응하고 대응할 수있는 것을 얻었고 가능한 빨리 그것을 발표했습니다. 그들은 피드백을 받고 그것을 다듬어 다시 발표했습니다. 반복하십시오. 이러한 세 가지 예에서 고객이 가치를 거의 또는 전혀 알지 못하는 것에 대해 가능한 한 적은 시간을 고객이 수용하고 원하는 기능으로 만 응답하는 방식입니다.

소프트웨어 개발 경험이 풍부한 사람이라면 완벽한 아키텍처 와 같은 것은 없다는 데 동의 할 것입니다 . 다른 대안보다 엔트로피와 큰 진흙 공에서 시작하는 것입니다. 애자일은 이것을 인정하고 그것을 고려합니다. 기술 부채, 빠른 우선 순위 지정 및 리팩토링과 같은 프로세스를 구축합니다.

스크럼 자체는 일반적인 프레임 워크이므로 기술 관행을 규정하지 않습니다.

민첩한 소프트웨어 개발에는 팀의 기술 우수성이 필요합니다. 이것은 XP (익스트림 프로그래밍)의 다음 기술 관행 에서 비롯됩니다 . 예를 들어 리팩토링, tdd, 전체 팀, 페어 프로그래밍, 증분 디자인, CI, 협업 등에 대해 배워야합니다.

그렇게하면 빠르고 안전하게 변경을 처리 할 수있게되는데, 이는 애자일 개발을 처음 사용하는 주된 이유이기도합니다.

중요한 민첩성 측정 중 하나는 정기적으로 (매주, 격주마다) 귀중한 작동 소프트웨어를 고객에게 공개하는 경우입니다. 그렇게 할 수 있습니까? 그럼 당신은 내 책에 민첩합니다.

저에게 애자일의 주요 이점은 프로젝트의 위험을 줄이는 것입니다.

반복적으로 제공하고 사용자 기반에서 많은 피드백을 받으면 실제로 원하는 것을 제공 할 가능성이 높아지고 가능한 한 빨리 가장 중요한 기능을 실용적으로 제공하여이를 수행 할 수 있습니다. 이론적으로는 더 나은 추정 및 계획으로 수행됩니다. 이것은 단순히 릴리스 가능한 빌드보다 훨씬 더 비즈니스 관점에서 매우 매력적입니다.

이 끊임없는 변화가 시스템을 손상시키고 품질을 떨어 뜨린다 고 주장 할 수 있지만 두 가지를 말씀 드리겠습니다. 1) 이러한 변화는 어쨌든보다 전통적인 소프트웨어 제공 프로젝트에서 발생합니다. 프로젝트에서 나중에 설명되지 않고 나중에 발생하기 때문에 변경이 더 어렵고 비용이 많이 듭니다. 2) 애자일은 경험이 많은 동기 부여 된 사람들과 TDD, 페어링 및 코드 검토와 같은 관행을 사용하는 관점에서 이러한 변화를 다루는 것에 대해 많은 이야기를합니다. 품질과 지속적인 개선에 대한 사고 방식이 바뀌지 않으면 민첩한 변화가 문제를 일으킬 수 있음을 암시합니다.

많은 경우 아키텍처를 매우 크게 수정해야하므로 이전 아키텍처에 의존했던 모든 기능을 다시 구현해야합니다.

요구 사항 변경으로 인해 아키텍처를 크게 수정해야하는 경우 아키텍처가 잘못되었거나 요구 사항이 잘못되었습니다. 좋은 아키텍처를 사용하면 가능한 한 많은 의사 결정을 연기하고 시스템 구성 요소를 분리 할 수 ​​있습니다. 좋은 (사용자) 요구 사항은 "다른 데이터베이스 사용"과 같은 것이 아닙니다.

따라서 우리는 훌륭한 작업 아키텍처를 가지고 있다고 가정합니다. 이 경우 민첩한 개발 방법론은 초기 설계 방법론으로이 "세척"을 잃습니다. 결국 민첩한 개발 방법론의 핵심 기능은 코드에서 느슨하게 커플 링을 촉진하는 TDD와 같은 관행으로, 프로젝트가 시작에 가까우거나 성숙하더라도 프로젝트를 고속으로 계속 진행할 수 있습니다.

많은 경우 아키텍처를 매우 크게 수정해야하므로 이전 아키텍처에 의존했던 모든 기능을 다시 구현해야합니다. 따라서 비용 절감의 요점은 여기서 사라집니다.

민첩한 프로세스를 수행하면 너무 많은 소프트웨어가 개발되기 전에이 요구 사항을 파악할 가능성이 높아집니다 (변경해야 함). 클라이언트와 작업하지 않고 몇 달 동안 보지 않고 살펴보면 제공 할 준비가 된 "생각"한 후에 만 ​​이러한 주요 아키텍처 문제가 발생합니다.

오히려 컴파일조차하지 않는 거대한 코드 더미보다 테스트 범위가있는 작동중인 응용 프로그램에서 이러한 변경 사항을 구현하려고합니다. 기술 지원을 담당하는 동안 몇 달 동안 개발되어 설치되지 않은 응용 프로그램의 CD를 받았습니다. 우리는 첫 주에 그 문제를 발견 할 수 있었지만, 긴 밤이어서 식당을 주문할 시간이었습니다.