"주요"기능 백 로그와 병행하여 "바이트 크기"작업의 백 로그?

고도로 사일로 된 "고독한"개발 부서 구조에서 2 년 이상 근무한 후 Agile SCRUM을 채택하고 있습니다. 큰. 나는 애자일을 좋아한다; 개발자는 어제 완료 될 것으로 예상하여 프로젝트를 진행 한 후 수많은 이해 관계자가 프로젝트를 진행하지 않고도 집중하고, 바쁘고, 생산성을 유지할 수 있습니다.

그러나 현재 "모델"과 비교하여 SCRUM으로 전환하는 한 가지 측면이 있습니다. 개발 외부의 사람들은 조금도 좋아하지 않을 것이라고 생각합니다. 그것이 "기다리는 동안"작은 변화를시킬 수있는 현재의 능력입니다. 우리 개발의 대부분은 사내 소비만을위한 것이며 대부분 같은 건물에 있습니다. 따라서 다른 부서의 부서장이나 관리자가 특정 응용 프로그램의 "코드베이스 소유자"에게 와서 작은 물건을 요구하는 것은 수년 동안 일반적인 관행이었습니다. 이러한 "드라이브 바이"를 기반으로 한 주 프로젝트). 우리 상사조차도 때때로 이런 식으로 그에게 제기 된 것들을 전달합니다. 종종 해당 코드베이스에서 작업하는 경우 소스 파일을 팝업하면됩니다.

기본적인 Agile SCRUM 방법론을 사용하면 이러한 조정은 결함 (이전에 소비 한 스토리에 지정된 요구 사항을 충족하지 못했음) 또는 새로운 작은 스토리 (모든 명시된 요구 사항을 충족했지만 해당 요구 사항이 불완전하거나 모호하거나 올바르지 않은 것으로 기록됨) 사용자가 새로운 기능을 본 후에는 배송 후 변경되었습니다. 어느 쪽이든, 대부분은 아니지만 대부분 제로에 한 포인터가 될 것이며, 상대적으로 낮은 우선 순위 (시스템은 현재 상태에서 사용할 수 있지만이 될 것이다 이렇게 하면 ... 많은 쿨러) 일하기가 어려울하고, 백 로그 하향식 작업시 스프린트로 가져 왔습니다.

이러한 가능성은 개발 부서 회의에서 다른 부서의 애자일 프로세스에 대한 적극적인 반대의 원천으로 제기되었으며, 이는 요청에 따라 미세 조정을 수행하는 현재의 능력보다 "민첩한"것으로 간주됩니다. 유효한 우려 IMO입니다. PO 뒤에있는 이해 관계자들은 항상 같은 관점을 가지고 있지 않기 때문에 가장 중요한 것에 동의하지는 않지만, 최종 결정을 내리는 것은 관리자에 의해서만 이루어지며, 따라서 그들의 편견은 제품 백 로그에 표시됩니다.

그런 다음 일시적으로 "사탕 용기"라고하는 해결책이 제안되었습니다 (또 다른 용어는 "중대한 배"였습니다). 여러 부서의 "작은 녀석들"에 의해 요청 된 작은 이야기, 기존 이야기의 결함이 아니며, 팀 내 합의 나 찬사에 의해 개발자의 하루의 절반도 걸리지 않는 것으로 추정되며, 최종 사용자의 의견에 따라 사용자 경험에 즉각적이고 중요하며 긍정적 인 영향은 기본 백 로그와 병행하여 목록에 포함됩니다. 그것들은 "이야기"로 식별되지만 우선 순위에 따라 "큰"이야기의 주요 백 로그와 별도로 유지됩니다. 스프린트가 정상적으로 진행되는 동안 언제라도 이러한 조정 중 하나를 수행 할 수있는 시스템 영역에서 작업하고있는 경우, 트윅을 사소한 것으로 만들면 스프린트를 스프린트로 가져 와서 더 큰 이야기와 함께 코딩 할 수 있습니다. 이렇게더 큰 이야기 나 다른 헌신적 인 작업의 완료를 위태롭게 해서는 안됩니다 . PO는 또한이 목록에 액세스 할 수 있으며, 조정과 관련된 기본 기능을 다루는 다음 사용자 스토리를 작업중인 경우이를 스토리로 접을 수 있으며 요구 사항을 충족시킬 수 있습니다. 다른. 이것은 생각보다 나중에 조정이 더 빨리 작동 할 가능성이 높아질 것이라고 생각했습니다.

