สิ่งที่คุณอธิบายคืออย่างน้อยในประสบการณ์ของฉัน - รูปแบบฉุกเฉินที่เกิดขึ้นบ่อยของทีมที่พยายาม "เป็นเปรียว" มันเปิดให้มีการถกเถียงกันว่าถ้านี่เป็นส่วนหนึ่งของ Agile เองหรือการใช้งานผิดพลาดร่วมกันของมันจะขัดต่อรายการ / หลักการเปรียวหรือผลที่ตามมาของมันและอื่น ๆ จากมุมมองเชิงประจักษ์และจากประสบการณ์ตัวอย่างเล็ก ๆ ของฉัน (และคนที่ฉันพูดด้วย) ถ้าทีมมีความว่องไวดูเหมือนว่าจะมีโอกาสสูงกว่าค่าเฉลี่ยในการใช้รูปแบบนี้ ปล่อยให้มันเป็นอย่างนั้นและให้ความสำคัญกับตัวอย่างที่เป็นรูปธรรมของคุณ
มีสองด้านแยกจากสิ่งที่คุณอธิบาย:
- ขาดความเข้าใจ / วิสัยทัศน์ร่วมกันดังนั้นจึงไม่มีประสิทธิภาพ
- วิธีวัดความสำเร็จ / ความก้าวหน้าและต้นทุนทั้งหมด
ลงเส้นทางที่ผิดหรือวิ่งเป็นวงกลม
จากประสบการณ์ของฉันเหตุผลหลักที่ทำให้สิ่งนี้เกิดขึ้นก็คือในความพยายามที่จะสร้างรหัสอย่างรวดเร็วทีมงานผลักดันกรณีการใช้งานหรือข้อกำหนดที่พวกเขารู้อยู่แล้วหรือหาได้ง่าย ลองคิดแบบนี้เมื่อ 10-20 ปีก่อนผู้คนพยายามเขียนสเป็คยักษ์และคิดถึงทุกอย่างล่วงหน้าและมักล้มเหลว พวกเขาใช้เวลานานเกินไปหรือมองข้ามบางสิ่งบางอย่าง หนึ่งในการเรียนรู้ที่ผ่านมาคือในการพัฒนาซอฟต์แวร์มีสิ่งที่คุณไม่สามารถรู้ได้และสิ่งต่าง ๆ เปลี่ยนแปลงไปมากดังนั้นความคิดในการทำซ้ำอย่างรวดเร็วและสร้างผลลัพธ์ที่รวดเร็ว ซึ่งเป็นหลักการที่ดีมาก แต่วันนี้เราอยู่ที่สุดขั้ว: "ฉันไม่สนใจเรื่องนี้เพราะมันเป็นส่วนหนึ่งของการวิ่งครั้งต่อไป" หรือ "ฉันไม่ได้ยื่นข้อผิดพลาดนั้นฉันจัดการกับมันเมื่อมันเกิดขึ้นอีกครั้ง"
- รวบรวมเคสการใช้งานระดับสูงความต้องการการพึ่งพาและข้อ จำกัด ที่คุณสามารถหาได้ ใส่ไว้ในวิกิเพื่อให้ผู้มีส่วนได้ส่วนเสียและผู้พัฒนาซอฟต์แวร์สามารถเห็นพวกเขาได้ เพิ่มไปยังพวกเขาเมื่อมีสิ่งใหม่เกิดขึ้น พูดคุยกับผู้ถือหุ้นและผู้ใช้ของคุณ ใช้สิ่งนี้เป็นรายการตรวจสอบในขณะที่กำลังพัฒนาเพื่อป้องกันการใช้สิ่งที่ไม่ได้มีส่วนร่วมในผลิตภัณฑ์ขั้นสุดท้ายหรือเป็นการแก้ปัญหา / แฮ็กที่แก้ปัญหาหนึ่งข้อ แต่ทำให้เกิดปัญหาใหม่สามรายการ
- กำหนดแนวความคิดระดับสูง ฉันไม่ได้พูดเกี่ยวกับการออกแบบส่วนต่อประสานหรือชั้นเรียน แต่ให้ร่างคร่าวๆโดเมนปัญหา องค์ประกอบหลักกลไกและการมีปฏิสัมพันธ์ในการแก้ปัญหาขั้นสุดท้ายคืออะไร? ในกรณีของคุณควรทำให้ชัดเจนเมื่อใช้ jquery-workaround ช่วยเป็นขั้นตอนกลางและเมื่อมันทำให้งานเพิ่มเติมเท่านั้น
- ตรวจสอบแนวคิดของคุณโดยใช้รายการที่คุณรวบรวม มีปัญหาอะไรที่ชัดเจนหรือไม่ มันสมเหตุสมผลหรือไม่ มีวิธีที่มีประสิทธิภาพมากกว่าในการบรรลุมูลค่าผู้ใช้เดียวกันโดยไม่ก่อให้เกิดหนี้สินด้านเทคโนโลยีเป็นเวลานานหรือไม่?
อย่าหักโหมจนเกินไป คุณแค่ต้องการอะไรบางอย่างเพื่อให้ทุกคนในทีม (รวมถึงผู้ที่ไม่พัฒนา) มีความเข้าใจร่วมกันว่าเส้นทางที่ดีที่สุดใน MVP ของคุณคืออะไร ทุกคนควรยอมรับว่าไม่มีการกำกับดูแลที่ชัดเจนและสามารถใช้งานได้จริง โดยทั่วไปจะช่วยป้องกันไม่ให้ไปสู่จุดจบตายหรือต้องทำซ้ำหลาย ๆ ครั้ง Agile สามารถช่วยให้คุณรับมือกับสิ่งที่ไม่คาดคิดได้ดีขึ้นมันเป็นข้อโต้แย้งที่ไม่สนใจสิ่งที่เป็นที่รู้จัก
ระวังการล่มสลายของต้นทุน : หากคุณเริ่มด้วยสถาปัตยกรรมหรือประเภทฐานข้อมูลคนส่วนใหญ่ลังเลที่จะเปลี่ยนโครงการกลาง ดังนั้นจึงเป็นความคิดที่ดีที่จะลงทุนในการ "คาดเดาที่ดีที่สุด" ก่อนที่จะเริ่มใช้สิ่งต่าง ๆ ผู้พัฒนามีแนวโน้มที่จะต้องการเขียนโค้ดอย่างรวดเร็ว แต่บ่อยครั้งที่มี mocks สองสามตัวต้นแบบสดภาพหน้าจอ wireframe ฯลฯ ช่วยให้การวนซ้ำเร็วกว่าการเขียนโค้ด เพิ่งทราบว่าทุกบรรทัดของโค้ดที่เขียนหรือการทดสอบหน่วยทำให้ยากที่จะเปลี่ยนแนวคิดโดยรวมของคุณอีกครั้ง
การวัดความสำเร็จ
แง่มุมที่แยกจากกันโดยสิ้นเชิงคือวิธีที่คุณวัดความก้าวหน้า สมมติว่าเป้าหมายของโครงการของคุณคือการสร้างหอคอยที่สูง 1 เมตรโดยใช้สิ่งที่อยู่รอบ ๆ การสร้างบ้านของการ์ดอาจเป็นวิธีที่ถูกต้องหากว่าเวลาในการทำตลาดมีความสำคัญมากกว่าความมั่นคง หากเป้าหมายของคุณคือการสร้างสิ่งที่ยั่งยืนใช้เลโก้จะดีกว่า ประเด็นก็คือ: สิ่งที่ถือว่าสับและสิ่งที่เป็นโซลูชั่นที่สง่างามอยู่ในความอุปการะทั้งหมดเกี่ยวกับวิธีการประสบความสำเร็จของโครงการเป็นวัด
ตัวอย่างการโหลดของคุณค่อนข้างดี ฉันมีสิ่งต่าง ๆ เช่นนี้ในอดีตที่ทุกคน (รวมถึงการขาย, PO, ผู้ใช้) เห็นด้วยว่ามันน่ารำคาญ แต่ไม่มีผลกระทบต่อความสำเร็จของผลิตภัณฑ์และก่อให้เกิดหนี้สินระยะยาว ดังนั้นเราจึงทิ้งมันลงเพราะมีสิ่งที่มีค่ามากกว่าสำหรับทรัพยากร dev
คำแนะนำของฉันที่นี่คือ:
- เก็บทุกอย่างแม้กระทั่งข้อบกพร่องเล็ก ๆ เช่นตั๋วในระบบตั๋วของคุณ ตัดสินใจอย่างแข็งขันว่าอะไรอยู่ในขอบเขตของโครงการและไม่ทำอะไร สร้างเหตุการณ์สำคัญหรืออื่น ๆ กรองงานในมือของคุณเพื่อให้คุณมีรายการ "สมบูรณ์" ของทุกสิ่งที่ยังคงต้องทำ
- มีลำดับความสำคัญที่เข้มงวดและชัดเจนจุดตัดซึ่งโครงการสามารถพิจารณาความสำเร็จ ผลิตภัณฑ์ขั้นสุดท้ายมีความเสถียร / คุณภาพ / รหัสในระดับใด พยายามใช้จ่ายทุกวันในการทำงานให้ดีที่สุดเท่าที่จะทำได้โดยเลือกจากด้านบน เมื่อทำงานกับตั๋วหนึ่งใบให้ลองแก้ปัญหาให้เสร็จโดยไม่ต้องแนะนำตั๋วใหม่ (เว้นแต่ว่าจะเหมาะสมกับการโพสต์ชุดย่อยเนื่องจากมีลำดับความสำคัญต่ำกว่า) ความมุ่งมั่นทุกครั้งควรนำคุณไปสู่เป้าหมายสุดท้ายของคุณไม่ใช่ไปด้านข้างหรือข้างหลัง แต่ให้เน้นอีกครั้ง: บางครั้งการแฮ็คที่สร้างงานเพิ่มเติมในภายหลังอาจยังคงเป็นผลบวกต่อโครงการ!
- ใช้ PO / ผู้ใช้ของคุณที่จะคิดออกค่าผู้ใช้แต่ยังมีรูป devs ของคุณออกค่าใช้จ่ายในเทคโนโลยี โดยทั่วไปผู้ที่ไม่ได้เป็น dev ไม่สามารถตัดสินได้ว่าต้นทุนระยะยาวที่แท้จริง (ไม่ใช่แค่ค่าใช้จ่ายในการติดตั้ง!) คืออะไรดังนั้นช่วยพวกเขา ระวังปัญหาเดือดกบ: มีปัญหาเล็ก ๆ น้อย ๆ จำนวนหนึ่งที่ไม่เกี่ยวข้องในช่วงเวลาหนึ่งอาจทำให้ทีมหยุดชะงัก พยายามหาปริมาณประสิทธิภาพของทีมของคุณ
- จับตามองเป้าหมาย / ค่าใช้จ่ายโดยรวม แทนที่จะคิดจากการวิ่งไปวิ่งค่อนข้างให้ความคิดของ "เราสามารถเป็นทีมทำทุกอย่างที่จำเป็นจนกว่าจะสิ้นสุดของโครงการ" Sprints เป็นเพียงวิธีที่จะทำลายสิ่งต่าง ๆ และมีจุดตรวจ
- แทนที่จะต้องการแสดงบางสิ่งก่อนเวลาให้วางหลักสูตรของคุณบนเส้นทางที่เร็วที่สุดไปยังผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำที่สามารถมอบให้แก่ผู้ใช้ อย่างไรก็ตามกลยุทธ์โดยรวมของคุณควรอนุญาตให้มีผลลัพธ์ที่ตรวจสอบได้ระหว่างนั้น
ดังนั้นเมื่อมีคนทำสิ่งที่ไม่เหมาะสมกับเป้าหมายการดำเนินงานขั้นสุดท้ายของคุณอย่านึกถึงเรื่องที่ทำ หากเป็นประโยชน์ในการปิดเรื่อง (เช่นรับข้อเสนอแนะจากลูกค้า) ให้เปิดเรื่องใหม่ / ข้อบกพร่องทันทีเพื่อจัดการกับคำย่อสั้น ๆ ทำให้ชัดเจนว่าการใช้ทางลัดไม่ได้ลดค่าใช้จ่าย แต่เพียงซ่อนหรือชะลอไว้!
เคล็ดลับที่นี่คือการโต้เถียงกับค่าใช้จ่ายทั้งหมดของโครงการ: ตัวอย่างเช่น PO ผลักให้ใช้ทางลัดเพื่อกำหนดเวลาปริมาณงานที่ต้องทำหลังจากพิจารณาโครงการที่ทำ!
นอกจากนี้ระวังการปรับตามเกณฑ์ : ถ้าทีมของคุณวัดจากจำนวนเรื่องราวที่พวกเขาสามารถแสดงได้ในการทบทวนการวิ่งวิธีที่ดีที่สุดเพื่อให้ได้คะแนน "ดี" คือการตัดทุกเรื่องออกเป็นสิบเรื่องเล็ก ๆ หากวัดจากจำนวนการทดสอบหน่วยที่เขียนก็จะมีแนวโน้มที่จะเขียนสิ่งที่ไม่จำเป็นจำนวนมาก อย่านับเรื่องราว แต่ควรวัดว่าต้องใช้ฟังก์ชันการทำงานของผู้ใช้มากน้อยเพียงใดต้นทุนทางเทคโนโลยีที่จะแก้ไขภายในขอบเขตโครงการเป็นอย่างไร
สรุป
การต้มให้ช้าลง: ไปอย่างรวดเร็วและน้อยที่สุดเป็นวิธีการที่ดี T เขาเป็นปัญหาในการตีความ "เร็ว" และ "น้อยที่สุด" หนึ่งควรพิจารณาค่าใช้จ่ายในระยะยาว (เว้นแต่คุณจะมีโครงการที่ไม่เกี่ยวข้อง) การใช้ช็อตคัทที่ใช้เวลาเพียง 1 วัน แต่สร้างหนี้เทคโนโลยีเป็นเวลา 1 เดือนหลังจากวันที่จัดส่งทำให้ บริษัท ของคุณเสียค่าใช้จ่ายมากกว่าโซลูชันที่ใช้เวลา 1 สัปดาห์ เริ่มเขียนแบบทดสอบทันทีดูเหมือนจะรวดเร็ว แต่ไม่ใช่ถ้าแนวคิดของคุณมีข้อบกพร่องและพวกเขาประสานวิธีที่ผิด
และจำไว้ว่าคำว่า "ระยะยาว" หมายถึงอะไรในกรณีของคุณ: ฉันรู้ว่ามี บริษัท มากกว่าหนึ่งแห่งที่พยายามจะเขียนโค้ดที่ยอดเยี่ยมและส่งไปช้าเกินไป สถาปัตยกรรมที่ดีหรือโค้ดที่สะอาด - จากมุมมองของ บริษัท - มีค่าก็ต่อเมื่อค่าใช้จ่ายในการบรรลุเป้าหมายนั้นน้อยกว่าค่าที่ไม่มี
หวังว่าจะช่วย!