Kanban 및 Trello를 사용한 소프트웨어 개발 관리 초보자 가이드

모두가 프로젝트 관리자입니다. 새로운 애플리케이션의 개발을 관리하고 스타트업을 성장시키든, 새로운 10억 달러 규모의 기업 프로젝트에서 작업하든, 아니면 DIY 조경으로 마당을 활기차게 만들려고 하든 항상 프로젝트를 관리하고 있습니다.

프로젝트의 성공은 여러 요인에 달려 있지만 프로젝트가 실패하는 가장 일반적인 이유 중 하나는 관리 부족 또는 완전히 잘못된 프로젝트 관리입니다. 팀이 아무리 작거나 요구 사항이 문서화되어 있더라도 팀을 제대로 관리하지 않으면 프로젝트는 실패할 수 있습니다.

애자일 프로젝트 관리는 현대 소프트웨어 개발 프로젝트에 접근하는 널리 인정되는 방법입니다. 그러나 Agile은 실제로 무엇을 의미합니까?

애자일 원칙에 대해 더 자세히 알아보려면 애자일 프로젝트 관리에 대한 궁극적인 가이드를 읽는 것이 좋습니다.

이번 포스트에서는 Kanban을 활용한 애자일 프로젝트 관리의 기본에 대해 설명하겠습니다.

애자일 원칙을 안팎으로 이해하는 경험 많은 프로젝트 관리자라도 기억을 새로고침하고 핵심 개념을 상기시켜야 합니다. 소프트웨어 개발의 혁신 주기는 지속적으로 빨라지고 있어 반복할 때마다 프로젝트 관리가 더욱 복잡해집니다. 애자일의 기본 원칙으로 돌아가서 핵심 원칙을 공고히 하는 것은 항상 중요합니다. 결국 반복은 모든 지식의 어머니입니다.

Kanban은 Agile 소프트웨어 개발 프로젝트를 관리하는 가장 쉬운 방법 중 하나입니다. 여러 시간대에 분산되어 있는 같은 사무실이나 분산된 팀에서 작업하는 로컬 개발 팀을 쉽게 처리할 수 있습니다.

칸반은 프로세스가 아닙니다. 이는 팀의 확립된 운영 활동에 대한 최소한의 변경으로 모든 프로세스를 관리하는 방법입니다.

Kanban 원칙을 작업에 적용하려면 두 가지 간단한 규칙을 적용해야 합니다.

1. 프로세스를 시각화하십시오.
2. 진행 중인 작업을 제한합니다.

프로세스 시각화

데이터 시각화는 보편적이고 이해하기 쉬운 방식으로 정보를 빠르고 쉽게 전달할 수 있는 방법입니다. 사진을 볼 때 인간의 뇌는 동시에 여러 정보를 처리할 수 있습니다. 일부 연구에서는 이것이 텍스트를 읽는 것보다 최대 60,000배 더 빠를 수 있다고 말합니다.

프로세스를 시각화하는 가장 일반적인 방법은 Kanban Board입니다. Kanban 보드는 수직으로 여러 열로 나누어진 보드로, 각 열은 프로세스의 한 상태를 나타냅니다.

간단한 소프트웨어 개발 보드가 어떻게 생겼는지 살펴보겠습니다. 먼저 개발 기능의 상태를 정의해야 합니다.

1. 할 일 - 기능이 개발 대기 중입니다.
2. 개발 - 기능이 개발자에게 할당되고 개발자가 작업 중입니다.
3. 품질 보증 - 기능 검토 중
4. 배포됨 - 기능이 승인되어 애플리케이션 릴리스에 포함됨

이를 기반으로 보드의 레이아웃은 다음과 같아야 합니다.

개별 작업을 시각화하는 것은 수행해야 할 작업을 나타내는 간단한 카드(포스트잇과 유사)를 만드는 것만큼 쉽습니다. 작업 이름을 지정하고 할당된 개발자의 이름, 기한 및 기타 관련 정보를 이 카드에 추가할 수 있습니다.

칸반 보드의 열에 해당 카드를 추가하면 예를 들어 특정 개발자가 특정 날짜에 마감되고 현재 개발 중인 특정 작업을 수행하고 있다는 것을 시각화한 것입니다.

진행 중인 작업 제한(WIP)

인간의 멀티태스킹은 망상입니다. 우리의 두뇌는 동시에 한두 가지에 주의를 기울이는 대신 매우 빠르게 전환합니다.

