대규모 시스템 변경 구현 [닫기]

Question

"버릴 것을 하나 만든다"는 말에 익숙하시다면, 글쎄요, 우리는 그렇게 한 것 같습니다.온라인 앱 버전 1의 한계에 도달했습니다.이제 다음과 같이 정리할 시간입니다.

• 코드 및 UI 재구성
• UI 프로세스 통합
• 더 많은 기능 추가
• 미래를 위한 구축
• 위의 모든 사항을 처리하도록 데이터베이스 구조 수정

이러한 전환을 수행하는 가장 좋은 방법은 무엇입니까?

우리는 모든 사용자를 새로운 시스템에 넘겨주는 것을 피하고 싶습니다(완료된 후).그들은 겁에 질렸고 우리는 통화량을 감당할 수 없었습니다.우리 사용자는 기술적으로 능숙한 소프트웨어 작성 유형부터 HTML이 무엇인지 모르는 사용자까지 다양한 범위를 사용합니다.

시스템의 새로운 "설치"를 시작하고 이 새로운 디자인이 버전 1의 문제를 충분히 해결한 후에 사용자를 점차적으로 시스템으로 옮겨야 할까요?

(어떻게든) 시스템의 각 모듈을 점진적으로, 단계적으로 변경해야 합니까?데이터베이스 레이아웃이 변경되어 "핵심 코드"와 여러 주변 모듈의 코드를 조정해야 하기 때문에 이는 어려울 수 있습니다.

최첨단 버전의 앱을 사용하는 신뢰할 수 있고 참을성 있는 "베타 테스터" 클라이언트 세트를 보유하는 것이 일반적입니까?(여기서의 목표는 피드백을 받고 새로운 시스템에서 버그를 테스트하는 것입니다)

다른 조언은 없나요?직접 경험?

Answer 1

대답은 상황에 따라 다르다는 것 같습니다.이는 애플리케이션의 종류와 사용자의 종류에 따라 다릅니다.시스템이 무엇인지, 버전 변경 범위가 무엇인지 모르면 답변을 드리기 어렵습니다.

즉, 몇 가지 경험 법칙이 있습니다.

첫째, 빅뱅 발사를 피하십시오.시스템을 시작하면 문제가 발생합니다.업계에는 사람들이 뱅뱅 출시가 좋은 아이디어라고 생각했지만 초기 문제로 인해 출시가 중단되었다고 생각하는 프로젝트가 가득합니다. 쿠일 최근 빅뱅 출시의 세간의 이목을 끄는 인과관계가 있었습니다.

초기 문제를 관리 가능하게 만들려면 처음에는 소수의 사용자로 작업한 다음 천천히 사용자 수를 늘려야 합니다.

둘째, 꼭 해야 할 일은 반드시 적극적으로 해야 한다는 것입니다. 사용자를 최우선으로 생각하라.사용자는 시스템의 V2를 사용하기 위해 가능한 최소한의 작업을 수행해야 합니다.이상적인 작업량은 0입니다.

즉, 한 시스템에서 다른 시스템으로 사용자를 천천히 마이그레이션하기로 선택한 경우 너 모든 데이터와 설정이 마이그레이션되었는지 확인할 책임이 있습니다.예를 들어, 사용자에게 2008년 12월 9일 이전의 모든 레코드에는 V1을 사용하고 이후의 모든 레코드에는 V2를 사용해야 한다고 말하는 것과 같은 어리석은 짓을 하지 마세요.

V2 출시의 목적은 사용자의 삶을 불필요하게 더 어렵게 만드는 것이 아니라 사용자의 삶을 더 쉽게 만드는 것이어야 합니다.

셋째, 베타 프로그램을 가지고 있습니다.이는 인트라넷 애플리케이션에도 적용됩니다.응용 프로그램을 개발하는 것은 다항식의 근을 찾는 Newton-Raphson의 방법과 매우 유사합니다.사용자가 원하는 것이 무엇인지 추측하고 이를 사용자에게 전달하면 사용자는 피드백을 제공하고 느리지만 확실하게 각 반복을 통해 문제의 해결 방법에 더 가까워집니다.

