애자일 방법론을 사용하여 소프트웨어 재 작성

Agile 방법론을 사용하여 전체 애플리케이션을 다시 작성해야한다고 가정 해보십시오.

현재 시스템의 동작에 따라 많은 사용자 스토리를 작성할 수 있다고 생각합니다. 그런 다음 작은 반복으로 구현하십시오. 그러나 이것이 우리가 UP FRONT 요구 사항을 가지고 있다는 것을 의미하지는 않습니다 ??

또한 언제 출시를 시작 하시겠습니까? 애자일은 초기에 자주 릴리스해야한다고 말했지만 완전한 재 작성이 완료되기 전에 릴리스하는 것은 의미가 없습니다.

높은 수준의 서사시로 분류하십시오. 응용 프로그램의 각 기능 영역을 한 번에 한 단계 씩 수행하십시오.

하나의 서사시를 스토리 그룹 (사용 가능한 청크-응용 프로그램을 향상시키는 것)으로 나누고 기존 응용 프로그램이 없었던 경우와 같이 한 가지 예외를 제외하고는 원하는대로 관리하십시오. 하나의 기능을 원래 응용 프로그램의 일부 또는 원본 응용 프로그램과 함께 구현할 수 있습니다.

애질리스트가 "일찍 자주 출시"한다고 말할 때 반드시 생산을 의미하는 것은 아닙니다. 기존 애플리케이션을 교체하려는 경우 스테이징 영역을 사용하여 자주 릴리스하고 사용자가 시스템을 테스트하고 있는지 확인해야합니다. 이렇게하면 다음 작업의 우선 순위를 정하고 생산을 위해 릴리스 된 제품이 제품을 감가 상각하지 않도록해야합니다.

하나의 컴포넌트를 프로덕션에 릴리스 한 후 다음 컴포넌트로 이동하십시오.

우리는 방금 그러한 경험을 얻었습니다 (나의 스크럼 제품 소유자). 뭔가 풀어 놓기까지 2 년이 걸렸습니다. 그러나 여전히 민첩성은 많은 이점을 가져 왔습니다.

첫째 : 완전한 재 작성은 본질적으로 민첩하지 않습니다. 대신 기존 제품을 개별적으로 리팩토링하는 것을 고려해야합니다. 그것은 또 다른 질문에서 논의되었습니다. 다시 작성해야한다고 가정 해 봅시다.

그런 다음 기존 제품의 모든 관련 사용 사례를 다루는 백 로그로 시작합니다. 그러나 작성 사양으로 접근하지 마십시오. 너무 자세한 내용입니다. 완료되어야합니다 (그렇지 않으면 릴리스 계획을 수행 할 수 없음). 그리고 너무 정교해서는 안됩니다 (그렇지 않으면 사양을 미리 작성하십시오). 우리가 접근 한 방법은 다음과 같습니다.

• 이전 제품의 사용자를 분류하십시오. 기존 제품의 일부만 필요한 사용자를 식별하고 여전히 유용한 제품을 찾으십시오. 그들은 첫 서사시를 정의합니다.

• 그런 다음 다른 범주의 사용자가 새 제품으로 이동할 수있는 서사시를 추가하십시오. 모든 사용자를 포함하는 백 로그가있을 때까지

• 이 서사시들은 더 나눌 필요가있을 것이다. 가능하면 각 부분에 여전히 가치가 있도록 분할하십시오. 그것이 가능하지 않다면 적어도 각 부분을 보여줄 수 있는지 확인하십시오.

• 20-50 개의 서사시를 가지고있을 때, 팀이 그것들을 평가하도록하십시오.

• 스프린트 내에서 팀이 실현 가능하다고 생각하는 최고 스토리를 User Stories로 나눕니다. 아직 모든 서사시에는 그렇게하지 마십시오. 나머지를 나누는 데 충분한 시간이 있습니다.

외부 출시시기! 그것은 사업 결정입니다. 최소한이 방법을 사용하면 특정 사용자 범주에 대해 조기에 릴리스 할 수 있습니다. 경영진이 결코 끝나지 않는이 프로젝트에 대해 신경이 쓰이면 편리 할 수 ​​있습니다.

가능한 경우 지금 출시

언제 코드 릴리스를 시작해야하는지에 대한 귀하의 질문은 큰 것입니다. 나는 두 가지 조항이 적용된다고 생각합니다. 첫째, "충분한 품질"을 유지하고 둘째, MVP (최소 실행 가능 제품)에 대한 요구 사항을 충족해야합니다.

