[แชร์ประสบการณ์] หลักสูตร 3 เสาร์ กับ การปรับประยุกต์ Agile principles กับการบริหารจัดการงาน IT และการบริหารจัดการโครงการ

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

จากที่ได้ติดตาม FB Page ของสยามชำนาญกิจ และ follow พี่หนุ่มทาง FB เพื่ออัพเดตความรู้ต่าง ๆ และโชคดีที่มีโอกาสได้เข้าร่วม “หลักสูตร 3 เสาร์ กับ การปรับประยุกต์ Agile principles กับการบริหารจัดการงาน IT และการบริหารจัดการโครงการ” ที่จัดขึ้น ฟรี!!!

วันเสาร์ที่ 21 กันยายน พ.ศ.2562
วันเสาร์ที่ 28 กันยายน พ.ศ.2562
วันเสาร์ที่ 5 ตุลาคม พ.ศ.2562

สถานที่จัด SCK Dojo ชั้น 10 อาคารพร้อมพันธุ์ 3 ซอยลาดพร้าว 3

เนื่องจากเนื้อหาในแต่ละวันมีรายละเอียดปลีกย่อยเยอะพอสมควรทีเดียว จำบ้าง จดบ้าง จดแล้วอ่านออกบ้างไม่ออกบ้าง สำหรับใน blog นี้ขอ recap เฉพาะในส่วนที่สนใจนะคะ

อุปกรณ์เพียบบบบ

เสาร์ที่ ๑

Agile is “Culture Change”

ประวัติของ Scrum

Scrum master ทุกคนน่าจะผ่านหูผ่านตากับ ​v.2017 กันมาบ้างแล้ว วันนี้มีโอกาสได้ทำความรู้จักกับ v.1995 กันบ้าง

Scrum 1995 ก็เป็นพื้นฐานของ scrum ในเวอร์ชันปัจจุบันที่ใช้อยู่นั่นเอง โดยผู้ริเริ่มแนวคิดและออกแบบคือ Dr. Jeff Sutherland และ Ken Schwaber ได้รวบรวมข้อมูลเอาไว้ในเอกสาร SCRUM Development Process สารภาพเลยว่าไม่เคยรู้มาก่อนเลยค่ะ

