#priwreadbooks The Nature of Software Development: Part II—Notes and Essays: Chapter 10–22 (สรุป)

ใน Part II นี้ เราจะพิจารณารายละเอียดที่ได้กล่าวไปใน Part I ให้ละเอียดยิ่งขึ้น

CHAPTER 10 — Value — What Is It?

ตอกย้ำกันอีกครั้งว่า คุณค่าคือสิ่งที่เราต้องการ คุณภาพก็เป็นสิ่งที่เราต้องการ

ในการพัฒนาซอฟต์แวร์แบบ Agile เราตัดสินใจ เลือกลำดับเกี่ยวกับสิ่งที่ควรทำหรือไม่ควรทำตามคุณค่า (หรือมูลค่า หรือ ROI) มันอาจทำให้เรานึกถึงสิ่งที่เราให้ความสำคัญในแง่ของ “ดีต่อธุรกิจ” หรือ “ดีต่อลูกค้า” ซึ่งสิ่งที่เราให้ความสำคัญอาจมีอีกหลายรูปแบบ เช่น

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

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

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

การเลือกคุณค่า คือการเลือกสิ่งที่สำคัญ
เพราะ คุณค่า คือสิ่งที่เราต้องการ

CHAPTER 11 — Value — How Can We Measure It?

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

แต่เราควรใช้ข้อมูลตัวเลขเพื่อตัดสินใจไม่ใช่หรือ?

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

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

เราควรวัดกันอย่างไร?

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

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

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

CHAPTER 12 — Of Course It’s Hard!

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

เราทำสิ่งที่ยากอยู่เสมอ แต่การ “แสดงซอฟต์แวร์ให้ดู” ช่วยให้เราทำสิ่งต่อไปนี้ได้สำเร็จ

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

ทุกแง่มุมของงานนี้มีความซับซ้อน แต่เราไม่จำเป็นต้องมีกระบวนการที่ซับซ้อนในการทำงาน ไม่มีวิธีที่ “ดีที่สุด” สังเกตสิ่งที่เกิดขึ้น ปรับเปลี่ยน และปรับปรุง สร้างกระบวนการทำงานของคุณเอง สร้างแนวคิดของคุณเอง และห้ามทำให้มันยากเด็ดขาด!

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

กระบวนการพัฒนาแบบวัฏจักรนี้ก็เหมือนกันกับการผ่าตัดเปลี่ยนเข่า ตอนแรกมันเจ็บทำอะไรไม่ได้มาก ผ่านไปซักพัก เราก็ทำได้เยอะขึ้นและก็ไม่เจ็บมากเท่าไหร่ และมันก็เป็นความเจ็บปวดที่ดี

ทำให้ดีเท่าที่คุณต้องการ ทำงานต่อไป ปรับปรุงวิธีการทำงานต่อไป

CHAPTER 13 — Not That Simple

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

CHAPTER 14 — Creating Teams That Thrive

คุณ Daniel Pink กล่าวว่า Purpose, Autonomy, and Mastery (วัตถุประสงค์ ความมีอิสระในการปกครองตัวเอง ความชำนาญ) เป็นตัวขับเคลื่อนความพึงพอใจของพนักงานและความสามารถในการทำงานที่ดีขึ้น (productivity)

วัตถุประสงค์มาจากธุรกิจ

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

ไม่แนะนำให้ Product Champion นำเสนอโซลูชัน เพราะทีมอาจไม่เข้าใจจุดประสงค์ของการแก้ปัญหา การมีโซลูชันมาทำให้ทีมไม่ได้แก้ปัญหาอย่างสร้างสรรค์ (ควรเป็นการบอกปัญหาหรือข้อกังวลมากกว่า)

ความมีอิสระในการปกครองตัวเอง เป็นการสร้างความรับผิดชอบของทีม

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

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

ทีมที่จัดการตนเองได้ คือทีมที่มีความเข้าใจในวัตถุประสงค์ตรงกัน

ความเชี่ยวชาญมาจากกระบวนการทำซ้ำ

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

