콘텐츠로 이동

소개

East Agile Tracker는 팀이 소프트웨어를 출시하는 방식에 대해 분명한 의견을 가진 애자일 계획 도구입니다 — 그리고 누가 팀에 속하는지에 대해 색다른 생각을 가지고 있습니다.

스토리는 진짜 XP 상태 기계를 거쳐 흐릅니다. 이터레이션은 속도로부터 스스로 계획됩니다. 보드는 작업이 정확히 어디에 있는지 보여 줍니다. 그리고 사람 동료와 더불어, 여러분은 에이전트 — 이름을 가지고 역할이 한정된 AI 참여자로, 스토리를 집어 들고, 댓글을 달고, 상태를 전환하며, 여러분이 읽을 수 있는 감사 추적을 남기는 — 를 둘 수 있습니다.

이 페이지는 개념을 다룹니다. 실제로 무언가를 하려면 사용 안내를 참고하세요.

스토리는 작업의 기본 단위입니다. 네 가지 유형이 있으며, 그 구분이 바로 핵심입니다:

  • Feature — 사용자를 위한 새로운 가치. 포인트를 가지는 유일한 유형이며, 속도에 기여하는 유일한 유형입니다. 이것이 작업을 사용자가 관찰 가능한 가치로 쪼개도록 강제합니다.
  • Bug — 결함. 추정되지 않으며, 그저 고쳐야 합니다. 버그는 점수를 얻지 못하므로, 재작업의 비용을 보상하는 대신 가시화합니다.
  • Chore — 유지보수 작업 — 리팩터, 의존성 업데이트, 인프라. 추정되지 않으며, 수락 관문이 없습니다. 팀은 가치 프레이밍이 정직하게 유지되도록 가능한 한 잡무를 기능에 묶어 넣도록 압박받습니다.
  • Release — 포인트가 0인 마일스톤. 배포나 버전 업데이트를 표시합니다. 예측을 위한 날짜를 고정합니다.

중요한 것은 행동적 효과입니다: 버그와 잡무가 점수를 받지 못하면, 팀은 자연스럽게 작업을 사용자 지향적 기능으로 표현하도록 밀어붙이게 되고, 결함 비용을 예민하게 인식하게 됩니다. 그것은 기억해야 할 지침이 아니라 — 데이터 모델에 인코딩된 계획 규율입니다.

모든 스토리는 제목, 설명(Markdown), 소유자, 팔로워, 라벨, 선택적 작업, 댓글, 첨부 파일, 블로커, 링크, 리뷰를 가집니다. 상세 패널은 보드 위에서 인라인으로 열립니다 — 모달도 없고, 컨텍스트 전환도 없습니다.

각 스토리는 여러 상태를 거쳐 이동합니다. 정확한 경로는 유형에 따라 다릅니다:

TypePath
FeatureUnstarted → Started → Finished → Delivered → Accepted (or Rejected)
BugUnstarted → Started → Finished → Delivered → Accepted (or Rejected)
ChoreUnstarted → Started → Accepted
ReleaseUnstarted → Accepted

핵심 상태는 Delivered입니다: 엔지니어가 스토리를 delivered로 표시하지만, 제품 책임자가 수락 기준에 비추어 명시적으로 수락할 때까지 — 또는 거부하여 Started로 되돌려 보낼 때까지 — 완료된 것이 아닙니다. 이것은 수락을 스프린트 종료 시연으로 미루는 대신 모든 단일 스토리에 고객 피드백 루프를 새겨 넣습니다. 수락 기준은 스토리가 시작되기 전에, 이상적으로는 수락 테스트에 직접 매핑되도록 Given/When/Then 형식으로 작성되어야 합니다. INVEST는 스토리가 잘 구성되었는지에 대한 점검 기준입니다.

카드의 인라인 액션 버튼에서 상태를 진행시키거나, 스토리를 다른 이터레이션 그룹으로 드래그하거나, API를 호출할 수 있습니다. 역방향 전환은 실수로 자리를 잃지 않도록 확인을 요청합니다.

작업은 시간이 정해진 이터레이션(우리는 “스프린트”라고 말하지 않습니다)으로 정리됩니다. 각 이터레이션은 시작일, 길이(프로젝트당 1–4주), 그리고 포인트 단위의 목표 용량을 가집니다.

여러분은 이터레이션을 수동으로 채우지 않습니다. 시스템이 여러분의 속도 — 최근 이터레이션들의 완료된 포인트의 평균 — 와 프로젝트의 “done 상태” 정의(아래 속도 참고)를 사용해 대신 해 줍니다. 스토리를 드래그해 순서를 바꾸면, 이터레이션이 자동으로 다시 채워집니다.

