초기 디자인 과정 없이, 스프린트에서 일관적인 디자인을 확보하는 것

이 글은 아래 Mike Cohn의 블로그 글을 번역한 것입니다.

지난 포스팅에서, ‘UI 디자인을 스프린트에 포함시키는 것‘에 대해서 이야기했다. 디자이너가 현재 진행되는 스프린트에서 팀의 일원으로 일해야 하지만, 일부 시간(아마도 대부분) 동안 다음 스프린트에서 해야 할 것을 앞서 살펴야 한다고 말했다.

그러나 이것은 이 글에서 언급하려 하는 우려를 제기한다. 그 우려는 “전체 제품을 디자인하는 초기 단계 없이, 어떻게 일관된 디자인을 보장하는가”이다.

의도적으로 디자인을 가이드하자

첫째, 디자이너는 의도적으로 시스템의 디자인을 가이드한다. 애자일 프로젝트는 초기 디자인 단계를 두지 않기 때문에, 디자인이 창발적이라고 말한다. 즉, 디자인은 시간이 지나면서 점차 나타난다. 디자인은 프로젝트의 어느 하나의 단계에서 만들어지지 않는다.

하지만, 디자인이 무작위로 나오는 것은 아니다. 디자인은 디자이너의 숙련된 의도에 의해 가이드 되어 나타난다. 디자이너는 전체 시스템의 영역을 확인하고 전체 영역을 먼저 디자인한다. 그런 다음 팀이 디자인을 구현하도록 팀과 협력하고, 실제 사용자의 피드백을 반영하여 디자인해야 하는 다음 영역을 발견한다.

이 프로세스는 점진적이고 반복적으로 지속된다. 핵심은 디자이너가 의도적으로 각 영역을 선택하여 남아있는 다지인 이슈에 대한 인사이트를 제공하는 것이다. 즉, 디자인은 무작위로 진행되지 않는다.

조각 그림 퍼즐이 어떻게 완성되는지 생각해보자. 무작위로 조각을 집어 들고 서로 매칭시켜 퍼즐을 완성하지는 않을 것이다. 아마도 먼저 모서리의 퍼즐 조각을 찾고, 그다음 가장자리를 찾는 등의 작업을 할 것이다. 전체 테두리의 윤곽을 그리면, 구체적인 색상 선정이나 패턴으로 이동할 수 있을 것이다. 이 접근법은 창발적이며 의도 적라고 할 수 있다.

빠른 피드백을 반영하기 위해 증분을 배포하자.

디자이너가 애자일 프로젝트를 통해 얻을 수 있는 큰 이점은 프로세스 초기부터 실제 사용자의 현실적인 피드백을 얻을 수 있다는 것이다. 전체 시스템을 미리 디자인할 수 있는 것을 포기하는 대신, 그 대가로 디자이너는 매우 가치있는 것을 얻는다. 즉, ‘피드백을 얻을 수 있는 기회’이다.

디자이너가 이러한 피드백이 유용하다는 것을 학습해가면서, 프로세스의 마지막 단계에서 제품의 일부를 변경할 수 있는 것이, 초기 디자인 단계에서 전체 디자인을 하는 이점을 능가한다는 것을 알게된다.

전체를 생각하고, 점진적으로 일하자

소설가 E. L. 닥터로는 “소설을 쓰는 것은 밤에 자동차를 운전하는 것과 같다, 차의 전조등이 비춰주는 데까지만 볼 수 있지만, 그런 방식으로 목적지까지 갈 수 있다”라고 말했다.   제품 디자인에도 마찬가지라고 생각한다.

디자이너는 전체 여정에 대한 비전을 가져야 하지만, 단지 전조등이 밝혀 주는 정도의 앞까지만 보면서 나아갈 수 있다.

애자일 프로젝트에서, 디자이너는 전체적으로 생각하지만, 점진적으로 작업할 필요가 있다. 디자이너와 소설가는 궁극적으로 어디로 향하는지 알지만, 특정 거리의 앞만 보면서 그곳에 도착하게 된다.

스프린트에 UI 디자인을 포함하는 것