로마 (그리고 민첩한)는 하루에 지어지지 않았다

턴키 애자일 팀과 함께 첫날을 인수 할 준비가되었을 수도 있습니다. 대부분의 조직에는 훈련, 개편 및 팀을 구성하는 일반적인 형성, 폭풍, 규범, 수행주기에 따른 작업과 비용이 있습니다. 위험과 비용에 대해 우선적으로 생각하고 현실적인 기대치를 설정하고주의를 기울여 접근 방식을 옹호 할 준비를하십시오.

재사용 부트 스트 래퍼가 되십시오

융합 능력과 마찬가지로 코드 재사용은 항상 우리의 경제 문제에 대한 미래의 해결책 이 될 것 입니다. 필자는 개발자들이 종종 재사용을 믿는다 고 말하지만 다른 사람이 이미 한 일을 바탕으로하는 것보다는 새로운 프레임 워크를 구축 한 후에 시작되는 재사용 만 할 뿐이라고 생각합니다. 누군가가 다른 사람의 기초를 기꺼이 세우기로 결정할 때까지 어떻게 작동 할 수 있습니까? 기껏해야 팀 리더십이 바뀔 때마다 몇 년마다 다시 작성해야합니다.

왜 조기에 출시해야합니까?

여러 가지 이유로 조기 출시가 종종 만트라입니다. 그것은 제품이되어야하는 것에 대한 우리의 토론에 생명을주고, 우리가 어디에 있는지를 현실화하며, 반복 / 증분 변화의 기초를 제공합니다. 릴리스 속도는 애자일에게는 거의 변하지 않으며 릴리스를받는 사람 (고객 대리 또는 최종 사용자)이 다릅니다. 민첩하기 전에 유지 관리는 소프트웨어 시스템 비용의 60 %를 차지하는 것으로 추정되었습니다. 이것은 관리자 및 다른 사람들에게 많은 혼란의 원천이며 일부는 제품 릴리스가 소프트웨어가 죽는 곳이라고 생각합니다. 그들에게 릴리스 이후의 모든 것은 재 작업과 이미 지불 한 제품을 고치기 위해 지불하는 것입니다.

시험판은 부자연 스럽다

켄트 벡 (Kent Beck)은 시험판은 소프트웨어 제품의 부 자연스러운 상태라고 말합니다. 고객이없고 지불하는 제품이 아닌 제품에 대해 지불하는 시간이기 때문에 확실히 불편한 시간입니다.

이전 팀을 비판하지 마십시오

프로젝트의 영웅이자 구원으로 다시 쓰기를 담당하는 개발자를 구성 할 수는 있지만 이전 팀의 성과를 비판하는 데 비용이 든다고 생각합니다.

• 첫째, 사람들이 이전 팀에 대해 자신의 마음을 갖도록하면 실제 임무에 더 많은 시간과 에너지가 있습니다.
• 제품 관리자, 프로젝트 관리자 또는 고객과 같은 이해 관계자뿐만 아니라 이전 팀의 구성원과 함께 작업해야하는 경우 어색합니다.
• 당신이 그것을 작동시킬 수 있다면, 당신은 이전 팀이 한 일에 대해 신용을 얻거나 더 나쁘게 받아 들일 수 있습니다.
• 평균적으로 이전 팀은 평균이었습니다. 평균적으로 평균 일 수 있습니다. 프로젝트 외에 새로운 방법론을 적용하기 때문에 이전 팀보다 더 많은 작업을 수행 할 수 있습니다.
• 이전 팀이 끔찍한 경우에도 너무 끔찍하지 않으면 결국 끔찍한 것보다 더 나은 것으로 인정받을 것입니다. 그들이 끔찍한 것보다 낫고 눈에 띄게 나쁘지 않다면, 끔찍하다고 말하면 불쾌한 비교를 불러 일으킬 수 있습니다.
• 이전 팀이 생각했던 것보다 낫고 조직이 부서 지거나 문제가 잘못 정의되었거나 매우 어렵 기 때문에 문제가 발생하면 기대치를 크게 올리지 않으면 상황이 나아질 것입니다.
• 그들이 얻는 것을 기대하지만 더 잘하면, 그것은 당신에게 승리입니다.
• 비판을 자제하는 것은 좋은 태도이며, 수업이 있다는 것을 보여줍니다.