이것은 "uh-uh"에 대한 ScrumMaster 교육으로 우리들 사이의 반응을 촉발 시켰습니다. 백 로그 가 하나 있습니다 . 두 개의 백로 그는 어떤 # 1 아이템이 실제로 가장 중요한지, 어떤 아이템의 아이템이 실제 속도를 결정하는지 , 그리고 스토리가 실제로 속하는 두 백 로그 중 어느 것에 대한 질문을 소개합니다 (크기 / 복잡성의 구분은 상대적으로 떨어지는 경우가 있습니다) 한쪽 또는 다른쪽으로 임의로). "프로세스가 작동하게하자"고 말했다. 변경 사항이 최종 사용자에게 실제로 중요한 경우 부서 담당자가 시간 / 돈 결정을 내릴 수 있도록 충분한 소음을 내고 개발 팀의 의식에 백 로그의 상단을 향하게됩니다.

나는 질문을 바닥에 던질 것이라고 생각했다 . 당신의 의견으로는, "물린 크기"이야기의 병렬 목록이 작고 유용하지만 궁극적으로 우선 순위가 낮은 변경이 더 빨라지는 데 가치가 있거나 전체적으로 더 나은 결정인가 메인 백 로그에 그것들을 접고 기본 프로세스가 스프린트에 포함되도록 통제 할 수 있습니까?

나는 당신이 당신의 길을 찾는 데 도움이 될 몇 가지 사항에 대해 이야기 할 것입니다.

1. " 스크럼 "은 민첩한 것입니다. 상식이 필요합니다. 변경 사항이 몇 분 변경되면 백 로그가 필요하지 않다고 생각합니다. 2 시간 이상이면 다시 생각해야한다고 생각합니다. "쉬운 승리"인 모든 것을 수행해야하는 것은 아닙니다. 스크럼에서는 우선 순위에 따라 작업합니다. PO는 추가와 노력으로 얻는 것에 대한 정보를 얻어야한다고 생각합니다. 그래야만 PO가 중요한지 여부를 결정할 수 있습니다. SCRUM으로 이동하면 때때로 많은 질문이 있으며 개발자는 종종 "하지만 몇 시간이면 끝날 것"이라고 말합니다. 그래서 무엇? 짧은 시간을 모두 포함 할 필요는 없지만 몇 시간은 시간입니다.
2. 한때 우리는 "엔지니어링 백 로그" 가있는 프로젝트에서 일했습니다 . 이 백 로그에는 제품 개선을 위해 개발자가 제안한 항목이 포함되어 있습니다. 이러한 항목에는 명시적인 사용자 값이 없었지만 내재 된 사용자 값이있었습니다. 예를 들어 : 코드에서 컴포넌트를 리팩토링합니다. 우리는 변화, 노력 및 이익을 설명했습니다 (이 경우 사용자에게 아무것도 제시 할 수 없습니다. 그러나 그러한 리팩토링으로 인해 새로운 기능이 더 빨리 개발되면 사용자에게는 확실히 이익입니다). 우리 PO는 버전 중에 각 스프린트의 10 % (평균)를 해당 항목에 투자하기로 결정했습니다. 각 스프린트 전에 PO는 다가오는 스프린트의 백 로그에 대해 결정할 때 10 %의 엔진 링 백 로그 항목을 가지고 있는지 확인했습니다. 따라서 2 버전 백 로그-> 1 스프린트 백 로그.
3. 버퍼 -스크럼에서 일을 시작할 때 사람들은 종종 소프트웨어 엔지니어로서 불확실성의 세계에 빠져 있다는 사실을 잊어 버립니다. 하루에 8 일 대신 6 시간으로 계산해도됩니다. 15 일의 스프린트가 있다고 가정합니다. 즉, 회의에 30 시간이 더 걸리고, 너무 오래 걸렸거나 기억하기에는 너무 미미하지만 하루 2 일의 일의 일부입니다.
4. 집중력 유지 -마지막으로, 스크럼에서는 집중력을 유지하는 것이 중요합니다. 그러한 작업에 투자하고이 시간과 노력에 투자하는 것을 잊지 말고 총 노력의 양과 우선 순위를 결정하십시오. 작은 것이기 때문에 "작은 일"을하기 위해 표류하지 마십시오. 결정에 도움이되는 PO가 있으며 상식이 있습니다.
5. 민첩성을 유지하십시오 -그리고 마지막으로 문제에 접근하기 위해 다른 방법을 시도하고 그것이 최선의 방법인지 스스로 질문하십시오. 도중에 개선하십시오.

