1인 스크럼: 혼자 스크럼 하는 방법(Scrum Of One: How to Bring Scrum into your One-Person Operation)

[최종 수정일 : 2017.06.27]

원문 : https://www.raywenderlich.com/162654/scrum-one-bring-scrum-one-person-operation

1인 스크럼: 혼자 스크럼 하는 방법(Scrum Of One: How to Bring Scrum into your One-Person Operation)

솔로(solo) 인디 개발자로서, 스크럼과 다른 애자일 개발 방법론은 큰 규모의 개발 팀에 대한 것으로 생각하기 쉽습니다. 너무 작은 예산으로 인해 이미 제약을 받을때 개발 프레임워크 구현의 오버헤드는 너무 큰 작업으로 보일 수 있으며, 끊임 없이 변화하는 기술과 하루 24시간이라는 제한 요인이 있습니다.

그러나 개발 방법론을 채택하는 것은 좋은 면이 정말 많이 있습니다. - 혼자 일하더라도 말입니다.

Ten Kettles의 알렉스 앤드류(Alex andrews)는 워크 플로우를 구조화하는데 어려움을 겪었지만, 스크럼에 대해 배우게 되었고 1인(one-person) 회사에 맞게 크기를 조정하는 법을 발견했으며, 솔로 개발자로서 이러한 구조에서 작업하는 것이 엄청나게 유리하고 생산적이라는 것을 발견했습니다.

그가 자신의 개발 워크플로우에서 스크럼을 채택한 방법과 어떻게 솔로 개발작업에 적용 할 수 있는지 읽어보세요!

그라운드제로: 인디로 조직화하기(Ground Zero: Getting Organized as an Indie)

새로운 회사에서 일을 시작할때, 일반적으로 일 처리 방식에 대한 전체 시스템이 있습니다. 아침에 나타나서, 얼마나 자주 회의를 할것인지, 마감 기간을 어떻게 처리할것인지 등등을 결정해야 합니다. 그러한 시스템은 회사의 성공여부를 결정하는데 도움이 되고, 중요한 것은 팀이 행복할지 여부를 결정하는데 도움이 됩니다.

하지만 회사에서의 첫번째 날에, 시스템에 대해서 말을 하지 않습니다. 일 처리 방식을 배우고 코딩을 하는 것이 여러분의 직업입니다.

인디(indies)에 대해서는 조금 다릅니다.

나는 먼저 2014년 3월 1일 Ten Kettles에서 독립했습니다. 내 방에서 2011년 맥북프로 노트북 한대와 몇가지 아이디어만 있었습니다. 따라야할 시스템이 없었습니다.몇시에 일을 시작하는지, 어떤 앱에 집중하는지, 작업 배치등,.. 모든 것이 내게 달렸습니다!

처음에는, 자유가 좋았지만 조금 압박을 받았었습니다. 리서치 엔지니어로써의 과거 생활에서 가장 큰 자부심중 하나는 내 시간에 대한 추정치였습니다. : 나에게 프로젝트를 제공하면, 날짜를 알려주고 그 날짜에 코드를 얻을 것입니다. 나는 그 스킬이 내 앱을 만드는데에 사용될 것이라 상상했었습니다. 내 말은, 유일한 차이점은 누가 프로젝트를 생각하고 있었는가 입니다. 맞죠? 하지만 2014년에서 2015년으로 되면서 그런 일은 일어나지 않았습니다 - 그런일은 결코 없었습니다.

나는 곧 인디 개발자가 정확한 직책이 아니라는 사실을 알게 되었습니다. 코딩은 많은 책임 중에 하나였고, 가장 중요한 하나가 아닙니다. 저를 늦추는 것은 코딩이 아닙니다 - 제품 결정이었습니다.

"기능 하나 더, ... 아니, 그 디자인은 별로... 클라우드 지원할때까지 앱 런칭을 기다립니다."

