Lean/Kanban과 함께 자주 출시하는 방법? [닫은

Question

나는 Lean/Kanban을 처음 접했지만 지난 몇 주 동안 온라인 리소스를 쏟아 부었고 좋은 답변을 찾지 못한 질문을 제시했습니다. Lean/Kanban은 이미 Scrum을 사용하고 있지만 그 방법론 내에서 몇 가지 한계에 도달 한 회사에 적합한 것으로 보입니다. 여기 누군가가 나에게 좋은 아이디어를 줄 수 있기를 바랍니다.

내가 알다시피, 폭포보다 스크럼의 가장 큰 장점 중 하나는 스프린트를 사용하는 것입니다. 14 일마다 모든 것을 준비하면 짧은 피드백주기를 얻고 자주 출시 될 수 있습니다. 그러나 Lean에 대한 독서에서 이해 한 바와 같이, 이것과 관련된 몇 가지 비용이 있습니다 (예 : 스프린트 계획 회의에서 보낸 시간, 팀 헌신 회의 및 스프린트 끝에서 모든 사람에게 유용한 것을 찾는 데 문제가 있습니다).

Lean/Kanban은 이러한 폐기물을 제거하지만 14 일마다 석방 할 수없는 비용 만으로만. 아니면 중요한 요점을 놓쳤습니까? Kanban에서는 어떻게 새로운 개발 작업을 수행하고 동시에 출시 할 수 있습니까? 반쯤 끝난 것을 배송하지 않도록하려면 어떻게해야합니까? 그리고 어떻게 올바르게 테스트 할 수 있습니까?

지금까지 나의 최고의 "솔루션/아이디어"는 다음과 같습니다.

• 자주 풀지 말고 새로운 개발 작업이 부족하는 것과 관련된 폐기물을 허용하십시오. 그래도 질문에 대한 해결책은 아닙니다.
• 가지에서 개발 한 다음 메인 트렁크로 병합하십시오. 내부적으로 두 개 이상의 지점을 지속적으로 지원해야합니다.
• 일부 스마트 자동 라벨링 시스템을 사용하여 특정 완료 작업 만 자동으로 구축하지 않고 다른 작업만을 구축하십시오.

요약으로 내 질문은: Lean/Kanban을 사용하면 폐기물을 소개하지 않고 자주 석방 할 수 있습니까? 또는입니다 자주 릴리스 Lean/Kanban의 일부가 아니십니까?

내 회사에 맞는 추가 정보: 우리는 Team Foundation System & Source Control을 사용하고 있으며 이전에는 분기 및 병합과 관련하여 나쁜 경험을했습니다. 이 분야에서 전문 지식을 제공함으로써 단순히 해결할 수 있습니까?

Answer 1

당신이 설명하는 문제는 더 많은 소스 제어 프로그램 인 것처럼 보입니다. 칸반보다는 완료 된 기능을 기능에서 분리하는 방법. 여러 지점을 운영하는 데 많은 형벌을받는 것 같습니다. 이는 여러 지점의 아이디어를 기반으로하지 않은 소스 제어 시스템의 경우입니다. Git 및 Mercury와 같은 분산 소스 제어 시스템에서 모든 것 지점이고 그들과 함께 일하는 것은 가벼운 것입니다.

나는 당신이 읽은 것으로 가정합니다 이 블로그 Kanban vs Scrum 및 관련 실용 가이드에 대해?

그리고 당신의 질문에 대한 답으로, 당신은 Kanban과 자주 석방 할 수 있습니다.

Answer 2

Kanban이 관리하도록 설계된 풀 시스템을 이해해야합니다.

실행중인 시스템의 기능에 대한 고객 (또는 제품 소유자 또는 이와 유사한) 요청은 프로세스를 유발하는 것입니다.

요청은 배포로 이동하는 신호입니다. 배포 요청과 일치하는 속성이있는 테스트 된 항목을 찾습니다. 아무것도 없으면 테스트를 작성하고 테스트를 수행하는 것을 구현하는 데 사용할 수있는 개발 슬롯이있는 경우 테스트를 작성하고 개발을 살펴 봅니다. 개발이 개발을 수행했을 때 (아마도 적절한 분석을 먼저 찾고있을 수도 있음) 테스트는 테스트를 수행하고 배포 배포를 수행합니다.

시스템을 통해 거꾸로가는 요청은 작동을 시작할 권한입니다. 요청이 도착하자마자, 이것은 각 활동이 가능한 빨리 완료되어야하는 많은 활동을 유발합니다. 거기에 터보 배치가 있습니다.

자동차 요청이 자동차 공장에 신호를 보내고 공급 업체에 신호를 보내는 선박을 바라 보는 딜러에게 간다.

Kanban은 시스템을 통해 요청을 추진하는 것이 아닙니다. 마지막 단계를 통해 들어가는 요청을 대가로 시스템에서 기능을 끌어내는 것입니다.

Answer 3

내가 관리하는 팀은 Kanban을 사용하고 2 주마다 출시됩니다. 메인 라인 코드 브랜치 (테스트 통과, 고객 승인 등)에 통합 된 내용에 대해 엄격한 경우 Kanban을 사용하면 원하는 때마다 릴리스 할 수 있습니다. 시스템을 통해 움직이는 이야기가이를 수행하기 위해 공동 의존적이지 않은지 확인해야하지만 일반적으로 문제가되지 않는 팀에서는 우리의 작업의 상당 부분이 유지 보수와 관련이 있습니다. / 릴리스 당 기능.

Answer 4

Kanban을 사용한 지속적인 엔지니어링 프로젝트에서 매주 릴리스를 처리하는 방식은 분기 전략을 구현하는 것이 었습니다. Devs는 샌드 박스 지점에서 일했으며 작업 품목 당 하나의 체크인을했습니다. 우리 테스터는 샌드 박스의 작업 항목을 테스트 할 것입니다. 회귀 테스트를 통과하면 체크인이 릴리스 지점으로 마이그레이션됩니다. 우리는 월요일 정오부터 릴리스가 나올 때까지 릴리스 지점을 잠그고 (보통 수요일까지, 때로는 목요일까지, 드롭 데드 날짜는 금요일이었다) 모든 마이그레이션 된 체크인에 대한 회귀 테스트와 제품에 대한 통합 테스트를 다시 실행했습니다. 모든 테스트가 통과되면 릴리스를 삭제합니다.

이 전략을 통해 DEV는 출시 과정에서 지점에서 얼어 붙지 않고 계속 문제를 해결할 수있었습니다. 또한 해결하는 데 일주일이 걸린 문제에 대해서도 작업 할 수있었습니다. 체크인하지 않고 테스트/승인하면 마이그레이션되지 않았습니다.

새로운 버전의 프로젝트를 위해 Kanban을 실행하고 있다면 유사한 전략을 사용하지만 모든 관련 Checkins를 '기능'으로 그룹화하여 기능을 마이그레이션합니다. 대량 릴리스 브랜치에 기능이 완료되면 해당 기능으로 릴리스를 삭제하기 전에 릴리스 브랜치에서 추가 장치/통합/수락/회귀 테스트를 수행합니다. Kanban의 핵심 개념은 진행중인 작업을 제한하고 있으므로 팀이 한 번에 하나의 기능에 대해 작업하도록 제한 할 수 있습니다 (아마도 여러 작업 항목/사용자 스토리 일 것입니다).

Answer 5

소스 컨트롤보다 더 많은 것이 있지만, 당신의 선택은 당신을 제한 할 것입니다. Burton 프로젝트가 2004 년에 다시 고안되었을 때 Microsoft는 Agile에주의를 기울이지 않았으며 훨씬 덜 간주했습니다. 한동안 가장 약한 기계적 링크가 될 것입니다. 귀하의 Hackles는 TFS 구현의 포스터 자식으로 Microsoft 커뮤니티에 제공된 후 Codeplex의 Mercurial 채택에 의해 제기되어야합니다.

여기서 더 중요한 문제는 작업 설계입니다. 기능 (작업 일정), 우선 순위 및 지연 비용, 작업 항목의 모양과 크기를 구현하기로 선택한 순서가 포함됩니다.

Scrum은 일반적으로 비 기술적 인 "제품 소유자"가 자신의 우려만으로 작업 일정을 결정할 수 있다고 말하면서 일반적으로 해석됩니다. 이 길을 따라 가면 함께 일할 기회를 갖지 않아서 많은 낭비가 발생합니다. 함께 속한 작업은 제품 소유자의 소원에 의해 결정될 수 없습니다. 기술 및 인력 (기술) 기회도 고려해야합니다.

작업이 가장 생산적인 방식으로 수행 되려면 작업 자체가 그런 식으로 설계되어야합니다. 이는 LAN 제품 개발 팀에서 비 기술적 근로자가 아니라 Toyota가 제품에 가까운 "우뚝 솟은 기술적 역량"을 가진 사람을 부르는 것에 의해 결정이 내려지고, 고객과 가깝고 팀에 가깝다는 것을 의미합니다. .

이 역할은 Scrum의 제안과 완전히 대조적입니다. 린 팀의 수석 엔지니어는 자신 (또는 자신)이 고객의 목소리이며 제품 소유자의 역할은 불필요합니다.

Scrum의 "제품 소유자"는 소프트웨어 개발 조직에서 저개발 된 역할을 인정하지만 폐기물을 지속적으로 피하는 지속 가능한 솔루션과는 거리가 멀다. "소프트웨어 아키텍트"의 역할은 종종 개발자 하위 문화에서 건축가가 작업에서 멀리 떨어진 것처럼 충분하지 않습니다.

지속적인 배포 문제는 기술과 도구로만 부분적으로 해결됩니다. 조직 문제를 살펴보고 아마도 스크럼의 목적을 무기한 조직이 아닌 폭포의 과도기적 접근법으로 생각할 것입니다.

Answer 6

소스 컨트롤의 경우 적극 권장합니다 억지로. 다른 분기의 변경 사항을 상대적으로 간단하게 만들고 지금까지 본 소스 컨트롤을위한 최상의 인터페이스를 제공합니다.

지속적인 통합은 또한 크고 잠재적으로 도전적인 합병 대신 일일 커밋보다 작고 매일 커밋하는 것보다 더 도움이됩니다. 도구와 같은 도구 크루즈 컨트롤 나쁜 커밋으로 소스가 깨질 때 강조하는 데 도움이 될 수 있습니다. 또한 모든 사람이 많은 작은 변화를 일으키면 상충되는 변화가 드물게됩니다.

또한 Lean, Scrum, Kanban & Co와 같은 것을 따르려고하지 말라고 조언합니다. 너무 가깝습니다. 문제를 직접 해결하면서 지시보다는 안내를 위해 이러한 아이디어를 찾으십시오. 문제의 세부 사항은 최상의 관리를 위해 약간의 유연성이 필요할 것입니다.

Answer 7

우리가하는 방법 :

우리는 다음 단계가있는 파이프 라인이 있습니다

1. 백 로그
2. 할 것
3. 진행중인 (개발 및 빠른 테스트)
4. 코드 검토
5. 테스트 (엄격한 테스트)
6. 통합 테스트 및 일반 수락 테스트
7. 배포

각 스토리는 배포 단계를 떠나기 위해 최신 버전을 기반으로 지점으로 개발되었습니다. 그런 다음 통합 테스트 준비의 일부로 통합됩니다.

QA는 코드 검토 단계에서 가져와 원하는 속도로 모든 릴리스를 준비 할 수 있습니다. 매주 대략 1 개의 릴리스 속도가 있다고 생각합니다.

GIT에서 "마스터"브랜치를 제거하고 코드 검토 단계 전에 병합을하지 않음으로써 코드를 릴리스로 "몰래"할 가능성이 없는지 확인했습니다. 흥미로운 부산물로서 우리는 숨겨져 있던 많은 작업을 시각화해야했습니다.