คุณต้องการอะไรที่จะประสบความสำเร็จกับ Agile?

การยอมรับแบบ Agile อาจล้มเหลวในบางองค์กรฉันยังทำงานให้กับ บริษัท ที่มีน้ำตกเป็นวิธีเดียว (จริง) แต่เพียงเพราะพวกเขาลองใช้ Agile ในโครงการและล้มเหลว

เมื่อฉันถามคนที่ยังจำได้ว่า (ฉันเป็นรุ่นน้อง) ฉันถูกปิดตัวลงอย่างหนักราวกับว่าฉันกำลังเตือนพวกเขาถึงฝันร้ายที่เกิดขึ้นจริง

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

อะไรคือสาเหตุที่การยอมรับแบบ Agile ล้มเหลวในบางองค์กร หรือวิธีอื่นในการวาง .. คุณต้องการประสบความสำเร็จกับ Agile อย่างไร?

คุณต้องมีการจัดการลูกค้าและนักพัฒนาเพื่อทำความเข้าใจและสนับสนุนวิธีคิดแบบ Agile และวิธี Agile รายละเอียดเพิ่มเติม:

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

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

ปรับปรุง

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

คุณต้องการ:

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

ดูเหมือนง่ายมาก แต่สิ่งเหล่านี้เป็นคำถามที่ยิ่งใหญ่ในอุตสาหกรรมนี้

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

ตัวอย่าง:

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

ฉันสามารถให้คำแนะนำจากประสบการณ์ส่วนตัวของฉันเท่านั้น

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

ที่นายจ้างคนอื่นทีมของเรามีสมาชิกที่กล้าหาญซึ่งพยายามสร้างแนวทางปฏิบัติที่ดีที่สุดให้กับ Agile - เรามีบอร์ด Kanban, การติดตามปัญหาเราใช้ TDD และ BDD (แม้ว่าไม่ใช่ Agile ในตัวเองพวกเขามักจะอยู่ในกลุ่ม Agile) . น่าเสียดายที่เราขาดสิ่งต่าง ๆ เช่นจุดเรื่องราวช่วงเวลาประมาณการวางแผนกำลังการผลิตแผนภูมิที่หมดลงกราฟความเร็ว - ประเภทของการจัดการโครงการ Agile ที่มีประโยชน์ที่ช่วยให้งานไหลผ่านได้อย่างราบรื่น ในฐานะที่เป็นอาการคลาสสิคของ Agile ที่ผิดไปเมื่อบอร์ด Kanban ของเราเต็มเกินไปเราซื้อบอร์ดที่ใหญ่กว่า: /

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

คิดว่าเพื่อให้ Agile ประสบความสำเร็จใน บริษัท คุณต้องมีสิ่งต่าง ๆ ดังต่อไปนี้:

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

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

ประสบการณ์ของฉันเกี่ยวกับความล้มเหลวของ Agile นั้นไม่ได้เกี่ยวอะไรกับเศรษฐศาสตร์ แต่เป็นเรื่องขององค์กร / แผนก / การเมืองส่วนบุคคล

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

เหนือสิ่งนั้นมีการจัดการการพัฒนา ฉันเห็นสิ่งนี้ผิดไปสองวิธี

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

อีกอย่างคือ 'Agile In Name Only' ที่ใช้คำศัพท์เฉพาะเช่น sprints และ scrum แต่เป็นเพียงการติดป้ายกำกับการปฏิบัติแบบเก่าเช่นการจัดการแบบไมโครการไม่ซื่อสัตย์จะขึ้นและลงห่วงโซ่การบังคับบัญชาการประชุมสถานะที่ไร้ประโยชน์และสิ่งอื่น ๆ . โครงการล้มเหลวเช่นเดียวกับที่เคยทำ แต่ตอนนี้ Agile สามารถถูกตำหนิได้มากกว่าการจัดการที่ไม่ดี

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

IMO "Agile" ล้มเหลวเมื่อไม่มีการบายอินแบบขายส่ง สิ่งที่ฉันหมายถึงคือ Agile อาศัย "ลูกค้า" (โดยทั่วไปคือแผนกหรือผู้จัดการ) เข้าใจว่า:

1. พวกเขาไม่ทราบว่า 100% สิ่งที่พวกเขาต้องการให้ซอฟต์แวร์ทำแม้ว่าพวกเขาคิดว่าพวกเขาทำ
2. พวกเขาไม่รู้ว่าจะใช้เวลานานเท่าใดจึงจะเสร็จสมบูรณ์แม้ว่าพวกเขาคิดว่าพวกเขาทำ
3. พวกเขาจะได้รับแจ้งว่าต้องใช้เวลานานเท่าใดและต้องยอมรับหรือลดคุณสมบัติเพื่อให้ตรงตามกำหนดเวลา
4. พวกเขาจะต้องเลือกคุณสมบัติการวนซ้ำแต่ละครั้งและจะไม่ได้รับแอปพลิเคชันที่สมบูรณ์และสมบูรณ์ 100% ในช็อตเดียว

ทั้งหมดเหล่านี้เป็นสิ่งที่ยากมากสำหรับผู้จัดการส่วนใหญ่ที่จะกลืนและ IMO # 1 เหตุผลว่าทำไมมันยากที่จะทำ Agile - ผู้จัดการจะใช้ในการพูดว่า "มันจะทำโดยวันที่ x" และมี "Magically" ทำวันที่ (หลังจากนักพัฒนาใช้เวลา 80 ชั่วโมงต่อสัปดาห์) และเป็น 180 ที่จะตระหนักได้ว่าทีมพัฒนากำลังจะบอกคุณว่าโครงการนี้จะทำใน 3 เดือนและทางเลือกเดียวที่คุณต้องยอมรับหรือลดข้อกำหนดเพื่อให้ได้ มันทำเร็ว

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

ประการที่สามทีมพัฒนาของคุณต้องอยู่เบื้องหลัง Agile นั่นหมายความว่าไม่ใช่การตัดมุมและไม่เพิกเฉยต่อคำติชมและคำถามอย่างต่อเนื่องของ "สิ่งนี้ถูกต้องหรือไม่เมื่อ x เกิดขึ้นฉันควรทำอย่างไร" แม้ว่าคุณจะไม่ได้ติดตาม TDD หรือ Pair Programming ทีมพัฒนาของคุณจำเป็นต้องมีความสามารถเพียงพอที่จะทำตามกระบวนการที่คล่องตัว (เช่น sprints, iterations) สิ่งนี้เกี่ยวข้องกับการมีผู้นำ / ผู้จัดการที่สามารถประเมินงานได้อย่างถูกต้องและเข้าใจว่าคุณไม่จำเป็นต้องทำให้คุณลักษณะทุกอย่างมีความสำคัญมันก็โอเคที่จะมีงานค้างและคุณไม่ควรทำงานหนักเกินไป