계속 그렇게 말하고 있었습니다.

넘쳐나는 스케쥴은 나를 짜증나게 했습니다. 나의 음악 이론 앱 Waay을 원료하는데 원래 계획했던 보다 훨씬 더 오래 결렸습니다. 그것이 나왔던 것이 정말 기뻤지만, 2년후에 회사에서 왜 더 잘하지 못했을까? 되돌아보기 어려웠습니다.

인디 개발자로서 개발하는데에 얼마나 작은 시간을 쓰는지 놀랍습니다.

제품은 좋았지만, 과정은 그렇지 않았습니다. 나는 더 나은 접근법이 필요하다는 것을 알았습니다. 뭔가 나를 더 생산적으로 만들고, 회사의 이익을 높이고, 나를 행복하게 해줍니다.

스크럼 시작하기(Enter: Scrum)

나는 언제나 내 작업 구조를 반복하고 있었지만, 그것은 반복(iterative)하고 점차적(Gradual)으로 느려(Slow)집니다. 나의 접근 방식을 크게 바꿨지만, 무엇을 해야 하는지에 대해서 몰랐습니다. 문제를 잠시 보류하기로 결정하고 재미있는 고객 작업에 뛰어들었습니다. 그것이 정확하게 내가 필요로한 해결책에 이끌어 주는 것을 거의 알지 못했습니다.

이 특정 고객은 스크럼(Scrum)이라는 프로젝트 관리 기술을 일부 채택한 중소 규모의 개발 회사였습니다. 아마도 여러분은 스크럼을 잘 알고 있을지 모르지만, 저는 그 당시에는 일상적인 스탠딩 미팅과 에자일에 대한 것 외에는 전혀 몰랐습니다.

처음에는 전문적인 개발을 위해서 더 많은 것을 배우고 싶었습니다. 하지만, 그 주제에 관한 책과 기사에 몰입할수록, 더 흥미로웠습니다. 스크럼은 내 프로세스에서 가장 큰 세가지 문제점을 다루는 것으로 보였습니다.

• 생산성 향상
• 수익 증대
• 행복 향상

이것이 나를 궁금하게 만듭니다 : 어떻게 하면 이러한 접근 방식을 내 제품에 적용할 수 있을까?

프로젝트를 완료하자 마자, 내가 가장 좋아하는 도시중 하나인 몬트리올(Montréal)에서 몇일간 떨어져서 내가 이 접근법을 내 프로젝트에 적용하는 방법에 대해 생각하기 위해 비행기를 탔습니다. 나는 내 노트를 자세히 보고, 그 주제에 관한 훌륭한 책 두권을 다시 읽었으며, 내 자신의 앱에 직면했던 실제 문제 대한 생각과 내 회사를 위한 1인 스크럼 변형을 만들었습니다. 그 후로 나는 이 프로세스를 사용해왔고, 그 변화는 놀라웠습니다. (나중에 자세히 설명할 것입니다)

스크럼에 대해 이야기하고 어떻게 1인으로 동작하는지 이야기 해 봅시다.

스크럼: 핵심 원칙(Scrum: Key Principles)

스크럼은 무엇인가요? 여기에 스크럼을 공부하기 위해 내가 처음 봤던 책에서 발췌한 내용이 있습니다.

1인 팀은 일반적인 5~9명인 팀과 너무 다르기 때문에, 여기에서는 스크럼의 팀(team)에 대한 구제척인 내용을 다루지는 않지만, 전체 프로세스를 정의하는 핵심 원칙입니다. 1인 스크럼의 중심(backbone)을 형성하는 것이 원리입니다.

스크럼의 핵심 원칙은 다음과 같습니다.

