#priwreadbooks The Nature of Software Development: Part I — The Circle of Value: Chapter 1–9 (สรุป)

บทนำ

หากคุณเคยมีส่วนร่วมในการพัฒนาซอฟต์แวร์ คุณมักจะรู้สึกว่า เรื่องทั้งหมดนี้ควรเป็นเรื่องง่าย แต่อย่างไรก็ดี มันมีความซับซ้อนอยู่ในนั้น

“Agile” นำเสนอให้การพัฒนาซอฟต์แวร์มีประสิทธิผลมากขึ้นและควบคุมได้ดีขึ้นด้วยการทำให้ง่ายขึ้น ด้วย 4 values และ 12 principles แต่สิ่งที่ดูง่ายเหล่านี้ดูเหมือนว่ามันจะซับซ้อนมากขึ้นไปอีก

วิธีการแบบ Agile เช่น Scrum และ XP ก็ดูเหมือนง่ายเช่นกัน values เล็กน้อย การประชุมอีกหน่อย artifacts จำนวนหนึ่ง สิ่งเหล่านี้จะซับซ้อนแค่ไหนกัน? แต่แล้วมันก็เกิดความซับซ้อนอีกอยู่ดี

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

เราต้องถอยออกจากรายละเอียด และค้นหาความเรียบง่ายที่ซ่อนอยู่ในกิจกรรมที่ซับซ้อนมากเหล่านี้

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

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

The Natural Way ช่วยให้

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

The Natural Way คือการ คิด เรียนรู้ และเปลี่ยนแปลงเล็กน้อย โดยเน้นที่การส่งมอบคุณค่าที่มองเห็นได้บ่อยครั้ง

Part I — The Circle of Value (ประกอบไปด้วย 9 บท)

การพัฒนาซอฟต์แวร์ที่ประสบความสำเร็จนั้นยาก มันจะยากเสมอ อย่างไรก็ตาม การทำอย่างราบรื่น สวยงามนั้นมีความเรียบง่ายอย่างแท้จริงซ่อนอยู่

CHAPTER 1 — The Search for Value

Value = “what you want” มันสามารถเป็นอะไรก็ได้ ตั้งแต่เงินไปจนถึงเสียงหัวเราะหรือชีวิต โดยมูลค่าที่เราผลิต ขึ้นอยู่กับสิ่งเหล่านี้

• Guiding เราสร้างมูลค่า โดยการสร้างทีมงานที่มีความรับผิดชอบในการสร้างมูลค่า ตรวจสอบให้แน่ใจว่าพวกเขาเข้าใจสิ่งที่จำเป็น และเข้าใจเวลาที่มี เราแนะนำพวกเขาได้ โดยสังเกตสิ่งที่พวกเขาสร้างขึ้นจริง
• Organizing เราจัดทีมที่มีความสามารถในการทำงานให้สำเร็จ จัดระเบียบคุณสมบัติต่างๆ ช่วยให้เราสามารถวางแผนและสร้างมูลค่าได้รวดเร็วที่สุด เราใช้คนที่ดีและช่วยพวกเขาสร้างทักษะของพวกเขา
• Planning เราควบคุมโครงการของเราโดยเลือกคุณสมบัติที่เราต้องการ ตามลำดับที่เราต้องการ เราสร้างมูลค่าได้ทันท่วงที
• Building เราสร้างผลิตภัณฑ์ตามคุณสมบัติ ให้การส่งมอบคุณค่าบ่อยครั้ง เราสามารถเห็นได้ว่าสิ่งต่างๆ ดำเนินไปอย่างรวดเร็วและบ่อยเพียงใด
• Slicing เราแบ่งคุณสมบัติต่างๆ ให้มีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ เราสร้างผลิตภัณฑ์ที่มีความสามารถโดยเร็วที่สุด จากนั้นจึงปรับปรุงและขยายผลิตภัณฑ์เมื่อใกล้ถึงกำหนดส่ง เราก็พร้อมส่งมอบเสมอ
• Quality เราใช้แนวทางปฏิบัติที่จำเป็น เพื่อให้แน่ใจว่าผลิตภัณฑ์ของเรามีการออกแบบที่ดี ปราศจากข้อบกพร่องเกือบเท่าที่เป็นไปได้ เราสามารถสร้างมูลค่าได้อย่างต่อเนื่อง ยั่งยืน อย่างไม่มีกำหนด

