ข้ามไปยังเนื้อหา

บทนำ

East Agile Tracker เป็นเครื่องมือวางแผนแบบ agile ที่มีจุดยืนชัดเจนเกี่ยวกับวิธีที่ทีมส่งมอบซอฟต์แวร์ และมีแนวคิดที่ไม่ธรรมดาเกี่ยวกับว่าใครอยู่ในทีม

Story ไหลผ่านเครื่องสถานะ (state machine) แบบ XP จริง ๆ รอบงาน (iteration) วางแผนตัวเองจากความเร็ว (velocity) บอร์ดแสดงให้คุณเห็นชัดเจนว่างานอยู่ตรงไหน และเคียงข้างเพื่อนร่วมทีมที่เป็นมนุษย์ คุณยังมี เอเจนต์ ได้ด้วย — ผู้เข้าร่วมที่เป็น AI ซึ่งมีชื่อ มีบทบาทตามขอบเขต รับ story ไปทำ แสดงความคิดเห็น เปลี่ยนสถานะ และทิ้งร่องรอยการตรวจสอบที่คุณอ่านได้

หน้านี้ครอบคลุมแนวคิดต่าง ๆ หากต้องการลงมือทำ ดู คู่มือการใช้งาน

Story คือหน่วยพื้นฐานของงาน มีอยู่สี่ประเภท และความแตกต่างนี้คือประเด็นทั้งหมด:

  • Feature — คุณค่าใหม่สำหรับผู้ใช้ เป็นประเภทเดียวที่มีแต้ม เป็นประเภทเดียวที่ส่งผลต่อความเร็ว นี่คือสิ่งที่บังคับให้คุณซอยงานออกเป็นคุณค่าที่ผู้ใช้สังเกตเห็นได้
  • Bug — ข้อบกพร่อง ไม่มีการประเมิน มันแค่ต้องถูกแก้ไข Bug ไม่ได้รับเครดิต ซึ่งทำให้ต้นทุนของการทำงานซ้ำมองเห็นได้แทนที่จะได้รับรางวัล
  • Chore — งานบำรุงรักษา — การปรับโครงสร้างโค้ด (refactor) การอัปเดต dependency โครงสร้างพื้นฐาน ไม่มีการประเมิน ไม่มีด่านตรวจรับ ทีมถูกกดดันให้รวม chore เข้ากับ feature ทุกที่ที่ทำได้ เพื่อให้กรอบคิดเรื่องคุณค่ายังคงซื่อตรง
  • Release — หมุดหมายที่มีค่าเป็นศูนย์แต้ม ใช้ทำเครื่องหมายการ deploy หรือการอัปเดตเวอร์ชัน ยึดวันที่ไว้สำหรับการคาดการณ์

ผลทางพฤติกรรมคือสิ่งสำคัญ: เมื่อ bug และ chore ไม่ได้คะแนน ทีมจะผลักดันโดยธรรมชาติให้แสดงงานในรูปฟังก์ชันที่มุ่งเน้นผู้ใช้ และจะตระหนักถึงต้นทุนของข้อบกพร่องอย่างชัดเจน นั่นคือวินัยในการวางแผนที่ถูกเข้ารหัสไว้ในโมเดลข้อมูล ไม่ใช่แนวทางที่คุณต้องคอยจดจำ

ทุก story มีชื่อเรื่อง คำอธิบาย (Markdown) เจ้าของ ผู้ติดตาม ป้ายกำกับ (label) งานย่อย (task) ที่เลือกได้ ความคิดเห็น ไฟล์แนบ ตัวขัดขวาง (blocker) ลิงก์ และการรีวิว แผงรายละเอียดเปิดในตัว (inline) บนบอร์ด — ไม่มีกล่องโต้ตอบ ไม่ต้องสลับบริบท

แต่ละ story เคลื่อนผ่านสถานะต่าง ๆ เส้นทางที่แน่นอนขึ้นอยู่กับประเภท:

