1145 204 SOPHOMORE PROJECT · WEEK 06 · GROCERY POS PLATFORM

การวางแผน Sprint 1 และตั้งค่า Environment Setup

01 / 09
SLIDE 01 · ORIENTATION Sprint 1: Database & Auth

เปลี่ยนเอกสารออกแบบสัปดาห์ที่ 5 ให้พร้อม ลงมือโค้ดใน Sprint 1

สัปดาห์ที่ 6 เป็นจุดเปลี่ยนจากการออกแบบระบบ Grocery POS Platform สู่การพัฒนาซอฟต์แวร์จริงตามแนวทาง Agile/Scrum ทีมจะต้องจัดระเบียบ Backlog, ประเมินขนาดงานด้วย Story Points, วางโครงสร้างโปรเจกต์มาตรฐาน, ตั้งค่า Docker ให้ทุกเครื่องรันเหมือนกัน และลงนามใน Sprint Commitment

3-SPRINT ROADMAP · GROCERY POS PLATFORM

แผนส่งมอบซอฟต์แวร์ 3 สปรินต์ (อ้างอิงโครงสร้างชิ้นงานปี 2)

Sprint ขอบเขตหลัก (Core Scope) ผลลัพธ์ที่ใช้งานได้ (Increment)
Sprint 1 (สัปดาห์นี้) Database & Auth + Dev Environment Docker Compose ทำงาน, DB Schema + Seed, Login/RBAC API พร้อมเทสต์
Sprint 2 POS Order Screen & Payment หน้าคิดเงินสแกนสินค้า, คำนวณยอด, PromptPay/Cash, ออกใบเสร็จ
Sprint 3 Inventory Alert & Analytics ตัดสต็อกอัตโนมัติ, แจ้งเตือนวัตถุดิบ/สินค้าใกล้หมด, รายงานยอดขาย PDPA
เป้าหมายการเรียนรู้สัปดาห์ที่ 6
  • 1. Backlog Grooming: คัดกรองและแตก User Story ตามหลัก MoSCoW พร้อม Acceptance Criteria
  • 2. Estimation: ประเมินความซับซ้อนสัมพัทธ์ด้วย Planning Poker และ Story Points
  • 3. Boilerplate & Docker: ตั้งค่าโครงสร้างโค้ดและ Container ให้ทุกคนรันคำสั่งเดียวติด
  • 4. Sprint Commitment: คำนวณ Capacity และกำหนด Definition of Done ที่วัดผลได้
SLIDE 02 · BACKLOG GROOMING Walking Skeleton & MoSCoW

Backlog Grooming: คัดงานที่สร้างคุณค่าแรกด้วย Walking Skeleton

