ความว่องไวหมายถึงอะไร

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

ในโครงการก่อนหน้านี้เรามีการวางแผนการประชุมจากนั้นกำหนด log back ของผลิตภัณฑ์และจัดสรรงานให้กับนักพัฒนาใน 2 ถึง 3 สัปดาห์ sprints ทุกเช้าเรามีการประชุมการต่อสู้ (ซึ่งดูเหมือนว่าจะดำเนินต่อไป 1/2 ชั่วโมงต่อครั้ง) และนักพัฒนาแต่ละคนก็ขึ้นไปหลังจากนั้น แทบจะไม่มีใครเขียนการทดสอบใด ๆ จนกว่าจะสิ้นสุดการวิ่งและงานที่ยังไม่เสร็จสมบูรณ์ถูกเพิ่มเข้าในการวิ่งครั้งต่อไป

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

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

ดังนั้นคำถามของฉันคือเราไปผิดที่ไหนและฉันจะป้องกันไม่ให้ทีมทำผิดพลาดแบบเดียวกันได้อย่างไร

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

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

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

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

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

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

Jarrod ให้คำตอบที่ดี (+1 ถึงเรื่องนั้น) และฉันอยากจะขยายไปเล็กน้อย

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

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

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

อาจใช้เวลาสักครู่ แต่ ...

1. คุณจะแก้ไขปัญหาที่ใหญ่ที่สุดก่อนซึ่งจะมีผลกระทบมากที่สุดต่อความสามารถของทีมในการส่งมอบผลิตภัณฑ์
2. โดยการระบุปัญหาที่เกิดขึ้นทันทีและการมีส่วนร่วมในการหาวิธีแก้ปัญหาสมาชิกในทีมของคุณจะเข้าใจว่าทำไมการปฏิบัติบางอย่างจึงมีความสำคัญและจะไม่ทำอย่างนั้นเพราะพวกเขาได้รับคำสั่งให้ทำ

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

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

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

พวกเขาควรมองลึกลงไปในวิธีปฏิบัติทางวิศวกรรมที่ใช้เพื่อสนับสนุนวิธีการเฉพาะโครงการเปรียวเลือก