CHAPTER 2— Value Is What We Want

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

เราจะเลือก Value ที่เหมาะสมที่เราต้องการ เพื่อให้ทีมของเราใส่มันลงในซอฟต์แวร์อย่างรวดเร็วและมั่นคงที่สุดเท่าที่จะทำได้ เมื่อเสร็จแล้ว เราจะดูให้แน่ใจว่าได้สิ่งที่ต้องการ แล้วเราจะพูดว่า “แสดงซอฟต์แวร์ให้เราดู” เพื่อดูมูลค่าที่ถูกสร้างขึ้นมา

โครงการมอบคุณค่า ก็ต่อเมื่อ เราจัดส่งซอฟต์แวร์ และนำไปใช้งานเท่านั้น

ผลิตภัณฑ์ทุกชิ้นประกอบด้วยชิ้นส่วนจำนวนมาก (features) แต่จงจำไว้ว่าผู้ใช้ผลิตภัณฑ์ส่วนใหญ่ไม่ได้ใช้ทุกคุณสมบัติที่มี ถึงได้มีกฎ 80/20 เกิดขึ้น ทุกคนอาจต้องการบางอย่างที่แตกต่างกัน แต่ไม่มีใครต้องการทุกอย่าง

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

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

เราจำเป็นต้องแนะนำทีมของเรา เพื่อสร้างชิ้นส่วนที่สมเหตุสมผลสำหรับเราและต่อผู้ใช้ของเรา สิ่งเหล่านี้มักเรียกว่า minimal marketable features (MMFs) คุณสมบัติแต่ละอย่างที่เราทำ อาจสร้างมูลค่าเพิ่มให้กับผลิตภัณฑ์ แต่ละคนก็ต้องใช้เวลา เราไม่สามารถรู้ได้อย่างแน่ชัดว่าสิ่งที่ทำนี้มีคุณค่าหรือใช้เวลาเท่าไร แต่เรายังสามารถเข้าใจได้ดีว่าเราต้องทำอะไร

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

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

ยังมีเรื่องให้เรียนรู้ต่อจากนี้อีกมาก เช่น เรื่องการบริหารโครงการ วิธีปฏิบัติของทีมงาน ทักษะอะไรที่ทีมต้องการ ฯลฯ

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

CHAPTER 3 — Guiding Goes Better “Feature by Feature”

สิ่งแรกที่เรารู้เกี่ยวกับโครงการใดๆ คือ “กำหนดเวลา” เรารู้เส้นตายนี้กันเป็นอย่างดีแต่โดยปกติเราจะทำการส่งมอบ “น้อยกว่า” หรือ “ช้ากว่า” หรือ “ทั้งสองอย่าง” เสมอ เราไม่สามารถมีทุกอย่างที่ต้องการได้ทั้งหมดจริงๆ ดังนั้น มาจัดการความเป็นจริงกันเถอะ

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

• เคยต้องจัดส่งมอบงานในสภาพที่ไม่ดีหรือไม่?
• ยังมีข้อบกพร่องมากเกินไปในซอฟต์แวร์หรือไม่?
• ซอฟต์แวร์เปลี่ยนยากเกินไปหรือไม่?
• คุณสมบัติที่สำคัญหายไปหรือไม่?
• แนวคิดใหม่ที่สำคัญ แต่สายเกินไปที่จะทำเพิ่ม?

งานทั้งหมดนั้นสูญเปล่า…

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

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

เป็นการลดความเสี่ยงของโครงการ โดยการสร้างสิ่งที่มองเห็นได้เร็วขึ้น

เมื่อโครงการของเราเติบโตละคุณสมบัติ เราสามารถตอบสนองต่อสิ่งที่เกิดขึ้นจริงได้ เราเปลี่ยน/เพิ่มฟีเจอร์ใหม่ๆ เพื่อตอบสนองต่อแนวคิดที่ดีขึ้นหรือเปลี่ยนแปลงตามความต้องการของผู้ใช้ได้ เราสามารถตอบสนองความต้องการและข้อมูลที่เปลี่ยนแปลงไปของธุรกิจและลงมือจัดการได้อย่างทันท่วงที

