docs(sdlc): Thai audit storytelling script
This commit is contained in:
Thanakorn
@@ -0,0 +1,178 @@
|
||||
# BRN WMS (200-WMS-26-001-00) — บทเล่าเรื่องสำหรับวันตรวจประเมิน ISO/IEC 29110
|
||||
|
||||
เอกสารช่วยจำสำหรับทีม ใช้เล่าเรื่องโครงการต่อผู้ตรวจประเมินตั้งแต่เปิดจนปิดโครงการ ทุกประโยคต้องชี้ไปที่เอกสารจริงได้ทันที
|
||||
ถ้าผู้ตรวจถามสิ่งที่ไม่มีในเอกสาร ให้ตอบตามจริงว่า "ไม่ได้บันทึกไว้" ห้ามแต่งเพิ่ม
|
||||
|
||||
## วิธีใช้
|
||||
|
||||
- เล่าตามลำดับบทที่ 1–8 ใช้เวลารวมประมาณ 25–30 นาที แล้วเปิดให้ผู้ตรวจเลือกเส้นสอบกลับเอง
|
||||
- แต่ละบทมี **ผู้เล่า** **เอกสารที่เปิด** และ **ประโยคหลัก** ให้เปิดเอกสารบนจอก่อนพูดทุกครั้ง
|
||||
- ผู้เล่า: ApS = Project Manager, NoC = System Analyst, ThS = Developer, PaNg = QA/Tester, YaB = Document Control, SeV = Project Sponsor
|
||||
|
||||
## โครงเรื่องในหนึ่งย่อหน้า
|
||||
|
||||
โครงการพัฒนาระบบบริหารจัดการคลังสินค้า 11 ระบบงาน ระยะเวลา 232 วัน (5 ม.ค. – 24 ส.ค. 69) ทีม 6 คน
|
||||
เราตั้ง Baseline ความต้องการ 80 รายการก่อนเริ่มพัฒนา ควบคุมงานด้วยรายงานความก้าวหน้า 15 งวดและการประชุม 11 ครั้ง
|
||||
ตรวจสอบเอกสาร 4 รอบ ทดสอบ 45 Test Case แล้ว **พบข้อบกพร่องระดับสูง 4 รายการ** ซึ่งเราบันทึกตามจริง แจ้งผู้รับมอบ
|
||||
และผู้รับมอบตรวจรับแบบมีเงื่อนไขให้แก้ไขภายใต้การบำรุงรักษา — เรื่องนี้คือจุดแข็งของกระบวนการ ไม่ใช่จุดอ่อน
|
||||
|
||||
## เส้นเวลา (ใช้เปิดเรื่อง)
|
||||
|
||||
| ช่วงเวลา | เหตุการณ์สำคัญ | หลักฐาน |
|
||||
|---|---|---|
|
||||
| 5 ม.ค. 69 | ประชุมเปิดโครงการ | Statement of Work, Minutes of Meeting 5 ม.ค. |
|
||||
| 16–23 ม.ค. 69 | ระบุผู้มีส่วนได้ส่วนเสีย อนุมัติกฎบัตร | Stakeholder Register, Project Charter, MoM 23 ม.ค. |
|
||||
| 6–18 ก.พ. 69 | ความต้องการ 80 รายการ แผนโครงการ ตั้ง Baseline | Customer Requirements, Software Project Plan, Work Schedule, MoM 18 ก.พ. |
|
||||
| 19 ก.พ. – 29 พ.ค. 69 | ออกแบบและพัฒนา ตั้ง Baseline การพัฒนา 29 พ.ค. (`a0677d6`) | SRS, Software Design, Correction Register ISS-001–027 |
|
||||
| 17 มี.ค. / 29 พ.ค. / 31 ก.ค. / 17 ส.ค. 69 | ตรวจสอบเอกสาร 4 รอบ (3+3+3+6 ชม.) | Verification Results V0.1–V1.0 |
|
||||
| 31 ก.ค. 69 | Test Case 45 รายการ และ Traceability Record | Test Case and Test Procedures, Traceability Record |
|
||||
| 3–10 ส.ค. 69 | แก้ไขหลัง Baseline (ISS-028) และอนุมัติแผนทดสอบ | Correction Register, MoM 10 ส.ค. |
|
||||
| 10–14 ส.ค. 69 | ทดสอบระบบและ UAT บน Build `b2c4374` | Test Report, Validation Results |
|
||||
| 17 ส.ค. 69 | ชุดติดตั้ง Docker และ Baseline ส่งมอบ `6c39700`; ตรวจสอบรอบที่ 4 | Software Configuration, Verification Results V1.0 |
|
||||
| 19 ส.ค. 69 | ประชุมสรุปผลทดสอบและ UAT | MoM 19 ส.ค. |
|
||||
| 22–23 ส.ค. 69 | อบรมผู้ใช้ 6 คน ปิดงานควบคุมปฏิบัติการ OP-001/OP-002 | Training Report, Product Operation Guide |
|
||||
| 24 ส.ค. 69 | ตรวจรับแบบมีเงื่อนไขและปิดโครงการ | Acceptance Report, MoM 24 ส.ค., List of Evidence |
|
||||
|
||||
---
|
||||
|
||||
## บทที่ 1 — ทำไมต้องมีโครงการนี้ และใครเกี่ยวข้อง
|
||||
|
||||
**ผู้เล่า:** ApS (เปิด) และ SeV (ยืนยันมุมลูกค้า)
|
||||
**เปิด:** Statement of Work → Project Charter Report → Stakeholder Register → Software Project Plan §5
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "บริษัทบันทึกคลังสินค้าแยกจากงานขายและบัญชี ยอดไม่ตรงกัน เราจึงตั้งโครงการรวม 11 ระบบงานไว้ในระบบเดียว ระยะเวลา 232 วัน"
|
||||
- "ผู้มีส่วนได้ส่วนเสียมี 10 กลุ่ม คือทีม 6 คน และผู้ใช้ 4 กลุ่ม — ฝ่ายคลัง ฝ่ายขาย/จัดซื้อ ฝ่ายบัญชี และผู้ดูแลระบบ
|
||||
รายชื่อชุดเดียวกันอยู่ทั้งใน Stakeholder Register และ Software Project Plan §5.1–5.2"
|
||||
|
||||
**ถ้าถูกถาม:** "ใครอนุมัติขอบเขต?" → SeV อนุมัติกฎบัตรในการประชุม 23 ม.ค. 69
|
||||
|
||||
## บทที่ 2 — วางแผนและตั้ง Baseline ก่อนลงมือ
|
||||
|
||||
**ผู้เล่า:** NoC (ความต้องการ) และ ApS (แผน)
|
||||
**เปิด:** Customer Requirements → Software Project Plan §6–§9 → Work Schedule → MoM 18 ก.พ.
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "เราเก็บความต้องการ 80 รายการใน 14 หมวด (CR01–CR14) ลูกค้าสรุปผลยอมรับทุกรายการ แล้วตั้ง Baseline ในการประชุม 18 ก.พ. 69 ก่อนเริ่มพัฒนา 19 ก.พ."
|
||||
- "แผนกำหนดความเสี่ยง 8 ข้อ (R1–R8) และแผนตรวจสอบ 4 รอบ รวม 15 ชั่วโมง ตามข้อแนะนำให้ตรวจราวทุก 2 เดือน"
|
||||
|
||||
**ถ้าถูกถาม:** "ความเสี่ยงไหนเกิดจริง?" → R1 (ความต้องการเปลี่ยนระหว่างพัฒนา) เกิดจริงในเรื่อง Rack → Bin (บทที่ 4)
|
||||
และ R4/R5 (ข้อมูลรั่วข้ามบริษัท, ความลับรั่ว) ปรากฏเป็นข้อบกพร่อง ISS-031/ISS-032 ในรอบทดสอบ (บทที่ 6)
|
||||
|
||||
## บทที่ 3 — พัฒนาและควบคุมงาน
|
||||
|
||||
**ผู้เล่า:** ApS (ติดตามงาน) และ ThS (การพัฒนา)
|
||||
**เปิด:** Progress Status Record (เลือก 1 งวด) → Minutes of Meeting ที่แนบ → Correction Register → Software Configuration
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "เราออกรายงานความก้าวหน้า 15 งวด ทุกฉบับถูกนำเสนอในการประชุมที่มีรายงานการประชุมรองรับ ดูได้จากช่อง 'สิ่งแนบ' ของรายงานการประชุม"
|
||||
- "การประชุมแต่ละครั้งจัดในวันทำการ หลังงานที่ทบทวนเสร็จอย่างน้อย 5 วัน เพื่อให้มีเวลาตรวจผลงานก่อนรายงานว่าเสร็จ"
|
||||
- "ข้อบกพร่องที่พบระหว่างพัฒนา 28 รายการ (ISS-001–028) ทุกรายการเชื่อมกับ Commit ที่แก้และ Test Case ที่ใช้ตรวจ"
|
||||
- "Source Code อยู่บน Branch `main` เท่านั้น สำรองไปยัง Backup Remote ตั้ง Baseline การพัฒนา 29 พ.ค. และ Baseline ส่งมอบ `6c39700`"
|
||||
|
||||
**ตัวอย่างที่ควรเปิดให้ดู:** PSR 17 มี.ค. 69 → นำเสนอในการประชุม 23 มี.ค. 69 ซึ่งทบทวนงาน Security & Database (Commit สุดท้าย 17 มี.ค.)
|
||||
|
||||
## บทที่ 4 — การควบคุมการเปลี่ยนแปลง
|
||||
|
||||
**ผู้เล่า:** ApS
|
||||
**เปิด:** Change Report ส่วนที่ 1–3 → MoM 18 พ.ค. → Correction Register ISS-023
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "เราใช้เกณฑ์ว่า 'ถ้าไม่ทำ ยังส่งมอบได้หรือไม่' ถ้ายังส่งมอบได้ ไม่ถือเป็นคำขอเปลี่ยนแปลง แต่บันทึกการพิจารณาไว้ทุกเรื่อง"
|
||||
- "มี 3 เรื่องที่ผ่านการพิจารณา ไม่มีเรื่องใดเข้าเกณฑ์ จึงไม่มีคำขอเปลี่ยนแปลงตลอดโครงการ"
|
||||
- "ตัวอย่าง: ที่ประชุม 18 พ.ค. มีมติเปลี่ยนคำว่า Rack เป็น Bin ทั้งระบบ เป็นการเปลี่ยนคำเรียก ไม่เพิ่มฟังก์ชัน ไม่กระทบ Man-day
|
||||
ทีมแก้ใน Commit `8f57ab5` (27 พ.ค.) และพบว่าเปลี่ยนไม่ครบ จึงบันทึก ISS-023 และแก้ใน `5df6736` (28 พ.ค.)"
|
||||
|
||||
**ถ้าถูกถาม:** "8 เดือนไม่มี CR เลยหรือ?" → เปิดเกณฑ์ใน Change Report ส่วนที่ 1 แล้วไล่ทั้ง 3 เรื่องด้วยคำถามเดียวกัน
|
||||
|
||||
## บทที่ 5 — ตรวจสอบเอกสาร (Verification)
|
||||
|
||||
**ผู้เล่า:** PaNg และ YaB
|
||||
**เปิด:** Software Project Plan §8.1 → Verification Results V0.1, V0.2, V0.3, V1.0
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "ตรวจสอบตามแผน 4 รอบ: 17 มี.ค. (แผนและความต้องการ), 29 พ.ค. (SRS และการออกแบบ), 31 ก.ค. (ชุดทดสอบและการสอบกลับ), 17 ส.ค. (ทุกสิ่งส่งมอบ)"
|
||||
- "รอบสุดท้ายเราบันทึก **ไม่ผ่าน 2 รายการ** คือผลการทดสอบที่ยังมีข้อบกพร่องคงค้าง และชุดติดตั้ง Docker ที่ยังไม่ได้ทดสอบ แล้วเสนอให้ตรวจรับพร้อมแผนแก้ไข"
|
||||
|
||||
## บทที่ 6 — ทดสอบระบบและทดสอบการยอมรับ
|
||||
|
||||
**ผู้เล่า:** PaNg (ทดสอบระบบ) และ SeV (UAT)
|
||||
**เปิด:** Test Case and Test Procedures → Traceability Record → Test Report → Validation Results → Correction Register ISS-029–032
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "Test Case 45 รายการ หนึ่งรายการต่อหนึ่ง Software Unit จัดทำพร้อม Traceability Record เมื่อ 31 ก.ค. 69"
|
||||
- "ทดสอบ 10–14 ส.ค. 69 บน Build `b2c4374` — ทดสอบได้ 43 รายการ ผ่าน 38 ไม่ผ่าน 5
|
||||
อีก 2 รายการ (ชุดติดตั้ง Docker) ยังไม่ได้ทดสอบ เพราะส่งมอบหลังรอบทดสอบเมื่อ 17 ส.ค."
|
||||
- "ข้อบกพร่องที่พบบันทึกเป็น ISS-029–032 ระดับสูงทั้งหมด:
|
||||
ไฟล์แนบเปิดได้จาก URL (ISS-029), การผ่าน GL ไม่อยู่ใน Transaction เดียวกับเอกสาร (ISS-030),
|
||||
Socket.IO ไม่ตรวจ Session (ISS-031), ค่าความลับในแม่แบบค่าตั้งค่า (ISS-032)"
|
||||
- "UAT ทำคู่ขนานกับการทดสอบระบบตามมติที่ประชุม 10 ส.ค. ซึ่งต่างจากเกณฑ์เข้าสู่ UAT ในเอกสาร Test Case — เราบันทึกความต่างนี้ไว้ใน Validation Results
|
||||
ผลคือความต้องการ 80 รายการ ผ่าน 60 ไม่ผ่าน 11 ยังไม่ได้ทดสอบ 5 และรอดำเนินการตามแผน 4"
|
||||
|
||||
**ถ้าถูกถาม:** "ทำไมไม่แก้ก่อนส่งมอบ?" → ข้อบกพร่องพบในสัปดาห์สุดท้ายของโครงการ เราเลือกบันทึกและแจ้งผู้รับมอบตามจริง
|
||||
แทนการแก้เร่งรีบโดยไม่มีรอบทดสอบซ้ำ ผู้รับมอบจึงกำหนดเป็นเงื่อนไขการตรวจรับ (บทที่ 7)
|
||||
|
||||
## บทที่ 7 — ส่งมอบ ตรวจรับ และปิดโครงการ
|
||||
|
||||
**ผู้เล่า:** SeV (การตัดสินใจตรวจรับ) และ ApS
|
||||
**เปิด:** MoM 19 ส.ค. → Training Report → Product Operation Guide (OP-001/OP-002) → Acceptance Report → MoM 24 ส.ค. → List of Evidence
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "ประชุม 19 ส.ค. สรุปผลทดสอบ ผู้รับมอบรับทราบข้อบกพร่องและขอแผนแก้ไขก่อนตรวจรับ"
|
||||
- "อบรมผู้ใช้ 6 คนเมื่อ 22 ส.ค. ปิดงานสำรองข้อมูลอัตโนมัติและการเฝ้าระวังเมื่อ 23 ส.ค."
|
||||
- "24 ส.ค. ผู้รับมอบตรวจรับ **แบบมีเงื่อนไข**: (1) แก้ ISS-029–032 และทดสอบซ้ำภายใต้การบำรุงรักษาแบบแก้ไข
|
||||
(2) ทดสอบ TC-UN13.002–003 ก่อนใช้ชุดติดตั้ง Docker ในสภาพแวดล้อมจริง — กำหนดติดตามใน Action Item ของการประชุม 24 ส.ค."
|
||||
|
||||
**ต้องเตรียม:** สถานะปัจจุบันของการแก้ไข ISS-029–032 (ผู้ตรวจจะถามแน่นอน) — ตอบตามความคืบหน้าจริง ณ วันตรวจ
|
||||
|
||||
## บทที่ 8 — สิ่งที่เราเรียนรู้
|
||||
|
||||
**ผู้เล่า:** ApS
|
||||
**เปิด:** Correction Register ส่วน Lessons Learned
|
||||
|
||||
**ประโยคหลัก**
|
||||
- "ข้อบกพร่องทั้ง 32 รายการจัดเป็น 5 กลุ่มสาเหตุ กลุ่มใหญ่ที่สุดคือความปลอดภัยและการควบคุมสิทธิ์ (15 รายการ รวม ISS-029, 031, 032)"
|
||||
- "โครงการถัดไปเราจะกำหนด Secure Coding Checklist และรูปแบบการตรวจสิทธิ์กลางตั้งแต่ช่วงออกแบบ
|
||||
และตามข้อแนะนำของที่ปรึกษา จะให้ PM กับ SI เดินผ่านโปรแกรมทั้งระบบพร้อม Document Control ก่อนรอบทดสอบ"
|
||||
|
||||
---
|
||||
|
||||
## เส้นสอบกลับสำหรับสาธิต (ซ้อมให้คล่อง)
|
||||
|
||||
**เส้นที่ผ่าน — สต๊อกต้องไม่ติดลบ**
|
||||
|
||||
| ขั้น | รายการ | เอกสาร |
|
||||
|---|---|---|
|
||||
| ความต้องการ | CR01:008 บันทึกการจ่ายสินค้าออกโดยตรวจสิทธิ์และยอดคงเหลือ | Customer Requirements |
|
||||
| ความต้องการซอฟต์แวร์ | SR03:004, SR09:003 | SRS |
|
||||
| การออกแบบ | UN04.002 ICS – Stock-out (`StockManager.php`, `OrderManager.php`) | Software Design |
|
||||
| ข้อบกพร่องระหว่างพัฒนา | ISS-002 พบ 18 เม.ย. แก้ใน `92d116f` 24 เม.ย. | Correction Register |
|
||||
| การทดสอบ | TC-UN04.002 → Passed | Test Case, Test Report |
|
||||
| การยอมรับ | CR01:008 → Passed | Validation Results |
|
||||
|
||||
**เส้นที่ไม่ผ่าน — ความถูกต้องของ Transaction**
|
||||
|
||||
| ขั้น | รายการ | เอกสาร |
|
||||
|---|---|---|
|
||||
| ความต้องการ | CR13:001 เอกสาร + สต๊อก + GL ต้องเป็น Transaction เดียวกัน | Customer Requirements |
|
||||
| ความต้องการซอฟต์แวร์ | SR09:003 | SRS |
|
||||
| การออกแบบ | UN08.002 Journal & GL Posting | Software Design |
|
||||
| การทดสอบ | TC-UN08.002 → Failed (เอกสารไม่ถูก Rollback เมื่อการผ่าน GL ล้มเหลว) | Test Report |
|
||||
| ข้อบกพร่อง | ISS-030 คงค้าง | Correction Register |
|
||||
| การยอมรับ | CR13:001 → Failed → เงื่อนไขการตรวจรับข้อ (1) | Validation Results, Acceptance Report |
|
||||
|
||||
## เรื่องที่ต้องพูดตรง ๆ
|
||||
|
||||
| ประเด็น | คำตอบสั้น |
|
||||
|---|---|
|
||||
| ไม่มีคำขอเปลี่ยนแปลงตลอดโครงการ | มีการพิจารณา 3 เรื่องตามเกณฑ์ ไม่มีเรื่องใดเข้าเกณฑ์ หลักฐานอยู่ใน Change Report และรายงานการประชุม |
|
||||
| ข้อบกพร่องคงค้างตอนตรวจรับ | บันทึกตามจริง แจ้งผู้รับมอบ และตรวจรับแบบมีเงื่อนไข — ห้ามบอกว่าแก้เสร็จก่อน 24 ส.ค. |
|
||||
| UAT ไม่เป็นไปตามเกณฑ์เข้า | ผู้สนับสนุนโครงการอนุมัติให้ทำคู่ขนานในการประชุม 10 ส.ค. และบันทึกความต่างไว้ใน Validation Results |
|
||||
| ชุดติดตั้ง Docker ยังไม่ได้ทดสอบ | ส่งมอบหลังรอบทดสอบ เป็นเงื่อนไขการตรวจรับข้อ (2) |
|
||||
| Baseline ส่งมอบ `6c39700` ไม่ใช่ Build ที่ทดสอบ | Build ที่ทดสอบคือ `b2c4374` ส่วนที่เพิ่มหลังจากนั้นคือข้อมูลสาธิตและชุดติดตั้ง Docker ซึ่งระบุไว้ในเงื่อนไข |
|
||||
|
||||
## สิ่งที่ห้ามทำในวันตรวจ
|
||||
|
||||
- ห้ามแก้ไขหรือเติมเอกสารย้อนหลัง ถ้ามีบันทึกใหม่ให้ลงวันที่จริง
|
||||
- ห้ามตอบเกินกว่าที่เอกสารบันทึกไว้ ถ้าไม่แน่ใจให้บอกว่า "ขอตรวจสอบเอกสารก่อน" แล้วเปิดดู
|
||||
- ห้ามอ้าง Commit, Branch หรือเอกสารที่เกิดหลังวันที่ของเอกสารที่กำลังพูดถึง
|
||||
Reference in New Issue
Block a user