이것은 다른 어느 곳보다 소프트웨어 개발에서 더 많이 볼 수 있습니다. 개발자는 한 번에 하나의 코드에서만 작업할 수 있으며 다른 기능으로 전환하면 지연이 발생하고 집중도와 성능에 영향을 미칩니다.

그렇다고 해서 할당 수를 한 번에 하나만으로 제한해야 하는 것은 아닙니다. 개발은 복잡하고 창의적인 작업이며 일부 작업은 완료하는 데 시간이 더 걸리고 다른 작업은 완료하는 데 시간이 덜 걸리며 개발자가 무언가 또는 누군가를 기다리는 동안 항상 지연이 있습니다. 중요한 것은 할당된 작업을 혼란을 일으키지 않는 합리적인 수로 제한하는 것입니다(일반적으로 한 번에 3-5개의 할당).

개발 팀이 두 명의 개발자와 QA 엔지니어로 구성되어 있다고 가정하면 보드에 다음과 같은 WIP 제한이 있을 수 있습니다.

• 할 일 - 무제한
• 개발 - 6개 카드 제한(2명의 개발자가 각각 최대 3개의 작업으로 제한됨)
• 품질 보증 - 카드 3장 제한(QA 엔지니어 1명은 최대 3장의 카드로 제한됨)
• 배포됨 - 무제한

해야 할 일 목록의 우선 순위를 적절하게 지정하고 필요한 것보다 빨리 개발자에게 작업을 할당하는 것은 프로젝트 관리자의 임무입니다.

적절하게 관리되는 칸반 보드는 프로젝트 상태를 한 눈에 명확하게 보여줍니다. 개발자의 작업이 충분하고 할당이 완료되면 맡을 수 있는 새 작업을 준비했으며 QA 엔지니어가 검토할 새 작업을 기다리고 있음을 알 수 있습니다.

Trello를 사용하여 Kanban 보드 관리

Trello는 웹 기반 Kanban 프로젝트 관리 응용 프로그램입니다. 팀 구성원은 물론 여러 팀과 프로젝트 간에도 쉽고 실시간으로 협업할 수 있습니다.

Trello에서 보드를 만들려면 "새 보드 만들기..." 메뉴 항목을 클릭하고 보드 제목을 설정합니다.

빈 보드로 시작합니다. "목록 추가 ..." 상자를 사용하여 Kanban 카드에 대한 열을 만듭니다.

목록 하단에 있는 "카드 추가..."를 클릭하면 작업을 쉽게 생성할 수 있습니다. 생성하는 각 카드는 팀 구성원이 실행할 작업을 나타내야 합니다.

Trello의 카드는 다양한 방식으로 사용자 지정할 수 있습니다.

• 작업 실행을 담당하는 팀 구성원 지정
• 추가하려는 특정 그룹에 따라 색상 코드 지정
• 마감일 설정
• 첨부 파일 추가
• 작업을 구성하는 더 작은 요소의 진행 상황을 추적할 수 있는 체크리스트와 같은 사용자 정의 필드 추가
• 팀 구성원은 카드에 댓글을 달 수 있으며 변경 사항이 있으면 모든 사람에게 알림이 전송됩니다.

시각화는 Kanban의 모든 것이므로 다음은 보드에서 카드가 어떻게 보이는지 보여줍니다.

상세 보기를 열지 않고 카드만 보면 다음을 확인할 수 있습니다.

1. GitHub Code Repository 설정 작업이 To-Do 목록에서 실행 대기 중입니다.
2. 작업은 1월 27일까지입니다.
3. 작업에 설명이 있습니다.
4. 작업에 대한 하나의 의견이 있습니다.
5. 두 항목의 체크리스트가 있으며 이 항목 중 어느 것도 현재 완료되지 않았습니다.
6. 작업은 다음에 선택할 사용자 DS에게 할당됩니다.
7. 작업은 녹색 카드 그룹에 속하므로 프로젝트가 시작되기 전에 필요합니다.

개발 작업의 시간 및 복잡성 추정

특정 작업을 완료하는 데 필요한 노력과 시간을 이해하지 않고는 프로젝트를 계획하고 관리할 수 없습니다. 그러나 소프트웨어 개발에서 가장 어려운 일 중 하나는 새로운 소프트웨어 제품이나 기능을 제공하는 데 걸리는 시간을 결정하는 것입니다.