Agile ที่ได้รับความนิยมมากที่สุดคือ “ตรวจสอบและปรับเปลี่ยน” (Inspect and Adapt)ในฐานะทีม เราสังเกตสิ่งที่เราทำสำเร็จ สิ่งที่รั้งเราไว้ และปรับปรุงให้ดีขึ้น

เมื่อทีมพัฒนาขึ้น เราทุกคนก็มุ่งสู่การเป็นผู้เชี่ยวชาญ

CHAPTER 15— The “Five-Card Method” for Initial Forecasting

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

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

CHAPTER 16— Managing Natural Software Development

เมื่อเราทำงานแบบ Natural Way “การจัดการ” ส่วนใหญ่จะทำภายในทีม

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

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

แน่นอนว่าการจัดการจากฝ่ายบริหารยังคงต้องทำ เช่น

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

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

การวางแผนในระดับไม่กี่เดือนหรือหนึ่งปีล่ะ?

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

แล้วการวางแผนระยะสั้น วันต่อวัน สัปดาห์ต่อสัปดาห์ล่ะ?

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

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

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

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

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

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

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

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

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

CHAPTER 17— Whip the Ponies Harder

ผู้จัดการระดับสูงได้รับแจ้งว่าโครงการกำลังดำเนินไปช้ากว่าที่คาดไว้ เขาโต้กลับว่า “เอาล่ะ เราต้องเฆี่ยนม้าให้หนักขึ้น” …

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

เราต้องการคุณสมบัติเพิ่ม! ทำไมเราไม่สามารถเพิ่มความเร็วได้

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

ไม่ เราต้องการคุณสมบัติมากกว่านี้จริงๆ!

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

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

หากคุณต้องพยายามไปให้เร็วขึ้น ให้วิเคราะห์สาเหตุของความล่าช้า

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

เพิ่มผลผลิตของแต่ละคนด้วยการเพิ่มความสามารถ ไม่ใช่โดยการกระตุ้นให้คนทำงานหนักขึ้น “Work smarter, not harder” (ทำงานให้ฉลาดขึ้น ไม่ใช่หนักขึ้น) หมายความว่า เราต้องช่วยให้พวกเขาฉลาดขึ้น

สิ่งที่ช่วยให้ทีมมีประสิทธิผลมากขึ้นคือทักษะที่สูงขึ้น ซึ่งหมายความว่าการลงทุนในการฝึกอบรมและการศึกษาของคุณจะคุ้มค่ากับประสิทธิภาพการทำงาน

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

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

CHAPTER 18 — To Speed Up, Build with Skill

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

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

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

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

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

เมื่อทีมจัดส่งซอฟต์แวร์ไปยัง QA เราต้องมั่นใจอยู่แล้วว่าซอฟต์แวร์จะไม่กลับมาพร้อมข้อบกพร่อง (บั๊ก) เราทำเช่นนั้นได้โดยใช้ acceptance test-driven development (ATDD) และ test-driven development (TDD) เรามั่นใจมากขึ้นว่าเมื่อเราส่งต่อสิ่งใดสิ่งหนึ่งไป ก็จะได้ผลตามที่ต้องการ ทีมของเราต้องเป็นผู้เชี่ยวชาญใน ATDD และ TDD

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

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

เราต้องการทีมงานของเราในการสร้างผลิตภัณฑ์ที่เพิ่มขึ้นในทุกๆ “Sprint” การเพิ่มขึ้นนั้นต้องเป็นไปตาม DoD และคำจำกัดความของ Done จะเข้มงวดมากขึ้นเมื่อเวลาผ่านไป สร้างความเข้าใจร่วมกันในสิ่งที่เราต้องการ

ฟังดูเหมือนช้ามาก!

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

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

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

CHAPTER 19 — Refactoring

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

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

ทางเดินเล็กๆ ที่คดเคี้ยว

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

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

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