베타 프로그램을 사용하면 사람들이 변경 사항에 대해 언급할 시간도 없이 새 버전을 떠맡는 것보다 훨씬 빠르게 루트를 찾을 수 있습니다.베타는 사용자를 더 일찍 참여시키고 프로세스에 포함된 느낌을 갖도록 도와줍니다.그 중요성은 아무리 강조해도 지나치지 않습니다.

Answer 2

우리는 방금 사용자에게 새로운 CRM 시스템 구축을 마쳤으며 그런 식으로 수행하는 것은 끔찍한 아이디어였다고 말씀드리고 싶습니다.이는 우리 팀과 고객 모두에게 매우 고통스러운 일이었습니다.

더 많은 작업을 수행하더라도 점진적인 릴리스를 수행하기 위해 가능한 모든 수단을 동원하겠습니다.모든 것을 옮기기 위해 엄청난 노력을 기울일 필요가 없기 때문에 감사하게 될 것이며 고객은 한 번에 조금씩 제품을 소개받을 수 있는 능력에 감사할 것입니다.

도움이 되었기를 바랍니다!

Answer 3

나는 동의한다 에스테반 점진적인 릴리스가 가장 좋습니다.집을 리모델링하는 것과 같습니다.처음에는 그것을 끝내는 것이 좋은 생각인 것 같습니다.하지만 모든 것을 미리 계획하고 계약자를 고용하고 이사해야 함을 의미합니다.그러면 계획에 뭔가가 변경되거나 계약자가 사라지고 저장하려고 했던 모든 시간이 사라져 버립니다.한편, 점진적인 변화는 모든 사람에게 단계 사이에서 멈추고 생각할 기회를 제공합니다.때로는 이전 변경 사항이 계획한 것보다 더 잘 작동하는 경우 나중에 변경 사항을 피할 수 있습니다.

저는 큰 스케일링 문제가 있는 시스템을 작업하고 있습니다.우리는 필요하다고 생각되는 모든 변경 사항의 목록을 작성하고 예상되는 영향에 따라 우선순위를 지정했습니다.그런 다음 한 번에 하나씩 변경하기 시작했습니다.목록의 중간쯤에서 우리는 크기 조정 문제를 해결했음을 발견했습니다.아직 목록이 있지만 완료할 필요가 없을 수도 있습니다.자유롭게 기능을 추가하고 다른 문제를 해결할 수 있습니다.

물론, 총탄을 깨물고 모든 것을 무너뜨리는 것이 가장 좋은 경우도 있습니다.그러나 그것은 사람들이 믿는 경향보다 훨씬 덜 일반적입니다.그리고 중요한 운영 시스템의 경우 "폐기" 결정은 치명적일 수 있습니다.모두가 동의하는 대규모 정부 프로젝트를 현대 컴퓨팅 시대에 도입해야 하지만 일부 중요한 서비스가 손실될 수 있기 때문에 그렇게 할 수 없는 경우를 살펴보십시오.철학이 점진적인 변화였다면 아마도 하나씩 현대화해갔을 것이다.

Answer 4

처럼 들린다 증분 아키텍처 재구축 당신이 선택한 민첩한 유행어가 되어야 합니다.

저는 웹 애플리케이션에서 이 작업을 수행한 적이 없지만 점진적으로 수행되는 상당히 급진적인 클라이언트 애플리케이션 변경을 겪었습니다.작업 조각이 상당히 합리적인 방식으로 순서가 지정되었는지 확인하기 위해 약간의 시간을 미리 투자하면 잘 작동할 수 있습니다.좋은 리팩토링 지원 도구가 아직 없는 경우 작은 투자를 하면 큰 도움이 될 것입니다.개인적으로 추천드릴 수 있어요 jetBrains 리샤퍼 .NET을 사용하고 있고 Java 기반이라면 IntelliJ IDEA에 유사한 기능이 포함되어 있다고 생각합니다.