CHAPTER 4 — Organizing by Feature

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

หากเราจัดทีมตามทักษะ (skill-set) งานแต่ละชิ้นจะต้องถูกส่งผ่านระหว่างทีม การส่งกันแต่ละครั้ง ต้องมีการกำหนดเวลา ต้องประสานงานกัน ต้องนั่งต่อคิว บ่อยครั้งฟีเจอร์นี้ก็ต้องกลับไปที่ทีมแรกเพื่อแก้ไขสิ่งที่พวกเขาไม่เข้าใจ วนไปมาหลายครั้ง การทำแบบนี้ทำให้เกิดความล่าช้า

แนะนำให้สร้างทีมเล็กๆ (Feature Team) ที่มีบุคลากรและทักษะทั้งหมดที่จำเป็นในการสร้างคุณสมบัติ (features) ทั้งหมด ซึ่งแต่ละทีมจะสร้างฟีเจอร์ที่ Product Champions สามารถเข้าใจได้ จากนั้นดูผลลัพธ์ว่า การส่งมอบเร็วขึ้นไหม ช่วยเรื่องปรับปรุงคุณภาพหรือไม่

เรามีผู้เชี่ยวชาญไม่เพียงพอ

• คุณไม่สามารถมีผู้เชี่ยวชาญได้ในทุกทีม คุณอาจจบลงด้วยสิ่งที่ต้องทำมากกว่าทีมที่ต้องทำ ดูเหมือนว่าคุณไม่สามารถสร้างฟีเจอร์ถัดไปที่คุณต้องการได้ แต่นั่นไม่ใช่ปัญหา
• อาจมีบางคนที่เป็นผู้เชี่ยวชาญแต่ไม่มีตำแหน่งนั้นปะหน้าอยู่ก็ได้ พวกเขาอาจจะทำได้ดีกว่าด้วยซ้ำ
• หรือสร้างทีมสุดแกร่งเพื่อสร้างคุณสมบัติที่สำคัญที่สุดก่อน ตามลำดับ จากนั้นก็ล้างทิ้งและทำซ้ำ
• มองว่าเป็นโอกาสในการฝึกอบรม โอกาสในการเรียนรู้ โอกาสในการสร้างชุมชนแห่งการปฏิบัติ (Community of Practice!)

Developer or Database or UX Community of Practice ก็เหมือนกับการเป็นสมาชิกครอบครัว หรือการเป็นสมาชิกของคลับตีกอล์ฟนั่นแหละ

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

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

Feature teams make “scaling” easy.

จะลงรายละเอียดอีกครั้งใน Part II

CHAPTER 5— Planning Feature by Feature

“วิสัยทัศน์” ของผลิตภัณฑ์เริ่มต้นด้วยแนวคิดที่ยิ่งใหญ่ คลุมเครือ แต่น่าดึงดูด เราจะย้ายจากแนวคิดผลิตภัณฑ์ที่ยิ่งใหญ่ไปสู่คุณสมบัติที่มีรายละเอียดที่เราต้องการเพื่อให้มองเห็นและควบคุมได้ดีที่สุดได้อย่างไร?

การวางแผนเป็นสิ่งที่ขาดไม่ได้

คุณ​ Eisenhower กล่าวว่า “แผนไม่มีประโยชน์ แต่การวางแผนเป็นสิ่งที่ขาดไม่ได้”

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

เรารู้สึกว่า เราต้องคิดให้ออกว่า แต่ละอันจะใช้เวลานานแค่ไหนเพื่อที่เราจะได้รวมกันและตัดสินใจว่า จะทำอะไรในหนึ่งร้อยวันนับจากวันนี้

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

วิธีที่ดีกว่า

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

เราส่งมอบคุณค่าจำนวนมากในเวลาที่น้อยกว่า ด้วยเงินที่น้อยกว่า

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

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

