การจัดการขนาดเล็กแบบใหม่นั้นเปรียวไหม?


80

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

ในที่สุด บริษัท ของฉันได้เริ่มต้นในการผสมผสานการปฏิบัติที่คล่องตัวและเริ่มต้นด้วยทีมนักพัฒนา 4 คนในกลุ่มเปรียวบนพื้นฐานการทดลอง เป็นเวลา 4 เดือนกับการทำซ้ำ 3 ครั้งและพวกเขายังคงทำต่อไปโดยไม่ต้องทำตัวให้คล่องสำหรับพวกเราที่เหลือ เนื่องจากความเชื่อมั่นของผู้บริหารที่จะตอบสนองความต้องการทางธุรกิจด้วยคำขอประเภทแอดฮอพเล็กน้อยจากด้านบน

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

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

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

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

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


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

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

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

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


71
ฉันเคยเห็นการละเมิดในนามของความคล่องตัวมากกว่าที่ฉันสนใจที่จะแสดงความคิดเห็น หลายครั้งที่ "เราทำตัวคล่องแคล่ว" หมายถึง "เรากำลังละทิ้งกระบวนการและทำสิ่งที่เราต้องการ Yeehaw!" (สำหรับการอ้างอิงคาวบอยชัดเจน) สภาพแวดล้อมที่เงียบสงบช่วยได้แน่นอน แต่คุณต้องอนุญาตให้นักพัฒนาพูดคุยกันและจัดการกับสิ่งต่าง ๆ โดยไม่ต้องมีการอนุมัติจากเผด็จการ
Berin Loritsch

28
คุณไม่ได้ทำเปรียว ...
CaffGeek

13
นี่เป็นคำพูดจริงๆ ไม่ใช่คำถาม
JohnFx

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

9
การอ่านที่จำเป็น: การประกาศ Agile Half-Arsed "เราเคยได้ยินเกี่ยวกับวิธีการใหม่ในการพัฒนาซอฟต์แวร์โดยจ่ายที่ปรึกษาและอ่านรายงานของ Gartner ... "
gnat

คำตอบ:


89

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


7
สิ่งเดียวที่ฉันพบได้คือโพสต์ "Joel on Software" ใน 12 อันดับแรกที่ทุก บริษัท ควรจัดเตรียมสำหรับโปรแกรมเมอร์ของพวกเขา หนึ่งใน 12 คนเป็นที่ทำงานที่เงียบสงบ ฉันสงสัยว่า Joel Spolsky มีความหมายเช่นนี้
Berin Loritsch

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

5
@ เควินแค็ ธ คาร์ทเราอยู่ในข้อตกลงที่รุนแรงในเรื่องนั้น ตอนนี้ฉันอยู่ใน บริษัท ที่ตรงข้ามเป็นจริง เรามีคน 40 คนอยู่ในอุปการะพร้อมโต๊ะเปิดและไม่มีก้อน ทีมเดียวที่สามารถทำได้ทุกอย่างคือทีมที่ทำเสียงดังได้ นั่นคือประเภทของสภาพแวดล้อมที่คุณต้องการป้องกัน
Berin Loritsch

8
@Kevin - แผนกพัฒนาของฉันเป็นฟาร์มกุฏิแบบเปิดอยู่ถัดจากอาร์เรย์ของสามระฆังที่มีชื่อว่า "ลดราคา", "ขายใหญ่" และ "ขายมาก" สองสามครั้งต่อวันพนักงานขายส่งเสียงดังและตะโกนว่า "wooooo!" : - \
Dan Ray

2
@Dan ฉันมีการสัมภาษณ์ไม่กี่ปีก่อนที่สาม startups บอกฉันว่าพวกเขาต้องย้ายพวกขายออกจาก devs เพราะพวกเขาเกินไป! @ # $ ing ดัง
Erik Reppen

46

พวกเขาไม่ได้รับอนุญาตให้พูดคุยกับนักพัฒนาคนอื่นโดย Scrum master ของพวกเขาและไม่ได้รับอนุญาตให้รับโทรศัพท์ใด ๆ ในพื้นที่ทำงาน

นี่ไม่ใช่ส่วนหนึ่งของการปฏิบัติแบบ Agile - และเป็นประเด็นแยกต่างหาก

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


29
เป็นสิ่งที่ขัดกับหลักการแรกของการประกาศความคล่องตัว: "บุคคลและการมีปฏิสัมพันธ์กับกระบวนการและเครื่องมือ" ดูagilemanifesto.orgสำหรับข้อมูลเพิ่มเติม
Berin Loritsch

