การมีคนที่มีหลายบทบาทในทีมการต่อสู้เป็นเรื่องดีหรือไม่?


9

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

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

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

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

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


2
เริ่มต้นกับทีมของคุณที่มีการประชุมแบบสแตนด์อัพเพื่อหารือเกี่ยวกับเซสชันส่วนตัวทั้งหมดกับ CIO เพื่อให้อยู่ในหน้าเดียวกัน ขอให้โชคดีกับการป้องกันไม่ให้วิ่ง
JeffO

คำตอบ:


13

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

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

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

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

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

มันไม่ควรที่จะทำงานอย่างนั้น

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

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

นี่ไม่ใช่เงินเดือนของทีมโครงการพัฒนาซอฟต์แวร์

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


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

1
@ WayneM ทุกคนสามารถกษัตริย์ม้าและกษัตริย์ทั้งหมดทำให้ humpty dumpty กลับมารวมกันอีกครั้งเมื่อพระราชาเป็นคนโง่จัดการไมโคร? ประสบการณ์ทั่วไปของฉันบอกฉันไม่ สภาพแวดล้อมนี้ไม่เอื้อต่อการเขียนซอฟต์แวร์ในโครงการ หากคุณต้องการประสบการณ์ที่ดีในการทำงานกับทีมโปรเจ็กต์จากนั้นเริ่มมองไปรอบ ๆ เพราะคุณจะไม่พบมันที่นั่น
maple_shaft

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

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

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

6

ดังที่ฉันได้กล่าวไว้ที่นี่ถ้าทั้ง Scrum Master หรือเจ้าของผลิตภัณฑ์มีภารกิจที่ต้องดำเนินการพวกเขาก็เป็นสมาชิกของทีมด้วย

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


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

1

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


1

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

เจ้าของผลิตภัณฑ์ควรอยู่นอกทีมพัฒนาเนื่องจากอาจมีความขัดแย้งทางผลประโยชน์ที่ไม่ดีเกิดขึ้นที่นี่ Scrum Master อาจเป็นนักพัฒนาแม้ว่าจะไม่มีความขัดแย้งในกรณีนี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.