บทที่ 9: Pragmatic Projects — โครงการแบบนักปฏิบัติ

ภาพรวม

บทสุดท้ายขยับจากเรื่องของปัจเจกบุคคลและโค้ด — ไปสู่เรื่องระดับโครงการ: ทีม, กระบวนการ, เครื่องมือที่จำเป็น, และการสร้างความพึงพอใจให้ผู้ใช้

---

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 กับทีม:

การสื่อสารของทีม: สร้างแบรนด์ให้ทีม — ตั้งชื่อโปรเจกต์ — มีเอกลักษณ์ — ทำให้คนภายนอกจดจำและอยากร่วมงานด้วย

---

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:

• 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."