ประเด็นเรื่องการแก้ไขข้อผิดพลาด: เหมาะสำหรับการต่อสู้หรือไม่?

ฉันแค่สงสัยว่าเราควรกำหนดเรื่องให้กับงานซ่อมบั๊กหรือไม่ JIRA ซึ่งเป็นซอฟต์แวร์ติดตามปัญหาของเราไม่มีฟิลด์จุดเรื่องราวสำหรับปัญหาประเภทBug (เฉพาะสำหรับStory s และEpicเท่านั้น)

เราควรเพิ่มประเภทของปัญหาBugไปยังประเภทของปัญหาที่เกี่ยวข้องในฟิลด์Story Pointsหรือไม่ ข้อดีและข้อเสียคืออะไร? มันจะเหมาะสำหรับการต่อสู้แย่งชิงกันหรือไม่

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

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

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

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

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

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

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

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

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

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

บางทีลิงค์ที่มีประโยชน์:

http://www.infoq.com/news/2011/01/story-points-to-bugs

ฉันจะแนะนำให้รักษาข้อผิดพลาดเป็นเรื่องราวของผู้ใช้และกำหนดจำนวนจุด ฉันไม่จำเป็นต้องเขียนมันในรูปแบบของ "As X, ฉันต้องการ Y เพื่อให้ Z" เป็นเรื่องธรรมดากับเรื่องราวของผู้ใช้ - ฉันจะเขียนมันมากขึ้นว่า "As a, X เมื่อ IY, Z เกิดขึ้น แต่ Z 'เป็นพฤติกรรมที่คาดหวัง "

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

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

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

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

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

ในทีมของเราเราได้ทดลองกับเทคนิคบางอย่างสำหรับการประเมินข้อบกพร่อง:

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

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

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

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

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

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

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

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

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

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

งานบางอย่างสามารถประเมินได้บางงานไม่ได้ สำหรับสิ่งที่ไม่สามารถคาดการณ์ได้ให้ใช้งบประมาณ

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

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

การสร้างงบประมาณสามารถทำได้หลายวิธีด้วยกันสำหรับงานซ่อมบั๊ก นี่คือแนวคิดที่ฉันใช้อย่างมีประสิทธิภาพ:

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

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

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

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

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

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

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

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

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

ฉันใช้ Pivotal Tracker (ฉันเป็นเพียง JIRA, Trak, Trello และอื่น ๆ ด้วย) และ Pivotal Tracker ยังไม่ได้ทำคะแนนสำหรับงานบ้านหรือข้อบกพร่อง มันทำด้วยเหตุผลที่ดีเช่นเดียวกันกับข้างต้นที่ทำให้มันเป็นจริงในจิราตามที่คุณเห็นตัวเอง