너무 급격한 변화의 비용을 어떻게 처리합니까?

대부분의 현대 개발자와 마찬가지로 고객 협업 및 변화에 대응하는 애자일 원칙을 중요하게 생각하지만 제품 소유자 (또는 요구 사항 및 우선 순위를 결정하는 사람)가 요구 사항 및 우선 순위를 너무 자주 변경하면 어떻게됩니까? 하루에 여러 번처럼?

나는 최근에 버그가 많고 불완전한 작은 코드 기반을 물려 받았으며, 가장 간단한 시나리오도 처리 할 수 ​​없었습니다. 기술적 인 문제를 처리 할 수 ​​있지만 "OMG 지금 당장 작업해야합니다! 최우선 순위! 이것은 필수 항목입니다!" 더 나쁜 것은 대부분의 일이 소프트웨어가 실제로해야 할 일과 관련이없고 어쨌든 구현하는 데 며칠이 걸리는 사소한 세부 사항이라는 것입니다. 시간이 얼마 남지 않았고 가장 중요한 것들에 먼저 초점을 맞춰야한다고 설명했지만, 하루나 이틀 후에 같은 일이 일어났기 때문에 번역에서 무언가가 잃어버린 것 같습니다.

낭비되는 양을 줄이거 나 적어도이 혼란스러운 행동의 비용을 설명하는 데 도움이 될 수있는 일종의 Product-Owner-Handler 역할, 심도있는 연구, 은유 또는 인용이 있습니까?

이것이 백 로그의 목적입니다. 새로운 요청은 백 로그에 저장되며 우선 순위는 반복 경계에서만 변경 될 수 있습니다. 평균 1 주일 지연 (2 주 스프린트의 절반)은 가장 심각한 응급 상황을 제외한 모든 상황을 처리 할 수있을 정도로 민첩합니다.

비슷한 문제를 다루는 방법은 다음과 같습니다. 애자일 이전에 민첩했던 시절로 거슬러 올라갑니다.

모든 변경 요청에 대해 고객이 우선 순위를 설정합니다. 개발자는 우선 순위가 높은 작업을 수행하기 위해 작업에 대한 작업 만 중지 할 수 있으며 중지해야합니다. 우선 순위가 동일한 작업은 도착 순서대로 진행됩니다. 작업이 시작되면 작업 우선 순위를 변경할 수 없습니다.

최근 요청과 우선 순위가 같은 중요하지 않은 작업 X에서 작업하고 있기 때문에 고객에게 자신의 작업을 수행 할 수 없다고 말하면 문제가 발생합니다. 그런 다음 해당 우선 순위 수준에서 최근 요청보다 50 개의 사소하고 중요하지 않은 작업이 있다고 말합니다. 이제 진짜 캐치-이 모든 작업은 우선 순위 수준 1 (가장 높음)에 의해 설정됩니다 ... HIM ... 그래서 그는 당신이하고있는 작업에서 당신을 부딪 칠 수 없습니다. 이제, 거의 사용하지 않는 구성 옵션에서 아이슬란드 어 번역에서 더 긴 단어를위한 공간을 만들기 위해 창 프레임을 3 픽셀 왼쪽으로 이동 한 후 .....

또한 SD 사무실 문을 닫고 잠그고 전화기를 꺼 냈습니다. 이메일은 오전 10시, 오후 12시 및 오후 2 시까 지 무시되었습니다. 사람들이 생각하고 느낀 것에도 불구하고, 세상은 여전히 ​​태양 주위를 돌아 다녔고, 우리는 우리의 작업을 완료했으며 "고객"은 과거 어느 때보 다 더 빠르고 더 나은 소프트웨어를 제공했습니다.

우선 순위가 더 현실적인 것으로 정착하는 데 몇 주가 걸렸고, 우리는 문 등을 열 수있었습니다. 그러나 시스템은 꽤 오랫동안 남아있었습니다. 그렇게 극단적 일 필요는 없으며 (우리가 한), 고위 경영진의 지원이 필요합니다. 그러나 작동합니다 ....