สิ่งที่ดูเหมือนจะได้ผลดีที่สุดคือ ปฏิบัติตามกฎของที่ตั้งแคมป์ (Campground Rule) เราเริ่มต้นด้วยการทำความสะอาดพื้นที่ที่เราจะทำงาน เราไม่จำเป็นต้องทำให้มันสมบูรณ์แบบ แค่ทำให้ดีขึ้นก็เพียงพอแล้วที่จะช่วยให้ฟีเจอร์ของเราทำงานได้ง่ายขึ้น และเมื่อฟีเจอร์ของเราใช้งานได้ เราก็ทำความสะอาดโค้ดอย่างที่ควรจะเป็นเสมอ พื้นที่ที่เราทำงานจำนวนมากได้รับความสนใจมากขึ้น พวกเขาทำความสะอาดอย่างรวดเร็ว นักพัฒนามักชอบเริ่มต้นใหม่ เขียนใหม่ แต่มันแทบจะไม่เคยเป็นแผนการที่ดีที่สุดเลย แทนที่จะทำเช่นนั้น ให้ทำ Refactoring โดยใช้ Campground Rule

CHAPTER 20 — Agile Methods

หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับการพัฒนาซอฟต์แวร์แบบอไจล์ มีวิธีการหรือเฟรมเวิร์กแบบอไจล์มากมาย ที่นิยมมากที่สุดคือ Scrum โดย Jeff Sutherland และ Ken Schwaber การออกแบบ Scrum ไม่ได้มุ่งเน้นไปที่ซอฟต์แวร์เพียงอย่างเดียว ด้วยเหตุนี้ Scrum จึงไม่ได้รวมหลักปฏิบัติทางเทคนิคไว้อย่างชัดเจน

XP หรือ Extreme Programming สร้างโดย Kent Beck เป็นเฟรมเวิร์กที่รวมหลักปฏิบัติทางเทคนิคเหล่านั้นไว้อย่างชัดเจน

สำหรับผู้เขียนหนังสือเล่มนี้กล่าวว่า Scrum บวกกับแนวทางปฏิบัติทางเทคนิคที่มีค่าบางอย่างเท่ากับ XP

Crystal Clear ของ Alistair Cockburn เป็นเฟรมเวิร์กแบบ Agile ที่ง่ายกว่า Scrum นอกจากนี้ยังมีเฟรมเวิร์กคล้าย Agile ขนาดใหญ่ที่ซับซ้อน เช่น Dynamic Systems Development Method (DSDM), Larman/Vodde’s Large Scale Scrum (LeSS), Scott Ambler’s Disciplined Agile Development (DAD) หรือ Dean Leffingwell’s Scaled Agile Framework (SAFe) และอื่นๆ อีกมากมาย

The Nature of Software Development เล่าสิ่งที่ต้องทำในโครงการซอฟต์แวร์ เพื่อให้คุณประสบความสำเร็จในการทำงานในเฟรมเวิร์กใดก็ตามที่คุณเลือกใช้

คำแนะนำเกี่ยวกับการใช้เฟรมเวิร์ก

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

คิดก่อนที่จะเริ่มลงมือทำ

CHAPTER 21—Scaling Agile

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

Agile นั้นเรียบง่าย แต่มันไม่ง่ายเลย

Chet Hendrickson ชี้ให้เห็นว่าเนื่องจาก Agile นั้นเรียบง่าย Agile เวอร์ชันที่ปรับขนาด จึงควรเรียบง่ายเช่นนั้นหรือง่ายกว่านั้น มิฉะนั้นจะไม่เป็น Agile อีกต่อไป

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

หากทีมของคุณมีความ Agile อย่างแท้จริง…

• ทีม Agile ทำงานทุกวันกับเพื่อนร่วมงานในฝั่งธุรกิจ (หลักการ Agile Manifesto ข้อที่ 4)
• พวกเขาจัดส่งซอฟต์แวร์ที่ใช้งานได้เป็นประจำทุกสองสามสัปดาห์ (หลักการที่ 3)
• พวกเขาวัดตัวเองด้วยซอฟต์แวร์ที่ใช้งานได้ (หลักการที่ 7)
• ทำงานในรูปแบบที่ยั่งยืน (หลักการที่ 8)
• ให้ความสนใจอย่างต่อเนื่องกับความเป็นเลิศทางเทคนิคและการออกแบบที่ดี (หลักการที่ 9) และอื่นๆ

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

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

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

