Scrum/Agile : 내부 개선을 어떻게 계획합니까? [닫은

Question

나는 지난 2 년 동안 민첩한/스크럼 접근법을 사용하는 두 팀에서 일했으며 두 팀 모두 소프트웨어 개발에 접근하는 방식을 개선하기를 간절히 원했습니다. 첫 번째 팀에서는 제품 소유자가 빌드 시스템 개선, 더 나은 통합 테스트 설정, 더 나은 릴리스 전략 등과 같은 내부 사항에 대한 시간을 얻도록 쉽게 설득 할 수 있습니다. 현재 PO는 우리에게 시간을 기꺼이 제공 할 것입니다. 그는 더 뒤로 밀고 있습니다. 그는 자신의 일을 끝내야하기 때문에 합리적입니다.

어쨌든 내 질문은 이제 다른 팀이 이것을 어떻게 처리합니까? 개선 스토리를 만들어 계획 중에 테이블에 올려 놓습니까, 아니면 그러한 것들에 대한 "버킷"을 유지합니까? 제품 소유자가 개선 할 시간을 얻도록 설득하는 것이 얼마나 어려운가? 이러한 모든 종류의 개선은 팀에 도움이되지만 Prodcut 소유자/비즈니스에 직접 또는 즉각적인 것은 아닙니다.

Answer 1

좋은 질문. 나는 다른 접근법을받을 자격이있는 회고의 "행동 항목"의 몇 가지 맛이 있다고 생각합니다.

1) 기술 부채 또는 인프라 개선과 같은 문제를 해결하기위한 기술적 인 작업 - "우리는 응용 프로그램의 뷰에 데이터베이스 호출이 없어야합니다. 코드를 검색하여 우리가 다른 곳을하고 있지 않은지 확인하십시오. "