행운을 빕니다 :)

Agile 및 SCRUM과 같은 프로그래밍 프레임 워크는 개발에 훈련과 구조를 적용하도록 설계되었습니다. 그러나 훈련과 구조는 재미와 창의성의 반석 인 것 같습니다. 일반적으로 훈련을 확립하고 유지하기 위해 더 열심히 노력해야합니다. 이 반대 개념들 사이에서 균형을 찾기가 매우 어렵습니다. 따라서 프레임 워크는 주제를 피하는 경향이 있습니다.

마지막 프로젝트에서 개발자는 매일 머리를 상쾌하게하거나 맑게하는 데 약간의 시간이 필요하다는 것을 알았습니다. 개발자는 예산 내 (일 기준으로 5 시간 또는 5 시간 또는 2.5 시간 / 주) 시간 내내 작업을 수행 할 수있었습니다. 이유 (직장에서 무언가에 적용될 가능성이 있음). 일을 징계하기 위해, 그들은 어떤 성과에 대해서도 신용을 얻을 수 있도록 그들의 활동을 문서화하도록 요청 받았다. "사탕 병"에 대한 특정 예산을 우리의 타임 라인에 맞추고 사물이 손에 닿지 않도록 막았다.

Btw, 우리는 "프로젝트 시원함"이라고 불렀고, 그 회사에서 많은 좋은 아이디어와 개선의 원천이되었습니다.

작은 이야기는 기본 백 로그에 보관해야합니다.

나는 스크럼을 사용하지 않지만 설명하고있는 것과 비슷한 문제에 직면 해있다. 우선 순위 지정 및 효율성 문제에 직면 하고 있습니다 .

"오래된 방식"에서 들리는 것처럼, 개발자의 사무실을 방문하는 경우 누구나 자신의 작업을 현재 "최우선 순위"로 만들 수 있습니다. 이것은 몇 가지 이점이 있습니다. 요청자는 응답 한 것처럼 느껴지고 요청자와 개발자 모두 "빠른 승리"를 얻습니다.

단점은 이러한 작업을 자주 삽입하면 제품 소유자와 합의한 우선 순위가 높은 작업이 느려지거나 탈선되는 경향이 있다는 것입니다. 참고로, 종종 모든 사람들이 이러한 "빠른"수정에 필요한 시간을 과소 평가합니다.

저의 경험은 우선 순위가 낮은 작업을 짜려고하면 우선 순위의 이점이 손상된다는 것입니다. 개발자로서 우선 순위 지정은 제품 소유자가 작업하고 싶은 작업을하고 있음을 확인합니다. 제품 소유자는 추가 작업을 수행할지 여부와 "좋아요"요청으로 폴딩이 발생할 위험이 있는지 (약간이라도) 결정해야합니다.

