เมื่อ Agile ผิดพลาด [ปิด]

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

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

สิ่งที่ต้องระวังเมื่อโครงการ Agile ผิดพลาด

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

• Standups รายวัน (ที่ใช้งานประมาณหนึ่งชั่วโมง)
• แบ่งงานเป็น sprints
• เรื่องราวของผู้ใช้ (ซึ่งมักจะน้อยกว่าประโยค แต่คาดว่าจะมีการประมาณ)

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

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

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

"เรากำลังพัฒนาความคล่องตัวดังนั้นคุณควรจะสามารถรองรับสิ่งที่ฉันต้องการภายในการวิ่งตามที่ฉันระบุได้"

“ เราไม่สามารถล็อคเรื่องราวที่เรามุ่งมั่นไว้ตั้งแต่เริ่มต้นของการวิ่งเพราะต้องการเปลี่ยนการวิ่งกลางคัน”

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

ผู้ที่ไม่เข้าใจความว่องไวคืออะไรและใช้กับ:

• ลูกค้าที่ไม่สามารถแสดงความคิดเห็นได้จนกว่าจะถึงกำหนด
  ... และคุกคามการดำเนินคดีในภายหลัง

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

  ดูเพิ่มเติม: การจัดการเห็ด , อาคา "เก็บไว้ปิดบังปุ๋ยคอกเลี้ยง"และแหลมผมบังคับบัญชา :)

• ทีมที่ใหญ่เกินกว่าจะไปไหนก็ได้

• บริษัท ที่ได้รับการรักษาในบัญชีเงินเดือนของพวกเขาเมื่อมีชื่อเสียงระดับนักออกแบบสถาปัตยกรรมระบบที่จะหมดชักจูงความสนใจจากความเป็นจริงที่พวกเขาสมบูรณ์หายไปจากสายตาของฝีมือการเข้ารหัสที่เกิดขึ้นจริงโดยoverdesigningงดงามใช้ไม่ได้ผล, ที่ยากต่อการตระหนักถึง UML Familias Sagrada

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

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

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

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

• การจัดการขนาดเล็กแบบใหม่นั้นเปรียวไหม?
• กระบวนการ Agile: ควรทำอย่างไรและควรมีการบันทึกไว้อย่างไร?
• ผสมผสานการวางแผนและการเขียนโปรแกรมที่เหมาะสมในโครงการใหม่

คุณเคยได้ยินคำว่า "หลอกเปรียว" หรือไม่? นี่คือสองรายการบล็อกเกี่ยวกับมัน:

• จาก Pseudo-Agile สู่ Waterfall - เส้นทางของ บริษัท ซอฟต์แวร์ขนาดเล็กและใหม่
• หลอกเปรียว!

มีบางอย่างที่ต้องบอกว่าสำหรับ บริษัท ที่อาจมองว่า Agile และเขียงใส่มันเป็นอะไรอย่างอื่น

ฉันทำงานกับทีม Agile ที่ประสบความสำเร็จอย่างสูงรวมถึงบางคนที่พยายาม Agile แต่ไม่สามารถทำงานได้

ที่ประสบความสำเร็จมีองค์ประกอบดังต่อไปนี้:

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

ทีมที่ประสบความสำเร็จทำแบบ Agile และทำได้ดีมาก ฉันคิดว่าถ้าคุณไม่มีประเด็นเหล่านี้คุณอาจล้มเหลวได้ง่าย สิ่งที่หนึ่งและสองไปจับมือกันและถ้าคุณไม่มีสิ่งนั้น Agile จะไม่ทำงาน

ทีมที่ฉันทำอยู่นั้นไม่ได้ทำ Agile อย่างดีมีองค์ประกอบบางอย่างเช่นกัน:

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

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

ซึ่งหมายความว่าใน บริษัท มหาชน (รัฐบาลตัวอย่าง) มันจะยากมากที่จะทำให้มันทำงานได้อย่างถูกต้อง

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

ฉันไม่จำเป็นต้องพูดว่าอย่างไรก็ตาม Waterfall จำเป็นต้องทำงานในสภาพแวดล้อมดังกล่าวไม่ใช่สถานการณ์ขาวดำมีน้อยมากที่เป็นขาวดำอย่างแท้จริง

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

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

ความล้มเหลวของ Agile นั้นแย่กว่าทีมน้ำตกที่ประสบความสำเร็จในหลาย ๆ ด้านและอาจมีอัตราความสำเร็จของโครงการลดลง

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

• โครงการที่มีผลิตภัณฑ์คือชีวิตหรือทรัพย์สินมีความสำคัญ - ตัวอย่างเช่นคุณไม่ต้องการใช้ความคล่องตัวในการพัฒนาซอฟต์แวร์ที่รันเครื่องกระตุ้นหัวใจของคุณ ทำไม? เนื่องจากคุณมีค่าเผื่อที่ใกล้เคียงกับศูนย์สำหรับข้อผิดพลาด พิจารณาตัวอย่างคลาสสิกของข้อผิดพลาดในการเขียนโปรแกรมภายในยาเกี่ยวกับTherac 2525 จริงอยู่มันไม่ได้ถูกสร้างขึ้นด้วยความคล่องตัว แต่ประเด็นคือ: การพัฒนาชีวิตหรือทรัพย์สินที่สำคัญไม่ใช่สถานที่ที่จะพูดว่า "เราจะทำความสะอาดสิ่งนั้นในการวิ่งครั้งต่อไป" หรือ "เราไม่ต้องการที่ดีเพียงแค่ดี พอ."

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

• โครงการที่ต้องการการควบคุมหรือการวางแผนในระดับที่สูงกว่าที่เสนอแบบดั้งเดิมกับ Agile

ฉันสมมติว่าคนอื่นจะกระโดดเข้ามาและช่วยด้วยตัวอย่างที่ดีกว่าหรือลงคะแนนของผ้าขี้ริ้วบิตที่ฉันเขียน ;-)

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