เกณฑ์การยอมรับสำหรับคดีขอบ

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

ในการป้องกันของฉันฉันไม่ทราบว่าการออกแบบของเขาสำหรับเรื่องราวจนกระทั่งหลังจากที่เขาใช้มันดังนั้นมันยากที่จะย้ำผ่านความเป็นไปได้ทั้งหมด (การกำหนดค่าจะอยู่ใน DB หรือไฟล์คุณสมบัติ?) เพื่อความเรียบง่ายสมมติว่าเรามีเรื่องราวที่จะเพิ่มการหารลงในแอพเครื่องคิดเลข ในโลก SCRUM ในอุดมคติมันจะเป็นหน้าที่ของฉันที่จะเพิ่ม "จัดการหารด้วยศูนย์สถานการณ์" เพื่อเกณฑ์การยอมรับหรือเขาควรจะทำงานผ่านกรณีเหล่านั้นในขณะที่เขาพัฒนาเพื่อให้แอปไม่ได้แปลในวันที่ 5/0? เพื่อความชัดเจนในกรณีนี้ฉันจะไม่ยอมรับหากแอปขัดข้องอย่างหนักในวันที่ 5/01 แต่ฉันจะผ่านถ้ามันบันทึกพิมพ์ DIV0 หรือวิธีอื่นใดเพื่อจัดการข้อผิดพลาด ... ตราบใดที่มันไม่ทำงาน ไม่ผิดพลาด

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

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

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

ทีมต้องทำงานร่วมกันเมื่อเทียบกับการมีทัศนคติ / มนต์ไม่ใช่ประเภทของฉัน "ไม่ใช่งานของฉันไม่ใช่ความรับผิดชอบของฉัน"

เกณฑ์การยอมรับมาในรูปแบบของ:

• การยอมรับทางธุรกิจ
• การยอมรับการประกันคุณภาพ

โดยทั่วไปแล้วการยอมรับทางธุรกิจมักจะตอบคำถาม:

• คุณลักษณะที่ใช้งานอยู่นั้นเป็นสิ่งที่ฉันต้องการหรือไม่

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

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

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

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

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

ทีมควรทำงานร่วมกัน (ธุรกิจ, QA, นักพัฒนา) เพื่อกัญชาออกประเภทการค้นพบใด ๆ ที่ชัดเจนของความต้องการ หากนี่เป็นความว่องไวพวกเขาทุกคนควรนั่งที่โต๊ะเดียวกันเพื่อส่งเสริมการสื่อสารและการแก้ไขปัญหาที่อาจเกิดขึ้นได้อย่างรวดเร็ว มันควรเป็นดังนี้:

QA:

"เฮ้นักพัฒนาเราควรจัดการสถานการณ์นี้โดยเฉพาะฉันค้นพบว่าถ้าฉันป้อนข้อมูลนี้ฉันจะได้รับข้อผิดพลาด"

DEV:

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

ธุรกิจ:

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

DEV:

"มันจะง่ายเพียงแค่ชั่วโมงหรือสองชั่วโมงเท่านั้นฉันสามารถทำซ้ำได้ QA โปรดอัปเดตเกณฑ์การยอมรับของคุณสำหรับสถานการณ์นี้เราไม่ต้องการเรื่องราวเพิ่มเติมสำหรับเรื่องนี้ขอบคุณ!"

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

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

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

การทดสอบการยอมรับควรเป็นส่วนสำคัญของเอกสารข้อกำหนดใด ๆ หากข้อกำหนดยังไม่ได้ระบุเกณฑ์ในการยอมรับก็ไม่ใช่ข้อกำหนดเช่นกัน มันเป็นความปรารถนา

มีอะไรเกิดขึ้นที่นี่เป็นที่ที่คุณได้ค้นพบความคุ้มค่า มูลค่าการป้อนข้อมูลไม่ได้คิดว่าเมื่อเรื่อง (และเกณฑ์การยอมรับ) ถูกเขียนหรือเมื่อรหัสถูกเขียน ถ้ามันไม่ได้เป็นส่วนหนึ่งของเกณฑ์การยอมรับคุณก็ไม่มีพื้นฐานที่จะปฏิเสธเรื่องนี้ได้