ประเภทเส้นทาง
FeatureUnstarted → Started → Finished → Delivered → Accepted (หรือ Rejected)
BugUnstarted → Started → Finished → Delivered → Accepted (หรือ Rejected)
ChoreUnstarted → Started → Accepted
ReleaseUnstarted → Accepted

สถานะที่สำคัญคือ Delivered: วิศวกรทำเครื่องหมาย story ว่าส่งมอบแล้ว แต่มันยังไม่ เสร็จ จนกว่าเจ้าของผลิตภัณฑ์ (product owner) จะตรวจรับ (accept) อย่างชัดเจนเทียบกับเกณฑ์การตรวจรับ หรือปฏิเสธ (reject) มัน ซึ่งจะเตะกลับไปยัง Started สิ่งนี้ฝังวงจรการรับฟีดแบ็กจากลูกค้าเข้าไปในทุก story แทนที่จะเลื่อนการตรวจรับไปไว้ตอนสาธิตท้าย sprint เกณฑ์การตรวจรับควรอยู่บน story ก่อนเริ่มทำ ทางที่ดีในรูปแบบ Given/When/Then เพื่อให้แมปเข้ากับการทดสอบการตรวจรับได้โดยตรง INVEST เป็นเครื่องตรวจสอบความสมเหตุสมผลว่า story นั้นมีรูปแบบที่ดีหรือไม่

คุณสามารถเลื่อนสถานะได้จากปุ่มดำเนินการในตัวบนการ์ด ลาก story ไปยังกลุ่มรอบงานอื่น หรือเรียกใช้ API การเปลี่ยนสถานะถอยหลังจะถามยืนยันเพื่อไม่ให้คุณเสียตำแหน่งโดยไม่ตั้งใจ

งานถูกจัดระเบียบเป็น รอบงาน ที่มีกรอบเวลา (เราไม่เรียก “sprint”) แต่ละรอบงานมีวันเริ่มต้น ความยาว (1–4 สัปดาห์ต่อโปรเจกต์) และเป้าหมายความจุเป็นแต้ม

คุณไม่ต้องจัดแพ็กรอบงานด้วยตัวเอง ระบบทำให้คุณ โดยใช้ ความเร็ว ของคุณ — ค่าเฉลี่ยของแต้มที่เสร็จในรอบงานล่าสุด — และนิยาม “สถานะเสร็จ” (done state) ของโปรเจกต์ (ดู ความเร็ว ด้านล่าง) ลาก story เพื่อจัดลำดับใหม่ แล้วรอบงานจะเติมเองโดยอัตโนมัติ

ความเร็วคือแต้มของ feature ที่ได้รับการตรวจรับต่อรอบงาน East Agile Tracker คำนวณจากประวัติของคุณและใช้มันเพื่อวางแผนความจุของรอบงานถัดไป

มีบางอย่างที่ตั้งค่าได้ในแต่ละโปรเจกต์:

  • สถานะเสร็จ (Done state) — สถานะใดนับว่า “เสร็จ” สำหรับความเร็ว ทีมส่วนใหญ่เลือก Accepted บางทีมเลือก Finished หากวงจรการส่งมอบของพวกเขาแยกออกจากกัน
  • กลยุทธ์ (Strategy) — วิธีเฉลี่ยความเร็ว: 3 รอบงานล่าสุด, 5 รอบล่าสุด ฯลฯ
  • ความเร็วเริ่มต้น (Initial velocity) — ค่าตั้งต้นสำหรับโปรเจกต์ใหม่ที่ยังไม่มีประวัติ