속도는 이터레이션당 수락된 기능의 포인트입니다. East Agile Tracker는 이를 여러분의 이력에서 계산하여 다음 이터레이션의 용량을 계획하는 데 사용합니다.

프로젝트별로 몇 가지를 설정할 수 있습니다:

  • Done 상태 — 어떤 상태를 속도 산정에서 “done”으로 칠지. 대부분의 팀은 Accepted를 선택하고, 전달 주기가 분리된 일부 팀은 Finished를 선택합니다.
  • 전략 — 속도를 평균 내는 방법: 최근 3개 이터레이션, 최근 5개 등.
  • 초기 속도 — 아직 이력이 없는 새 프로젝트를 위한 시드 값.

보드는 작업이 머무는 곳입니다. 세 영역, 하나의 규칙:

  • Icebox — 우선순위가 정해지지 않은 아이디어 풀. Icebox는 무덤이 되어도 괜찮습니다.
  • Backlog — 엄격하게 정렬된 단일 우선순위 목록. 동률 없음. “P1/P1/P1” 없음. 제품 책임자가 위에서 아래까지 순서를 소유합니다. 불변식: 백로그의 맨 위는 항상 가장 중요하고 가장 잘 명세되어 있으며, 아래로 내려갈수록 명확성이 정당하게 감소합니다. 상단 근처의 스토리가 모호한 수락 기준을 가지고 있다면 그것은 계획 버그입니다 — 무시할 미래의 문제가 아닙니다.
  • Current — 활성 이터레이션. 스토리는 이터레이션 시간 순서로 놓이며 각 카드에 상태(Unstarted / Started / Finished / Delivered / Accepted)가 보입니다. 순서는 다음에 무엇을 처리할지 알려 주고, 상태는 그것이 주기의 어디에 있는지 알려 줍니다.

Current 열은 상태가 아니라 이터레이션 헤더(current, 그다음 upcoming, 그다음 closed)별로 그룹화됩니다. 이는 의도적입니다: Current 이터레이션은 상태별 구획이 아니라 작업의 계획입니다. 이터레이션 안의 많은 스토리가 Unstarted입니다(일부는 시작될 것이고, 일부는 다음 이터레이션으로 넘어갈 것이며, 일부는 폐기될 것입니다). 열을 상태별로 쪼개면 팀이 실제로 계획하는 이터레이션 시간 순서가 깨집니다.

사이드바의 Board 섹션에서 추가 열을 켜거나 끌 수 있습니다(프리셋당 체크박스): Done, My Work, Blocked, Epics, Chat. 또한 커스텀 필터 패널을 저장하고 원하는 대로 열 크기를 조정할 수 있습니다 — 레이아웃은 프로젝트별, 브라우저별로 유지됩니다.

여러분은 기능만 추정하며, 시간이 아니라 상대 포인트를 사용합니다. 추정은 약속이 아니라 크기를 정하는 대화입니다. 버그와 잡무는 0에 머뭅니다. 그것들을 포인트화하면 속도가 아무 의미 없는 것으로 부풀려지고, 전체 시스템을 정직하게 만드는 예측이 무너집니다. 속도는 측정 도구입니다. 여러분은 자신의 도구를 조작하지 않습니다.

East Agile Tracker는 기본으로 세 가지 척도를 제공합니다:

  • Fibonacci0, 1, 2, 3, 5, 8, 13. 고전적인 XP 척도. 13보다 큰 것은 더 작은 스토리로 쪼개야 합니다.
  • East Agile0, 1, 2, 3. 우리가 직접 쓰는 더 빡빡한 척도. 과도한 고민을 막으며, 3을 넘는 것은 한 이터레이션에 속하지 않습니다.
  • 3-Point1, 2, 3 (Small / Medium / Large). 최소한의 세분화를 원하는 팀을 위한 엄격한 티셔츠 사이징.

프로젝트별로 척도를 고르세요. 나중에 척도를 변경할 수 있으며 — 기존 추정치는 가로질러 매핑됩니다.

규율 있는 추정의 보상: 릴리스 날짜 예측이 협상이 아니라 계산이 됩니다. 이해관계자와의 대화는 “금요일까지 X를 약속할 수 있나요”에서 “현재 속도라면 이 릴리스는 대략 날짜 Y에 도착합니다 — 여기 범위/날짜 트레이드오프가 있습니다”로 바뀝니다.

라벨은 색이 있는 태그입니다. 스토리는 여러 개를 가질 수 있습니다. Labels 페이지에서 관리합니다 — 색상, 이름, 오래되면 보관.

