작업 시스템을 교체 할 때 민첩성이 어떻게 작동합니까?

이상적인 애자일 세계에서는 원하는 최종 시스템의 작지만 유용한 서브 세트를 신속하게 구축하여 사용자에게 제공합니다. 그들은 유용하기 때문에 흥분합니다. 사용하기 시작하고 피드백을 제공합니다. 그런 다음 추가 할 작업을 수행하고 빌드 한 후 시간이 없을 때까지 반복하십시오.

최근에 일종의 작업 시스템을 교체하는 몇 가지 프로젝트가있었습니다. 위의 모델은 전혀 작동하지 않았습니다. 기존 시스템의 거의 모든 기능을 포함하는 시스템을 만들 때까지 사용자는 전혀 관심이 없었습니다. 그들은 그것을 사용하지 않을 것입니다.

"가장 작은 유용한 부분 집합"이 "모두"인 경우 어떻게 Agile을 적용합니까?

민첩한 솔루션은 모든 것을 한 번에 교체 하지 않고 점차적으로 교체를 단계적으로 수행하는 것일 수 있습니다 .

기존 시스템의 일부를 계속 실행하면서 비트 단위로 점진적으로 새로운 시스템을 도입하십시오. 기존 시스템은 한 번에 모두 꺼지지 않고 단지 사라집니다. 새로운 부품은 새로운 기능 또는 다른 이점을 제공하므로 사용자는 기꺼이 사용할 수 있습니다. 항상 100 % 작업 시스템을 가지고 있기 때문에 덜 위험합니다.

• Martin Fowler에서 더 많은 것을 읽으십시오 .
• Michael Feather의 레거시 코드로 효과적으로 작업 의 전략 이 유용 할 수 있습니다.

기존 시스템을 다시 작성하는 대신 (새 시스템이 기존 기능과 일치하기 전에 상당한 노력이 필요함 ), 덩굴 식 접근 방식을 고려하십시오 . 기본적으로 기존 응용 프로그램 위에 새로운 접근 방식 을 사용하여 새로운 기능을 구현 합니다. 결국 새로운 기능을 해결하기 위해 기존 시스템의 단점을 해결함에 따라 새로운 코드가 기존 코드를 완전히 대체합니다.

이전 앱의 "재부팅"보다 더 많은 정확성과 노력이 필요합니다. 그러나 ROI를 단축 할 수 있습니다. 또한 프로세스를 진행하면서 "새"시스템이 다음 "새"시스템에 의해보다 쉽게 ​​교착 될 수 있도록 후크를 제자리에 놓을 수 있습니다.

세계로 조금씩 증가 시키면 그린 필드 프로젝트에는 효과가있을 수 있지만, 소수의 기능은 그다지 유용하지 않을 수 있습니다.

스크럼은 각 스프린트 후 제품이 "잠재적으로 배송 가능"하다고 주장합니다. 배송 할 필요는 없지만 배송 가능한 제품의 품질을 가져야합니다.

사용자에게 앱의 증분 버전을 제공하려는 경우 실제 프로덕션 앱을 계속 사용하면서 알파, 베타, 릴리스 후보 버전으로 분류 할 수 있습니다.

사용자의 피드백을 통합하면 새로운 기능이 추가되고 이전 기능이 삭제되는 것을 알 수 있습니다.

저는 주요 국가의 케이블 TV 네트워크를위한 대규모 비즈니스 응용 프로그램 교체 작업을 수행했습니다. 새로운 시스템 개발은 SCRUM으로 이루어졌으며, 거의 모든 주요 하위 시스템을 재 구현하기위한 약 18-24 개월의 개발 프로젝트였습니다. 10 살이 다가오고있었습니다.

개발이 시작되기 6 개월 전과 같은 계획 단계가 있었지만 SCRUM으로 접근했습니다. 제품 소유자는 기존 시스템 분석 및 고객 인터뷰 ​​후 고급 상점 및 서사시를 썼습니다.

기존 시스템은 중요한 유지 관리 모드로 전환 될 때 매우 안정적이었습니다. 스토퍼 문제가 수정되었음을 표시하고 기록 목적으로 방금 기록한 모든 내용이 새 시스템에 동일한 문제가 나타나지 않도록합니다.

새로운 시스템은 애자일 프로세스에서 설명한대로 진화했으며 대부분 매우 매끄 럽습니다. 교체 시스템이 기능 부분에 도달하면 생산 단계가 아니라 병렬 생산 시험 단계에 들어갔습니다. 중요하지 않은 작업자의 하위 집합은 두 시스템 을 모두 사용 하여 새 시스템이 이전 시스템과 같은 방식으로 작동하는지 확인했습니다. 물론 오래된 버그가 수정되었습니다.

