บทที่ 8: Before the Project (ก่อนเริ่มโครงการ)
2 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