#priwreadarticles Queueing theory — ทฤษฎีการจัดคิว

Photo by Lisanto 李奕良 on Unsplash

บทความนี้สรุปจาก https://less.works/less/principles/queueing_theory พี่หนุ่ม ประธาน ส่งมาให้อ่าน ตอนแรกก็นึกว่าจะสั้นๆ จะเขียนสรุปเล่นๆ แต่พอลงมือแล้วยาวเฉย ก็กลายเป็นเลยตามเลย ซึ่งในบทความต้นฉบับจะมีภาพประกอบแต่ละหัวข้อย่อยด้วย สามารถกดเข้าไปดูได้เลย

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

เป็นการยากที่จะแก้ไขปัญหาที่คุณไม่รู้ว่ามันมีอยู่ ซึ่งทฤษฎีการจัดคิว ชี้ให้เห็นถึงแนวทางในการปรับปรุง

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

ทางโตโยต้าเรียนรู้เกี่ยวกับความแปรผันทางสถิติและความหมายของทฤษฎีการเข้าคิว โดยสะท้อนผ่านหลักการทำงานแบบลีน (Lean) ลดความแปรปรวนด้วยแบตช์งานที่เล็กกว่าและรอบเวลาที่สั้นลง

โน้ตไว้ว่าบางครั้ง ลีน ถูกอธิบายเน้นไปที่ แบตช์งานขนาดเล็ก คิวที่สั้นกว่า รอบเวลาการทำงานที่เร็วขึ้น ส่งมอบคุณค่าอย่างรวดเร็ว แต่ ลีน เป็นมากกว่านี้ สิ่งหลักที่ผู้คิดค้นว่าไว้คือ “การเคารพผู้คนและการพัฒนาอย่างต่อเนื่อง” การจัดคิว การทำ WIP Limits และอื่นๆ เป็นเพียงเครื่องมือเท่านั้น ส่วน LeSS สนับสนุนเรื่องของทฤษฎีการเข้าคิว

Little’s Law Myth Alert

บทความกว่าพันล้านบทความอ้างว่า กฎของลิตเติ้ล พิสูจน์ได้ว่าการลดระดับ WIP จะลดรอบเวลาเฉลี่ย แต่การพิสูจน์ของเขาก็ขึ้นอยู่กับสมมติฐาน/เงื่อนไขที่ต้องเป็นจริง ซึ่งเงื่อนไขเหล่านั้นไม่รับประกันว่าเป็นจริงในเรื่องที่มีความแปรปรวนสูงอย่างเช่นการพัฒนาซอฟต์แวร์ ซึ่งสิ่งนี้ก็ถูกนำมาวิเคราะห์แยกส่วนใหม่ในกฎของ Little’s Flaw โดย Daniel Vacanti

การลด WIP เป็นเป้าหมายที่มีความสำคัญใน LeSS

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

Compete on Shorter Cycle Times

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

• “concept to cash” for one release
• “concept to done” for one feature
• potentially shippable time; how frequently could you ship?
• compile time (of all the software)
• “ready to pilot” to delivery time
• deployment time for testing (into embedded hardware)
• analysis and design times

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

Half the time is not half the cost

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

Half the time is not twice the cost

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

Queue management

มีกลยุทธ์มากมายในการลดรอบเวลา เช่น ลีน อไจล์ ซึ่งเครื่องมือหนึ่งคือ การจัดการคิว

Queue Management to Reduce Cycle Time

หน่วยธุรกิจที่นำแนวทางการจัดคิวมาใช้ [สำหรับพอร์ตโฟลิโอและการจัดการผลิตภัณฑ์] บอกว่า ลดเวลาในการพัฒนาโดยเฉลี่ยลง 30% เป็น 50% [AMNS96]

ตัวอย่างคิวในการพัฒนาและการจัดการพอร์ตโฟลิโอ

• products or projects in a portfolio
• new features for one product
• detailed requirements specifications waiting for design
• design documents waiting to be coded
• code waiting to be tested
• the code of a single developer waiting to be integrated with other developers
• large components waiting to be integrated
• large components and systems waiting to be tested

