WordPress 개발에 Kanban 사용

당신은 "슬레이트를 깨끗이 닦는" 사람입니까? 월요일이나 1월 1일, 새해에 새롭게 시작하겠다고 몇 번이나 말했습니까? 여기에 비밀이 있습니다. 작동하지 않습니다.

슬레이트를 깨끗이 닦을 수도 없고, 원해서도 안 됩니다. 당신은 과거에 당신이 한 일 덕분에 여기까지 왔습니다. 네, 아마도 더 효율적인 방법이 있을 것입니다. 하지만 당신이 이룬 모든 진전을 취소한다고 해서 그것을 발견할 수는 없을 것입니다.

이것이 내가 칸반 시스템을 좋아하는 이유입니다. 2019년 초에 워크플로를 점검하기 위해 사용하기 시작했고 푹 빠졌습니다. 조직을 유지하고 업무를 처리해야 하지만 상황이 많이 바뀔 것임을 알고 있는 유형의 팀에 적합합니다.

이 기사에서는 WordPress 개발 팀을 위한 칸반에 초점을 맞출 것이지만, 내가 사용하는 몇 가지 샘플은 내 작성 워크플로를 중심으로 만들어진 내 자신의 칸반 보드에서 가져온 것입니다.

칸반이란?

칸반 개발을 이해하려면 먼저 린 사고를 이해해야 합니다.

린 사고 는 방법론이 아닙니다. 대신 프로젝트의 컨텍스트를 구성하는 가치를 기반으로 하는 사고 방식입니다. 7가지 린 값은 다음과 같습니다.

1. 프로젝트에 가치를 추가하지 않는 모든 것을 제거하여 낭비를 제거하십시오.
2. 프로세스를 개선하기 위해 정기적으로 피드백을 수집하여 학습을 증폭합니다.
3. 결정을 알리기 위해 모든 정보를 수집한 후 가능한 한 늦게 결정하십시오.
4. 팀 사기나 제품 품질을 희생하지 않고 최대한 빨리 제공합니다. 이것은 속도만이 아니라 효율성과 지속 가능성에 관한 것입니다.
5. 팀에 권한을 부여하고 개발자의 건강과 에너지를 보장하며 전문성과 리더십을 기반으로 승진합니다.
6. 직관적이고 가치 있는 경험을 만드십시오.
7. 개별 기능뿐만 아니라 전체 프로젝트를 평가하여 전체 그림을 보십시오.

린 사고 방식을 사용하는 팀은 종종 워크플로 관리에 칸반 방법을 사용합니다. 하드 카피 색인 카드로 칸반 보드를 설정하거나 Asana 또는 Trello와 같은 도구를 사용하여 디지털 칸반 보드를 만들 수 있습니다. 다른 열을 설정하여 워크플로를 만든 다음 작업이 완료되면 워크플로를 통해 카드를 왼쪽에서 오른쪽으로 이동합니다.

출처: 아사나

가장 기본적인 칸반 보드에는 세 개의 열이 있습니다.

• 할 것
• 행위
• 완료

고급 칸반 보드를 사용하면 추가 열을 가질 수 있으며 각 카드에는 완료해야 할 고유한 하위 작업 세트가 있을 수 있습니다. 다음은 내 Asana의 카드에 있는 일부 하위 작업의 예입니다.

칸반은 작은 작업 대신 더 큰 작업 항목을 추적하는 경향이 있기 때문에 시작 및 종료 날짜, 담당자 및 지원 문서와 함께 하나의 카드에 여러 하위 작업 및 지침이 필요한 것이 일반적입니다.

칸반 원칙

Kanban 개발은 진화하는 프로세스를 설정하는 방법입니다. 즉석에서 특정 작업을 수행하여 즉각적인 변경을 요구하지 않습니다. 또한 백지 상태로 시작하지 않습니다. 대신 현재 프로세스와 팀 구조를 기반으로 하고 조정합니다.

네 가지 기본 칸반 원칙이 있습니다.

