เปรียวคืออะไร? ปรัชญาที่พัฒนาจากการฝึกฝน

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

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

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

บรรพบุรุษเปรียว

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

ต้นแบบของปรัชญาที่ให้ความสำคัญกับการปรับปรุงซ้ำๆ แบบจำลอง Plan-Do-Study-Act ได้รับการพัฒนาในช่วงทศวรรษที่ 1930 โดยนักฟิสิกส์และนักสถิติของ Bell Labs Walter Shewhart หลังสงครามโลกครั้งที่สอง ดับเบิลยู เอ็ดเวิร์ดส์ เดมิง บุตรบุญธรรมของเขาได้นำไปใช้เพื่อฝึกอบรมผู้จัดการที่โตโยต้า วิธีการนี้เป็นส่วนสำคัญในการพัฒนาระบบการผลิตของโตโยต้า ซึ่งเป็นแหล่งที่มาหลักของการคิดแบบลีนด้วยวงจรการเรียนรู้การสร้าง-วัด-เรียนรู้ที่มีประสิทธิภาพ

ในปี 1970 แนวคิดนี้ได้รับการพัฒนาเพิ่มเติมเมื่อ Barry Boehm เสนอเทคนิค Wideband Delphi โดยใช้กระบวนการซ้ำๆ เพื่อประเมินแรงงานและเวลาที่ต้องใช้ในการพัฒนาซอฟต์แวร์อย่างแม่นยำและเป็นกลาง

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

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

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

เปรียวในทางทฤษฎีคืออะไร?

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

ในฐานะผู้ปฏิบัติงานที่มีความก้าวหน้าในการถ่ายทอดหลักการ Agile เป็นอย่างดี ทุกองค์กรที่ต้องการรับการเปลี่ยนแปลงแบบ Agile จะต้องค้นหาและปรับแนวทางที่เหมาะสมกับพวกเขา ฉันอำนวยความสะดวกให้กับกระบวนการเรียนรู้นี้โดยแสดงให้ทีมเห็นถึงวิธีการปฏิบัติตามค่านิยมและหลักการของแถลงการณ์ จากนั้นจึงดึงแรงบันดาลใจจากกรอบการทำงาน เช่น Scrum, Kanban และ Extreme Programming (XP) เพื่อนำไปปฏิบัติจริง

หลักการของแถลงการณ์เป็นลักษณะที่สองสำหรับผู้จัดการโครงการ Agile:

1. บุคคลและปฏิสัมพันธ์ระหว่างกระบวนการและเครื่องมือ
2. ผลิตภัณฑ์ที่ใช้งานได้มากกว่าเอกสารที่ครอบคลุม
3. ความร่วมมือกับลูกค้าเหนือการเจรจาสัญญา
4. ตอบสนองต่อการเปลี่ยนแปลงตามแผน

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

การสร้างสมดุลที่เหมาะสมระหว่างรายการทางด้านขวาและซ้ายได้กลายเป็นกุญแจสำคัญในการแนะนำการเปลี่ยนแปลงแบบ Agile นอกจากนี้ยังเป็นตัวอย่างของแนวทางการจัดการที่ Apple, Google, Amazon, Facebook และ Netflix ซึ่งไม่มีสิ่งใดที่สมัครใช้งาน Agile framework เอกพจน์ พวกเขาได้รวบรวมหลักการของแถลงการณ์ก่อนและสำคัญที่สุด ในขณะที่ติดตามหรือเปลี่ยนแปลงส่วนต่างๆ ของเฟรมเวิร์กต่างๆ ตามสิ่งที่ได้ผลดีที่สุดสำหรับพวกเขา เป็นผลให้พวกเขาได้ปรับตัวให้เข้ากับการเปลี่ยนแปลงของตลาดและสามารถส่งมอบผลิตภัณฑ์ใหม่ได้อย่างรวดเร็ว

Agile ในทางปฏิบัติคืออะไร?

ในภาพรวมต่อไปนี้ ฉันได้แก้ไขการใช้ถ้อยคำดั้งเดิมของค่านิยมของแถลงการณ์ การเปลี่ยนแปลงความหมายช่วยชี้แจงวิธีที่ฉันนำค่า Agile ไปใช้ในทางปฏิบัติ

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