ในการพัฒนาตามลำดับแบบดั้งเดิม มีคิวของงานที่เสร็จสิ้นบางส่วนจำนวนมาก เรียกว่า work-in-progress or WIP queues เช่น เอกสาร specification รอการเขียน หรือโค้ดที่เขียนแล้วรอการทดสอบ นอกจากเรื่อง WIP queues แล้วยังมีคิวทรัพยากรที่ใช้ร่วมกันอีกด้วย เช่น การขอใช้ห้องปฏิบัติการทดสอบราคาแพงหรือขอชิ้นส่วนอุปกรณ์ทดสอบ

Queues Are a Problem

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

WIP Queues

คิวจะเพิ่มรอบเวลาเฉลี่ยและลดการส่งมอบมูลค่า และอาจลดผลกำไรตลอดอายุการใช้งานลง ในการคิดแบบลีน WIP Queues ถูกระบุว่าเป็นของเสียและต้องถูกกำจัด เพราะ

• มีผลกระทบต่อรอบเวลา
• เป็นของที่ทำเสร็จแค่บางส่วน ซึ่งไม่ได้ผลตอบแทนจากการลงทุน
• เอากลับมาทำซ้ำ/แก้ได้อีก ยังไม่ได้ถูกใช้จริงหรือตรวจสอบ เช่น โค้ดที่ยังไม่ได้รวมเข้ามาไว้ด้วยกัน
• เราเห็นกลุ่มผลิตภัณฑ์แบบดั้งเดิมที่ใช้เวลาประมาณหนึ่งปีในการทำงานกับฟีเจอร์ที่เป็น deal breaker แต่แล้ว product management ก็ตัดสินใจเอาออก เพราะตลาดเปลี่ยนไปแล้ว การวางแผนใหม่ใช้เวลาหลายสัปดาห์ โดยทั่วไป WIP queues จะส่งผลต่อต้นทุนและความสามารถในการตอบสนองต่อการเปลี่ยนแปลง — 1) เงินและเวลาถูกใช้ไปกับงานที่ยังไม่เสร็จและไม่ทำแล้ว 2) รายการที่ถูกลบไปอาจส่งผลกับฟีเจอร์อื่น 3) งานที่เพิ่มใหม่อาจจะล่าช้าเพราะมี WIP กองจำนวนมาก

Shared-Resource Queues

การต้องรอใช้ทรัพยากรอะไรบางอย่างที่เป็นของส่วนรวม ก่อให้เกิดการล่าช้าได้เช่นกัน เช่น เราต้องทดสอบโค้ดใหม่ของเรากับเครื่องพิมพ์นั้นในห้องปฏิบัติการ เมื่อไหร่จะว่าง

แผน A: กำจัด (แทนที่จะจัดการ)​ คิว

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

คิดนอกกรอบ ลดกรอบระยะเวลา เปลี่ยนระบบไม่ให้มีคิวอีกต่อไป

นำทีมที่อยู่คนละสายงานมาอยู่ด้วยกัน (วิเคราะห์ เขียนโปรแกรม ทดสอบ) โดยไม่ต้องส่งงานให้กลุ่มอื่น ใช้การพัฒนาที่ขับเคลื่อนด้วย automated acceptance test-driven development และ automated continuous deployment คิวก็จะหายไปเป็นการย้ายการพัฒนาจากแบบต่อเนื่องกันสู่คู่ขนานกัน

Fake Queue Elimination

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

แผน B: จัดการคิว เมื่อคุณไม่สามารถกำจัดได้

WIP queues สามารถกำจัดได้ตามแผน A แต่ก็อาจจะกำจัดไม่ได้ทั้งหมด จึงเกิดแผน B ขึ้น ปรับปรุงรอบเวลาเฉลี่ย ลดขนาดแบตช์ ลด WIP limits และขนาดคิว

• คิวทรัพยากรที่ใช้ร่วมกัน เช่น ห้องปฏิบัติการทดสอบ
• คิวของฟีเจอร์ที่อยู่ใน Product Backlog
• ใช้การจัดการคิว เมื่อแผน A ไม่สามารถทำได้ หรือ ติดปัญหาทางเครื่องมือหรือเทคนิค เช่น การเปลี่ยนการทดสอบจาก Manual ไปเป็น fully automated ยังอ่อนแอ/ช้า

