นักพัฒนามักชอบ "แก้ไข" โค้ด นี่คือสาเหตุที่เป็นปัญหา

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

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

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

วิธีสร้างกระบวนการรีแฟกเตอร์ที่สามารถจัดการได้ในทีมของคุณ

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

1. สร้างหนี้ทางเทคนิคค้างไว้และจัดสรรทรัพยากรเป็นประจำ
2. สร้างกระบวนการดูแลและวางแผนที่เหมาะสมเพื่อค้นพบการปรับปรุงที่เป็นไปได้
3. ประกาศกระบวนการในกรณีที่มีปัญหาที่ไม่คาดคิดในระหว่างการวนซ้ำ

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

มาเจาะลึกในแต่ละหัวข้อกัน

การสร้างหนี้ทางเทคนิคค้างอยู่และกฎการจัดสรรทรัพยากร

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

ทางเลือกที่ดีกว่าการใช้ "สิ่งที่ต้องทำ" คือการกำหนดกระบวนการในการสร้างงานสำหรับการเปลี่ยนแปลงในอนาคต หากนักพัฒนาพบจุดที่อาจเกิดปัญหาหรือมีแนวคิดในการปรับปรุงฐานโค้ด พวกเขาควรสร้างรายการงานในระบบตั๋ว (Jira, Azure DevOps หรือระบบใดก็ตามที่ทีมใช้) การขอให้วิศวกรให้คำอธิบายโดยละเอียดเกี่ยวกับแนวคิดของพวกเขาแก่สมาชิกในทีมทุกคนถือเป็นเรื่องเกินจำเป็น แต่คำอธิบายควรชัดเจนเพียงพอเพื่อให้หัวหน้าทีมเข้าใจจุดสำคัญและขอบเขตของการเปลี่ยนแปลง ซึ่งครอบคลุมถึงขั้นตอนแรก นั่นคือ วิธีที่เราสามารถสร้างรายการงานที่อาจเกิดขึ้นและให้คำอธิบายในระดับสูงเกี่ยวกับการเปลี่ยนแปลงในอนาคต

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

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

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

คำแนะนำสำหรับกระบวนการแบ็คล็อกทางเทคนิคคือ:

1. ในการทำซ้ำแต่ละครั้ง ทีมงานจะต้องสำรองเวลาไว้สำหรับการปรับปรุงเทคโนโลยี

2. หากมีแนวคิดในการปรับปรุงใดๆ ควรจัดทำเป็นรายการงานอย่างเป็นทางการพร้อมคำอธิบายที่เหมาะสม

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

4. รายการงานจะต้องได้รับการวางแผนในรูปแบบการวนซ้ำแบบ Agile ตามการประมาณการของพวกเขา

   
   

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

การใช้กระบวนการดูแลและวางแผนสำหรับการเปิดเผยหนี้เทคโนโลยีที่มีศักยภาพ

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

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

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

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

การสร้างกระบวนการในกรณีที่เกิดปัญหาที่ไม่คาดคิดในระหว่างการทำซ้ำ

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

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

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

วิจารณ์ระบบราชการเพิ่มเติมและวิธีตอบ

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

การสร้างงานดังกล่าวใช้เวลานาน และบางครั้งการเปลี่ยนแปลงโค้ดอาจเร็วกว่าการอธิบายงานเหล่านั้น

และนั่นเป็นเรื่องจริง การอธิบายงานของคุณเป็นภาษาธรรมชาติบางครั้งอาจยากกว่าการแก้ไขโค้ด แต่มีวิธีแก้ปัญหาบางประการดังต่อไปนี้:

• การสร้างระบบเทมเพลตในระบบตั๋วอาจเป็นประโยชน์ เพราะช่วยให้เพิ่มงานได้อย่างรวดเร็ว และกรอกพารามิเตอร์และลิงก์ที่ถูกต้อง
• การมีนโยบายเกี่ยวกับตั๋วในวิกิขององค์กร เช่น Confluence / Notion / SharePoint หรือแพลตฟอร์มเอกสารของทีมอื่นๆ ถือเป็นเรื่องที่ดี หน้าเหล่านี้สามารถแสดงตัวอย่างที่ดีของงานที่สร้างขึ้นอย่างถูกต้องได้ เป็นประโยชน์อย่างยิ่งสำหรับหัวหน้าทีมในการดูแลรักษาเอกสารทางเทคนิคและปรับปรุงเทมเพลตเพื่อช่วยให้สมาชิกทีมคนอื่นๆ สามารถส่งตั๋วได้อย่างชัดเจนและเข้าใจง่าย
• ในระดับพื้นฐาน การบังคับให้วิศวกรสร้างงานที่มีคำอธิบายระดับสูงโดยไม่ต้องมีบทความเชิงกลยุทธ์หรือศักยภาพของข้อเสนอแนะอย่างละเอียดก็เพียงพอแล้ว คำอธิบายควรช่วยให้ผู้ตรวจสอบ (โดยปกติคือหัวหน้าทีม) เข้าใจแนวคิดหลักของการเปลี่ยนแปลงได้ ในภายหลัง หัวหน้าทีมสามารถตรวจสอบข้อเสนอแนะและกรอกรายละเอียดเพิ่มเติมตามกระบวนการ ซึ่งจะช่วยให้เข้าใจว่าการเปลี่ยนแปลงเหล่านี้จำเป็นหรือไม่ และยังช่วยกรองคุณภาพอีกด้วย
• หากนักพัฒนาซอฟต์แวร์มีเวลานำข้อเสนอแนะไปปฏิบัติ นโยบายคุณลักษณะ-สาขาอาจเป็นประโยชน์อย่างมาก อย่างไรก็ตาม จำเป็นต้องสร้างงาน เนื่องจากการมีกฎเกณฑ์สำหรับการสร้างคุณลักษณะสาขาที่ตั้งชื่อตามตั๋วนั้นมีประโยชน์ แต่ผลลัพธ์ที่ได้คือ วิศวกรที่พึงพอใจ ซึ่งได้นำหนี้ทางเทคนิค ตั๋ว และการใช้งานที่เชื่อมโยงบางส่วนไปใช้งาน ซึ่งสามารถดูแลและวางแผนสำหรับการตรวจสอบในรอบที่เหมาะสมได้ โดยไม่มีความเสี่ยงต่อความไม่เสถียรที่ไม่คาดคิด

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

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

เพียงเขียนบางอย่างเช่น:

“วิธีการ “XXX” ใช้ RAM มากเกินไปในการเรียกแต่ละครั้ง การสร้างแคชเพิ่มเติมสำหรับวิธีการนี้จะช่วยลดการใช้ RAM และเพิ่มความเร็วให้กับ API ทั้งหมด วิธีการนี้ใช้ข้อมูลที่เปลี่ยนแปลงไม่บ่อยนัก เพียงแค่ลบแคชออกเมื่อรีสตาร์ทก็เพียงพอแล้ว การเปลี่ยนแปลงนั้นปลอดภัย แต่อาจส่งผลกระทบต่อคุณสมบัติต่อไปนี้: XXX, XXX, XXX…”

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

นโยบายทั้งหมดเหล่านี้จะป้องกันไม่ให้ผู้ใช้ได้รับการปรับปรุงใหม่เท่านั้น

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

เราจำเป็นต้องมีระบบราชการมากมายขนาดนี้เพื่อให้ได้รูปแบบโค้ดที่เรียบง่ายซึ่งจะไม่ก่อให้เกิดอันตรายใดๆ ใน 99.99% ของกรณีเลยหรือ?

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

บทสรุป

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

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