"เป็นสิ่งที่ขัดกับหลักการแรกของ <XXX> แถลงการณ์"; แทนที่อะไรก็ได้สำหรับ XXX และคุณจะมีทางเลือกที่คุณต้องการ ;-) อย่างจริงจังนี่ไม่ทำให้คุณแปลกใจใช่ไหม
CesarGon

5
@ CesarGon ในกรณีนี้เรากำลังพูดถึงหลักการของสิ่งที่ทำให้การทำงานคล่องตัว หากคุณไม่สามารถอธิบายหลักการหลักของความคล่องตัวได้บางทีคุณอาจไม่ต้องการความคล่องตัว ค่อนข้างง่าย ฉันไม่ได้พูดว่า "เปลี่ยนไปเชื่อ" ฉันกำลังพูดว่า "ทำในสิ่งที่คุณพูดว่าคุณเชื่อ" อย่างจริงจังนั่นไม่ทำให้คุณแปลกใจ?
Berin Loritsch

1
@ CesarGon สิ่งที่ OP อธิบายไว้เกี่ยวกับขั้วตรงข้ามของเจตนาของแนวทางนั้นเท่าที่จะทำได้ คุณคิดว่าเสียงกลางของคุณใกล้พอแล้ว วิธีที่คุณพูดมันฟังดูเหมือนความแตกต่างระหว่างเสียงอยู่ที่ 95% ใกล้พอ C'mon และให้เครดิตฉัน ฉันทำงานในโลกแห่งความเป็นจริงและกำหนดกระบวนการในองค์กรมาเป็นเวลานาน ฉันเข้าใจดีว่ามีอะไรใกล้พอ - และสิ่งที่ OP อธิบายไม่ได้
Berin Loritsch

2
@Berin Loritsch: ฉันให้เครดิตคุณ มันไม่ใช่ความตั้งใจของฉันที่จะปรากฏเป็นอย่างอื่น คำพูดเริ่มต้นของฉันเกี่ยวกับลัทธิพยายามที่จะฟังบางส่วนล้อเล่นจริง ประเด็นที่ฉันพยายามทำก็คือเราไม่จำเป็นต้องใช้สองสามบรรทัดในการแถลงเพื่อปกป้องสิ่งที่โจ่งแจ้งจากสามัญสำนึก OP อธิบายถึงสถานการณ์ที่ทำให้เกิดเสียงสัญญาณเตือนภัยทั้งหมด ฉันหวังว่าคุณจะใช้มันอย่างดี ขอโทษถ้าฉันรุนแรงเกินไป :-)
CesarGon

31

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


24

สภาพแวดล้อมที่คุณอธิบายเสียงเหมือนสวนหลากหลายพล่ามหลอกเปรียว

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

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

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

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


4
+1 Agile / scrum / xp หรืออะไรก็ตามที่เป็นเพียงคำว่า "mumbo jumbo" สำหรับร้านค้าไอทีที่ไม่ใช่ บริษัท ซอฟต์แวร์จริง อย่างที่คุณพูดไม่มีใครเปลี่ยนแปลงอย่างรุนแรงในขณะที่ฝังหัวของพวกเขาลงบนพื้นทรายด้วยวิธีการเหล่านี้ สิ่งหนึ่งที่ต้องอ่านคือการพัฒนาซอฟต์แวร์แบบลีนที่ยอดเยี่ยม: Agile Toolkitและวาง BS ทั้งหมดไว้ข้างหลัง การปฏิบัติเหล่านี้ไม่ได้มีไว้สำหรับร้านค้าไอทีเป็นข้อสรุปของฉัน
Smith James

23

นี่ไม่ใช่ความคล่องตัว

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

เอาล่ะทะเลาะกันโวยวาย!

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

ฉันรู้สึกว่าควรจะมีหนึ่งในสาม ไม่มี


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

6
เอ๊ะนี่คือปี 2012 อ้างอิงงานเขียนสาธารณะของ Kent Beck หรือทิ้งไว้ ไม่สำคัญว่าเขาจะนอนบนโซฟาของคุณหรือไม่
nes1983

6
@ nes1983: ฉันเขียนว่าในปี 2011 สิ่งต่าง ๆ ในตอนนั้น
Tom Anderson