• 전달과 공유(ship and share) 
  제품을 다른 사람의 손에 닿게 하세요. - 최종 사용자, 베타 테스터, 또는 안목있는 친구든 간에. 그렇게 하지 않으면 아무도 원하지 않는 기능이나 제품에 시간을 낭비 할 수 있기 때문입니다. 특히, 1인 조직에서, 특정 업무의 중요성에 대해 잃어버리는 것은 너무 쉽습니다. 테스터와 베타 버젼을 공유하는 것이 빠른 프로세스가 될 수 있고 그 절약되는 시간은 엄청날 수 있습니다.

• 생산성의 우선순위를 매기고, 수치화 하세요(Prioritize productivity, and quantify it)
  가장 중요한 단기(shrot-term) 기준(metric)은 생산성입니다. 판매량, 출시 수가 아닙니다. - 단지 순수한 생산성입니다. 매주 중요한 일을 얼마나 많이 하고 있나요? 질문에 답하기 위해, 진행정도를 수치화 할 필요가 있습니다. 다음 섹션에서 작업 점수를 사용해서 진행상황을 추적하고 최적화 하는 방법을 설명합니다.

• 자기반성 및 의미있는 반복(Self-reflection & meaningful iteration)
  생산성, 소득, 행복을 향상시키는데 있어 중요한 것은 여러분의 프로세스와 자신의 게획을 면밀히 검토해야 하기 때문에, 자신의 참 모습을 바라볼수 있어야 합니다(i hope you have a good mirror). 현재 어떤 일을 하고 있는지 점검하면서, 다른 접근 방식을 테스트하고 실시간으로 효과를 확인하는 것이 훨씬 쉬워집니다.

하나의 스크럼 : 방법(Scrum of One: A How-To)

이제 스크림의 전달(shipping) 원칙과, 생산성 우선순위를 정했고, 반영/반복을 다뤘으니 구체적인 내용을 살펴볼 시간입니다. 이러한 기술을 1인 운영을 관리하기 위해 어떻게 사용할수 있나요?

다음은 자신의 작업을 위해 Ten Kettles에서 만든 1인 스크럼 변형입니다. 전통적인 스크럼 전문용어의 많은 부분을 제거했으며, 스크럼 전문가가 필요한 전제 조건이 없습니다. 자세히 봅시다.

스프린트(The Sprint)

스프린트(sprint)는 정해진 목표를 위해 할애할 시간을 정하는 것이며, 앱에 새로운 기능을 추가하거나 복잡한 버그를 처리하는 작업을 할 수 있습니다. 스프린트에서 하는 거의 모든 일은 목표를 실현(또는 목표를 설정)하는데 중점을 둬야 합니다.

스프린트는 일반적으로 1~4주 사이이며, 제품의 스티일에 따라 다릅니다. 나는 2주 스프린트를 사용하면 완벽하다는 것을 알고 있습니다. : 중요하지 않는 일들을 하거나 다른 일을 하는데 많은 시간이 들이지 않고 의미있는 작업을 완료하기에 충분한 시간입니다. 2주 스프린트 모습은 다음과 같습니다.

보다시피, 스프린트는 핵심 작업과 집중해서 만들며, 몇가지 이벤트를 추가합니다. : 매일 아침 데일리 스크럼(Daily Scrum); 주간 스토리 타임(weekly Story Time); 마지막에 스프린트 배포(Sprint Release), 회고(Retrospective), 스프린트 계획(Sprint Plan). 각각에 대해 아래에서 자세히 읽을 수 있습니다.

데일리 스크럼(The Daily Scrum): 5분

스크럼의 기본요소 중의 하나는 일정한 자기 반성(self-reflection)과 반복(iteration)입니다. - 특히 생산성 측면에서 그렇습니다. 그래서, 하루 만에 일을 완료할 계획이지만, 그런 일이 일어나지 않을 것이며, 무엇이 잘못되었는지 파악하고 프로세스를 개선할 수 있는 기회로 활요하세요. 데일리 스크럼(Daily Scrum)은 그런 일을 가능하게 도와줍니다.

