PyPy에서의 분산 및 애자일 개발
==============================

.. note::
  이 페이지는 현재의 오픈소스 개발 모델보다 앞선 개발 방식을 설명합니다. 누구나 저희의 (이제는 매년 열리는) 스프린트에 참여할 수 있지만, https://github.com/pypy/pypy/ 의 GitHub 저장소를 통한 참여를 권장합니다. 이슈는 `issue tracker`_\ 에서 등록하고 논의할 수 있으며, `pull requests`_\ 를 환영합니다.

.. _`issue tracker`: https://github.com/pypy/pypy/issues/
.. _`pull requests`: https://github.com/pypy/pypy/pulls/

PyPy는 단지 코드를 만드는 것에 관한 것이 아니라, 코드를 만드는 방식에 관한 것이기도 합니다. 커뮤니티 내에서 작업을 조율하고, 이를 EU의 지원을 받는 프로젝트 부분과 확실히 융합시키는 일의 어려움은 실제로 까다롭습니다. 저희의 목표는 물론 커뮤니티의 작업 방식이 최대한 방해받지 않도록 하고 PyPy에 기여하는 일이 여전히 즐겁고 흥미롭게(;-) 느껴지도록 하는 것이지만, 동시에 오픈소스의 아이디어, 도구, 방법론이 개발 프로젝트를 운영하는 정말 좋은 방법이라는 것을 EU와 다른 지원 프로젝트들에게도 보여주려는 것이기도 합니다. 그래서 프로젝트로서의 PyPy가 운영되는 방식—분산적이고 애자일한—은 다른 오픈소스 개발 프로젝트와 상업 프로젝트에도 유용할 수 있으리라고 저희는 생각합니다.

이를 달성하기 위한 주요 방법은 다음과 같습니다:

  * 스프린트 주도 개발
  * 동기화 회의

이를 달성하기 위한 주요 도구는 다음과 같습니다:

  * py.test\ - 자동화된 테스트
  * Git\ - 버전 관리
  * 투명한 커뮤니케이션과 문서화(메일링 리스트, IRC, 튜토리얼 등등)


스프린트 주도 개발:
-------------------

스프린트(sprint)란 무엇이며, 우리는 왜 스프린트를 진행하나요?

원래 파이썬 커뮤니티에서 사용되는 스프린트 방법론은 Zope3 개발 관행에서 비롯되었습니다. 스프린트의 정의는 "개발자들이 한 방에 모여 짝을 이루어 특정 서브시스템을 구축하는 데 집중하는 이틀 또는 사흘간의 집중 개발 세션"입니다.

그 밖의 일반적인 스프린트 요인들:

  * 10명을 넘지 않아야 합니다 (다만 PyPy를 비롯한 다른 프로젝트에서도 그보다 많은 인원이 있었던 것으로 확인되었습니다. 이는 권장 사항이며, 절대적으로 필요한 조정 시간 이상을 추가로 요구하지 않으면서도 상호작용/소통하며 작업할 수 있는 임계 규모의 인원을 갖춘다는 발상에 기반한 것으로 보입니다. 2005년과 2006년의 스프린트는 스프린트당 약 13~14명이 참여했으며, PyPy 스프린트 중 최다 참가자 수는 24명의 개발자였습니다)

  * 코치(코치는 스프린트의 "관리자"로서 목표를 설정하고, 준비하고, 작업을 이끌고 조율하며, 진행 상황을 추적하여 이를 팀에게 보여줍니다. 여기서 중요하게 짚고 넘어갈 점은 - PyPy는 스프린트에서 코치를 둔 적이 한 번도 없다는 것입니다. 대신 전체 그룹이 함께 짧은 현황 회의를 열고, 결정 역시 같은 방식으로 이루어집니다. 지금까지 이 방식은 잘 작동해왔으며, 압박이 심한 상황이나 릴리스 등에서도 우리는 여전히 엄청난 성과를 낼 수 있었습니다. 우리에게 있는 것은 현지 조직자로, 흔히 그 지역에 거주하는 개발자 한 명과 스프린트를 준비하고 조직하는 개발자 한 명이 더 있습니다. 이들은 스프린트가 시작된 이후에는 이를 "관리"하지 않습니다 - 이들의 역할은 오히려 물류적인 성격에 가깝습니다. 이것이 앞으로 코치 기법이나 이와 비슷한 방식을 활용할 일이 없다는 의미는 아닙니다).

  * 코딩만 하는 것(이건 어려운 문제입니다. 스프린트 방식을 그저 아이디어를 시각화하고 의견을 모으는 데에만 사용한 프로젝트들도 있었습니다. PyPy도 비슷한 브레인스토밍 시작 스프린트를 가진 적이 있습니다. 다만 지금까지는 이것이 공식 입장이지만, 다시 말씀드리자면 PyPy 스프린트에 참여해 보시면 소그룹 단위로 스프린트 계획 수립, 문서화, EU 산출물\ 및 평가 조율 등 다른 소소한 활동들도 꽤 많이 진행하고 있다는 것을 아실 수 있습니다. 하지만 걱정하지 마세요 — 저희의 주된 초점은 프로그래밍입니다 ;-)

  * XP 기법(주로 페어 프로그래밍과 단위 테스트 - PyPy는 이러한 측면에 크게 의존하고 있습니다)을 사용합니다. 코드베이스에 대한 지식 수준이 서로 다른 사람들과 핵심 개발자를 짝지은 결과, 사람들이 꽤 빠르게 시작하여 개발에 합류할 수 있었습니다. 프로젝트와 코드베이스를 처음 접한 많은 참여자들은 페어 프로그래밍과 자동화된 테스트 작업을 병행하는 것이 시작하기에 훌륭한 방법이었다고 밝혔습니다. 물론 이는 딜레마이기도 한데, 핵심 개발자들이 특히 까다로운 문제를 해결하기 위해 짝을 지어야 할 수도 있고, 이는 다른 짝들의 구조와 효과에 영향을 미치기 때문입니다.