3
ฉันไม่เคยได้ยินคำว่า "หนี้ทางเทคนิค" จนกว่าจะมีการทะเลาะกันในเรดาร์ ฉันเคยไปฝึกซ้อม น้ำมันงูที่ขายได้ง่ายหมายถึงการดึงดูดผู้บริหารโดยคำนึงถึงคุณภาพของผลิตภัณฑ์ในระยะยาว พล่าม 100% แม้ว่าฉันจะกลืนมันโดยสิ้นเชิงถ้า Scrum Masters ต้องพกดาบสไตล์โคนันเพื่อกระทืบผู้คนที่คุกคามความสมบูรณ์ของกระบวนการด้วย
Erik Reppen

2
+1 สำหรับการพูดจาโวยวาย ฉันคิดว่า Scrum เป็นวิธีการ "เปรียว" สำหรับคนที่ชอบน้ำตกมากจนพวกเขาต้องการทำมันทุกสองสัปดาห์
Kyralessa

16

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

วิธีการที่คล่องตัวทั้งหมดนั้นเกี่ยวกับการสร้างรหัสการทำงานโดยไม่ได้รับอึ อ่านอีกครั้ง และอีกครั้ง.

สิ่งใดก็ตามที่ขวางหน้าเป้าหมายไม่ว่า "กฎว่องไว" จะไม่ดีก็ตาม หากกฎเข้ามาขวางเปลี่ยนกฎf * * ! นั่นคือวิธีที่คล่องตัวนั่นคือสิ่งที่ทำให้มีความเกี่ยวข้องและมีประสิทธิภาพ

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

“ ใส่คน 4-6 คนในห้องที่มีเวิร์คสเตชั่นและไวท์บอร์ดและเข้าถึงผู้ใช้ ให้พวกเขาส่งมอบซอฟต์แวร์ที่ทำงานทดสอบแล้วแก่ผู้ใช้ทุกหนึ่งหรือสองเดือน

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

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


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

2
@ user272671 ไม่ ให้พวกเขาส่งมอบซอฟต์แวร์ที่รันและทดสอบให้กับผู้ใช้เป็นประจำ ไม่อยู่ในช่วงเวลาที่กำหนดอย่างโง่เขลาเช่น 2 หรือ 3 สัปดาห์ หากผู้ใช้หรือความซับซ้อนของซอฟต์แวร์นั้นใช้งานได้ 6 สัปดาห์ให้ทำ 6 สัปดาห์ หากสามารถทำได้ใน "เมื่อเสร็จแล้ว" ให้ทำเช่นนั้น อย่าเอ็นร้อยหวายตัวเองด้วยข้อ จำกัด เทียม นั่นไม่ใช่ความว่องไว
gbjbaanb

11

Scrum master คนปัจจุบันเป็นผู้จัดการที่เข้าชั้นเรียนการฝึกอบรมแบบว่องไวสองสามวันที่ผู้บริหารได้รับค่าตอบแทนตอนนี้เป็นผู้นำทีมเปรียวนี้

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

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

ไม่ว่าในกรณีใดหากนักพัฒนาปฏิเสธมันอย่านำไปใช้ ! หรือมันจะเป็นหายนะที่คุณอธิบาย


9

"Agile" และ "วิธีการจัดการ" อื่น ๆ ทุกครั้งถูกใช้ในทางที่ผิดเพื่อบังคับให้มีการจัดการกับคน OTOH บางครั้งก็ถูกทารุณกรรมเพื่อปกป้องฝีมือไม่ดี

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

สองหลักสูตรนี้มักจะขัดแย้งโดยตรงและสามารถเกิดขึ้นได้ในโครงการเดียวกัน


จากประสบการณ์ของฉัน .. ฉันเคยได้ยินเพียงความคล่องแคล่ว (ต่อสู้ตลอดเวลา) แนะนำให้รู้จักกับการจัดการขนาดเล็ก ฉันจะไม่ปฏิเสธมันเป็นรูปแบบที่แตกต่างและเป็นเอกลักษณ์ของการจัดการขนาดเล็ก ฉันไม่เคยได้ยินนักพัฒนาคนใดพูดว่าพวกเขาคล่องแคล่วและอธิบายการมาสั้น ๆ คุณเคยมีประสบการณ์ด้านการจัดการแบบใดบ้าง
JM Becker

1
เมื่อใดก็ตามที่ฉันพบการทะเลาะวิวาทก็มีการแนะนำเพราะผู้จัดการ (มักจะสูงกว่าผู้จัดการโครงการ) เคยได้ยินเกี่ยวกับมันว่า "สิ่ง"
jwenting