이해 당사자들에게 우선 순위를 정하도록 요구할 때 종종 "당신은 이것을 짜낼 수 있습니까?"라는 질문을받습니다. 암시적인 소망은 현재 가장 높은 우선 순위에 영향을 미치지 않으면서도 새로운 작업을 마술처럼 완료하는 것입니다.

자주 발생하는 것은 이해 관계자가 LargeImportantProject 및 SmallLessImportantTask를 요청한다는 것입니다. 딜레마는 SmallLessImportantTask가 LargeImportantProject가 완료 될 때까지 기다려야합니까 (또는로드 블록이 있어야 함)? 트레이드 오프가 있으며 제품 소유자가 결정해야 할 경험이 있습니다. (제품 소유자가 결정하지 않으면 개발 팀은 추측해야합니다.)

스크럼 (및 일반적으로 프로젝트 관리)의 한 가지 목표는 우선 순위가 가장 높은 작업의 장애물을 피하는 것입니다. 보다 효율적으로 작업할수록 "좋은"추가 작업을 수행 할 공간이 줄어 듭니다.

효율성은 무서울 수 있지만 두 가지 중요한 방법으로 비용보다 큰 이점을 보았습니다.

1. 효율성이 높아질수록 "좋은"요청을 포함하여 귀중한 작업을 완료 할 수있는 팀의 역량이 향상됩니다.
2. 요청이 진정으로 "좋은 것"이라면 요청이 더 중요한 비즈니스 우선 순위가 해결 될 때까지 기다리는 것이 합법적 일 것입니다.

내 의견으로는; 문제는 백 로그에서 작업의 우선 순위가 결정되는 방식입니다. 예를 들어 "우선 순위"는 중요도와 완료 시간을 모두 고려할 수 있습니다. 중요하지 않지만 10 분 안에 완료 할 수있는 것은 구현하는 데 몇 주가 걸리는 더 중요한 것보다 우선 순위가 높습니다.

나는 잠시 동안 민첩하게 일했습니다. 내가 말할 수있는 것은 이것입니다-방법론을 고집하는 것과 그것이 포함하는 모든 것이 절대적으로 잘못된 상황이 있습니다. 당신은 민첩해야하며, 특정 상황에 대한 방법론을 조정하는 것은 필수입니다.

위의 Avi가 말했듯이 "스크럼"은 민첩한 것입니다. 상식이 필요합니다. 변경 사항이 몇 분 변경되면 백 로그가 필요하지 않다고 생각합니다.

변경에 시간이 걸리면 "무해한"것이 아니며 문서화가 잘되어 있어야합니다.

귀하의 첫 질문과 그 이후의 설명을 바탕으로, 이것이 귀하의 고통 지점이

• 끊임없이 변화하는 요구 사항
• 개발자가 응용 프로그램의 다른 영역에 집중할 수 없음 우리는 응용 프로그램의 한 부분에서 영웅이지만 다른 것을 만지는 것에 관심이 없습니다.
• 채택되는 아키텍처, 솔루션, 프레임 워크에 대한 다양한 접근 방식
• 요구 사항 수집 프로세스가 작동하지 않는 것 같습니다

스크럼은 처음에 올바르게 고수했다면 이러한 많은 문제를 해결해야하며, 더 중요한 것은 해결해야 할 다른 문제를 미리 제기해야합니다.

-끊임없이 변화하는 요구 사항

모든 것이 올바르게 공급되고 우선 순위가 지정되는 단일 백 로그가 있다는 것은 팀이 개발 중에 변화하는 요구 사항을 감당하지 않아야한다는 것을 의미합니다. 매우 역동적 인 환경 인 경우 1-2 주 간의 작은 스프린트는 상대적으로 짧은 기간 내에 우선 순위 변경을 계속 촉진 할 수 있어야합니다.

