The Pragmatic Programmer

Topic 48	แก่นแท้ของ Agility

คุณใช้คำนั้นอยู่เรื่อยเลย ผมไม่คิดว่ามันจะมีความหมายอย่างที่คุณเข้าใจหรอกนะ

Inigo Montoya, The Princess Bride

Agile คือคำคุณศัพท์ (adjective): มันคือวิธีการที่คุณทำบางสิ่ง คุณสามารถเป็น agile developer ได้ คุณสามารถอยู่ในทีมที่นำ agile practices มาใช้ ทีมที่ตอบสนองต่อการเปลี่ยนแปลงและปัญหาด้วย agility ได้ Agility คือสไตล์ของคุณ ไม่ใช่ตัวตนของคุณ

Tip 83	Agile ไม่ใช่คำนาม; Agile คือวิธีการที่คุณทำงาน

ในขณะที่เราเขียนเรื่องนี้ ก็เกือบจะ 20 ปีแล้วตั้งแต่มีการก่อกำเนิด Manifesto for Agile Software Development,[73] เราเห็นนักพัฒนาจำนวนมากประสบความสำเร็จในการนำคุณค่า (values) ของมันไปใช้ เราเห็นทีมที่ยอดเยี่ยมหลายทีมที่รู้วิธีนำคุณค่าเหล่านี้ไปใช้เป็นแนวทางในสิ่งที่พวกเขาทำ และวิธีการที่พวกเขาปรับเปลี่ยนสิ่งที่ทำ

แต่เราก็เห็นอีกด้านหนึ่งของ agility เราเห็นทีมและบริษัทที่กระหายหาวิธีแก้ปัญหาแบบสำเร็จรูปอย่าง Agile-in-a-Box และเราเห็นที่ปรึกษาและบริษัทจำนวนมากที่ยินดีจะขายสิ่งที่พวกเขาต้องการให้ เราเห็นบริษัทที่เพิ่มชั้นของการจัดการมากขึ้น การรายงานที่เป็นทางการมากขึ้น นักพัฒนาที่เชี่ยวชาญเฉพาะด้านมากขึ้น และชื่อตำแหน่งงานเก๋ๆ ที่จริงๆ แล้วหมายถึง "ใครบางคนที่มีคลิปบอร์ดและนาฬิกาจับเวลา"[74]

เราเริ่มรู้สึกว่าหลายคนลืมความหมายที่แท้จริงของ agility ไปแล้ว และเราอยากเห็นพวกเขากลับสู่พื้นฐานอีกครั้ง

จำคุณค่า (values) จาก manifesto ได้ไหม:

เรากำลังค้นหาวิธีการพัฒนาซอฟต์แวร์ที่ดีกว่าเดิม โดยการลงมือทำด้วยตนเอง และช่วยเหลือผู้อื่นในการทำสิ่งนั้น ผ่านงานชิ้นนี้ เราได้ให้ความสำคัญกับสิ่งต่อไปนี้:

Individuals and interactions (คนและการสื่อสาร) มากกว่า processes and tools (กระบวนการและเครื่องมือ)

Working software (ซอฟต์แวร์ที่ใช้งานได้) มากกว่า comprehensive documentation (เอกสารที่ละเอียดถี่ถ้วน)

Customer collaboration (การร่วมมือกับลูกค้า) มากกว่า contract negotiation (การเจรจาต่อรองสัญญา)

Responding to change (การตอบสนองต่อการเปลี่ยนแปลง) มากกว่า following a plan (การทำตามแผนที่วางไว้)

นั่นคือ แม้ว่าจะมีคุณค่าในสิ่งที่อยู่ทางขวา แต่เราให้คุณค่ากับสิ่งที่อยู่ทางซ้ายมากกว่า

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

และใครก็ตามที่ขาย solution-in-a-box ให้กับคุณ เขาไม่ได้อ่านคำแถลงตอนต้นหรอก คุณค่าเหล่านี้ขับเคลื่อนและบอกเล่าถึงการลงมือทำอย่างต่อเนื่องในการค้นหาวิธีการที่ดีกว่าเดิมในการสร้างซอฟต์แวร์ นี่ไม่ใช่เอกสารที่ตายตัว แต่มันคือคำแนะนำสำหรับกระบวนการที่สร้างสรรค์สิ่งใหม่ๆ ได้ตลอดเวลา

ไม่มีสิ่งใดที่เรียกว่า Agile Process (กระบวนการ Agile) ได้หรอก

ในความเป็นจริง เมื่อไหร่ก็ตามที่มีคนบอกว่า "ทำแบบนี้สิ แล้วคุณจะเป็น agile" พวกเขาคิดผิดแล้ว ตามนิยาม (by definition)