스탠드 미팅(또는 데일리 스크럼)은 스크럼 방식의 특징입니다. 전통적으로, 그때 팀원들이 어제 진행 상황과 오늘 계획, 생산성을 저해하는 요소에 대해서 공유합니다. 미팅이 길어지는 것(한가지만 더…)을 막기 위해 짧게 유지하고 모든 사람을 서있게 하는데 도움이 됩니다.

좋은 스크럼은 최선을 다해서, 모든 사람들을 같은 위치에 올려놓고, 모든 어려움을 가볍게해주며- 팀원들의 도움을 이끌어내기 - 팀이 성장하는데 도움을 줍니다.

그렇다면, 한 사람에게 어떻게 적용할수 있을까요?

여기에서 여러분의 장점에 대해 약간의 기술을 사용 할 수 있습니다. 1인 스탠딩 미팅은 매일 아침 녹화하는 짧은 비디오가 됩니다. (짧다라는 것은 45초 이하를 목표로 합니다.) 방법은 다음과 같습니다.

• 리뷰(Review)
  어제 동영상 보는 것을 시작하여, 성취할 것이라고 말한 것을 특히 주의를 기울이면서 봅니다.

• 반성(Reflect)
  어제 목표에 도달하지 못했나요? 괜찮습니다. 이것이 스크럼의 목적입니다 : 왜 그런일이 일어나지 않았고 무엇을 더 잘할 수 있었는지 생각해 봅니다. 오후 중반에 회의를 예약하여 나머지 시간에 코딩을 할수 없었을수 있습니다. 또는 앱 스토어에 수동으로 스크린 샷을 준비하거나, 예상보다 훨씬 오래걸렸을 수도 있습니다. (fastlane를 시도할 시간인가요?)

• 연습(Rehearse)
  1~2분 안에 오늘의 비디오를 연습합니다 : 각 질문에 몇가지 문장: 어제 무엇을 했는지, 오늘은 무엇을 할것인지, 가로막고 있는 것이 무엇인지. 다음에 예제가 있습니다.

어제(yesterday)는 hearEQ v2.2.0의 스크린 샷을 만들고 모든 앱 스토어 메타정보를 업데이트 했습니다. 오늘(today)은 일정 목록을 업데이트하고, 배포 자료를 작성하고나서 음악 선생님을 만나 Waay를 상의 할 것입니다. 가로막고 있는 일은(blocking) 스크린 샷을 만드는데 너무 오래걸렸고, 내가 계획했던 일정 목록대로 하지 못했습니다. 다음에는, fastlane으로 빠르게 작업 해야합니다.

• 녹화(Record) 폰으로 영상을 녹화하면 끝납니다. 이것들이 회고(retrospective)에서 특히 도움이 될것입니다.

스토리 타임(Story Time): 30~45분

각 스프린트(sprint)에서, 새 앱을 만들거나 현재 앱으로 사업을 전환하(pivoting)는것 같은, 큰 그림을 생각하는데 많은 시간을 투자하지 않고 개발자로서(developer hat on) - 버그를 고치고, 새로운 기능을 넣고, 등등. - 대부분의 시간을 보낼것입니다. 스토리 타임(Story Time)은 CEO로써 큰 그림을 생각할 때입니다. 스프린트(sprint)의 이 부분에서, 일반적인 작업 환경에서 벗어나 커피 샾에 가거나 아침을 먹거나 집에서 다른 곳에서 일하는 것을 좋아합니다.

장소를 변경하면(다른방으로) 큰 그림을 생각하는데 도움이 됩니다.

스토리 타임(Story Time)을 하는 동안에, 사용자 의견을 검토하며, 내가 추가하고 싶은 앱의 기능에 대해 브레인 스토밍하고, 어떻게 앱(또는 회사)의 방향을 전환(pivot)할 것인지 고민합니다. 새로운 앱을 생각하고나 오래된 앱을 버릴때도 마찬가지 입니다. 그런 다음에 몇가지 구체적인 아이디어를 제시하고 이를 제품 백 로그(Product Backlog)라는 특수한 목록에 추가합니다.