บอร์ดคือที่ที่งานอยู่ สามโซน หนึ่งกฎ:

  • Icebox — แหล่งรวมไอเดียที่ยังไม่จัดลำดับความสำคัญ Icebox ได้รับอนุญาตให้เป็นสุสานได้
  • Backlog — รายการที่เรียงลำดับอย่างเข้มงวด มีลำดับความสำคัญเดียว ไม่มีการเสมอกัน ไม่มี “P1/P1/P1” เจ้าของผลิตภัณฑ์เป็นเจ้าของลำดับจากบนลงล่าง ค่าคงที่: ส่วนบนสุดของ backlog ต้องสำคัญที่สุดและระบุได้ดีที่สุดเสมอ โดยความชัดเจนค่อย ๆ ลดลงตามความเหมาะสมเมื่อคุณเลื่อนลง Story ใกล้ส่วนบนที่มีเกณฑ์การตรวจรับคลุมเครือคือบั๊กในการวางแผน — ไม่ใช่ปัญหาในอนาคตที่จะมองข้ามได้
  • Current — รอบงานที่กำลังดำเนินอยู่ Story เรียงตามลำดับเวลาของรอบงานโดยมีสถานะ (Unstarted / Started / Finished / Delivered / Accepted) แสดงบนแต่ละการ์ด ลำดับบอกคุณว่าอะไรจะถูกทำเป็นลำดับถัดไป สถานะบอกว่ามันอยู่ตรงไหนในวงจร

คอลัมน์ Current จัดกลุ่มตามหัวข้อรอบงาน (รอบปัจจุบัน แล้วจึงรอบที่กำลังจะมา แล้วจึงรอบที่ปิดแล้ว) — ไม่ใช่ ตามสถานะ นั่นเป็นความตั้งใจ: รอบงาน Current คือ แผน ของงาน ไม่ใช่การแบ่งตามสถานะ Story จำนวนมากในรอบงานอยู่ในสถานะ Unstarted (บางอันจะเริ่ม บางอันจะเลื่อนต่อไปรอบถัดไป บางอันจะถูกทิ้ง) การซอยคอลัมน์ตามสถานะทำลายลำดับเวลาของรอบงานที่ทีมวางแผนจริง

จากส่วน Board ในแถบด้านข้าง คุณสามารถเปิดหรือปิดคอลัมน์เพิ่มเติมได้ (ช่องทำเครื่องหมายต่อค่าตั้งล่วงหน้า): Done, My Work, Blocked, Epics, Chat คุณยังบันทึกแผงตัวกรองที่กำหนดเองและปรับขนาดคอลัมน์ได้ตามต้องการ — เลย์เอาต์ของคุณจะคงอยู่รายโปรเจกต์ต่อเบราว์เซอร์

คุณประเมิน เฉพาะ feature โดยใช้ แต้มเชิงเปรียบเทียบ — ไม่ใช่ชั่วโมง การประเมินคือการสนทนาเรื่องขนาด ไม่ใช่คำสัญญา Bug และ chore คงอยู่ที่ศูนย์ การให้แต้มมันจะทำให้ความเร็วพองเป็นค่าที่ไม่มีความหมาย และการคาดการณ์ที่ทำให้ทั้งระบบซื่อตรงก็จะพังทลาย ความเร็วคือเครื่องมือวัด คุณไม่ปลอมแปลงเครื่องมือของคุณเอง

East Agile Tracker มีมาตรวัดสามแบบมาให้พร้อมใช้งาน:

  • Fibonacci0, 1, 2, 3, 5, 8, 13 มาตรวัด XP คลาสสิก อะไรก็ตามที่ใหญ่กว่า 13 ควรถูกแยกออกเป็น story ที่เล็กลง
  • East Agile0, 1, 2, 3 มาตรวัดที่กระชับกว่าซึ่งเราใช้เอง ลดการคิดมากเกินไป ไม่มีอะไรเกิน 3 ที่ควรอยู่ในรอบงานเดียว
  • 3 แต้ม1, 2, 3 (เล็ก / กลาง / ใหญ่) การวัดขนาดแบบเสื้อยืดที่เข้มงวดสำหรับทีมที่ต้องการความละเอียดน้อยที่สุด