1. 현재 프로세스로 시작하십시오. 현재 따르고 있는 단계, 정책 및 규칙을 포함합니다. 이것은 앞으로 변경될 수 있지만 그것이 칸반 개발의 요점입니다. 즉, 진화하는 것입니다.
2. 팀은 점진적이고 진화적인 변화에 전념해야 합니다.
3. 최소한 당분간은 직위, 역할 및 책임을 존중하고 유지하십시오. 팀 구조는 프로세스를 조정함에 따라 변경될 수 있습니다.
4. 모든 수준의 팀원들이 적절할 때 이끌도록 격려하십시오.

간판 관행

6가지 핵심 칸반 관행이 있습니다.

1. 현재 프로세스의 각 단계와 일치하는 열을 만들어 프로젝트를 시각화합니다.
2. 각 열에 있는 활성 작업 항목의 수를 제한하려면 한도를 설정하십시오. 이렇게 하면 현실적인 속도를 만드는 데 도움이 되며 팀 구성원이 산만하거나 압도당하지 않고 가장 중요한 작업 항목에 집중할 수 있습니다.
3. 카드가 전반적으로 얼마나 빨리 이동하는지 측정하고 병목 현상이나 낭비가 있는지 평가하십시오.
4. 모든 팀 구성원에게 정보를 제공할 수 있도록 프로세스의 단계, 정책 및 규칙을 정의합니다.
5. 피드백 루프를 구현하고 필요한 프로세스를 조정합니다.
6. 공동으로 개선하고 빠르게 발전하십시오. 이 관행은 팀이 전체적으로 의사 결정을 내릴 수 있도록 네 가지 원칙을 결합합니다.

워드프레스 개발을 위한 칸반

보드 만들기

WordPress 개발에 kanban을 사용하려면 프로세스를 특정 개발 단계로 나누어야 합니다. 이를 수행하는 가장 쉬운 방법은 이미 제공한 기능을 살펴보고 각 개발 단계를 나열하는 것입니다. 다음은 소프트웨어 엔지니어 Harrison Ferrone의 예입니다.

그런 다음 각 단계를 사용하여 간판 보드에 열을 생성합니다. 다음은 버그 추적에 사용되는 Asana의 예시 칸반 보드입니다.

다음은 WordPress 개발 간판 보드에 대한 추가 열 아이디어입니다.

• 백로그: 구현되거나 구현되지 않을 수 있는 아이디어
• 필수: 개발 아이디어
• 디자인을 위한 준비: 명확하고 다음 단계로 나아갈 수 있는 아이디어
• 진행 중: 설계, 코딩 및 생산 단계에 대해 별도의 "진행 중" 열을 가질 수 있습니다.
• 검토 준비 완료: 각 단계에 대해 별도의 "검토 준비 완료" 열을 가질 수 있습니다.
• 검토 중: 각 단계에 대해 별도의 "검토 중" 열을 가질 수 있습니다.
• 필요한 변경 사항: 더 많은 작업이 필요한 반품된 항목
• 완료

우선 순위에 따라 카드를 분류할 수도 있습니다. Asana 및 Trello와 같은 도구에는 이를 위한 색상 코딩이 있습니다. 버그, 고객 기능 및 고객 문제와 같은 범주의 우선 순위를 지정할 수 있지만 팀에 가장 적합합니다.

진행 중인 작업 한도 설정

칸반 보드 설정은 워크플로 구성의 시작일 뿐입니다. 전체 개발 팀은 칸반 보드를 사용하는 방법과 각 단계에서 기대되는 사항을 이해해야 합니다. 이는 병목 현상이 발생하거나 다른 열보다 빠른 속도로 작업이 쌓이는 열을 발견한 경우 특히 중요합니다. 팀 구성원이 충분히 효율적으로 작업하고 있다고 믿는다면 이러한 상황을 방지하기 위해 진행 중인 작업(WIP) 제한을 설정해야 할 수 있습니다.