예규. 표준 운영 절차 (또는 최소한 관리 팀에서 서명 한 느슨한 프로토콜). 부서는 하나를 개발하거나 관리 팀과 협력하여 하나를 개발해야합니다. 대화해야 할 사람들이 제품 소유자 / 계정 관리자보다 위에 있습니다.

SOP가 정의해야하는 몇 가지 예.

• 고객 또는 내부 기관이 변경을 요청할 때 따라야 할 절차
• 이 제품의 품질 관리 또는 검증에 미치는 영향 및 / 또는 영향은 무엇입니까?
• 배송 기간을 합리적으로 결정하는 방법은 무엇입니까? 이 반복? 다음 버전?

이러한 절차가 없으면 모든 사람들이 좀비에게 쫓기고 지금 당장 모든 것을 기대하는 것처럼 당신을 향해 달려갑니다. 그런 사람들은 당신의 예의 '아니오'또는 '기다려주십시오'를 존중하지 않습니다. 확고한 정책이 확립되면, 이러한 코드 갈망 돌연변이 체는 그러한 느슨한 기초를 요구할 때 그들이 잘못되었다는 것을 이해할 것입니다.

최종 결과는 당신에게 불행하며, 그것은 당신의 회사에 가장 큰 관심사가 아닙니다.

참고로, 당신은 자신의 위치와 의무에 대한 그러한 뻔뻔한 무례 함으로 인해 누군가의 혼란을 물려 받았을 것입니다. 그런 상황에 처한 사람들은 양질의 제품을 생산하기가 어렵다는 경향이 있습니다. 궁금해? 소프트웨어 공학 101.

이러한 "준비, 발사, 조준"조건에서 작업하는 것은 매우 어렵습니다. 매우 안전하지 않은 사람으로부터 요구 사항을 받고있는 것처럼 들립니다. 높은 사람이 개념적인 아이디어를 제안 할 때마다 의견이 바뀝니다.

이러한 상황에서 이메일에 응답하기 전에 적어도 한 시간을 기다리는 것이 중요하다는 것을 알았습니다. (문자 메시지가 조직 전체의 이메일을 대체하지 않는 한 텍스트를 무시합니다.) 아마도 읽을 수는 있지만 응답하지는 않습니다. 이렇게하면 내일 부적절 할 수있는 임의의 긴급 상황에 대한 논의 나 나중에 2 ~ 3 개의 이메일에 대한 논의가 아니라 실제 필요한 업무에 집중할 수 있습니다. 마지막 직장에서 정말 긴급한 일이 있다면, 아직 이메일을 보지 못했다고 가정하고 누군가가 나와 직접 대화를 나 would을 것입니다. 동등한).

대면 또는 전화 대화를 할 때 상대방이 자신의 말로 요청한 내용을 반복 한 다음 새로운 요구 사항 및 우선 순위에 대한 질문을하는 것이 좋습니다. "정확히 이해한다면 현재 최고 우선 순위 X에 대한 작업을 중단하고 이제 우선 순위 Y 우선 순위에 집중해야한다고 말하고 있습니다. 큰 변화입니다. 비즈니스 변화에 대해 설명해 주시겠습니까? 더 많은 배경이 필요할 수 있습니다. 청구 또는 인벤토리와 같은 다른 비즈니스 프로세스에 변경이 있을까요?이 새로운 데이터 요소가 모든 월별 보고서에 나타날 것으로 예상합니까? " "이 새로운 노력을 계속하면 현재 최우선 순위 X의 출시가 적어도 (주, 월,

긴급 상황 인 경우 요청자는 이러한 종류의 질문에 대답하거나 즉시 다른 사람에게 문의 할 수 있어야합니다. 긴급 상황이 아닌 경우, 이런 종류의 대화는 요청자가 더 많은 정보를 얻을 필요가 있다는 점을 감안하여 요청자가 속도를 늦추고 변경이 실제로 얼마나 중요한지를 결정하게합니다. 종종 파이프에 이미있는 것이 더 중요하거나 적어도 그만한 가치가 없다는 것을 알게 될 것이며 새로운 요청이 목록에 올 수 있습니다.