คนเหนือกระบวนการ

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

ฉันผิดหวังที่เห็นความคิดนี้ก่อให้เกิด "อุตสาหกรรมที่คล่องตัว" ที่ทำกำไรได้ ตามที่ Ward Cunningham และ Jon Kern ผู้ก่อตั้ง Agile อธิบาย ธุรกิจจำนวนมากขายซอฟต์แวร์ที่พวกเขาอ้างว่าจะช่วยให้บริษัทต่างๆ แต่การก้าวไปสู่ ​​Agile นั้นหมายถึงการนำปรัชญามาใช้ ไม่ใช่การใช้ซอฟต์แวร์และปฏิบัติตามโปรแกรมที่กำหนดไว้

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

ฉันรวมการประชุมปรับแต่งงานในมือ การประชุมทบทวน และการต่อสู้รายวันเพื่ออำนวยความสะดวกในการทำงานร่วมกันภายในและระหว่างทีม การปรับแต่ง Backlog เป็นส่วนหนึ่งของ Scrum Guide แต่การประชุมการปรับแต่งไม่ใช่ ฉันเพิ่มสิ่งเหล่านี้เพื่อให้มีการสนทนาที่ดีเกี่ยวกับสาเหตุที่เราวางแผนที่จะใช้คุณสมบัติเฉพาะในการวิ่งที่กำลังจะมีขึ้น ซึ่งเป็นประโยชน์สำหรับมือใหม่ Agile ฉันยังเลือก "เหตุการณ์สำคัญ" ของระบบการตั้งชื่อ ซึ่งเป็นคำที่ใช้ในการจัดการโครงการ Waterfall เพราะคุ้นเคยกับลูกค้ามากกว่า บทวิจารณ์และการโต้ตอบ scrum รายวันเป็นองค์ประกอบทั่วไปจาก Scrum Guide แต่ฉันทำให้พวกเขามีโครงสร้างมากขึ้นในแง่ของกำหนดการ ระยะเวลา และโฟลว์

นอกจากนี้ ในขณะที่การปฏิบัติตาม Scrum อย่างเคร่งครัดจะทำให้แต่ละคนทุ่มเทอย่างเต็มที่กับหนึ่งในบทบาทที่ระบุไว้ใน Scrum Guide แต่ก็มีคนในทีมของลูกค้าของฉันที่ชุดทักษะไม่เข้ากับบทบาทเดียว การใช้วิธีการแบบ Agile แบบมีวินัยทำให้ฉันสามารถแบ่งความรับผิดชอบของตำแหน่งเหล่านี้ระหว่างสมาชิกในทีมหลายคน และสร้างกระบวนการที่เล่นกับจุดแข็งของผู้ที่เกี่ยวข้อง

การส่งมอบซอฟต์แวร์ผ่านเอกสารประกอบ

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

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

ความร่วมมือเหนือสัญญา

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

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

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

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

การปรับตัวเหนือกรอบการทำงาน

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

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

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

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

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

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

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

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

อนาคตของ Agile คืออะไร?

การระบาดใหญ่ของ COVID-19 สร้างความเป็นจริงใหม่ซึ่งทีมไม่สามารถอยู่ร่วมกันได้อีกต่อไป ซึ่งเป็นวิธีที่นิยมในการทำงานภายใน Agile เมื่อตั้งครรภ์ อย่างไรก็ตาม แนวคิดที่ว่าสิ่งนี้ต้องคงอยู่ในลักษณะนี้เป็นมายาคติ: เนื่องจากการทำงานทางไกลกลายเป็นเรื่องธรรมดาไปแล้ว จึงเป็นที่ชัดเจนว่าการสื่อสารอย่างใกล้ชิดเป็นไปได้ทั้งหมดด้วยซอฟต์แวร์การประชุมทางวิดีโอ ทีมที่ฉันทำงานด้วยตอนนี้มีการกระจายอย่างเต็มที่แล้ว และฉันกำลังฝึกอบรมจากทางไกล บางทีมยังเลือกที่จะทำงานแบบอะซิงโครนัสโดยใช้เครื่องมือเช่น Notion และ Loom รวมถึงปลั๊กอิน Slack เช่น Standuply

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

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