이는 분산 팀에 잘 맞는 방법인데, 계획 수립과 요구사항 수집에 오래 시간을 들이는 대신 짧은 증분 작업과 태스크, "실행"과 테스트를 우선하는 가속화된 방식으로, 그리고 협업적으로(페어 프로그래밍, 상태 점검 회의, 토론 등) 작업하면서 팀을 명확하고 도전적인 목표에 집중시키기 때문입니다. 이는 대부분의 경우 스프린트가 결과를 얻는 훌륭한 방법일 뿐만 아니라, 새로운 사람들이 코드베이스에 익숙해지도록 하는 데도 훌륭한 방법이라는 것을 의미합니다. 페어 프로그래밍 덕분에 스프린트는 팀 내에서 지식을 전파하고 학습하는 데에도 훌륭한 방법입니다.

스프린트를 실제로 여러 장소를 옮겨 다니며 진행하고, PyCon이나 EuroPython과 같은 컨퍼런스 기간뿐 아니라 커뮤니티 내 다양한 활동적인 개발자 그룹과 가까운 곳에서 진행하는 방식과 결합하면, 팀은 새로운 인재를 팀에 영입하는 일이 더 쉬워질 것입니다. 또한 이는 커뮤니티에 활기를 불어넣고, 서로 다른 Python 구현체 프로젝트 간의 교류를 늘립니다.

방법론은 언제나 그렇듯 여러분의 프로젝트에 맞게 조정해야 합니다(그 반대의 경우가 너무 흔하지만, 그래서는 안 됩니다). PyPy 팀은 2003년 초부터 스프린트를 진행해왔으며, 지금까지 유럽에서 19회, 미국에서 2회, 아시아에서 1회, 총 22회의 스프린트를 진행했습니다. 이 팀에서는 특정 관행들이 더 성공적임이 입증되었으며, 이것이 바로 여기서 정리하는 내용입니다.


어떻게 하는 것일까요?
~~~~~~~~~~~~~~~~~~~~~

스프린트에는 여러 측면이 있습니다. PyPy 팀에서는 다음에 중점을 둡니다:
1. 내용 (목표)
2. 장소
3. 정보
4. 프로세스