변경 사항이 필요하다고 판단되면 요청한 사항과 변경 사항에 대한 이해를 이메일로 작성하여 변경 사항에 동의하는지 묻는 요청을 원래 요청자에게 보내는 것이 좋습니다. 다시 설명으로. 이 방법으로 현재 상위 우선 순위 X에서 더 이상 작업하지 않는 이유 또는 원래 기한이 지체되는 이유를 설명해야하는 경우 수행해야 할 사항 및 요청 이유에 대한 문서를 작성했습니다. 만나야합니다.

지식을 입증하고 원하는 작업을 수행하고 있지만 변경하는 데 정직한 태도를 취하고 있기 때문에 요청자와의 관계를 개선해야합니다. 요청에 대해 자세하게 질문함으로써, 그들은 당신이 미리 생각하고 원래 가지고 있지 않은 것들을 고려한다는 것을 알게됩니다.

아직 아무도 언급하지 않은 것 같습니다. 스프린트 와 사용자 스토리 ideally should be locked till the next sprint(일반적인 스프린트는 2-4 주가 소요됩니다). 잠그면 이미 시작된 Sprint에 추가 작업을 추가하지 않아야합니다.

사용자 스토리가 스프린트에 맞지 않을만큼 충분히 크면 스프린트 중에 달성 할 수있는 더 작고 달성 가능한 작업으로 분류하십시오. 또한 언급했듯이 우선 순위가 지정된 작업조차도 백 로그에 보관해야 하며 다음 스프린트 계획 중에 우선 순위가 높은 플래그를 한 번 올리십시오. :)

편집 : 봄 동안 사소한 변경 만 도입 할 수 있습니다. 그들이 비상 상태를 가지고 있다면. 그러나 스프린트 중에 항상 몇 가지 응급 상황이 발생하면 스프린트 계획 자체에서 무언가 변경해야합니다.

스크럼은 언급 한 문제를 해결해야 할 사람이 될 스크럼 마스터 역할을합니다.

책임이있는 팀장, 프로젝트 관리자, 스크럼 마스터 등과 같은 사람이 있다면 그 사람과 대화 할 것입니다.

시간이 얼마 남지 않았고 가장 중요한 것들에 먼저 초점을 맞춰야한다고 설명했지만, 하루나 이틀 후에 같은 일이 발생하기 때문에 번역에서 무언가가 잃어버린 것 같습니다.

나는 당신이 계속해서 그것을 계속해서 설명해야한다고 생각합니다. 함께 일하는 특정 사람들에게 도움이되지 않는 습관이 있다는 것을 받아 들여야 할 것 같습니다. 운이 좋으면 결국 변화가 나타납니다.

애자일 선언문 은 가장 기본적인 교장 중 하나는 다음과 같습니다.

개발 후반에도 변화하는 요구 사항을 환영합니다. 민첩한 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.

그러나 나는 그들이 매일 변화를 의미한다고 생각하지 않습니다. 제품의 기본 가격을 하루에 여러 번 변경해야하지만 해당 제품의 판매 방식은 하루에 여러 번 변경하지 않아도됩니다. 오히려 제품 판매 워크 플로는 반응이 빠르고 역동적 인 비즈니스에서 주 단위로 변경 될 수 있습니다.

다시 한 번, 제품 판매 워크 플로가 매주 변경 될 수 있지만 전체 제품은 매주 변경되지 않는다고 생각합니다. 오늘 Microsoft에 Office를 제공하는 Microsoft는 상상할 수 없지만 내일은 Offooose를 제공하고 1 주일 후에는 Offasooooooooooos를 제공 할 것입니다.

아니, 그것은 민첩한 변화가 의미하는 것이 아닙니다. 나는 그것이 나쁜 비전과 변화의 개념에 대한 큰 오해에서 비롯된 것이라고 믿습니다.

스프린트에서는 개발자가 동굴 로 가서 자신이하는 일에 집중해야하는 스프린트에서는 이러한 변화를 환영하지 않습니다 . 그보다는 변경 사항을 제품 백 로그에 추가하고 스크럼 팀에 전달되기 전에 분석하고 우선 순위를 지정해야합니다. 다시 말해, 스프린트 백로 그는 변경할 수 없습니다. 하루에 여러 번 개발자 방에 직접 변경 사항을 주입하는 것이 아니라 더 짧은 스프린트를 사용하여 더 민첩성을 추구해야합니다.