ใน LeSS แบตช์ที่เล็กลงหมายถึง แพ็กเกจงานขนาดเล็กของ Item หรือ Feature ที่จะพัฒนาใน Sprint แบตช์ที่มีขนาดเท่ากันบ่งบอกว่าแต่ละชุดมี effort ที่น่าจะใช้เท่ากัน

Queueing Theory

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

• สมมุติฐาน: It is fastest to do sequential (‘waterfall’ or V-model) development with large-batch transfers between groups.
• สมมุติฐาน: It is fastest for people or groups to have high utilization rates and multitask on many projects at the same time.

ความเข้าใจในทฤษฎีการจัดคิว สามารถเปิดเผยว่าสมมติฐานเหล่านี้ช่วยลดรอบเวลาเฉลี่ยได้จริงหรือไม่

Qualities of a Stochastic System with Queues

คิดถึงการจราจรในเมืองใหญ่ในช่วงเวลาคับคั่ง สมมติว่ามีถนน 12 เลน รถหนาแน่นแต่ก็ยังขยับเคลื่อนตัวไป จู่ๆ ก็เกิดอุบัติเหตุไป 3 เลน แล้วรถก็ติดหนัก พออุบัติเหตุได้รับการแก้ไขใน 30–60 นาทีต่อมา คิวขนาดใหญ่นี้จะใช้เวลาอีกยาวนานเพื่อเคลียร์สภาพ

ข้อสังเกต:

• Nonlinear เมื่อความโหลดของถนนอยู่ที่ 0–50% รถจะเคลื่อนตัวอย่างราบรื่น แต่เมื่อความโหลดกลายเป็น 50–100% การชะลอตัวจะเพิ่มขึ้นอย่างเห็นได้ชัด การเกิดคิวไม่ได้เพิ่มขึ้นเป็นเชิงเส้นตรงจากศูนย์
• Delay and overload do not start at 99.99% utilization ไม่ใช่ทุกอย่างที่จะราบรื่นไปจนถึง 100% สิ่งต่างๆ จะช้าลง ชะลอตัว การติดขัดจะเกิดขึ้นก่อนเต็มขีดพิกัด บางครั้งที่ความจุ 60% คุณจะเริ่มสังเกตเห็นการชะลอตัว ซึ่งเป็นรอบเวลาเฉลี่ยที่ยาวนานขึ้น
• Clearing the queue takes longer than making it การเคลียร์คิวช้ากว่าการสร้างเสมอ
• Stochastic, not deterministic มีความผันแปร/การสุ่ม/ความน่าจะเป็น มาเกี่ยวข้องมากมาย เช่น อัตราการมาถึงของรถยนต์ เวลาที่ใช้ในการกำจัดอุปสรรค อัตราการออกรถ

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

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

Modeling a Basic Single-Arrival System with Queues

อัตราการมาถึงระหว่างการเข้าคิวคือ Markovian และอัตราค่าบริการคือ Markovian (Markovian: กระบวนการสุ่มที่มีความน่าจะเป็น (stochastic) ซึ่งสถานะในอนาคตไม่สามารถทราบได้อย่างชัดเจนจากสถานะปัจจุบัน คล้ายกับ “ความเป็นจริงที่ยุ่งเหยิง”) โมเดลการจัดคิวพื้นฐานทั่วไปคือ M/M/1/∞ โดยมีเซิร์ฟเวอร์หนึ่งเครื่องและคิวที่ไม่จำกัด ค่าเหล่านี้เป็นค่าเฉลี่ยในพฤติกรรมการรอสำหรับระบบ M/M/1/∞ พื้นฐาน เนื่องจากองค์ประกอบมีความแปรปรวนแบบสุ่ม เช่น

• คำขอมาถึงเวลาต่างกัน ด้วยความพยายามต่างกัน
• การทดสอบหรือความพยายามในการเขียนโปรแกรมต้องใช้เวลาผันแปร
• คนทำงานเร็วขึ้นหรือช้าลง ป่วยหรือทำงานนานขึ้นหรือสั้นลง

สิ่งนี้แสดงให้เห็นถึง

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

Modeling a Batch System with Queues (Traditional Development)

ระบบ M/M/1/∞ พื้นฐาน จะเป็นการทำรายการเดียว (สำหรับการทดสอบ วิเคราะห์ เขียนโปรแกรม ทดสอบ) มาแบบแยกส่วน มีข้อกำหนดเดียวที่ชัดเจน ไม่ถูกจับมาเป็นก้อนใหญ่ๆ