สิ่งที่เราจะทำกับทีมของฉันคือ:

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

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

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

ข้อสังเกตบางอย่าง:

... เมื่อฉันปฏิเสธเรื่องราวของเขา

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

เขาบอกว่ามันไม่ยุติธรรมเพราะฉันไม่ได้ระบุเคส

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

ฉันไม่รู้การออกแบบของเขาสำหรับเรื่องนี้จนกว่าเขาจะนำไปใช้

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

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

• แนะนำให้ผู้พัฒนารวมถึงเวลาในเรื่องที่จะแก้ไขปัญหาฝาครอบค้นพบกรณีขอบ Heck ทำให้เป็นส่วนหนึ่งของเรื่องราวของผู้ใช้แต่ละคน สิ่งนี้สามารถป้องกันได้อย่างง่ายดายผ่านเป้าหมายของข้อบกพร่องใหม่ 0 รายการ ปัญหาคือว่า dev ไม่ได้วางแผนในขณะนี้ และเขานอกเวลาเมื่อคุณค้นพบปัญหา มันจะต้องใช้เวลาทั้งสองทางดังนั้นใส่ไว้ในเรื่องราวที่มองเห็นได้ในระหว่างการวางแผน
• หลังจากการทดสอบของคุณ (และขอขอบคุณสำหรับการทดสอบโดยวิธี!) ส่ง dev ของรายการปัญหาที่ค้นพบ การแก้ไขปัญหาเหล่านี้จะไปกับสภาพ "กรณีแก้ไขขอบ" ของความพึงพอใจ
• หากมีสิ่งใดที่ยังคงไม่เปลี่ยนแปลงหรือถูกค้นพบว่าสายเกินไปให้ตัดสินใจว่าเรื่องนั้นต้องถูกผลักดันโดยขึ้นอยู่กับว่ากรณีการใช้นั้นสามารถเติมเต็มได้หรือไม่ ปัญหาที่พบและวิธีแก้ปัญหาเกิดขึ้น เปิดเผยในบันทึกย่อรีลีสและสร้างเรื่องราวใหม่เพื่อแก้ไข
• หากมีจุดหยาบเฉพาะในกระบวนการที่สร้าง pushback ให้เปลี่ยนกระบวนการของคุณ! ท้ายที่สุดการปรับปรุงกระบวนการเป็นส่วนหนึ่งของการต่อสู้ ตัวอย่างเช่นหาก dev ของคุณอารมณ์เสียเมื่อคุณปฏิเสธเรื่องนี้แนะนำให้ทีมเปลี่ยนกระบวนการเพื่อที่การปฏิเสธจะไม่ทำการแก้ไข ทำการทดสอบและแก้ไขก่อนทำและปฏิเสธ
• ทำงานกับทีมและสิ่งที่พวกเขาสร้างขึ้นมาและใช้ให้เกิดประโยชน์สูงสุดเท่าที่จะทำได้ พวกเขาไม่ได้ทำงานที่สมบูรณ์แบบและไม่ทำคุณ ดังนั้นวางแผนสำหรับสิ่งนั้น ทีมของฉันมักจะถูกเบี่ยงเบนไปดังนั้นเราจึงมีเรื่องราวผู้ใช้ Unplanned Support ในแต่ละการวิ่งสำหรับปัญหาเร่งด่วน ... การวางแผนเพื่อยกเลิกการวางแผน

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

ตัวอย่างที่เฉพาะเจาะจงเกี่ยวกับการหารด้วยศูนย์ หากคุณไม่ได้ระบุว่าคุณต้องการบันทึกข้อผิดพลาดอย่าบ่นว่านักพัฒนาพิมพ์ 100 เป็นผล

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