ความมหัศจรรย์ของการจับกลุ่มที่ว่องไว

การเป็นทีมพัฒนาซอฟต์แวร์แบบเปรียวย่อมหมายถึงสิ่งที่แตกต่างกันสำหรับคนทั่วไป มีระดับการนำไปใช้ในสเปกตรัมที่กว้างมากโดยเห็นได้ชัดว่ามีองค์กรน้อยมากที่คิดว่าทำได้ดี จากการสำรวจ State of Agile ของ VersionOne (เผยแพร่เมื่อเมษายน 2017) 80% ของผู้ตอบแบบสอบถามกล่าวว่าพวกเขา“ อยู่ในระดับที่ยังไม่สุกหรือต่ำกว่า” น่าเสียดายที่ทีมพัฒนามักไม่ได้ใช้ความพยายามมากนักในส่วน "เรียนรู้" ของการทำซ้ำ เราต้องการที่จะรีบทำพิธีการ Scrum ให้เสร็จเพื่อที่เราจะได้กลับไปเขียนโค้ดได้ ท้ายที่สุดมีงานมากมายที่ต้องทำ! แต่เวลาในการเข้ารหัสไม่เพียงพอเป็นปัญหาจริงหรือ?

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

หลักการในการพัฒนาอย่างมีประสิทธิภาพ

Pixabay

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

“ แต่ไม่คล่องตัวในการทำซ้ำ (เช่นการปรับโครงสร้างใหม่)?” เพราะผู้สร้าง Agile เข้าใจว่าสาเหตุหลักสองประการของการทำงานซ้ำคือสถานการณ์ที่คาดไม่ถึงและข้อกำหนดทางธุรกิจที่เปลี่ยนแปลงไป ปรากฎว่ามนุษย์แย่มากในการทำนายอนาคต ผู้สร้าง Agile ยังเข้าใจว่าผู้มีส่วนร่วมอย่างมากต่อความไม่มีประสิทธิภาพคือสิ่งที่นักพัฒนาเรียกว่า "การชุบทอง" ซึ่งเราคิดว่าจะมีคนใช้แม้ว่าผู้ใช้ปลายทางจะไม่เคยขอก็ตาม มันเหมือนกับเนื้อหมูสำหรับผลิตภัณฑ์ซอฟต์แวร์ของคุณเสียเวลาโดยสิ้นเชิง "อย่าสร้างสถานีอวกาศเมื่อสิ่งที่พวกเขาต้องการคือ Volvo" ดังนั้น บริษัท ต่างๆจึงเริ่มทิ้งเนื้อหมูอย่างชาญฉลาดและยอมรับการปรับโครงสร้างใหม่แทนโดยเพิ่มฟังก์ชันการทำงานเมื่อมีความต้องการที่ชัดเจน แต่ความไม่สามารถคาดเดาได้ในชีวิตไม่ใช่ตัวขับเคลื่อนเพียงอย่างเดียวสำหรับการทำงานซ้ำใช่หรือไม่?

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

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

การจับกลุ่มแบบดั้งเดิม

Pixabay

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

กำลังเลิกบล็อก

Pixabay

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

นี่คือตัวอย่างบางส่วน:

1. ปรับใช้ UI ที่ใช้งานได้พร้อม Stubs

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

2. API ของแบ็กเอนด์ที่ปรับใช้ (ข้อมูลที่ถูกตรึงและเข้ารหัส)

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

3. สร้างแอปพลิเคชันและบริการใหม่ในเวอร์ชัน HelloWorld

หากต้องการบริการใหม่ (เช่น microservice) ให้สร้าง repo และสร้างบริการเวอร์ชัน“ hello world” สิ่งนี้ช่วยให้ทรัพยากร dev-ops เริ่มต้นในงาน Jenkins และสคริปต์การปรับใช้ก่อนที่จะพัฒนาบริการ

การเพิ่มประสิทธิภาพเหล่านี้ช่วยให้เกิดความคิดเห็นในช่วงต้นซึ่งใครบางคนสามารถพูดว่า“ ฉันต้องการอะไรที่แตกต่างออกไป” ก่อนที่การพัฒนาจะเสร็จสมบูรณ์ในองค์ประกอบที่ต้องการการเปลี่ยนแปลง

ห่อมัน

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

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

1. เราจะจัดระเบียบงานสำหรับเรื่องนี้อย่างไรเพื่อให้หลาย ๆ คนมีส่วนร่วมในครั้งเดียว?
2. ขั้นต่ำที่ฉันต้องทำเพื่อปลดบล็อกคนที่รอฉันอยู่คืออะไร?

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

© 2017 Mike Shoemake