7

เพื่อตอบคำถามเดิมของคุณ Agile คือการจัดการขนาดเล็กแบบใหม่ฉันจะบอกว่าไม่

ก่อนอื่นให้อ่านสิ่งนี้ (รายการ Agile) และคุณจะสังเกตเห็นว่าไม่ได้พูดคุยกับผู้พัฒนาร่วมของคุณไม่มีอยู่ในรายการ

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


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

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

2

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

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

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

ถ่ายทอดสดAgile

"เรากำลังค้นพบวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์ด้วยการทำและช่วยเหลือผู้อื่นให้ทำได้"

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

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


1

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

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


1
พัฒนาความสัมพันธ์ในการทำงานหลังเลิกงานเราควรพัฒนาความสัมพันธ์เพื่อนและครอบครัวที่ถูกทอดทิ้งบ่อยครั้งหลังเลิกงาน การพิจารณาเพื่อนร่วมงานไม่ค่อยมีเพื่อนและใช้โอกาสส่วนใหญ่ในการช่วยเหลือตนเองในค่าใช้จ่ายอื่น บริษัท ใช่พวกพ้องเพื่อนฝูงและเครื่องมือต่าง ๆ ก็ไม่ได้ตระหนักเพราะโอกาสไม่บ่อยนัก XP อาจมีค่าบางอย่างฉันไม่มีประสบการณ์จะพูดเป็นอย่างอื่น การแย่งชิงกันกลายเป็นรุ่นที่แตกต่างกันของการทำ micromanaging อย่างน้อยก็อย่างน้อย 3 บริษัท ที่ฉันรู้จัก .... คุณรู้อะไรฉันเกลียด Corporate America มากเกินกว่าที่จะเป็นเป้าหมายได้เล็กน้อย
JM Becker

0

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

ความคิดของฉันเกี่ยวกับหัวข้อ "ผู้ที่ไม่ได้พูดคุยกับใครนอกจากเป็นหัวหน้าการต่อสู้":

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

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

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

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

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


-1

ผู้แต่งดั้งเดิม Janes Smith อาจได้รับประสบการณ์ แต่สิ่งเหล่านี้เป็นปัญหาทั่วไปที่ฉันพบในโครงการ Agile

  1. องค์กรส่วนใหญ่ผู้พัฒนาควรทำงานในหลายโครงการใน Agile / scrum .. Sprints ไม่เคยถูกพิจารณาข้อเท็จจริงนี้ Scrum Master ของคุณสมมติว่าคุณควรทำกับเรื่องราวของคุณในตอนท้ายของการวิ่ง .. Scrum Master ของคุณอาจจะทุ่มเทให้กับโครงการเดียวเท่านั้น แต่ไม่ใช่นักพัฒนา .. นี่คือการจัดจำหน่าย - ไม่จำเป็นต้องเป็นแค่การโทรศัพท์ หรืออนุญาตให้โทร
  2. ฉันเคยเห็นโปรเจกต์ Agile ที่มีการวางแผน Sprint เรื่องที่รวมอยู่ใน Sprint โดยไม่ต้องฮัดเดิลแชท .. ครึ่งทางหรือกลางสปรินท์ .. นักพัฒนาค้นหาการอ้างอิงที่ไม่ได้รับการแก้ไขข้อกำหนดหรือเรื่องราวยังไม่สมบูรณ์ เป็นหนึ่งในการละเมิดในโครงการส่วนใหญ่ที่คล่องตัว
  3. การทดสอบ: TTD .. ใช่มันดีมาก .. แต่ฉันได้เห็นโครงการ Agile ส่วนใหญ่ที่พึ่งพา TTD โดยสิ้นเชิง ... ไม่มีขอบเขตหรือเวลาสำหรับการทดสอบการใช้งานหรือการใช้งานของมนุษย์ ไม่ทราบหรือเข้าใจความสำคัญของการทดสอบตามหน้าที่ โค้ดของคุณอาจทำงานได้อย่างสมบูรณ์หากไม่ตอบสนองความต้องการทางธุรกิจ .. มันไม่มีประโยชน์ .. สิ่งนี้เกิดขึ้นเมื่อธุรกิจไม่เข้าร่วมล่วงหน้า .. หรือมีส่วนร่วม ... แต่ไม่ได้สะท้อนถึงการตัดสินใจทางธุรกิจ .. ในตอนท้ายนักพัฒนาถูกตำหนิคุณไม่ได้ส่งมอบฟังก์ชั่นการทำงาน .. หรือมันจะจบลงด้วยการเปลี่ยนแปลงในนาทีสุดท้าย ... ชั่วโมงที่ยาวนานเป็นพิเศษเพราะนาย Scrum ของคุณไม่ต้องการที่จะตำหนิเรื่องที่ไม่สมบูรณ์