เราสามารถนำพาทีมไปสู่ความสำเร็จด้วยการประมาณการคร่าวๆ ได้หรือไม่?

การวางแผนอย่างต่อเนื่อง: การแยกคุณสมบัติ

เนื่องจากเราเน้นที่คุณค่า เราจึงต้องวางแผนตลอดเวลา

• ทีมควรทำงานตามจังหวะที่กำหนด ทำซ้ำระยะสั้น เป็นเวลา 2 สัปดาห์ (iterations, or sprints)
• สิ่งต่างๆ จะดีที่สุด หากแต่ละฟีเจอร์ (Story) ใช้เวลาเพียงสองหรือสามวันในการทำ
• ไม่แนะนำให้แตก Story ที่ใหญ่มากออกเป็น technical items (tasks) เพราะฝั่งธุรกิจจะมองไม่ออกว่ามันคืออะไร มักจะไม่เข้าใจว่าจะช่วยเหลืออย่างไร จนกว่าจะสิ้นสุดช่วงการทำงานสองสัปดาห์
• การแบ่ง stories ให้เป็น stories ที่เล็กลง สมเหตุสมผลกับทางฝั่งธุรกิจเป็นสิ่งที่ดีกว่าการแบ่งเป็น technical items ในตอนแรกมันอาจจะยากหน่อย แต่หากได้รับการฝึกฝน ทีมก็จะสามารถทำได้อย่างแน่นอน

ทีมงานควรทำงานมากแค่ไหน?

ทีมงานควรตัดสินใจว่า จะทำงานได้มากน้อยเพียงใดในช่วงสองสัปดาห์ถัดไป พวกเขารู้ดีกว่าใครๆ และพวกเขาจะรู้สึกผูกพันมากขึ้น หากพวกเขาตัดสินใจด้วยตัวเอง

Kent Beck and Martin Fowler: “Yesterday’s Weather.” วันนี้คุณน่าจะทำเสร็จได้มากเท่ากับเมื่อวาน

• ก่อนที่จะเริ่มงาน เราวางแผนการทำงานของแต่ละรอบ
• การตัดสินใจว่า จะต้องทำงานมากน้อยเพียงใด เราต้องเข้าใจงานนั้น เราพูดคุยกันเป็นทีม
• Product Champion จะนำเสนอคุณสมบัติทีละอย่าง ตามด้วยการอภิปรายสั้นๆ ของทีมเกี่ยวกับสิ่งที่ต้องทำ เพื่อให้คุณสมบัตินี้สำเร็จ ทุกคนมีส่วนร่วม และทีมเข้าใจคุณสมบัตินี้ก่อนจะลงมือทำ
• ไม่แนะนำให้ประมาณค่าชิ้นงานแต่ละชิ้น ให้ทำความเข้าใจ ดูผลรวมและตัดสินใจว่าทีมสามารถทำได้มากเพียงใด
• ถ้าการประมาณการช่วยทีมได้จริงๆ ก็ลุยเลย
• แต่ระวัง! ประเด็นไม่ใช่การประมาณการที่ดี แต่ประเด็นคือ การทำงานที่ดีด้วยความเร็วที่สม่ำเสมอ

การประเมินมีความเสี่ยง

เรามีความปรารถนาแทบจะต้านทานไม่ได้ที่จะปรับปรุงหรือเปรียบเทียบค่าการประเมินเหล่านี้ การมุ่งเน้นที่การประมาณการจะลดทอนความรับผิดชอบ และอาจจะเกิดการสร้างการประมาณการที่มีการระมัดระวังสูง โดยหวังว่าจะสร้างค่าประมาณที่ถูกต้อง นี่คือสัญญาณอันตราย!

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

การวางแผนด้วย “เป้าหมายที่ยืดได้” คือการทำลายล้าง

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

• ข้อบกพร่องที่เกิด ใช้เวลาในการแก้ไขนานกว่าที่ป้องกัน
• การรีบเร่งจะทำให้คุณช้าลง
• ความกดดันเป็นสิ่งที่ทำลายล้าง จงหลีกเลี่ยงมัน

ทำงานโดยไม่มีการประมาณการ

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