제품 백로그(Product Backlog)는 큰 그림의 작업이 정렬된 목록입니다. 이것이 다음 스프린트에 대한 목표를 결정할때 가장 먼저 보게 될 것입니다. 하지만 새로운 업무를 백 로그에 추가하는것 만큼이나 중요하며, 스토리 타임(Story Time)은 기존 것을 수정하고 다시 정렬하는 것입니다.

아마도 여러분의 웹 사이트 분석에 브라질로부터 많은 관심을 보일것입니다. 그것은 계획한 스페인어 번역 대신 포르투칼어 번역을 고려해야 할 때입니다. 아니면 갑자기 사람들이 원하는 것으로 보이는 기능에 대한 리뷰를 받았습니다. 해당 기능을 목록 위로 이동할 시간입니다.

스프린트 배포(Sprint Release)

스크럼의 기본 원리는 정기적으로 세상에(into the world) 여러분의 일을 알리는 것입니다. 이것이 스프린트 배포(Sprint Release)에서 일어나는 일입니다. 전체 앱을 배포할 필요는 없지만, 다른 사람들에게 새로운 것을 얻게 해주는 것이 중요합니다 - 특히 당신이 감동을 줄때 약간 긴장하는 사람들. 베타 테스터에게 새로운 버전을 제공할수 있으며, 새로운 디자이너에게 와이어프레임 세트를 제공하거나 새로운 내부 테스터에게 사소한 업데이트를 제공할 수 있습니다.

배포 범위는 특히 처음에는 스프린트 전체적으로 변경될 가능성이 있습니다. 예를 들어, 계획된 3가지 기능중 2개만 배포할 것입니다. 괜찮습니다. 배포 날짜에 가까울때 범위를 줄이며, 귀중한 테스터의 의견(feedback)을 지연시키지 않고 가장 중요한 기능에 우선순위를 부여합니다. 테스터가 누락한 기능에 대해서 언급(comment)하지 않는 경우, 그것은 중요하지 않을지 모릅니다. 그런 경우에, 다음 스프린트에서 우선순위를 결정하는 명확한 아이디어가 있습니다.

스프린트의 마지막 날(Last Day of the Sprint)

스프린트의 목표를 달성하기 위해 9일을 보냈고, 이제 마지막 날을 위한 시간입니다. 좋은 뉴스는 이것이 쉬운일이라는 것입니다 - 오늘은 개발자 모드가 되지 않아도 됩니다!:] 회고를 하는 날이며, 슬레이트(slate)를 깨끗이 닫고, 다음 스프린트를 계획하고나서 즐기세요.

처음에는 하루를 보내는것이 아주 이상한 것 같습니다. - 특히 마감시간에 죽을것 같은 경우에 그렇습니다. 하지만 나는 이렇게 생각합니다 : 어린시절 학교에서 집으로 걸어서 갈때, 걸으면서 책을 읽었습니다. 정말 그 책에 몰두했다면, 한쪽 도로로 따라가거나 다른 사람의 정원을 끊임없이 지그재그로 가로지르는 것을 알게 될것입니다. (실제 에자일에서) 내가 찾지 못하면, 잘못된 길로 가게 됩니다.

스프린트 마지막날에 하는것은 올바른 길로 가고 있는지 확인하는 것입니다. 2주마다 하루동안(압박이 크면 반나절) 머리를 숙이고 주변을 둘러보고 필요한 코스(course)를 수정합니다. 여러분의 생산성이 높더라도, 그것이 잘못된 작업으로 낭비되는 경우에 그 생산성이 가치가 없기 때문입니다.

이제, 오늘의 3가지 주요 업무에 뛰어들어 봅시다.

회고(Retrospective): ~2시간

