งานและตั๋ว — คืออะไร ระบบติดตามและการทำงานกับงาน

งานและตั๋วคืออะไร

งาน — หน่วยงานที่บันทึกในระบบติดตาม ประกอบด้วยคำอธิบาย ลำดับความสำคัญ (Critical, High, Medium, Low) ผู้รับผิดชอบ กำหนดเวลา และสถานะ ในการพัฒนาแอปมือถือ งานอาจเป็น “เพิ่มหน้าจอโปรไฟล์พร้อมรูปประจำตัว” “ใช้การแบ่งหน้าฟีด” หรือ “อัปเดต targetSdk เป็น 35” งานแต่ละงานเชื่อมโยงกับโปรเจกต์ สปรินต์ และนักพัฒนาหรือทีมที่เฉพาะเจาะจง

ตั๋ว — เอนทิตีที่กว้างขึ้น ตั๋วสามารถเป็นรายงานข้อบกพร่อง (“แอปค้างเมื่อหมุนหน้าจอบน Android 14”) คำขอฟีเจอร์ (“เพิ่มรองรับธีมมืด”) การสอบถามสนับสนุนทางเทคนิค (“การแจ้งเตือนแบบพุชไม่มา”) หรืองานจากผู้จัดการ (“เตรียมรายงานอัตราการค้างของเดือน”) เส้นแบ่งระหว่างงานและตั๋วนั้นไม่ชัดเจน: ใน Jira ทั้งสองแนวคิดรวมกันเป็น Issue ความแตกต่างหลัก: งานมีผู้รับผิดชอบเสมอ ในขณะที่ตั๋วอาจเป็นคำขอที่ไม่มีผู้รับผิดชอบเฉพาะจนกว่าจะมีการคัดแยก

ใน Scrum และ Kanban งานเป็นองค์ประกอบหลักของแบ็กล็อก งานแต่ละงานควรเป็นไปตามเกณฑ์ INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) งานอิสระสามารถดำเนินการตามลำดับใดก็ได้ ประมาณการได้ — ทีมสามารถประมาณความพยายามได้ เล็ก — เหมาะกับหนึ่งสปรินต์ ทดสอบได้ — มีเกณฑ์การยอมรับที่ชัดเจน งานขนาดใหญ่ (มหากาพย์) ถูกแบ่งเป็นงานย่อยจนกว่าเกณฑ์ทั้งหมดจะสำเร็จ

ประเภทงานในการพัฒนาแอปมือถือ

Feature — ฟังก์ชันใหม่ของแอปพลิเคชัน ตัวอย่าง: “หน้าจอเข้าสู่ระบบด้วยไบโอเมตริก (Face ID / Touch ID)” งาน Feature เชื่อมโยงกับเรื่องราวผู้ใช้เสมอและมีเกณฑ์การยอมรับ การประมาณการเป็นสตอรีพอยต์ (1, 2, 3, 5, 8, 13) Bug — ข้อบกพร่องที่พบระหว่างการพัฒนาหรือการทดสอบ ลำดับความสำคัญของตั๋วบักถูกกำหนดโดยความรุนแรง (crash → Critical, บัก UI → Medium, พิมพ์ผิด → Low) ในการพัฒนาแอปมือถือ อัตราการค้างสูงกว่า 0.1% เป็นบักวิกฤตที่ต้องแก้ไขทันที

Tech Debt / Chore — งานทางเทคนิคที่ไม่มีผลกระทบต่อผู้ใช้ที่เห็นได้: อัปเดตไลบรารี (Dependency Bump) การปรับโครงสร้าง (การย้ายจาก ViewPager เป็น ViewPager2) การตั้งค่า CI/CD การเขียนทดสอบ งาน Tech Debt มักถูกประเมินต่ำเกินไป แม้ว่าตามข้อมูลของ Stripe 2025 สูงถึง 30% ของเวลาทีมมือถือใช้ไปกับการบำรุงรักษาและการชำระหนี้ทางเทคนิค การละเลยหนี้ทางเทคนิคนำไปสู่การเพิ่มขึ้นของข้อบกพร่องและการพัฒนาฟีเจอร์ใหม่ที่ช้าลง

ประเภทเพิ่มเติม: Spike (งานวิจัย — สำรวจเทคโนโลยีใหม่ เขียน POC), Task (งานที่ไม่เกี่ยวกับโค้ด — เอกสาร การตรวจสอบการออกแบบ), Improvement (การปรับปรุงฟังก์ชันที่มีอยู่ — การปรับเวลาโหลดหน้าจอให้เหมาะสม) ใน Jira ประเภท issue ปรับแต่งได้ตามโปรเจกต์ ชุดมาตรฐานสำหรับทีมมือถือ: Story, Bug, Task, Improvement, Epic Epic — หัวข้อใหญ่ที่รวมเรื่องราวหลายเรื่อง ตัวอย่าง: “อีคอมเมิร์ซ: ตะกร้าและชำระเงิน”