1. 내용(목표)은 행사 약 한 달 전에 메일링리스트(pypy-dev)와 IRC에서 논의됩니다. 사전에 "스프린트 사이(between sprints)"라고 불리는 대략적인 계획을 세우며, 스프린트 계획은 이러한 이슈들의 상태를 기반으로 하되 다가오는 릴리스와 결과물에도 초점을 맞춥니다. 보통 이 작업은 핵심 개발자들이 하지만, IRC에서 매주 "pypy-sync 회의"를 시작한 이후로 투명성과 참여도가 높아졌습니다. 동기화 회의와 대략적인 사이 계획이 결합되어 다른 개발자들이 진행 상황을 따라가고 다가오는 스프린트의 목표 설정에 참여하기가 더 쉬워졌습니다.

   목표는 도전적이어야 팀의 전력을 이끌어낼 수 있지만, 지나치게 비현실적이면 오히려 큰 좌절감과 불만을 유발하는 경향이 있으므로 비현실적이어서는 안 됩니다. 스프린트의 목표를 설정할 때 참가자들을 고려하는 것 또한 매우 중요합니다. 스프린트가 컨퍼런스(또는 이와 유사한 공개 행사)와 연계하여 진행되는 경우, 실제 코딩 진행에 관한 목표는 더 낮게 설정하거나(혹은 다른 방식으로 다루거나) 초점을 홍보와, 신규/관심 있는 사람들이 PyPy 코드베이스에 대해 어느 정도 이해하도록 돕는 쪽으로 옮겨야 합니다. 올바른 목표를 설정하고 이를 공유된 것으로 만드는 일은 중요한데, 이는 참가자들이 어느 정도 비슷한 기대를 가지고 참여하도록 돕기 때문입니다 ;-)

2. 장소 - PyPy 프로젝트에서는 몇 달 앞서 어디에서 스프린트를 진행할지에 대한 대략적인 계획을 가지고 있습니다. 그렇게 미리 상세한 계획을 세우지는 않습니다. 날짜와 장소를 알면 항공편 예약이 더 쉬워집니다 ;-) 장소는 생각보다 훨씬 더 중요합니다. 어느 정도 편안하게 작업할 수 있는 환경(최대 15명이 앉아서 작업할 수 있는 공간)이 필요하며, 이는 곧 테이블과 의자, 조명, 전기 콘센트를 의미합니다. 한 사람만 열 수 있도록 출입 카드가 필요한 장소인가요? 얼마나 머물 수 있나요 - 하루 24시간 가능한가요, 아니면 건물주가 23시까지 팀이 철수하기를 원하나요? 이는 스프린트의 "느낌과 분위기"뿐만 아니라 원하는 결과에도 큰 영향을 미칠 수 있는 중요한 질문들입니다!

   또한, 참가자들이 저렴하게 식사하고 숙박할 수 있는 장소와도 어느 정도 가까워야 합니다. 차/커피를 끓일 수 있는 시설과 음식을 보관할 냉장고 같은 것도 필요합니다. 상시 인터넷 연결은 필수입니다 - 스프린트가 계획된 장소에 네트워크 접근과 관련된 이상한 규정 등이 있는지 확인해야 합니다.

   화이트보드는 유용한 도구이며 갖추어 두면 좋습니다. 빔프로젝터(PyPy 용어로 프로젝터를 가리키는 말)는 상태 회의에 매우 유용하므로 최소 1대는 준비되어 있어야 합니다. 프로젝트에서도 스프린트 용도로 빔프로젝터 1대를 보유하고 있습니다.

   좋은 스프린트 장소의 요건이 충족되고 있는지 확인하는 사람은 따라서 현지와 매우 좋은 연고가 있거나, 가급적이면 그곳에 거주하고 있어야 합니다.

3. 정보 - 콘텐츠와 목표에 대한 논의(사전 공지)는 보통 pypy-dev(메일링 리스트/IRC)에서 이루어집니다. 그 밖의 모든 정보는 pypy-sprint 메일링 리스트를 통한 이메일과 codespeak의 웹 페이지로 배포됩니다. 날짜, 장소, 콘텐츠가 완전히 결정되면 스프린트 공지가 작성되어 pypy-dev와 pypy-sprint뿐만 아니라 comp.lang.python 같은 좀 더 범용적인 메일링 리스트로도 발송되며, codespeak에도 갱신됩니다 - 이는 스프린트 2~4주 전에 이루어집니다. 스프린트 공지가 현지 교통편(해당 국가, 도시, 행사장까지의 이동), 화폐 문제, 음식과 식당 등에 대한 정보를 안내하는 것이 중요합니다. 참가자들이 도착 시점과 숙소를 알리는 웹 페이지도 있습니다.

   스프린트를 위한 계획 텍스트는 스프린트 전까지 계속 업데이트되며, 이후 진행 상황 회의 때와 그 사이사이에 작업을 추적하는 데 사용됩니다. 스프린트가 끝난 후(또는 더 좋게는, 기억이 생생할 때 중간중간) 개발자 중 한 명이 스프린트 보고서를 작성해 codespeak에 업데이트합니다. 이는 전체 스프린트에 대한 일종의 요약으로, 수행된 작업과 참여한 사람들을 알려줍니다.

   장소를 계획할 때 매우 중요한 전략 중 하나는 비용 효율성입니다. 숙박비와 식비/교통비를 가능한 한 낮게 유지하면, 더 많은 사람이 스프린트를 방문하거나 온전히 참여할 여유를 가질 수 있습니다. 프로젝트 중 EU의 부분적 지원을 받는 부분에는 이른바 스프린트 예산이라는 것이 있으며, 이는 개발자들이 우리 스프린트에 참여(교통비 및 숙박비)하도록 돕는 데 사용됩니다. 그리고 자금의 대부분이 이른바 매칭 펀딩이기 때문에, 어차피 우리는 각자의 조직과 회사에서 대부분의 비용을 부담하게 됩니다.