새로운 시스템이 거의 100 % 새로운 기능을 완성하면 일반 병렬 생산 작업을 위해 출시되었으며 몇 달이 걸렸습니다.

고객이 자신의 요구를 충족시키는 것으로 간주되면 기존 시스템을 백업하고 전원을 끄고 앉았습니다. 이전 시스템 하드웨어를 다시 용도 변경 한 후 이전 시스템으로 되돌릴 필요가 없기 때문에 이전 시스템 하드웨어를 다시 사용했다고 가정합니다.

나는이 시나리오에서 민첩성이 많은 가치를 더한다고 생각합니다.

'현재 시스템 교체'라는 최종 목표가 정해져 있다는 것입니다.

민첩한 기술과 프로세스를 통해 보다 효과적으로 활용할 수 있습니다 .

예를 들어 :

여전히 시스템을 반복적으로 그리고 작은 스프린트로 제공 할 수 있습니다.

핵심 인력과 의사 소통 한 후에도 민첩한 기술을 사용하여 작업의 우선 순위를 지정할 수 있습니다.

애자일을 사용하여 관측 된 속도를 기준으로 계획을 세울 수 있습니다.

지식 확산, TDD, 깨끗한 코딩과 같은 민첩한 기술과 철학을 사용하여 프로젝트의 품질과 내부 디자인을 향상시킬 수 있습니다.

프로젝트에 진정으로 '관심이없는'사람들이 있고 완벽한 교체가 될 때까지 프로젝트에 참여하지 않는 사람들이 있다면 폭포, 민첩성 또는 실제로 어떤 프로세스를 사용하든 더 큰 문제가 있습니다.

동일하게 작동하지만이 방법은 기존 사용자에게 판매하기가 더 어려울 것입니다. 그들은 새로운 시스템을 원하지 않을 수도 있고주기적인 테스트에 참여하기를 원하지 않습니다. 그들은 가능한 한 오래 기다렸다가 결국 테스트하기를 원합니다. 대부분의 사용자는 이런 식으로 어느 정도 느끼지만 교육을 담당하는 사람은 전적으로 사용자에게 달려 있습니다. 그들의 마음에, 당신은 기존의 응용 프로그램과 함께 일하고 있으므로, 당신은 무엇을해야하는지 알고 왜 귀찮게합니까?

재미 있고 폭포 과정을 통해 외로워지기 때문에 이런 식으로하고 싶지 않다는 것을 이해 시키십시오. 장기적으로 더 나은 앱을 만들 것입니다.

핵심 판매 포인트는 항상 원했던 새로운 앱을 구축하는 동안 하나의 변경 사항을 구현하는 것이지만 이전 시스템에서는 결코 얻을 수 없었습니다.

오래 된 녹슬었던 차가 있으면 일을하기 위해 운전해야하고, 대리점에 가서 새 차를 구입합니다. 내가 원했던 모델은 재고가 없어서 공장에서 주문해야하고 들어 오기 전에 약간의 시간이 걸릴 것입니다.

딜러는 선의로 주문한 자동차가 들어올 때까지 자동차 엔진 블록을 제공하기로 결정합니다. 자동차 엔진으로 무엇을해야합니까? 물론 테스트하기 위해 일부 구성 요소를 연결하여 작동시킬 수는 있지만 실제로 오래된 녹슬었던 자동차가 내일 일하는 데 도움이되지는 않습니다.

A는이 부여 까지 차를 구축하고 맞춤형 소프트웨어를 구축하는 사이 다른 울기 만하자의 인수를 위해 그 무시합니다. 이야기의 요점은 당황스럽지 않다. 클라이언트는 이미 작업을 수행하기에 충분한 소프트웨어를 가지고있을 때 증분 변경을 사용하지 않는다. 그것은 이미 한동안 그들의 필요를 채우고 있습니다.

즉, 애자일은 프로젝트 상태에 대해 고객에게 지속적으로 피드백을 제공 할 수 있기 때문에 여기서 중요한 프로세스가 아닙니다. 그들은 주요 이정표와 산출물보다 진보가 이루어 지도록 할 수 있습니다. 수정하기에는 너무 많은 비용이 드는 실수가되기 전에 잠재적 인 문제와 문제를 조기에 식별 할 수 있습니다.

어쩌면 자동차 고객으로서 엔진을보고 평가하여 실제로 예상 한 것을 얻을 수 있는지 확인하고 싶을 것입니다. 죄송합니다. 실제로 4 기통 엔진 대신 6 기통 엔진을 원했습니다! 내가 일찍 말하지 않았어? 문제 없습니다. 공장 주문을 변경하십시오.

새로운 소프트웨어 릴리스를 아직 교체 용으로 사용하지 않고 평가하여 평가하고 각 단계에 만족하는지 확인하는 것이 최선의 이익이된다는 아이디어를 고객에게 판매하십시오.