음, 귀하의 질문에 직접 대답이 될 것이다 뮤 난 두려워 – 당신이 또는 시도 종료 할 것인지 여부 정보통 추측을하기에 충분한 세부 사항이 바로이 아니다.

내가 매우 긍정적으로 생각하는 것은 민첩성 수준이 고객 / 시장 요구 (정보를 제공하지 않은)에 의해 주도되어야한다는 것입니다.

• ^{예를 들어, IDE 사용자로서 일년에 한 번 또는 두 번 새 버전으로 업그레이드하는 것이 매우 기쁩니다. 결코 그렇게 서두르지 않습니다. 즉, 릴리스주기가 3 개월 ( 12 주 )이면 완벽하게 만족합니다.
   
  반면에, 금융 거래 회사가 소프트웨어가 시장 변화에 적응하는 데 한 달 이상이 걸리면 파산한다고 쉽게 상상할 수 있습니다 .이 경우 12 주 테스트주기는 지옥으로가는 길입니다. 이제이 점에서 귀하의 제품은 무엇입니까?}

고려해야 할 또 다른 사항은 고객 / 시장 요구를 충족시키기 위해 어떤 수준의 품질이 필요합니까?

• ^{예를 들어, 내가 한 회사에서 소프트웨어 공급 업체로부터 라이센스를받은 제품에 새로운 기능이 필요하다는 것을 알았습니다. 이 기능이 없다면 우리는 오히려 강하게 고통을 겪었습니다. 그래서 우리는 그들이 민첩 하고 한 달 안에 업데이트를 제공 하기를 정말로 원했습니다 .
   
  그리고 예, 그들은 민첩한 것처럼 보였습니다. 그리고 그들은 한 달에 그 업데이트를 발표했습니다 (QA주기가 12 주라면 그냥 건너 뛰었을 것입니다). 그리고 우리의 기능 은 완벽하게 작동했습니다-우리가 완벽하게 행복했을 것 같아요? 아니! 우리는 이전에 잘 작동했던 일부 기능에서 showtopper regression 버그를 발견했습니다. 그래서 우리는 이전 버전을 고수해야했습니다.
   
  또 다른 달이 지났습니다-그들은 또 다른 새로운 버전을 출시했습니다 : 우리의 기능동일한 회귀 버그가 있었지만 다시 업그레이드하지 않았습니다. 또 다른 달과 다른 달.
   
  결국 우리는 반년 만에 민첩성으로 업그레이드 할 수있었습니다.}

자, 언급 한 12 주에 대해 조금 더 자세히 살펴 보겠습니다 .

품질 관리주기를 단축하기 위해 어떤 옵션을 고려 했습니까? 당신은 위의 예에서 볼 수 있듯이, 단순히 당신이 더 나은 그래서, 음, 기대를 포기하지 않을 수 있습니다 건너 뛰는 민첩 하고 고려 다른 그것을 해결하는 방법을.

예를 들어, 제품의 테스트 가능성 을 향상시키는 방법을 고려 했 습니까?

아니면 더 많은 QA를 고용하기 위해 무차별 대입 솔루션을 고려 했습니까? 그러나 간단하게 보이지만 어떤 경우에는 실제로 갈 길입니다. 경험이 부족한 경영진이 평균 적인 전문 테스터만으로도 점점 더 많은 수석 개발자를 맹목적으로 고용함으로써 제품 품질 문제를 해결하려는 것을 보았습니다 . 한심한.

마지막이지만 최소한은 아닙니다- 민첩한 원칙의 적용에 대해 민첩 해야한다고 생각합니다 . 프로젝트 요구 사항이 민첩하지 않거나 (안정하거나 느리게 변경되는 경우) 왜 귀찮게합니까? 나는 한 번도 완벽하게 잘하고 있던 프로젝트에서 최고 경영진이 Scrum을 강요하는 것을 보았습니다. 정말 낭비였습니다. 전달 기능이 향상되었을뿐만 아니라 개발자와 테스터 모두 불행하게되었습니다.

의견에 제공된 설명을 기반으로 업데이트