이 글은 아래 Mike Cohn의 블로그 글을 번역한 것입니다.

최근에 많이 들었던 질문 중 하나는 UI 디자이너가 스크럼 팀에 속해야 하는지, UI 디자이너의 작업을 스프린트의 일부로 포함해야 하는지에 대한 것이다. 큰 주제다. 바로 본론으로 들어가자.

스프린트의 두 가지 목표

팀이 각 스프린트에서 해야 하는 두 가지 목표가 있다.

  • 새로운 기능을 구현하는 것
  • 새로운 지식을 쌓는 것

우리 모두는 팀이 각 스프린트마다 새로운 기능을 구현해야 한다는 것을 알고 있다. 즉, 대부분의 프로젝트 목적은 결국 새로운 기능을 사용자에게 제공하는 것이다.

그러나, 팀은 또한 새로운 지식을 쌓아야 한다. 팀은 시작한 것보다 훨씬 더 스마트하게 스프린트를 끝내야 한다. 때때로 팀은 사용 중인 기술이나 팀이 개발한 기능을 사용자가 어떻게 바라보는지 학습한다. 다른 경우, 팀은 팀 스스로에 대해 그리고 팀의 성과가 어떤지 학습할 수 있다.

두 가지 목표 모두 중요하다.

스프린트 기간 동안 UI 디자이너가 해야 하는 것

각 스프린트 동안, UI 디자이너는 기능을 구현하고 지식을 쌓는 두 가지 목표를 추구해야 한다. 스프린트 내에서 UI 디자이너는 다음 피쳐 (또는 그다음 피처까지)에 대해 생각하는 동안, 동시에 나머지 팀원이 디자인을 개발과 테스트 코드로 옮기는데 도움을 주어야 한다. 이것은 디자이너가 이번 스프린트에 참여하기도 하고 다음 스프린트에서 진행할 작업을 미리 내다보기도 한다는 것을 의미한다.

결과는 아래 그림과 같다. 이 그림은 제품 백 로그의 일부분을 구현하고 테스트하는 동안 UI 디자이너는 다가오는 제품 백로그를 좀 더 자세히 들여다보는데 일부 시간(아마도 대부분 시간)을 할애하는 것을 보여준다. 그러나, 여전히 한 번에 하나의 스프린트에서 일하는 한 팀이다.

UI 디자이너의 최우선 과제는 현재 스프린트의 작업이어야 한다. 팀원이 현재 스프린트에서 작업중인 제품 백 로그 항목에 대해 디자인 설명이 필요하다고 하면, 디자이너는 다음 스프린트에 대해 생각하는 것을 잠시 멈추고 현재 스프린트의 작업에 대한 질문에 답한다.

다른 역할은 어떤가?

잠시 멈추고 방금 UI 디자이너에 대해 언급한 모든 것을 고려하자. 그러나 이제 제품 소유자, 분석가, 데이터베이스 디자이너, 건축가 또는 프로젝트에 다가오는 것에 대해 미리 생각해야 하는 중요한 책임이 있는 사람에 대해 생각해보자.

모든 것이 여전히 적용된다. 다만 양의 차이일 뿐이다. 다자이너는 지식을 쌓는데 대부분의 시간을 할애할지도 모르지만, 기능을 구현하는 것에 여전히 시간을 할애한다. 그리고 직전에 언급 한 다른 역할 중 하나는 그 반대 일 수 있다. 애자일 프로젝트의 모든 역할자들은 자신의 시간을 기능을 구현하는 것과 지식을 쌓는 것에 나눠서 할애할 것이다.

디자인을 완벽하게하는 것을 피하자

UI 디자이너에게 앞을 내다볼 수 있는 권한을 주었을 때, 팀은 디자이너에게 디자인을 완료하도록 요구하지 않는다. 대신에, 디자이너는 제품 백로그 아이템이 다음 스프린트에서 팀원들에 의해서 완료될 수 있을 만큼만 미리 해둔다.