새 문서를 열거나 노트북의 새 페이지를 열고, 지난 2주간의 생산성에 대해서 적습니다. 여기에서 더 생산적이고 행복해지지 못하게 하는 것들을 발견할 수 있는 기회입니다.

시작을 위한 몇가지 질문

• 무엇을 성취하였나요?
• 스프린트 목표를 달성했나요?
• 스프린트가 정말 잘 된 이유는 무엇인가요? 무엇이 더 잘되었나요?
• 생산성을 높이는 블록이 끊기지 않았나요? 이러한 정보에 대해 데일리 스크럼 비디오를 검토하세요.
• 불필요하게 스트레스 받거나 즐거웠던 적이 있었나요?

반성을 위해 책상에 앉아있는 것보다 걷는것이 더 좋다면, 밖으로 나가고(hit the pavement)난 이후에 빠른 요약을 간단하게 입력하세요. 나는 일반적인 작업 환경 밖에서 이것을 하는 것이 도움이 된다는 것을 발견했습니다.

때로는 숲속 산책은 좋은 회고 과정에 필요합니다.

마지막으로, 여러분의 반성을 기반으로, 다음 스프린트에서 개선할 수 있는 두가지 간단한 것을 선택합니다.

1. 더 생산적(productive)으로 만드는 한가지
2. 더 행복하게(happier) 만드는 한가지

최근 스프린트에서 반성한 몇가지 예가 있습니다.

• 생산성(Productivity)
  특히 베타 테스트 기간중에, 나는 끊임없이 이메일을 주고 받는 일을 하는 것이 나를 늦추는 것을 알았습니다. 근무일에 이메일 확인 하는 것을 3번으로 제한하기 시작했고, 내가 집중하는데 도움이됬습니다.

• 행복(Happiness) 
  집에서 작업하기 때문에, 가끔씩 하루가 끝날때 직장 모드에서 집 모드로 전환하기가 어렵습니다. 그래서 나는 저녁 전에 리셋(reset)을 위해 근무일의 마지막에 긴 산책을 시작했습니다.

스프린트 계획(Sprint Plan): ~2시간

회고(Retrospective) 전에 두번의 스토리 타임(Stroy Times)과 제품 백로그(Product Backlog)사이에 다음 스프린트를 위해 무엇을 해야 하는지에 대한 좋은 아이디어가 있어야 합니다. 잘 관리된 백로그(Backlog)를 가져와서 몇가지 주요 항목을 선택합니다. 스프린트 계획 단계는 스프린트 목표를 적고, 어떻게 작업할 것인지, 작업 점수(Task Points)를 지정합니다. 이 순간에 대해서 자세히 살펴봅니다.

여기에 간단한 예제가 있습니다. 거의 완성된 앱이 있다고 가정하고, 다음 스프린트는 최종 기능을 추가하는 것이며, 몇가지 내부 테스트를 수행한 다음 사용자 의견에 대한 베타 테스트를 실시합니다. 스프린트 계획 문서에서 다음과 같은 내용을 작성합니다.

2주 스프린트의 경우, 훨씬 더 많은 작업을 할것입니다. 하지만 요점을 설명하기에는 충분합니다.

각 작업 옆에 있는 숫자가 보이나요? 그것들을 작업 점수(Task Points)라고 합니다. 그것들은 시간이나 쉽게 측정할 수 있는 것을 대표하지 않습니다 - 그것들은 완전히 추상적입니다. 중요한 것은 일관성 입니다.

예를 들어, 1점 짜리 작업은 2점 짜리 작업의 절반정도 걸립니다(평균적으로). 원하는 만큼 사용하세요. 개인적으로, 개인적으로 나는 더 큰 작업을 과소평가하려는 마음을 바로잡을수 있는 1, 2, 3, 5, 8 숫자를 사용하는 것을 좋아합니다. 예를 들어, 4가 없기 때문에 5까지 반올림 해야 합니다. :]

