Agile, Scrum และ Kanban: คำเหล่านี้หมายความว่าอย่างไร?

เมื่อนักพัฒนาซอฟต์แวร์ได้ยินข่าวเกี่ยวกับ “เฟรมเวิร์ก JavaScript ใหม่” หรือ “IDE ใหม่” เขาไม่จำเป็นต้องถามคำถามเพิ่มเติมเพื่อชี้แจงว่าเนื้อหาเกี่ยวกับอะไร แต่ถ้าเขาได้ยินเกี่ยวกับ "กรอบใหม่ที่เปรียว" เขาน่าจะพยักหน้าโฮเมอร์ - ซิมป์สันโดยแสร้งทำเป็นว่าเขารู้ว่ามันเกี่ยวกับอะไร แต่เขาจะมีคำถามเดียวและมีเพียงคำถามเดียว: "กรอบงานเปรียว" นี้ทำอะไร หมายถึง?

ในสภาพแวดล้อมการพัฒนาซอฟต์แวร์สมัยใหม่ เราได้ยินคำว่า "agile" "scrum" และ "kanban" มากขึ้นเรื่อยๆ และมักใช้คำเหล่านี้อย่างไม่เหมาะสม ในบทความนี้ ฉันจะพยายามอธิบายและชี้แจงข้อกำหนดเหล่านี้บางข้อ

เปรียว

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

“ Agile” หมายถึง “การพัฒนาซอฟต์แวร์ที่คล่องตัว” ซึ่งเป็นแนวทางในการพัฒนาที่เป็นไปตามหลักการที่คล่องตัว แต่อะไรคือ "หลักการที่คล่องตัว" ดูแถลงการณ์ Agile และหลัก 12 ประการของความคล่องตัวซึ่งเป็นรากฐานของการพัฒนาที่คล่องตัว จากแถลงการณ์:

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

แต่ทำไมการปฏิบัติตามหลักการเหล่านี้ในงานของเราจึงสำคัญมาก

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

Scrum

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

Scrum ไม่ใช่วิธีการ แม้ว่าเราทุกคนจะเคยได้ยินว่าเรียกบ่อยกว่าจำนวนการสังหารใน Game of Thrones Scrum ไม่ได้ให้คำตอบสำหรับทุกคำถาม และไม่ได้ให้ขั้นตอนที่แม่นยำในการตอบสนองต่อทุกสถานการณ์ที่คุณเผชิญ และอาจเป็นผลมาจากการตีความที่ไม่ถูกต้อง การใช้งาน scrum ส่วนใหญ่ก็ผิดเช่นกัน: ทีมไม่ได้รับคุณค่า นี่อาจเป็นคำกล่าวที่โง่เขลาที่สุดเกี่ยวกับ scrum: “Scrum ไม่ทำงาน”

การต่อสู้คืออะไร? Scrum Guide กำหนด scrum เป็น:

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

Scrum ประกอบด้วยบทบาทดังต่อไปนี้: เจ้าของผลิตภัณฑ์, Scrum Master, ทีมพัฒนา

นอกจากนี้ยังมีพิธีการ Scrum สี่แบบ: Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective

และสิ่งประดิษฐ์สามอย่าง: Product Backlog, Sprint Backlog, Product Increment

โปรเจ็กต์ Scrum ถูกจัดเป็นกรอบเวลาปกติ ซึ่งเราเรียกว่า sprints โดยปกติจะใช้เวลาสองสัปดาห์

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

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

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

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

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

มีการใช้เทคนิคหลายอย่างร่วมกับการต่อสู้: การวางแผนโป๊กเกอร์ การเขียนโปรแกรมคู่ การพัฒนาที่เน้นการทดสอบ (TDD) การพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม (BDD) และอื่นๆ พวกเขาไม่ได้เป็นส่วนหนึ่งของการต่อสู้ แต่เป็นเทคนิคที่เข้ากันได้ วิธีหนึ่งที่มักกล่าวถึงในเวลาเดียวกันกับ scrum คือคัมบัง และมีความสับสนมากมายเกี่ยวกับความหมายของสองสิ่งนี้ในความสัมพันธ์ซึ่งกันและกัน

คัมบัง

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

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

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

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

Backlog → การกำหนดข้อกำหนด → พร้อมสำหรับการพัฒนา → การพัฒนา → การตรวจสอบโค้ด → การทดสอบ → ใช้งานแล้ว (→ ไม่มีใครใช้มันจริงๆ → ถูกลบโดยสมบูรณ์)

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

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

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

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

ฉันควรใช้อะไร?

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

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

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

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

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