เพราะ agility ไม่ว่าจะในโลกทางกายภาพหรือในการพัฒนาซอฟต์แวร์ มันคือการตอบสนองต่อการเปลี่ยนแปลง การตอบสนองต่อสิ่งที่ไม่รู้ที่คุณเจอหลังจากที่คุณได้เริ่มต้นไปแล้ว กวางกาเซลล์ที่กำลังวิ่งไม่ได้วิ่งเป็นเส้นตรง นักยิมนาสติกทำการแก้ไขท่าทางหลายร้อยครั้งในวินาทีเดียวเพื่อตอบสนองต่อสภาพแวดล้อมที่เปลี่ยนแปลงไป และข้อผิดพลาดเล็กๆ น้อยๆ ในการวางเท้าของพวกเขา

มันก็เหมือนกันกับทีมและนักพัฒนาแต่ละคน ไม่มีแผนการใดเพียงหนึ่งเดียวที่คุณจะทำตามได้ในการพัฒนาซอฟต์แวร์ สามในสี่คุณค่า (values) บอกคุณไว้เช่นนั้น ทั้งหมดคือการรวบรวมและตอบสนองต่อ feedback

คุณค่า (values) เหล่านี้ไม่ได้บอกว่าคุณต้องทำอะไร แต่มันบอกว่าคุณควรสังเกตอะไรเมื่อคุณต้องตัดสินใจว่าจะทำอะไรด้วยตัวเอง

การตัดสินใจเหล่านี้ขึ้นอยู่กับบริบท (contextual) เสมอ: ขึ้นอยู่กับว่าคุณคือใคร ธรรมชาติของทีมคุณ แอปพลิเคชันของคุณ เครื่องมือที่คุณใช้ บริษัทของคุณ ลูกค้าของคุณ โลกภายนอก และปัจจัยจำนวนมหาศาล ทั้งเรื่องใหญ่และเรื่องเล็กๆ น้อยๆ ไม่มีแผนการที่ตายตัวที่สามารถเอาชนะความไม่แน่นอนนี้ได้

แล้วเราควรทำอย่างไรดี?

ไม่มีใครบอกคุณได้ว่าต้องทำอย่างไร แต่เราคิดว่าเราสามารถบอกอะไรบางอย่างเกี่ยวกับจิตวิญญาณที่คุณควรมีเมื่อทำสิ่งนั้น ทุกอย่างสรุปได้ว่าคุณจัดการกับความไม่แน่นอนอย่างไร Manifesto แนะนำให้คุณทำสิ่งนี้โดยการรวบรวมและตอบสนองต่อ feedback ดังนั้นนี่คือสูตรสำเร็จของเราสำหรับการทำงานในแบบ agile:


1. วิเคราะห์ว่าตอนนี้คุณอยู่ที่จุดไหน

2. ก้าวไปข้างหน้าในก้าวที่เล็กที่สุดที่มีความหมายไปยังจุดที่คุณต้องการจะไป

3. ประเมินว่าคุณมาจบลงที่จุดไหน และแก้ไขสิ่งที่คุณทำพังไป

ทำขั้นตอนเหล่านี้ซ้ำไปเรื่อยๆ จนกว่าคุณจะทำเสร็จ และใช้มันแบบวนซ้ำ (recursively) ในทุกระดับของทุกสิ่งที่คุณทำ

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

“ตอนนี้โค้ดของฉันจำเป็นต้องดึงข้อมูลเจ้าของบัญชี

	let user = accountOwner(accountID);

หืม... user เป็นชื่อที่ไม่มีประโยชน์เลย ฉันจะเปลี่ยนเป็น owner แล้วกัน

	let owner = accountOwner(accountID);

แต่ตอนนี้มันเริ่มรู้สึกซ้ำซ้อนไปนิด จริงๆ แล้วฉันกำลังพยายามทำอะไรกันแน่? ในสตอรี่ (story) บอกว่าฉันกำลังส่งอีเมลหาคนนี้ ดังนั้นฉันจึงต้องหาที่อยู่อีเมลของเขา บางทีฉันอาจไม่ต้องการข้อมูลเจ้าของบัญชีทั้งหมดเลยก็ได้

	let email = emailOfAccountOwner(accountID);

การนำ feedback loop มาใช้ในระดับที่ต่ำมาก (เช่น การตั้งชื่อตัวแปร) จริงๆ แล้วมันช่วยปรับปรุงการออกแบบระบบโดยรวม ลดการพึ่งพา (coupling) ระหว่างโค้ดส่วนนี้กับโค้ดส่วนที่จัดการกับบัญชี

