개요: 민첩한 프로젝트 관리를 위한 5개의 MCP 서버
Il 민첩한 프로젝트 관리 소프트웨어 개발에서 가장 복잡한 영역 중 하나는 다음과 같습니다. 스프린트, 작업, 성과 지표, 시간 추적, 예산의 조정이 필요합니다. 그리고 회고록. 스위트룸에서 Tech-MCP, 이러한 측면은 다음에 의해 관리됩니다. 5개의 특수 MCP 서버 협력하는 사람 EventBus를 통해 통합 프로젝트 관리 생태계를 형성합니다.
이 기사에서는 각 서버, Zod 스키마가 포함된 도구, 게시 및 구독된 이벤트, 그리고 이를 응집력 있는 시스템으로 통합하는 협업 흐름입니다.
MCP Suite의 5개 PM 서버
| 섬기는 사람 | 역할 | 도구 | 저장 |
|---|---|---|---|
| 스크럼 보드 | 중앙 스크럼 허브 | 7 | SQLite(테이블 3개) |
| 민첩한 측정항목 | 분석 및 예측 | 4 | 무국적 |
| 시간 추적 | 시간 추적 | 4 | SQLite(테이블 2개) |
| 프로젝트 경제학 | 예산 및 비용 | 4 | SQLite(테이블 2개) |
| 회고 관리자 | 애자일 회고 | 5 | SQLite(테이블 3개) |
1. 스크럼 보드 서버: 중앙 허브
서버 스크럼 보드 그리고 수술의 심장 프로젝트의 전체 MCP Suite 중 관리. Scrum 방법론에 따라 스프린트, 사용자 스토리 및 작업을 관리하며 다음을 통해 허브 역할을 합니다. 대부분의 협업 워크플로우가 통과합니다. 거의 모든 다른 PM 서버 직접 또는 게시하는 이벤트를 통해 스크럼 보드와 상호 작용합니다.
+---------------------------+
| SCRUM-BOARD SERVER |
| HUB CENTRALE |
+---------------------------+
/ | | | \
/ | | | \
v v v v v
+-------+ +-------+ +------+ +-------+ +-------+
|agile | |time | |retro | |standup| |project|
|metrics| |track. | |mgr | |notes | |econ. |
+-------+ +-------+ +------+ +-------+ +-------+
서버 스크럼 보드 도구
스크럼 보드가 노출됩니다. 7가지 도구 전체 스크럼 수명주기를 포괄합니다.
도구 테이블: 스크럼 보드
| 도구 | 설명 | 주요 매개변수 |
|---|---|---|
create-sprint |
새 스프린트 만들기 | name (끈), startDate (끈), endDate (끈), goals (끈[]) |
get-sprint |
스프린트 세부정보 검색 | sprintId (숫자) |
create-story |
새로운 사용자 스토리 만들기 | title, description, acceptanceCriteria (끈[]), storyPoints (숫자), priority, sprintId (고르다.) |
create-task |
스토리에 대한 작업 만들기 | title, description, storyId (숫자), assignee (고르다.) |
update-task-status |
작업 상태 업데이트 | taskId (숫자), status (열거: todo | in_progress | in_review | 완료 | 차단됨) |
sprint-board |
스프린트의 칸반 보기 | sprintId (숫자, 선택 사항; 기본값: 스프린트 활성) |
get-backlog |
스프린트에 할당되지 않은 스토리 | 아무도 |
Zod 스키마: 생성-스프린트
각 도구는 입력의 자동 검증을 위해 Zod 체계를 통해 자체 매개변수를 정의합니다.
// Tool: create-sprint
const CreateSprintSchema = z.object({
name: z.string().describe("Nome dello sprint"),
startDate: z.string().describe("Data inizio ISO (YYYY-MM-DD)"),
endDate: z.string().describe("Data fine ISO (YYYY-MM-DD)"),
goals: z.array(z.string()).describe("Obiettivi dello sprint")
});
Zod 구성표: 업데이트 작업 상태
// Tool: update-task-status
const UpdateTaskStatusSchema = z.object({
taskId: z.number().describe("ID del task da aggiornare"),
status: z.enum(["todo", "in_progress", "in_review", "done", "blocked"])
.describe("Nuovo stato del task nel flusso Kanban")
});
작업 칸반 흐름
작업 상태의 각 변경은 표준 Kanban 흐름을 따릅니다. 모든 주에서 가능하며
쪽으로 전환 blocked:
+-------+ +-------------+ +-----------+ +------+
| todo | --> | in_progress | --> | in_review | --> | done |
+-------+ +-------------+ +-----------+ +------+
| | |
+-------+-------+-------------------+
|
v
+--------+
| blocked|
+--------+
ScrumStore 데이터베이스: 세 개의 SQLite 테이블
ScrumStore는 외래 키를 통해 상호 연결된 세 개의 테이블을 관리합니다.
+------------------+ +-------------------+ +------------------+
| sprints | | stories | | tasks |
+------------------+ +-------------------+ +------------------+
| id (PK) |<------| sprintId (FK) | | id (PK) |
| name | | id (PK) |<------| storyId (FK, NN) |
| startDate | | title | | sprintId (FK) |
| endDate | | description | | title |
| goals (JSON) | | acceptanceCriteria| | description |
| status | | storyPoints | | status |
| createdAt | | priority | | assignee |
+------------------+ | status | | createdAt |
| createdAt | | updatedAt |
+-------------------+ +------------------+
스프린트 보드: 칸반 보기
도구 sprint-board 작업을 열로 구성하여 완전한 Kanban 보기를 생성합니다.
지정되지 않은 경우 sprintId, 상태 저장 스프린트를 자동으로 검색합니다. active:
+--------------------------------------------------------------------+
| Sprint Board: Sprint 14 |
+--------------------------------------------------------------------+
| TODO | IN PROGRESS | IN REVIEW | DONE | BLOCKED |
|---------------|---------------|---------------|---------|----------|
| Task: Setup | Task: Login | Task: Test | Task: | Task: |
| OAuth | form UI | OAuth flow | DB | Deploy |
| | | | schema | (needs |
| Task: 2FA | Task: Token | | | infra) |
| research | refresh | | | |
+--------------------------------------------------------------------+
스크럼보드에서 게시한 이벤트
스크럼보드와 교장 이벤트 프로듀서 PM 제품군 중 하나입니다. 각 중요한 작업은 다른 서버에서 연쇄 반응을 유발하는 이벤트를 생성합니다.
스크럼보드 이벤트
| 이벤트 | 페이로드 | 발행자 |
|---|---|---|
scrum:sprint-started |
{ sprintId, name, startDate, endDate } |
create-sprint |
scrum:task-updated |
{ taskId, status, previousStatus, storyId, sprintId } |
update-task-status |
scrum:sprint-completed |
{ sprintId, name, completedPoints } |
마무리 스프린트 |
scrum:story-completed |
{ storyId, storyPoints, sprintId } |
이야기의 완성 |
스크럼보드를 통해 구독되는 이벤트
스크럼 보드는 또한 스크럼 보드를 사용하는 몇 안 되는 서버 중 하나입니다. 수신 다른 서버의 이벤트, 양방향 피드백 루프 생성:
구독: Retro:action-item-created
회고 관리자가 회고에서 작업 항목을 생성하면 게시됩니다.
retro:action-item-created. 스크럼보드는 이를 받아 자동으로 생성한다.
백로그의 작업으로 지속적인 개선 주기가 종료됩니다.
예: 스프린트의 전체 워크플로
// 1. Creare lo sprint
{ "tool": "create-sprint",
"arguments": {
"name": "Sprint 14 - Autenticazione",
"startDate": "2025-02-03",
"endDate": "2025-02-14",
"goals": ["Implementare login OAuth", "Aggiungere 2FA"]
} }
// 2. Creare una user story
{ "tool": "create-story",
"arguments": {
"title": "Login OAuth Google",
"description": "Come utente voglio autenticarmi con Google",
"acceptanceCriteria": ["Redirect a Google", "Token salvato", "Sessione attiva"],
"storyPoints": 8,
"priority": "high",
"sprintId": 1
} }
// 3. Creare task per la story
{ "tool": "create-task",
"arguments": {
"title": "Configurare OAuth credentials",
"description": "Setup su Google Cloud Console",
"storyId": 1,
"assignee": "mario"
} }
// 4. Aggiornare lo stato del task
{ "tool": "update-task-status",
"arguments": { "taskId": 1, "status": "in_progress" } }
// 5. Visualizzare la board
{ "tool": "sprint-board", "arguments": { "sprintId": 1 } }
2. Agile Metrics Server: 분석 및 예측
서버 민첩한 측정항목 측정하고 예측할 수 있는 분석 도구를 제공합니다. 팀 성과. 속도 계산, 번다운 데이터 생성, 사이클 시간 분석 및 생산 완료 예측을 기반으로 함 몬테카를로 시뮬레이션.
근본적인 특징은 서버 e 완전 무국적: 소유하지 않음 내부 저장소의 데이터베이스. 데이터를 입력으로 수신합니다(일반적으로 스크럼 보드에서). 순수한 계산을 반환합니다.
도구 테이블: Agile-metrics
| 도구 | 설명 | 주요 매개변수 |
|---|---|---|
calculate-velocity |
추세 분석을 통한 평균 속도 | sprints (배열 { name, completedPoints, totalPoints }) |
generate-burndown |
번다운 차트용 데이터 | totalPoints, sprintDays, dailyCompleted (숫자[]) |
calculate-cycle-time |
사이클 타임 통계 | tasks (배열 { taskId, startDate, endDate }) |
forecast-completion |
몬테카를로 예보 | remainingPoints, velocityHistory (숫자[]), sprintLengthDays |
Zod 방식: 계산 속도
const CalculateVelocitySchema = z.object({
sprints: z.array(z.object({
name: z.string(),
completedPoints: z.number(),
totalPoints: z.number()
})).describe("Lista sprint con punti completati e totali")
});
Zod 계획: 예측-완료
const ForecastCompletionSchema = z.object({
remainingPoints: z.number().describe("Punti rimanenti da completare"),
velocityHistory: z.array(z.number())
.describe("Storico velocity degli ultimi sprint"),
sprintLengthDays: z.number()
.describe("Durata di uno sprint in giorni")
});
몬테카를로 시뮬레이션
도구 forecast-completion 실행 1000번의 시뮬레이션 예측하다
과거 속도 변동성을 고려하여 남은 작업이 완료되면:
Algoritmo Monte Carlo:
+-------------------------------------------------------+
| Per ogni simulazione (1..1000): |
| remainingWork = remainingPoints |
| sprints = 0 |
| while remainingWork > 0: |
| velocity = random(velocityHistory) |
| remainingWork -= velocity |
| sprints++ |
| record(sprints * sprintLengthDays) |
+-------------------------------------------------------+
| Ordina risultati |
| p50 = risultato al 50-esimo percentile |
| p85 = risultato all'85-esimo percentile |
| p95 = risultato al 95-esimo percentile |
+-------------------------------------------------------+
출력은 세 가지 신뢰 수준을 제공합니다.
{
"remainingPoints": 50,
"simulations": 1000,
"forecast": {
"p50": { "sprints": 2, "days": 28, "date": "2025-03-14" },
"p85": { "sprints": 3, "days": 42, "date": "2025-03-28" },
"p95": { "sprints": 3, "days": 42, "date": "2025-03-28" }
},
"confidence": "Con l'85% di probabilità, completamento entro 42 giorni"
}
번다운 차트: 이상적 vs 현재
도구 generate-burndown 이상적인 라인과 실제 진행 상황을 비교하고,
매일 진행 여부를 표시합니다. on-track, behind o ahead:
Punti
40 |*
| * .
30 | * .
| * . * <-- attuale (in ritardo)
20 | * .
| * . *
10 | * . *
| * . *
0 |--------*------------------.--*-----> Giorni
1 2 3 4 5 6 7 8 9 10
* = linea ideale . = avanzamento reale
주기 시간: 자세한 통계
도구 calculate-cycle-time 작업 완료 시간을 분석합니다.
주기 시간 측정항목
| 미터법 | 설명 |
|---|---|
average |
사이클 시간의 산술 평균 |
median |
중앙값(p50) |
p95 |
95번째 백분위수 |
min |
최소 완료 시간 |
max |
최대 완료 시간 |
Agile-metrics가 구독하는 이벤트
민첩한 측정항목과 순수 데이터 소비자. 이벤트를 게시하지 않지만 구독합니다. 진행 중인 스프린트의 변화에 반응하는 스크럼 보드의 사항:
scrum:sprint-completed→ 속도 재계산 및 스프린트 보고서 종료 트리거scrum:task-updated→ 실시간 번다운 데이터 업데이트scrum:story-completed→ 속도 추적을 위한 업데이트 포인트 완료
3. 시간 추적 서버: 시간 추적
서버 시간 추적 작업 수행 시간 추적을 관리하고, 에 대한 지원으로 라이브 타이머 e 수동 녹음. 유지하다 두 개의 테이블(시간 항목용 테이블과 활성 타이머용 테이블)이 있는 SQLite를 통한 지속 상태.
서버는 다음을 구현합니다. 이중 부팅 보호: 가질 수는 없다 동일한 사용자에 대해 동시에 두 개 이상의 타이머가 활성화됩니다.
도구 테이블: 시간 추적
| 도구 | 설명 | 주요 매개변수 |
|---|---|---|
start-timer |
작업 타이머 시작 | taskId (끈), description (고르다.), userId (고르다.) |
stop-timer |
활성 타이머 중지 | userId (고르다.) |
log-time |
수동 시간 기록 | taskId, durationMinutes (숫자), description (고르다.), date (고르다.) |
get-timesheet |
날짜별로 필터링된 작업표 | userId (고르다.), startDate (고르다.), endDate (고르다.) |
Zod 구성표: 시작 타이머 및 로그 시간
const StartTimerSchema = z.object({
taskId: z.string().describe("ID del task da tracciare"),
description: z.string().optional()
.describe("Descrizione dell'attivita"),
userId: z.string().optional()
.describe("ID utente (default: 'default')")
});
const LogTimeSchema = z.object({
taskId: z.string().describe("ID del task"),
durationMinutes: z.number()
.describe("Durata in minuti"),
description: z.string().optional(),
date: z.string().optional()
.describe("Data ISO (YYYY-MM-DD)"),
userId: z.string().optional()
});
타이머 흐름
의 흐름 start-timer 이중 부팅 보호 기능이 포함되어 있습니다.
그만큼 stop-timer 자동으로 기간을 계산하고 시간 항목을 생성합니다.
start-timer(taskId: "TASK-42")
|
v
Verifica: esiste timer attivo per userId?
|
+--[SI]--> Errore: "Timer attivo per TASK-15. Ferma prima quello."
|
+--[NO]--> Crea record in active_timers
startTime = new Date().toISOString()
stop-timer()
|
v
Cerca timer attivo per userId
|
+--[NON TROVATO]--> Errore: "No active timer found"
|
+--[TROVATO]
|
v
endTime = now()
durationMinutes = Math.round((endMs - startMs) / 60000)
|
v
INSERT INTO time_entries --> DELETE FROM active_timers
|
v
Pubblica time:entry-logged
타임스토어 데이터베이스
TimeStore는 두 개의 SQLite 테이블을 관리합니다.
- 활성 타이머: 현재 실행 중인 타이머(
id,taskId,userId,startTime,description) - 시간_항목: 등록 완료 (
id,taskId,userId,startTime,endTime,durationMinutes,description,date)
시간 추적 이벤트
게시된 이벤트: 시간:항목 기록
타이머가 중지되거나 시간이 수동으로 기록될 때마다 서버는
이벤트 time:entry-logged 페이로드 포함:
{
"taskId": "TASK-42",
"userId": "mario",
"durationMinutes": 45,
"date": "2025-02-07"
}
이 이벤트는 다음에 의해 차단됩니다. 프로젝트 경제학 변환하다 비용을 절감하고 프로젝트 예산을 업데이트하세요.
4. 프로젝트 경제 서버: 예산 및 비용
서버 프로젝트 경제학 프로젝트 예산 및 비용을 관리하고 지출, 카테고리별 분석, 예산 소진 예측에 대한 가시성. 포함 자동 경보 시스템 예산이 소진되면 이벤트를 게시합니다. 사용된 비율이 80%에 도달하거나 초과합니다.
도구 테이블: 프로젝트 경제
| 도구 | 설명 | 주요 매개변수 |
|---|---|---|
set-budget |
프로젝트 예산을 정의합니다. | projectName, totalBudget (숫자), currency (기본값: 'EUR') |
log-cost |
비용 기록 | projectName, category, amount (숫자), description, taskId (고르다.) |
get-budget-status |
예산 현황 완료 | projectName |
forecast-budget |
예산 소진 예측 | projectName |
Zod 방식: 로그 비용
const LogCostSchema = z.object({
projectName: z.string().describe("Nome del progetto"),
category: z.string().describe("Categoria di spesa (es. sviluppo, infra, testing)"),
amount: z.number().describe("Importo in valuta del budget"),
description: z.string().describe("Descrizione del costo"),
date: z.string().optional().describe("Data ISO del costo"),
taskId: z.string().optional().describe("ID task associato")
});
예산 예측 알고리즘
도구 forecast-budget 계산하다 일일 연소율 그리고 존경
예산이 소진되면:
Algoritmo di previsione:
+---------------------------------------------------+
| 1. Trova prima e ultima data di costo |
| 2. daysTracked = (lastDate - firstDate) + 1 |
| 3. dailyBurnRate = totalSpent / daysTracked |
| 4. estimatedDaysRemaining = remaining / burnRate |
| 5. runOutDate = today + daysRemaining |
+---------------------------------------------------+
세분화된 예산 상태
도구 get-budget-status 분석이 포함된 예산의 전체 보기를 반환합니다.
비용 카테고리별:
{
"projectName": "MCP Suite v2",
"totalBudget": 50000,
"currency": "EUR",
"totalSpent": 38500,
"remaining": 11500,
"percentageUsed": 77.0,
"breakdown": [
{ "category": "sviluppo", "total": 25000 },
{ "category": "infrastruttura", "total": 8500 },
{ "category": "testing", "total": 3000 },
{ "category": "design", "total": 2000 }
]
}
프로젝트 경제 이벤트
자동 경보 시스템
| 이벤트 | 페이로드 | 상태 |
|---|---|---|
economics:cost-updated |
{ projectName, category, amount, totalSpent } |
항상(매번 log-cost) |
economics:budget-alert |
{ projectName, percentageUsed, remaining, totalBudget } |
언제 percentageUsed >= 80% |
예산 알림 흐름
log-cost("MCP Suite v2", "sviluppo", 5000, ...)
|
v
Calcola percentageUsed = totalSpent / totalBudget * 100
|
v
percentageUsed = 82% --> >= 80%?
|
+--[SI]--> Pubblica economics:budget-alert
| { projectName: "MCP Suite v2",
| percentageUsed: 82,
| remaining: 9000,
| totalBudget: 50000 }
|
+--[NO]--> Solo economics:cost-updated
프로젝트 경제학이 구독하는 이벤트
time:entry-logged(time-tracking에서) → 기록된 시간을 비용으로 변환하여 프로젝트에 추가scrum:sprint-completed(스크럼 보드에서) → 비용 분석이 포함된 스프린트 종료 보고서 트리거
5. Retrospective Manager Server: 민첩한 회고
서버 회고 관리자 민첩한 회고의 전체 주기를 관리합니다. 특정 형식의 세션 생성부터 카테고리별 피드백 수집까지, 투표 시스템, 가장 많이 투표된 테마에서 작업 항목 자동 생성까지.
지원하다 세 가지 형식 표준 회고:
지원되는 소급 형식
| 체재 | 카테고리 |
|---|---|
| 정말 슬프고 기쁘다 | mad, sad, glad |
| 4L | liked, learned, lacked, longed-for |
| 시작-중지-계속 | start, stop, continue |
도구 테이블: 회고 관리자
| 도구 | 설명 | 주요 매개변수 |
|---|---|---|
create-retro |
회고록 만들기 | format (열거형), sprintId (고르다.) |
add-retro-item |
피드백 추가(카테고리 검증 포함) | retroId, category, content, authorId (고르다.) |
vote-retro-item |
아이템에 등급을 추가합니다 | itemId (숫자) |
generate-action-items |
가장 많이 투표한 항목에서 작업 항목 생성 | retroId, topN (기본값: 3) |
get-retro |
완전한 회고 | retroId (숫자) |
Zod 패턴: create-retro 및 add-retro-item
const CreateRetroSchema = z.object({
format: z.enum(["mad-sad-glad", "4ls", "start-stop-continue"])
.describe("Formato della retrospettiva"),
sprintId: z.string().optional()
.describe("ID dello sprint associato")
});
const AddRetroItemSchema = z.object({
retroId: z.number().describe("ID della retrospettiva"),
category: z.string()
.describe("Categoria (validata dal formato della retro)"),
content: z.string().describe("Contenuto del feedback"),
authorId: z.string().optional()
.describe("Autore del feedback")
});
카테고리 검증
서버 카테고리가 유효합니다 형식과 일치하는지 확인 회고의. 카테고리가 유효하지 않으면 오류를 반환합니다.
add-retro-item(retroId: 1, category: "happy", content: "...")
|
v
Verifica formato retro #1 = "mad-sad-glad"
Categorie valide: ["mad", "sad", "glad"]
"happy" NON e valida
|
v
Errore: 'Invalid category "happy" for format "mad-sad-glad".
Valid categories: mad, sad, glad'
작업 항목 생성
도구 generate-action-items 가장 평점이 높은 상위 N개 항목을 선택하고 생성합니다.
각각에 대한 작업 항목, 이벤트 게시 retro:action-item-created:
Top 3 votati --> Action Items:
1. [mad] Deploy troppo lento (8 voti)
2. [sad] Manca documentazione (6 voti)
3. [glad] Code review migliora qualità (5 voti)
|
v
Per ogni action item:
Pubblica retro:action-item-created
{ retroId, actionItemId, description, assignee }
|
v
scrum-board riceve --> crea task nel backlog
RetroStore 데이터베이스: SQLite 테이블 3개
- 뒤쪽: 회고 세션 (
id,sprintId,format,status) - 레트로_아이템: 팀 피드백(
id,retroId,category,content,votes,authorId) - action_items: 구체적인 행동(
id,retroId,description,assignee,dueDate,status)
스크럼 보드를 사용한 양방향 흐름
피드백 루프: 스프린트 → 백 → 백로그
- 스프린트 완료 → 스크럼 보드 게시
scrum:sprint-completed - 회고관리자는 이벤트를 수신하고 자동으로 회고를 생성합니다.
- 팀이 항목을 추가하고 투표합니다.
- 생성된 작업 항목은 다음과 같이 게시됩니다.
retro:action-item-created - 스크럼 보드는 이벤트를 수신하고 백로그에 작업을 생성합니다.
이 주기는 지속적인 개선 루프를 종료합니다. 모든 회고전이 생성됩니다. 스크럼 워크플로에 백로그 작업으로 들어가는 구체적인 작업입니다.
협업 흐름: 오후 5시 서버가 상호 작용하는 방식
이 5개 서버의 진정한 가치는 바로 여기에서 나옵니다. EventBus를 통한 협업. 어떤 서버도 고립되어 작동하지 않습니다. 게시된 각 이벤트는 다음과 같은 연쇄 반응을 유발합니다. 통합되고 자동화된 프로젝트 관리 흐름.
PM 이벤트 전체 지도
| 이벤트 | 생산자 | 소비자 |
|---|---|---|
scrum:sprint-started |
스크럼 보드 | 민첩한 측정, 회고적인 관리자 |
scrum:task-updated |
스크럼 보드 | 민첩한 측정, 시간 추적, 프로젝트 경제학 |
scrum:sprint-completed |
스크럼 보드 | 민첩한 측정, 회고적 관리자, 프로젝트 경제 |
scrum:story-completed |
스크럼 보드 | 민첩한 측정항목 |
time:entry-logged |
시간 추적 | 프로젝트 경제학 |
economics:budget-alert |
프로젝트 경제학 | (미래: 스탠드업 노트) |
economics:cost-updated |
프로젝트 경제학 | (로그 및 감사) |
retro:action-item-created |
회고 관리자 | 스크럼 보드 |
협업 다이어그램
+------------------+
| SCRUM-BOARD | (HUB CENTRALE)
| 7 tool |
+--------+---------+
|
| scrum:sprint-started
| scrum:task-updated
| scrum:sprint-completed
| scrum:story-completed
|
+-----+-----+-----+------------------+
| | | |
v v v v
+----------+ +------+ +---------------+ +----+
|agile- | |time- | |retrospective- | |... |
|metrics | |track.| |manager | | |
|4 tool | |4 tool| |5 tool | | |
|stateless | | | | | | |
+----------+ +--+---+ +------+--------+ +----+
| |
| time: | retro:action-
| entry- | item-created
| logged |
v v
+----------+ +------------------+
|project- | | SCRUM-BOARD |
|economics | | (riceve e crea |
|4 tool | | task backlog) |
+----+-----+ +------------------+
|
| economics:budget-alert
| economics:cost-updated
v
(alert e audit)
통합 시나리오: 모든 서버로 스프린트 완료
다음은 스프린트 수명 주기 동안 5개 서버가 모두 함께 작동하는 방식에 대한 예입니다.
-
계획: AI가 호출
create-sprint스크럼 보드에서. 이벤트scrum:sprint-started민첩한 지표 알림(새로운 속도) e 회고-관리자(미래 복고를 위한 콘테스트). -
실행: 개발자는 다음을 사용하여 작업 상태를 업데이트합니다.
update-task-status. 이벤트scrum:task-updatedAgile-metrics에서 번다운 재계산 활성화 e 시간 추적은 타이머를 자동으로 시작/중지할 수 있습니다. -
시간 추적: al
stop-timer, 공개 시간 추적time:entry-logged. 프로젝트 경제는 이벤트를 수신하고 시간을 변환합니다. 비용으로 예산을 업데이트합니다. -
예산 알림: 지출이 예산의 80%를 초과하면 프로젝트 경제학이 발표합니다.
economics:budget-alert팀에 알립니다. - 스프린트 마감: 스프린트가 완료되면 Agile-metrics가 다시 계산합니다. 속도 및 예측을 수행하고 회고 관리자가 자동으로 회고를 생성합니다.
-
회고: 팀은 피드백을 입력하고, 투표하고, 작업 항목을 생성합니다.
이벤트
retro:action-item-created스크럼 보드 백로그에 작업을 생성하고, 다음 스프린트를 위한 준비.
PM 서버의 내부 아키텍처
5개의 PM 서버는 모두 동일한 표준화된 아키텍처 구조를 따릅니다.
패키지의 패턴 및 규칙 공유 @mcp-suite/core:
server-name/
src/
index.ts --> entry point
server.ts --> createXxxServer(), registra tool e collaboration
services/
xxx-store.ts --> Store SQLite (gestione dati persistenti)
tools/
tool-name.ts --> handler singolo tool con schema Zod
collaboration.ts --> setupCollaborationHandlers(eventBus, store)
패턴 collaboration.ts 특히 중요합니다: 그리고 그것이 관리하는 파일
계약을 명시적으로 만드는 EventBus의 이벤트 구독 및 게시
각 서버와 나머지 제품군의 공동 작업.
공유 패키지 종속성
PM 서버는 MCP Suite의 세 가지 공유 패키지를 사용합니다.
@mcp-suite/core: MCP 서버 생성, 도구 등록, 라이프사이클 관리를 위한 기반@mcp-suite/event-bus: 서버간 통신을 위한 대표적인 이벤트 시스템@mcp-suite/database: 자동 마이그레이션 기능이 있는 SQLite 래퍼(서버 5대 중 4대에서 사용, 민첩한 메트릭 및 상태 비저장)
결론
MCP Suite의 5개 프로젝트 관리 서버는 MCP 프로토콜이 어떻게 복잡한 워크플로우 지원 진정한 협력. 스크럼보드는 다음과 같습니다. 중앙 허브, Monte Carlo를 사용한 예측 분석을 위한 민첩한 측정 항목, 시간 추적 시간 관리, 비용 관리를 위한 프로젝트 경제 및 회고 관리자 지속적인 개선을 통해 완전한 민첩한 관리 생태계가 형성됩니다.
핵심 패턴은 이벤트 기반 협업: Each server publishes events 다른 사람의 작업을 트리거하여 수동 작업을 줄이는 자동화 체인을 생성합니다. and keep the entire system in sync. The retrospective-backlog cycle is an example MCP 서버가 완전히 자동화된 방식으로 피드백 루프를 닫을 수 있는 방법을 완벽하게 만듭니다.
다음 기사에서는 고급 서버 제품군: 사건 관리자, 의사결정 로그, 액세스 정책, 품질 게이트, 워크플로우 조정자, 통찰력 엔진 및 기타, 고급 아키텍처 패턴을 사용하여 훨씬 더 복잡한 시나리오를 관리하는 방법을 발견합니다.
모든 프로젝트 관리 서버의 전체 코드는 저장소에서 사용할 수 있습니다. GitHub의 Tech-MCP.