스프린트 작업을 계획할때, 각각 하나가 다른것들과 관련해서 얼마나 오래 걸릴 것인지 생각해 보세요. 여기에 희망은 없습니다(throw hope out the window here) : 냉정하게 각 작업을 계산하고 완료하기 위해 얼마나 걸릴지 합리적인 예측을 합니다.

작업이 복잡하지만 그일을 많이 해본 경우, 조금 더 빨라질 것이고 점수를 줄일 수 있습니다. 작업이 단순하지만, 익숙하지 않은 경우에, 시간이 더 오래 걸릴것이므로, 해당 작업에 할당된 점수는 증가해야 합니다. 문제 없습니다.

작업이 끝나면, 모든 작업 점수를 추가하고 지난 몇번의 스프린트 동안 얻은 결과와 비교합니다. 예를들어, 스프린트에서 보통 80~100개의 작업 점수를 처리했다면, 다음 스프린트가 대략 80인지 확인하세요.

내 경험상, 이것이 스크럼의 가장 효과적인-그리고 가장 어려운- 부분 중 하나입니다. 내가 원하는 작업을 위해 이 시점이 어디인지 스스로 업무를 중단시키는 것이 중요합니다. 이것은 내가 개발자 보다 CEO처럼 생각하게 만들며, 수시로 도움이 될수 있습니다.

이제 스프린트 계획을 세우고 나면, 마지막 스프린트에서 작업 보드(Task Board)를 제거하고 월요일을 준비합니다!

잠깐만요. 작업 보드(Task Board)란 무엇인가요?

조직 유지하기(Keeping Organized): 작업 보드(The Task Board)

스프린트에서 벗어나서 작업 보드(Task Board)에 대해서 이야기할 시간입니다. 비록 스프린트 계획을 자세히 입력하지만(보통 OneNote에), 내 일상 작업 조직은 작업 보드(Task Board)에서 시작합니다. 그 보드(보통 사무실 벽)는 몇가지 다른 요소가 있을수 있지만, 가장 중요한 부분은 3가지 포스트잇(post-it)으로 시작하며, 하나 또는 두개 따로 위치시킵니다. : TODO, DOING, DONE

매일 끝날때, 별도의 포스트잇 노트에 다음 날 업무를 기록하고 TODO아래에 그것들을 붙입니다. 지난 몇번의 스프린트를 동안 평균 일별 작업 점수 10을 처리했다고 가정해 봅시다. 다음날 약 10점의 작업을 했습니다.

다음날 아침에, 작업 보드에 가서 오늘의 첫뻔째 작업을 TODO에서 DOING으로 옮깁니다. 하루의 대부분을 컴퓨터 앞에서 보낼때, 집중하는데 도움이 되도록 이러한 단순한 행위를 의도적으로 합니다.

그런다음, 작업이 완료하면, 포스트잇을 DONE로 옮깁니다. 이상하게 만족합니다. 스프린트가 진행됨에 따라, DONE 영역이 가득찹니다. :]

휴식과 탐색(Rest and Explore)

스프린트로 돌아갑니다. 스프린트의 마지막 금요일 오후로 들어갑니다. 즐거운 하루를 보내세요! 랩탑을 소파에 가지고 와서 며칠전에 북마크해둔 raywenderlich.com 튜토리얼을 가지고 올때이거나 아마도 내가 마침내 Regex의 기능을 알아내는 시간입니다.

자질구레한 느낌을 갖지 마세요: 즐기는 일과 관련된 여유로운 일을 하세요. 술을 한잔 하고, 음악을 틀어놓고, 잘된 스프린트를 축하해주세요!

1인 스크럼 대 현실(One-Person Scrum vs. The Real World)