วางแผนบ่อยๆ เลือกสิ่งที่ต้องทำต่อไป อย่ากินทีเดียวมากเกินไป

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

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

CHAPTER 6— Building the Product, Feature by Feature

การทำงานแบบ Feature by feature ให้คุณค่าที่ดีกว่า เนื่องจากทีมสามารถแสดงซอฟต์แวร์ให้เราดูได้ จึงง่ายต่อการจัดการ วางแผน และได้ผลตอบแทนที่เร็วขึ้น

สร้างผลิตภัณฑ์ชิ้นเล็กๆ อย่างสมบูรณ์ ในแต่ละรอบเล็กๆ

ในการทำซ้ำสองสามสัปดาห์ เราจะผ่านวงจรการพัฒนาผลิตภัณฑ์ที่สมบูรณ์ ตั้งแต่แนวคิดไปจนถึงพร้อมส่ง ในแต่ละรอบเราเรียนรู้ว่า

• เราจะทำอะไรได้บ้างในสองสัปดาห์
• เรียนรู้วิธีทดสอบว่า เราได้ทำสิ่งที่เราตั้งใจจะทำหรือไม่
• เรียนรู้วิธีที่มีประสิทธิภาพที่สุดในการกำหนดคุณสมบัติโดยไม่มีค่าใช้จ่ายส่วนเกิน
• เรียนรู้วิธีสร้าง Feature by feature ในขณะที่รักษาสภาพที่ดีของโค้ด การออกแบบที่ชัดเจนและซอฟต์แวร์ยังมีความแข็งแรงดี

ปรับแต่งวิสัยทัศน์ของผลิตภัณฑ์

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

ต้องทำให้วิสัยทัศน์ของเราชัดเจนว่า ผลิตภัณฑ์ “ต้อง” ทำอะไรบ้าง และอะไรที่ “ถ้ามีก็ดี” ที่เราจะได้รับคือ ผลตอบแทนจากการลงทุนที่ส่งมอบเร็วขึ้น

พวกเขาต้องการความช่วยเหลือจากทั่วทั้งองค์กร และอาจมาจากภายนอกเพื่อทำสิ่งนี้ให้สำเร็จ …เชื่อใจพวกเขาและทีมของพวกเขา

ทำงานด้วยมูลค่าสูงสุดที่เป็นไปได้เสมอ

สิ่งสำคัญคือ ต้องทำคุณสมบัติที่มีคุณค่าที่สุดก่อน ทีมงานทำงานร่วมกันเพื่อระบุคุณสมบัติที่มีมูลค่าสูงและต้นทุนต่ำที่เราสามารถทำได้ ทีมงานเรียนรู้ที่จะสร้างผลิตภัณฑ์ที่ดีที่สุดภายในเวลาและเงินที่มีอยู่ ทุกคนต้องเห็นความคืบหน้าที่แท้จริง ไม่มีคำว่า “เสร็จ 90 เปอร์เซ็นต์” มีแค่ “เสร็จสิ้น” หรือ “ยังไม่เสร็จ” ไม่มีจุดกึ่งกลาง เราต้องดูว่าเกิดอะไรขึ้นภายในโครงการ เพื่อที่เราจะสามารถชี้นำให้ได้ข้อสรุปที่ดีที่สุด

ระบุความคืบหน้าที่แท้จริง

เมื่อทีมของคุณเริ่มสร้าง Feature และบอกคุณว่า “เสร็จแล้ว” แต่ละคนจะสร้างความเข้าใจคำว่า “เสร็จสิ้น” ในรูปแบบของเราเอง แต่เมื่อเราเห็นคุณสมบัติการทำงานจริง เราก็มีข้อมูลที่ชัดเจนเกี่ยวกับสภาพของโครงการ

ปราศจากข้อบกพร่อง

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

ซอฟต์แวร์เกือบจะต้องปราศจากข้อบกพร่องเกือบตลอดเวลา
และเพื่อให้แน่ใจว่าไม่มีข้อบกพร่อง
เราต้องตรวจสอบทุกอย่างตลอดเวลา

ขยายและปรับปรุงการออกแบบในขณะที่เรากำลังเดินหน้าไป

