ลักษณะเฉพาะของการทำงานของทีม Agile ใน SAFe เมื่อเทียบกับ Scrum ในทางปฏิบัติ

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

ก่อนอื่นผมจะ列举ประเด็นหลักที่สุดที่ทำให้การทำงานใน SAFe แตกต่างจาก SCRUM ในความเห็นของผม

• Increment ใน Scrum และ Program Increment ใน SAFe
• ART - Agile Release Train
• จำนวนทีมที่ทำงานร่วมกัน
• PIPE
• SOS
• PO - ไม่ใช่เจ้าของธุรกิจ
• RTE
• สปรินต์ที่ห้าสำหรับการเรียนรู้
• System Demo

Increment ใน Scrum และ Program Increment ใน SAFe จริงๆ แล้วเป็นคำศัพท์ที่แตกต่างกัน แต่ก็ง่ายที่จะสับสนเพราะ ไม่มีใครใช้คำว่า Program Increment ในหมู่เรา ทุกคนพูดแค่ว่า Increment ซึ่งเป็นอีกคำศัพท์หนึ่ง ที่ใช้ใน SCRUM แต่โดยรวมแล้วทั้งสองมีความคล้ายคลึงกันในแง่ของความหมาย ในความเห็นของผม Increment ใน SCRUM คือผลิตภัณฑ์ปัจจุบันบวกกับเรื่องราวที่วางแผนไว้สำหรับสปรินต์ในสถานะที่เสร็จสมบูรณ์ (ผ่าน DOD ของทีมแล้ว) Program Increment คือช่วงเวลาที่รถไฟ (Agile Release Train) ส่งมอบ คุณค่าแบบเพิ่มพูนสู่โปรดักชัน ในด้านระยะเวลา สำหรับเราคือ 4 สปรินต์ สปรินต์ละ 2 สัปดาห์สำหรับการพัฒนา และหนึ่งสปรินต์ สำหรับการเรียนรู้

Agile Release Train - คือทีมของทีมที่ทำงานบนสายธารแห่งการสร้างคุณค่าเดียวกัน เราเรียกสิ่งนี้ว่า แค่รถไฟ แต่ตามเฟรมเวิร์กที่ถูกต้องควรเรียกว่า "Solution" ในกรณีของเรา กฎนี้ไม่ได้ถูกปฏิบัติอย่างสมบูรณ์ และทีมมักทำงานบนผลิตภัณฑ์ที่แตกต่างกันจากมุมมองทางเทคนิค เนื่องจากฟีเจอร์ทางธุรกิจส่วนใหญ่ ถูกดำเนินการแบบบูรณาการและเกี่ยวข้องกับหลายผลิตภัณฑ์ นี่คือจากมุมมองทางเทคนิค แต่ผมมั่นใจว่า มีคนที่ถือว่าระบบไอทีทั้งหมดเป็นผลิตภัณฑ์เดียวของบริษัท และบางทีอาจจะถูกต้องกว่าด้วยซ้ำ

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

มันแสดงความสัมพันธ์ระหว่างทีมต่างๆ ของรถไฟ และเมื่อพูดคุยกันก็จะมีการจัดกิจกรรมประจำสัปดาห์ Scrum Of Scrums (SOS) ของเรา