4. 진행 방식 - 일반적인 PyPy 스프린트는 중간에 휴식일이 하루 있는 7일 일정입니다. 보통 스프린트 참가자들은 스프린트가 시작되기 전날 도착합니다. 첫날에는 시작 회의가 열리며, 프로젝트에 새로 참여하는 사람이 있거나 새로운 도구나 기능이 구현된 경우 튜토리얼이 진행됩니다. 참가자들과 그들의 배경 및 기대사항에 대한 짧은 발표를 하는 것도 좋습니다. 아쉽게도 첫날에는 항상 시간이 소요되는데, 주로 사람들이 도착하는 오전에 인터넷과 서버 인프라를 구축하는 데 쓰입니다. 그래서 우리는 :ref:`문서 <getting-started-index>`\ 를 통해 참가자들이 스프린트에 도착하기 전에 필요한 도구와 설정을 미리 준비하도록 노력하고 있습니다.

   대략적인 진행 시간은 10시부터 17시까지이지만, 사람들은 저녁에도 코드를 작성하기 위해 더 오래 머무는 경향이 있습니다. 짧은 상황 점검 회의로 하루를 시작하며, 필요와 희망에 따라 작업이 "짝(pair)"으로 나뉩니다. PyPy 스프린트는 개발자와 그룹이 주도합니다. "코치"가 없기 때문에 상황 점검 회의는 노트를 작성하고 계획 문서를 업데이트하는 동안 상당 부분 그룹 토론으로 이루어집니다. 또한 - 스프린트는 그 지역에 익숙한 사람(대개 그곳에 거주하는 개발자)과 함께 개발자 그룹 내에서 계획되고 실행됩니다. 따라서 팀 내에서 스프린트를 공식적으로 책임지는 사람은 없습니다.

   휴식일의 여가 활동과 사교 행사에 대한 제안은 휴식을 취하는 것이 얼마나 중요한지 강조하는 좋은 방법입니다 - 현지 주최자가 그런 방향으로 몇 가지 조언을 해주는 것이 좋습니다.

   스프린트가 끝날 무렵에는 기술적인 요약(목표/내용을 달성했는지)을 진행하고, 다음 스프린트까지 작업의 대략적인 초점이 무엇이어야 하는지를 정하며, 스프린트 바퀴는 다시 굴러가기 시작합니다 ;-) 참가자들과 함께 스프린트를 평가하는 것 또한 중요한 부분입니다. 대개 이는 스프린트 이후 이메일로 질문을 보내는 방식으로 이루어지며, 짧은 그룹 평가 형태로 진행될 수도 있습니다. 평가하는 이유는 물론 피드백을 얻고, 스프린트를 더욱 효율적이고 즐겁게 만들 기회를 놓치지 않도록 하기 위함입니다.

    저희 스프린트 진행 방식의 주요 어려움은 참가자들이 서로 다른 날짜에 도착하고 서로 다른 날짜에 떠난다는 점입니다. 이는 공유 소개(목표/내용, 튜토리얼, 발표 등)와 마무리(기술 요약 등)에도 영향을 미칩니다. 이 부분에서는 아직 적절한 중간 지점을 찾기 위해 고심하고 있으며, 그렇기 때문에 피드백의 중요성이 커집니다.


저도 참여할 수 있나요?
~~~~~~~~~~~~~~~~~~~~~~

물론입니다. 그냥 pypy-dev의 작업을 따라가시면 되고, 저희 스프린트에 관한 정보에 특별히 관심이 있으시다면 pypy-sprint@codespeak.net을 구독하시고 공지 등을 위해 codespeak의 뉴스를 읽어보시기 바랍니다.

여러분의 도시에서 스프린트를 진행해야 한다고 생각하신다면 저희에게 이메일을 보내주세요 - 저희는 스프린트를 활발히 활동하는 개발자들(Python/컴파일러 설계 등)과 접촉하는 방법으로 활용하는 데 큰 관심이 있습니다!