หรืออาจมีงานมากพอ ที่จะทำให้ทีมที่มีมากกว่าหนึ่งทีมไม่ว่างจริงๆ? ก็ถึงเวลา Scaling Agile แล้วใช่ไหม?

Feature teams คือทีมเล็กๆ ที่มีหน้าที่นำเสนอฟีเจอร์ต่างๆ ลงในผลิตภัณฑ์ หากต้องการฟีเจอร์เพิ่ม คุณต้องเพิ่ม Feature team ซึ่งทุกทีมจะส่งซอฟต์แวร์ในผลิตภัณฑ์เดียวกัน

ทีม Agile ประสานงานกันโดยใช้การทดสอบ

• ทำฟีเจอร์เล็กๆ จำนวนมากทุกสองสัปดาห์
• หนึ่งทีม สามารถทำคุณสมบัติดังกล่าวได้ 15–20 อย่างในการทำซ้ำสองสัปดาห์
• วิธีทำงานประสานกันของหลายทีม คือการตรวจสอบอัตโนมัติที่เพิ่มมากขึ้น ด้วยการใช้ acceptance test-driven development และ test-driven development
• ทุกครั้งที่จะเพิ่มฟีเจอร์ใหม่ ต้องไปพร้อมกับการตรวจสอบอัตโนมัติลงใน codebase
• ให้การตรวจสอบทั้งหมดทำงานตลอดเวลา หากพบปัญหาก็ทำการแก้ไขก่อนที่จะรวมร่างเข้าไป
• หากการตรวจสอบทำงานอยู่ก่อนที่คุณจะใส่การเปลี่ยนแปลง และทำงานไม่ได้หลังจากที่คุณใส่การเปลี่ยนแปลง การเปลี่ยนแปลงของคุณทำให้บางอย่างเสียหาย คุณพบสิ่งนั้นและแก้ไขเพื่อให้การตรวจสอบทั้งหมดดำเนินต่อไป ทั้งของคุณเอง รวมถึงการตรวจสอบในอดีตทั้งหมด
• เมื่อพวกเขาทำฟีเจอร์ทีละน้อยและทำทีละฟีเจอร์ โอกาสที่พวกเขาจะทำลายบางอย่างมีน้อยมาก เมื่อพวกเขาทำบางอย่างพัง การค้นหาปัญหาจึงเป็นเรื่องง่าย เนื่องจากมีการเพิ่มหรือเปลี่ยนแปลงโค้ดเพียงเล็กน้อยเท่านั้น

แล้วโครงสร้างพื้นฐานล่ะ

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

ฉันแนะนำให้ Feature Team ของคุณจัดการกับการเปลี่ยนแปลงโครงสร้างพื้นฐาน โดยประสานงานกันเองตามความจำเป็น คุณไม่จำเป็นต้องมีโครงสร้างพื้นฐานพิเศษใดๆ คุณเพียงแค่ต้องการทีมที่ได้รับการเสริมศักยภาพหลายทีมที่มีความสามารถ และจะประสานงานกันเองได้ตามต้องการ

บริษัทที่สามารถทำงานได้โดยทีมเดียว ไม่จำเป็นต้องมีอะไรพิเศษเพื่อ Scaling Agile

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

ขั้นแรก ให้ขยายขนาดทีละน้อย

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

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

หากแต่ละทีมของคุณไม่สามารถทำงานแบบ Agile ได้ แสดงว่าคุณยังไม่พร้อมที่จะ “เปลี่ยนแปลง” บริษัทของคุณ

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

CHAPTER 22 — Conclusion

ลองจินตนาการว่าคุณกำลังปีนเขาที่เรียกว่าการพัฒนาซอฟต์แวร์

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

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

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

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

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

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

Thanks for reading!