แบทช์

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

แบทช์คือหน่วยของงานที่ส่งผ่านจากสเตจหนึ่งไปยังสเตจถัดไปในกระบวนการ ขนาดแบทช์ตามมาตราส่วนของผลิตภัณฑ์ที่ทำงานนั้น
http://dev2ops.org/2012/03/devops-lessons-from-lean-small-batches-improve-flow/

หนังสือ “เร่ง สร้าง และปรับขนาดองค์กรเทคโนโลยีที่มีประสิทธิภาพสูง” พบว่ามีความสัมพันธ์ระหว่างวิธีการปฏิบัติงานของทีมกับตัวชี้วัดDORA ที่แตกต่างกัน:

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

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

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

• คุณจะมีทีม DevOps (อันที่จริงแล้วคือทีม Ops แบบเก่า แต่ด้วยชื่อใหม่) พวกเขาจะเป็นทีมที่ปรับใช้ในการผลิต
• ทีม DevOps จะเป็นผู้รับผิดชอบในการตรวจสอบการผลิต จะมีการแจ้งเตือนมากมายที่ DevOps ไม่เข้าใจ
• คุณจะมีแผนก QA (อันที่จริงมีผู้ทดสอบด้วยตนเองจำนวนมากตรวจสอบสิ่งต่าง ๆ ด้วยตนเองในสภาพแวดล้อมของตนเอง)
• จะมีแผนกของ DBa ที่รับผิดชอบการเปลี่ยนแปลงในฐานข้อมูล
• คุณจะมีสภาพแวดล้อมก่อนการผลิตจำนวนมาก เพื่อให้แต่ละบทบาทก่อนหน้านี้สามารถทดสอบส่วนของตนของงานแบบแยกส่วนได้

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

เพิ่มความถี่

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

• นักพัฒนาจะมีงานในมือที่เต็มไปด้วยข้อบกพร่องสำหรับการทำซ้ำครั้งต่อไป เนื่องจากการปรับใช้ครั้งล่าสุดไม่ได้ผลดีอย่างที่ทุกคนคิด
• QA จะสร้างตั๋วจำนวนมากสำหรับข้อบกพร่องหรือข้อบกพร่องที่ไม่มีใครสนใจ
• BA จะพยายามเปลี่ยนแปลงฐานข้อมูลทั้งหมดด้วยตัวเอง โดยแปลงตัวเองเป็นผู้รักษาประตู
• PM หรือ Scrum Master ของ PO จะบ่นเพราะความเร็วของทีม และจำนวนจุดบกพร่องที่สร้างขึ้นในการทำซ้ำแต่ละครั้ง

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

การเปลี่ยนแปลง

เพื่อให้สามารถเพิ่มความถี่ในการปรับใช้ของเรา เราจำเป็นต้องเปลี่ยน เพื่อลดเวลา เราต้องปรับปรุงกระบวนการ
แต่จะมีอะไรเปลี่ยนแปลงบ้างทฤษฎีข้อ จำกัดสามารถช่วยเราได้ในเรื่องนี้ ทฤษฎีข้อจำกัดใช้กระบวนการที่เรียกว่า Five Focusing Steps เพื่อระบุและขจัดข้อจำกัด:

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

หนึ่งคุณลักษณะ

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

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

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

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

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

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

คอมมิตคือขนาดแบทช์ที่เล็กกว่าที่คุณสามารถจินตนาการได้