ขณะที่เราสร้าง Feature by feature การปราศจากข้อบกพร่องยังไม่เพียงพอ เรายังต้องพัฒนาการออกแบบต่อไป หากเราออกแบบมากเกินไป เราจะไม่ได้ทำ feature หากเราออกแบบน้อยเกินไป feature จะทำได้ยาก เราจะทำงานช้าลงทั้งสองแบบ

สังเกต เรียนรู้วิธีปรับขนาดให้เหมาะสม รักษาการออกแบบให้ดี (สะอาด)

CHAPTER 7— Build Features and Foundation in Parallel

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

ตามหลักการแล้วเราจะส่งมอบคุณสมบัติทั้งหมดให้สมบูรณ์ภายในกำหนดเวลา

แม้หลังจากจัดลำดับความสำคัญ เราก็ทำมากเกินไปอยู่ดี

• เราจำเป็นต้องทำงานให้น้อยที่สุดเท่าที่จะทำได้ เพื่อส่งมอบผลิตภัณฑ์ที่ดีที่สุดเท่าที่จะเป็นไปได้ ภายในวันที่ต้องส่งมอบ
• เราจำเป็นต้องสร้างคุณสมบัติและรากฐานในลักษณะที่จะรักษาเราให้ปลอดภัย ทำให้เราเคลื่อนไหวอย่างรวดเร็ว เสียเวลาและความพยายามให้น้อยที่สุด

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

การสร้างเวอร์ชันที่เรียบง่ายแต่ใช้งานได้จริงของคุณสมบัติแต่ละอย่างก่อนนั้นปลอดภัยกว่ามาก

ทำเวอร์ชันเล็กๆ ของคุณสมบัติที่จำเป็นแต่ละรายการ โดยมีพื้นฐานเพียงพอที่จะทำให้มั่นคง สร้างสิ่งที่เรียกว่า “minimum viable product (MVP)” โดยเร็วที่สุด จากนั้นปรับแต่งคุณสมบัติแต่ละอย่างผ่านการทำซ้ำหลายครั้ง

เราทำงานในเวอร์ชันขนาดเล็ก เวอร์ชันที่เพิ่มขึ้นของ Feature ทำให้ผลิตภัณฑ์ดีขึ้นเล็กน้อยเพื่อให้เรามีผลิตภัณฑ์ที่ดีที่สุดอยู่เสมอ

และเราจะมีผลลัพธ์ที่ดีที่สุดในวันที่ต้องการส่งมอบ

เราสามารถทำซ้ำได้เรื่อยๆ ตัดสินใจกับลำดับความสำคัญได้ตลอด จนกว่าเวลาและเงินจะบอกเราว่า ถึงเวลาต้องหยุดหรือเปลี่ยนความสนใจไปที่ผลิตภัณฑ์ใหม่

เรื่องนี้มันต้องใช้ทักษะ

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

แล้วอะไรคือทักษะที่ทีมงานของเราต้องการเพื่อทำงานในลักษณะนี้? (ไว้จะมาบอกเล่าต่อไป)

CHAPTER 8— Bug-Free and Well Designed

ผลิตภัณฑ์ของเราประกอบด้วยชุดคุณสมบัติการทำงาน (features) อย่างถูกต้องที่เพิ่มขึ้นเรื่อยๆ ซึ่งสร้างขึ้นจากพื้นฐานการออกแบบที่พัฒนาปรับปรุงขึ้นเรื่อยๆ มีการตรวจสอบเรื่อยๆ เพื่อให้ทำงานได้ดี

เรากำลังพยายามวางแผนการทำงาน ด้วยการเพิ่มขึ้นของ feature by feature ซึ่งหมายความว่า เมื่อเราได้รับแจ้งว่า feature เสร็จสิ้นแล้ว มันจำเป็นต้องใช้งานได้จริง

เราไม่สามารถทำงานได้อย่างมีประสิทธิภาพในโลกที่เต็มไปด้วยข้อบกพร่อง (defects ที่ปกติอาจจะเรียกกันว่า บั๊ก)

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

