บทที่ 8: Before the Project — ก่อนเริ่มโครงการ
3 min readภาพรวม
ก่อนที่โค้ดบรรทัดแรกจะถูกเขียน — มีสิ่งสำคัญที่ต้องจัดการ: requirements ที่แท้จริง, วิธีแก้ปัญหาที่ยาก, การทำงานร่วมกัน, และแก่นแท้ของ agility
Topic 45: The Requirements Pit — หลุมพรางของ requirements
Tip 75: No One Knows Exactly What They Want — ไม่มีใครรู้แน่ชัดว่าตัวเองต้องการอะไร
Tip 76: Programmers Help People Understand What They Want — โปรแกรมเมอร์ช่วยให้คนเข้าใจว่าพวกเขาต้องการอะไร
Tip 77: Requirements Are Learned in a Feedback Loop — requirements เรียนรู้ผ่าน feedback loop
Tip 78: Work with a User to Think Like a User — ทำงานกับผู้ใช้เพื่อคิดแบบผู้ใช้
Tip 79: Policy Is Metadata — นโยบายคือ metadata
Tip 80: Use a Project Glossary — ใช้ศัพทานุกรมของโปรเจกต์
Requirements ไม่ได้ "มีอยู่แล้ว" ให้เราไป "เก็บ" — มันถูกฝังอยู่ใต้ชั้นของ assumptions, misconceptions, และ politics — บางทีมันก็ไม่มีอยู่จริงด้วยซ้ำ
Programming as Therapy: เมื่อ client บอก requirement มา — นั่นไม่ใช่ requirement ที่สมบูรณ์ — มันคือคำเชิญให้สำรวจ หน้าที่ของคุณคือถามคำถาม หา edge cases — และสะท้อนผลกระทบกลับไปให้ client คิดต่อ
Requirements vs Policy: แยกแยะระหว่าง requirement ที่เป็นกฎตายตัว กับ policy ที่อาจเปลี่ยนแปลง — implement ระบบให้รองรับ policy แบบ metadata — เมื่อ policy เปลี่ยน ไม่ต้องเปลี่ยนโค้ด
Documentation: requirements document ที่ดีที่สุดคือ working code — แต่ก็ต้องมีเอกสารสำหรับการวางแผน — ใช้ user stories บน index cards — ทำให้สั้น กระตุ้นให้ถามคำถาม
Overspecification: การระบุรายละเอียดมากเกินไปเป็นอันตราย — requirements ที่ดีเป็น abstract — จับ semantic invariants ที่เป็นแก่น
Maintain a Project Glossary: สร้างและรักษาศัพทานุกรมของโปรเจกต์ — ทุกคนต้องใช้คำเดียวกันในความหมายเดียวกัน
Topic 46: Solving Impossible Puzzles — แก้ปริศนาที่ดูเป็นไปไม่ได้
Tip 81: Don't Think Outside the Box — Find the Box — อย่าคิดนอกกรอบ — หากรอบของกรอบให้เจอ
เมื่อเจอปัญหาที่ดูแก้ไม่ได้ — ความลับอยู่ที่การระบุ ข้อจำกัดที่แท้จริง (real constraints) — แยกแยะระหว่างข้อจำกัดที่เปลี่ยนแปลงไม่ได้ กับ preconceived notions ที่คุณคิดไปเอง
Degrees of Freedom: ระบุ degrees of freedom ที่คุณมี — ในนั้นคุณจะพบทางออก วิธีของ Alexander the Great กับปม Gordian — ฟันมันออกเป็นชิ้น ๆ — ก็เป็นการตีความ requirements อีกแบบหนึ่ง
เมื่อรู้สึกติดขัด:
- หยุดทำ — ไปทำอย่างอื่น — ให้สมองใต้สำนึกทำงาน
- อธิบายปัญหาให้ใครสักคนฟัง (rubber ducking)
- ถามตัวเอง: ทำไมต้องแก้ปัญหานี้? ประโยชน์คืออะไร? มีปัญหาที่ง่ายกว่าและเกี่ยวข้องกันไหม?
"Fortune favors the prepared mind." — Louis Pasteur
Topic 47: Working Together — การทำงานร่วมกัน
Tip 82: Don't Go into the Code Alone — อย่าเข้าไปในโค้ดคนเดียว
Conway's Law: โครงสร้างการสื่อสารขององค์กรจะสะท้อนออกมาใน design ของระบบ — ถ้าทีมไม่คุยกัน — ระบบจะเป็น silos — ถ้าทีมแยกเป็นสองส่วน — ระบบจะเป็น client/server
Pair Programming: คนหนึ่งพิมพ์ — อีกคนคิด — สลับกันได้ — ประโยชน์: ต่างคนต่างนำประสบการณ์ที่ต่างกันมา, คนพิมพ์โฟกัส syntax — อีกคนโฟกัส big picture, peer pressure ลดการทำ shortcut
Mob Programming: ขยาย pair programming ให้มีคนมากขึ้น — รวมถึง people ที่ปกติไม่ได้อยู่ในทีมพัฒนา (users, sponsors, testers) — เหมาะกับปัญหายาก
เคล็ดลับ: สร้างโค้ด — ไม่ใช่สร้าง ego, เริ่มจากเล็ก ๆ, วิจารณ์โค้ด — ไม่ใช่คน, ฟังและเข้าใจมุมมองคนอื่น
Topic 48: The Essence of Agility — แก่นแท้ของความคล่องตัว
Tip 83: Agile Is Not a Noun; Agile Is How You Do Things
Agile ไม่ใช่ process — มันคือ วิธีการ ที่คุณทำสิ่งต่าง ๆ — มันคือ adjective ไม่ใช่ noun
คุณค่าจาก Agile Manifesto:
- Individuals and interactions > processes and tools
- Working software > comprehensive documentation
- Customer collaboration > contract negotiation
- Responding to change > following a plan
ไม่มีทางที่จะมี "agile process" แบบตายตัว — เพราะ agility คือการตอบสนองต่อการเปลี่ยนแปลงและการตอบสนองต่อสิ่งที่ไม่รู้ — ไม่มีแผนตายตัวใดรอดจากความไม่แน่นอน
สูตรการทำงานแบบ agile:
- รู้ว่าตอนนี้คุณอยู่ที่ไหน
- ก้าวที่เล็กที่สุดที่มีความหมายไปสู่ที่ที่คุณอยากไป
- ประเมินว่าคุณไปถึงไหนแล้ว — และซ่อมอะไรก็ตามที่พัง
ทำซ้ำจนเสร็จ — และใช้ recursively ในทุกระดับของทุกสิ่งที่คุณทำ
สิ่งนี้ขับเคลื่อน Design: feedback loop จะมีประสิทธิภาพก็ต่อเมื่อการ "ซ่อมสิ่งที่พัง" ทำให้ง่าย — และนั่นคือเหตุผลที่การออกแบบที่ดี (ETC) เป็นหัวใจของ agility