검색은 자연스럽게 조합되는 간단한 필터 구문을 사용합니다:

type:feature state:started label:mvp owner:claire

일반적인 필터: type:, state:, label:"with spaces", owner:, requester:, has:blocker, is:unestimated, 그리고 제목과 설명에 대한 자유 텍스트. 필터를 보드의 명명된 패널로 저장하세요.

  • Owners — 작업을 하는 사람. 여러 명일 수 있습니다.
  • Followers — 업데이트에 관심 있는 사람. 여러 명일 수 있습니다.
  • Requestor — 스토리를 요청한 사람. 보통 한 명입니다.

이 슬롯 각각은 사람 멤버 또는 에이전트로 채울 수 있습니다. 스토리 카드는 소유자 아바타를 보여 주며, 에이전트 소유자는 누가 실제로 무엇을 했는지 항상 분명하도록 별도의 시각적 처리를 받습니다.

이것은 대부분의 트래커에 없는 부분이며, 우리가 의도적으로 만든 부분입니다.

에이전트는 프로젝트의 이름을 가진 참여자입니다 — 멤버와 같지만 AI입니다. 자신의 정체성, 자신의 역할(viewer / member / owner — owner는 사람으로 제한됨), 그리고 자신의 감사 추적을 가집니다. 에이전트가 스토리를 전환하면, 활동 로그는 그 에이전트가 했다고 말합니다. 에이전트가 댓글을 달면, 그 댓글은 에이전트가 서명합니다. 에이전트의 쓰기에 유령 같은 사람은 없습니다.

에이전트는 프로젝트별로 발급되는 에이전트 API 키(ea_agent_*)로 인증합니다. 에이전트의 권한을 취소하면 접근 권한이 키와 함께 사라집니다. 에이전트의 이력은 감사 로그에 영원히 남으므로, 무슨 일이 있었는지 항상 알 수 있습니다.

사용 안내 → 에이전트API 가이드에서 더 읽어 보세요.

댓글, 첨부 파일, 블로커, 링크, 리뷰

섹션 제목: “댓글, 첨부 파일, 블로커, 링크, 리뷰”
  • Comments — Markdown, 최대 10,000자. 스토리 아래에 스레드로 달립니다.
  • Attachments — 동영상을 포함한 파일, 각 최대 2 GB.
  • Blockers — “무엇이 이를 막고 있는가”를 적는 자유 텍스트 메모, 해결됨/미해결로 표시.
  • Links — 스토리를 서로(blocks, is blocked by, duplicates, relates to) 또는 외부 URL(GitHub PR/브랜치 자동 감지)에 연결.
  • Reviews — 리뷰어(사람 또는 에이전트)를 배정하고, 승인/거부를 받습니다.

보드 너머로, Analytics 탭은 다음을 제공합니다:

  • Project Overview — 속도, 수락률, 사이클 타임, 최근 이터레이션 KPI.
  • Iteration Report — 이터레이션별 드릴다운.
  • Releases & Burndowns — 릴리스 마일스톤과 이터레이션별 번다운.
  • Story Activity — 누가 무엇을 언제 했는지(필터 가능).
  • Cycle Time — Started부터 프로젝트의 done 상태까지의 시간.
  • Projections — 현재 속도로 백로그가 언제 완료될지 예측.

기본으로 네 가지 테마가 제공됩니다:

  • Agile — 마케팅 랜딩 페이지 팔레트. 따뜻한 흰색, 짙은 파란색 브랜드 강조(#1f6f9f), 채도 높은 금색/빨강/슬레이트/보라 스토리 유형 아이콘. 새 방문자의 기본값이자 전환기의 선두 옵션.
  • Labs — 원조 Pivotal Tracker 팔레트 — 어두운 크롬, PT 파란색 상단바, 파스텔 열 간격. 정성스럽게 보존됨.
  • Dark — 순수 중립 다크, 색조 없음.
  • Light — 순수 중립 라이트, 색조 없음. 종이 위의 잉크.

사이드바 푸터나 Account Settings → Theme에서 전환하세요. 선택은 세션 간에 유지됩니다.

UI는 15개 언어로 번역되어 있습니다: 영어, 프랑스어, 독일어, 스페인어, 일본어, 중국어, 한국어, 포르투갈어, 이탈리아어, 네덜란드어, 스웨덴어, 덴마크어, 체코어, 핀란드어, 폴란드어. 사이드바 푸터에서 전환하며, 선택은 유지됩니다. 크롬, 인증 페이지, 계정/보안 영역, 마케팅 랜딩이 오늘날 연결되어 있으며, 스토리 상세 / 분석 / 설정은 이후 업데이트에서 따라옵니다.