การทำงานกับสครัม

เรื่องราวของผู้ใช้

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

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

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

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

โครงสร้างเรื่องราวมีลักษณะดังนี้: “ในฐานะผู้ใช้ <ประเภทผู้ใช้> ฉันต้องการดำเนินการ <การกระทำ> เพื่อให้ได้ <ผลลัพธ์>” (ในฐานะเจ้าของผลิตภัณฑ์ ฉันต้องการ ...) โครงสร้างดังกล่าวไม่เพียง แต่เรียบง่าย แต่ยังเข้าใจได้สำหรับทุกคน

ประโยชน์ของการใช้เรื่องราวของผู้ใช้:

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

ข้อเสียของเรื่องราวผู้ใช้:

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

งานค้าง

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

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

เงื่อนไขงานค้างที่สำคัญสองประการ

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

การสร้างเว็บไซต์ “Teams in Space” เป็นข้อเสนอแรกจากแผนงาน จะต้องแบ่งออกเป็นมหากาพย์ (ในรูปจะแสดงเป็นสีเขียว สีฟ้า และสีเขียวขุ่น) และเรื่องราวของผู้ใช้สำหรับแต่ละมหากาพย์

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

ลูกค้าควรจัดลำดับความสำคัญตามปัจจัยใด?

• ความเกี่ยวข้องกับผู้ใช้
• การปรากฏตัวของความคิดเห็น
• ความซับซ้อนของการพัฒนา
• ความสัมพันธ์ระหว่างงาน (เพื่อให้ "B" เสร็จสมบูรณ์ คุณต้องทำ "A" ก่อน)

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

วิธีเก็บงานค้าง

หากมีการสร้างงานค้างแล้วหลังจากนั้นคุณจะต้องเปลี่ยนเป็นระยะในระหว่างการทำงานต่อไป ลูกค้าซอฟต์แวร์ควรตรวจสอบให้แน่ใจว่ามีการรวบรวมงานในมืออย่างถูกต้องก่อนวางแผนการทำซ้ำใหม่แต่ละครั้ง สิ่งนี้จะช่วยชี้แจงลำดับความสำคัญหรือเปลี่ยนแปลงบางอย่างหลังจากการวิเคราะห์การวนซ้ำครั้งล่าสุด การปรับ Backlog ใน Agile บางครั้งเรียกว่า "grooming" หรือ "refinement" หรือ "backlog maintenance"

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

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

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

ขอแนะนำให้หลีกเลี่ยงการเปลี่ยนแปลงโดยตรงระหว่างการทำงาน สิ่งนี้ส่งผลเสียต่อเวิร์กโฟลว์และสภาวะทางอารมณ์ของโปรแกรมเมอร์

วิ่ง

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

“การใช้ Scrum ทำให้คุณสามารถพัฒนาผลิตภัณฑ์ได้หลายครั้งโดยมีระยะเวลาที่ชัดเจน นั่นคือ sprints ช่วยแบ่งโครงการขนาดใหญ่ออกเป็นงานเล็ก ๆ ได้” Megan Cook, Jira Lead จาก Atlassian กล่าว

Scrum วางแผนและดำเนินการ Sprint อย่างไร

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

ลูกค้าซอฟต์แวร์ Scrum master และโปรแกรมเมอร์มีส่วนร่วมในการกำหนดรายการงาน ลูกค้าอธิบายเป้าหมายของการวิ่งและงานจากงานในมือ

จากนั้นทีมพัฒนาแผนตามที่งานในการวิ่งจะเสร็จสมบูรณ์ แผนนี้พร้อมกับรายการงานที่เลือก เรียกว่า sprint backlog หลังจากการประชุมวางแผน ทีมงานก็เริ่มทำงาน นักพัฒนาจะเลือกงานจาก Backlog เมื่องานเสร็จสมบูรณ์ สถานะของแต่ละงานจะเปลี่ยนจาก “กำลังดำเนินการ” เป็น “เสร็จสิ้น”

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

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

การหวนกลับเสร็จสิ้นวงจรของการวิ่ง ทีมงานจะระบุพื้นที่ที่ต้องปรับปรุงในการวิ่งในอนาคต

สิ่งที่ควรใส่ใจและสิ่งที่ไม่ควรทำ

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

เราต้องทำอะไร:

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

สิ่งที่ควรหลีกเลี่ยง:

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

กระดานต่อสู้

Scrum Board เป็นเครื่องมือที่แสดงวิธีการทำงานของ Scrum Team คุณสามารถแสดงข้อมูลบนกระดานบนกระดาษ บนผนัง หรือในรูปแบบอิเล็กทรอนิกส์ (JIRA, Trello)

Scrum board มีอย่างน้อยสามคอลัมน์: To Do, In Progress และ Done นี่คือบอร์ดตัวอย่าง:

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

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

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

แผนภูมิเบิร์นดาวน์

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

แผนภูมิมีสองประเภท:

• แผนภูมิ Burndown แสดงความคืบหน้าของงานใน Sprint
• แผนภูมิเบิร์นดาวน์แสดงความคืบหน้าของงานจนถึงการเปิดตัวผลิตภัณฑ์ (ข้อมูลสรุปจากการวิ่งหลายครั้ง)

ตัวอย่างแผนภูมิ:

ตัวอย่างนี้ใช้หลักจิตวิทยา: แผนภูมิไม่แสดงจำนวนงานที่เสร็จสมบูรณ์ แต่แสดงจำนวนงานที่เหลือ (ยังไม่เสร็จ)

นั่นคือหากทีมทำ 90 งานจาก 100 แล้วอาจมีความรู้สึกผิด ๆ ว่าทุกอย่างพร้อมแล้ว ท้ายที่สุด ความคืบหน้าจาก 90 ถึง 100 งานไม่ได้เปลี่ยนแปลงอะไรเลย

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