Product Backlog ไม่ใช่รายการสิ่งที่ต้องทำทั้งหมดในคราวเดียว การทำ Refinement (Grooming) คือการเรียงลำดับความสำคัญด้วยโมเดล MoSCoW (Must, Should, Could, Won't) และเลือกชุดงานขั้นต่ำที่เชื่อมต่อระบบตั้งแต่ฐานข้อมูลถึงหน้าจอได้จริง (Walking Skeleton) เพื่อเข้าสู่ Sprint 1

ข้อควรระวังในการเขียน User Story: รูปแบบมาตรฐานต้องระบุ As a [บทบาท], I want to [สิ่งที่ต้องการ] so that [คุณค่าที่ได้] และต้องมี Acceptance Criteria แบบ Given–When–Then ที่ทดสอบได้จริง มิฉะนั้นคะแนนประเมินหมวด Requirements & Backlog จะตกอยู่ในระดับพอใช้ (14–17 คะแนน)
SLIDE 03 · ESTIMATION Story Points & Planning Poker

Story Points วัดขนาดและความเสี่ยงสัมพัทธ์ ไม่ใช่จำนวนชั่วโมง

ตามหลักของ Mike Cohn นักพัฒนามักประเมินเวลาเป็นชั่วโมงพลาดเมื่อเจอความไม่แน่นอน การใช้ Story Points แบบลำดับฟีโบนัชชี (1, 2, 3, 5, 8, 13) ช่วยให้ทีมเปรียบเทียบขนาดสัมพัทธ์ได้รวดเร็ว เช่น งาน 8 คะแนนใช้แรงและความซับซ้อนประมาณสองเท่าของงาน 4 คะแนน และหากงานใดเกิน 8 คะแนนต้องแบ่ง (Split) ให้เล็กลงก่อนนำเข้า Sprint

INTERACTIVE LAB · PLANNING POKER SIMULATOR

ทดลองโหวต Story Points สำหรับ Sprint 1

เลือกไพ่คะแนนของคุณ (Your Estimate)
TEAM CONSENSUS & DISCUSSION

US-101: ออกแบบและ Migrate ฐานข้อมูล POS 6 ตารางหลัก

ครอบคลุมตาราง Users, Categories, Products, Inventory_Stock, Orders และ Order_Items พร้อมข้อมูลทดสอบเริ่มต้น 20 รายการ

ผลการเปิดไพ่ของทีม (4 Developers)

เลือกไพ่ของคุณทางซ้าย แล้วกด "เปิดไพ่พร้อมกัน" เพื่อดูความเห็นต่างของทีม

Velocity คือเข็มทิศวางแผน ไม่ใช่เกมแข่งขัน: คะแนนรวมที่ทำสำเร็จในแต่ละ Sprint (Velocity) ใช้คำนวณงบประมาณงานของ Sprint ถัดไป ห้ามนำไปเปรียบเทียบข้ามทีมเพราะแต่ละทีมนิยามฐาน 1 Point ต่างกัน
SLIDE 04 · ARCHITECTURE & BOILERPLATE Relational Schema & Greenfield Setup

Boilerplate Setup: โครงสร้างฐานข้อมูล POS และ Repository มาตรฐาน

หลักการ Simple Design ของ Agile แนะนำให้สร้างโครงสร้างที่เรียบง่าย ชัดเจน และรองรับงาน Sprint 1 ได้ทันที โดยแยกชั้น Business Logic ออกจาก Third-party API และกำหนดโครงสร้างไฟล์กลาง (Scaffolding) ให้สมาชิกทุกคนเขียนโค้ดและเทสต์ในมาตรฐานเดียวกัน

PROJECT DIRECTORY TREE · CLICK TO INSPECT
CORE RELATIONAL SCHEMA (SPRINT 1 TARGET)
Table Key Columns หมายเหตุด้านวิศวกรรม & PDPA
Users user_id, username, password_hash, role_enum เก็บรหัสผ่านแบบ Hash (bcrypt/argon2) เท่านั้น
Categories category_id, category_name เช่น เครื่องดื่ม, ของแห้ง, ของสด, เบเกอรี่
Products product_id, category_id, sku_barcode, name, price ราคาต่อหน่วยใช้ชนิด Decimal/Numeric ป้องกันทศนิยมเพี้ยน
Inventory_Stock stock_id, product_id, stock_quantity, unit, reorder_level รองรับ Atomic Update ป้องกันตัดสต็อกซ้อนกัน
Orders & Order_Items order_id, user_id, order_datetime, payment_method, total_amount PromptPay / Cash / Credit Card และไม่เก็บเลขบัตร/เบอร์โทรเกินจำเป็น
SLIDE 05 · DOCKER ENVIRONMENT Eliminate Environment Viscosity

Docker Environment: จบปัญหา "เครื่องฉันรันได้" ด้วย Container เดียวกัน

เมื่อทีมมีสมาชิกหลายคนที่ใช้ Windows, macOS หรือ Linux ต่างกัน ความหนืดของสภาพแวดล้อม (Viscosity) จะทำให้เสียเวลากับเวอร์ชัน Database หรือ Runtime ไม่ตรงกัน Docker Compose ช่วยให้ทั้ง Frontend, Backend API และ PostgreSQL ทำงานด้วยคำสั่งเดียวและตั้งค่าผ่าน .env อย่างปลอดภัย 


            

              
              
            

          


          

            

              TROUBLESHOOTING LAB · ปัญหาที่พบบ่อยในสัปดาห์แรก
              
คลิกเลือกอาการเพื่อดูวิธีแก้ไข

              

                
                
                
              

              

                
              

            

          

        

      


      
      

        

          

            SLIDE 06 · WORKFLOW & CI GATE
            GitHub Projects & Continuous Integration
          

          
GitHub Projects & CI: ทำงานเป็นทีมเหมือนทีม Pit Crew Formula 1

        


        

          Continuous Integration (CI) ป้องกันอาการ "Morning-After Syndrome" ที่โค้ดพังเมื่อรวมงานปลายสัปดาห์ ทุก Task ใน Sprint 1 ต้องเชื่อมกับ GitHub Issue ผ่าน Branch ย่อยและ Pull Request พร้อมผ่านด่าน Automated Test ก่อนย้ายการ์ดไป Done
        


        

          

            

              INTERACTIVE KANBAN SIMULATION · SPRINT 1 BOARD
              
ลองเลื่อนสถานะงาน Sprint 1 ผ่าน Pipeline (Todo → Done)

            

            
          


          

            
          

        


        

          

            STEP 01 · ISSUE TEMPLATE
            User Story + Linked Tasks
            

              แตก User Story เป็น Task ย่อยที่ใช้เวลา ≤ 1 วัน แล้วเชื่อมด้วย #issue บน GitHub Projects
            

          

          

            STEP 02 · BRANCH & PR
            ห้าม Commit ตรงเข้า main
            

              ตั้งชื่อ Branch เช่น feat/us102-auth-jwt เปิด Pull Request และให้เพื่อนอย่างน้อย 1 คนรีวิว
            

          

          

            STEP 03 · AUTOMATED CI
            Build + Lint + Unit Test
            

              บอร์ดย้ายไป Done ได้ก็ต่อเมื่อ Acceptance Criteria ผ่านและ CI เป็นสีเขียว
            

          

        

      


      
      

        

          

            SLIDE 07 · CAPACITY & COMMITMENT
            Sprint 1 Planning Simulator
          

          
Sprint Commitment: วางคำมั่นสัญญาให้สมดุลกับ Capacity จริงของทีม

        


        

          Scrum Guide กำหนดให้ Sprint Planning ตอบ 3 คำถาม: (1) ทำไม Sprint นี้จึงมีคุณค่า (Sprint Goal), (2) ทำอะไรได้บ้างตามกำลังจริงของทีม, และ (3) จะส่งมอบให้ผ่าน Definition of Done อย่างไร ทดลองปรับกำลังคนและเลือก Story เพื่อคำนวณความเสี่ยงก่อนลงนาม Commitment
        


        

          

            TEAM CAPACITY INPUTS
            

              

                
                
              

              

                
                
              

            


            

              
              
            


            

              
              
            


            

              เลือก Backlog ที่จะ Commit เข้า Sprint 1:
              

                
              

            

          


          

            

              

                กำลังรองรับสูงสุด (Capacity)
                
18 pts

                คำนวณจาก 4 คน · 2 สัปดาห์ · 75%
              

              

                งานที่เลือกรวม (Committed)
                
16 pts

                สมดุลดี (89% ของ Capacity)
              

            


            

              
            


            

              
              

                Sprint 1 Goal (Draft): ส่งมอบโครงสร้างฐานข้อมูล Grocery POS 6 ตาราง ระบบยืนยันตัวตนแยกสิทธิ์ Cashier/Manager และสภาพแวดล้อม Docker Compose ที่รันทดสอบผ่าน CI ได้ทุกเครื่อง
              

            

          

        

      


      
      

        

          

            SLIDE 08 · DOD, RISKS & RUBRIC
            Quality & 25-Point Evaluation
          

          
Definition of Done, แผนลดความเสี่ยง และเกณฑ์ประเมิน 25 คะแนน

        


        

          งานที่ยังเขียนไม่เสร็จหรือยังไม่มี Automated Test จะไม่ถูกนับเป็น Increment ในวัน Sprint Review ทีมต้องกำหนด Definition of Done (DoD) ที่ชัดเจน ระบุความเสี่ยงทางเทคนิคตั้งแต่ต้น และตรวจสอบคุณภาพ Backlog ให้ตรงตามรูบริกของรายวิชา
        


        

          

            DEFINITION OF DONE (SPRINT 1: DATABASE & AUTH)
            
    
              
  • 1. Code & PR: โค้ดถูก Merge ผ่าน Pull Request และมีเพื่อนร่วมทีม Review อย่างน้อย 1 คน
    • 
              
  • 2. Tests Pass: Unit Test และ Acceptance Criteria (Given–When–Then) ผ่านครบ 100%
    • 
              
  • 3. Clean Build: รัน docker compose up --build บนเครื่องสมาชิกอื่นแล้วใช้งานได้ทันที
    • 
              
  • 4. Security & PDPA: ไม่มีรหัสผ่านแบบ Plain-text, ไม่ Commit .env, และไม่เก็บ PII เกินความจำเป็น
    • 
            

          


          

            SPRINT 1 RISK REGISTER (GROCERY POS)
            
    
              
  • ความเสี่ยงตัดสต็อกซ้อนกัน (Concurrency): ออกแบบ Transaction & Row Lock ไว้ใน Schema ตั้งแต่ Sprint 1
    • 
              
  • OS / Port Conflict ระหว่างสมาชิก: บังคับใช้ Docker Compose พร้อม Healthcheck และคู่มือแก้พอร์ตชน
    • 
              
  • ขอบเขต Sprint 1 บานปลาย (Scope Creep): ย้ายฟีเจอร์เสริม (เช่น สะสมแต้ม) ไปไว้ใน Icebox/Sprint 3
    • 
              
  • Backlog ขาด Acceptance Criteria: ใช้ GitHub Issue Template บังคับกรอกช่อง Given–When–Then
    • 
            

          

        


        

          COURSE GRADING RUBRIC · REQUIREMENTS & AGILE BACKLOG (25 คะแนน)
          

            

              
                

                  ระดับคุณภาพ
                  ช่วงคะแนน
                  เกณฑ์พิจารณาจากอาจารย์ที่ปรึกษาและกรรมการ (50% + 50%)
                

              
              
                

                  ดีเยี่ยม
                  22–25
                  วิเคราะห์ Functional/Non-functional Requirements ครบถ้วน เขียน User Stories ตามมาตรฐาน Agile พร้อมประเมิน Story Points และระบุ Acceptance Criteria สมบูรณ์
                

                

                  ดี
                  18–21
                  Requirements และ User Stories ครอบคลุมฟังก์ชันหลักของระบบ มีการประเมิน Story Points โดยมีจุดต้องปรับแก้เล็กน้อย
                

                

                  พอใช้
                  14–17
                  User Stories เขียนไม่ถูกรูปแบบ ขาดรายละเอียด Acceptance Criteria หรือวิเคราะห์ Requirements ไม่ครอบคลุม
                

                

                  ปรับปรุง
                  0–13
                  ไม่มีการวิเคราะห์ Requirements หรือจัดทำ User Story Backlog ตามหลักวิศวกรรมซอฟต์แวร์
                

              
            

          

        

      


      
      

        

          

            SLIDE 09 · WORKSHOP & DELIVERABLES
            Action Plan & Auto-Saved Checklist
          

          
Workshop ท้ายคาบ: เช็กลิสต์ส่งมอบก่อนเริ่มพัฒนา Sprint 1

        


        

          ให้แต่ละกลุ่มดำเนินการตั้งค่า Environment และ Sprint 1 Backlog ให้ครบทั้ง 6 รายการด้านล่าง ระบบจะบันทึกสถานะเช็กลิสต์ของกลุ่มไว้ให้อัตโนมัติ และสามารถส่งออกเป็นไฟล์สรุป Sprint 1 Commitment เพื่อนำไปแนบใน GitHub Repository หรือ Google Classroom ได้ทันที
        


        

          

            
          


          

            

              ความพร้อมก่อนเริ่ม Sprint 1
              
0%

              

                ยังไม่ได้ทำเครื่องหมายรายการส่งมอบ กดเลือกทีละข้อทางซ้ายเพื่อติดตามงานกลุ่ม
              

            


            

              

                
                
              

              
              
              
            

          

        


        

          
          จบเนื้อหาสัปดาห์ที่ 6 · 1145 204 Sophomore Project