스프린트 끝에, 팀은 “디자이너로부터 충분한 정보를 얻지 못했다면, 스프린트 내에 제품 백로그 아이템을 완료하는 것이 불가능했을 거야”라고 느껴야 한다. 이것은 일부 제품 백로그 아이템은 방대한 세부 사항 (그리고 하나 이상의 앞 선 스프린트)으로 여겨야 하는 반면, 다른 것들은 미리 할 필요가 전혀 없다는 것을 의미한다.

또한 디자이너가 현재 스프린트를 넘어서 살펴보게 되는 아이템은 제품 소유자와 상의하여 선택해야 한다. 디자이너는 제품 소유자가 후에 불필요하다고 여기는 작업을 피하고 싶어 한다.

이것이 나쁜 디자인을 유도하는가?

일반적인 우려는 이것이 나쁜 설계로 이어질 수 있다는 것이다. 디자이너가 전체 시스템에 대해 앞서 총체적으로 생각할 수 있다면 더 좋지 않을까? 다음 주 블로그 글에서 이런 방식으로 하는 작업이 나쁜 디자인으로 이어지지 않는 이유를 설명할 것이다.

여러분의 생각은 어떤가요?

여러분의 팀은 UI 디자이너와 어떻게 협력하나요? 여러분이 디자이너인 경우, 팀과 어떻게 협력하나요? 여러분의 생각을 공유해주세요.

불평을 끝내기 위해서 데일리미팅에서 해야하는 2가지

이 글은 Mike Cohn의 블로그 글을 번역한 것입니다.

“팀원들은 의심의 여지없이 ‘긴 시간 동안 진행되는’ 데일리 미팅에 대해 어느 정도 불만을 토로했을 것이다.”

이러한 불평을 끝내기 위해 할 수 있는 두 가지 간단한 방법을 나누고 싶다. (모든 불평을 없앨 수 있다고 약속할 수는 없다. 어떤 사람들은 항상 불평한다.)”

데일리 미팅을 문제 해결에 사용해서는 안된다는 ‘스크럼’ 가이드라인 때문에, 많은 스크럼 마스터는 데일리 미팅 중에 언급된 문제들을 따로 기록한 뒤 미팅이 끝난 후 즉시 논의하도록 한다. 예를 들어, 데일리 미팅 중에 2개의 ‘핫 한’ 이슈가 언급되면 스크럼 마스터가 해당 이슈에 대한 토론을 중단할 수 있다.

스크럼 마스터는 우선 모든 사람이 데일리 미팅의 세 가지 질문에 답할 수 있도록 한 후에 중간에 언급된 두 가지 이슈를 다시 불러올 것이다. 이로 인해, 데일리 미팅을 위한 표준 시간제한 인 15분보다 길어진다.

여러분이 해야 할 첫 번째 것은, 매일의 데일리 미팅을 마칠 때 오늘 데일리 미팅이 얼마나 걸렸는지 팀에 얘기하는 것이다.

모든 사람이 세 가지 질문에 답하고 문제 해결 모드로 전환하기 직전에 그렇게 하자. 예를 들어, “수고하셨습니다. 오늘은 12분 동안 진행했습니다”라고 말하자. 그러나 데일리 미팅 중에 언급되었던 어떤 문제나 이슈를 모두에게 다시 한번 말해 주자. 그것들을 토론하거나 해결하기 위해 남아야 한다고 얘기하자. 가능하다면, 하나 이상의 문제를 논의해야 하는 경우 팀을 몇 개의 그룹으로 나누도록 하자.

즉, 그런 다음, 데일리 미팅의 시간에 대한 불만을 끝내는 데 도움이 되는 두 번째 것을 수행하자. 즉, “토론 또는 해결해야 하는 문제와 관련이 없는 사람들은 참여하지 않아도 된다”라고 알리자.


이 두 가지 액션을 취하자 :

  1. 공식적으로 데일리 미팅을 소집하고 몇 분이 걸렸는지 알리는 것. 그리고,
  2. 이어지는 토론에 관련이 없는 팀원은 참여하지 않아도 된다고 말하는 것

팀원들이 데일리 미팅이 15분 시간제한을 초과하고 있다고 느끼지 않도록 도울 수 있다.