(http://www.jeffsutherland.org/oopsla/schwapub.pdf)

ขอยืมรูปจาก pinterrest นะคะ https://www.pinterest.com/pin/41447259051351283/?lp=true

โดยใน v.1995 จะมีการลงรายละเอียดในบางส่วนที่ v.2017 ไม่ได้กล่าวถึงเลย เช่นรายละเอียดในแต่ละ เฟสว่าต้องโฟกัสที่ส่วนไหนและทำอะไรบ้าง โดยแบ่งออกเป็น 3 phase คือ

Scrum Methodology

1. Pregame ไม่คุ้นกันเลยหละสิ แต่ถ้าบอกว่า Pregame=Planning คงจะร้องอ๋อ… โดยจะประกอบไปด้วย Planning และ Architecture/High Level Design โดยในเอกสารฉบับบนี้จะบอกอย่างละเอียดเลยว่าต้องทำอะไรบ้าง

2. Game หรือก็คือช่วง Development Work (Sprint)

3. Post Game ช่วงปิด project/ sprint

General Agile Software Development Picture

Change the Development and Delivery Approach

เปรียบเทียบการทำงานแบบ waterfall vs Iterative

Business cycle and Development cycle

• รอบการส่งมอบควรอยู่ระหว่าง 1-6 เดือน แต่ละรอบเราเรียกว่า Release (จริง ๆ จะเรียกว่า Season ก็ได้
• development cycle อยู่ระหว่าง 1–3 weeks และเรียกแต่ละรอบว่า Iteration หรือจะเรียกว่า Episode ก็ได้
• ช่วง End Game (Final Check) และต้องซ้อม Deploy ด้วยนะ

Mini Waterfall

อาการมินิ waterfall ใน scrum มันเป็นยังไงนะ mini waterfall แบ่งออกเป็น 2 รูปแบบ

• Testing at the End of the Iteration
• Testing in the next Iteration

โดนเลย mini waterfall ตั้งแต่ข้อแรกเลย ยาวจนถึงบางก็มีข้อสอง ส่วนวิธีการหลีกเลี่ยง mini waterfall ก็คือ

• Integrate testing and coding เดฟไปด้วยเทสไปด้วยเป็น full stack
• Focus the whole team on testing ทุกคนในทีมควรจะเทสได้
• Limit work in progress กำหนด work limit ในการทำงาน
• Rule of thumb of story size
• No story is done until tested ต้องผ่านการเทสทุก story ถึงจะเรียกว่า done
• UNDER commit

เกร็ดเล็กเกร็ดน้อยสำหรับวันนี้ …

• PO ต้อง Trust Dev ไม่ก้าวก่ายการ assign งานใน dev (ไปเตรียมของไป !!!)

วันนี้ไม่ค่อยได้เตรียมตัวจดสักเท่าไหร่ กลับมานั่งทบทวนอีกทีลืม!!! ก็ได้เท่านี้แล เสาร์หน้าจะตั้งใจเรียนกว่านี้นะคะ

เสาร์ที่ ๒

วันนี้เปิดตัวด้วยเรื่องของการทำ Sprint Retrospective ซึ่งเป็นอีกหนึ่งพิธีกรรมสำคัญสุดท้ายก่อนปิด Sprint และต้องเกิดหลังจาก Sprint Review

ดังนั้น feedback ต่างๆ ที่เกิดจาก user หรือ Stakeholder สามารถหยิบยกมาคุยกันได้ โดยทีมทั้งหมดอันได้แก่ Product Owner , Development Team จะต้องเข้าด้วย รวมทั้งอาจจะเชิญคนอื่นเข้ามาเช่น Stakeholder หรือผู้ที่เกี่ยวข้องเข้ามาได้ด้วย เช่นถ้ามีประเด็นที่ Product Owner ตอบไม่ได้ แต่ต้นสายปลายเหตุมาจาก Stakeholder ที่เป็นเจ้าของ requirement ก็สามารถเชิญเข้ามาได้ด้วย และที่สำคัญ Sprint Retrospective ต้อง facilitate โดย Scrum Master

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

การที่ scrum master เป็นคน facilitate sprint retrospective เพราะตลอดระยะเวลา scrum master ต้องคอยเก็บ evidence ทีมทุกอย่างว่าทีมควร improve อะไรบ้าง ดังนั้นจึงเป็นคำตอบว่า scrum master ควรจะต้องอยู่กับทีมว่าทีมขาด skill เรื่องอะไรบ้าง ทั้ง technical skill และ soft skill ด้วย

ซึ่ง scrum master ไม่ใช่แค่มา run scrum จบแล้วก็ไป จะต้องอยู่กับทีมตลอด

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

→สำหรับกรณีที่มีการจ้าง Outsource
ถ้าใช้ Scrum หน้าที่ของ Scrum Master คือการ Build Capability ของ Outsource ให้ดีขึ้น ในขณะเดียวกันก็จะต้อง Build Capability ของ Product Owner ด้วย

คำถามคือถ้าเป็น Product Manager … ถ้าต้องจ้าง Scrum Master จากข้างนอก เราจะจ้างเพื่อมา Build Outsource หรือไม่ ?

→ สำหรับกรณีที่จ้าง Outsource แล้วมี SM ติดมาด้วย
การมี Scrum Master มาส่วนใหญ่จะจะควบต่ำแหน่ง Dev หรือ PM ของฝั่ง Outsource เพื่อจะเข้ามาคุม Project ดังนั้น SM คนนี้ก็ย่อมรักษาผลประโยชน์ของบริษัทของตัวเอง

แต่พอมาเป็น Scrum Master จริง ๆ จะต้อง Balance ตัว ROI และ Capability ดังนั้นถ้าจะต้องใช้ Scrum และเลี่ยงไม่ได้ Scrum Master จะต้องอยู่ในฝั่งของผู้ว่าจ้างเพื่อรักษาผลประโยชน์ขององค์กร

และที่สำคัญการเป็น SM ถ้าจะไปอยู่ในธุรกิจไหน ต้องเข้าใจธุรกิจนั้นด้วยว่าเป็นอย่างไรและฝั่ง development ทำงานอย่างไรด้วย

กลับมาต่อที่การทำ Retrospective ถ้ากลับไปอ่านที่ Scrum Guide การหาจุดที่โฟกัส (Inspection)โดยสิ่งที่สามารถหยิบยกมาพูดคุยกัน ได้แก่

1. Product : product ที่ออกมา
2. Process : สามารถนำ scrum ที่รันเป็น sprint นำกลับมาดูว่า effective หรือไม่
3. People โดยแยกเป็นหลาย ๆ ส่วนได้แก่

• Skills คนของเรามี skills เพียงพอหรือไม่ทั้งส่วนของ technical และ soft skills
• Knowledge มีความรู้ความเข้าใจในตัว business ที่ทำแค่ไหน
• Relationship แยกออกเป็น 2 ส่วนคือความสัมพันธ์ทั้งภายในทีม และนอกทีม

4. Tools เช่น มีเครื่องมือที่จะต้องใช้มากหรอน้อยเกินไปหรือไม่ รวมถึงคนที่ใช้มีความรู้พอที่จะใช้ tools หรือไม่

และตัว scrum master เองจะต้องมี backlog หรือแผนการทำงานของตัวเองว่าสภาพของทีมเป็นอย่างไร และแต่ละ sprint ทีมจะต้องดีขึ้นอย่างไรบ้าง

หลังจากจบ Retrospective ก็จะได้ post-it ที่มีจุด (dot vote ที่เรารู้จักนั่นแหละ) เป็นสิ่งที่ทีมตกลงกันว่าเราจะทำสิ่งนี้กันนะ ซึ่งจะมีไอเดียที่คนในทีมเสนอมาแล้วรู้สึกว่าเอาไอเดียนี้ ถ้าปัจจุบันเราใช้ jira อยู่ ชุดไอเดียนี้ต้องถูกแปลงเป็น BPI แล้วไปอยู่ใน board jira และเป็นของที่ต้องทำใน sprint ถัดไป แล้วก็จะไปอยู่ในช่อง to do ของ sprint ถัดไปโดย default เพราะปกติของที่จะถูกดึงไปในช่อง to do จะต้องให้ product owner ตัดสินใจ แต่สิ่งนี้ตัดสินใจกันครบแล้วเพราะ product owner , dev team และ stockholder เข้า แล้วเห็นชอบร่วมกันว่า sprint หน้าเราจะพัฒนาตัวเองให้ดีขึ้น

หลังจากจบในส่วนของการ Retrospective ก็มี Workshop ให้เข้าใจเส้นทางของการทำของการทำ User Story ไปจนถึงการ Deliver งานในแต่ละ Cycle

เสาร์ที่ ๓

สำหรับวันสุดท้ายเริ่มต้นด้วยการลงรายละเอียดในการทำ Release Planning ให้มากขึ้นโดยปกติแล้วถ้าเราพูดถึงบริบทของ Project Management สิ่งที่จะต้องทำมีดังนี้

1. Scope (ขอบเขต) การทำงานโดยสิ่งที่ scope จะ link ลงมาก็คือ architecture ที่จะต้องได้ เพราะถ้าไม่มี architecture ปลายทางก็จะไม่สามารถคำนวณต้นทุนได้อยู่แล้วว่าจะต้องซื้อ server เพิ่มหรือไม่
2. Time (ระยะเวลา) เริ่มโปรเจคเมื่อไหร่ จบโปรเจคเมื่อไหร่และรวมถึง milestone ต่าง ๆ ก็คือ outcome ในหนึ่งช่วงเวลานั่นเอง
3. Cost (ต้นทุน) ที่จะต้องใช้
4. Quality (คุณภาพ)โดยพี่หนุ่มให้ข้อมูลว่าใน quality นี้จะมีองค์ประกอบทั้งหมด 19 ตัว ซึ่งการเทสเป็นแค่หนึ่งในนั้นเท่านั้น (เดี๋ยวต้องไปหาข้อมูลเพิ่มเติมละว่ามีรายละเอียดอะไรบ้าง)โดยงานเทสก็จะถูกลิงก์ไปถึง Test Environment และ Test Data ด้วย

ดังนั้นสิ่งเหล่านี้ควรถูกกำหนดก่อนที่จะเริ่มโปรเจค หรือถ้าบางหัวข้อยังไม่ชัดอาจจะสามารถเข้ามาสู่ช่วง Release Planning ได้ หลังจากนั้นควรจะมีการ distribute แผนและควรจะมีการเรียก kickoff เพื่อสื่อสารให้คนเข้าใจ (อืม … ชีวิตจริงก็เริ่มโปรเจคตอน kickoff เนี่ยแหละ)

ดังนั้นไม่ว่าจะเป็น agile coach,scrum master หรือ project manager ก็จะต้องมีความรู้เรื่อง project management ถ้าไม่มีพี่หนุ่มแนะนำว่าให้ไปลงเรียนให้เข้าใจก่อน

กลับมาพูดถึงคำว่า Scrum ถูกสร้างโดย Ken Schwaber กับ Jeff Sutherland ซึ่ง Jeff เป็น CTO เป็นคน manage โครงการและพบปัญหากับเจ้าของบริษัท IT เนื่องจากไม่สามารถส่งมอบงานได้ ดังนั้นจึงคิดรูปแบบในการ manage โครงการขึ้นมาใหม่ให้ฝั่ง business ได้รับข้อมูลตลอดเวลาว่างานถึงไหนแล้ว และนี่ก็คือที่มาของ Scrum

Scrum จึงถูกนำมาใช้ในการ manage โครงการเยอะ ๆ ยกเว้นอย่าใช้กับโปรเจค IT เพราะหลังจากพ้นช่วงเดลี่ scrum ไปแล้ว scrum ไม่ได้บอกว่าให้ทำงานอย่างไร จึงทำให้มีความเป็น mini water เล็ก ๆ ขึ้นมา และ scrum guide ไม่ได้กล่าวถึงสิ่งต่าง ๆ ข้างต้นทั้งหมด

อีกเรื่องที่จะต้องระบุให้เรียบร้อยในช่วง Initial คือ ความเสี่ยงต่าง ๆ ที่อาจจะเกิดขึ้น (Risk) ทั้งหมดที่กล่าวมาข้างต้น เราเรียกช่วงนี้ว่า Release Initial

Release Planning

• Business Understanding ต้องเข้าใจโจทย์ก่อน เช่นที่มาที่ไปของโครงการ
• Technical Challenge อะไรบ้าง เช่น automation test แต่ทีมไม่มีความรู้ , environment ไม่พร้อมที่จะทำ automation test
• ให้แน่ใจว่า Resource ของการเทสทั้งหมด available โดย resource ในที่นี้ไม่ใช่คน แต่คือเครื่อง server อุปกรณ์ หรือแม้กระทั้ง data ต่าง ๆ
• ต้องรู้ด้วยว่าจะ pack software ขึ้นอย่างไร , มีเทรนนิ่งหรือไม่
• Communication Plan ให้คนรับทราบว่าจะต้องทำอะไรบ้าง
• Dependencies มีใครบ้างที่เกี่ยวข้อง

อ่อ … อีกหนึ่งเรื่องที่จะต้องทราบคือ … เราจะไม่เขียน Code จนถึงวัน Deploy เราจะไม่ Dev จนถึงวันสุดท้าย (ฮ๊ากก!!! แทบกระอักเลือด หนังชีวิตล้วน ๆ ) โดยสำหรับพี่หนุ่มจะใช้เวลา 5–10 วัน ในการ freeze development หลังจากนั้นคือขั้นตอนในการซ้อม deploy

กลับมาที่รอบการทำงานกรณีที่เราทำงานเป็นรอบ Scrum Master ควรจะเป็นแผนการทำงานในแต่ละรอบว่ามี activities อะไรบ้าง เมื่อไหร่ วันไหน ใช้เวลากี่นาที

ควรถามหาสิ่งนี้จากคนที่เรียกตัวเองว่า Scrum Master ขอตารางการทำงานทั้งหมด (โหย … เดี๋ยวกลับไป office จะรีบกลับไปจัดเลย)

ตัดเข้าช่วงคำถามที่น่าสนใจจากเพื่อนบ้านโต๊ะข้าง ๆ …

ถ้าเราไม่ได้ใช้ scrum framework อย่างเต็มสูตร เพราะมี limitation บ้างอย่าง แต่ … เรามีรอบการทำงาน ซึ่งก็ไม่อยากใช้คำว่า sprint หรือว่าเราใช้ agile เวลาที่เราต้อง present กับบุคคลภายนอก เราควรจะบอกว่าอย่างไร

คำแนะนำจากูรู … จะใช้คำว่า Integration/Cycle/Drop/Episode/Season อะไรก็ได้ โดยพี่หนุ่มใช้ . Heart Of Agile ของ Dr.Alistair Cockburn กล่าวคือทำอย่างไรก็ได้ ถ้า check point คือ 4 คำนี้

1. Collaboration มีเป้าร่วมกันในการมาทำงานร่วมกัน
2. Deliver (Early and Often)
3. Reflect การหยุดแล้วมองกลับมาว่าผลลัพท์ที่ได้จากการ deliver ที่เกิดจากการทำงานร่วมกัน มีจุดไหนที่จะปรับปรุงให้ดีขึ้นได้
4. Improve

Plan for Visibility

Roles in Release Planning

Multiple Teams — Integration

Rolling Backlog Alternative

ขอแทรกสักหน่อย ฟังพี่หนุ่มพูดแล้วอันนี้ขำดีแต่มีสาระ

Scrum Master ต้องไม่ทำตัวให้เป็นมัคทายกวัด กล่าวคือ มัคทายกจะไม่สนใจว่าแขกที่มาจะสวดได้หรือไม่ ทำหน้าที่ของตัวเองให้จบ ๆ ไป แต่ … Scrum Master จะต้องทำตัวเป็น Facilitator มี 4 เรื่องดังนี้

• จุดประสงค์ของ Event นั้น ประกอบด้วยอะไรบ้าง
• กรอบเวลาหรือ time-box
• กฎ/กติกา/มารยาทต่าง ๆ
• ให้ feedback ทุกคน

Requirements

Functional Requirement ก็คือ Domain Knowledge เช่นถ้าทำ Banking ก็ต้องมีความรู้ในเรื่อง Banking เป็นต้น ส่วนของ Non-Functional Requirement ในเรื่องของ software architecture ต่าง ๆ

Requirements = Function Requirements + Non-Functional Requirements

พี่หนุ่มบอกว่าสมการด้านบนมาจาก website microservice.io ต้องเข้าใจก่อนว่า micro service เกิดมาเพราะรับ load ไม่ได้ ไม่ได้เกิดมาเพราะฟังก์ชันมี bug เยอะ

Extreme Programming (XP)

1. User Stories จะประกอบไปด้วย requirements โดยทั้งหมดจะถูก feed เข้าไปใน การทำ Release Planning
2. กรณีที่มี Spike หรือก็คือ Uncertain Estimate จะต้องมีการนำไปทดลองก่อน เพื่อให้ได้สิ่งที่เรียกว่า Certain Estimate เนื่องจากหลังจากจบ release plan จะต้องบอกได้ว่าต้องใช้กี่ Iteration
3. จบจาก Iteration จะต้องได้ในสิ่งที่เรียกว่า release ล่าสุด และนำไป check กับ acceptance test อีกครั้ง (กรณีไม่ผ่านจะกลายเป็น bug)
4. Acceptance test ควรมาตั้งแต่ User Story
5. เมื่อตรวจรับเรียบร้อยแล้ว ก็ทำการ Small releases

Rule of Extreme Programming (XP)

เล่าเรื่องก่อน คนที่สร้าง XP ขึ้นมาชื่อ Kent Beck และเคยทำงานในบริษัทที่ Ken Schwaber ที่เป็น Scrum Master มาก่อน ก็จะนำ Scrum บางส่วนมาใช้ ถ้าดูตามรูปด้านล่าง กฎ กติกา มารยาท ก็ดูจะมากมายทีเดียว และจำเป็นต้องทำให้ครบทุกข้อ เพราะ Fix XP When It Breaks

• Customer is always available หมายถึงต้องพร้อม ถ้ามีคำถามในการทำ software ต้อง response ทันทีเพราะรอบการทำงานค่อนข้างเร็ว
• ทุก Production Code ต้องเขียนโดย Programmer 2 คนเสมอ จะได้มีคนที่งานแทนกันได้
• ณ หนึ่งช่วงเวลาให้มีแค่ 1 คู่เท่านั้น ในการ integrate ไปกับของที่ทำงานได้
• ทุกครั้งที่ commit ต้องมีการ integrate เทส
• ทุกคนสามารถแก้ไข Code ซึ่งกันและกันได้

พี่หนุ่มขิงกลับว่า มีใครเห็นอะไรแบบนี้ไหน Scrum ไหม …. No!!
ไม่เท่านั้นยังโชว์อีกว่า developer 3 คนของพี่หนุ่มนั้น commit code 300 ครั้งต่อวัน No!! (1 method แล้ว commit : baby step)

Acceptance-Test Driven Development

ควรทำในช่วงที่เรียกว่า product backlog refinement โดยใช้เวลา 10% ของการทำงานทั้งหมด และแบ่งออกเป็น 4 session
Create Stories
Define Acceptance Tests สร้างตารางเคส (case , data test)
Expand Test, Think about coding
Re-Visit Iteration Goal and Stories that ready

เมื่ออยู่ในช่วง Iteration WIP ในการทำงานแบบ Scrum คือทำทีละชิ้น

ปิดท้าย blog นี้ด้วย Slide นี้ Self-Managing Team

คุณคิดว่า board นี้ควรอยู่ที่ไหน

…. ในถ้ำหลวงไง (ชอบ NO IDEA IS STUPID IDEA อ่า)

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

สุดท้ายต้องขอขอบพระคุณพี่หนุ่มที่เสียสละเวลา สอนก็ฟรี วันแรกก็เลี้ยงข้าวเที่ยงด้วย ขนมก็มีแจกทุกวัน ขอบคุณจริง ๆ ค่ะ