나를 위해, 애자일의 가장 중요한 부분 중 하나는 각 스프린트가 끝날 때 배송 가능한 석방 물을 가지고 있습니다. 그것은 몇 가지를 의미합니다. 먼저, 고객에게 빌드를 공개 할 수 있다고 생각되는 경우, 버그가 발생하지 않도록 테스트를 수행해야합니다.

배송 가능한 릴리스 입니다. 흠. 흠. 민첩한 칵테일 에 린 (Lean) 을 한 두 번 더하는 것을 고려하십시오 . 이것이 고객 / 시장 요구가 아니라면 (테스트) 자원 낭비 만 의미합니다.

나는 스프린트-엔드-릴리스를 팀을 만족시키는 몇 가지 체크 포인트 로 취급하는 데 범죄가 없다고 본다 .

• ^{dev : 네, 테스터에게 전달하기에 충분히 좋아 보입니다. QA : 예. 추가 배송 테스트가 필요한 경우에는 그 경우에 적합합니다 . 팀 (dev + QA)이 만족입니다.}

요구 사항이 민첩하지 않은 경우 민첩성을 적용하지 않는 측면에서 응답이 끝났을 때 가장 중요했습니다. 나는 이것이 자리에 있다고 생각합니다. 우리가 민첩하게 일을 시작했을 때, 우리는 전화를 걸었고 상황이 합리적이었습니다. 그러나 그 이후로 상황은 극적으로 변화했으며 더 이상 의미가없는 프로세스에 집착하고 있습니다.

정확히 맞았습니다. 또한 설명 한 내용에서 상태 (팀 / 관리 성숙도 및 고객 관계)에 도달 한 것처럼 보이므로 Scrum 대신 정기적 인 반복 모델 개발 을 사용할 수 있습니다 . 그렇다면 정기적 인 반복 과 같은 경우 내 경험에 따라 Scrum보다 생산성이 높았다는 것을 알고 관심을 가질 수도 있습니다 . 훨씬 더 생산 – 단순히 거기 때문에 훨씬 적은 오버 헤드, 단순히 너무 쉽게 (각각에 품질 보증을위한 테스트에 초점) 개발에 집중했다.

• ^{나는 보통 페라리 (정기 반복)와 랜드 로버 (스크럼)의 관점에서 생각합니다 .
   
  고속도로에서 운전할 때 (그리고 프로젝트가 해당 고속도로에 도달 한 것처럼 보임) 페라리는 Landrover에서 지옥을 이겼습니다.
   
  스포츠카가 아닌 지프가 필요한 오프로드입니다. 요구 사항이 불규칙하거나 팀워크 및 관리 경험이 좋지 않은 경우 스크럼을 선택해야합니다. 붙어-페라리는 오프로드에 붙어 것입니다.}

우리의 전체 제품은 실제로 독립적으로 업그레이드 할 수있는 많은 작은 부품들로 구성되어 있습니다. 고객은 이러한 작은 구성 요소를 훨씬 더 자주 업그레이드하려고합니다. 스프린트가 끝날 때 작은 구성 요소를 출시하고 QA하는 데 집중해야 할 것 같습니다.

위의 계획은 좋은 것 같습니다. 나는 그런 프로젝트에서 한 번 일했다. 우리는 매월 릴리스를 작은 위험이 적은 구성 요소에 국한된 업데이트와 함께 제공 했으며 그에 대한 QA 사인 오프는 쉽게 얻을 수있었습니다.

• ^{이 전략에 대해 명심해야 할 한 가지는 변경이 예상되는 곳에 현지화되어 있음을 테스트 할 수있는 검증하는 것입니다. 변경되지 않은 구성 요소에 대한 비트 단위 파일 비교에 이르기까지 갔다가 가지 않으면 선적하지 못할 것입니다. 우리 개발자가 아닌 릴리즈 품질을 책임지는 것은 QA입니다.
   
  예상치 못한 변경 사항이 발생하지 않도록하는 것은 테스터의 골치 아픈 일입니다. 솔직히 개발자에게는 걱정할만한 다른 것들이 더 중요하기 때문에 더 중요합니다. 그리고 그로 인해 (테스터) 는 테스트 후 출시로 상황이 통제되고 있다는 확실한 증거 가 실제로 필요합니다 .}

답변