การรักษาความคล่องตัวด้วยนโยบาย zero-bug / defect

ในโครงการของเราเราทำงานในวิธีการ zero-bug (aka ศูนย์บกพร่อง) แนวคิดพื้นฐานคือข้อบกพร่องมักจะมีความสำคัญสูงกว่าคุณสมบัติ หากคุณกำลังทำงานกับเรื่องราวและมีข้อบกพร่องจะต้องได้รับการแก้ไขเพื่อให้เรื่องราวได้รับการยอมรับ หากพบข้อผิดพลาดในระหว่างการวิ่งเพื่อเล่าเรื่องราวที่เก่ากว่าเราต้องใส่มันไว้ใน Backlog ของเราและแก้ไขมัน - ลำดับความสำคัญสูงสุด

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

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

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

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

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

โดยทั่วไปยิ่งคุณรอการแก้ไขบั๊กนานเท่าไรค่าใช้จ่าย (เวลาและเงิน) ก็จะแก้ไขได้

คุณมีทางเลือก:

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

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

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

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

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

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

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

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

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

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

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

บุคคลและการโต้ตอบเกี่ยวกับกระบวนการและเครื่องมือ
และเรามีกระบวนการและเครื่องมือที่จำเป็นในการควบคุมวิธีการที่บุคคลเหล่านั้น (เราต้องการคำว่า 'ทรัพยากร') โต้ตอบ

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

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

การตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน
โดยมีแผนรายละเอียดเพื่อตอบสนองต่อการเปลี่ยนแปลงและปฏิบัติตามอย่างแม่นยำ

เพื่อความสมบูรณ์แบบไม่ใช่เพียงหลักการเปรียว ๆ ที่นโยบาย zero-bug ดูเหมือนจะเบี่ยงเบนจาก

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

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

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

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

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

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

สิ่งที่คุณสามารถทำได้คือเมื่อมีการรายงานปัญหาใหม่ให้ทำการตัดสินใจสามทาง:

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

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

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

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

ข้อเสนอแนะของฉันคือการบังคับให้ลำดับความสำคัญข้อผิดพลาดเพิ่มขึ้นในแต่ละวิ่ง ให้บอกว่าคุณมีข้อผิดพลาดที่ระดับ 5 (มาตราส่วน 1-high, 5 = low) มันเริ่มจาก 5, 4 sprints ในภายหลัง, มันเป็น bug ระดับ 1 อย่างไรก็ตามชุดความคิดที่จำเป็นสำหรับการคำนวณลำดับความสำคัญคือ "ลำดับความสำคัญปัจจุบัน - จำนวน Sprints" แทนที่จะ "เพิ่มลำดับความสำคัญของข้อบกพร่องที่ยอดเยี่ยมในตอนท้ายของการวิ่งแต่ละครั้ง" - นี่เป็นการป้องกันไม่ให้ลำดับความสำคัญถูก

ข้อผิดพลาดระดับ 1 จะต้องแก้ไขในการวิ่งครั้งต่อไป ......

ง่ายต่อการอธิบายใช้งานง่าย ....

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

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

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

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

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

หวังว่าจะช่วย :)