Feedback loop ยังใช้ได้กับระดับสูงสุดของโปรเจกต์ด้วย งานที่ประสบความสำเร็จมากที่สุดของเราบางงานเกิดขึ้นเมื่อเราเริ่มทำงานตามความต้องการของลูกค้า ก้าวไปเพียงก้าวเดียว แล้วก็ตระหนักว่าสิ่งที่เรากำลังจะทำนั้นไม่จำเป็นเลย และวิธีแก้ปัญหาที่ดีที่สุดไม่เกี่ยวข้องกับซอฟต์แวร์ด้วยซ้ำ

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

และสิ่งนี้จะขับเคลื่อนการออกแบบ

ใน Topic 8, _แก่นแท้ของการออกแบบที่ดี_ เราขอยืนยันว่ามาตรวัดของการออกแบบคือผลลัพธ์ของการออกแบบนั้นเปลี่ยนได้ง่ายเพียงใด: การออกแบบที่ดีจะสร้างสิ่งที่เปลี่ยนแปลงได้ง่ายกว่าการออกแบบที่แย่

และการพูดคุยเรื่อง agility นี้เองที่อธิบายว่าทำไมถึงเป็นเช่นนั้น

คุณทำการเปลี่ยนแปลงหนึ่ง และพบว่าคุณไม่ชอบมัน ขั้นตอนที่ 3 ในรายการของเราบอกว่าเราต้องสามารถแก้ไขสิ่งที่เราทำพังได้ เพื่อให้ feedback loop ของเรามีประสิทธิภาพ การแก้ไขนี้ต้องเจ็บปวดน้อยที่สุดเท่าที่จะเป็นไปได้ ถ้าไม่เป็นเช่นนั้น เราก็อาจจะอยากเพิกเฉยต่อมันและปล่อยทิ้งไว้โดยไม่แก้ไข เราพูดถึงเอฟเฟกต์นี้ใน Topic 3, _Software Entropy_ เพื่อให้เรื่อง agile ทั้งหมดนี้ได้ผล เราจำเป็นต้องฝึกการออกแบบที่ดี เพราะการออกแบบที่ดีจะทำให้สิ่งต่างๆ เปลี่ยนแปลงได้ง่าย และถ้ามันเปลี่ยนได้ง่าย เราก็สามารถปรับเปลี่ยนได้ในทุกระดับโดยไม่ต้องลังเลเลย

นั่นแหละคือ agility

หัวข้อที่เกี่ยวข้อง

Topic 27, _อย่าขับรถเร็วเกินกว่าไฟหน้าจะส่องถึง_
Topic 40, _การรีแฟกเตอร์_
Topic 50, _มะพร้าวช่วยอะไรไม่ได้_

ความท้าทาย

Feedback loop ง่ายๆ นี้ไม่ได้มีไว้สำหรับซอฟต์แวร์เท่านั้น ลองนึกถึงการตัดสินใจอื่นๆ ที่คุณเพิ่งทำไปเมื่อเร็วๆ นี้ดู มีการตัดสินใจใดบ้างที่น่าจะดีขึ้นได้ถ้าคุณคิดว่าคุณจะสามารถย้อนกลับ (undo) ได้อย่างไรหากสิ่งต่างๆ ไม่ได้ดำเนินไปในทิศทางที่คุณต้องการ? คุณนึกถึงวิธีที่คุณสามารถปรับปรุงสิ่งที่คุณทำโดยการรวบรวมและตอบสนองต่อ feedback ได้อย่างไรบ้าง?

ฟุตโน้ต

[70]

หนึ่งสัปดาห์ฟังดูเหมือนนานไหม? จริงๆ แล้วมันไม่นานเลย โดยเฉพาะอย่างยิ่งเมื่อคุณกำลังมองดูกระบวนการที่ฝ่ายจัดการและคนทำงานอยู่กันคนละโลก ฝ่ายจัดการจะให้ภาพหนึ่งแก่คุณว่าสิ่งต่างๆ ดำเนินไปอย่างไร แต่เมื่อคุณลงไปสัมผัสหน้างานจริงๆ คุณจะพบกับความจริงที่แตกต่างออกไปอย่างสิ้นเชิง—ซึ่งเป็นความจริงที่จะต้องใช้เวลาในการทำความเข้าใจ

[71]

https://www.wired.com/1999/01/eno/

[72]

https://www.psychologytoday.com/us/blog/your-brain-work/201209/stop-trying-solve-problems

[73]

https://agilemanifesto.org

[74]

หากต้องการอ่านเพิ่มเติมว่าแนวทางดังกล่าวนั้นแย่แค่ไหน โปรดดูที่ The Tyranny of Metrics [Mul18]