เราควรเลิกพยายามทำตัวให้คล่องถ้า QA ใช้เวลา 12 สัปดาห์?

24

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

agile qa

— เดวิดโฮเซอร์
แหล่งที่มา

36

ฉันอยากจะบอกว่าถ้า QA ใช้เวลา 12 สัปดาห์คุณก็ไม่ได้ "คล่องแคล่ว"

— เจรจาต่อรองเดี่ยวสิ้นสุด

9

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

— merryprankster

1

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

— David Hosier

2

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

— merryprankster

2

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

— merryprankster

21

คำตอบสำหรับคำถามของคุณคือMuฉันกลัว - มีรายละเอียดไม่เพียงพอที่จะคาดเดาได้ว่าคุณควรหรือไม่เลิกลอง

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

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

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

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

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

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

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

ในที่สุดเราก็สามารถอัพเกรดได้เพียงครึ่งปีหลังจากนั้นมากสำหรับความคล่องตัวของพวกเขา}

ทีนี้มาดูในระยะเวลา 12 สัปดาห์ที่คุณพูดถึง

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

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

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

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

อัปเดตตามการชี้แจงที่ให้ไว้ในความคิดเห็น

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

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

ฉันเห็นใครทำผิดทางอาญาในการรักษา Sprint-end-release เป็นเพียงจุดตรวจสอบบางอย่างที่น่าพอใจของทีม

^{dev: ใช่ว่าคนที่ดูดีพอที่จะผ่านไปยังผู้ทดสอบ; QA: ใช่แล้วว่ามันดูดีพอสำหรับกรณีนี้ถ้าต้องการการทดสอบแบบ shippable เพิ่มเติม - สิ่งที่ต้องการ ทีม (dev + QA) พอใจนั่นแหล่ะ}

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

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

^{ฉันมักจะคิดว่ามันในแง่ของเฟอร์รารี (ตามปกติซ้ำ ๆ ) เทียบกับแลนด์โรเวอร์ (เหมือนการต่อสู้)

เมื่อขับรถบนทางหลวง (และโครงการของคุณดูเหมือนจะมาถึงทางหลวงนั้น) เฟอร์รารีชนะนรกจาก Landrover

มันเป็นรถออฟโรดที่ใคร ๆ ก็ต้องการรถจี๊ปไม่ใช่รถสปอร์ต - ฉันหมายความว่าถ้าความต้องการของคุณไม่ปกติและ / หรือถ้าประสบการณ์การทำงานเป็นทีมและการจัดการไม่ดีคุณต้องเลือก Scrum - เพราะการพยายามไปตามปกติจะทำให้คุณ ติดอยู่ - เช่นเดียวกับ Ferrari จะติดอยู่นอกถนน}

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

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

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

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

— ริ้น
แหล่งที่มา

1

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

— David Hosier

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

— David Hosier

3

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

— David Hosier

1

+1 ฉันชอบตัวอย่างของความต้องการของตลาดที่แตกต่างกัน หนึ่งสามารถให้ตัวอย่างที่มากขึ้น เช่นซอฟต์แวร์ควบคุมเพื่อจัดการการปล่อยจรวดอวกาศ ลูกค้าอาจจะมีความสุขกับการอัพเกรดทุกห้าปี (กฎหมายของฟิสิกส์ไม่เปลี่ยนแปลงมากนัก) แต่เพียงหนึ่งในข้อผิดพลาดการถดถอยเดียวอาจเสียค่าใช้จ่ายหลายร้อยล้านดอลลาร์

— MarkJ

14

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

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

การทดสอบคุณสมบัติ - พลิกกลับอย่างรวดเร็วในการทดสอบการพัฒนาใหม่

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

การทดสอบอัตโนมัติ - การเขียนชุดการทดสอบการถดถอยแบบเต็มเพื่อเพิ่มความเร็วในการทำงานของทีมทดสอบการถดถอย

ทีมที่สามเป็นโบนัส แต่ถ้าคุณไม่มีสองทีมแรกคุณก็อาจเป็นน้ำตกได้

— สาธารณรัฐประชาธิปไตยประชาชนลาว
แหล่งที่มา

+1 การทดสอบอัตโนมัติ - การทดสอบการถดถอยเป็นตัวเลือกอันดับต้น

— Joshua Davis

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

— David Hosier

13

ตามภาพประกอบ:

ป้อนคำอธิบายรูปภาพที่นี่

โปรดทราบว่าทีมงานควบคุมคุณภาพของคุณอาจทำงานนอกวงเวียน (ATDD) และคุณกำลังทำงานอยู่ภายใน

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

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

2

ปัญหาคือคุณได้รับรายงานข้อบกพร่องจากการทำงาน 4-6 ครั้งที่ผ่านมา (สมมติว่าการวิ่ง 2-3 สัปดาห์) ขึ้นอยู่กับนโยบายและขั้นตอนการควบคุมคุณภาพของ บริษัท พวกเขาอาจต้องลงชื่อออกจริง ๆ ก่อนที่จะปล่อยให้ลูกค้าทราบ ใช่คุณอาจมีผลิตภัณฑ์ที่สามารถส่งได้หลังจากการวิ่งทุกครั้ง แต่น้อยกว่า 25% จะถูกโจมตี QA (สมมติว่าเมื่อพวกเขาทดสอบผู้สมัครคนหนึ่งเสร็จพวกเขาจะเริ่มการทดสอบผู้สมัครล่าสุด) เพื่อให้ลูกค้าแสดงผลิตภัณฑ์ทุก ไม่กี่สัปดาห์ แต่พวกเขาสามารถรับได้ทุก ๆ 12 สัปดาห์เท่านั้นและจะเก่ากว่าที่พวกเขาเพิ่งเห็น

— Thomas Owens

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

— David Hosier

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

— David Hosier

8

ดูเหมือนว่าคุณมีปัญหา "คำจำกัดความของเสร็จสิ้น"

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

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

ควบคุมคุณภาพไม่ควรหาอะไร

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

— Sean McMillan
แหล่งที่มา

3

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

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

— Michael Borgwardt
แหล่งที่มา

3

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

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

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

— GuyR
แหล่งที่มา

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

— David Hosier

2

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

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

ปัญหาอยู่ที่ (ในสายตาของคุณ) กับแผนก QA ปัญหาสามารถแก้ไขได้ที่นั่น? คุณเคยคุยกันไหม?

— refro
แหล่งที่มา

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

— David Hosier

@ David: ฉันเห็นด้วยกับคุณ

— Christopher Mahan

1

12 สัปดาห์นั้นมีความยาว แต่หวังว่า QA จะสามารถให้ข้อเสนอแนะและรายงานข้อผิดพลาดในช่วงเวลานั้นได้ (หลังจากผ่านไปสามเดือน)

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

— ฮิวโก้
แหล่งที่มา

-2

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

ทีมพัฒนามีความคล่องตัว แต่ส่วนที่เหลือของ บริษัท ไม่ใช่

ใครก็ตามที่รับผิดชอบในการควบคุมคุณภาพก็ไม่ทราบว่าเขา / เธอกำลังทำอะไรหรือพวกเขาได้ทำ Jedi Mind Trick เกี่ยวกับผู้บริหารระดับสูงและได้รับอนุญาตให้ใช้เวลาอันแสนหวาน QA ใช้เวลานานกว่าการพัฒนาอย่างไร

— JeffO
แหล่งที่มา