가장 인기 있는 애자일 원칙 중 하나인 스크럼은 시간을 기반으로 하든 "복잡성 지점"을 기반으로 하든 상관없이 추정에 크게 의존합니다.

팀은 작업 범위를 지정하는 데 상당한 시간을 할애해야 합니다.

이는 스크럼이 특정 작업 그룹이 완료될 것으로 예상되는 시간 간격을 기반으로 하기 때문입니다. 배송을 계획하려면 해당 타임 박스에 대해 계획된 모든 작업을 완전히 이해해야 합니다.

Kanban은 정시 배송에 의존하지 않으며 원하는 경우 매일 배송을 계획할 수 있습니다. 이는 흐름 최적화에 의존하므로 팀의 초점은 가능한 한 빨리 WIP 열을 완료하고 비우는 것입니다.

팀은 일을 미리 예측하는 데 시간을 많이 들이지 않습니다. 개발자는 To-Do에서 다음 항목을 선택합니다. 가능한 한 빨리 완료하십시오. 그리고 다른 작업을 선택합니다.

그렇다고 해서 팀이 워크로드의 양을 추정해서는 안 된다는 의미는 아닙니다.

주간 또는 일일 통화를 사용하여 기한을 업데이트하고 확인할 수 있습니다.

그러나 소규모 팀의 경우 개발자가 주어진 순간에 가장 우선 순위가 높은 작업을 수행하고 있고 병목 현상이 없어 개발자가 작업을 일시 중지하도록 하는 것이 더 중요합니다.

결국에는 프로젝트가 커질 것이고 개발 작업의 양을 더 자세히 추정하기 시작해야 합니다. 이 상황에 도달하면 Agile 프로젝트 관리의 소프트웨어 비용 추정 가이드를 읽는 데 시간을 할애하십시오.

필수 관리 관행

지금까지 프로세스를 시각화하고 WIP를 제한하는 것의 중요성과 Trello를 사용하여 프로젝트를 관리하는 방법에 대해 배웠습니다.

그러나 소프트웨어 프로젝트는 카드와 열로만 관리할 수 없습니다. 따라서 Agile 모범 사례도 구현하는 것이 중요합니다.

• 정기적인 팀 회의를 조직합니다.
  수행한 작업을 검토하고 필요한 경우 백로그(할 일 목록)를 수정하고 우선 순위를 지정하기 위해 최소한 매주 이 작업을 수행합니다. 이렇게 하면 전체 팀이 동시에 업데이트를 받고 아이디어를 공유할 수 있습니다. 이러한 회의에서는 프로젝트 이해 관계자(클라이언트, 회사 CTO 또는 결정을 내리고 질문에 답할 수 있는 제품 팀의 모든 사람)가 궁극적으로 비기술적 피드백을 제공하도록 하는 것이 중요합니다.

• 개별 팀 구성원과 지속적인 의사 소통을 보장합니다.
  이렇게 하면 모든 사람의 일상 업무가 훨씬 쉬워집니다. 이러한 회의 또는 동기화를 매우 짧고 간단하게 유지하고 좋아하는 채팅 프로그램을 빠르게 업데이트하면 됩니다. 매일 15분 내외의 팀 회의가 가능한 일일 체크인을 하는 것이 유용합니다. 이 회의에서 모든 팀원은 몇 초 동안 다음과 같이 말합니다.

통화 중에 메모를 하고 가능한 문제(차단, 작업에 대한 잘못된 집중, 예기치 않은 기술적 문제)를 찾고 팀과 함께 작업할 수 있도록 주의를 기울이십시오.

소프트웨어 개발 프로젝트 부트스트랩

모든 소프트웨어 개발 프로젝트는 다르지만 거의 모든 프로젝트에서 특정 작업을 찾을 수 있습니다. 다음은 소프트웨어 개발 프로젝트를 시작할 때 계획해야 하는 몇 가지 작업입니다.

• 코드 버전 관리 및 리포지토리를 설정합니다.
  변경 내용을 추적하고 코드를 모니터링하는 것은 특히 여러 사람이 동일한 코드를 업데이트하는 프로젝트에서 공동 작업할 때 매우 중요합니다.
  
  코드 버전 관리를 위한 가장 인기 있는 서비스 중 하나는 GitHub입니다. GitHub는 Git의 모든 분산 버전 제어 및 소스 코드 관리(SCM) 기능을 제공하는 웹 기반 Git 또는 버전 제어 리포지토리입니다.
  
  모든 프로젝트에 대한 액세스 제어 및 버그 추적, 기능 요청, 작업 관리 및 Wiki와 같은 여러 협업 기능을 제공합니다.