วงจรชีวิตงาน: จากการสร้างถึงการปิด

Open (To Do) — งานถูกสร้างแต่ยังไม่ได้เริ่ม ประกอบด้วยคำอธิบาย เกณฑ์การยอมรับ ลำดับความสำคัญ ในสถานะนี้ งานต้องผ่านการกลั่นกรอง (grooming) ก่อนเข้าสปรินต์ In Progress — นักพัฒนาเริ่มทำงาน ในการพัฒนาแอปมือถือ การเชื่อมโยงคอมมิตและคำขอดึงกับงานเป็นสิ่งสำคัญ: ใน Jira ผ่าน Smart Commits (APP-123 #comment fix bug) ใน GitHub/GitLab ผ่านคำสำคัญในคำอธิบาย PR (Closes APP-123)

In Review — ส่งโค้ดเพื่อตรวจสอบ การตรวจสอบอัตโนมัติ: CI (Gradle build, lint, unit tests), SonarQube (คุณภาพโค้ด), Danger (changelog, tests) นักพัฒนาไม่สามารถรับงานถัดไปได้ในขณะที่งานปัจจุบันอยู่ใน Review — ซึ่งป้องกันการทำงานหลายอย่างพร้อมกัน QA / Testing — ผู้ทดสอบตรวจสอบบนอุปกรณ์จริง (Android — เวอร์ชันระบบปฏิบัติการและขนาดหน้าจอต่าง ๆ, iOS — รุ่น iPhone ต่าง ๆ) หากพบข้อบกพร่อง งานจะกลับไปที่ In Progress พร้อมความคิดเห็น

Done (Closed) — งานเสร็จสมบูรณ์: รวมโค้ดใน main/master ทดสอบแล้ว พร้อมเผยแพร่ ทีมบางทีมเพิ่มสถานะ Deployed — งานถึงผู้ใช้หลังจากบิลด์ถูกเผยแพร่ในร้านค้าแล้วเท่านั้น การปิดงานพร้อมความคิดเห็นเกี่ยวกับผลลัพธ์เป็นสิ่งสำคัญ: เวอร์ชันใด PR ใด เมตริกใดเปลี่ยนแปลง ตามข้อมูลของ Linear (2025) ทีมที่ปิดงานพร้อมคำอธิบายผลลัพธ์มีโอกาสกลับมาทำงานเดียวกันน้อยกว่า 40%

วงจรชีวิตอาจรวมถึงสถานะ Blocked — งานไม่สามารถเสร็จสมบูรณ์ได้เนื่องจากการพึ่งพาภายนอก (รอการออกแบบ การตอบกลับจากแบ็กเอนด์ การอนุมัติจากผู้จัดการ) งานที่ถูกบล็อกต้องมีความคิดเห็นพร้อมเหตุผลและวันที่ตรวจสอบครั้งถัดไป การตรวจสอบงานที่ถูกบล็อกทุกสัปดาห์ช่วยระบุความล่าช้าของระบบในกระบวนการพัฒนา ตัวบล็อกที่กินเวลานานกว่า 2 สัปดาห์ต้องยกระดับไปยังผู้จัดการผลิตภัณฑ์

ระบบติดตามงาน

Jira — มาตรฐานอุตสาหกรรมสำหรับทีมตั้งแต่ 10 คนขึ้นไป รองรับบอร์ด Scrum และ Kanban การปรับแต่งเวิร์กโฟลว์ขั้นสูง ฟิลด์กำหนดเอง ระบบอัตโนมัติ และการรวมกับ Bitbucket/GitHub ข้อเสีย: มากเกินไปสำหรับทีมเล็ก UI ช้า การกำหนดค่าซับซ้อน สำหรับโปรเจกต์มือถือ Jira ถูกปรับแต่งด้วย: ปลั๊กอิน Mobile-specific fields (Platform, OS version, Device model) การรวมกับ TestFlight และ Firebase Test Lab และระบบอัตโนมัติบิลด์เผยแพร่ Jira เป็นตัวเลือกสำหรับโปรเจกต์องค์กรที่มีกระบวนการระบบราชการ

Linear — ตัวติดตามสมัยใหม่สำหรับทีมผลิตภัณฑ์ UI รวดเร็ว รองรับแป้นพิมพ์ลัดระดับเฟิร์สคลาส Cycle ในตัว (คล้ายสปรินต์) การรวมกับ GitHub และ Slack ข้อดี: การสร้างงานที่รวดเร็วผ่าน CMD+K การกระจายเฟสอัตโนมัติ (Triaged → Backlog → Upcoming → Current → Completed) เอกสารและแผนงานในตัว เลือกใช้โดยสตาร์ทอัพและทีมผลิตภัณฑ์ที่ให้ความสำคัญกับความเร็ว ในปี 2025 40% ของโปรเจกต์มือถือใหม่ใช้ Linear

Trello — บอร์ดคัมบังง่ายสำหรับทีมเล็ก (2–5 คน) การ์ดพร้อมรายการตรวจสอบ ป้ายกำกับ วันที่ครบกำหนด ข้อเสีย: ไม่มีสปรินต์ การวิเคราะห์จำกัด ขยายยาก YouGile — ตัวเทียบเท่ารัสเซียของ Trello พร้อมบอร์ดคัมบัง แชท และการโทรวิดีโอ Asana — ตัวติดตามที่เน้นโปรเจกต์และไทม์ไลน์ การเลือกตัวติดตามขึ้นอยู่กับขนาดทีม งบประมาณ และความชอบ: Jira สำหรับองค์กร, Linear สำหรับทีมผลิตภัณฑ์, Trello/YouGile สำหรับสตาร์ทอัพ สำคัญ: เครื่องมือต้องเป็นระบบเดียวสำหรับทั้งทีม — นักออกแบบ นักพัฒนา QA ผู้จัดการทำงานในระบบเดียวกัน

แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการงาน

เขียนเกณฑ์การยอมรับ — เกณฑ์การยอมรับควรจำเพาะและตรวจสอบได้ ไม่ดี: “หน้าจอเข้าสู่ระบบทำงาน” ดี: “ผู้ใช้ป้อนอีเมลและรหัสผ่าน คลิกเข้าสู่ระบบ หากข้อมูลถูกต้อง — นำทางไปยังหน้าจอหลัก หากไม่ถูกต้อง — แสดงข้อผิดพลาด “อีเมลหรือรหัสผ่านไม่ถูกต้อง”” เกณฑ์การยอมรับ (AC) คือสัญญาระหว่างนักพัฒนา ผู้ทดสอบ และผู้จัดการผลิตภัณฑ์ หากไม่มี AC งานจะไม่เป็นไปตาม Definition of Ready (DoR) และไม่ควรเข้าสปรินต์

เชื่อมโยงทุกอย่าง คอมมิต PR กรณีทดสอบ แบบจำลองการออกแบบ (Figma) การสนทนาใน Slack — ทุกอย่างต้องเชื่อมโยงกับงาน ใน Jira ทำได้ผ่านลิงก์ในความคิดเห็น ใน Linear ผ่านการเชื่อมโยง PR อัตโนมัติ กฎหนึ่งคลิก: จากงานถึงการออกแบบ/โค้ด/ทดสอบ — ไม่เกินหนึ่งคลิก นักพัฒนาเปิดงานและเห็นแบบจำลอง Figma ลิงก์ PR และกรณีทดสอบทันที ซึ่งเร่งการเริ่มงานของสมาชิกทีมใหม่ถึง 30% ตามข้อมูลของ Linear (2025)

อย่าสร้างงานผี งานที่ไม่มีคำอธิบาย ไม่มี AC และไม่มีลำดับความสำคัญคือขยะ หากในสแตนด์อัปรายวันไม่มีใครจำได้ว่างานถูกสร้างขึ้นมาทำไม — ควรลบหรือทำให้ชัดเจน กฎ 48 ชั่วโมง: หากงานอยู่ในสถานะ In Progress โดยไม่มีกิจกรรมเป็นเวลา 48 ชั่วโมง นักพัฒนาต้องแสดงความคิดเห็นเกี่ยวกับสาเหตุของความล่าช้า ตามข้อมูลของ Jira (2025) 60% ของงานที่ไม่มีการเคลื่อนไหวนานกว่า 3 วันสุดท้ายถูกปิดโดยไม่เสร็จสมบูรณ์

การแยกย่อยงาน: มหากาพย์ เรื่องราวผู้ใช้ และงานย่อย

มหากาพย์ (Epic) — พื้นที่ฟังก์ชันขนาดใหญ่ที่รวมเรื่องราวหลายเรื่อง ตัวอย่าง: “การเริ่มต้นใช้งานผู้ใช้” รวมถึง “หน้าจอต้อนรับ” “การเลือกความสนใจ” “อัปโหลดรูปประจำตัว” “การตั้งค่าการแจ้งเตือน” เรื่องราวผู้ใช้ (User Story) — งานจากมุมมองของผู้ใช้ รูปแบบ: “ในฐานะ [บทบาท] ฉันต้องการ [การกระทำ] เพื่อ [คุณค่า]” ตัวอย่าง: “ในฐานะผู้ใช้ ฉันต้องการเข้าสู่ระบบด้วยไบโอเมตริกเพื่อไม่ต้องป้อนรหัสผ่านทุกครั้ง” เรื่องราวผู้ใช้เขียนโดยผู้จัดการผลิตภัณฑ์หรือเจ้าของผลิตภัณฑ์

งานย่อย (Sub-task) — การแยกย่อยงานทางเทคนิคภายใน Story / Task ตัวอย่างสำหรับ Story “หน้าจอโปรไฟล์”: งานย่อย 1: สร้าง UI (XML / SwiftUI), งานย่อย 2: เชื่อมต่อกับ ViewModel, งานย่อย 3: เขียน Unit Tests, งานย่อย 4: Snapshot Tests, งานย่อย 5: UI Tests (Espresso / XCUITest) กฎการแยกย่อย: งานย่อยแต่ละงานเสร็จภายใน 1–2 วัน หากนักพัฒนาประมาณงานย่อยนานกว่า — แยกย่อยเพิ่ม งานย่อยเป็นเทคนิคภายในทีม ไม่ปรากฏในแบ็กล็อกผลิตภัณฑ์ ผลรวมของการประมาณงานย่อยไม่จำเป็นต้องเท่ากับการประมาณของ Story หลัก (ส่วนหนึ่งของงานคือการสื่อสาร การตรวจสอบโค้ด การทดสอบ)

พีระมิดการแยกย่อย: Epic (ไตรมาส / ครึ่งปี) → Feature / Story (สปรินต์) → Task (1–3 วัน) → Sub-task (หลายชั่วโมง) เทคนิค INVEST ช่วยตรวจสอบคุณภาพของการแยกย่อย หากงานไม่อิสระ (ขึ้นอยู่กับผู้อื่น) — นี่แสดงถึงการแยกย่อยที่ไม่ถูกต้อง หากงานไม่เล็ก (มากกว่า 8 สตอรีพอยต์) — ต้องแยกย่อยเพิ่ม รูปแบบทั่วไป: Epic → 5–15 Stories → แต่ละ Story → 3–8 Sub-tasks การประมาณมหากาพย์สุดท้าย = ผลรวมของการประมาณ Stories แต่สปรินต์แรกมักมีค่าคลาดเคลื่อน 20–30% ในการประมาณ

ข้อผิดพลาดทั่วไปเมื่อทำงานกับงาน

ข้อผิดพลาด 1: งานใหญ่เกินไป งาน 2 สัปดาห์คือมหากาพย์ที่ต้องการการแยกย่อย งานใหญ่ไม่สามารถรวมเข้ากับการติดตามรายวันได้ พวกมันค้างอยู่ใน In Progress เป็นสัปดาห์ กฎ: ขนาดงานสูงสุด — 2–3 วันของงาน ที่ใหญ่กว่านี้ต้องแยกย่อย ผลข้างเคียง: นักพัฒนารู้สึกถึงความคืบหน้าโดยการปิด 2–3 งานต่อสัปดาห์แทนงานใหญ่หนึ่งงาน ซึ่งเพิ่มแรงจูงใจและความสามารถในการคาดการณ์กำหนดการ

ข้อผิดพลาด 2: ขาดเกณฑ์การยอมรับ นักพัฒนาดำเนินการฟีเจอร์ ผู้ทดสอบตรวจสอบ — ทุกอย่างดี ผู้จัดการ: “ปุ่มแก้ไขอยู่ที่ไหน” — “ไม่ได้เขียนไว้ในงาน” หากไม่มี AC แต่ละฝ่ายเข้าใจงานแตกต่างกัน ผลลัพธ์: ทำงานซ้ำ ความขัดแย้ง พลาดกำหนดส่ง AC คือสัญญา: หากงานไม่มีเกณฑ์ ก็ไม่พร้อมสำหรับสปรินต์ ในการกลั่นกรอง สิ่งแรกที่ตรวจสอบคือการมี AC หากไม่มี AC งานจะถูกส่งกลับไปยังผู้จัดการผลิตภัณฑ์เพื่อปรับปรุง

ข้อผิดพลาด 3: ลืมหนี้ทางเทคนิค ทีมทำงาน Feature อย่างเดียวสปรินต์แล้วสปรินต์เล่า หกเดือนต่อมา: การบิลด์ใช้เวลา 15 นาที Gradle ล้าหลัง 3 เวอร์ชันหลัก การทดสอบล้มเหลวบน CI เนื่องจาก deprecation วิธีแก้: สำรอง 20% ของเวลาทีมสำหรับ Tech Debt (แนวทางปฏิบัติ Google SRE “SLO-based error budget”) สร้างงาน Tech Debt อย่างน้อยหนึ่งงานต่อ Feature แต่ละสปรินต์ สัดส่วน: ทุก 3 งาน Feature — 1 Tech Debt หรือ Bug ซึ่งป้องกันการสะสมของหนี้ทางเทคนิคและรักษาความเร็วในการพัฒนา