기금넷 공식사이트 - 펀드 투자 - 민첩한 개발 방법의 간판 (KanBan)
민첩한 개발 방법의 간판 (KanBan)
주의: 저는 태생이기 때문에 소프트웨어 업계에서 간판의 사용을 소개하겠습니다.
1. 간판이란 무엇입니까?
간판의 정의에 대하여 나는 인터넷에서 한 광주리를 수색했다. 데이빗 앤더슨의 말입니다. 누군가는 이 사람이 누구인지 묻고 싶어할지도 모른다. 결론적으로, Taiichi Ohno 는 간판의 아버지이며, 데이비드는 IT 업계에 간판을 도입하는 선구자이다.
즉, 개발 모델이 민첩하든 (예: XP, FDD, TDD) 기존 개발 모델 (예: 폭포, 반복) 이든 간판은 지속적인 소프트웨어 개발을 지원하고 촉진하기 위해 모든 개발 프레임워크에 도입될 수 있습니다.
개인 이해는 이러한 소프트웨어 개발 프로세스 관리 방법으로 소프트웨어의 지속적인 통합을 보장하고 개발 팀을 과부하하지 않도록 하는 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 개발명언) 코스가 "개발팀이 과부하를 가하지 않도록 하라" 는 말을 듣고 싶은지 모르겠다. (윌리엄 셰익스피어, 개발팀, 개발팀, 개발팀, 개발팀, 개발팀) 팀 능력에 따라 WIP (WIP) 작업 수를 제한합니다.
2. 왜 간판입니까?
1) 워크플로우를 시각화합니다. 모든 태스크에 대한 진행이 간판에 표시되며, 모두가 진행 및 프로세스를 한 눈에 파악할 수 있습니다.
2) WIP 에서 작업 수를 제한합니다. 일반적으로 이 수치는 팀의 개발자 수와 같습니다.
3) 프로세스 관리 및 최적화 WIP 에서 작업이 완료되면 ToDo 에서 우선순위가 가장 높은 작업이 WIP 로 이동됩니다. 따라서 프로젝트의 우선순위를 자주 변경해야 할 때 간판이 선택됩니다.
4) 양적 개발주기.
5) 개발주기를 단축하다. 이것은 사실 문제를 발견하고, 문제를 해결하고, 더 과학적인 방법을 찾아 개발 효율을 높일 수 있는 것으로 이해할 수 있다.
6) 추월식 시스템 (만일의 경우) 은 풀 시스템 (시기 적절한 경우) 입니다. 팀이 능력이 있는 경우에만 새로운 사례를 시작할 수 있다.
3. 간판 모델
현재 프로젝트의 광고판에 따르면, 나는 그 위에 간판 벽을 그렸다.
1) 분표, 백로그: 하지 않은 것은 보통 제품 부서 (새로운 수요) 또는 온라인 지원 고객 서비스 담당자 (bug) 입니다. 설계: 설계가 준비 중입니다. 일반적으로 이 섹션은 솔루션 아키텍처 또는 UI 디자이너의 책임이며 모든 작업이 이 목록에 나타나는 것은 아닙니다. 개발: 이 부분은 분명히 코딩 부분이며 개발자가 책임진다. 테스트: 테스트 섹션은 테스터가 담당하며 완료: 완료, 온라인 대기 중입니다. 각 항목은 자신의 수요에 따라 자신의 간판을 생성할 수 있습니다. 위의 것이 유일한 것은 아니다.
2) 위의 각 프로세스에서 제한된 수의 작업을 설정합니다. 이것은 간판의 핵심 사상 중 하나이며, 이는 이렇게 많은 임무를 동시에 완수할 수 있다는 것을 의미한다. 예를 들어 디자인이 2 라면 이 단계에는 두 가지 임무만 있을 수 있다. 이것은 일반적으로 인원수에 따라 결정된다.
3) Dell 프로젝트는 이미 온라인 상태이므로 고객의 버그와 제품 그룹의 새로운 요구 사항, 프로젝트의 일부 부분에 대한 기능 개선이 필요한 경우가 많습니다. 그래서 우리는 서로 다른 색깔로 서로 다른 종류의 수요를 대표한다. 파란색은 버그, 녹색은 개선, 보라색은 새로운 수요다. 이렇게 하면 더 명확하게 분류할 수 있다.
4) 우리 프로젝트의 제품 그룹은 프로젝트 관계자이기 때문에 일반적으로 백록에서 임무 우선 순위를 매깁니다. 그런 다음 하나의 임무를 완료하면 팀은 다음으로 우선 순위가 가장 높은 임무를 선택합니다. 제품 그룹은 1 을 제외하고 언제든지 이러한 backlog 에서 작업의 우선 순위를 변경할 수 있습니다. 작업이 이미 시작되었으므로 진행 중인 작업을 대체할 수 없습니다. 2. 프로젝트 주기의 잔여 시간은 태스크의 예상 완료 시간보다 작으며, 이 태스크는 다음으로 높은 우선순위로 변경할 수 없습니다.
4. 종이 모형
-응? 1) 작업 ID 는 작업의 고유 식별자입니다. 우리 프로젝트에서는 물리적 간판을 사용합니다. 즉, 큰 화이트보드를 사서 직접 내용을 그립니다. 하나의 임무가 온라인으로 완성되면, 우리는 그것을 떼어내고, 시스템에 입력해서 백업할 것이다. 그래서 우리가 시스템에 들어갈 때마다 ID 에 따라 이러한 작업을 찾습니다.
2) 작업에 대한 설명입니다. 이것이 바로 이 임무가 해야 할 일이다.
3) 예상 주기 일수는 이 작업을 완료하는 데 걸리는 시간을 예측하는 것입니다. 이 시간에 근거하여, 우리는 모든 임무를 완성할 수 있는 가능한 시간을 추정할 수 있다. 또한 한 번의 반복에서 수행할 수 있는 작업 수를 추정하여 backlog 에서 작업의 우선 순위를 더 잘 지정할 수 있습니다. 일반적인 예상 시간은 개발팀 단체토론으로 주어진 것이다.
4) 실제 주기 일수는 작업을 완료하는 데 실제로 필요한 시간입니다. 이 시간이 예상 주기 일수와 크게 다를 경우 팀 전체가 무엇이 잘못되었는지 검토하고 요약할 것입니다. 문제를 해결할 수 있습니다. 일반적으로 새 조직의 초기 단계에서는 예상 주기 일수와 실제 주기 일수 사이에 큰 차이가 있습니다. 몇 번의 반복 끝에 모두가 서로를 알게 된 후, 어림잡아 볼까? 주기 일수는 점점 더 정확해질 것이다.
5) 작업 우선 순위. 임무를 얻기 위해 먼저 해야 할 일을 정렬하는 데 사용한다. 이는 제품 책임자에 의해 결정되며, scrum 에서는 제품 책임자라고 하고, 기존 프로젝트에서는 비즈니스 사용자라고 합니다. 누가 이 프로젝트를 위해 돈을 지불합니까? 우리의 프로젝트는 제품 팀의 사람들에 의해 결정된다.
6) 임무 책임자. 이것은 명백히 이 임무를 하고 싶은 사람이다.
5. 간판과 스크럼의 차이.
일부 항목은 Scrum 을 사용할 수 있으며 간판보다 훨씬 복잡합니다. 스크럼은 엄격한 역할 정의와 개발 주기 관리를 가지고 있다. 그러나 간판은 사용할 수 없습니다. 개인적으로 Scrum 은 완벽한 개발 관리 프레임워크로, 비교적 완벽하다고 생각하는데, 간판은 개발 프로세스의 관리 도구일 뿐, 다양한 개발 프레임워크에 배치할 수 있다. 다음 그림을 보면 간판과 스크럼 보드의 차이를 비교할 수 있습니다. 여기에는 모든 차이가 포함되지 않을 수 있습니다.
이 문장/iamdll/article/details/18552607 도 볼 수 있습니다.
6. 간판 도구.
간판에는 많은 도구가 있습니다. 직접 온라인으로 가서 찾을 수 있습니다. 우리 프로젝트에서는 주로 물리적 간판, 테레로, 지라를 사용합니다. Dell 프로젝트 중 일부는 아웃소싱되어 있기 때문에 Trero 나 JIRA 와 같은 온라인 도구만 사용하여 공급업체와 커뮤니케이션할 수 있습니다. 만약 네가 자신의 개발팀이라면, 나는 개인적으로 물리적 간판을 사용하는 것을 추천한다.
7. 작업 계약
실제로 작업 계약은 간판에서뿐만 아니라 민첩한 모든 방법론에서도 사용할 수 있습니다. 다만 다른 방법론이나 프로젝트에 적응하기 위해 합의가 달라질 것이다. 본 계약은 팀 또는 개인을 대상으로 하지 않습니다. 이것은 프로젝트에 참여하는 모든 팀을 위한 것이다. 계약은 프로젝트의 꾸준한 진전을 보장할 수 있다. 여기 몇 가지 예가 있습니다.
1) 작업 시작 후 작업 요구 사항을 수정하거나 작업을 바꿀 수 없습니다.
2)2) 작업의 예상 시간은 반복의 나머지 시간 (근무 시간만 포함) 보다 클 수 없습니다.
3) 오전 9 시까지 회사에 도착해서 일을 시작하고 오후 6 시에 사무실을 떠납니다 .....
4) 회의 때 핸드폰을 사용하지 말고 회의 주제에 집중하세요.
5) 회의 기간 동안 회의 주제와 관련된 내용만 토론하여 회의가 제때에 끝날 수 있도록 합니다.
요약
각 프로젝트에는 고유한 환경과 인력 구성이 있습니다. 간판은 각 프로젝트가 자신의 상황에 따라 적합한 사용 방법을 찾을 수 있는 프로세스 관리 도구입니다. 모두가 참여하는 과정에서 더 많은 것을 배울 것이다.