ความช่วยเหลือ - ทีมเทคนิคไม่ต้องการทำงานอย่างคล่องตัว
ฉันเป็นเจ้าของผลิตภัณฑ์ในทีม Scrum ซึ่งนักพัฒนาไม่ต้องการยอมรับการทำงานในรูปแบบที่คล่องตัวและเพิ่มขึ้น ตัวอย่างง่ายๆ: ลูกค้าต้องติดต่อเราเพื่อสร้างผู้ใช้ทุกครั้งดังนั้นเราจึงเรียกใช้โดยตรงใน SQL เนื่องจากไม่มี UI เหตุการณ์นี้เกิดขึ้นหลายครั้งในระหว่างวัน ในบางครั้งอาจมีคำขออื่น ๆ เช่นการรีเซ็ตรหัสผ่านสำหรับผู้ใช้ เมื่อพูดถึงการพัฒนาคุณสมบัติใหม่พวกเขายืนยันที่จะมีรายการ Backlog ที่เรียกว่า 'Users Grid' โดยทุกอย่างเป็นลายลักษณ์อักษร (การดำเนินการ CRUD การดำเนินการทางตรรกะทางธุรกิจเช่นการรีเซ็ตรหัสผ่านรับผู้ใช้ที่เกี่ยวข้อง ฯลฯ ) และเราส่งมอบตารางผู้ใช้ใน หนึ่งเดียวกับฟังก์ชั่นทั้งหมด ในขณะที่ฉันต้องการมีรายการค้างแยกต่างหากหนึ่งรายการสำหรับแต่ละฟังก์ชันการทำงานที่ฉันเพิ่งกล่าวถึงและส่งมอบรายการเพิ่มขึ้นในจำนวน Sprints ตามลำดับความสำคัญและมูลค่าทางธุรกิจ ตัวอย่างเช่นก่อนอื่นเราส่งมอบตารางผู้ใช้ที่ให้การดำเนินการ CRUD (ซึ่งจะทำให้ลูกค้าประสบปัญหาได้เร็วที่สุด) จากนั้นจึงส่งมอบคุณสมบัติอื่น ๆ ในการวิ่งครั้งต่อไป
เหตุผลของฉันคือการทำงานนั้นง่ายต่อการพัฒนาและทดสอบว่าเพิ่มขึ้นหรือไม่ ช่วยลดความเสี่ยงเราสามารถแสดงสิ่งต่างๆให้ลูกค้าทราบก่อนหน้านี้และรับข้อเสนอแนะก่อนหน้านี้ ในขณะที่สำหรับพวกเขามันง่ายกว่าถ้าเราไม่รวบรวมงานและส่งมอบสิ่งต่างๆให้เสร็จสิ้นในทันที
ฉันกลัวว่าเราจะจบลงด้วยโครงการขนาดเล็กจำนวนมากและฉันได้พยายามทุกอย่างเพื่อให้พวกเขาถอยห่างจากแนวทางนี้ ฉันค่อนข้างสงสัยว่ามันเป็นการขาดประสบการณ์ของหัวหน้าทีมที่ทำให้ทีมเป็นแบบนี้ นอกจากนี้เรายังมีโค้ชที่คล่องตัวซึ่งควรจะช่วยทีมในการทำงานแบบนี้ แต่ในนาทีที่เขาไม่ได้มองเรากลับมาที่สิ่งนี้
ฉันพยายามสื่อสารเรื่องนี้นับครั้งไม่ถ้วน แต่ทุกครั้งที่ฉันพบกับใบหน้าว่างเปล่าและการต่อต้าน ฉันมาถึงสถานการณ์ที่ฉันอยากให้พวกเขาทำงานอย่างที่ต้องการเพื่อให้พวกเขาเรียนรู้จากความผิดพลาดซึ่งฉันมั่นใจว่าพวกเขากำลังจะเกิดขึ้น แต่ฉันกังวลว่าโครงการและลูกค้าจะได้รับความเดือดร้อน ฉันไม่เคยมีปัญหาเหล่านี้ในอดีต ฉันพลาดอะไรไปรึเปล่า? มีความคิดอะไรอีกบ้างที่ฉันสามารถลองได้?
(ฉันมาจากภูมิหลังในการพัฒนาและมีบทบาทขั้นสูงระหว่างการพัฒนาและโครงการที่เป็นผู้นำในช่วง 20 ปีที่ผ่านมาดังนั้นฉันจึงเข้าใจความคิดเห็นบางส่วนจากนักพัฒนาด้านล่างฉันพัฒนามาเป็นบทบาท PO ในการเปลี่ยนแปลงตามธรรมชาติเพราะฉันใช้จ่ายไปมาก เวลาจัดการกับความต้องการของลูกค้าดังนั้นฉันจึงแต่งตั้งทีมงานด้านเทคนิคเพื่อมุ่งเน้นไปที่ปัญหาด้านเทคนิค / ทีมในขณะที่ฉันให้ความสำคัญกับลูกค้า)
คำตอบ
คุณไม่ได้เอ่ยถึง Scrum Master ในคำถามของคุณดังนั้นฉันจะถือว่าไม่มีตัวตนหรือไม่มีประโยชน์ ถ้าไม่แน่ใจว่าคุณเกี่ยวข้องกับ Scrum Master! เป็นหน้าที่ของเขา / เธอในการแก้ไขปัญหากระบวนการ
ดังที่กล่าวไว้ Scrum เป็นเครื่องมือในการจัดการกับสิ่งต่างๆเช่นนี้ - Retrospective นี่คือสิ่งที่ฉันจะทำในรองเท้าของคุณ
- สำหรับ Sprint หนึ่งครั้งฉันจะหยุดและปล่อยให้นักพัฒนาแยกเรื่องราวตามที่พวกเขาต้องการ (การแบ่งเรื่องราวควรเป็นกระบวนการทำงานร่วมกันระหว่าง PO และทีม Dev)
- ในตอนท้ายของ Sprint ในช่วง Retrospective ฉันจะชี้ให้เห็นปัญหาจริงในทางปฏิบัติที่เกิดจากการขาดการแยกส่วน (สมมติว่ามีอยู่ ! ใด ๆ ถ้าไม่ได้กลับไปขั้นตอนที่ 1)
- ฉันจะขอให้ทีมช่วยระดมความคิดวิธีแก้ปัญหาที่เป็นไปได้ ไม่มีอคติใด ๆ . เฉพาะในกรณีที่และหลังจากที่ทีมล้มเหลวในการจัดหาโซลูชันที่ใช้งานได้ฉันจะเสนอคำแนะนำของฉันเกี่ยวกับ 'แยกเรื่องราวให้ละเอียดยิ่งขึ้น'
จำไว้ว่าความคล่องตัวไม่ได้เกี่ยวกับการหลีกเลี่ยงปัญหา มันเกี่ยวกับการค้นหาได้อย่างรวดเร็ว อย่ายึดติดกับการทำตามความคล่องตัวเพื่อหลีกเลี่ยงปัญหาในอนาคตที่อาจเกิดขึ้นซึ่งคุณจะหลีกเลี่ยงรากฐานที่สำคัญของความคล่องตัว - พยายามตรวจสอบปรับตัว
นั่นคือสถานการณ์ที่น่าหงุดหงิดของคริส จากคำถามของคุณดูเหมือนว่าทีมจะไม่สามารถพัฒนาสิ่งต่างๆเป็นชิ้นเล็กชิ้นน้อย แต่จะทำไม่ได้ ฉันใช้สิ่งนี้ตามความจริงที่ว่าเมื่อโค้ชเปรียวอยู่ที่นั่นพวกเขาทำและจากประสบการณ์ของฉันในฐานะนักพัฒนาประเภทของการแยกส่วนที่คุณพูดถึงมักจะไม่ใช่เรื่องยาก
ในระยะสั้นคุณไม่มีปัญหาด้านความคล่องตัวหรือทางเทคนิคคุณมีปัญหาเรื่องคน ในการแก้ปัญหาผู้คนคุณต้องเข้าใจว่าเหตุใดทีมจึงเลือกสร้างคุณลักษณะด้วยวิธีนี้ ฉันหวังว่าโค้ชที่คล่องแคล่วหรือผู้เชี่ยวชาญด้านการต่อสู้ของคุณจะช่วยอำนวยความสะดวกในการสนทนานั้นได้ แต่ฉันคิดว่าฉันจะให้ความเป็นไปได้สองประการด้านล่างเพื่อให้คุณได้คิด โปรดระวังสิ่งเหล่านี้เป็นไปได้ทั้งคู่ วิธีเดียวที่จะทราบว่าเป็นหนึ่งในสิ่งเหล่านี้หรืออย่างอื่นคือการพูดคุยกับทีมอย่างดี
ความเป็นไปได้ 1: คุณกำลังเหยียบนิ้วเท้าของพวกเขา ผู้คนดูถูกได้ง่ายและในทางเทคนิค Scrum กล่าวอย่างชัดเจนว่าไม่มีใครสามารถบอกทีมพัฒนาได้ว่าจะทำงานอย่างไร สถานการณ์ที่คุณกำลังพูดถึงเป็นพื้นที่สีเทาเล็กน้อย แต่ถึงกระนั้นก็เป็นไปได้อย่างสมบูรณ์ที่คนอื่นบอกวิธีทำลายงานให้พวกเขาฟังว่า "คุณไม่รู้วิธีทำงานของคุณ"
ความเป็นไปได้ 2: วิธีการทำของพวกเขามีประสิทธิภาพมากกว่าเล็กน้อยและพวกเขาคิดว่าคุณจะขอให้พวกเขาทำทุกอย่างต่อไปเพื่อที่พวกเขาจะได้รับการต่อต้านน้อยที่สุด ในกรณีเหล่านี้อาจถูกต้องหรือคุณอาจต้องนำเสนอสถานการณ์ที่แตกต่างออกไปโดยที่คุณต้องการเพิ่มและดูใน 4 หรือ 5 พื้นที่ก่อนส่วนที่เหลือของฟังก์ชัน
อย่างที่ฉันพูดมีความเป็นไปได้มากมายเกินกว่าที่ฉันจะทำได้ สิ่งเหล่านี้เป็นเพียงส่วนหนึ่งที่จะช่วยให้คุณคิดตามแนวเหล่านั้น หวังว่า SM หรือโค้ช Agile ของคุณจะสามารถอำนวยความสะดวกในการสนทนาในหัวข้อนี้ได้
ฉันเป็นนักพัฒนาที่ทำงานกับรหัสเดิมเกี่ยวกับการต่อสู้และให้ฉันบอกคุณฉันคิดว่ามันถูกต้องในแบบของพวกเขาเพราะฉันทำแบบเดียวกัน ให้ฉันอธิบายกรณีของฉันโปรดทราบว่าฉันเป็นคนที่คิดว่าเป็นโปรแกรมเมอร์คาวบอย / แฮ็กเกอร์ :
TL.DR:
การทำลายทุกอย่างในรายการที่มีขนาดเล็กไม่ดีคุณจะพลาดรูปแบบและการโต้ตอบ : คุณกำลังแลกเปลี่ยนโอกาสในการมีรหัสตัวประกอบสำหรับฟังก์ชันเฉพาะหลายอย่างที่ทับซ้อนกันและสามารถแยกตัวประกอบได้ในภายหลัง (ไม่เคย) นั่นคือสาเหตุที่ซอฟต์แวร์เส็งเคร็งถือกำเนิดขึ้น
คุณกำลังมุ่งเน้นไปที่วิธีการแทนที่จะเป็นผลลัพธ์ : หากวิธีการนั้นได้ผลคุณภาพดีและจำนวนจุดบกพร่องต่ำเนื่องจาก PO มีอะไรผิดปกติ? คุณต้องปล่อยให้ผู้เชี่ยวชาญทำตามที่เห็นสมควร คุณไม่สามารถบังคับให้คนอื่นเปลี่ยนวิธีการของพวกเขาได้เพราะคุณไม่ชอบพวกเขา นั่นเป็นวิธีที่ผู้จัดการที่น่ากลัวเกิดมา
การมีคุณธรรมดีกว่าที่จะทำงานในโครงการขนาดใหญ่ที่มีจุดจบแทนที่จะต้องบดของชิ้นเล็ก ๆ ที่ไม่มีที่สิ้นสุด : เช่นเดียวกับคนงานในโรงงานของฟอร์ดที่ต้องทนทุกข์ทรมานการต่อสู้นั้นค่อนข้างจะทำลายจิตใจและลดความสำคัญลงด้วยวัฏจักรของสินค้าชิ้นเล็กชิ้นใหม่ที่ไม่มีที่สิ้นสุด ไม่เคยเป็นผลิตภัณฑ์เต็มรูปแบบ นั่นเป็นวิธีที่อัตราการเปิดมากกว่าสูงเกิด(อ้างอิงเป็นสิ่งจำเป็น)
คำตอบยาว ๆ (มีเบื้องหลัง)
เรามีโซลูชันซอฟต์แวร์ที่เขียนขึ้นในภาษาเฉพาะและการส่งสแปมโค้ด 1 ล้านบรรทัดขึ้นไปในหลายร้อยโมดูลและแอปพลิเคชัน ดังนั้นทุกครั้งที่ลูกค้า / PO / ใครบางคนถามว่า "ทำไมเราไม่ทำหน้าที่เล็ก ๆ นี้ที่นี่" และผู้เชี่ยวชาญด้านการต่อสู้ทำให้มันกลายเป็นอะตอมที่ไม่สามารถจดจำได้เราได้นำเสนอข้อบกพร่องในการโต้ตอบใหม่ซึ่งค่อนข้างยากที่จะแก้ไข วงจรของงานเล็ก ๆ ที่ไร้ความหมายไม่สิ้นสุดการแก้ไขข้อบกพร่องอย่างต่อเนื่องที่สามารถป้องกันได้และไม่รู้สึกถึงแรงจูงใจในการทำสิ่งดีๆค่อยๆทำให้นักพัฒนาของเราก้าวต่อไปจนกระทั่งเราจบลงด้วยเพียงคนเดียว: ฉัน
เมื่อเห็นได้ชัดว่าฉันจะเป็นหนูคนสุดท้ายบนเรือ (เรือฉันยังคงนึกถึงคุณ) ฉันทำอะไรโง่ ๆ แต่จำเป็น: ฉันศึกษาฐานรหัสทั้งหมด เมื่อในที่สุดฉันก็กลายเป็นคนเดียวที่สามารถทำงานกับรายการได้ฉันใช้วิธีที่มีประสิทธิภาพที่สุดในการแก้ไขสิ่งต่าง ๆ : บอกให้พวกเขาเลิกยุ่งฉันจะทำในแบบของฉันโดยมีรายการลำดับความสำคัญของฉันเองและถ้าพวกเขาไม่ชอบ พวกเขาสามารถยิงฉันและไปภายใต้หนึ่งเดือน
ก่อนอื่นฉันยกเลิกการประชุมเพราะฉันอยู่คนเดียวฉันไม่จำเป็นต้องให้คำอธิบายหรือประสานงานกับใคร จากนั้นฉันก็ยกเลิกรูปแบบการจัดส่งแบบวนซ้ำเพราะฉันไม่จำเป็นต้องแสดงความคืบหน้าและซอฟต์แวร์ที่ใช้งานได้ครึ่งหนึ่งก็ไม่มีประโยชน์ที่นี่ จากนั้นฉันก็ทิ้งการวิ่งเพราะต้องการส่งมอบผลิตภัณฑ์ที่มีคุณภาพอย่างรวดเร็วดังนั้นฉันจึงใช้เวลาในการทำให้มันถูกต้องตั้งแต่เริ่มต้น และด้วยสิ่งนั้นฉันพบบางสิ่งที่เรียบร้อยจริงๆ:
- ถ้าฉันอุทิศตัวเองเพื่อแก้ไขโมดูลทั้งหมดแทนที่จะเป็นกลุ่มของรายการในการทำซ้ำแต่ละครั้งฉันก็สามารถเขียนโค้ดที่เล็กลงมีประสิทธิภาพมากขึ้นและป้องกันข้อผิดพลาดที่ยังคงยืนอยู่
- กับทุกโมดูลทั้งหมดที่ฉันทำงานฉันสามารถเรียนรู้กำหนดมาตรฐานและแนวทางปฏิบัติที่ดีที่สุดที่ทำให้การโต้ตอบกับธุรกรรมมากกว่าการคาดเดา
- แม้ว่าฉันจะรู้สึกเจ็บปวดว่าถ้าฉันล้มเหลวทุกอย่างก็จะจบลงในช่วงเวลานั้นฉันรู้สึกมีแรงบันดาลใจและพอใจกับทุกโมดูลที่ถ่ายทอดสด ไม่ใช่แค่การส่งเสริมศีลธรรม แต่ฉันรู้สึกมีความสุขกับการทำงาน
เมื่อสิ่งต่างๆดีพอและเราเริ่มมีคนมากขึ้นวิธีการ "ยอมช่วยเรือ" ก็ได้รับการปรับเปลี่ยนตามธรรมชาติ:
- ฉันจำเป็นต้องประสานงานกับผู้คนดังนั้นเราจึงพัฒนานโยบาย "เปิดรับคำถามได้ตลอดเวลา" แทนการประชุมที่มีโครงสร้าง
- การส่งมอบซ้ำลงเอยด้วยการถูกแทนที่ด้วยการส่งมอบงานเต็มรูปแบบซึ่งปรับปรุงความเข้าใจของชิ้นส่วนทั้งหมดที่โต้ตอบกับมันและป้องกันข้อผิดพลาดได้มากขึ้นแทนที่จะเป็นงานแพทช์แบบวัฏจักร
- ทุกคนเข้าใจดีว่างานต้องใช้เวลาในการทำสิ่งที่ถูกต้องแทนที่จะพยายามทำให้มันพอดีกับกรอบเวลาที่กำหนด
ตอนนี้เรากำลังทะเลาะกันในชื่อเพราะมันเป็นเพียงการต่อสู้เว้นแต่ว่ามันจะขัดขวางการทำงาน
สิ่งนี้เกี่ยวข้องกับทีมของคุณอย่างไร :
ดูเหมือนว่าทีมของคุณจะได้ข้อสรุปเดียวกันกับที่ฉันทำการทำให้อะตอมมีปัญหามากกว่าที่จะแก้ได้ แล้วคุณจะทำอย่างไร?
มีหลายวิธีในการทำบางสิ่งและแต่ละคน / กลุ่มก็มีวิธีที่ดีที่สุดสำหรับพวกเขา ขอให้ชัดเจนเหตุผลเดียวที่ฉันไม่ถูกไล่ออกและเพื่อนร่วมงานทุกคนเกลียดชังมันเป็นเพราะสิ่งที่ฉันทำงาน (ตอนนั้นพวกเขาค่อนข้างเกลียดฉันนิดหน่อย); แต่นั่นเป็นความจริงสำหรับการต่อสู้และวิธีการใด ๆ เช่นกัน: ใช้เพียงเพราะให้ผลลัพธ์ที่เราพอใจ หากวิธีการทำงานของพวกเขาให้ผลลัพธ์ที่ดีและจำนวนจุดบกพร่องของคุณอยู่ภายใต้การควบคุมทำไมคุณถึงต้องการเปลี่ยนแปลง เพราะมันไม่ใช่แบบที่คุณชอบ? ฟังดูคล้ายกับสิ่งที่ผู้จัดการแย่ ๆ จะพูดแทน PO
หากบทบาทของคุณคือ PO งานเดียวของคุณคือบอกพวกเขาว่าคุณต้องการ / ต้องการอะไรในผลิตภัณฑ์ของคุณไม่ใช่ว่าจะทำอย่างไร หากสิ่งที่คุณต้องการคือผลิตภัณฑ์ที่ทำในแบบที่คุณคิดว่าควรทำแสดงว่าคุณไม่ใช่ PO คุณเป็นแค่ผู้จัดการที่ไม่ดีในเสื้อผ้าของ PO
คุณกำลังสมมติว่าคุณรู้ว่าอะไรดีที่สุดสำหรับทีมโดยไม่ต้องกังวลในการส่งมอบซอฟต์แวร์
ฉันเชื่อมั่นในวิธีการแบบว่องไวและการต่อสู้โดยเฉพาะ ฉันสนับสนุนแนวทางเรื่องราวของผู้ใช้แบบวนซ้ำอย่างเต็มที่ จากที่กล่าวมามีข้อยกเว้นที่ต้องพิจารณา:
- หากทีมกำลังทำงานกับผลิตภัณฑ์ที่มีอยู่หรือคุ้นเคยกับการทำงานกับผลิตภัณฑ์ที่มีอยู่แล้วพวกเขาอาจลังเลที่จะทำงานบางอย่างโดยรู้ว่าพวกเขาจะต้องทำการ refactor ในภายหลัง รู้สึกเหมือนเสียเวลาไปเปล่า ๆ
- เป็นเรื่องปกติในหลาย ๆ องค์กรที่คาดว่านักพัฒนาจะผลักดันฟีเจอร์ออกมาอย่างรวดเร็วพร้อมสัญญาว่าจะกลับมาและ "ทำถูกต้อง" ในภายหลังจากนั้นจะไม่มีเวลาให้ หากทีมงานมีประสบการณ์เช่นนั้นแม้จะทำงานที่ผ่านมาพวกเขาอาจถูกกำหนดเงื่อนไขให้ไม่ไว้วางใจการพัฒนาซ้ำ ๆ
การพัฒนาซ้ำถือว่ามีต้นทุนต่ำในการเปลี่ยนแปลง การพัฒนาซ้ำเป็นเรื่องของการปรับโครงสร้างใหม่ หากคุณปรับโครงสร้างใหม่ทุกวันแสดงว่าคุณทำถูกแล้ว แต่ถ้าคุณปรับโครงสร้างใหม่อยู่ตลอดเวลาคุณจะไม่ใช้เวลาทั้งหมดในการทดสอบการถดถอยหรือไม่? Agile ทำงานได้ดีเมื่อคุณสามารถเปลี่ยนรหัสเรียกใช้การทดสอบและมั่นใจได้ว่าคุณไม่ได้ทำอะไรผิดพลาด ทีมงานต้องมีประสบการณ์เพื่อที่จะเชื่อในสิ่งนั้น และเป็นการยากอย่างยิ่งที่จะอบความสามารถในการทดสอบแบบนั้นลงในผลิตภัณฑ์ที่มีอยู่
ดังนั้นคำแนะนำของฉันคือพูดคุยกับทีมและทำความเข้าใจกับความลังเลใจของพวกเขา ดูว่าคุณสามารถช่วยอะไรได้บ้าง ค้นหาว่ามีใครในทีมที่มีประสบการณ์ในการทำงานซ้ำแล้วซ้ำเล่าที่สามารถเป็นพันธมิตรของคุณได้
จากมุมมองของนักพัฒนา
ตัวอย่างที่คุณใช้: 'Users Grid', with everything written in (search, filter, sort, add/edit users
เพื่อให้บรรลุผลข้างต้นเฟรมเวิร์กจำนวนมากมีเครื่องมือในตัว (เช่น Yii2 Gii) และจะสร้างตารางในเวลาไม่กี่นาที ตอนนี้ถ้าคุณต้องการแยกมันออกจะต้องใช้เวลามากขึ้นเนื่องจากนักพัฒนาต้องเข้าไปและลบคุณสมบัติออกและเพิ่มเข้าไปใหม่ในภายหลัง การทำตามวิธีนั้นจะเป็นเรื่องน่าหงุดหงิด
ดังนั้นอาจจะคุยกับพวกเขาและถามว่าทำไมพวกเขาถึงคัดค้าน หากเหตุผลเป็นอย่างที่กล่าวมาข้างต้นให้เปลี่ยนวิธีการของคุณเล็กน้อยเพื่อให้ทั้งคุณและทีมได้พบกับพื้นๆ
สิ่งที่คุณมีที่นี่เป็นความขัดแย้ง คุณชอบทำสิ่งต่างๆทางเดียวทีมเทคนิคจึงชอบทำสิ่งต่างๆ ดังนั้นวิธีแก้ไขคือถามว่าทำไม? . และไม่ใช่แค่ว่าทำไมพวกเขาถึงชอบในแบบของพวกเขา แต่ทำไมคุณถึงชอบในแบบของคุณด้วย
บางทีพวกเขาอาจถูกกำหนดไว้ในแบบของพวกเขาและคุณก็ถูกกำหนดไว้ในของคุณ บางทีพวกเขาอาจไม่เข้าใจสิ่งที่ Agile ทั้งหมดนี้และมองไม่เห็นประเด็น บางที Scrum อาจดูเหมือนโง่ บางทีพวกเขาอาจจะไม่ชอบวิธีที่คุณแบ่งเรื่องราว บางทีคุณอาจจะไม่ดีในการแยกเรื่องราว บางทีพวกเขาอาจมีข้อมูลเชิงลึกเกี่ยวกับผลิตภัณฑ์และคิดว่าดีกว่าที่จะทำในแบบของพวกเขา คุณเป็น PO แต่บางทีคุณควรเปิดรับความคิดเห็นของพวกเขามากกว่านี้ บางทีพวกเขาอาจจะไม่ชำนาญทางเทคนิคมากนักและพวกเขาก็กังวลว่าพวกเขาจะทำเรื่องยุ่ง ๆ โดยไม่รู้ว่าจะแยกงานอย่างไรให้ถูกต้องเพื่อให้มีการพัฒนาเพิ่มขึ้นดังนั้นพวกเขาจึงพยายามรวบรวมทุกอย่างไว้ด้วยกัน "อาจจะ" เป็นจำนวนมากเพราะฉันพยายามเดาว่าเกิดอะไรขึ้นจากสิ่งที่โพสต์ไว้ที่นี่ แต่ฉันแน่ใจว่าคุณอาจตั้งสมมติฐานคล้าย ๆ กันก่อนที่จะได้ข้อสรุปและถามคำถามนี้
ดังนั้นจัดการประชุมกับทุกคนและพูดคุยเรื่องต่างๆ วัตถุประสงค์ของการประชุมครั้งนี้คือการเข้าใจซึ่งกันและกันและรับที่ด้านล่างของปัญหา เท่านั้นแล้วคุณสามารถหาวิธีการแก้ปัญหาที่เหมาะกับทุกคน การบอกพวกเขาว่าคุณต้องการให้พวกเขาทำงานด้วยวิธีที่คล่องตัวมากขึ้นจะไม่มีความหมายอะไรสำหรับพวกเขาเว้นแต่พวกเขาจะเข้าใจว่าทำไมจึงจำเป็น
โค้ช SM / Agile สามารถไกล่เกลี่ยสิ่งต่าง ๆ และตรวจสอบให้แน่ใจว่าการพูดคุยอยู่ในระดับที่เหมาะสมและน่านับถือ แต่ต้องเป็นการประชุมแยกกันไม่ใช่ส่วนหนึ่งของเหตุการณ์ Scrum การย้อนหลังเป็นสถานที่ที่จะมีการอภิปรายเช่นนี้ แต่เห็นได้ชัดจากคำถาม OPs ว่าการย้อนหลังไม่ได้ทำงานอย่างถูกต้อง (ทีมงานกลับไปใช้วิธีเดิม ๆ ในนาทีที่ SM ไม่ได้มองหามีการต่อต้านแนวคิด และสิ่งนี้เกิดขึ้นเป็นเวลานานมากจน OP ยอมแพ้และยินดีที่จะทำงานกับน้ำตกขนาดเล็กแม้จะมีความเสี่ยงต่อโครงการและลูกค้าก็ตาม) การประชุมแยกกันเป็นการส่งสัญญาณเพิ่มเติมเกี่ยวกับน้ำหนักของสถานการณ์ ผู้คนต้องเข้าใจว่า " ข้อตกลงนี้ไม่ได้ผลสำหรับทุกคน " เมื่อผู้คนเข้าใจถึงน้ำหนักของสถานการณ์ปัญหาจะถูกย่อยสลายและพบต้นตอของความไม่เห็นด้วยจากนั้นจะทำอะไรบางอย่างได้ ไม่เช่นนั้นใครก็ตามทั้งสองฝ่ายสามารถรับรู้สิ่งต่างๆเช่น " เป็นเพราะมีคนพูดหรือต้องการอย่างนั้น "
รู้สึกนิดหน่อยสำหรับฉันเหมือนทั้งคุณและทีมงานขาดจุดเดียวกัน ไม่ใช่เรื่องง่ายที่จะสร้างหรือทดสอบ แต่ไม่เกี่ยวกับการเพิ่มขึ้นเพื่อประโยชน์ของมัน แต่เป็นการส่งมอบคุณค่าที่เหมาะสมในเวลาที่เหมาะสม
คุณกำลังเข้าใกล้เป้าหมายการวิ่งของคุณอย่างไร? คุณได้กล่าวถึงการจัดลำดับความสำคัญตามลำดับความสำคัญและมูลค่า แต่คุณกำหนดเป้าหมายการวิ่งที่ชัดเจนหรือไม่? คุณมีเป้าหมายทางธุรกิจที่ชัดเจนหรือไม่? คุณปล่อยให้เลือกขั้นตอนการทำงานจากเป้าหมายที่ตั้งไว้สำหรับการวิ่งหรือว่ามีงานค้างอยู่จำนวนมากและคุณกำลังทำตามขั้นตอนของคุณเอง?
ถ้าเป็นอย่างหลังฉันสามารถจินตนาการได้ว่านักพัฒนากำลังคิดแบบที่พวกเขากำลังทำอยู่ตอนนี้ หากไม่มีเหตุผลที่แท้จริงในการส่งมอบสิ่งใดสิ่งหนึ่งในตอนนี้หรือการวิ่งครั้งต่อไปการรวมพื้นที่ใช้งานได้ง่ายขึ้นและนำเสนอคุณลักษณะใหม่ ๆ ที่เกิดขึ้นอย่างสมบูรณ์
แต่ถ้ามีเป้าหมายที่เฉียบคมเมื่อถึงจุดหนึ่งคุณต้องคุยว่า "เราจะไปถึงเป้าหมายนี้ได้อย่างไร" และคุณจะรู้ว่าคุณไม่สามารถส่งมอบคุณสมบัติด้านที่ไม่จำเป็นทั้งหมดเพื่อบรรลุเป้าหมายการวิ่งได้และทุกคนจะรู้ว่าการบรรลุเป้าหมายเป็นสิ่งสำคัญจากนั้นคุณสามารถพูดคุยเกี่ยวกับการแยกองค์ประกอบและการสร้างสิ่งที่สำคัญ สิ่งแรกและสิ่งที่ไม่สำคัญมากหลังจากที่บรรลุเป้าหมาย
หากไม่มีเป้าหมายสำคัญที่จะต้องทำก็ไม่มีวิธีใดดีไปกว่าอีกวิธีหนึ่งเพราะหากไม่มีเป้าหมายในการวิ่งทุกสิ่งที่คุณทำจะลดลงเหลือเพียงการทำงานที่ยุ่งและไม่มีวิธีใดที่ดีที่สุดในการทำงานที่ยุ่งให้สำเร็จ
เมื่อผู้คนมีความต้านทานต่อการเปลี่ยนแปลงมากมักจะมีพฤติกรรมป้องกันและนั่นคือเหตุผลที่สำคัญที่สุด คุณต้องถาม
ปฏิกิริยาทันทีฉันคือการที่พวกเขาดูเหมือนจะสร้างในจำนวนมากของการตรวจสอบเข้าไปในงานที่คุณรับรู้ว่าเป็นน้ำตกขนาดเล็ก
เมื่อทีมสร้างผู้ใช้ใหม่ด้วยตนเองใน SQL พวกเขามีโอกาสทำอะไรอีกบ้าง? พวกเขากังวลเกี่ยวกับผลกระทบของคนอื่นที่สร้างผู้ใช้หรือไม่? บางครั้งขั้นตอนแบบแมนนวลรวมถึงการตรวจสอบที่ต้องสร้างโค้ดจำนวนมาก
ดูเหมือนคุณจะใช้วิธีการทั่วไปในการแบ่งสิ่งต่างๆออกเป็นส่วน ๆ ของฟังก์ชันการทำงานในแนวนอน อาจเป็นเพราะพวกเขาได้เรียนรู้วิธีที่ยากมากซึ่งนำไปสู่ข้อบกพร่องและปัญหาอื่น ๆในบริบทของฐานรหัสนี้
อาจมีปัญหาทางการเมืองหรือความทรงจำเช่นนี้ในองค์กรที่พวกเขาเคยมีประสบการณ์ที่เลวร้ายมากจากการนำเสนอคุณลักษณะที่คาดหวังเพียงบางส่วน
ดังนั้นหากคุณต้องการนำเสนอทีละน้อยคุณสามารถคงชุดคุณสมบัติที่มีอยู่มากมาย แต่ส่งมอบเวอร์ชันที่เรียบง่ายขึ้นทีละน้อยได้หรือไม่? UI สามารถเรียบง่ายขึ้นอย่างมากได้หรือไม่?
การทำงานนั้นง่ายกว่าในการพัฒนาและทดสอบว่าเพิ่มขึ้นหรือไม่
ไม่เสมอไป คุณมีประสบการณ์โดยตรงกับโดเมนนี้หรือโค้ดเบสเฉพาะที่อนุญาตให้คุณเป็นผู้มีอำนาจในเรื่องนี้หรือไม่?
ฉันเกลียดคำเปรียวเพราะมันเป็นเรื่องเกี่ยวกับการตัดสินมากเมื่อคุณกำลังบอกคนที่พวกเขาจะไม่เป็นเปรียว
ฉันเป็นนักพัฒนาซอฟต์แวร์มาเกือบ 40 ปีแล้วและในฐานะที่เป็นคนที่สนใจเครื่องมือและเทคนิคอย่างลึกซึ้งสังเกตการเติบโตของการส่งมอบที่เพิ่มขึ้นและการกำเนิดของAgile Movement ฉันยังทำงานกับฐานรหัสที่ซับซ้อนเช่น 3D CAD ที่มี C ++ มากกว่า 1M บรรทัด ฉันชอบการจัดส่งแบบเพิ่มหน่วย แต่ก็รู้ว่ามันไม่เหมาะสมเสมอไป
ที่อยู่เวลาชกมวยและวัฒนธรรมองค์กร
แนวคิดเรื่อง "การทำงานซ้ำ" เป็นเรื่องยุ่งยากเมื่อใช้วิธีการพัฒนาแบบวนซ้ำ ในเฟรมเวิร์กแบบเดิมสิ่งอื่นใดที่นอกเหนือจากการทำครั้งเดียวจะถือว่าเป็นข้อบกพร่องหรือความล้มเหลวในส่วนของทีมพัฒนา ความจริงก็คือกรอบการทำงานที่คล่องตัวยอมรับการเปลี่ยนแปลงและการทำงานซ้ำและการปรับโครงสร้างจำนวนหนึ่งเป็นการแลกเปลี่ยนที่รู้จักกันดีสำหรับวงจรการตรวจสอบและปรับเปลี่ยนที่บ่อยขึ้น
การตรวจสอบให้แน่ใจว่าทั้งทีม (และองค์กรที่อยู่ภายใน) เข้าใจจุดประสงค์ของการชกมวยเวลาตลอดจนคุณค่าอรรถประโยชน์ของการตรวจสอบผลิตภัณฑ์และกระบวนการพัฒนา / การจัดส่งเป็นประจำไม่ใช่งานของเจ้าของผลิตภัณฑ์ มันเป็นของ Scrum Master อย่างถูกต้องซึ่งได้รับการสนับสนุนจากองค์กรแม่และโค้ชใด ๆ ที่อาจได้รับมอบหมายเพื่อให้การเปลี่ยนแปลงง่ายขึ้น
ในระยะสั้นนักพัฒนาซอฟต์แวร์จำนวนมากที่เพิ่งเริ่มใช้งาน Scrum จำเป็นต้องรู้สึกปลอดภัยในการนำกระบวนการพัฒนา / การส่งมอบที่ส่งเสริมการออกแบบที่เกิดขึ้นโดยธรรมชาติแทนที่จะเป็นการออกแบบที่มีขนาดใหญ่และตรงไปตรงมา (BUFD) ในฐานะที่เป็นกระบวนการควบคุมเชิงประจักษ์ Scrum ทำให้เกิดค่าใช้จ่ายจำนวนมากและการทำงานซ้ำซึ่งจะก่อให้เกิดการตำหนิการชี้นิ้วและการกระทำที่ไม่พึงประสงค์ของบุคลากรในองค์กร BUFD จนกว่าทั้งทีมจะมั่นใจว่าสิ่งนี้จะไม่เกิดขึ้นพวกเขาจะไม่เชื่อในการเปลี่ยนแปลงรูปแบบการทำงานที่ให้บริการพวกเขาได้ดีในอาชีพการงานจนถึงตอนนี้
การดำน้ำที่ลึกขึ้น: การปรับกรอบการสนทนาใหม่
เหตุผลของฉันคือการทำงานนั้นง่ายต่อการพัฒนาและทดสอบว่าเพิ่มขึ้นหรือไม่ ช่วยลดความเสี่ยงเราสามารถแสดงสิ่งต่างๆให้ลูกค้าทราบก่อนหน้านี้และรับข้อเสนอแนะก่อนหน้านี้ ในขณะที่สำหรับพวกเขามันง่ายกว่าถ้าเราไม่รวบรวมงานและส่งมอบสิ่งต่างๆให้เสร็จสิ้นในทันที
การไม่ทำงานเป็นชิ้นส่วนจะไม่ส่งมอบอะไรเลย "ทันที" จากนั้นอีกครั้งกระบวนทัศน์ที่เพิ่มขึ้นและวนซ้ำมักจะส่งมอบชิ้นส่วนแทนที่จะเป็นคุณลักษณะที่เต็มเปี่ยมในคราวเดียว ไม่ว่าในกรณีใดทั้งสองฝ่ายดูเหมือนจะพูดคุยเกี่ยวกับคำถามพื้นฐานที่ว่าการต่อยเวลาที่มีอยู่ใน Scrum ช่วยเพิ่มมูลค่าให้กับกระบวนการหรือผลิตภัณฑ์ปัจจุบันของคุณหรือไม่
ไม่มีใครนอก บริษัท ของคุณสามารถกำหนดสิ่งนี้ได้จริงๆ อย่างไรก็ตามคุณควรทำงานร่วมกับโค้ชที่มีความคล่องตัวของคุณเพื่อวางกรอบสิ่งนี้ให้แตกต่างจากการอภิปราย "เสาหินเทียบกับส่วนเพิ่ม" ในปัจจุบันที่คุณและทีมกำลังมีอยู่
ในฐานะเจ้าของผลิตภัณฑ์คุณเป็นสมาชิกของทีม Scrum สิ่งนี้ จำกัด จำนวนผู้มีอำนาจ (โดยเฉพาะไม่มีใครอยู่เหนือทีมพัฒนา) และอิทธิพล (มากที่สุดเท่าที่คุณสามารถให้ได้) ที่คุณมีในกระบวนการ Scrum อย่างไรก็ตามคุณยังเป็นผู้ควบคุม Product Backlog โปรดทราบว่าบทบาทคู่ของคุณเป็นทั้งเจ้าของผลิตภัณฑ์และสมาชิกในทีม Scrum สามารถช่วยให้คุณวางกรอบการสนทนาได้แตกต่างกัน โดยเฉพาะอย่างยิ่งคุณควร:
จัดการ Backlog ของผลิตภัณฑ์อย่างแข็งขันเพื่อให้แน่ใจว่าคุณจัดลำดับความสำคัญของรายการค้างที่ (อย่างน้อยตามแนวคิด) พอดีภายในการทำซ้ำครั้งเดียว
ทำงานร่วมกับ Scrum Master และทีมพัฒนาเพื่อตั้งความคาดหวังว่าเป้าหมาย Sprint ที่ตกลงกันจะต้องเสร็จสิ้นภายใน Sprint เดียว
โดยกำหนดกรอบการสนทนาว่า "เราจะใส่อะไรลงไปในกล่องครั้งต่อไปได้อย่างมั่นใจ" แทนที่จะเป็น "คุณควรทำงานเพิ่มขึ้น!" คุณจะเปลี่ยนกรอบการสนทนาจากหัวข้อหนึ่งว่าจะทำงานทีละน้อยเกี่ยวกับวิธีแบ่งส่วนงานอย่างไร มุ่งเน้นไปที่สิ่งที่คุณต้องการ (เช่นลูปข้อเสนอแนะในการตรวจสอบและปรับเปลี่ยนอย่างรวดเร็วซึ่งสามารถแสดงให้ลูกค้าเห็นได้ว่าเป็นงานระหว่างทำ) แทนที่จะเป็นวิธีที่ทีมควรทำให้สำเร็จ
Scrum Master และโค้ช Agile ควรทำงานร่วมกับคุณและทีมเพื่ออธิบายมุมมองทางธุรกิจ (หากจำเป็น) รวมทั้งเสนอเทคนิคที่ใช้ได้จริงหากทีมกำลังดิ้นรนกับการพัฒนาตามเวลา อย่างไรก็ตามคุณและ Scrum Master ต้องทำงานร่วมกันอย่างแข็งขันเพื่อให้แน่ใจว่าทีมพัฒนามีโอกาสที่จำเป็นในการทำงานซ้ำและปรับโครงสร้างใหม่เมื่อ Backlog ของผลิตภัณฑ์มีการเปลี่ยนแปลง
การแยกส่วนและการย่อยสลายคุณสมบัติอาจเป็นเรื่องยุ่งยากและจะนำมาซึ่งการลองผิดลองถูกมากมายก่อนที่ทีมจะได้รับประสบการณ์และกระบวนการครบกำหนดเพื่อดำเนินการในช่วงความเชื่อมั่น 60-80% เว้นแต่ทีมจะได้รับแรงจูงใจ (ไม่ว่าจะด้วยตนเองหรือจากภายนอก) ให้ทุ่มเทและมั่นใจว่าพวกเขามีโอกาสที่ปลอดภัยในการเรียนรู้โดยการลองผิดลองถูก (โดยเน้นที่ "ข้อผิดพลาด") โดยไม่มีผลเสียเพียงแค่ยอมรับ เครื่องประดับของ Scrum จะไม่ประสบความสำเร็จ
การคาดหวังความสำเร็จจากแฟชั่นการบริหารคือลัทธิดิลแบร์ต กรอบเปรียวเช่นการต่อสู้เท่านั้นที่มีประสิทธิภาพเมื่อใช้โดยเพิ่มขีดความสามารถและทีมงานด้วยตนเอง actualizing การกำหนดกรอบการทำงานแบบว่องไวสำหรับนักอนุรักษนิยมที่ไม่ได้แปลงกลับเป็นรูปแบบหนึ่งของ Buzzword Management ™และเป็นเหตุผลอันดับหนึ่งที่ฉันเห็นว่าการใช้งานแบบ "คล่องตัว" ล้มเหลว เพื่อให้ประสบความสำเร็จ Scrum ต้องได้รับการยอมรับจากทั้งทีม Scrum องค์กรแม่และลูกค้า / ผู้มีส่วนได้ส่วนเสีย / ผู้สนับสนุนโครงการ
การช่วยให้ผู้ทำงานร่วมกันแต่ละคนในกระบวนการค้นพบคุณค่าของกรอบงานเนื่องจากเกี่ยวข้องกับผิวของตนเองในเกมไม่ใช่สิ่งที่คุณควรต้องทำด้วยตัวเอง เรียนรู้เกี่ยวกับ Scrum Master ของคุณและคนอื่น ๆ อย่างมากเพื่อทำให้ปัญหาการนำกระบวนการมาใช้มีความโปร่งใสและมองเห็นได้เพื่อให้สามารถแก้ไขได้อย่างสร้างสรรค์
(ค้นหากรองเรียงลำดับเพิ่ม / แก้ไขผู้ใช้ ฯลฯ )
จากมุมมองของนักพัฒนา:
- การแสดงรายการโดยไม่สามารถเพิ่มรายการนั้นไร้ประโยชน์ดังนั้นนี่คือสิ่งแรกของคุณ
- มาสก์สำหรับแก้ไขไอเท็มอาจจะเหมือนกับมาสก์สำหรับเพิ่มไอเท็ม
ดังนั้นนี่จึงเป็นการวิ่งครั้งแรกสำหรับฟังก์ชัน CRUD
- โดยปกติการค้นหาคำหลักเป็นเพียงตัวกรองอื่นที่ใช้กับแบบสอบถามฐานข้อมูล
ดังนั้นจึงเหมาะสมที่จะพัฒนาฟังก์ชันการค้นหาและกรองร่วมกันในการวิ่งครั้งที่สอง
- การเรียงลำดับอาจอยู่ในประเภทดั้งเดิมจากนั้นก็ง่ายหรืออาจเกี่ยวข้องกับอัลกอริทึมที่ยากจากนั้นก็สมเหตุสมผลที่จะทำแบบแยกส่วน
นั่นเป็นวิธีที่ฉันจะแยกงานออก แต่ฉันไม่เห็นจุดที่จะส่งมอบหลังจากการวิ่งแต่ละครั้ง จะต้องสามารถนำไปใช้ได้จริง แต่ไม่ได้หมายความว่าคุณจัดส่งหรือตรวจสอบกับลูกค้า ดูสิเรามีรายการ โอ้ดูตอนนี้มันสามารถค้นหา แล้วตอนนี้ .. คุณตื่นยัง? สวัสดี? ฉันคิดว่าลูกค้าส่วนใหญ่ของเราจะแนะนำรีวิวหนึ่งรายการหลังจากที่ของพร้อมแล้ว นอกจากนี้ยังเป็นเรื่องที่น่าอึดอัดเล็กน้อยที่เราจะนำเสนอฟังก์ชันเล็ก ๆ น้อย ๆ เพราะทุกคนคิดว่า "นั่นคือทั้งหมดที่คุณทำในการวิ่ง" สนุกกว่ามากในการคลิกผ่านฟีเจอร์เต็มรูปแบบและแสดงสิ่งต่างๆที่คุณทำได้ในคราวเดียว .
จากประสบการณ์ฉันไม่คิดว่าจะเปลี่ยนข้อเสนอแนะที่ชาญฉลาดสำหรับหน้าจอ CRUD ที่เรียบง่ายมากนักอาจจะมีลักษณะการออกแบบหรือเค้าโครงบางอย่างที่สามารถแก้ไขได้หลังจากการตรวจสอบครั้งแรก สำหรับส่วนที่ใหญ่กว่าของโปรเจ็กต์คุณควรแยกมันออกและรับการตรวจสอบล่วงหน้าสมมติว่าหน้าจอการจัดการรายการที่คุณอธิบายหน้าจออื่น ๆ ที่รายการโต้ตอบหรือหน้ารายงานที่คุณสามารถพิมพ์สิ่งต่างๆได้ สิ่งเหล่านี้เป็นเอนทิตีแยกต่างหากและควรได้รับการพัฒนาในการวิ่งแบบแยกส่วน
นอกจากนี้ยังขึ้นอยู่กับเทคโนโลยีและแพลตฟอร์มที่คุณใช้จำนวนคนที่มีส่วนร่วมในการพัฒนาความพร้อมใช้งานและการประสานงานที่จำเป็นเพื่อให้บางสิ่งเสร็จสมบูรณ์ในการวิ่ง
คุณต้องถามทีมว่าจะแบ่งงานอะไรได้อย่างมีประสิทธิภาพและทำงานจากที่นั่น บางทีพวกเขาอาจต้องการสภาพการทำงานที่แตกต่างกัน
Scrum ยังหมายความว่าพวกเขาทั้งหมดทำงานในสิ่งเดียวด้วยกันเป็นไปได้หรือไม่? บางทีพวกเขาอาจต้องการตัวบล็อกในโครงการที่เข้ามาอื่น ๆ บางทีพวกเขาอาจต้องการเครื่องมือที่ดีกว่านี้?
หาปัญหาที่แท้จริงแล้วแก้ไขด้วยกัน