ต่อสู้ทุกวัน - ถามคำถาม 3 ข้อต่อผู้พัฒนาหรือซื้อตั๋ว?
เราเป็นทีมเล็ก ๆ ที่มีนักพัฒนาประมาณ 5 คน
เรากำลังใช้ระบบจัดการตั๋วที่มี Scrumboard เสมือน
บน Scrumboard มีหลายคอลัมน์ รายการในคอลัมน์เรียงตามลำดับความสำคัญ:
New | Consultation | Working | Waiting | Test & Review | Done
การให้คำปรึกษา = เราต้องการคำติชมจากคนภายนอก
Waiting = รอใครบางคนหรือบางสิ่ง
เรามีตั๋วที่ใช้งานอยู่ประมาณ 40-50 ใบในขณะที่วิ่ง 2 สัปดาห์
ใน Scrum-daily มาตรฐานโดยปกตินักพัฒนาทุกคนจะตอบคำถาม 3 ข้อ:
เมื่อวานนี้ฉันทำอะไรไปบ้าง?
วันนี้ฉันจะทำอะไร
อุปสรรคของฉันคืออะไร?
กระบวนการของเราแตกต่างกันอย่างไร:
เราไปทีละคอลัมน์แล้วทีละตั๋วในคอลัมน์
เราทำสิ่งนี้เนื่องจากสาเหตุหลายประการ:
- กระบวนการนี้พัฒนาขึ้นเองเราไม่ได้วางแผนไว้มันเพิ่งเกิดขึ้น
- นักพัฒนาบางรายจะ "เว้นวรรค" เมื่อคนอื่นจะพูดและไม่ฟัง ใช่โดยปกติแล้วจะใช้เวลาเพียง 15 นาทีต่อวันดังนั้นจึงสามารถคาดหวังได้ว่าการฟังในครั้งนี้ควรเป็นไปได้ แต่เนื่องจากเราทุกคนทำงานจากที่บ้านเราจึงไม่สามารถสังเกตได้ว่ามีใครฟังอยู่หรือไม่
- เมื่อนักพัฒนาซอฟต์แวร์ตอบคำถาม 3 ข้อของเขาเสร็จแล้วเขาอาจไม่ฟังคนอื่นเนื่องจากโฟกัสของเขาหายไป
- นักพัฒนาสามารถมองเห็นได้บนตั๋ว แต่การค้นหาชื่อของคุณเองเพื่อค้นหาตั๋วที่คุณกำลังดำเนินการอยู่นั้นต้องใช้เวลาสักหน่อย มีหลายวิธีในการเปลี่ยนมุมมอง แต่การสลับมุมมองอย่างต่อเนื่องทำให้ทุกคนน่ารำคาญค่อนข้างเร็ว
- ถ้าเราไปโดยนักพัฒนาบางครั้งเขาอาจมองข้ามตั๋วสำคัญในขณะที่นำเสนอ
ไปทีละคอลัมน์จากนั้นตั๋วให้ความรู้สึก "เป็นธรรมชาติ" มากขึ้นและทุกคนก็ดูกระตือรือร้นในการฟังมากขึ้นเนื่องจากตั๋วใบต่อไปอาจเป็นของเขาหรือเธอ นอกจากนี้เราไม่มองข้ามรายละเอียดหรือตั๋วที่สำคัญใด ๆ โดยส่วนใหญ่แล้วนักพัฒนาซอฟต์แวร์จะตอบคำถาม 3 ข้อโดยอ้อมด้วยวิธีนี้เช่นกัน แต่ไม่เสมอไป กระบวนการนี้ยังคงให้ความรู้สึกค่อนข้างดีกว่า - อย่างน้อยก็ในสภาพแวดล้อมของเรา!
คุณควรตอบคำถาม 3 ข้อนี้เสมอหรือควรไปด้วยตั๋ว?
หรือมีวิธีที่จะบอกได้ว่าเมื่อไหร่แนวทางไหน "ดีกว่า"?
(บางทีภาพนี้อาจช่วยให้เข้าใจคำถามของฉัน)
คำตอบ
คุณควรตอบคำถาม 3 ข้อนี้เสมอหรือควรไปด้วยตั๋ว? หรือมีวิธีที่จะบอกได้ว่าเมื่อไหร่แนวทางไหน "ดีกว่า"?
Scrum Guide เวอร์ชันปี 2020 ได้ลบคำถามสามข้อออกไปในขณะที่คู่มือฉบับปี 2017ระบุว่า:
โครงสร้างของการประชุมกำหนดโดยทีมพัฒนาและสามารถดำเนินการได้หลายวิธีหากเน้นไปที่ความคืบหน้าไปสู่เป้าหมาย Sprint ทีมพัฒนาบางทีมจะใช้คำถามบางส่วนจะใช้การอภิปรายมากกว่า
ดังนั้นทำทุกอย่างที่คุณคิดว่าดีที่สุดหรือถามทีมของคุณว่าพวกเขาชอบอะไรและพบว่ามีประโยชน์มากกว่า
คำถามสามข้อเป็นตัวอย่างของวิธีการดำเนินการในแต่ละวันเพราะเน้นการอภิปรายในสิ่งพื้นฐานที่คุณต้องครอบคลุมเพื่อประสานความพยายามของคุณไปสู่เป้าหมาย หากคุณพบว่าการพูดคุยเรื่องตั๋วเป็นแนวทางที่เหนือกว่าให้ทำตามนั้น
เพียงตรวจสอบให้แน่ใจว่าคุณไม่หลงตัวเองในรายละเอียดมากเกินไป (คุณสามารถพูดคุยในรายละเอียดเพิ่มเติมได้ทุกวันหลังจากนั้น) และนอกเหนือจากกรอบเวลาซึ่งจะทำให้สิ่งต่างๆเปลี่ยนเป็นการประชุมและเปิดโอกาสให้ผู้คนชำระจิตใจ
TL; ดร
คุณควรเดินตามนักพัฒนาหรือคอลัมน์หรือไม่? ทั้งสองอย่าง ทั้งสองเป็นรูปแบบการต่อต้าน
ไม่รักษา standup เป็นดึงสถานะจากทีมและแน่นอนไม่ได้ใช้มันเป็นมินิการตรวจสอบสถานะของงานทุกวางแผนสำหรับทั้งการวิ่ง หากคุณรักษาขอบเขตของความโดดเด่นให้กับงานของวันปัจจุบันคำถามเกี่ยวกับวิธีที่ดีที่สุดในการ "เดินบนกระดาน" (คำใบ้: ไม่มีเพราะคุณไม่ควรทำอย่างนั้น) จะหายไป
เน้นที่การประสานงานของทีม
คำถามของคุณเริ่มต้นจากข้อสันนิษฐานพื้นฐานที่มีข้อบกพร่องนั่นคือการรายงานสถานะของตั๋วทั้งหมดเป็นประโยชน์หรือแม้กระทั่งเป็นที่ต้องการใน Scrum เป็นปัญหา X / Y จริง ๆ เนื่องจากทีมขาดจุดรวมของการยืนประจำวันซึ่งก็คือการดำเนินการวางแผนและประสานงานแบบทันเวลาสำหรับกิจกรรมของวันปัจจุบัน
"คำถามสามข้อ" เป็นเพียงแนวทางในการยุติ ในทีมที่มีวุฒิภาวะน้อยการมีแนวทางหรือประเด็นการพูดคุยจะช่วยให้สมาชิกในทีมระบุการพึ่งพาระหว่างงานได้ แม้ว่าเจตนาจะไม่ให้รายงานสถานะ เป้าหมายคือเสมอเพื่อช่วยให้ทีมงานวางแผนการทำงานในวันปัจจุบันร่วมกัน ตัวอย่างเช่น:
แซนดี้: เมื่อวานนี้ฉันทำงานเกี่ยวกับการสร้างวิดเจ็ตส่วนกลาง วันนี้ฉันต้องคลำฟันเฟืองหลัก แต่ฉันต้องการ whatchamacallit จาก Susan เพื่อทำสิ่งนั้น
ซูซาน: เมื่อวานฉันทำ whatchamacallit เสร็จแล้วก็เลยพร้อมสำหรับแซนดี้ วันนี้ฉันอยากจะทำงานกับผู้ช่วยให้รอด แต่ฉันติดอยู่จนกว่าเรื่องราวของ MacGuffin จะเสร็จสมบูรณ์ ยังมีใครทำงานอยู่ไหม
กล่าวอีกนัยหนึ่งคืออย่าใช้การยืนประจำวันเพื่อ "เดินบนกระดาน" ใช้เพื่อให้ทีมสามารถจัดระเบียบตัวเองในการทำงานของวัน! หากคำถามช่วยให้ทีมทำเช่นนั้นได้เยี่ยมมาก ถ้าไม่ให้โยนทิ้ง
ในทำนองเดียวกันควรมีการหารือเฉพาะงานที่กำลังดำเนินการอยู่แล้วหรือวางแผนไว้สำหรับวันนั้นที่จุดเริ่มต้น การทำงานใน Backlog Sprint หรือสถานะรอดำเนินการมีความเกี่ยวข้อง แต่ถ้ามันเป็นพึ่งพาของงานในปัจจุบันป้องกันอย่างอื่นหรือแผนการที่ใครบางคนที่จะดึงมันในการทำงานในความคืบหน้าในวันนี้
หากคุณต้องการสถานะ Sprint จริงๆให้ใช้ประโยชน์จากคอลัมน์เสร็จสิ้นและแผนภูมิเบิร์นดาวน์ของคุณเพื่อพิจารณาว่าคุณอยู่ในเส้นทางที่จะบรรลุเป้าหมาย Sprint หรือไม่ หากสถานะของ Sprint Goal เป็นปัญหานั่นอาจสมควรได้รับการประชุมแยกกันนอกการประชุมประจำวันและแน่นอนว่าส่วนใหญ่จะได้รับความสนใจจากทีม Scrum ทั้งหมดใน Sprint Retrospective ครั้งต่อไปของคุณ ที่ดีที่สุดการเดินบนกระดานถือเป็นการหยุดเพื่อปกปิดการสื่อสารที่ไม่มีประสิทธิภาพหรือตัวระบายข้อมูลที่ขาดหายไป / ไม่ถูกต้อง ที่แย่ที่สุดคือป้องกันไม่ให้ทีมทำงานร่วมกันในการวางแผนแบบทันเวลาโดยสนับสนุนการรายงานสถานะมากกว่าการโต้ตอบระหว่างสมาชิกในทีม
แนวทางคำถามสามข้อมุ่งเน้นไปที่แต่ละบุคคล แต่แนวทางของคณะกรรมการมุ่งเน้นไปที่ทีมและเป้าหมายในการวิ่ง (หรืออย่างน้อยก็คือเป้าหมายที่ด้านขวามือของกระดาน) จากประสบการณ์ของฉันข้อผิดพลาดของคำถามสามข้อคือเมื่อแต่ละคนรู้สึกว่าพวกเขาต้องพิสูจน์ว่าพวกเขาได้ผล แต่ถ้าไปโดยตั๋วคุณอาจไม่ได้คุยกับทุกคน
ตามที่ฉันได้บอกไว้ข้างต้นซึ่งจะดีกว่าขึ้นอยู่กับเป้าหมายของคุณ
หากทีมมีความเหนียวแน่นและคณะกรรมการสะท้อนเส้นทางไปสู่เป้าหมายให้ใช้กระดาน (ฉันขอแนะนำให้ทำต่อไปและใช้กระดานจากขวาไปซ้ายอย่างชัดเจน: ให้ความสำคัญกับการทำสิ่งต่างๆให้เสร็จสิ้น)
แต่ถ้าทีมยังใหม่หรือยังทำงานร่วมกันไม่ได้ดีหรือถ้าคณะกรรมการไม่ได้เป็นตัวแทนของเป้าหมายจริงๆคำถามสามข้ออาจเป็นทางออกที่ดีกว่า เป้าหมายในการวิ่งจริง ๆ แล้วอาจเป็น "รวมทีมใหม่นี้ให้เจล" หรือ "ขึ้นเครื่องแฟรงกี้เพื่อให้เธอมีประสิทธิภาพ" หากเป็นเช่นนั้นคุณต้องแน่ใจว่าทุกคนมีโอกาสพูดคุยเกี่ยวกับสิ่งที่พวกเขาทำสิ่งที่ได้ผลและสิ่งที่ไม่ได้ผล
หรือมีวิธีที่จะบอกได้ว่าเมื่อไหร่แนวทางไหน "ดีกว่า"?
สิ่งหนึ่งของการพัฒนา Agile คือการให้ความยืดหยุ่นกับเป้าหมายโครงการและองค์กร สิ่งหนึ่งที่คุณสามารถยืดหยุ่นได้เกี่ยวกับวิธีการดำเนินการประจำวันของคุณคือการปรับปรุงมันซ้ำ ๆ รวบรวมความคิดเห็นจากทีมของคุณพูดคุยเกี่ยวกับโครงสร้างรายวันในการย้อนหลังของการวิ่งและอย่ากลัวที่จะทดสอบตามคำแนะนำของทีม
ปัจจุบันฉันทำงานในทีมที่เรามีทั้งสองแนวทาง - เราทั้งคู่มีภารกิจที่มุ่งเน้นทุกวันและ "คำถามสามข้อ" ทุกวัน ครั้งแรกคือสิบนาทีต่อวันระหว่างนักพัฒนาเพื่อหารือเกี่ยวกับคณะกรรมการปัจจุบันและมีพื้นที่สำหรับการสังเกตการณ์ทางเทคนิคบางอย่าง อย่างที่สองคือเวลา 15 นาทีต่อวันซึ่งเน้นที่ "คำถามสามข้อ" มากขึ้นเพื่อพยายามที่จะมีมนุษยธรรมมากขึ้นทุกวันกับทีมที่กว้างขึ้น
เรามีนักพัฒนาและงานของพวกเขาดำเนินการทุกวัน แต่เราตัดสินใจที่จะยกเลิกกระบวนการด้วยเหตุผลทั้งสองประการที่คุณกล่าวถึงในเรื่องโฟกัสความกังวลเรื่องเวลาและการขาดความเข้าใจที่ตรงกันเกี่ยวกับสถานะของงานที่เกี่ยวข้อง และใช่การกรองงานโดยนักพัฒนาซอฟต์แวร์อย่างต่อเนื่องก็เป็นเรื่องยุ่งยากสำหรับเราเช่นกัน
ฉันไม่สามารถแสดงความคิดเห็นได้ดังนั้นฉันจึงเพิ่มสองเซ็นต์เป็นคำตอบ
หากฉันอาจแนะนำ: "คำถามสามข้อ"อาจ "จ้องมองไปที่สะดือของคุณ" ในขณะที่คุณต้องการให้ทุกคน "มองไปรอบ ๆ " จริงๆ
สิ่งแรกที่ฉันจะทำคือหาวิธีจัดกลุ่มรายการงานของคุณด้วยวิธีใดวิธีหนึ่งที่ช่วยให้คุณพิจารณางานที่เกี่ยวข้องร่วมกันได้อย่างสะดวกในลักษณะที่ "เป็นประโยชน์ทางธุรกิจ" (นอกจากนี้หาวิธีที่ใช้งานได้ในการ "แท็ก" งานที่อาจเกี่ยวข้องกับมากกว่าหนึ่งกลุ่มในซอฟต์แวร์โดยทั่วไปแล้วทุกอย่างจะเกี่ยวข้องกับอย่างอื่นทั้งหมด)
จากนั้นฉันจะขอให้ทีมพิจารณาแต่ละกลุ่มร่วมกับคุณและเพื่อช่วยให้คุณทุกคนเลือก (!)อะไร - โดยความเห็นพ้องร่วมกันและได้รับข้อมูล - ควรเป็น "คำถามสามข้อสำหรับวัน" ของทีม
ในแง่หนึ่งนักพัฒนาซอฟต์แวร์ได้เรียนรู้ที่จะได้รับความสามารถที่เหนือกว่าในการมุ่งเน้นไปที่สิ่งที่เป็นปัญหาในแต่ละวัน เพื่อที่จะพูดว่า "พวกเขารู้วิธีที่จะดำดิ่งลงไปลึก ๆ และไม่ย่อท้อ" แต่ - พูดจากประสบการณ์ส่วนตัวตอนนี้ - มันแย่มากที่จะตระหนักว่าสายเกินไปที่คุณไม่รู้ว่าคุณดำดิ่งลงไปในจุดที่ผิดด้วยเหตุผลที่ไม่ถูกต้องและคุณเพิ่งประสบกับพายุเฮอริเคน “ มีคุณ แต่รู้จัก ... ”
ดังนั้นประเด็นพื้นฐานจึงชัดเจน: เนื่องจากนักพัฒนาคือ - และต้องเป็น "นักดำน้ำลึก" ที่มักจะนั่งเรือแห้งตลอดเวลาดูภาพใหญ่อยู่เสมอ? ดูฉลาม? ช่วยให้พวกเขารู้ว่าพวกเขาพายเรือไปมาบนผิวน้ำที่ไหนและทำไมต้องดำน้ำต่อไป? นั่นจะเป็นคุณ
ตอนนี้ - เพื่อให้ความคิดสมบูรณ์ - บางครั้งนักดำน้ำเหล่านั้นจะกลับมาที่ผิวน้ำพร้อมกับการค้นพบใหม่ที่สำคัญที่คุณไม่อาจรู้ได้ ให้นักพัฒนาซอฟต์แวร์ร่วมให้ "ตั๋ว" ในมิกซ์ของคุณเสมอ
ตามที่ผู้อื่นกล่าวไว้ Scrum Guide ไม่ได้กำหนดคำถาม 3 ข้ออีกต่อไป และตามจริงแล้วการต่อสู้ประจำวันส่วนใหญ่จากคำถาม 3 ข้อขัดแย้งกับวัตถุประสงค์ของเหตุการณ์ เมื่อได้รับการจัดเตรียมโดย Scrum Master และสมาชิกในทีมจะต้องรายงาน 24 ชั่วโมงที่ผ่านมาซึ่งอยู่ในการจัดการตนเอง 0% จะไม่ส่งผลให้ตรวจสอบสถานะของ Sprint อย่างแท้จริงและวางแผนวันด้วยจิตวิญญาณในการบรรลุเป้าหมาย Sprint ควรเป็นการสนทนาภายในของทีมพัฒนาที่สมาชิกในทีมสนใจในความสำเร็จของตนเอง