บทที่ 9: Pragmatic Projects — โครงการแบบนักปฏิบัติ
3 min readภาพรวม
บทสุดท้ายขยับจากเรื่องของปัจเจกบุคคลและโค้ด — ไปสู่เรื่องระดับโครงการ: ทีม, กระบวนการ, เครื่องมือที่จำเป็น, และการสร้างความพึงพอใจให้ผู้ใช้
Topic 49: Pragmatic Teams — ทีมแบบนักปฏิบัติ
Tip 84: Maintain Small, Stable Teams
Tip 85: Schedule It to Make It Happen
Tip 86: Organize Fully Functional Teams
ทีมที่ดีคือทีมเล็ก (ไม่เกิน 10-12 คน) — สมาชิก stable — ทุกคนรู้จักและไว้ใจกัน
การประยุกต์หลักการ Pragmatic กับทีม:
| หลักการ | การประยุกต์กับทีม |
|---|---|
| No Broken Windows | Quality เป็นหน้าที่ของทุกคน — ไม่ใช่ "quality officer" คนเดียว |
| Boiled Frogs | ทุกคนต้องระวังการเปลี่ยนแปลงแบบค่อยเป็นค่อยไป — ดู scope creep, deadline shift |
| Knowledge Portfolio | จัด schedule สำหรับ: maintenance ระบบเก่า, process reflection, ทดลองเทคโนโลยีใหม่, ฝึกอบรม |
| DRY | สื่อสารแบบ frictionless — ถามตอบได้ทันที — หลีกเลี่ยง stovepipe systems |
| Tracer Bullets | จัดทีมให้มีทุกทักษะที่จำเป็น — frontend, backend, DBA, QA — เพื่อสร้าง end-to-end ได้ |
การสื่อสารของทีม: สร้างแบรนด์ให้ทีม — ตั้งชื่อโปรเจกต์ — มีเอกลักษณ์ — ทำให้คนภายนอกจดจำและอยากร่วมงานด้วย
Topic 50: Coconuts Don't Cut It — มะพร้าวใช้แทนไม่ได้
Tip 87: Do What Works, Not What's Fashionable — ทำสิ่งที่เวิร์ค ไม่ใช่สิ่งที่กำลังฮิต
Tip 88: Deliver When Users Need It — ส่งมอบเมื่อผู้ใช้ต้องการ
เรื่องเล่า Cargo Cult: ชาวเกาะสร้างสนามบินจำลองจากมะพร้าวและใบปาล์ม — หวังให้เครื่องบินกลับมา — พวกเขาเลียนแบบ form แต่ไม่เข้าใจ content — เช่นเดียวกับทีมที่ "ทำ Scrum" โดย standup อาทิตย์ละครั้ง และ sprint 4 สัปดาห์ที่ยืดเป็น 8 สัปดาห์
Context matters: กระบวนการของ Spotify/Netflix อาจไม่เหมาะกับคุณ — บริษัทเหล่านั้นก็ไม่ได้ใช้ process เดิมตอนที่พวกเขากำลังเติบโต
One size fits no one well: ไม่มี methodology ไหนสมบูรณ์ — เอาแนวปฏิบัติที่ดีจากหลาย ๆ ที่มาผสมกัน — ลองทำ — เก็บส่วนที่ดี — ทิ้งส่วนที่เสีย
เป้าหมายที่แท้จริง: ไม่ใช่ "ทำ Scrum" หรือ "ทำ agile" — แต่คือความสามารถในการส่งมอบซอฟต์แวร์ที่ทำงานได้เมื่อผู้ใช้ต้องการ:
- จาก delivery รายปี → รายเดือน → รายสัปดาห์ → รายวัน → on demand
Topic 51: Pragmatic Starter Kit — ชุดเริ่มต้นของนักปฏิบัติ
Tip 89: Use Version Control to Drive Builds, Tests, and Releases
Tip 90: Test Early, Test Often, Test Automatically
Tip 91: Coding Ain't Done 'Til All the Tests Run
Tip 92: Use Saboteurs to Test Your Testing
Tip 93: Test State Coverage, Not Code Coverage
Tip 94: Find Bugs Once
Tip 95: Don't Use Manual Procedures
สามเสาหลักของทุกโครงการ:
1. Version Control: ทุกอย่างที่ต้องใช้ build โปรเจกต์ต้องอยู่ใน VCS — build, test, deployment ถูก trigger โดย commits/pushes — releases กำหนดด้วย tags ใน VCS
2. Ruthless and Continuous Testing:
| ประเภท | ขอบเขต |
|---|---|
| Unit Testing | ทดสอบแต่ละ module — foundation ของ testing ทั้งหมด |
| Integration Testing | ทดสอบว่า subsystems ทำงานด้วยกันได้ |
| Validation & Verification | ทดสอบว่าตอบโจทย์ผู้ใช้จริงหรือไม่ |
| Performance Testing | ทดสอบภายใต้ load จริง — scalable ไหม? |
- Testing the Tests: จงใจใส่ bug เพื่อดูว่า tests จับได้ไหม (saboteurs)
- State Coverage > Code Coverage: 100% code coverage ไม่ได้รับประกันว่า test ทุก state แล้ว
- Find Bugs Once: เมื่อพบ bug — เพิ่ม automated test ทันที — bug นั้นต้องไม่ถูกพบโดยมนุษย์อีกเป็นครั้งที่สอง
3. Full Automation: ทุกอย่างที่ทำซ้ำต้องอัตโนมัติ — manual procedures คือ broken window — คนไม่สามารถทำซ้ำได้แม่นยำเท่าคอมพิวเตอร์
Topic 52: Delight Your Users — ทำให้ผู้ใช้ปลาบปลื้ม
Tip 96: Delight Users, Don't Just Deliver Code
เป้าหมายของเราไม่ใช่แค่ส่งมอบซอฟต์แวร์ที่ทำงานได้ — แต่คือการทำให้ผู้ใช้พอใจ มากกว่าแค่ deliver — ต้อง delight
คำถามสำคัญที่ควรถาม: "คุณจะรู้ได้อย่างไรว่าเราประสบความสำเร็จ — หนึ่งเดือน (หรือหนึ่งปี) หลังจากโปรเจกต์นี้เสร็จ?"
คำตอบมักไม่เกี่ยวกับซอฟต์แวร์โดยตรง: customer retention, data quality, cost savings — สิ่งเหล่านี้คือความคาดหวังทางธุรกิจที่แท้จริง — ซอฟต์แวร์เป็นเพียงวิธีการ
สิ่งที่ต้องทำ:
- ทำให้ทุกคนในทีมเข้าใจความคาดหวังเหล่านี้ชัดเจน
- ทุกการตัดสินใจ — ถามว่า "เส้นทางไหนพาเราเข้าใกล้ความคาดหวังนั้นมากกว่า?"
- วิเคราะห์ requirements ในแง่ของความคาดหวัง — หลายครั้ง requirement ที่ลูกค้าบอกเป็นแค่ "การเดาว่าเทคโนโลยีทำอะไรได้"
- เสนอ suggestion ที่เปลี่ยน requirement ถ้ามันพาโครงการเข้าใกล้เป้าหมายมากขึ้น
ตำแหน่งของคุณอาจเป็น "Software Developer" — แต่ความจริงคุณคือ "Problem Solver"
Topic 53: Pride and Prejudice — ความภาคภูมิใจ
Tip 97: Sign Your Work — ลงชื่อในผลงานของคุณ
ช่างฝีมือในยุคก่อนภูมิใจที่ได้เซ็นชื่องานของตน — คุณควรทำเช่นกัน การไม่เปิดเผยตัวตน (anonymity) เป็นแหล่งเพาะของความสะเพร่าและโค้ดแย่ ๆ
แต่ต้องสมดุล: code ownership ไม่ควรกลายเป็นการหวงโค้ด (territoriality) — ใช้ Golden Rule: ปฏิบัติต่อโค้ดของคนอื่นเช่นเดียวกับที่คุณอยากให้เขาปฏิบัติต่อโค้ดของคุณ
"I wrote this, and I stand behind my work."