Scrum ฉบับย้อย่อ

วงจรพัฒนา Products หรือ Projects แบบ Scrum วาดออกมาแล้ว แสดงได้ดังรูปข้างล่างนี้

scrumLifecycle

ต่อไปนี่ก็คือ Scrum ในแบบฉบับย้อย่อ

  • Scrum เป็นกรอบการบริหารโครงการ(projects) เพื่อพัฒนา products อะไรก็แล้วแต่สักอย่างหนึ่งที่มีความซับซ้อนสูง(extremely complexity) ซึ่งมีแบบแผน(patterns)บริหารและจัดการโครงการแบบ Iterative และ Incremental
  • ในลำดับของกระบวนการจัดการโครงการแบบ Scrum ทุกๆ iterations ใช้ระยะเวลาตั้งแต่ 1 ถึง 4 สัปดาห์ เรียกว่า Sprints (นี่จึงเรียกว่า iterative) ที่ใช้ระยะเวลาสั้นๆ พอดีๆ แบบนี้ เหตุผลหนึ่ง ก็เพื่อที่จะปล่อย(release) feature ที่แล้วเสร็จ มีประโยชน์ได้สูงสุด ใช้ทรัพยากรน้อยสุด และเร็วที่สุด ออกไปสู่สายตาท่านลูกค้าได้ทดลองใช้ก่อนตลอดทั้งโครงการ(นี่จึงเรียกว่า incremental) ทุกๆ Sprint จะต้องสามารถปล่อย feature products ที่ใช้งานได้จริง มีคุณภาพ และมีประโยชน์กับลูกค้า แบบนี้ ไปเรื่อยๆจนครบทุก feature ที่ได้ตกลงกับลูกค้าไว้(อารมฌ์เดี่ยวกับศิลปินนักร้องที่มีการ ปล่อย single ของตนออกมานั่นเอง ถ้าดีก็ทำต่อ ถ้าไม่ดีก็ปรับปรุงต่อไป หรือยกเลิกโครงการไปเลย)
  • ScrumMaster จะเข้ามาช่วย หรือเป็น Project Manager แต่จะไม่มีอำนาจควบคุมการทำงานพัฒนาเหมือน PM แบบของดังเดิมทั่วไป โดยรับหน้าที่มาบริหารโครงการ แต่จำเป็นต้องมีคุณสมบัติเพิ่มเติมอีก คือมีทั้งความเป็น leadership และ facilitator หรือเป็น Servant leadership เช่น ค่อยช่วยเหลือ DevelopmentTeam ให้สามารถทำงานได้โดยสะดวกสบาย ทั้งใจ ทั้งกาย ไม่ติดขัด ทำให้ทีมเข้าใจเป้าหมาย ความตั้งใจของโครงการ(chartering) แล้วกระตุ้นให้ทีมใช้ความเชี่ยวชาญในงานของตนเอง (individuals), มีปฏิสัมพันธ์ (interaction) เพื่อทำงานร่วมกัน (collaboration) กับผู้ที่เกี่ยวข้องอื่นๆ ให้สามารถบรรลุเป้าหมายไปด้วยกัน ช่วยให้คำแนะนำแก่ทีม และบุคคลในองค์กรให้เข้าใจ Scrum เพื่อให้ทีมไม่ติดกับปัญหาใดๆที่จะไปขัดจังหวะการทำงาน ที่ทำให้ทีมส่งมอบผลงานไม่ได้ หรือล่าช้า รวมถึงเป็นผู้นำเสนอที่ดี ที่สามารถอธิบาย และผลักดันให้ทีมรู้ เข้าใจหลักการ หลักปฏิบัติ บทบาทหน้าที่ ความรับผิดชอบ เทคนิคเครื่องมือ และแบบแผนการพัฒนาโปรดักส์ หรือโปรเจกต์ในกรอบของ Scrum ได้อย่างถูกต้อง ไม่ออกนอกกรอบ ไม่เล่นนอกกฏ และ มีหน้าที่สำคัญมากๆคือทำให้ทีมรับเอา (Adopt) 4 ค่านิยม (4 values) และ 12 หลักการ (12 principles)แห่ง Agile ให้ได้
  • โดยทั่วไป DevelopmentTeam(หรือเรียกสั้นๆว่า Team) หนึ่งนั้น จะประกอบไปด้วยนักพัฒนาประมาณ 5 ถึง 9 คน ซึ่งจะประกอบด้วยผู้เชี่ยวชาญด้านต่างๆ เช่น โปรแกรมเมอร์, นักออกแบบ, นักวิเคราะห์, วิศวกรรมฮาดแวร์, สถาปนิกทั้งซอฟแวร์หรือฮาดแวร์, นักวิเคราะห์ฐานข้อมูล, นักทดสอบ หรือบุคลใดๆที่จะช่วยสร้างอะไรก็แล้วแต่ทั้ง code เอกสาร ไดอะแกรม ติดตั้งเครื่อง ลงซอฟแวร์พื้นฐาน หรืออุปกรณ์ทุกสิ่งอย่างที่จะทำให้เกิดซอฟแวร์ที่เป็น product ทำงานได้เพื่อทำให้ลูกค้าใช้ feature จาก product ของเข้าตามต้องการได้ ไม่ว่าจะทำหน้าที่บทบาทอะไรก็แล้วแต่ ให้เรียกเป็น หนึ่งเดียวกันว่า DevelopmentTeam ในกรณีถ้าเป็น projects ขนาดใหญ่ ก็จะแบ่ง feature ออกเป็นส่วนๆ โดยมี ProductOwner คอยดูแล feature ในแต่ละส่วน หรือเป็น package ที่ประกอบไปด้วย feature ต่างๆ เป็นลำดับชั้นลงมา ซึ่งมี ScrumMaster ค่อยกำกับดูแลบริหารให้บริการในทุกๆทีม เพื่อค่อยช่วยเหลือ ประสานงานเพื่อให้ทีมพัฒนา feature ในแต่ละส่วนของตนเองได้อย่างต่อเนื่องไม่มีสะดุด และยังคงเล่นอยู่ในเกมส์ Scrum โดยปกติ 1 ScrumMaster สามารถรับผิดชอบช่วยเหลือได้ 4 DevelopmentTeam
  • ProductBacklog คือรายการของ feature หรือ รายการความต้องการ (requirement list) ที่ลูกค้าปรารถนา(ambition)อยากได้ อยากให้มีเพื่อใช้ประโยชน์ได้ในตัว product ของลูกค้าเองหรือเป็นตัวแทนลูกค้าก็ได้ มันจะถูกสร้างโดย ProductOwner (แนะนำให้เขียนเป็น UserStories โดยไม่ต้องสนใจโครงสร้างมากนัก) เริ่มต้นนั้น รายการ feature เหล่านั้นก็ยังทำไม่ได้ทันที ถ้ามันยังไม่ได้ถูกอธิบายให้ team เข้าใจ แล้ววางแผน จัดลำดับคุณค่าความสำคัญก่อน จะเพิ่มเข้ากระบวนการ Sprint ต่อไปได้ การวางแผนใน Sprint หนึ่งจะเรียกว่า  SprintPlanningMeeting โดยเริ่มต้น ProductOwner จะอธิบายแต่ละ ProductBacklog ก่อนว่า feature นี้มันคืออะไร ทำไปให้ใคร ทำไมถึงต้องมี จะสำเร็จ feature นี้ได้ เมื่อใช้ feature นี้แล้ว product จะให้ประโยชน์ได้อะไรออกมาบ้าง หลังจากนั้นจึงขอความช่วยเหลือจากทีมพัฒนาเพื่อประมาณเวลาที่ใช้พัฒนา feature ทั้งหมดจนกลายเป็น product ได้ แล้วจึงทำการลำดับความสำคัญ หลังจากนั้นทีมก็จะเลือก feature เข้า Sprint ด้วยทีมเอง แล้วทำการวางแผนร่วมกันสร้างงาน(SprintBacklog) หรือจะต้องทำกิจกรรมอะไรบ้าง อย่างไรบ้าง ที่จะทำให้ feature นี้สำเร็จและใช้งานได้อย่างถูกต้องตามความต้องการของ ProductOwner (ProductOwner มีความรับผิดชอบในการสร้าง ProductBacklog ซึ่งจะอยู่ในกิจกรรม ProductBacklogGrooming ดูจากภาพจะอยู่บริเวณ vision)
  • SprintBacklog คือรายการของ feature บวกกับ รายการของงาน(tasks) ที่ต้องทำ ซึ่งจะอยู่ภายใต้แต่ละ feature ในรายการที่ทีมนำเข้ามาใน SprintBacklog นี้เสร็จสามารถเล่นได้ ใช้ประโยชน์มันได้จริงๆ หรือ ลูกค้ายินดีจ่ายเงินเพื่อแลกกับ feature นี้ ซึ่ง DevelopmentTeam จะวางแผน และตกลงร่วมกันไว้แล้วว่าจะทำ feature อะไรบ้างใน Sprint ขณะนี้ ทีมจะเลือกมาจาก ProductBacklog ซึ่งมันจะถูกวางแผนก่อนแล้วใน SprintPlanning ข้างต้น โดยทีมจะให้ StoryPoint วิธีการให้ StoryPoint นิยมใช้เทคนิค PlanningPoker แล้วจึงเพิ่ม feature นี้เข้าไปใน SprintBacklog เพื่อเริ่มกระบวนการที่กำลังจะ Sprint ในรอบนี้ และก็จะทำแบบนี้ในรอบถัดๆไป (SprintBacklog จะสามารถบรรจุ feature ที่ใช้ระยะเวลาพัฒนาจนสามารถใช้งานได้ รวมกันไม่เกินความยาวของ Sprint ที่ทีมพัฒนาตกลงร่วมกันไว้ เช่น 1 อาทิตย์ หรือ 2 อาทิตย์)
  • ทำให้งานใน SprintBacklog นั้นมองเห็นจับต้องได้(Transparency) เพื่อให้ทีมเข้าใจสถานะของงาน และสื่อสารอธิบายเข้าใจกันได้ง่ายขึ้น โดยการเขียนใส่กระดาษสี่เหลี่ยมขนาดพอดีเขียนข้อความสั้นๆ ให้เข้าใจตรงกันเป็น card หรือใช้เป็นขนาด post-it(sticky notes) ก็ได้ แล้วแปะมันใส่ไว้ใน ScrumTaskBoard โดยจะแบ่งกระดานออกเป็นช่องๆ ตามแต่สถานะของงานที่ทีมกำลังทำอยู่ เช่น Product Backlog, Sprint Backlog, In Progress,  In Testing และ Done เป็นต้น
  • ProductOwner จะเป็นผู้กำหนดคุณค่าลำดับความสำคัญของรายการ feature ใน ProductBacklog ที่เรียกว่า prioritize เพราะเขาเป็นคนที่เข้าใจความต้องการของลูกค้า และรู้ถึงอัตถประโยชน์สูงสุด(utility maximization) หรือคุณค่ามากที่สุดของ feature ที่ลูกค้า จะได้รับใน product ของเขา ที่กำลังจะสร้างเป็นอย่างดี รวมทั้งยังเป็นผู้นำเสนอ feature ของ product แก่ลูกค้าหรือผู้ใช้หรือผู้บริโภค กับทีมก่อนนำเข้า Sprint และเป็น ผู้เขียนรายการ feature ด้วยโดยนิยมเขียนในรูปแบบของ UserStories ซึ่งจะอยู่ในกิจกรรม ProductBacklogGrooming หน้าที่ทั้งหมดนี้ DevelopmentTeam สามารถทำได้ แต่ความรับผิดชอบทั้งหมด เป็นของ ProductOwner แต่เพียงผู้เดียว
  • ตอนเริ่มต้น Sprint ทีมจะเป็นผู้สร้าง วางแผน แล้วเลือกงานไปทำเองตามลำดับความสำคัญใน ProductBacklog ว่า ต้องทำงานอะไร และจะใช้ความพยายามเท่าไรจึงจะทำให้งานทุกชิ้นสำเร็จทั้งหมดภายใต้ feature ที่จะทำให้สามารถทดสอบแล้วปล่อย feature นี้ได้สมบูรณ์ นั้นขึ้นอยู่กับข้อตกลงที่ได้วางแผนไว้กับทีมแล้ว(เป้าหมายของ Sprint ซึ่งรวม รายการงานด้านคุณภาพไว้ด้วยแล้ว) เพื่อให้ทุกๆ feature เสร็จสมบูรณ์ได้ในช่วงระยะเวลาของ Sprint ในที่กำลังจะเริ่มต้นขึ้นขณะนั้น
  • ใช้ DailyScrumMeeting เพื่อพบปะพูดคุยกันในทีม จะใช้ระยะเวลา ประมาณ 10-15 นาที นั้นจะช่วยทีมได้มาก ระหว่างที่ทีมพบปะกัน เขาก็จะพูดคุยเกี่ยวกับว่า เมื่อ DailyScrumMeeting ที่แล้วจนถึงตอนนี้ทำงานอะไรเสร็จไปแล้วบ้าง, แล้ววันนี้จะทำงานอะไรต่อไป และมีปัญหา ความคลุมเครือที่ยังไม่เข้าใจ อันเป็นอุปสรรค์ ในระหว่างการทำงานนั้นคืออะไร เมื่อทีมรับรู้ปัญหา ทีมก็จะให้คำแนะนำกันว่า จะแก้ไขยังไงกันดี เพื่อที่จะทำให้การ Sprint นี้ราบเรียบ ไม่สะดุด ต่อเนื่องไป ไม่หยุดไปเฉยๆได้ นำไปสู่การบรรลุเป้าหมายร่วมกันตามตกลงไว้กับ ProductOwner แล้วใน SprintPlanning
  • แต่ละ Sprint ทีมจะต้องพร้อม และมีศักยะภาพเพียงพอที่จะสามารถรับผิดชอบในการพัฒนา(iterative) เพื่อส่งมอบผลงานที่สมบูรณ์แล้วนี้ไปยังผู้ใช้(end-user) ให้เพิ่มขึ้น(incremental)  ได้อย่างต่อเนื่อง ไหลลื่น ไม่มีสะดุด(continuous) สรุปสั้นๆก็คือ แต่ละ Sprint ทีมจะต้องมี PotentiallyShippableProductIncrement ให้จงได้ (แนะนำว่าทีมตกลง ร่วมกันเพื่อติดตั้ง ContinuousDelivery(CD) เข้าไปเลย ก็จะสำเร็จตรงจุดนี้ได้โดยง่าย) เพราะว่า Agile ประเมิณความคืบหน้าของโครงการว่าเสร็จไปเท่าไรแล้วด้วยจำนวน feature ที่เสร็จสมบูรณ์แล้วใช้งานได้ มีประโยชน์ได้ กับผู้ใช้จริงๆแล้วเท่านั้น
  • เมื่อจบ Sprint หนึ่ง ทีม จะอธิบาย product ที่สร้างเสร็จแล้ว บวกกับที่เพิ่งทำเพิ่มขึ้นมาใหม่จาก Sprint นี้ ใน  SprintReviewMeeting ให้แก่ ProductOwner ได้ทดลองใช้งาน product จริงๆได้ ซึ่ง ProductOwner จะเชิญผู้ที่เกี่ยวข้อง ตัวแทนของลูกค้า(customer) หรือตัวแทนผู้ใช้งานจริง(end user) เข้า review ด้วย ในกิจกรรม SprintReview นี้ ProductOwner สามารถเพิ่มเติม ProductBacklog เข้าไปใหม่ได้ หลังจากนี้ทีมก็จะต้องทำกิจกรรมที่เรียกว่า Retrospective ต่อเลย ซึ่งกระบวนการนี้ก็จะต้องได้ การกระทำที่ทีมตกลงร่วมกันเพิ่มเข้ามา ช่วยปรับปรุงกระบวนการทำงานของทีมให้ดีขึ้นใน Sprint ต่อไปด้วย(ContinuousImprovement)
  • เมื่อได้ ProductBacklog ของตัว product เองเช่น feature นี้ใช้งานยากแก้ไขนิดหน่อย, มี bug ที่ feature นี้ต้องแก้ไขแล้วจากกิจกรรม SprintReview และ ชิ้นงาน หรือ เทคนิค หรือ การศึกษาเรียนรู้ และวิจัย เทคนิคใหม่ เครื่องมือใหม่  จากกิจกรรม Retrospective เพื่อปรับปรุงวิธีการทำงาน หรือสภาวะแวดล้อมในการทำงานของทีมให้ดีขึ้น แล้วนั้น ProductOwner ก็จะตัดสินใจนำเข้า หรือไม่นำเข้าไปใน ProducBacklog ทำการจัดลำดับ แล้วจึงนัด ทีม และผู้ที่เกี่ยวข้อง วนกลับมาทำกิจกรรม ProductGrooming เมื่อจบแล้ว ทีมก็จะนัดกันวนมาที่ SprintPlanning เพื่อวางแผนเดินหน้า Sprint ถัดไปได้เลย…
  • สรุปสิ่งต่างๆที่อยู่ในกรอบการทำงานแบบ Scrum จะประกอบไปด้วย
    • ผู้เล่น 3 ตำแหน่ง คือ Product Owner, Scrum Master, และ Development Team
    • กิจกรรมการพัฒนา 6 กิจกรรม คือ Product Backlog Grooming, Sprint Planning, Sprint, Daily Scrum, Sprint Review และ Sprint Retrospective
    • สิ่งที่ได้จากกิจกรรม 3 สิ่ง คือ Product Backlog, Sprint Backlog และ Potentially Shippable Product Increment
    • แสดงเป็นแผ่นภาพ Class Diagram ได้แบบนี้

