ทีมแย่งชิงไม่ปฏิบัติตามหลักการ YAGNI

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

จากสิ่งนี้และการสนทนาที่ฉันมีกับเจ้าของผลิตภัณฑ์ฉันสร้างต้นแบบสำหรับการตอบกลับ API (HAL + JSON) มันง่ายมาก JSON ที่สอดคล้องกับ HAL ซึ่งไม่ได้ทำอะไรมากไปกว่าการเป็นตัวแทนของสิ่งที่อยู่ในการจำลอง ฉันไม่ได้รับอิทธิพลจากความคิดในอนาคตที่นักธุรกิจเล็งเห็นเนื่องจากพวกเขามีแนวโน้มที่จะเปลี่ยนความคิดของพวกเขาบ่อยครั้งและฉันตัดสินใจที่จะใช้วิธีการที่เรียบง่าย ข้อเสนอของฉันถูกปฏิเสธโดยทีมงานและฉันได้รับคะแนนมากกว่า 7 ต่อ 1

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

เวลาส่วนใหญ่ที่เราถกเถียงกันเกี่ยวกับสิ่งที่ไม่ได้เป็นส่วนหนึ่งของการวิ่งหรือไม่ได้กล่าวถึงในการจำลอง ปัญหาที่อธิบายไว้คือ "จะเกิดอะไรขึ้นถ้าการตลาดในอนาคตจะ ... ", "จะเกิดอะไรขึ้นถ้าธุรกิจอาจต้องการให้เรา ... "

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

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

เป็นมูลค่าการกล่าวขวัญว่าผลิตภัณฑ์นี้เป็น MVP ขั้นต้น

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

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

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

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

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

ความเข้ากันได้ไปข้างหน้าเป็นเรื่องที่ถูกต้องตามกฎหมาย

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

เช่นเดียวกับข้อกำหนดอื่น ๆ คุณต้องมีเกณฑ์การยอมรับ

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

มันไม่ควรเป็นการเรียกวิจารณญาณ

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

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

ถ้าฉันเป็นเจ้าของผลิตภัณฑ์ฉันพนันว่าฉันจะมีความสุขมากขึ้นกับทีมพัฒนาที่ใช้แนวทางแรกมากกว่าหลัง

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

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

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

มันคิดว่ามีความสับสนเล็กน้อยเกี่ยวกับ YAGNI

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

หากคุณไม่ได้ "ขยาย" ระบบที่มีฟังก์ชั่น "ชัดแจ้ง" ที่ไม่ได้ร้องขอคุณไม่ได้จัดการกับ YAGNI แนะนำ abstractions ที่การขยายอาจเกิดขึ้นคือ "ความเข้ากันได้ไปข้างหน้า" ที่กล่าวถึงแล้ว

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

ปัญหาที่เกิดขึ้นกับ YAGNI และ KISS คือพวกเขาเป็นส่วนตัวและคลุมเครือ

JSON ?? YAGNI! เพียงแค่ส่งสตริง csv!

วัตถุ ?? KISSTUPID !!! เพียงแค่ใช้ gotos !!

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

• การทดสอบหน่วยสำหรับรหัส
• การทดสอบการรวมสำหรับ apis
• การทดสอบ UI อัตโนมัติสำหรับผลิตภัณฑ์สุดท้าย
• ข้อกำหนดด้านประสิทธิภาพและการปรับขนาด

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

หลังจากนั้นมันก็ผลักไปทำแบบเดียวกัน แต่เร็วกว่า

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

สิ่งใดก็ตามที่ส่งมอบเกินกว่าสิ่งนี้จะต้องอยู่ในสิ่งที่ค้างซึ่งตัวมันเองจะมีคำจำกัดความของตัวเองที่ทำ

สำหรับการจัดลำดับความสำคัญวิธีการMoSCoWให้บริการเราอย่างดีเสมอ - YMMV

ความคิดแรกของฉันเกี่ยวกับเรื่องนี้คือ ... เพราะเหตุใดทีมจึงกังวลเกี่ยวกับการเปลี่ยนแปลง พวกเขามีความเข้าใจในประวัติศาสตร์ของเจ้าของผลิตภัณฑ์ที่ทำให้พวกเขารู้สึกว่าพวกเขาต้องการสร้างโซลูชันแรกเพื่อให้สามารถกำหนดค่าได้มากขึ้นอีกเล็กน้อยเพื่อให้การปรับปรุงในอนาคตง่ายขึ้นหรือไม่ หากวิธีการแก้ปัญหาของคุณจะใช้เวลา 2 วันและของพวกเขา 5 วันใช่มันเป็นเวลานานกว่าสองเท่า แต่ถ้าการเปลี่ยนแปลงแผนของคุณจะใช้เวลา 2 วันในแต่ละครั้ง แต่การปรับปรุงแผนของพวกเขาจะใช้เวลา 1 วันแผนของพวกเขาดูเหมือนจะมีประสิทธิภาพมากกว่าการลากยาว ฉันไม่คิดว่าจะมีการตัดสินใจที่ถูกหรือผิดในคำถามนี้ ขึ้นอยู่กับปัจจัยอื่น ๆ IMHO อย่างไรก็ตามคุณมีความเข้าใจอย่างถ่องแท้เกี่ยวกับความคิดนี้หากใช้วิธีแก้ไขปัญหาอื่น ๆ พวกเขาเป็นสองเท่าของ LOE โดยไม่มีคำแนะนำโดยตรง (เช่นหลักฐานบางอย่างที่แสดงว่าจำเป็นต้องมีความซับซ้อนเพิ่มเติมสำหรับความสามารถในการขยายขีดความสามารถ ข้อเสนอแนะของฉันจะนำเจ้าของผลิตภัณฑ์มาสู่การสนทนาเหล่านี้เพราะพวกเขาต้องการความช่วยเหลือในการจัดลำดับความสำคัญ หากวิธีการแก้ปัญหาของคุณคือ 5 คะแนนและมันจะตอบสนองความต้องการในตอนนี้ แต่สิ่งที่พวกเขาต้องการจะต้องมี 50 คะแนนและสอง sprints หรือมากกว่านั้น PO อาจพูดว่า ไม่สามารถใช้เวลา 2 สัปดาห์ในการสร้างฟังก์ชันการทำงานที่ไม่ได้อยู่ในแผนงาน! "