Atlassian GreenHopper 및 Release Management

Question

우리는 Atlassian 제품을 가지고 놀고 있으며 GreenHopper를 사용하여 민첩한 스프린트를 준비했으며 흐름과 혼동하지 않습니다.

여기 내 사무실에서 현재 개발중인 내용은 다음과 같습니다.
1. 개발자는 할당 된 문제를 완료합니다. 그들을 해결 된 것으로 표시하십시오.
2. 스프린트에 대한 모든 문제가 완료되면 릴리스 세부 정보를 제공하는 릴리스 티켓이 있으며이를 INF 팀에 할당하여 QA에서 빌드하고 배포합니다. 물건이 품질 보증에서 승인되면 준비, 생산으로 옮깁니다.
3. 문제가 발견되거나 문제가 해결되지 않은 경우 릴리즈를 거부하고 개발자에게 다시 할당합니다. devs는 그들을 수정하고 또 다른 릴리스를 준비합니다.

누구나 JIRA + GreenHopper 또는 더 좋은 아이디어와 비슷한 것을 달성하기위한 제안 사항이 있습니까?

미리 감사드립니다.

Answer 1

우리는 여기에 꽤 비슷한 일을하고, 모두가 JIRA/사항 GreenHopper에서 잘 작동 :

1. 제품 소유자가

   는

2. 백 로그 정리가 발생 메뚜기 JIRA /의 서사시/테마/사용자 스토리를 만들고, 이야기가 조금 빗나가고 스토리 포인트가 사용자 스토리에 입력 됨

3. 스프린트 계획 : 곧 출시 될 스프린트에 대한 스토리가 선택되고 greenhopper를 사용하여 스토리를 스프린트에 추가한다. 아래를보십시오

4. 스프린트가 시작됩니다. 개발자가 JIRA에서 진행 상황을 추적하기 위해 작업을 생성하고 사용자 스토리에 연결합니다. 스토리에 대한 모든 작업이 완료되면 사용자 스토리가 완료됩니다.

5. 우리는 JIRA에 "done"을위한 스크립트를 넣었습니다.이 버튼은 빌드 팀을 우리의 기본베이스 라인에 병합합니다. 제작 빌드에 넣으면 사용자 스토리가 품질 보증 팀에 할당됩니다.

6. 품질 보증 팀 테스트 생산 빌드 ... 통과하면 스토리가 닫힙니다.

내가 스프린트 허용하는 것보다 품질 보증 팀이 이야기를 테스트하는 데 시간이 더 걸릴 수 있음을 추가 할 수 있습니다 - 지점에서 할 정도로 팀의 전력 질주와 속도의 목적을 위해, 이야기는 촬영 빌드 팀에 할당됩니다.

의미가 있습니까?

JIRA는이 모든 것을 할 수있는, 그것은 중대하다 - 당신이 서사시/테마 등

우리는 만들고 이야기와 달리기를 추적 할 사항 GreenHopper 기능을 사용

만에 대한 설정 항목을 일부 구성을해야 할 수도 있지만 작업 진행 등, 우리는 화이트 보드를 사용합니다. 훨씬 더 눈에 잘 띄고, 매일 일어 서기 위해 더 좋습니다.

희망이 도움이 ..궁금한 점이 있으면 기꺼이 대답 해 드리겠습니다.

Answer 2

프로세스가 상당히 간단하다고 들립니다. GreenHopper 5.10.1의 새 Rapid Board를 가지고 가시는 것이 좋습니다. Rapid Board 's는 명확한 계획> 작업> 보고서 흐름을 제공합니다.

나는 다음과 같은 권하고 싶습니다 당신의 세부 사항을 보면 :

• 먼저 일반적인 개발을위한 신속한 보드를 만들 수 있습니다. 이 보드는 개발 팀에 사용되며 버그 수정, 기사 및 백 로그 항목이 포함 된 Sprints를 보유하게됩니다. 이 보드의 마지막 열은 '완료'또는 '품질 관리를위한 준비'입니다.
  • 스프린트가 끝나면 팀은 스프린트를 '완료'하고 빌드를 가져 와서 QA
• 그런 다음 과 동일한 개의 이슈를 QA 프로세스를 통해 Sprint에 있던 것과 같이 옮겨서 각각을 거부 할 수 있도록하는 것이 좋습니다. 이를 위해 QA 팀은 첫 번째 열 '품질 관리를위한 준비'가있는 별도의 스크럼 급 이사회를 가질 수 있습니다. 이렇게하면 방금 완료된 스프린트의 문제가 포함 된 별도의 스프린트를 실행할 수 있습니다.
  • 이 스프린트가 끝나면 '완료'항목에 기사가 표시되고 팀에서 배포를 결정할 수 있습니다. 정확한 이야기 ​​또는 전체 발표를 거부하십시오.
  • 품질 보증을 통과하지 못한 이야기는 개발 팀 백 로그에 다시 반영되어 다음 스프린트에 포함될 수 있습니다. 또한 그들은 작정