개발자 당 Kanban 보드 사용

Question

저는 소프트웨어 부서에서 일종의 개발 프로세스 방법을 채택하려고 노력해 왔습니다. 우리는 9 명의 개발자와 많은 프로젝트가 있습니다. 현재, 우리는 단지 혼란이라고 할 수 있습니다. 아니면 다른 SO 사용자가 호출 한 것을 보았을 때 '위기 주도 개발'이라고 생각할 수도 있습니다.

칸반을 사용하는 것이 우리에게 적합 할 것 같습니다. 그래서 나는 다른 모든 사람들과 그것을 논의했습니다, 모두는 그것이 좋은 것으로 생각했습니다. 그러나 우리가 이사회가 어떻게 준비되어야하는지에 관해 논의했을 때, 모든 사람들은 한 사람당 하나의 이사회를 원했습니다.

이제는 Kanban 또는 모든 방법론을 실제로 시도한 적이 없지만 각자 자신의 보드에서 관리하는 것이 Kanban 프로세스가 제공해야하는 이점을 무효화하는 것처럼 느낍니다. 이 개념은 저를 슬프게 만들고, '호 - 흠 (hum-hum)은이 모든 아이디어를 고쳐야합니다.'라고 말하고 싶다.

개발자 당 칸반 보드를 구현하는 것이 가치가 있다고 생각하십니까?

Answer 1

보드가 여러 개 있어야하는 경우 개발자 당 보드가 아닌 프로젝트 당 보드를 갖고있는 것이 더 좋지 않습니까? 어쩌면 시간이 지남에 따라 프로젝트의 자연스러운 그룹화 (따라서 이사회의 통합)가 나타날 수 있습니다.

보드의 한 가지 목적은 "정보 복사기"역할을하는 것입니다. 달팽이 페이스로 진행되는 많은 수의 프로젝트 보드는 "우리는 심각하게 과부하되어있다"및/또는 "누군가 우선 순위를 정해야합니다"라는 메시지를 방송합니다. 개발자 당 많은 수의 게시판이 "우리는 여기서 팀워크를하지 않습니다"라는 메시지를 보냅니다.

Answer 2

내 생각에 개발자마다 하나의 보드가 아니라 하나의 Kanban 보드를 사용하는 것이 좋습니다. 이유는 Kanban이 모든 팀 구성원을위한 시각적 도구라는 생각 때문에, 그리고 각 개발자가 자신의 보드를 가지고 있다면 생각이 조금 잘못되었다고 생각하기 때문입니다. 당신이 마이크로 소프트 TFS를 사용하는 경우

Subnote

는, 당신은 사용 Telerik Work Item Manager를 사용할 수 있습니다. 나는 이것을 나 자신으로 사용했고 그것은 훌륭합니다. 각 개발자는 자신의 PC에서이 도구의 사본을 실행하고 작업 항목을 시각적 작업 보드 (색상 포스트잇 포함)에서 볼 수 있습니다. 이 보드는 여러 가지 방법으로 그룹화되고 필터링 될 수 있으므로 개발자는 자신의 모든 작업을 볼 수 있지만 필터를 변경하여 프로젝트의 모든 작업을 볼 수 있습니다. 당신은 TFS의 재미 subnote :

Answer 3

칸반이 시스템을 통해 흐름을 제한하는 시스템으로 실제로 대한 사과를 사용하지 않는 경우