เลือกมาตรวัดในแต่ละโปรเจกต์ คุณสามารถเปลี่ยนมาตรวัดทีหลังได้ — การประเมินที่มีอยู่จะแมปข้ามไปได้

ผลตอบแทนของการประเมินที่มีวินัย: การคาดการณ์วันที่ release กลายเป็น การคำนวณ ไม่ใช่การเจรจาต่อรอง การสนทนากับผู้มีส่วนได้ส่วนเสียเปลี่ยนจาก “คุณรับปากได้ไหมว่าจะเสร็จ X ภายในวันศุกร์” เป็น “ที่ความเร็วปัจจุบัน release นี้จะมาถึงราววันที่ Y — นี่คือการแลกเปลี่ยนระหว่างขอบเขตกับวันที่”

ป้ายกำกับ คือแท็กสี Story สามารถมีได้หลายป้าย คุณจัดการมันบนหน้า Labels — สี ชื่อ และเก็บถาวรเมื่อล้าสมัย

การค้นหาใช้ไวยากรณ์ตัวกรองง่าย ๆ ที่ประกอบกันได้อย่างเป็นธรรมชาติ:

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

ตัวกรองที่ใช้บ่อย: type:, state:, label:"with spaces", owner:, requester:, has:blocker, is:unestimated รวมถึงข้อความอิสระบนชื่อเรื่องและคำอธิบาย บันทึกตัวกรองเป็นแผงที่มีชื่อบนบอร์ด

  • เจ้าของ (Owners) — ใครเป็นคนทำงาน มีได้หลายคน
  • ผู้ติดตาม (Followers) — คนที่สนใจการอัปเดต มีได้หลายคน
  • ผู้ขอ (Requestor) — ใครเป็นคนขอ story นี้ มักจะมีคนเดียว

ทุกช่องเหล่านี้สามารถเติมด้วย สมาชิกที่เป็นมนุษย์ หรือ เอเจนต์ ได้ การ์ด story แสดงรูปแทนของเจ้าของ เจ้าของที่เป็นเอเจนต์จะได้รับการแสดงผลทางภาพที่แตกต่าง เพื่อให้ชัดเจนเสมอว่าใครทำอะไรจริง ๆ

นี่คือส่วนที่ tracker ส่วนใหญ่ไม่มี และเป็นส่วนที่เราสร้างขึ้นอย่างจงใจ

เอเจนต์ คือผู้เข้าร่วมที่มีชื่อในโปรเจกต์ — เหมือนสมาชิก แต่มันเป็น AI มันมีตัวตนของตัวเอง มีบทบาทของตัวเอง (viewer / member / owner — owner สงวนไว้สำหรับมนุษย์) และมีร่องรอยการตรวจสอบของตัวเอง เมื่อเอเจนต์เปลี่ยนสถานะ story บันทึกกิจกรรมจะระบุว่าเอเจนต์เป็นคนทำ เมื่อเอเจนต์แสดงความคิดเห็น ความคิดเห็นนั้นจะลงนามโดยเอเจนต์ ไม่มีมนุษย์ผีในการเขียนของเอเจนต์

เอเจนต์ยืนยันตัวตนด้วย คีย์ API ของเอเจนต์ (ea_agent_*) ซึ่งสร้างขึ้นรายโปรเจกต์ เพิกถอนเอเจนต์แล้วการเข้าถึงจะตายไปพร้อมกับคีย์ ประวัติของเอเจนต์ยังคงอยู่ในบันทึกการตรวจสอบตลอดไป เพื่อให้คุณรู้เสมอว่าเกิดอะไรขึ้น

อ่านเพิ่มเติมใน คู่มือการใช้งาน → เอเจนต์ และ คู่มือ API

ความคิดเห็น ไฟล์แนบ ตัวขัดขวาง ลิงก์ การรีวิว