• 데이터베이스 백업 정책을 정의합니다.
  GitHub와 같은 서비스를 사용하면 코드가 정기적으로 백업됩니다.
  
  데이터베이스는 일반적으로 버전 관리 시스템의 일부가 아니므로 데이터베이스 백업도 자주 설정해야 합니다.
  
  개발 프로세스는 오류가 발생하기 쉽고 개발 중에 실수를 하고 잘못된 데이터를 업데이트하기 쉽습니다. 백업이 있으면 이러한 문제가 발생할 경우 문제를 줄일 수 있습니다.

• 협업 도구 및 파일 공유를 설정합니다.
  프로젝트 문서, 기능 사양, 디자인 파일 및 프로젝트 개발 중에 사용되는 기타 문서와 파일은 지속적으로 업데이트되며 팀에 배포해야 합니다.
  
  다양한 서비스를 사용하여 이러한 파일을 공유할 수 있습니다. Google은 이 문제에 대한 간단하고 비용 효율적인 솔루션을 제공합니다. Google 드라이브, Google 문서, Google 스프레드시트 및 기타 Google 앱을 사용하여 파일을 공유하고 공동작업하세요.

• 별도의 개발 및 테스트 서버를 설정합니다.
  개발 프로세스는 항상 계속되어야 합니다.
  
  개발자는 애플리케이션 테스트의 결과를 기다리지 말고 품질 보증이 완료된 기능을 검토하는 동안 할당 작업을 계속해야 합니다.
  
  동시에 클라이언트는 개발팀을 기다리지 않고 언제든지 애플리케이션의 현재 상태를 확인할 수 있어야 합니다. 정기적으로 업데이트되는 전용 테스트 서버를 보유하면 이 프로세스의 모든 병목 현상이 제거되고 팀이 중단 없이 운영될 수 있습니다.

• 주간 팀 호출에 대해 고정 시간을 정의하고 일일 팀 캐치업 호출 또는 채팅에 대해 고정 시간을 정의합니다.
  모든 팀 구성원이 캘린더에서 통화 및 회의 시간을 예약하도록 합니다. 이를 통해 팀은 작업 중단 없이 안정적인 일정을 유지할 수 있습니다.

테이크아웃

프로젝트 관리는 복잡하고 매우 스트레스가 많은 활동입니다. 여기에 구조를 추가하고 프로젝트 상태를 항상 가시적이고 정확하게 만들면 이러한 스트레스를 상당 부분 완화할 수 있습니다. 적절한 도구와 결합된 Kanban 방법과 Agile 원칙을 사용하면 많은 시간을 절약할 수 있습니다.

즉, 프로젝트 관리자로서 프로젝트 관리에 전념해야 하는 시간을 보상할 도구나 방법론은 없습니다.

프로젝트가 작다고 해서 반드시 시간이 덜 필요한 것은 아닙니다. 이러한 사고방식은 큰 골치거리에 대한 훌륭한 처방입니다.

다음은 프로젝트가 제대로 관리되고 있는지 확인하는 데 도움이 되는 간단한 체크리스트입니다.

1. 프로세스가 제대로 시각화되어 있습니까?
2. 각 팀원에 대한 WIP가 제한되고 최소화됩니까?
3. 귀하의 팀은 매주 또는 매일 일정하게 일정이 잡힌 회의를 갖고 있습니까?
4. Kanban 보드는 정기적으로 업데이트됩니까?
5. 코드 저장소가 있습니까?
6. 데이터베이스 백업을 예약했습니까?
7. 팀 커뮤니케이션 및 협업 도구를 설정했습니까?
8. 개발 환경이 테스트, 승인 및 프로덕션과 분리되어 있습니까?

이 목록은 명확하지 않고 완료되지 않았음을 명심하십시오. 그것은 시작에 불과합니다.

소프트웨어 개발 팀의 역량을 강화하기 위한 끝없는 여정을 막 시작하는 프로젝트 관리자에게 의견을 남기고 팁과 사례를 공유하십시오.