(

우리는 진행 중 WIP (일) 칸반에 대한 제한을 왜 보드와 사람이 한 번에 하나의 직업을 할 수 있기 때문에 나는 이것이 작동한다고 생각하지 않습니다.

개발자 당 한 개의 보드를 가지고 있으면 어떤 이점도 얻지 못합니다. (그리고 저는 그것이 실제로 칸반이 아니라고 주장 할 것입니다). 한 프로젝트 당 하나의 보드가 더 좋은 아이디어입니다.

다른 개발자가 일부 작업에 참여하면 프로젝트의 전반적인 진행 상황을 볼 수 있습니다.

Answer 4

귀하의 그룹과 다른 토론을하는 것이 가치가 있다고 생각합니다. 어떤 종류의 새로운 기술/연습/방법론을 채택하기 전에, 왜 당신이 그것을 채택하기를 원하는지, 그리고 당신이 해결하고자하는 문제에 관해 매우 눈을 뜨게 될 것입니다. Kanban Boards를 우연히 발견하고 해결하려고 시도하는 문제를 실제로 알지 못하는 사이에 채택하려고합니다.

내 충고는 환경에서 볼 수있는 문제에 대해 더 많은 생각이나 분석을 시도하고 가능한 경우 근본 원인 분석을 수행 한 다음 (5-whys와 유사 함) 이러한 문제를 해결하는 데 도움이 될 것입니다.

여러분 그룹의 사람들이 개발자 당 보드 사용을 제안했다는 사실은 나에게 다음과 같은 것을 의미합니다. 그들은 그들이 가지고있는 문제의 종류를 이해하지 못하고 해결하려고 노력하고 있습니다. b. 그들은 간판 보드가 이루고자하는 것을 이해하지 못합니다. 즉, 칸반 보드를 사용하면 문제가 해결되지 않는 문제가 있습니다.

Answer 5

개발자 당 보드를 가지고 있어도 틀리지 않습니다. 보드는 작업을 시각화하기 위해 존재합니다. 개발자가 다른 프로젝트에서 작업하는 경우 별도의 보드로 프로젝트 별 작업을 시각화하는 것이 더 쉬울 것입니다 (일반적으로 그렇습니다). 개발자가 별도의 프로젝트에서 작업하는 경우 별도의 프로젝트에서 작업합니다. 엄밀히 말하면, 그들은 실제로 하나의 팀이 아니라 "연습"입니다. 이러한 관점에서 볼 때, 별도의 보드를 사용하는 것이 더 자연스러운 방법 일 수 있습니다.

내가 개인 프로젝트로 작업 할 때 나는 아직도 서구의 소프트웨어 개발자 (실수로)를 "간판 보드"라고 부르는 Heijunka Box를 사용한다. 나는 작업을 시각화하고 작업 일정을 계획하고 한 번에 작업하고있는 것들의 수를 제한하는 데 도움이됩니다.

Answer 6

저는 Operations Automation을 수행하는 팀을 위해 Kanban을 구현했습니다 (Ops 작업의 절반 정도, Dev 작업의 절반 정도). 여기 우리 팀에서 가장 잘 작동하는 것으로 나타났습니다. 우리는 INBOX/Backlog에 대한 공통적 인 칼럼을 가지고 있습니다. 그런 다음 '개발 중'칼럼은 개발자 당 WIP 제한으로 5 개 섹션으로 나누어집니다. 그런 다음 '통합'을위한 또 다른 공통 열과 '생산으로의 릴리스'를위한 공통 열.

간 반의 장점은 개발자가 자신이 수행하는 작업에 집중할 수 있도록 WIP 제한을 설정한다는 것입니다. 각 개발자는 프로젝트에서 상당히 자율적이지만 INBOX 용 공통 열은 개발자가 새로운 작업, 그리고 나머지 단계를 통해 팀 리드가 변화를 이끌어내는 '통합'/ '생산'을위한 것입니다.

제 생각에는 몇 가지 공통 열 (백 로그 및 릴리스)이 있고 개발자별로 (예 : '개발 중'과 같은) 일부 열이 있어야합니다. 그렇게함으로써 각 개발자는 자신이 작업하고있는 것을 관리 할 수 ​​있으며 동시에 보드는 파이프 라인을 통해 흐르는 모든 작업의 ​​상태를 시각화하는 데 도움을 줄 수 있습니다.

Answer 7

프로세스에 Kanban을 적용하는 가장 중요한 두 가지 이유는 프로세스를 시각화하고 진행중인 작업 (WIP)을 제한하는 것입니다.

개발자 당 하나의 보드가 있다면 개인 kanban 메커니즘에 가깝고 한 번에 한 사람 씩 WIP를 시각화하고 제한 할 수 있지만 팀 수준에서는 개요를 볼 수 없습니다.

프로젝트 또는 팀당 하나의 보드가있는 경우 공유 리소스, 즉 둘 이상의 프로젝트 또는 팀에서 작업하는 사람이 있는지에 따라 보드가 다릅니다. 그렇다면, 당신은 몇 가지 개요를 잃어 버리고, 하나 이상의 보드에있는 사람들의 작업을하는 사람들이 있다면 WIP를 제한함으로써 얻을 수있는 몇 가지 이점이 있습니다. F.ex. 병목 현상은 더보기 힘들다.

Answer 8

실제로 최소한 2 ~ 3 개 팀을 만들고 각 팀에 하나의 프로젝트에만 영향을주고 프로젝트별로 하나의 보드에만 영향을줍니다. 프로젝트 상태를 관리하는 또 다른 이사회.

다시 시작하려면 : 프로젝트별로 하나씩 모든 작업이 있으며, 하나는 프로젝트 상태에 따라 개발자와 관리자가 서로 통신하는 데 도움이됩니다.