인디 개발자로서 올바른 작업구조를 선택하는 것은 매우 개인적인 일입니다. 여러분의 강점에 공감하고, 동기를 부여하며, 지속적인 성장을 장려해야 합니다. 이를 염두에 두고, 여러분에 대한 1인 변형된 스크럼 작업의 요소들이 일부는 맞지만 다른 것들은 그렇지 않습니다. 여러분이 요구사항과 스타일에 맞게 일상생활에서 자유롭게 적용하세요. - 전달(shipping) 원칙, 정량화된 생산성, 반성/반복을 유지하기 위해 무엇이든 하세요.

몇가지 팁:

• 초기 스프린트에서 계획했던 것보다 적은 수의 작업을 수행해도 기분 나빠하지 마세요. 다음 스프린트에 대한 예측과 작업 부하를 조정하세요. 의미있는 반복은 게임의 이름입니다!
• 스프린트 계획을 스프린트의 매일(또는 이틀마다) 수정합니다. 각 작업을 검토하고 작업 점수를 조금씩 조정하세요(실제로 3점짜리 작업이 많은 것처럼 보입니다). 전체 점수가 너무 높아지면 우선순위가 낮은 일부 작업을 제거하여 보정해야 합니다.
• 간격을 두고 세부사항을 계획하기 어렵습니다. 2주 스프린트를 사용하는 경우, 두번째 주에 작업 계획이 조금 덜 상세해도 괜찮습니다. 스프린트 계획에 대한 일일 조정을 통해 두번째 주가 오면 세부정보를 채웁니다.
• 회사에 장기적인 계획을 세우는 것은 훌륭한 일이지만, 그것들에 맹목적으로 집착하지 마세요. 살아잇는 훌륭한 제품 백로그를 갖는 것이 나으며, 항상 변하고, 새로운 징후에 언제나 적응해야 합니다.
• 비록 10개의 Kettles(주전자) 앱을 만드는데 사용하는 계획이지만, 그것이 단지 몇가지 사소한 변형으로 클라이이언트 작업에 적합하다는 것을 알았습니다. 예를 들어, 물리적인 작업 보드가 아닌 공유된 Trello 보드를 사용하면 클라이언트가 작업중인 일을 신속하게 진행 할 수 있으며, 비록 작업 보드를 사용하는 경향이 있지만, CEO 역할(제품 백로그, 스토리 타임, 등)에 대해서 확실히 필요하지 않습니다.
• 많은 표식과 포이스잇을 많이 구입하는 것을 잊지 마세요.

인디로서 더 나은 작업 구조가 필요하다는 것을 처음 알게 됐을때, 그것은 3가지로 나뉩니다 : 생산성 증가, 앱으로 부터의 수입 증가, 더 많은 행복. 스크럼의 1인 버젼이 실제로 제공되는 것을 알려주게 되어 기쁩니다. Ten Kettles에서 의미있는 앱 업데이트 빈도가 급증했으며, 앱 수입은 현재 월 평균 18% 증가하고 있으며, 사용자들도 매우 행복하고(두 앱 모두 앱 스토어의 별점이 현재 4.75), 일과 생활의 균형이 좋아졌습니다. - 저녁과 주말이여 안녕!

여기서 어디로 가야하나요?(Where to Go From Here?)

최근 인터뷰(recent interview)에서 Ten Kettles에서의 작업과 일상 업무 흐름에 대해서 자세히 설명합니다.

• 정규적인 전달(Regular shipping)
• 생산성 우선순위(Prioritizing productivity)
• 정규적인 반성(Regular reflection)

그것은 단순해 보이지만, 좋은 구조로 이러한 규칙의 힘이 여러분의 일을 분명하게 해줄수 있습니다.

스크럼에 대해 더 자세히 알고 싶으면(특히 여기서 다루지 않은 팀의 요소들), 여기에 훌륭한 리소스가 많이 있습니다.

시작하기 위한 몇가지 간단한 책입니다.

• Scrum: The Art of Doing Twice the Work in Half the Time (Sutherland, Sutherland)
• Scrum: a Breathtakingly Brief and Agile Introduction (Sims, Johnson)