2) 프로세스 개선 (예 : "사람들은 제 시간에 스탠드 업에 오지 않습니다 ... 누군가가 늦을 때마다 자선 기부금을 위해 $ 1을 시작하겠습니다.)

첫 번째 범주는 중요한 작업 일 수도 있고 간단 할 수 있습니다. 내가 보여준 예제는 매우 쉽지만 예약 해야하는 다른 작업을 생성 할 수 있습니다 (예 : 발견 된 5 개 위치에서 데이터베이스 호출을 제거).

두 번째 카테고리는 반복 관리자, 프로젝트 관리자, 스크럼 관리자 등이 처리/주행해야합니다. 저는 (스크럼 마스터 또는 프로젝트 관리자로서) 일반적으로 프로젝트 위키에 나열하여 회고전으로 이야기하고 그들에 대해 이야기하면서 확인하십시오. '다시 주소를 지정하고 상태에 대해 팀에보고합니다. 나는 불을 피우고있다.

첫 번째 범주 인 기술 작업의 실수는 수락 기준을 정의하지 않는다는 것입니다. 예제에는 "빌드 시스템 개선, 더 나은 통합 테스트 설정, 더 나은 릴리스 전략"이 포함되었습니다. 이들은 비 결정적이며 바삭 바삭한 용어로 열거되어야합니다 (필요한 경우 스파이크 사용). 따라서 - 빌드 시스템을 개선하면 옵션을 평가하기위한 기술 작업 또는 스파이크로 시작할 수 있습니다.

또한 기술 작업을 해소하고 우선 순위를 정해야합니다 (예 : "더 나은 통합 테스트"는 현재 통합 범위를 정의하는 기술적 인 작업으로 시작하거나 통합 실패로 인해 사례를 구축하는 데 비난 할 수있는 버그의 비율을 평가할 수 있습니다. 거기에 투자.

우선 순위가 설정되면 우선 순위가 높은 항목의 가치를 전달하고 제품 소유자와 협상하여 시간을 소비 할 수 있습니다. 나는 사전 정의 된 버킷을 좋아하는 팬이 아니지만, 선명한 요구 사항, ROI 및 수락 기준을 가진 제품 소유자와 대화하는 것이 중요합니다.

Answer 2

개선은 새로운 기능과 같은 방식으로 스프린트의 일부 여야합니다. 다가오는 스프린트에 이러한 개선이 필요하다는 것을 제품 소유자에게 보여주는 것은 팀에 달려 있습니다. 이것은 새로운 기능이 생산되는 속도를 늦출 수 있지만 결국 제품에 유용합니다.

반면에 개선 사항 만 포함하는 스프린트에 문제가 있습니다. 모든 스프린트는 제품 소유자에게 입증 될 수있는 출력을 생성해야합니다.

Answer 3

결정 방법 개발 프로세스를 조정하기위한 수단으로 반사 워크숍의 개념을 가지고 있습니다. 팀은 공정의 개선과 상태에 대해 논의하기 위해 정기적으로 (개발주기보다 덜 자주)를 충족합니다. 우리가 이번에 시도한 0-3 가지를 생각해 내고 우리는 작동하지 않는 1-3 가지, 다음에 시도해 볼 1-3 가지를 유지할 것입니다. 아이디어는 제품뿐만 아니라 프로세스가 점진적으로 개선되는 것입니다.

Answer 4

작년에 나는 가장 초기의 민첩한 (XP) 채택 자/컨설턴트/트레이너 중 하나에서 일했습니다. 그는 내가 생각하는 좋은 접근 방식을 가졌다.

우리는 매주 금요일에 만났고 무엇이 효과가 있었는지, 그렇지 않은지에 대해 논의했습니다. 우리는 그것들을 두 개의 큰 종이에 쓸 것입니다 (그는 화이트 보드 대신 종이와 이젤에 실제로 있었기 때문에 더 영구적이며 더 쉽게 재배치 할 수 있기 때문에).

작동 한 것은 매우 간단 할 수 있습니다. 팀이 잘 상호 작용하고, 짝을 이루고 부드럽게 진행되었습니다.

작동하지 않은 것은 단순하고 무작위였습니다. 어떤 사람들은 Paring에 저항하고있을 수도 있고, 심지어 "상사는 약속대로 보트에서 우리를 데려 가지 않았습니다".

매주 우리는 또한 과거의 "작동하지 않았다"를 다시 방문하고 우리가 그것들을 수정했는지 알아보십시오. 그렇다면이 주에 항상 "Work"열에 나열 될 것입니다.

우리는 특정 솔루션에 대해 논의 할 것이지만, 공개에서 문제를 제기하는 것은 매우 긍정적 인 영향을 미치는 경향이있었습니다. 그들이 3 ~ 4 주 동안 "작업하지 않은"목록에 남아 있다면, 우리는 다른/더 나은 솔루션에 대해 논의하고이를 구현하려는 의도적으로 더 많은 시도를 할 것입니다.

품목이 "일이 잘 된"열에서 일주일 또는 2 주를 보내면, 우리는 계속해서 예상되지 않았기 때문에 그것을 떨어 뜨릴 것입니다 (계속 개선되지 않는 한).

또한 모든 사람들이 참여할 수있는 모임이 매우 재미있어서 금요일 오후를 조금 더 흥미롭게 만들었습니다.

Answer 5

나는 그런 것들에 '스파이크'를 사용할 것입니다. 내부/프로세스 개선은 사용자 스토리가 될 수는 없지만 완벽한 스파이크가 될 것입니다.

Answer 6

여기에 추가 할 것이 많지 않지만 이러한 환경 개선 관련 문제에 대한 자원이 있어야한다고 생각하며 작업을 번 다운 차트에 포함해서는 안된다고 생각합니다. 이 프로젝트에 필요한 추가 하드웨어 인 경우 Advanced에 추가 및 예산을 책정해야합니다. 따라서 궁극적으로 이것들은 스크럼에 시간의 할당에 영향을 미치지 않아야하지만, 이러한 문제의 결과로 영향을받는 작업은 정당화를 설명해야합니다.

Answer 7

아니요 ~ 아니다 기술 사용자 스토리 만들기 : 이론적으로, 일반적으로 고객에게 직접적인 가치를 가져 오지 않기 때문에 반복에서 선택할 기회는 거의 없습니다. 제품 소유자를 설득하는 것은이를 완화하는 옵션이지만 여기에는 사용할 수있는 또 다른 도구 인 Slack이 있습니다.

슬랙은 a 작은 반복 시간의 일부는 이러한 개선 작업에 따로 설정했습니다. 반복 중에 모든 것이 잘 진행되면 그 시간을 개선하기 위해 그 시간을 사용할 수 있습니다. 반면에, 팀이 반복에 대해 과도하게 커미셔닝 한 경우 (또는 과제가 과소 평가되고, 예상대로 더 어려워 졌을 경우) 약속을 충족시킬 수있는 또 다른 기회를 얻게됩니다.

Slack을 사용하는 또 다른 이점은 초과 근무에 의지하지 않고 약속을 더 자주 충족시킬 가능성이 높기 때문에 속도의 변화를 낮추는 것입니다.

Tom DeMarco를 참조하십시오 Slack : 과거의 소진, 바쁜 작업 및 총 효율성의 신화 (아마존 링크) -ISBN 0767907698.