Scrum 3 Days 3 วันแห่งการรุมสกรัม
จุดมุ่งหมายของคลาสนี้คือการสอน Scrum ให้กับเด็กสหกิจที่พึ่งเข้ามาใหม่ ให้ได้เข้าใจถึงคำถามที่ว่า ทำไมเราถึงต้องทำ Agile และเพื่อให้เด็กๆ ได้สัมผัสถึง Perfection Scrum เพื่อที่จะส่งมอบซอฟแวร์ที่ดีให้กับลูกค้าได้อย่างต่อเนื่อง
Disclaimer ว่านี่คือ Class Scrum ในมุมมองของคนนอกที่ไม่เคยเรียน Scrum มาก่อน และได้ย้ายสายเข้ามาเป็นนักพัฒนาซอฟแวร์
Overview
- Day 1 Defined process vs Empirical process
- Day 2 Agile ≠ Scrum
- Day 3 Sprints & รุม Scrum
Day 1
พวกเราเริ่มต้นวันแรกด้วยการแบ่งกลุ่มด้วย
- โปรเจคที่เรารับผิดชอบว่าถือกี่โปรเจคห้ามมาจากที่เดียวกัน
- มหาวิทยาลัยห้ามซ้ำกัน
- ความหลากหลายทางเพศของคนในกลุ่ม
หลังจากใช้เวลานานพอสมควรในการจัดกลุ่ม เราเริ่มต้นด้วยการทำ Workshop แรก ผมเรียกมันว่า “SABIE Board” พี่รูฟให้เด็กๆ จำลองกระบวนการทำงานด้วยการวาดรูปคัดลอกสิ่งที่อยู่บนบอร์ดให้เหมือน Original มากที่สุด โดยมีข้อแม้เล็กๆ ว่าห้ามเอากระดาษไปทาบแล้ววาดตาม พวกเราจำลองวิธีการทำงานด้วย 2 วิธีการ
- ให้เวลา 15 นาที ทำงานทั้ง flow จนเสร็จแล้วมา Review กัน
- ให้เวลารอบละ 3 นาที 5 รอบ ก่อนทำให้เดินมาถามว่า “เห้ย รูฟ , เจน มีเวลา 3 นาที อยากเห็นอะไรวะ” 555555555555+ ทำเสร็จแต่ละรอบเราก็มา Review กัน และคุยกันว่าเมื่อกี๊ทำอะไรไปวะ แล้วทำให้ดีขึ้นได้ยังไงบ้าง
ผลของการทำ Workshop แน่นอนว่า วิธีแรกทำให้เราได้ SABIE Board ที่เละไม่เป็นท่า ได้รับ feedback ที่ช้ามาก และได้ Product ที่ไม่ตรงปก ต่างจากวิธีการทำงานเป็นรอบที่ Team ถามพี่รูฟว่ามีเวลาเท่าเนี๊ยะ อยากได้อะไร ทำให้แต่ละรอบเราได้ Product ที่มันใกล้เคียงกับสิ่งที่ รูฟรูฟ ต้องการมากที่สุดเท่าที่จะเป็นไปได้
โอเคครับ ที่ผ่านมาเป็นเพียงเกริ่น Overview เท่านั้นยังมีอะไรที่น่าตื่นเต้นอีกเยอะ
ในโลกยุคที่เราเริ่มจะเข้าสู่การปฏิวัติอุตสาหกรรม เป็นยุคที่เครื่องจักรเริ่มเข้ามาทำงานแรงงานแทนคน แต่เราก็ยังคงต้องการแรงงานที่จะมาใช้งานเครื่องจักรเหล่านั้น เราเรียกคนเหล่านั้นว่า “Worker” และแยกคนที่ต้องใช้ความรู้ความเข้าใจในการวางแผน และออกแบบไว้อีกกลุ่มหนึ่ง เราเรียกคนเหล่านี้ว่า “Designer” คนสองกลุ่มนี้ทำงานโดยมีเส้นที่แบ่งหน้าที่ของกันและกันไว้อย่างสิ้นเชิง Worker ทำงานตามพิมพ์เขียวที่ Designer บอกว่าสิ่งนี้ออกแบบไว้ดีแล้วให้เชื่อและทำตามนี้ซะ ผลลัพธ์ที่ได้เกิดเป็น Mass Product ที่ออกมาหน้าตาเหมือนเดิมเป๊ะตรงตามแบบที่ออกแบบไว้ เราเรียกวิธีการทำงานแบบนี้ว่า “Defined Process” คือกระบวนการทำงานที่ถูกกำหนดขั้นตอนต่างๆ ไว้แล้ว เฉกเช่นเดียวกันกับ
Baking การอบขนมปังที่เราต้องรู้สูตร รู้สเต็ป ซึ่งทำให้มันง่ายต่อการทำเป็นขั้นเป็นตอน
ในยุค The age of Software & Digital คำว่า “Software” ถือว่าเป็นเรื่องที่ใหม่มาก คนที่อยากทำ Software ไม่รู้ว่าจะนำวิธีการไหนมาใช้ดี เราจึงนำวิธีการแบบเดิมที่เคยได้ผลกับโลกยุคเดิมมาใช้ นั่นคืองานก่อสร้าง ทำให้ Software ที่ถูกสร้างขึ้นในยุคก่อนมีลักษณะที่เหมือนตึก ทำแล้วแก้ยาก เพราะไม่มี feedback loop ที่ต่อเนื่องมากพอ ในคืนท่ามกลางหิมะที่รีสอร์ทแห่งหนึ่งในรัฐยูทาห์ มีคนกลุ่มหนึ่งรวมตัวกันพูดคุยถึงวิธีที่จะพัฒนาวิธีการพัฒนาซอฟแวร์ให้ดีขึ้น เป็นจุดกำเนิดของ Agile Manifesto ซึ่งเป็นหัวใจที่เหล่าคนที่เชื่อในการทำงานแบบ Agile ยึดเป็นสรณะ
แล้ว Agile มันคืออะไรกันนะ พี่เจนกล่าวเอาไว้ว่า เราสามารถเปรียบลักษณะการทำงานแบบอไจล์ที่มี feedback loop ที่ต่อเนื่องได้เช่นเดียวกับ
Cooking ที่เราสามารถชิม feedback ว่ามันยังขาดหวานนะก็เติมน้ำตาล ชิมรอบที่สองยังขาดรสเผ็ดนะก็เติมพริกเพิ่มได้ จนกระทั่งเราได้รสชาติที่กลมกล่อมที่สุดแล้ว ณ เวลานั้น เราจึงเสิร์ฟจานนี้ให้กับลูกค้า Software ก็เช่นกัน
เราเรียกลักษณะการทำงานแบบ Cooking process ในอีกชื่อว่า “Empirical process” หรือแปลเป็นไทยได้ว่า กระบวนการเชิงประจักษ์…
Agile Manifesto
คำแถลงการเอ้ยแถลงการณ์(ถูกมั้ยนะ55555555)ที่เหล่าคนที่เชื่อในการทำงานแบบ Agile ยึดเป็นสรณะมีอยู่ 4 ประการ
Individuals and interactions over processes and tools จงเชื่อในความเป็นมนุษย์ เชื่อในการมีปฏิสัมพันธ์ระหว่างกัน มากกว่า การทำงานตามขั้นตอน และยึดติดในเครื่องมือ จงถามตัวเอง และทีมอยู่เสมอว่าเราใช้เครื่องมือนี้ไปทำไมนะ
Working software over comprehensive documentation จงทำซอฟแวร์ให้ใช้งานได้ มากกว่า การทำเอกสารโครงการในโปรเจค Agile ไม่เคยบอกว่าเอกสารไม่สำคัญ แต่ Agile บอกว่า Software ที่ใช้งานได้นั้นมาก่อนเสมอ
Customer collaboration over contract negotiation จงเชื่อในการทำงานร่วมกันกับลูกค้า มากกว่า การทำข้อตกลงสัญญา เพราะ Agile บอกว่า Software เปลี่ยนแปลงอยู่เสมอ หากเกิดเหตุการณ์ที่ไม่คาดฝันเกิดขึ้น จงหลับตาแล้วบอกว่าสัญญาเดิมไม่ถูกต้องอีกต่อไปแล้ว เพราะ Software ที่ลูกค้าต้องการได้เปลี่ยนไปแล้ว
Responding to change over following a plan จงอ้าแขนเพื่อพร้อมโอบรับการเปลี่ยนแปลง มากกว่าการทำตามแผน
Note: อไจล์ ไม่ได้บอกว่าสิ่งของทางขวาไม่สำคัญ แต่เราเพียงแค่ใส่ใจสิ่งของทางซ้ายมากกว่า
Day 2
พวกเราเริ่มต้นวันที่สองด้วยการฟังคลิปวีดีโอ Glasses Product ของ Google ในคลิปเล่าถึงสถานการณ์ที่ Team จาก Google เข้าไปรับ Real Requirement กับ User , Develop และให้ Real User ทดลองใช้ ณ ตอนนั้นเลย สิ่งนี้แสดงถึง Agile ในรูปแบบที่สุดขั้ว และเป็น Agile ในอุดมคติ แต่การทำอะไรที่สุดขั้วเกินไปย่อมไม่ยั่งยืน ดังนั้น แว่นตาที่ Google พัฒนาด้วย Process ดังกล่าวก็ยังไม่ได้วางขายตราบเท่าทุกวันนี้
Agile ≠ Scrum มีหลายคนเข้าใจผิดว่าถ้าอยากจะเป็นองค์กร Agile ต้องทำ Scrum เท่านั้น ซึ่งเป็นเรื่องที่ผิดมหันต์ Agile ไม่เท่ากับ Scrum แต่ Scrum คือการตีความ Agile ในรูปแบบหนึ่งเท่านั้น Scrum ยืดหยุ่น และอยู่บนทางสายกลางจึงนิยมนำมาใช้ในการทำ Software ก็เท่านั้นเอง
Scrum จุดที่ไม่เข้มข้น และไม่หละหลวมจนเกินไป สกรัมประกอบไปด้วยองค์ประกอบสามสิ่ง ได้แก่ Roles หน้าที่, Event เหตุการณ์ และ Artifact สิ่งที่ได้จากการกระทำ Scrum
3 Roles
Perfection Scrum บอกว่า Roles ในกระบวนการทำซอฟแวร์มีแค่ 3 Roles ได้แก่
- Product Owner เป็นตัวแทนของผู้ที่มีส่วนได้ส่วนเสีย, เสียงของลูกค้า เป็นคนที่รู้ว่าทำอะไรคุ้มที่สุด เป็นผู้จัดเรียงความสำคัญ item ในการทำงาน และเป็นผู้มีอำนาจตัดสินใจว่าทีมต้องทำอะไร
- Scrum Master เปรียบเสมือนโค้ช, ผู้นำพา, กรรมการผู้คุมกฎ และมีหน้าที่กำจัดอุปสรรคที่คอยขวางไม่ให้ทีมทำงานต่อไปได้
- Team หรือ Development Team เป็นกลุ่มคนที่คอยพัฒนา Software ทำทุกอย่างเพื่อให้สามารถส่งมอบ Product ได้ ทีมต้องเป็น Cross Functional Team ที่ทุกคนในทีมเป็นอิสระต่อกันไม่มีเดอะแบก และมี Self Manage Team โดยไม่ต้องรอให้ใครมาชี้นิ้วสั่ง
แล้ว Team นี่ควรมีสมาชิกกี่คนกันนะ? Perfection Scrum บอกเอาไว้แบบนี้ครับ
Team Size ที่ Scrum แนะนำ ไม่ควรมีสมาชิก 7 ± 2 คน อ้างอิงจากวิจัยตีพิมพ์ ชื่อ The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information ของ George A. Miller ได้บอกเอาไว้ว่ามนุษย์มีข้อจำกัดในการรับสาร และการประมวลผลข้อมูล จำนวนสมาชิก 7±2 คือตัวเลขที่มนุษย์จะสามารถรับข้อมูลที่เกิดจากจำนวนสมาชิกเหล่านี้ได้ และมีบทสนทนาที่พูดคุยกันรู้เรื่อง
5 Events
ในช่วงบ่ายของวันที่ 2 พี่เจนผู้สอนได้เล่าถึง Pain Point ของบริษัทแห่งหนึ่งชื่อขึ้นต้นด้วย O ลงท้ายด้วย Thailand ที่มีปัญหาอย่างมากว่า หลังจากเข้าไปสอนที่องค์กรต่างๆ ลูกค้าประทับใจมาก และอยากทราบว่า
- ที่ Odd-e มี Course อะไรบ้าง
- มี Class อะไรที่เปิดสอนบ้าง ใครคือผู้สอน
- เปิดให้เรียนวันเวลาใดบ้าง รวมถึงอยากให้มีระบบจอง Class ด้วย
โจทย์นี้ถูกโยนมาที่ Team ให้ช่วยกันคิด Product ที่จะช่วยทะลาย Pain Point ของ Real User
- พวกเราเริ่มจากการคิดว่าจะทำ Product อะไรและสรุปได้ว่าจะทำเป็น Website ODDS| Training
- List Feature ที่พวกเราคิดว่าจะสามารถแก้ปัญหาให้กับ Real User ได้
- โดย Team จะต้องเข้าไปคุยกับ Business Domain Expert เจ้าของ Requirement ตัวจริงเสียงจริงเพื่อทำ Product ออกมาให้ตรงจุดมากที่สุด รับบทโดยพี่รูฟ
- และนำ Card เหล่านั้นมาเรียงใส่ใน Product Backlog ให้เป็นแถวเดียว
Events เป็นสิ่งที่เกิดขึ้น same time, same place ตาม Perfection Scrum ประกอบด้วย 5 Events ดังนี้
- Sprints
- มักเกิดขึ้นรอบละ 1 - 4 weeks
- ระยะเวลาขึ้นอยู่กับ Product Owner ที่จะสามารถยอมรับได้ว่านานเท่าไหร่ที่ Product Owner จะยอมทนไม่เปลี่ยน Requirements
- รอบของ Sprints ขึ้นอยู่กับ Product ว่ามีการแข่งขันสูงหรือไม่ เช่น ถ้าเป็น Ecommerce ควรที่จะสั้นกว่า เพราะอยากเห็นของเร็ว เป็นต้น
2. Sprints Planing (10% of Sprint)
- Planing Part I ใช้เวลาทั้งสิ้น 5% ของทั้ง Sprint พาร์ทนี้เป็นพาร์ทที่ทีมต้องถาม Why? ทำไม Sprint รอบนี้จึงมีความสําคัญและจะสร้างมูลค่ากับ Product Owner และ What? ด้วยระยะเวลาเท่านี้ Product Owner อยากเห็นอะไร และให้ Product Owner ช่วยเรียง Order ของ Item มาว่าอะไรเป็นสิ่งที่สำคัญและทำให้เกิด Values ต่อ Product นี้มากที่สุด
- Planing Part II ใช้เวลาทั้งสิ้น 5% ของทั้ง Sprint เช่นกัน เราเรียกพาร์ทนี้ว่า Detail Design เป็นสิ่งที่ Team จะต้องถามตัวเองว่า How? จะทำงานที่ได้รับมาให้เสร็จได้อย่างไร & How much? และเท่าไหร่ ช่วยกันออกแบบ Task ร่วมกัน ให้เสร็จตาม Definition of Done ที่กำหนดไว้
- และ Sprints Planing ก่อให้เกิดผลพลอยได้ นั่นคือ Artifact ที่เรียกว่า Sprint Backlog ซึ่งเราจะกล่าวถึงในหัวข้อถัดไป
3. Daily Scrum ≠ Stand up meeting
- Daily Scrum คือเวลาที่ Team มาพูดคุยกันว่า เมื่อวานทำอะไร, อะไรคือสิ่งที่ขวางไม่ให้เราสามารถไปต่อได้ และบอกว่าวันนี้จะทำอะไรต่อไป
- ในการ Daily Scrum เราจะไม่ยืนคุยกัน กำหนดกรอบของเวลาไว้เพียง 15 นาทีเท่านั้น และผู้ที่เข้าร่วม Daily จะมีเพียง Developer เท่านั้น
- เพื่อให้ทุกคนในทีมรู้ว่าใครกำลังทำอะไรอยู่ เพื่อไม่ให้เกิดการทำของซ้ำกัน และพูดคุยว่าตอนนี้มีปัญหาอะไร ดังนั้น Daily Scrum จึงเป็นการทบทวนถึง Sprint Goal นั่นเอง
4. Sprint Review ≠ Sprint Demo
- การทำ Sprint Reviewใช้เวลาทั้งสิ้น 5% ของทั้ง Sprint เท่านั้น
- Sprint Review คือการให้ User นั่งที่หน้าจอแล้วเล่น ซึ่งต่างจาก Sprint Demo ที่ Team เป็นผู้ที่ Demo งานให้ User ดู
- Sprint Review นั้นสร้าง User experience ต่างจาก Sprint Demo ที่ไม่สร้าง Feedback สักเท่าไหร่ อย่างมากคือการแก้สีของ Product
5. Sprint Retrospective
- Retrospective แปลว่าการทบทวน หากเปรียบ Sprint Review คือการ Review Product ฉันใด Sprint Retrospective ก็เปรียบเหมือนการ Review Process ฉันนั้น
- Team ให้ feedback ว่า Sprint ที่ผ่านมามีอะไรดี ไม่ดีบ้าง สิ่งไหนที่เราจะ Keep going และแก้ไขมัน
3 Artifact
พี่รูฟได้กล่าวเอาไว้ว่า Artifact คือ ผลข้างเคียง เฮ้ยย ผลพลอยได้จากการทำ Scrum
- Product Backlog(Items)
- Product Backlog มักประกอบไปด้วย Stories, Feature, Technical Works, Bug, Knowledge Acquisition(POC)
- พี่รูฟกล่าวเอาไว้ว่า Product Backlog ที่ดีจะต้อง ODDS
Order ถูกเรียงเอาไว้อย่าง Well Shape
Detail Appropriate มีรายละเอียดที่มากพอให้หยิบไปทำโดยไม่มีอะไรติดใจ ไม่มีอะไรที่ควรต้องถาม Product Owner และเพียงพอล่วงหน้าสำหรับ 1–2 Sprints
Dynamic พร้อมที่สลับสับเปลี่ยนได้ตลอดเวลาตามสถานการณ์
Sizing มีขนาดที่พอเหมาะไม่มากไม่น้อยจนเกินไป
2. Sprint Backlog
- Team จะค่อยๆลำเลียง Backlog Card แต่ละใบที่ถูกเรียงโดย Product Owner ใน Product Backlog เข้ามาใน Sprint เท่าที่ทีมคิดว่าไหว
- มักยืม Board ของ Kanban มาใช้ ประกอบด้วย ToDo, Doing, Done เป็นต้น
- Sprint Backlog เป็นสิ่งที่ Product Owner ไม่มีสิทธิ์มายุ่งเด็ดขาดเพราะเป็นสิ่งที่เป็น Commitment ที่ Team ตกลงกับ Product Owner แล้ว
- ถ้าเกิดมีการ์ดที่ทำไม่เสร็จล่ะ ง่ายๆเลย คือเอามันกลับเข้าไปใน Product Backlog แล้วให้ Product Owner Order มันอีกครั้งใน Sprint ถัดไป
3. Potentially Shippable Product Increment
- อีกหนึ่งผลพลอยได้จากการทำ Scrum นั่นคือ Product ที่พร้อมต่อการ Release ทุกเมื่อ
Activity ≠ Events
Activity ไม่เท่ากับ Events เป็นสิ่งที่เราไม่ทำใน Sprint ก็ได้ แต่เป็นกิจกรรมที่ควรทำ ได้แก่ Product Backlog Refinement คือเวลาที่เราจะกลับมาดูว่า Product Backlog ของเรานั้นยัง Well Shape อยู่หรือไม่ นั่นคือการมา Refine ว่ารายละเอียดของการ์ดแต่ละใบใน Product Backlog มีดีเทลมากพอที่จะหยิบไปทำโดยที่ไม่ต้องไปถาม Product Owner หรือเปล่า มักทำในช่วงเวลา กลาง Sprints
ขั้นตอนการทำ Product Backlog Refinement ประกอบด้วย
- Clarify Business Scope เข้าใจถึงปัญหาของ User และถามให้ชัดว่าทำไมของสิ่งนี้จะมี Values กับ Product
- Split Item หั่นไอเท็มที่มีให้บางที่สุด เพื่อให้ปัญหานั้นง่าย ทำได้เร็ว และเกิด feedback loop ที่ต่อเนื่อง
- Estimate ประเมินความยากของไอเท็มแต่ละชิ้น อาจใช้วิธี Poker Card ให้คะแนนการ์ดโดยคำนึงถึงความสามารถ ประสบการณ์ของตนเอง
Day 3
LeSS = Large Scale Scrum เป็น Scrumในรูปแบบที่ใหญ่ขึ้นในระดับองค์กร แล้วอะไรคือสิ่งที่ต่างกันระหว่าง LeSS และ Traditional Scrum ล่ะ นั่นสิ ผมก็ไม่รู้55555หยอกกก
ในวันที่สามของคลาส Scrum 3 days เป็นวันที่เราจะมาจำลองสถานการณ์การทำ Scrum ในสเกลที่ใหญ่ขึ้น พวกเราชาวออดส์ที่ถูกแบ่งออกเป็น 9 ทีมย่อย ตอนนี้ได้รับจากโจทย์ว่าที่ผมได้เล่าไปใน Day 2 เพื่อแก้ปัญหาในเรื่อง Service ของ ODDS
เอาล่ะ แต่เราจะไม่ทำ Scrum แบบ Traditional Scrum แล้วนะ สิ่งที่เราจะทำคือ Large Scale Scrum นั่นเอง
- พวกเราทั้ง 9 ทีม เริ่มต้นจากการเอา List Feature ของแต่ละ Team ที่เหมือนกันมา Merge รวมกัน จากนั้นเราก็เข้าสู่กระบวนการ Scrum Events ตั้งแต่การทำ
- Sprint planing Part I สิ่งที่ LeSS ต่างจาก Traditional Scrum คือ ทุกๆทีมจะเข้าไปถาม Product Owner พร้อมๆ กันว่า Sprint นี้ Product Owner อยากได้อะไร และขอให้ Product Owner ช่วย Order Card มาได้มั้ย
- Sprint Planing Part II แต่ละ Team จะหยิบการ์ดจาก Product Backlog และช่วยกัน Design แต่ละ Task โดยแต่ละ Team จะหยิบการ์ดจนกว่า Capacity ของทีมจะเต็ม แต่ก่อนจะทำ Planing Part II ทุกทีมจะกำหนด Definition of Done ให้ตรงกัน (ต้องถูก Approved by Product Owner) และถ้ามีอะไรที่เราสงสัยเกี่ยวกับ process ทีมจะเดินเข้าไปถาม Scrum Master รับบทโดยพี่รูฟของเรา
- ทุกทีมจะแชร์ Resource และ Sprint Backlog ของทีมตัวเองให้ทั้งองค์กรมีภาพเดียวกัน พี่เจนใช้วิธีการให้ทุกทีมทำ Gallery Walk รอบละ 5 นาที วนให้ครบ 9 กลุ่มโดยให้ 1 คนในทีมเป็น Host คอยเล่าเกี่ยวกับ Card ที่ทีมได้รับ และสมาชิกคนอื่นเดินไปแต่ละทีมในห้องประชุมเพื่อรับสารจาก Host
- หลังจากแชร์ Resource ทุกทีมก็เริ่มทำ Card ของตัวเองโดยไม่แบ่งว่าทีมคนไหนคือ Frontend หรือ Backend และทุกคนจากแต่ละทีมสามารถเดินเข้าไปยื่นมือช่วยเหลือทีมที่งานล้นมือได้ เพราะตอนนี้เราทุกคนถือ Sprint Backlog เดียวกันอยู่
พวกเราจำลองเวลา 1 วัน ให้เท่ากับระยะเวลา 3 sprint sprint ละ 120 นาที ซึ่งเป็นเรื่องที่บ้ามาก แต่มันโคตรสุดยอด sprint แรกจบลงแบบทุลักทุเลมาก ยังไม่มีแม้กระทั่ง List ของ Course แต่สุดท้ายพวกเราเด็กสหกิจทั้ง 9 ทีม ก็สามารถที่จะทำเว็บไซต์(ผมเรียกมันว่า Skooldiodds 5555555555+) ที่สามารถแก้ปัญหาให้กับ Real user ได้
จากทั้งสามข้อจะเห็นได้ชัดเลยว่า LeSS มีสิ่งที่ต่างจาก Traditional Scrum อยู่ สรุปได้ดังนี้
- Team ทุกทีมจะมี Product Backlog เดียวกันที่ถูกแชร์กันทั้งองค์กรr และ Product Backlog นี้จะต้องมีความ ODDS ด้วยนะ
- Single Definition of Done พวกเราทุกทีมจะต้องกำหนด Definition of Done ร่วมกันที่ทุกทีมสามารถทำตามข้อกำหนดนี้ได้ครบถ้วนจึงนับว่าเป็น 1 ข้อใน Definition of Done และที่สำคัญ ต้องเป็น Definition of Done ที่ Product Owner ยอมรับได้ด้วย
- All teams work on a common sprint ทีมทุกทีมทำงานด้วยการโฟกัสที่ Product เดียวกันโดยไม่แบ่งว่าเป็น Sprint ของใครของมัน
Product Owner ควรมี 1 คนตาม Perfection Scrum
Scrum Master 1 คน หรืออาจมีจำนวนประมาณหนึ่ง เพราะต้องดูแลหลายทีม
Many Team แต่ Focus ที่ Features ที่ต่างกัน แต่ๆๆๆๆๆ ทุกทีมจะยึดถือ Product Backlog เดียวกัน
1 Product Backlog ทุกทีมต้องสามารถแชร์ Resource ให้กันและกันได้ โดยไม่มีกำแพงระหว่างกัน
สรุป เมื่อไหร่ ที่ควรทำ Scrum กันนะ
จาก Stacey Matrix ถูกคิดขึ้นโดย Ralph Douglas Stacey ได้กล่าวเอาไว้แบบนี้
ยิ่งเราเข้าใกล้แกน 0 คือ เราเข้าใจถึง Techonology และ Requirements มากเท่าไหร่หมายความว่างานนั้น Simple และไม่เปลี่ยนแปลง เราควรใช้สิ่งที่เรียกว่า “Defined process” แต่ถ้าเมื่อไหร่งานที่ทำเริ่ม Complicated และไกลจากสิ่งที่เรารู้ เราอาจเริ่มมองหา framework อื่นของ agile มาใช้ ซึ่ง Scrum ก็เป็นอีกหนึ่งทางเลือกที่ไม่เข้มข้น และไม่หละหลวมจนเกินไป จงคำนึงอยู่เสมอว่า Product เป็นเพียงผลพลอยได้ของการทำ Scrum แต่ผลลัพธ์ของการทำ Scrum ที่ชัดเจนที่สุดนั่นคือ Team
จงทำ Agile เมื่อเรารู้ว่า Agile ให้อะไรแก่เรา อย่าทำ Agile เพียงเพราะเห็นคนอื่นทำ
สุดท้ายแต่ไม่ท้ายสุดขอให้เครดิตการรวบรวมข้อมูลจากเหล่าทีม Generation at ODDS ช่วยตอบคำถามในสิ่งที่ผมทำตกหล่นไป ในขณะที่เขียนบทความนี้
ขอบคุณพี่รูฟ พี่เจน ที่เปิดคลาสที่ยอดเยี่ยมแบบนี้ให้เด็กสหกิจได้เรียนรู้ และขอบคุณพี่รูฟสำหรับชาบูเพนกวิน กราบส์
เพราะเราเชื่อว่าการทำซอฟแวร์ต้องสนุก และเราเชื่อในเรื่องการฝึกฝน Scrum 3 Days By Nobody :)
Resource:
