概要: アジャイル プロジェクト管理のための 5 つの MCP サーバー
Il アジャイルなプロジェクト管理 ソフトウェア開発において最も複雑なドメインの 1 つです。 スプリント、タスク、パフォーマンス指標、時間追跡、予算の調整が必要 そして回顧展。スイート内 テックMCP、 これらの側面はによって管理されます 5 つの専用 MCP サーバー 誰が協力するのか EventBus を通じて、統合プロジェクト管理エコシステムを形成します。
この記事では、各サーバーとそのツールを Zod スキーマで詳細に分析します。 公開およびサブスクライブされたイベント、およびそれらを一貫したシステムに統合するコラボレーション フローです。
MCP スイートの 5 つの PM サーバー
| サーバ | 役割 | ツール | ストレージ |
|---|---|---|---|
| スクラムボード | 中央スクラムハブ | 7 | SQLite (3 テーブル) |
| アジャイルメトリクス | 分析と予測 | 4 | ステートレス |
| 時間の追跡 | 時間の追跡 | 4 | SQLite (2テーブル) |
| プロジェクトの経済学 | 予算と費用 | 4 | SQLite (2テーブル) |
| 振り返りマネージャー | アジャイルの振り返り | 5 | SQLite (3 テーブル) |
1. スクラム ボード サーバー: 中央ハブ
サーバー スクラムボード そして 作動可能な心臓 プロジェクトの MCP スイート全体の 管理。スクラム方法論に従ってスプリント、ユーザー ストーリー、タスクを管理し、 ほとんどの共同ワークフローが通過します。ほぼすべての 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 | 進行中 | レビュー中 | 完了 | ブロック済み) |
sprint-board |
スプリントのカンバンビュー | sprintId (数値、オプション、デフォルト: スプリントアクティブ) |
get-backlog |
スプリントに割り当てられていないストーリー | 誰でもない |
Zod スキーマ: create-sprint
各ツールは、入力の自動検証のために 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")
});
タスクカンバンの流れ
タスクのステータスの変更はそれぞれ、標準のカンバン フローに従います。どの状態からでも可能
への移行 blocked:
+-------+ +-------------+ +-----------+ +------+
| todo | --> | in_progress | --> | in_review | --> | done |
+-------+ +-------------+ +-----------+ +------+
| | |
+-------+-------+-------------------+
|
v
+--------+
| blocked|
+--------+
ScrumStore データベース: 3 つの SQLite テーブル
ScrumStore は、外部キーを介して相互接続された 3 つのテーブルを管理します。
+------------------+ +-------------------+ +------------------+
| 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 タスクを列に整理して完全なカンバン ビューを生成します。
指定されていない場合 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. アジャイル メトリクス サーバー: 分析と予測
サーバー アジャイルメトリクス 測定と予測のための分析ツールを提供します チームのパフォーマンス。速度の計算、バーンダウン データの生成、サイクル タイムの分析、生産 に基づく完成予測 モンテカルロシミュレーション.
基本的な特徴は、サーバーが 完全に無国籍: 所有していません 内部ストアのデータベース。データを入力として受信します (通常はスクラムボードから)。 純粋な計算を返します。
ツールテーブル: アジャイルメトリクス
| ツール | 説明 | 主なパラメータ |
|---|---|---|
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 |
+-------------------------------------------------------+
出力には、次の 3 つの信頼レベルが示されます。
{
"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"
}
バーンダウン チャート: 理想と現在
ツール 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 |
最大完了時間 |
アジャイルメトリクスによってサブスクライブされたイベント
アジャイルメトリクスと 純粋なデータ消費者。イベントは公開しませんが、サブスクライブします 進行中のスプリントの変化に対応するスクラム ボードのメンバー:
scrum:sprint-completed→ 速度再計算とスプリント終了レポートのトリガーscrum:task-updated→ リアルタイムのバーンダウンデータ更新scrum:story-completed→ 速度追跡のためのポイントの更新が完了しました
3. タイムトラッキングサーバー: タイムトラッキング
サーバー 時間の追跡 タスクに費やした時間の追跡を管理します。 のサポート付き ライブタイマー e 手動録音。維持します 2 つのテーブル (時間エントリ用とアクティブ タイマー用) を持つ 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 は 2 つの SQLite テーブルを管理します。
- アクティブタイマー: 現在実行中のタイマー (
id,taskId,userId,startTime,description) - time_entries：登録完了（
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 (デフォルト: 'ユーロ') |
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
project-economics によって購読されたイベント
time:entry-logged(時間追跡から) → 記録された時間をコストに変換し、プロジェクトに追加します。scrum:sprint-completed(スクラムボードから) → コスト分析を含むスプリント終了レポートのトリガー
5. レトロスペクティブ マネージャー サーバー: アジャイル レトロスペクティブ
サーバー 振り返りマネージャー アジャイル振り返りの完全なサイクルを管理します。 特定の形式でのセッションの作成から、カテゴリごとのフィードバックの収集まで、 最も投票されたテーマからアクション アイテムが自動生成されるまで、投票システムに追加されます。
サポート 3つのフォーマット 標準的な振り返り:
サポートされているレトロスペクティブ形式
| 形式 | カテゴリー |
|---|---|
| 怒る・悲しい・嬉しい | 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 データベース: 3 つの SQLite テーブル
- 後方: 振り返りセッション (
id,sprintId,format,status) - レトロアイテム: チームのフィードバック (
id,retroId,category,content,votes,authorId) - アクションアイテム：具体的な行動（
id,retroId,description,assignee,dueDate,status)
スクラムボードによる双方向フロー
フィードバック ループ: スプリント → バック → バックログ
- スプリントが完了 → スクラムボードが公開される
scrum:sprint-completed - レトロスペクティブ マネージャーはイベントを受信し、自動的にレトロスペクティブを作成します。
- チームはアイテムを追加して投票します
- 生成されたアクションアイテムは次のように公開されます。
retro:action-item-created - スクラムボードはイベントを受信し、バックログにタスクを作成します。
このサイクルにより、継続的な改善ループが終了します。すべての振り返りにより、 バックログ タスクとしてスクラム ワークフローに入る具体的なアクション。
コラボレーション フロー: 5 PM サーバーがどのように対話するか
これら 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-updatedアジャイルメトリクスでのバーンダウン再計算の有効化 タイムトラッキングはタイマーを自動的に開始/停止できます。 -
時間の追跡: al
stop-timer、公開時間追跡time:entry-logged。プロジェクト経済はイベントを受け取り、時間を変換します コスト、予算を更新します。 -
予算に関するアラート: 支出が予算の 80% を超える場合、プロジェクト経済学が発行する
economics:budget-alertチームに通知するため。 - スプリントの終了: スプリントの完了時に、アジャイルメトリクスが再計算します 速度と予測を実行する一方で、retrospective-manager は自動的にふりかえりを作成します。
-
回顧展: チームはフィードバックを入力し、投票し、アクションアイテムを生成します。
イベント
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 の 3 つの共有パッケージを使用します。
@mcp-suite/core: MCP サーバーの作成の基礎、ツールの登録、ライフサイクル管理@mcp-suite/event-bus: サーバー間通信の代表的なイベントシステム@mcp-suite/database: 自動移行機能を備えた SQLite ラッパー (5 台のサーバーのうち 4 台で使用、アジャイル メトリクスおよびステートレス)
結論
MCP Suite の 5 つのプロジェクト管理サーバーは、MCP プロトコルがどのように機能するかを示します。 複雑なワークフローをサポートする 本当に協力的な。スクラムボードとして 中央ハブ、モンテカルロによる予測分析のためのアジャイルメトリクス、時間追跡 時間管理、コスト管理のためのプロジェクト経済学、および 継続的な改善により、完全なアジャイル管理エコシステムが形成されます。
鍵となるパターンは、 イベント主導のコラボレーション: 各サーバーがイベントを発行します 他のユーザーのアクションをトリガーし、手動作業を削減する自動化チェーンを作成します。 システム全体の同期を保ちます。遡及バックログサイクルは一例です MCP サーバーが完全に自動化された方法でフィードバック ループを閉じる方法は完璧です。
次の記事では、 高度なサーバー スイートの担当者: インシデント マネージャー、 意思決定ログ、アクセス ポリシー、クオリティ ゲート、ワークフロー オーケストレーター、インサイト エンジンなど、 高度なアーキテクチャ パターンを使用してさらに複雑なシナリオを管理する方法を発見します。
すべてのプロジェクト管理サーバーの完全なコードはリポジトリで入手できます。 GitHub 上の Tech-MCP.