เมื่อพิจารณาระบบ M[x]/M/1/∞ ที่เป็นชุดของไอเท็มมาถึง โมเดลนี้เปรียบได้กับการพัฒนาผลิตภัณฑ์แบบดั้งเดิม สรุปได้ว่า

• ระบบขนาดใหญ่มักเกี่ยวข้องกับความต้องการขนาดใหญ่ คนงานที่คาดว่าจะถูกใช้งาน 100% (ไม่ว่าง) สามารถมีผลกระทบที่น่าอัศจรรย์ต่อรอบเวลาเฉลี่ย
• การผลักดันให้มีอัตราการใช้แรงงานสูง ด้วยงานจำนวนมาก เป็นการเพิ่มขึ้นของรอบเวลาแบบ Super Linear
• ความล่าช้าทวีความรุนแรงมากขึ้นในการพัฒนาตามลำดับแบบเดิม เนื่องจากมีชุดของกระบวนการที่มีคิว WIP อยู่ข้างหน้า
• เมื่อประกอบกับความแปรปรวน ก็เป็นการเพิ่มผลกระทบเชิงลบให้กับรอบเวลาเฉลี่ยโดยรวม
• The Law of Variability Placement [HS08] เปิดเผยว่า ตำแหน่งที่แปรปรวนที่สุด คือ requirements analysis เฟสแรก (ด่านหน้าสุด) ที่มี specifications ที่เป็นก้อนใหญ่และเยอะมาก

Hidden Batches: Eyes for Batches

เพื่อลดเวลาเฉลี่ยของรอบการทำงาน ให้คงความหย่อนในระบบไว้ ไม่ใช่ “ไม่ว่าง 100%” และ ค่อยๆ เพิ่มขึ้นเรื่อยๆ ลดรายการความต้องการใหญ่รายการเดียว ให้เป็นรายการขนาดเล็ก มีขนาดเท่ากันโดยประมาณ ที่สามารถเห็นได้ชัดใน Product Backlog

Hidden Queues: Eyes for Queues

• Invisible queues ในการพัฒนาแบบดั้งเดิมยังมีคิวทุกประเภท แต่เนื่องจากคิวที่มองไม่เห็น จึงไม่ถูกมองว่าเป็นคิวหรือรู้สึกว่าเป็นปัญหา
  หากคุณเป็นนักธุรกิจที่ลงทุนไป 10 ล้านยูโร เพื่อสร้างสิ่งของที่ทำเสร็จบางส่วนจำนวนมหาศาลแล้วมันถูกกองอยู่บนพื้น ไม่ได้ทำเงินใดๆ คุณเดินผ่านและเห็นมัน คุณจะรู้สึกถึงความเจ็บปวดและรู้สึกเร่งด่วนที่จะต้องทำอะไรสักอย่าง คุณจะคิดได้ว่า จะไม่ทำของกองใหญ่ที่ทำเสร็จแล้วบางส่วนอีกต่อไป แต่นักพัฒนาผลิตภัณฑ์กลับมองไม่เห็นและไม่สัมผัสถึงความเจ็บปวดจากการรอคิว
• Visual management for tangible queues การทำให้เห็นภาพ ช่วยให้มองเห็นคิวได้ชัดขึ้น เทคนิคยอดนิยมคือการแสดงงานทั้งหมดสำหรับ Sprint บนการ์ดกระดาษที่แปะบนผนังและย้ายไปรอบๆ เมื่องานเสร็จสิ้น การ์ดที่จับต้องได้เหล่านี้ทำให้มองเห็นคิวที่มองไม่เห็นที่ซ่อนอยู่ภายในคอมพิวเตอร์ได้อย่างแท้จริง

Indirect Benefits of Reducing Batch Size and Cycle Time

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

Applying Queue Management in LeSS

มีกลยุทธ์มากมายในการจัดการคิว แต่ในบริบทของ LeSS ประกอบด้วย

1. change the system to utterly eradicate queues

feature teams and acceptance TDD and continuous deployment

2. learn to see remaining queues with visual management

3. reduce variability

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

