การต่อสู้ - สมาชิกในทีมกำลังยุ่งกับอะไรในระหว่างการวิ่ง

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

เมื่อมีการจัดตั้งกฎเหล่านี้ขึ้นมาแล้วเราอาจสงสัยว่าคนเหล่านี้จะไม่ว่างในระหว่างการวิ่ง ในตอนต้นของการวิ่งนั้นยังไม่มีอะไรให้ทดสอบและในตอนท้ายของการวิ่งจะไม่มีอะไรเหลือหรือน้อยมากที่จะพัฒนา / แก้ไข

ฉันได้เห็น 2 วิธีในการจัดการกับสิ่งนี้ แต่ดูเหมือนว่าไม่มีวิธีใดที่จะแก้ปัญหาได้อย่างเหมาะสม

1) ให้สมาชิกในทีมตัดสินใจว่าจะทำอย่างไรเมื่อใดก็ตามที่พวกเขาไม่ทำงาน

จุดด้อย:

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

2) ทำให้ห้องใน sprint เท่านั้นสำหรับการพัฒนาและเริ่มการทดสอบหลังจาก sprint เสร็จสิ้น (เมื่อนักพัฒนาเริ่มทำงานกับคุณสมบัติจาก sprint ถัดไป)

จุดด้อย:

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

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

ในตอนต้นของการวิ่งยังไม่มีการทดสอบอะไร

จริงๆ? คุณไม่มีข้อกำหนดในการตรวจสอบ? ไม่มีการสนทนากับลูกค้าของคุณ? ไม่มีโครงลวดในการประเมิน? ไม่มีแผนการทดสอบที่จะคิด

ในตอนท้ายของการวิ่งจะไม่มีอะไรเหลือหรือน้อยมากที่จะพัฒนา / แก้ไข

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

ฉันรู้ว่าบางคนเคร่งศาสนามากเกี่ยวกับสิ่งที่เป็นและสิ่งที่ไม่ 'SCRUM' ฉันไม่แคร์เรื่องนั้นน้อยลง แต่ฉันคิดว่าคุณมีสองประเด็นที่นี่:

1. แผนก QA แบบ 'ดั้งเดิม' ที่ทดสอบโค้ดเมื่อเสร็จสิ้นโดยนักพัฒนาแทนที่จะทำงานกับลูกค้าและนักพัฒนาเพื่อให้แน่ใจว่าคุณกำลังสร้างสิ่งที่ถูกต้องและสร้างมันให้ถูกต้อง ดูที่การทดสอบความคล่องตัวโดย Lisa Crispin ผู้ทดสอบที่ดีที่สุดมีส่วนร่วมในทุกระยะของวงจรการพัฒนาซอฟต์แวร์และนักพัฒนาที่ดีที่สุดจะเขียนการทดสอบของตัวเอง

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

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

@Cort Ammon นำเสนอจุดพิเศษหนึ่งจุดในความคิดเห็น แถลงการณ์เปรียวพูดคุยเกี่ยวกับการทำงานร่วมกันของลูกค้าในการเจรจาสัญญา คุณพูดว่า:

ลูกค้าอาจรู้สึกผิดหวังที่เห็นว่าทีมต้องเสียเวลากับบางสิ่งที่ไม่คุ้มค่าทันที

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

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

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

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

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

อย่างไรก็ตามในทุก ๆ ทีมที่ฉันทำงานอยู่มันมีงานเยอะอยู่เสมอ ให้ฉันพูดถึงข้อกังวลบางข้อของคุณ:

ในตอนต้นของการวิ่งยังไม่มีการทดสอบอะไร

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

ในตอนท้ายของการวิ่งจะไม่มีอะไรเหลือหรือน้อยมากที่จะพัฒนา / แก้ไข

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

ฉันได้เห็น 2 วิธีในการจัดการสิ่งนี้ ... 1) ให้สมาชิกในทีมตัดสินใจว่าจะทำอย่างไรเมื่อใดก็ตามที่พวกเขาไม่ทำงาน

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

ทำให้มีที่ว่างในการวิ่งเพื่อการพัฒนาเท่านั้น

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

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

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

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

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

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

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

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

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