예를 들어 "테스트 및 검증" 단계는 프로세스의 이 부분이 다른 부분보다 오래 걸리는 경우 병목 현상이 될 수 있습니다. 솔루션은 해당 열, 그 앞의 열 또는 전체 간판 보드에 대한 WIP 제한을 설정하는 것입니다. "기능 빌드" 및 "테스트 및 검증" 열을 각각 5개로 제한할 수 있습니다. 그렇게 하면 한 번에 5개 이하의 기능을 구축할 수 없으며 한 번에 테스트 및 검증이 필요한 기능을 5개 이하로 만들 수 있습니다. 기능에 대한 테스트 및 유효성 검사가 완료되면 "빌드" 열에서 다른 작업 항목을 이동할 수 있습니다. 이렇게 하면 한 곳에 얽매이지 않고 워크플로가 계속 진행됩니다.

Kanbanize에 따르면 WIP 제한을 설정하는 좋은 경험 법칙은 개발자를 2배로 늘리는 것입니다. 10명의 개발자가 있는 경우 주어진 시간 동안 최대 20개의 프로젝트를 설정합니다. 제한을 낮추는 것이 효율성에 더 좋지만 너무 낮게 설정하여 다른 개발자가 작업 항목을 완료할 때까지 기다리는 동안 팀이 할 일이 없도록 하십시오.

간판 개발 모범 사례

WIP 한도에 대한 구체적인 내용과 근거를 포함합니다. 팀원들이 필요할 때 참고할 수 있도록 게시판에 직접 작성할 수 있습니다. 예를 들어, 내 고객 중 한 명이 열 상단에 있는 카드에 하루에 청구할 수 있는 기사 수와 기사가 일주일 내내 게시판에 추가되는 요일과 시간을 설명하는 지침이 있습니다.

카드가 한 보드에서 다음 보드로 이동해야 하는 시기를 명확히 합니다. 나는 이것을 내 카드 중 일부의 하위 작업에 바로 내장했으며 이전 하위 작업이 완료된 후에만 카드를 이동하는 것으로 알고 있습니다.

보다 구체적인 매개변수를 설정할 수도 있습니다. 예를 들어, 난 단지 문서는 지불하면 내 포트폴리오에 기사의 게시 된 링크를 추가 한 경우 "완료"열에 카드를 이동할 수 있습니다.

열 간에 앞뒤로 충돌하는 작업 항목을 고려하도록 워크플로를 확장합니다. "코드 검토" 열에 항목이 있다고 가정해 보겠습니다. 코드 검토에 실패하면 "기능 빌드"와 같은 이전 열로 돌아가야 합니다. 이런 일이 많이 발생하면 새로운 종류의 병목 현상이 발생하지만 WIP 한도를 낮게 설정하면 충분한 작업을 수행할 수 없습니다.

해결책은 "Failed Code Review" 및 "Second Code Review"와 같은 새 열을 만드는 것입니다. 그런 다음 기능이 초기 코드 검토를 통과하면 다음 단계로 바로 이동하고 방금 추가한 두 개의 추가 열을 건너뛸 수 있다고 팀에 알립니다. 또는 워크플로 시작 부분에 새 열을 추가하여 실패한 리뷰를 수집하고 프로세스를 다시 푸시하거나 프로세스 내에 "수정" 열을 추가하여 이러한 문제를 해결할 수 있습니다. 최고의 솔루션은 맞춤형 프로세스와 함께 작동하는 솔루션입니다.

마무리

똑같은 일을 하는 두 개발 팀이더라도 한 가지 유형의 칸반 보드는 없습니다. 이것이 바로 이 제품의 장점입니다. 필요에 따라 완전히 맞춤화한 다음 필요가 증가하고 변경됨에 따라 조정할 수 있습니다. 전반적으로 칸반 개발은 사용자가 원하는 것을 만들어야 하는 팀에 탁월합니다. 이러한 기능을 적시에 제공합니다. 지속 가능한 워크플로 속도를 만듭니다.

개발 워크플로가 원활해지면 생산성 향상을 위해 디지털 작업 공간을 설정하는 방법을 배우십시오.