ประมาณทุกๆ 2.5 เดือน (ทุกๆ 5 สปรินต์) จะมีกิจกรรม PIPE - Programm Increment Planning Event. นี่คือเมื่อทีมที่กระจายอยู่ทั่วทุกแห่งมารวมตัวกันในห้องเดียวเป็นเวลา 2 วันและวางแผนงานของตนสำหรับ 2.5 เดือนถัดไป ในระหว่างกิจกรรมนี้จะเกิดอาร์ติแฟกต์ต่างๆ เช่น Program board ซึ่ง แสดงการพึ่งพากันทั้งหมดระหว่างทีมสำหรับแต่ละรถไฟ ข้างต้นผมได้แสดงให้เห็นแล้วว่ามันมีหน้าตาอย่างไร หน้าที่ของ Scrum Master ของแต่ละทีมในกิจกรรมนี้คือการอำนวยความสะดวกในการระบุการพึ่งพากันให้ได้มากที่สุด จากนั้นพยายามขจัดออก (เช่น โดยการถ่ายทอดความสามารถด้วยวาจาจากทีม หนึ่งไปยังอีกทีมหนึ่ง หรือโดยการดึงการพึ่งพาจากทีมหนึ่งไปยังอีกทีมหนึ่ง เพื่อให้ทีมสามารถดำเนินการ ฟีเจอร์ของตนได้อย่างอิสระโดยไม่ต้องพึ่งพาใคร) ในทางปฏิบัติของเราก็เป็นเช่นนี้ ก่อนอื่นฟีเจอร์จะถูกแบ่งย่อยเป็น User Story, User Story จะถูกกระจายไปยัง 4 สปรินต์ ฟีเจอร์จะถูกวางบน Program Board และแสดงการพึ่งพาจาก ทีมอื่นๆ ที่มีอยู่ ในระหว่างกิจกรรมนี้จะมีการพูดคุยและปรับแก้

SOS - Scrum Of Scrum กิจกรรมนี้จัดขึ้นสัปดาห์ละครั้งสำหรับแต่ละรถไฟแยกกัน Scrum Master ของทุกทีมในรถไฟจะรวมตัวกันออนไลน์ มีการถ่ายทอด Program Board ของรถไฟและพูดคุยเกี่ยวกับสถานะของการพึ่งพา และฟีเจอร์ทั้งหมดของทีมในรถไฟนั้น โดยพื้นฐานแล้วกิจกรรมนี้จำเป็นสำหรับการซิงโครไนซ์ ทีมภายในรถไฟแบบรวมศูนย์ คล้ายกับสแตนด์อัป แต่สัปดาห์ละครั้งและไม่ใช่สำหรับทีม แต่สำหรับ Scrum Master

PO (เจ้าของผลิตภัณฑ์) - ไม่ใช่เจ้าของธุรกิจ มี Product Manager ซึ่งทำงานกับ Business Owner ของสายธุรกิจที่เกี่ยวข้อง และโดยพื้นฐานแล้วแจกจ่ายฟีเจอร์ให้เจ้าของผลิตภัณฑ์ เจ้าของผลิตภัณฑ์ทำงาน โดยตรงในทีม - แบ่งฟีเจอร์เป็น User Stories (ในกรณีของเราร่วมกับทีม) และไม่ได้แบ่งทุกครั้ง แต่เรากำลังพัฒนาอย่างต่อเนื่องในทิศทางนี้

