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

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

เพื่อความชัดเจนนี่เป็นกระบวนการที่นักพัฒนากำลังเขียนหน่วยการรวมและการทดสอบ UI ที่มีความครอบคลุมที่ดี

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

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

ในฐานะเพื่อนร่วมงานของคุณฉันไม่ได้เห็นองค์กรที่ประสบความสำเร็จซึ่งไม่ต้องคำนึงถึงเวลาในการทดสอบ

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

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

ใช่เลยใช่ไหม

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

หากนี่เป็นความคล่องตัวฉันจะรวมความพยายามทดสอบเป็นส่วนหนึ่งของคะแนนรวม ตัวอย่างเช่นความพยายามในการพัฒนา 1 วันและทดสอบ 1 วันเพื่อให้เป็น 2 ประเด็น

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

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

แน่นอนว่าจะได้รับทั้งหมดเมื่อคุณเริ่มใช้คะแนนเรื่องราวเนื่องจากความแตกต่างระหว่าง dev-only 5 และ dev-only 8 จะเป็นสัดส่วนที่ค่อนข้างดีกับ dev-and-QA 5 เทียบกับ dev-and-QA 8

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

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

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

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

หากเป็นทีมเดียว แต่มีบทบาท "ผู้พัฒนา" และ "ผู้ทดสอบ" ที่แยกจากกันนั่นอาจหมายความว่าคุณมีตั๋วจำนวนมากที่มีเพียงฝ่ายเดียวเท่านั้นที่สามารถทำงานต่อได้และแผนภูมิ Gantt ของคุณ (อาจเป็นสมมุติฐานโดยสิ้นเชิง) เหมือนกับแผนภูมิสำหรับสองทีมที่แยกกันจะมีลักษณะ ความจริงเรื่องนี้จะทำให้เสียวิธีการบางอย่างมากกว่าวิธีอื่นและคุณอาจจะแยกการวางแผนออกได้ดีกว่า แต่ถ้าคุณไม่แยกมันคุณจะต้องออกตั๋วและประเมินทุกอย่างที่ทีมต้องทำหรือการคาดการณ์ของคุณจะสิ้นหวัง .

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

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

เรากำลังทำเมื่อเรากำลังการผลิตพร้อม

ซึ่งรวมถึงการทดสอบด้วยตนเองและการสำรวจเชิงลึกใด ๆ รวมถึงการทดสอบการยอมรับของผู้ใช้

ทีม Agile ควรจะสามารถปล่อยงานใหม่ที่เสร็จสมบูรณ์ได้ทุกเมื่อ เช่น:

ซอฟต์แวร์ที่ใช้งานเป็นมาตรการหลักของความคืบหน้า

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

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

นี่คือสิ่งที่สำคัญมาก: ประมาณการทุกคนควรจะมาพร้อมกับสมมติฐานและการยกเว้น

ซึ่งรวมถึงการระบุสิ่งที่รวมอยู่: การพัฒนาเท่านั้นการออกแบบและการพัฒนาการทดสอบ dev และยูนิตการครอบคลุมสำหรับการทดสอบการยอมรับการสร้างโครงสร้างพื้นฐานเป็นต้น

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

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

เวลาที่ควรจะรวมอยู่ในประมาณการ แต่คุณไม่ควรประมาณการระยะเวลาในการทดสอบแทนทดสอบควรประเมินเวลาของพวกเขา

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

encapsulation

ฉันจะเข้าหาสิ่งนี้จากมุมมองการพัฒนาซอฟต์แวร์และภาษา

• คุณเป็นฟันเฟืองขนาดเล็กในเครื่องขนาดใหญ่
• จากด้านนอกของทีมระบบตั๋วของคุณทำหน้าที่เป็นส่วนต่อประสาน / API กับทีมของคุณ
• ผู้ใช้ทางธุรกิจที่ใช้ระบบจองตั๋วไม่ใช่นักพัฒนา

จากการออกแบบซอฟต์แวร์ที่ดีคุณควรทำให้ง่ายขึ้นและห่อหุ้มให้มากที่สุด

เพื่อดูกระบวนการจากมุมมองของผู้ใช้ทางธุรกิจพวกเขาสนใจเพียง 2 อย่างเท่านั้น

1. ราคาเท่าไหร่
2. เราเสร็จแล้วหรือยัง

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

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