ทีมของคุณทำงานได้ดีโดยไม่ทำตามวิธีการทำงาน (เช่นต่อสู้) หรือไม่?

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

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

มีใครอื่นที่ก้าวหน้าเป็นเวลานานโดยไม่ต้องเผชิญกับการต่อสู้ / เปรียว / ฯลฯ ?

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

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

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

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

สุจริตถ้าทีมเล็ก ๆ ของคุณทำงานโดยไม่มีเหตุการณ์สำคัญมาตลอดหลายปีที่ผ่านมาโดยที่ไม่ต้องคิดถึงกระบวนการคุณอาจทำแบบว่องไว กระบวนการที่ว่องไวทั้งหมดนั้นหมายความว่ามันสอดคล้องกับ "Agile Manifesto" http://agilemanifesto.org/ซึ่งไม่ค่อยน่าประหลาดใจที่จะพูดเกี่ยวกับการทำซ้ำกระดานเรื่องราว ฯลฯ ผู้เช่ารายแรกของเปรียวคือคุณชอบ "บุคคลและ ปฏิสัมพันธ์ระหว่างกระบวนการและเครื่องมือ " ทีมใดที่ทำงานร่วมกันได้ดีไม่จำเป็นต้องคิดหนักเกี่ยวกับกระบวนการ

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

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

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

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

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

หากคุณไม่มีปัญหาในการแก้ปัญหาขอให้โชคดี

ฉันเคยเห็นหลายทีม (โดยเฉพาะใน บริษัท ขนาดเล็กมาก) ทำงานได้ดีโดยไม่มีวิธีการที่กำหนดไว้

การใช้วิธีการ (หรือเทคนิค) เพราะมันสนุกหรือเพราะคุณอ่านบล็อกโพสต์บนอินเทอร์เน็ตนั้นอันตรายมาก

ถ้าคุณสบายดีอย่าเปลี่ยนอะไรเลย ลองใช้การปรับให้เหมาะสมเมื่อคุณทำได้

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

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

การกำหนด<insert-buzzword-here>แนวทางปฏิบัติงานล่าสุดอย่างครอบคลุมมีแนวโน้มที่จะทำให้เกิดความสับสนมากกว่าที่คาดไว้ แต่โดยทั่วไปแล้วสามารถให้ตัวชี้วัดช่องทำเครื่องหมายมากมายที่ผู้จัดการสายที่ไม่ได้เข้ารหัสสามารถทำเครื่องหมายอย่างกระตือรือร้น

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

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