@Chuck의 의견과 Netscape에 대한 언급은 본질적으로 다시 쓰지 않는다는 말과 OP가 자신이해야하는지 묻지 않는다는 사실에 대한 유효한 답변입니다. -진정으로 민첩한 소프트웨어 개발 주기로 재 작성이 불가능합니다. 재 작성은 거의 항상 애자일의 많은 원칙을 위반합니다. 현재 소프트웨어를 기준으로 사용하면 이러한 Agile 원칙 ( Agile Manifesto의 )을 다시 작성할 수 없습니다.

• 귀중한 소프트웨어를 조기에 지속적으로 제공합니다 . -고객은 이미 가지고있는 것에 대해 측정했을 때 초기 가치를 얻지 못합니다
• 몇 주에서 몇 달 사이에 작업 소프트웨어를 자주 제공 하면 프로젝트 규모가 커지므로 고객은 언제든지 더 유용한 정보를 얻을 수 있다고 정직하게 말할 수 있습니다.
• 작업 소프트웨어는 진행의 주요 척도입니다 . 기준과 비교하여 작업은 서두르지 않습니다.
• 민첩한 프로세스는 지속 가능한 개발을 촉진합니다. -고객에게 작업 기준이 있다면 개선 된 기능을 제공해야한다는 압박이 가중 될 것입니다. 이것은 지속 가능한 속도로 수행되지 않을 것입니다
• 완료되지 않은 작업량을 최대화하는 기술인 단순성은 필수적입니다. 이 모든 것을 정말 말합니다 ...

"애자일 방법론을 사용하여 전체 응용 프로그램을 다시 작성해야한다고 가정 해보십시오."

이 질문은 잘못된 전제에 기초하고 있습니다. 다시 쓰기는 민첩한 것으로 간주 될 수 있습니다.

다시 작성된 응용 프로그램을 한 번에 하나씩 해제하여 이전 응용 프로그램과 나란히 프로덕션 환경에 둘 수 있는지 고려하십시오.

특히 웹 응용 프로그램의 경우 응용 프로그램의 한 부분을 새로운 플랫폼으로 옮기고로드 밸런서가 요청을 적절한 시스템으로 라우팅하는 것이 매우 쉽습니다. 그런 다음 첫 페이지를 제작하여 민첩하게 전달할 수있는 기사를 작성하십시오.

데스크톱 응용 프로그램은 더 복잡 할 수 있지만 종종 가능할 수도 있습니다.

기존 시스템이 완전히 다시 작성하지 않고도 새로운 시스템이 책임을 맡을 수있는 이음새를 찾고 있습니다.

아마도 새로운 웹 서비스 나 프레임 워크로 옮길 수있는 자체 포함 된 비즈니스 로직이있을 수 있으며, 기존 앱은 기존 코드 대신이를 사용하여 수정 될 수 있습니다. 남은 것이 한 번에 모두 관리 할 수있을 때까지 이음새에서 덩어리를 조각하십시오.

이음새를 찾을 수 없으면 실제로 다른 답변에서 제안 된 종류의 빅뱅 접근 방식을 찾아야 할 수도 있습니다. 그러나 목적지에 도착하기 전에 긴 행진을 준비하십시오. 특히 오래된 시스템을 계속 병렬로 개발 해야하는 경우 ...

애자일은 초기에 자주 릴리스해야한다고 말했지만 완전한 재 작성이 완료되기 전에 릴리스하는 것은 의미가 없습니다.

실제로 IMHO는 이것이 핵심 포인트입니다. 프로덕션에서 재 작성된 응용 프로그램의 일부를 더 빨리 얻을 수 있고 (구형 시스템의 기능을 이상적으로 대체할수록) 프로젝트가 성공할 가능성이 커집니다. 이것이 의미가 없다고 생각하면 더 열심히 생각하십시오-부품을 출시 할 가능성은 거의 항상 있습니다.

예를 들어, 재 작성이 완료되지 않은 시간에 재 작성된 응용 프로그램과 상호 작용하기 위해 일부 새로운 인터페이스를 추가하는 등 누군가 이전 응용 프로그램에서 무언가를 변경해야한다는 의미 일 것입니다. 그러나 내 경험에 따르면 그러한 추가 작업은 항상 비용을 지불합니다.

새 애플리케이션의 첫 번째 부분이 프로덕션 환경에 있으면 민첩하고 반복적 인 접근 방식이 분명해집니다. 요구 사항이 변경되고, 사용자 사례가 변경되거나 새로운 우선 순위가 부여되며, 기존 시스템의 점점 더 많은 기능이 작은 단계로 대체되기를 바랍니다.