-개발자가 응용 프로그램의 다른 영역에 집중할 수 없음 우리는 응용 프로그램의 한 부분에서 영웅이지만 다른 것을 만지는 것에 관심이 없습니다.

팀 내에서 지식을 공유하고 응용 프로그램의 다른 부분에서 작업해야하는 과제를 찾는 데 중점을 두는 스크럼 팀은 서로 잘 협력하고 서로를 지원합니다. 페어 프로그래밍과 같은 일부 관행은 사람들이 익숙하지 않은 코드 작업에 대한 두려움을 극복하고 지식을 배우고 공유하는 데 도움이 될 수 있습니다. 응용 프로그램에 대한 지식이 팀간에 배포되고 사람들이 응용 프로그램의 모든 영역에서 편안하게 작업하기 전에 약간의 스프린트가 필요할 수 있습니다. 또한, 사람들이 보드 작업을 수행 할 수 있도록하는 것, 즉 그들이하고 싶은 일을 스스로 선택하게하면이를 장려 할 수 있습니다.

-아키텍처, 솔루션, 프레임 워크에 대한 다양한 접근 방식 채택

Scrum은 의사 소통을 개선하고 팀워크와 의사 결정을 용이하게하며 진행 상황에 대한 가시성을 높입니다. 이것은 차례대로 프레임 워크, 건축 솔루션 등의 사용에 대한 조직의 결정을 촉진해야하며 스크럼 스크럼 메커니즘을 사용하면 조직 전체에이를 적용하는 데 도움이 될 수 있습니다.

-요구 사항 수집 프로세스

다시 한 번, 규칙을 엄격하게 준수하는 경우 요구 사항이 명확하지 않고 팀이 요구 사항을 충족하는 데 필요한 사항을 이해하고 평가할 준비가 된 경우 스프린트로 가져 와서는 안됩니다. 우선 순위가 높고 명확하게 정의 된 다른 요구 사항을 수행하십시오. 그러면이를 제공 할 수 있다는 것을 알기 때문입니다! 요구 사항 수집 프로세스를 즉시 수정하지는 않지만 해당 프로세스를 수정하는 데 필요한 변경 사항이 적용됩니다.

첫 번째 질문에 답하기 위해 두 개의 별도 백 로그가 없어야합니다. 언제든지 개발자와 조직이 가장 우선 순위가 높은 항목을 작업하는 것이 모든 사람의 이익을위한 것입니다. 우선 순위는 주로 비즈니스 가치를 기반으로해야하며, 많은 미세 조정 및 요청이 비즈니스 가치를 추가 할 수 있습니다. 제품 소유자가 결정하게하십시오.

저는 7 년 이상 스크럼 마스터 (Scrum Master)였으며 다양한 팀과 회사에 스크럼을 도입하는 데 도움을주었습니다. 겸손한 의견과 관찰 결과에 따르면, 스크럼이 조직에 처음으로 소개되면 책을 따라 가십시오. 일탈하지 마십시오. 스크럼은 규율이 실무와 프로세스를 고수 할 수 있어야합니다. 특정 상황에 맞게 예외를 작성하는 것은 너무 쉬운 일이며, 너무 일찍 수행하면 혜택과 가치가 침식 될 수 있습니다. 기본 사항을 잘 수행하십시오. 기본 사항을 수행하고 그 이유가 무엇인지 이해하는 데 전문가가되어 조직에보다 적합하고 지속적인 개선을 위해 프로세스를 변경하십시오.

이것이 "애자일"이라고하는 데 유효한 사례가 있으므로 프로세스를 기꺼이 바꾸어야하지만, 자기 주도적, 자체 조직 팀이 프로세스를 이해하고 변경 사항을 논의하는 것에는 큰 차이가 있습니다. 애자일 또는 스크럼의 길을 걷기 시작한 팀과 달리 프로세스. 크롤링을하기 전에 실행하는 것과 같습니다.