SLIDE 01 / 10 COURSE 1145 204 SOPHOMORE PROJECT

กรอบแนวคิด Agile Framework และเครื่องมือทำงานร่วมกันสำหรับแพลตฟอร์ม Grocery POS

สัปดาห์ที่ 4: เปลี่ยนจากการต่างคนต่างเขียนโค้ด มาสู่ระบบการทำงานเป็นทีมด้วย Scrum & Kanban บน GitHub Projects / Jira, กลยุทธ์ Branching แบบ Git Flow, ขั้นตอน Pull Request Review และกติกาทีมที่ตรวจสอบหลักฐานได้จริง

CORE OUTCOME
4 ทักษะ

ตั้งค่า Board, แตก Branch, ทำ PR Review และร่าง Working Agreement

CASE PLATFORM
6 ตาราง

Users, Categories, Products, Inventory, Orders, Order_Items

DELIVERY CADENCE
3 Sprints

Sprint 1 ฐานข้อมูล/Auth · Sprint 2 ขายหน้าร้าน · Sprint 3 ตัดสต็อกและแจ้งเตือน

INTERACTIVE LABS
4 ฐาน

จำลองบอร์ดงาน, กราฟ Git Flow, ตรวจ PR Race Condition และสร้าง DoD

SLIDE 02 / 10 AGILE FOUNDATION & INCREMENTAL DELIVERY

ทำไมโปรเจกต์ปี 2 มักพังช่วงปลายเทอม? แก้ปัญหา Integration Crisis ด้วย Agile

ปัญหาคลาสสิกของการพัฒนาซอฟต์แวร์แบบดั้งเดิม (Waterfall หรือ Weekly Build) คือสมาชิกแต่ละคนแยกกันเขียนโค้ดบนเครื่องตัวเองจนถึงวันสุดท้าย แล้วนำมารวมกันทีเดียวจนเกิดบั๊กและ Conflict จำนวนมหาศาล Agile แก้ปัญหานี้ด้วยการส่งมอบงานทีละส่วนเล็กๆ (Incremental) และรวมโค้ดสม่ำเสมอ

4 CORE VALUES — AGILE MANIFESTO