Product Backlog เป็นคิวลำดับความสำคัญขนาดใหญ่ที่เกือบจะไม่มีที่สิ้นสุด ให้มองแยกเป็นสองก้อนคือ

1. current release ซึ่งควรเป็นทุก Sprint
2. future backlog ประกอบได้สองส่วนคือ กลุ่มของรายการที่วิเคราะห์อย่างชัดเจน ประมาณการได้ดี ละเอียดพอที่จะทำได้ใน Sprint สำหรับหนึ่งทีม กับ กลุ่มที่ยังคลุมเครือที่ต้องการการวิเคราะห์ การประมาณค่า ลงรายละเอียดเพิ่มเติม ซึ่งกลุ่มนี้ต้องได้รับการขัดเกลาผ่าน Refinement ก่อนที่จะนำไปเข้า Sprint

มีความแปรปรวนหลากหลาย (ถือว่าเป็นของเสีย) ที่อาจเกิดขึ้นได้ เช่น

• big batches and big items
• ambiguity of what items mean
• ambiguity of how to design/implement items
• different (estimated) efforts for different items
• number of items in the “current release” clear-fine priority queue
• estimate-versus-actual effort variance, which can reflect what/how ambiguity, unskillful estimation, learning, and much more
• the arrival rate of items into the clear-fine priority queue of the current release
• team and individual variability
• overloading or failure of shared resources, such as a testing lab

ในการคิดแบบลีน โฟลว์เป็นหลักการสำคัญ และโฟลว์ต้องการการลดหรือขจัดความแปรปรวนออกไป

Reducing Special-Cause Variability in LeSS:

• Reduce variability by a small queue (buffer) of clear-fine, similar-sized user stories in the Release Backlog คิวของรายการที่มีขนาดใกล้เคียงกัน
• Reduce variability by holding a Product Backlog Refinement (PBR) workshop each Sprint เตรียมรายการเพื่อให้พร้อมสำหรับ Sprint ในอนาคต ให้แบ่งสิ่งของออกเป็นชิ้นเล็กๆ ประมาณเท่าๆ กัน เวิร์กช็อปที่ทำซ้ำๆ เหล่านี้ช่วยสร้างจังหวะปกติในการเพิ่มรายการที่ชัดเจนลงในคิว
• Reduce variability by stable feature teams ใช้ทีมที่มีความอยู่ตัว ที่รวมคนที่อยู่คนละสายงานมาทำงานร่วมกัน ช่วยเพิ่มการทำงานแบบขนาน
• Reduce variability by timeboxed effort-boxed learning goals เคล็ดลับนี้มีประโยชน์มากที่สุดในโดเมนที่มีความต้องการเชิงวิจัยขนาดใหญ่ เสนอเป้าหมายแบบจำกัดเวลา ให้ทีมศึกษาเรียนรู้หัวข้อดังกล่าวและนำมาเสนอ จากนั้นเจ้าของผลิตภัณฑ์อาจตัดสินใจที่จะทุ่มเทความพยายามที่มีขอบเขตมากขึ้นในวงจรการวิจัยอื่นสำหรับ Sprint ในอนาคต ทำให้มันชัดเจนเพียงพอที่จะนำไปทำงานต่อได้

4. limit queue size

เทคนิคการจัดการคิวอีกวิธีหนึ่งคือการจำกัดขนาดคิว ใน WIP queues ของการพัฒนาแบบเข้าก่อนออกก่อน (FIFO) แบบดั้งเดิม คิวยาวเป็นปัญหาเพราะจะใช้เวลาตลอดไป ส่วนใน Product Backlog ก็มีการเรียงคิวโดยใช้ priority แต่การจำกัดจำนวนรายการก็ยังคงมีความจำเป็นอยู่

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

บทสรุป

• ตอบสนองต่อปัญหาภายในที่เกิดขึ้น พิจารณาทำระบบไคเซ็น ให้ระบบพื้นฐานมีการเปลี่ยนแปลงในทางใดทางหนึ่ง เพื่อให้คิวไม่สามารถสร้างหรือมีอยู่ได้อีกต่อไป
• Parallelizing with cross-functional teams and acceptance test-driven development เป็นเพียงตัวอย่างเท่านั้น ยังมีอีกหลายอย่างมากมาย
• ใช้การจัดการคิว เมื่อคุณไม่สามารถกำจัดคิวได้