การทดสอบ ช่วยให้ซอฟต์แวร์ปราศจากบั๊กมากที่สุด

โดยแบ่งการทดสอบออกเป็นสองระดับคือ 1. Business 2. Programmer

เมื่อสิ้นสุดรอบการทำงานทุกครั้ง เราจำเป็นต้องมีการทดสอบระดับ Business เพื่อยืนยันว่า ได้รับสิ่งที่เราขอแล้ว พร้อมตรวจสอบทุกแง่มุมของทุกคุณสมบัติที่เราสามารถทำได้ เพื่อให้มั่นใจว่าอันใหม่ใช้งานได้และอันเก่าไม่พัง เพื่อลดภาระและเวลาที่ใช้ในการทดสอบ ให้เปลี่ยนการทดสอบเป็นแบบอัตโนมัติ สิ่งนี้เรียกว่า acceptance test-driven development

ในด้านของ Programmer ที่โค้ดมีการเปลี่ยนแปลงอยู่ทุกวัน การทดสอบก็ต้องได้รับการตรวจสอบบ่อยขึ้นเช่นกัน จึงจำเป็นต้องสร้าง automated tests ที่ครอบคลุม เพื่อให้แน่ใจว่าจะพบปัญหาได้เร็วขึ้นและแก้ไขปัญหาได้ง่ายขึ้น วิธีที่ดีที่สุดที่เราทราบคือเขียนการทดสอบก่อนแล้วค่อยลงมือเขียนโค้ด สิ่งนี้เรียกว่า test-driven development (TDD)

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

เมื่อระบบเติบโตขึ้น การออกแบบก็ต้องเติบโตตาม

เรากำลังจัดส่งคุณสมบัติที่ทำงานได้จริงในทุกๆ สองสัปดาห์

• เราต้องการ การออกแบบที่ดีตั้งแต่เนิ่นๆ แต่เราต้องการการออกแบบที่ดีเพียงเล็กน้อยเท่านั้น
• เราต้องทำงานอย่างเชี่ยวชาญ มีทักษะ ระมัดระวัง และแก้ไขการออกแบบในทุกขณะที่เรากำลังเดินหน้าไป
• ทุกการเปลี่ยนแปลง มีแนวโน้มที่จะทำลายการออกแบบปัจจุบันของเรา
• เมื่อโครงการเติบโตขึ้น เมื่อฟีเจอร์เติบโตขึ้น เราต้องขยายการออกแบบเพื่อรองรับฟีเจอร์เหล่านั้น เราต้องการการออกแบบคุณภาพสูงในทุกช่วงเวลา
• การรักษาการออกแบบให้ดีอยู่เสมอเมื่อมีการเปลี่ยนแปลง เรียกว่าการปรับโครงสร้างใหม่ ซึ่งเป็นทักษะที่จำเป็นสำหรับการพัฒนาซอฟต์แวร์
• การไม่รักษาการออกแบบให้ดีพอ จะทำให้การดำเนินงานช้าลงหรือหยุดชะงักได้ นักพัฒนาจำเป็นต้องรู้ให้แน่ชัดว่าจุดไหนเสียเมื่อมีบางอย่างไม่สามารถใช้งานได้
• แม้แต่การปรับโครงสร้างใหม่ที่ดีที่สุด ก็สามารถทำลายบางสิ่งได้
• automated tests ที่แข็งแกร่ง ช่วยให้เรามั่นใจว่าสิ่งต่างๆ ทำงานได้ดี
• การทดสอบสองระดับ 1. Business 2. Programmer จะทำให้งานออกมาดีที่สุด

การทดสอบและการปรับโครงสร้างใหม่ (Testing and refactoring) เป็นเครื่องมือสำคัญในการพัฒนา Feature by Feature

CHAPTER 9 — Full Circle

คุณค่า (value) คือสิ่งที่เราต้องการ
คุณสมบัติ (feature) ส่งมอบ คุณค่า (value)

การนำเสนอคุณสมบัติตั้งแต่เนิ่นๆ ทำให้เราได้รับคุณค่าเร็วขึ้น เราจึงควรจัดการโดยดูจากคุณค่า ไม่ใช่วันที่

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