บทที่ 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."