ใช้ผิดวิธีที่นี่ ... ไม่ว่าจะเป็นการมีส่วนร่วมของธุรกิจหรือผู้มีส่วนร่วมที่ไม่รอบรู้

  1. ไม่ใช่ทุกโครงการที่เหมาะสำหรับ Agile ... ผู้จัดการหรือผู้ทะเลาะกันส่วนใหญ่ไม่ทราบเรื่องนี้ .. โครงการบำรุงรักษา .. อาจมีข้อบกพร่องในขั้นต้นซึ่งสามารถทำได้ภายใน 8 ชั่วโมงซึ่งเป็นที่ยอมรับในการวิ่ง หลังจากใช้เวลา 4 ชั่วโมงพบว่านี่คือ Java / ผลิตภัณฑ์อื่น ... (เมื่อเร็ว ๆ นี้ฉันกำลังเผชิญกับข้อบกพร่องที่เกี่ยวข้องกับ Quartz Scheduler .. ภายในโครงการของเรา) และข้อบกพร่องนี้อาจนำไปสู่การอัปเกรดผลิตภัณฑ์ / แพคเกจ .. การสนับสนุนทางการเงิน, เวอร์ชั่นใหม่หรือการอัพเกรดควรได้รับการอนุมัติจากฝ่ายวิศวกรรมภายใน, 5. การย้อนเวลา: มีเพียงไม่กี่โครงการที่ Agile ทำตามขั้นตอนนี้ .. ถ้าทำได้ทั้งหมด .. การจัดการ, Scrum Master ไม่เคยรับผิดชอบเรื่องที่ล้มเหลว ..
  2. การจับคู่ .. นักพัฒนาจำนวนมากปฏิบัติต่อการจับคู่เป็นสถานที่เพื่อใช้ในทางที่ผิดเพื่อนร่วมงาน .. แสดงความคิดเห็นต่อการออกแบบอื่น ๆ การเขียนโปรแกรม .. ผู้ปฏิบัติต่อการทำงานเป็นทีมเรียนรู้จากกันและกัน ...

Agile เป็นวิธีการที่ดีอย่างแน่นอน .. หากองค์กรของคุณไม่ได้ปฏิบัติตามอย่างสมบูรณ์หรือไม่ได้รับการฝึกฝน .... มันถูกทารุณ .... ผลข้างเคียง 60+ ชั่วโมงการทำงานต่อสัปดาห์เกมโทษต่ำคุณธรรม


ดูลิงค์นี้ .. ทำไมโครงการ Agile จึงล้มเหลว .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

ฉันบังเอิญเห็นด้วยกับข้อมูลที่นำเสนอในบทความนั้นด้วย ฉันเข้าใจว่ามีผู้ที่คิดว่า Agile นั้นผิดพลาด แต่ความจริงก็คือ Agile ออกจากห้องเล็กน้อยหรือไม่มีเลยเพื่อแนะนำแนวคิดใหม่และมีประสิทธิภาพมากขึ้น is..brighthubpm.com / agile / 55778-Why-do-agile-projects-fail
272671

-3

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


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

เพิ่มเหตุผลบางอย่างเพื่อสนับสนุนการยืนยันของคุณ (ซึ่งทำให้รู้สึกบางอย่างกับฉัน แต่มันไม่สำคัญ) และฉันจะลบ downvote
gnat

1
ฉันเห็นด้วยกับ @Geo จนถึงปัจจุบันนั่นคือความประทับใจที่ฉันมีต่อสิ่งที่ "เปรียว" ในโลกแห่งความเป็นจริง เมื่อคุณมีการตั้งค่าบนพื้นโรงงาน - มันเป็นเพียงรูปแบบของการจัดการขนาดเล็ก ตอนนี้แถลงการณ์พยายามที่จะบอกเราว่าไม่ใช่ แต่โครงการหลังจากโครงการฉันนำไปสู่การเชื่อมากขึ้นว่ามันเป็นเพียงชื่ออื่นสำหรับ "Micromanagement" และจะฆ่าความคิดสร้างสรรค์
272671
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.