ScrumModels

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

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

โดยปกติทั่วไป รวมทั้งตัวผมเองก็จะใช้เทคนิคที่ ถูกพิสูจน์ว่าใช้งานได้ดีแล้วจาก XP มาติดตั้งใช้ได้เลยในกิจกรรม Sprint หรือ เทคนิคต่างๆจาก Lean Startup ก็สามารถนำมาใช้ได้ในกิจกรรม Product Backlog Grooming ก็ทำได้ เพราะ Scrum เป็นกรอบการทำงานที่มีความเป็น Agile มันจึงมีความคล่องตัว มีความยืดหยุ่นสูง ปรับสภาพ หรือตั้งค่าใหม่ได้ตลอดเวลาตามความเหมาะสม (Adapt) นั่นคือ Scrum ได้ให้คุณค่าของการประสานงาน ทำงานร่วมกันมากกว่า กระบวนการที่ตายตัว และไม่ยึดติดกับเคลื่องมือใดๆ

ดัดแปลงจาก:User Stories Applied: For Agile Software Development ของอาจารย์  Mike Cohn หน้า Summary ของบทที่ 15

ข้อมูลเพิ่มเติม

ข้อมูลรูปภาพจาก: http://www.mountaingoatsoftware.com/scrum/overview

ขอบคุณครับ

“ขอพลังสร้างสรรค์แห่งนักประดิษฐ์ทั่วทั้งโลก จงมาสถิตอยู่ในใจของท่าน ในทุกๆลมหายใจ”

#:P

Advertisements

#agile-software-development, #delivery-software, #pattenrs, #scrum