ค่านิยมหลัก 4 ประการสำหรับการทำงานโครงงาน

  • 1. บุคคลและการมีปฏิสัมพันธ์ เหนือกว่า กระบวนการและเครื่องมือ
    Alistair Cockburn ย้ำว่า "คนคือปัจจัยอันดับหนึ่ง" เครื่องมืออย่าง GitHub หรือ Jira มีไว้ช่วยให้ทีมสื่อสารกันชัดขึ้น ไม่ใช่สร้างงานเอกสารซ้ำซ้อน
  • 2. ซอฟต์แวร์ที่ใช้งานได้จริง เหนือกว่า เอกสารที่สมบูรณ์ครบถ้วน
    กฎข้อแรกของ Robert C. Martin (Martin's First Law of Documentation): อย่าเขียนเอกสารเว้นแต่จำเป็นเร่งด่วน ใช้หลัก "Just enough documentation" เช่น ERD และ API Contract ที่ทีมใช้จริง
  • 3. การร่วมมือกับผู้ใช้/อาจารย์ที่ปรึกษา เหนือกว่า การยึดติดข้อตกลงตายตัว
    นำระบบ Grocery POS ไปสาธิตให้ผู้ใช้ (แคชเชียร์/เจ้าของร้าน) หรืออาจารย์ดูทุกจบ Sprint เพื่อปรับแก้ได้ทันท่วงที
  • 4. การตอบสนองต่อการเปลี่ยนแปลง เหนือกว่า การทำตามแผนเดิมอย่างแข็งทื่อ
    เมื่อพบความเสี่ยงทางเทคนิค (เช่น ปัญหาการตัดสต็อกพร้อมกัน) ทีมต้องปรับ Backlog ของ Sprint ถัดไปเพื่อลดความเสี่ยงได้ทันที
SPRINT ROADMAP · GROCERY POS

แบ่งส่งมอบ 3 รอบการทำงาน

  • Sprint 1 ฐานข้อมูลและสิทธิ์ผู้ใช้
    Schema 6 ตาราง, Login/Role (Admin, Cashier), Seed สินค้า
  • Sprint 2 หน้าจอขายหน้าร้าน (POS)
    สแกนบาร์โค้ด, ตะกร้าสินค้า, คำนวณยอดสุทธิ, ออกใบเสร็จ
  • Sprint 3 คลังสินค้าและแจ้งเตือน
    ตัดสต็อกอัตโนมัติแบบ Atomic, แจ้งเตือนเมื่อต่ำกว่า Reorder Level
เปรียบเทียบ CI กับทีม Pit Crew (Formula 1)

การรวมโค้ดบ่อยๆ (Continuous Integration) เหมือนทีมช่าง Pit Stop ที่เปลี่ยนยาง เติมน้ำมัน และปรับปีกพร้อมกันอย่างประสานสอดคล้อง แทนที่จะต่างคนต่างทำแล้วค่อยรอลุ้นตอนจบการแข่งขัน

SLIDE 03 / 10 DOMAIN MODEL & REQUIREMENT ENGINEERING

ฐานข้อมูล Grocery POS และการแปลงความต้องการเป็น User Stories

ก่อนสร้างการ์ดงานบนบอร์ด ทีมต้องเข้าใจโครงสร้างข้อมูลกลางร่วมกัน แล้วจึงเขียน User Story จากมุมมองของผู้ใช้งานจริง พร้อมจัดลำดับความสำคัญด้วย MoSCoW Model เพื่อไม่ให้หลุดขอบเขต MVP

RELATIONAL SCHEMA · GROCERY POS

โครงสร้าง 6 ตารางหลักของระบบ

ชื่อตาราง คอลัมน์สำคัญ (Key Attributes) ความรับผิดชอบ
Users user_id, username, password_hash, role_enum สิทธิ์ผู้ใช้งาน (Cashier / Manager)
Categories category_id, category_name หมวดหมู่สินค้า (เครื่องดื่ม, ของแห้ง, ของใช้)
Products product_id, category_id, barcode, name, price ข้อมูลสินค้าและราคาขายหน้าร้าน
Inventory_Stock stock_id, product_id, stock_quantity, unit, reorder_level คงคลังปัจจุบันและจุดแจ้งเตือนสั่งซื้อซ้ำ
Orders order_id, user_id, order_datetime, total_amount, status หัวบิลขายและการชำระเงิน
Order_Items order_item_id, order_id, product_id, quantity, subtotal รายการสินค้าในแต่ละใบเสร็จ
USER STORY TEMPLATE & MOSCOW

โครงสร้างการเขียน Story และจัดลำดับ MVP

โครงสร้างมาตรฐาน: "ในฐานะ [บทบาทผู้ใช้] ฉันต้องการ [สิ่งที่อยากทำ] เพื่อที่จะได้ [คุณค่าหรือผลลัพธ์ทางธุรกิจ]"
ต้องแนบ Acceptance Criteria (AC) ที่ทดสอบได้จริงเสมอ ไม่ใส่รายละเอียดโค้ดลงในตัว Story
ระดับ MoSCoW ตัวอย่าง User Story ใน Grocery POS Sprint
Must Have ในฐานะ Cashier ต้องการสแกนบาร์โค้ดเพื่อคิดเงินและตัดสต็อกทันที ลดความผิดพลาดหน้าเคาน์เตอร์ S2–S3
Should Have ในฐานะ Manager ต้องการรับแจ้งเตือนเมื่อสินค้าต่ำกว่า reorder_level เพื่อสั่งเติมทันเวลา S3
Could Have ในฐานะ Manager ต้องการส่งออกสรุปยอดขายรายวันเป็น CSV เพื่อตรวจบัญชีสิ้นวัน S3+
Won't Have ระบบสะสมแต้มสมาชิกและคูปองส่วนลดข้ามสาขา (เก็บไว้ใน Icebox สำหรับเฟสถัดไป) Icebox
SLIDE 04 / 10 FRAMEWORK COMPARISON · SCRUM & KANBAN

Scrum vs. Kanban — เลือกจังหวะและการไหลของงานให้เหมาะกับโครงงาน

ทั้ง Scrum และ Kanban ต่างมีเป้าหมายเพื่อส่งมอบงานให้เร็วและมองเห็นปัญหาได้ไว แต่มีจังหวะการวางแผนและการคุมปริมาณงานต่างกัน สำหรับโครงงานนักศึกษา 3–5 คน แนวทางผสม (Scrumban) มักได้ผลดีที่สุด

มิติการเปรียบเทียบ Scrum (เน้นรอบ Sprint คงที่) Kanban (เน้นการไหลต่อเนื่อง) การประยุกต์ใช้ใน 1145 204
รูปแบบการทำงาน แบ่งเป็นรอบเวลาคงที่ 1–4 สัปดาห์ (Time-boxed Sprints) ไหลต่อเนื่องตลอดเวลา ไม่รอจบรอบ Sprint วางแผน Sprint ละ 2 สัปดาห์ตามปฏิทินตรวจงาน
การควบคุมปริมาณงาน กำหนด Sprint Commitment ตาม Capacity ของทีม ใช้ WIP Limits จำกัดจำนวนงานที่กำลังทำพร้อมกัน จำกัดช่อง In Progress ไม่เกิน 1 งานต่อ 1–2 คน
บทบาทหน้าที่ Product Owner, Scrum Master, Developers ไม่มีบทบาทบังคับตายตัว เน้นความรับผิดชอบร่วมกัน หมุนเวียนคนดูแลบอร์ด (Scrum Master) ในแต่ละ Sprint
การปรับเปลี่ยนระหว่างทาง ไม่เปลี่ยนขอบเขตกลาง Sprint หากไม่กระทบเป้าหมายหลัก ปรับลำดับคิวงานได้ทันทีเมื่อมีงานแทรกด่วน งาน Bug ด่วนระหว่างทดสอบเข้าช่อง Kanban ได้เลย
ตัวชี้วัดหลัก (Metrics) Velocity, Burndown / Burn-up Chart Lead Time, Cycle Time, Cumulative Flow Diagram ใช้ Burn-up ของ GitHub Projects / Jira ติดตามงาน
RULE OF THUMB · ESTIMATION

อย่าเสียเวลาประเมิน Story Points ซับซ้อน

สำหรับโปรเจกต์นักศึกษา แนะนำให้แตก User Story เป็น Task ย่อยที่ทำเสร็จภายใน 1–2 วัน หรือใช้สเกลขนาดง่าย (S / M / L) แทนการถกเถียงตัวเลข Story Points นานเกินจำเป็น

WIP LIMIT BENEFIT

ทำไมต้องจำกัด WIP Limit?

เพื่อป้องกันอาการ "เปิดงานทิ้งไว้ 8 อย่าง แต่ไม่เสร็จสักอย่าง" เมื่อช่อง Awaiting Review เต็ม เพื่อนในทีมต้องหยุดเปิดงานใหม่แล้วมาช่วย Review ให้จบก่อน

TOOL CHOICE

GitHub Projects vs. Jira

GitHub Projects เชื่อมตรงกับ Issues, PR และ Code ในที่เดียวเหมาะกับทีม Dev ขนาดเล็ก ส่วน Jira โดดเด่นเรื่อง Velocity Chart และรายงาน Scrum/Kanban เต็มรูปแบบ

SLIDE 05 / 10 · INTERACTIVE LAB 1 GITHUB PROJECTS & JIRA BOARD SETUP

ห้องปฏิบัติการตั้งค่า Board: จำลองบอร์ดงาน Grocery POS

โครงสร้างบอร์ดมาตรฐานสำหรับโปรเจกต์ซอฟต์แวร์ประกอบด้วย 7 สถานะหลัก (Product Backlog, Sprint Backlog, Icebox, Todo, In Progress, Awaiting Review, Done) พร้อม Workflow Automation เมื่อปิด Issue หรือ Merge PR ทดลองสลับมุมมอง Scrum/Kanban และย้ายการ์ดด้านล่าง

INSIGHTS · BURN-UP PROGRESS
0%
0 / 0 งานเสร็จสมบูรณ์ (Done)

ทิป GitHub Projects: ในหน้า Insights ให้พิมพ์ตัวกรอง is:issue label:"user story" และอย่าย้ายงานที่เสร็จแล้วไป Archive แต่ให้สร้างคอลัมน์ Done/Completed เพื่อให้กราฟ Burn-up แสดงผลครบ

ADD NEW ISSUE / USER STORY

เพิ่มการ์ดเข้าสู่บอร์ด

GITHUB PROJECTS AUTOMATION CHECKLIST
1. Issue Templates (.github/ISSUE_TEMPLATE)
สร้างฟอร์ม User Story และ Bug Report อัตโนมัติ พร้อมติด Label เช่น user story, must have, spike
2. Built-in Workflows
เปิดใช้งาน Item closed และ Pull request merged เพื่อให้บอทย้ายการ์ดเข้า Done อัตโนมัติ
3. Iteration & Roadmap View
สร้าง Custom Field ชนิด Iteration กำหนดช่วงวันที่ Sprint 1–3 เพื่อดูไทม์ไลน์ร่วมกันในมุมมอง Roadmap
SLIDE 06 / 10 · INTERACTIVE LAB 2 GIT FLOW BRANCHING STRATEGY

กลยุทธ์ Git Flow: แยกสายโค้ดพัฒนาและ Production อย่างปลอดภัย

หากทุกคน Commit โค้ดลง main พร้อมกัน โค้ดที่ยังเขียนไม่เสร็จจะทำให้ระบบของเพื่อนพังทันที การใช้ Git Flow ช่วยแยกโค้ดที่พร้อมส่งมอบ (main) ออกจากสายรวมงานระหว่างพัฒนา (develop) และงานรายฟีเจอร์ (feature/*) กดจำลองการทำงานทีละขั้นตอนด้านล่าง

สถานะเริ่มต้น: Repository พร้อมใช้งาน

มีสาขาหลัก main (Production) และ develop (Integration) กดปุ่ม "1. Start Feature" เพื่อแตกสาขาพัฒนาฟีเจอร์สแกนบาร์โค้ด

GIT CLI EXECUTION LOG
# พร้อมจำลองคำสั่ง Git Flow สำหรับ Grocery POS
$ git branch -a
* develop
main
CONVENTIONAL COMMITS & BRANCH NAMING
  • feature/12-barcode-scan — พัฒนาฟีเจอร์ใหม่จาก develop
  • fix/15-stock-lock — แก้ไขบั๊กใน Sprint จาก develop
  • hotfix/vat-rounding — แก้ด่วนบน Production จาก main
  • feat: add barcode input handler — ขึ้นต้นข้อความ Commit ด้วย feat:, fix:, test:, docs:
SLIDE 07 / 10 PULL REQUEST WORKFLOW & QUALITY GATES

Pull Request Workflow: ด่านคัดกรองคุณภาพก่อนโค้ดเข้าสู่สาขาหลัก

Pull Request (PR) ไม่ใช่แค่ปุ่มกดรวมโค้ด แต่เป็นกระบวนการสื่อสารทางเทคนิค (Peer Review) และด่านตรวจสอบอัตโนมัติ (CI Pipeline) เพื่อให้มั่นใจว่าโค้ดใหม่ไม่ทำลายฟีเจอร์เดิมของเพื่อนในทีม

STEP 01–02

เปิด PR พร้อม Template และ Link Issue

ใช้ไฟล์ .github/PULL_REQUEST_TEMPLATE/feature_pr_template.md บังคับกรอก: คำอธิบายฟีเจอร์, ผลลัพธ์ที่คาดหวัง, รายการ Test Cases (- [ ]) และเชื่อม Issue ด้วยคำสั่ง Closes #15 แล้วลากการ์ดไปคอลัมน์ Awaiting Review

STEP 03–04

ด่านตรวจอัตโนมัติ (CI Pipeline)

ทุกครั้งที่ Push โค้ดขึ้น PR ระบบ CI (เช่น GitHub Actions) จะรัน: Source Control → Build → Automated Unit/Integration Tests → Static Code Analysis (Linter / Security Scan) หากไม่ผ่าน ห้ามกด Merge เด็ดขาด

STEP 05–06

Peer Review & Auto-Merge

กำหนด Reviewers อย่างน้อย 1–2 คนตรวจ Logic และ Edge Cases เมื่อ Approve และ CI ขึ้นสีเขียวครบจึง Squash/Merge เข้า develop จากนั้นบอทจะย้ายการ์ดไป Done และปิด Issue ให้อัตโนมัติ

AI IN PR WORKFLOW

ใช้ AI ช่วยเขียนและตรวจโค้ดอย่างมีวินัย

เครื่องมือ Agentic AI และ Copilot สามารถช่วยร่าง Unit/Regression Test, สรุปคำอธิบาย PR และสแกนช่องโหว่ Dependency ได้ แต่ Human-in-the-Loop เป็นสิ่งบังคับ: นักศึกษาต้องอ่าน เข้าใจ และตรวจสอบหลักฐานการรัน Test จริงก่อนกด Approve เสมอ

PULL REQUEST TEMPLATE (.GITHUB/PULL_REQUEST_TEMPLATE/FEATURE_PR_TEMPLATE.MD)
### Feature Description - อธิบายความสามารถใหม่และเชื่อม Issue: Closes #15 ### Expected Behavior - เมื่อแคชเชียร์กดยืนยันบิล ระบบตัดสต็อกและบันทึก Order_Items ใน Transaction เดียวกัน ### Test Cases - [x] ทดสอบตัดสต็อกสินค้าปกติ 2 รายการสำเร็จ - [ ] ทดสอบกรณีสั่งซื้อพร้อมกัน 2 จุดขายเมื่อสต็อกเหลือ 1 ชิ้น ### Additional Information (SQL / Migration) - เพิ่ม CHECK (stock_quantity >= 0) ในตาราง Inventory_Stock
SLIDE 08 / 10 · INTERACTIVE LAB 3 CODE REVIEW CASE STUDY · CONCURRENT STOCK RISK

ห้องปฏิบัติการตรวจ Pull Request #24: ระบบตัดสต็อก Grocery POS

จำลองบทบาท Reviewer ตรวจโค้ดใน PR #24 (feature/15-stock-deduction → develop) สังเกตความเสี่ยงสำคัญที่ระบุไว้ในแผนบริหารความเสี่ยงโครงงาน: ปัญหาการตัดสต็อกพร้อมกันจากหลายเครื่อง (Race Condition) แล้วเลือกรายการตรวจและตัดสินใจ

PR #24: feat: implement auto stock deduction on checkout
ผู้ส่ง: @somchai-dev · เป้าหมาย: feature/15-stock-deduction → develop
Lint: Passed Concurrency Test: Missing
14async function checkoutOrder(db, items, cashierId) {
15+ for (const item of items) {
16+ const row = await db.query('SELECT stock_quantity FROM Inventory_Stock WHERE product_id = ?', [item.id]);
17+ if (row.stock_quantity < item.qty) throw new Error('Out of stock');
18+ // BUG RISK: ไม่มี DB Transaction & Atomic Check ตอน UPDATE!
19+ await db.query('UPDATE Inventory_Stock SET stock_quantity = ? WHERE product_id = ?', [row.stock_quantity - item.qty, item.id]);
20+ }
21+ return createOrderRecord(db, items, cashierId);
22}
HOW TO FIX (ATOMIC TRANSACTION PATTERN)

ควรหุ้มด้วย BEGIN TRANSACTION ... COMMIT และใช้เงื่อนไข Atomic Update: UPDATE Inventory_Stock SET stock_quantity = stock_quantity - ? WHERE product_id = ? AND stock_quantity >= ? แล้วตรวจจำนวนแถวที่ถูกอัปเดต (affectedRows === 1) หากเป็น 0 ให้ Rollback ทันที

REVIEWER CHECKLIST

ตรวจสอบก่อนตัดสินใจ

SLIDE 09 / 10 · INTERACTIVE LAB 4 WORKING AGREEMENT & DEFINITION OF DONE

กติกาการทำงานเป็นทีม (Working Agreement) และสร้างไฟล์ CONTRIBUTING.md

เครื่องมือที่ดีที่สุดจะไร้ความหมายหากทีมไม่มีข้อตกลงร่วมกัน กำหนดกติกาการทำงาน (Daily Stand-up, Pair Programming, Sustainable Pace, Definition of Done และหลักฐานคุณภาพตามแนวทาง AUN-QA) เพื่อสร้างไฟล์กติกาประจำกลุ่มของทีมคุณ

TEAM SETTINGS BUILDER

ปรับแต่งกติกาทีมของคุณ

รายการ Definition of Done (DoD)
GENERATED CONTRIBUTING.MD PREVIEW
AVOID MICRO-MANAGEMENT

Stand-up เพื่อแก้ปัญหา ไม่ใช่จับผิด

Mike Cohn เตือนว่าอย่าตั้งกฎตายตัวแบบไร้เหตุผล (เช่น บังคับเข้าประชุม 10:00 น. เป๊ะทุกวันจนคนรู้สึกถูกจับผิด) ให้ยึดเป้าหมายคือความโปร่งใสและการช่วยเพื่อนปลดล็อก Blocker

AUN-QA EVIDENCE MINDSET

หลักฐานจริงพิสูจน์ระดับคุณภาพ (4–6)

ตามเกณฑ์คุณภาพการศึกษา (AUN-QA) การมีเอกสารแผนอย่างเดียวได้เพียงระดับ 2–3 การจะผ่านระดับ 4–6 ต้องมีหลักฐานว่าทีมใช้งานจริง (PR Logs, Burn-up Chart, Risk Review)

SLIDE 10 / 10 WEEK 4 DELIVERABLES & CONCEPT CHECK

ภารกิจประจำสัปดาห์ที่ 4 และแบบทดสอบทบทวนท้ายคาบ

ก่อนเข้าสู่ Sprint 1 อย่างเต็มรูปแบบในสัปดาห์หน้า ทุกกลุ่มต้องดำเนินการตั้งค่าเครื่องมือพื้นฐานให้ครบทั้ง 4 รายการ และทดสอบความเข้าใจร่วมกัน

DELIVERABLES CHECKLIST (FOR NEXT WEEK)

สิ่งที่ต้องส่งตรวจใน GitHub Repo ของกลุ่ม

  • 1. Repository & Branch Protection: มีสาขา main และ develop พร้อมตั้งค่าห้าม Direct Push เข้า main
  • 2. Agile Board & Sprint 1 Backlog: ตั้งค่า GitHub Projects หรือ Jira อย่างน้อย 5–7 คอลัมน์ พร้อม User Stories และ MoSCoW Labels
  • 3. PR Template & First PR: มีไฟล์ .github/PULL_REQUEST_TEMPLATE/ และมี PR อย่างน้อย 1 ใบที่ผ่านการ Review จากเพื่อนร่วมทีม
  • 4. Working Agreement: อัปโหลดไฟล์ CONTRIBUTING.md ที่ทีมตกลงร่วมกันไว้ที่ Root ของ Repository
QUICK CONCEPT CHECK (3 QUESTIONS)

ทบทวนความเข้าใจก่อนจบคาบ

1. หากพบ Bug ร้ายแรงบนระบบขายหน้าร้านที่ลูกค้าใช้งานจริง (Production) ควรแตก Branch จากสาขาใด?
2. ประโยชน์หลักของการตั้ง WIP Limit ในบอร์ด Kanban คืออะไร?
3. ข้อใดถูกต้องเกี่ยวกับการใช้ AI ช่วยสร้างโค้ดและชุดทดสอบใน Pull Request?