2/4

เจตนารมณ์สำคัญของปรัชญาอะไจล์ซอฟต์แวร์เดเวลลอปเม้นท์มีอยู่สี่ข้อ … เราคุ้นเคยกันดี

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

ไม่รู้เป็นเรื่องฟลุ๊กรึเปล่าแต่ผมมีความรู้สึกว่าเจตนารมณ์ทั้งสี่ข้อนั้นถูกวางลำดับไว้อย่างมีนัยยะด้วยการแบ่งแยกสิ่งที่ทีมส่วนใหญ่ (คิดว่า) ทำได้และทำไม่ได้

(คิดว่า) ทำได้

Individuals and interactions over processes and tools — ผ่านอย่างสบายตัวเลย พวกเราไม่มีใครชอบกระบวนการเยอะๆ เครื่องไม้เครื่องมือที่ยุ่งยากอยู่แล้ว ประเภท CMMi นี่ขอเหอะ

Working software over comprehensive documentation — หูยย อันนี้ก็ผ่านฉลุย มีใครชอบเขียนเอกสาร ทำงานกับตัวหนังสือเยอะๆบ้าง? น้อยยยย ดังนั้นข้อนี้ถูกใจพวกเราอย่างยิ่ง เอกสารฉันไม่ต้องทำ

ทำไม่ได้

Customer collaboration over contract negotiation — มาถึงข้อนี้จะเริ่มเห็นว่ามีประเด็น บางคนรู้สึกไม่ชอบการคุยกับคนอื่น ยิ่งเป็นลูกค้าแล้วขอเลี่ยงเลย ไม่อยากรับรู้ อยากได้อะไรก็บอกมาแล้วอีกหกเดือนเจอกัน บางคนตีความไปว่างานนี้เป็นหน้าที่ของโปรดักส์โอนเนอร์ ฉันเป็นทีมเทคนิคัล ฉันไม่ยุ่ง … LEAVE ME ALONE, PLEASE!!!

Responding to change over following a plan — อันนี้สิเจ๋ง … เค้าบอกว่าเราต้องพร้อมและยินดีที่จะทำงานตอบสนองความเปลี่ยนแปลงมากกว่าไปยึดติดกับแผนที่วางไว้ บางคนบางทีมเถียงว่า … เฮ้ๆๆ อย่ามาใส่ร้ายฉัน ทีมฉันทำได้ย่ะ

• งานไม่เสร็จก็เลื่อนเดดไลน์ออกไป — นี่ไงเราไม่ยึดติดกับแผน
• งานไม่เสร็จก็ลดสโคปลงมา — นี่ไงเราไม่ยึดติดกับแผน
• ทีมอื่นทำงานไม่ทันทีมเราก็เข้าไปช่วยได้ทันที — นี่ไงเราไม่ยึดติดกับแผน

เราทำงานให้ล้อไปกับการเปลี่ยนแปลงได้ตลอด … ถ้าเข้าใจว่าแบบนี้ถูกต้องนี่ก็อาการหนักนะผมว่า ฮ่าๆ

1. ตอนนี้ในโปรดักส์แบ็กล็อกมีงานอยู่กี่ชิ้น? — น่าจะห้าสิบขึ้น
2. เขียนทิ้งไว้นานยัง ที่ว่าห้าสิบชิ้นอะ? — เก่าหน่อยก็น่าจะหกเดือนแล้ว แต่ก็มีเปลี่ยนแปลงเรื่อยๆนะ
3. ที่ว่าเปลี่ยนแปลงเรื่อยๆอะ เอาข้อมูลมาจากไหน? — อ๋อ ก็แตกงานใหญ่ที่เขียนไว้ให้ย่อยลงตามที่ควรจะเป็นแหละ บางเรื่องก็เป็นงานที่ทีมอื่นฝากให้ทำ มันมีดีเพ็นเด็นซี่กันแหละ
4. ครั้งสุดท้ายที่ได้ฟีดแบ็คจากผู้ใช้ตัวจริงอะเมื่อไร? — อืม ไม่เคยอะ ไม่เคยให้เค้าดูสิ่งที่เราทำอยู่ ก็เห็นว่าทำงานตามแบ็กล็อกอยู่แล้ว มันน่าจะโอเค
5. ไม่ยอมให้เค้าดู … ถ้าเกิดผู้ใช้ไม่ถูกใจสิ่งที่เราทำไปตั้งแต่ตอนแรกๆหละ ไม่ต้องแก้กันใหม่หมดหรอ? — ก็คงงั้นมั้ง …

เห็นมั้ยว่าคำตอบข้างบนมันไม่ใช่การตอบสนองต่อความเปลี่ยนแปลงที่เกิดจากลูกค้าและผู้ใช้เลย … สำหรับผมทีมที่เข้าใจเจตนารมณ์ข้อสี่คือ

1. ทีมนี้มีความเชื่อว่าไม่มีอะไรมีคุณค่าและเป็นจริงไปมากกว่าความคิดเห็นโดยตรงจากผู้ใช้ตัวจริง
2. ทีมจะไม่มีงานในแบ็คล็อกระดับ 50 ชิ้น 100 ชิ้น (นั่นแปลว่าคุณหมกมุ่นเกินไปแล้ว)
3. ทีมจะพยายามเข้าถึงตัวผู้ใช้ให้บ่อยเพื่อแสดงผลงานและเก็บฟีดแบ็ค
4. ทีมนี้พร้อมที่จะลบโปรดักส์แบ็คล็อกทิ้งทั้งหมดเพื่อทำงานในทิศทางใหม่ในสมมติฐานใหม่จากข้อมูลที่ได้จากผู้ใช้
5. ทีมนี้จะอึดอัดกับคำถามที่ว่า “อีกสามเดือนทีมจะทำอะไรเสร็จบ้าง” เพราะพวกเค้าไม่ได้คิดไปไกลขนาดนั้น
6. แต่ทีมนี้จะตอบคำถามที่ว่า “ตอนนี้งานถึงไหนแล้ว?” ได้อย่างฉะฉาน “ผู้ใช้ชอบส่วนเสิร์จนะครับ แต่ทีมกำลังแก้ไขในส่วนการแสดงผลของรายงานเพราะผู้ใช้คิดว่ามันใช้ยากไป” — เค้ารู้ฟีดแบ็ค เค้าสามารถกำหนด “ปัญหา” ได้ เมื่อรู้ปัญหาที่แท้จริงโซลูชั่นที่เป็นไปได้จะตามมา

ไมค์ โคห์น (Mike Cohn) พูดไว้ดีครับว่า

“ You do not need to know what to do. You only need to know what to do next.” — Mike Cohn from this post

“คุณไม่จำเป็นต้องรู้ว่าจะทำอะไร (ทั้งหมด) คุณแค่ต้องการรู้ว่าจะทำอะไรต่อไป” … และต่อไปนั่นคือคำที่แสดงให้เห็นถึงความเข้าใจในเจตนารมณ์ข้อสี่ได้ชัดเจน

“Responding to change (what to do next) over following a plan (what to do)”

อะไจล์ทีมไม่ควรเลือกปฏิบัตินะ … เจตนารมณ์มีสี่ข้อ ควรทำให้ได้ทั้งสี่ข้อครับ :)