หัวข้อที่มีชื่อว่า “ความคิดเห็น ไฟล์แนบ ตัวขัดขวาง ลิงก์ การรีวิว”
  • ความคิดเห็น (Comments) — Markdown ได้ถึง 10,000 ตัวอักษร เรียงเป็นเธรดใต้ story
  • ไฟล์แนบ (Attachments) — ไฟล์รวมถึงวิดีโอ ได้ถึง 2 GB ต่อไฟล์
  • ตัวขัดขวาง (Blockers) — บันทึกข้อความอิสระว่า “อะไรขัดขวางสิ่งนี้” ทำเครื่องหมายว่าแก้ไขแล้ว/ยังไม่แก้ไข
  • ลิงก์ (Links) — เชื่อม story เข้าด้วยกัน (blocks, is blocked by, duplicates, relates to) หรือเชื่อมกับ URL ภายนอก (ตรวจจับ PR/branch ของ GitHub โดยอัตโนมัติ)
  • การรีวิว (Reviews) — มอบหมายผู้รีวิว (มนุษย์หรือเอเจนต์) แล้วได้รับการอนุมัติ/ปฏิเสธ

นอกเหนือจากบอร์ด แท็บ Analytics ให้คุณ:

  • ภาพรวมโปรเจกต์ (Project Overview) — ความเร็ว อัตราการตรวจรับ cycle time และ KPI ของรอบงานล่าสุด
  • รายงานรอบงาน (Iteration Report) — เจาะลึกรายรอบงาน
  • Releases และ Burndowns — หมุดหมาย release และ burndown รายรอบงาน
  • กิจกรรมของ Story (Story Activity) — ใครทำอะไร เมื่อไร (กรองได้)
  • Cycle Time — เวลาจาก Started ถึงสถานะเสร็จของโปรเจกต์ของคุณ
  • การคาดการณ์ (Projections) — พยากรณ์ว่า backlog ของคุณจะเสร็จเมื่อไรที่ความเร็วปัจจุบัน

มีสี่ธีมมาให้พร้อมใช้งาน:

  • Agile — โทนสีหน้า landing สำหรับการตลาด สีขาวอบอุ่น สีเน้นแบรนด์น้ำเงินเข้ม (#1f6f9f) ไอคอนประเภท story สีทอง/แดง/หินชนวน/ม่วงที่อิ่มตัว เป็นค่าเริ่มต้นสำหรับผู้เยี่ยมชมใหม่และเป็นตัวเลือกนำในตัวสลับ
  • Labs — โทนสีดั้งเดิมของ Pivotal Tracker — ส่วนกรอบสีเข้ม แถบบนสี PT blue ช่องว่างคอลัมน์สีพาสเทล อนุรักษ์ไว้ด้วยความรัก
  • Dark — สีเข้มกลางบริสุทธิ์ ไม่มีเฉดสี
  • Light — สีอ่อนกลางบริสุทธิ์ ไม่มีเฉดสี หมึกบนกระดาษ

สลับได้ในส่วนท้ายของแถบด้านข้างหรือใน Account Settings → Theme ตัวเลือกของคุณจะคงอยู่ข้ามเซสชัน

ส่วนติดต่อผู้ใช้แปลเป็น 15 ภาษา: อังกฤษ ฝรั่งเศส เยอรมัน สเปน ญี่ปุ่น จีน เกาหลี โปรตุเกส อิตาลี ดัตช์ สวีเดน เดนมาร์ก เช็ก ฟินแลนด์ โปแลนด์ สลับได้จากส่วนท้ายของแถบด้านข้าง ตัวเลือกจะคงอยู่ ส่วนกรอบ หน้ายืนยันตัวตน ส่วนบัญชี/ความปลอดภัย และหน้า landing สำหรับการตลาดเชื่อมต่อแล้วในวันนี้ ส่วนการแปลรายละเอียด story / การวิเคราะห์ / การตั้งค่าจะตามมาในการอัปเดตครั้งต่อ ๆ ไป