RTE (Release Train Engineer - พนักงานขับรถไฟ. สกรัมมาสเตอร์แห่งสกรัมมาสเตอร์ จัดกิจกรรม SOS ของรถไฟของตนเอง มีปฏิสัมพันธ์กับ Product Manager ในระดับฟีเจอร์ อำนวยความสะดวก PIPE

สปรินต์ที่ห้าเพื่อการเรียนรู้ - ใช่ ต่างจาก Scrum ตรงที่ที่นี่ทีมได้รับสปรินต์เต็มในตอนท้ายของ增量เพื่อการเรียนรู้ ตามปกติแล้วในทางปฏิบัติเราใช้มันเพื่อเข้าร่วมการฝึกอบรมภายในเป็นหลัก รวมถึงเกี่ยวกับ SAFe ด้วย แต่ไม่เพียงเท่านั้น เราพยายามจัดหลักสูตรส่วนตัวและการมีตอัปให้อยู่ในช่วงเวลานี้หากเป็นไปได้ นอกจากนี้เรายังมีนักพัฒนาที่ขยายสแตกของตนในช่วงสปรินต์ที่ 5 เพื่อให้สามารถปิดทักษะของใครบางคนในทีมได้ (สำรองไว้เมื่อจำเป็น)

System Demo จากผลของ PIPE แต่ละทีมมีรายการเป้าหมายสำหรับ增量 และแต่ละเป้าหมายเหล่านี้ได้รับการประเมินโดย Business Owner ของรถไฟตามมาตรา 10 คะแนน สิ่งนี้เรียกว่า Business Value เป้าหมายเหล่านี้แบ่งออกเป็นเป้าหมายหลักและเป้าหมายขยาย เป้าหมายหลักคือเป้าหมายที่ทีมไม่เห็นความเสี่ยงใดๆ ในการบรรลุ เป้าหมายขยายคือเป้าหมายที่มีความเสี่ยงในการบรรลุ เป้าหมายทั้งหมดเป็นสิ่งบังคับ และปริมาณงานถูกวางแผนสำหรับเป้าหมายทั้งหมด ในการสาธิตระบบ Business Owner ยอมรับผลลัพธ์ของงานสำหรับ增量 สมมติว่าทีมมีเป้าหมายหลัก 3 เป้าหมายด้วยคะแนน 10, 6, 8 และเป้าหมายขยาย 2 เป้าหมายด้วยคะแนน 10, 3 สมมติว่า Business Owner ให้คะแนนตามลำดับดังนี้: 8, 6, 4, 2, 0 ตอนนี้สามารถคำนวณเปอร์เซ็นต์การบรรลุเป้าหมายได้: 100% คำนวณจากผลรวมคะแนนเริ่มต้นสำหรับเป้าหมายหลัก ในกรณีของเราคือ 10+6+8=24 คะแนนที่บรรลุจะคำนวณโดยคำนึงถึงเป้าหมายขยาย (กล่าวคือ ทีมบรรลุ 20 จาก 24) ดังนั้นผลลัพธ์เปอร์เซ็นต์การบรรลุเป้าหมายของทีมจะเป็น (20*100)/24 = 83.3% ผลลัพธ์ปกติถือเป็นการบรรลุตั้งแต่ 80% ถึง 100%

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

ความคิดเห็นของเพื่อนร่วมงานจาก facebook

«เจินยา สวัสดี! เยี่ยมมากที่เขียน เก่งมาก! ขอแก้ไขเล็กน้อยเกี่ยวกับรถไฟ - พวกมันไม่ได้รวมตัวกันรอบผลิตภัณฑ์ แต่รอบกระแสการสร้างคุณค่า และในธุรกิจค้าปลีกของเรา จากมุมมองของ SAFe ไม่ใช่รถไฟ แต่เป็น Solution เพียงเพื่อความสะดวกในการสื่อสารและทำให้เข้าใจง่ายขึ้น เราจึงยังคงเรียกรถไฟ)»

– คอนสตันติน โวโรนิน (ตัวแทนสำนักงานโครงการของ Ingosstrakh)

«และบางทีอาจมีคนสังเกตว่าจากมุมมองของ SAFe การประเมินเป้าหมายเกิดขึ้นที่ I&A (ซึ่ง SD เป็นส่วนหนึ่งแต่ไม่ได้เชื่อมโยงโดยตรงกับการประเมิน) และ SD เองควรผ่านทุกสปรินต์ (หลังการสาธิตของทีม) แต่เรายังห่างไกลจากสิ่งนี้ ดังนั้นเราจึงเรียกทุกอย่างตามที่เขียนในบทความของคุณอย่างมีสติ)»

– คอนสตันติน โวโรนิน (ตัวแทนสำนักงานโครงการของ Ingosstrakh)

«เจินยา ช่วยเขียนต่อเถอะ มีประโยชน์มาก!»

– อเล็กเซย์ อิโอ诺夫 (ผู้ฝึกสอนที่ได้รับการรับรองด้าน SAFe)