เกร็ดที่ได้จาก ICAgile Certified Professional (ICP)
เมื่ออาทิตย์ที่แล้ว บริษัทส่งพนักงานทั้งหมดไปเรียน Agile Coaching Fundamentals ร่วมกันแบบไม่แคร์ว่าคุณอยู่แผนกอะไร ต้องบอกว่าเป็นโอกาสที่ดีมาก เริ่มงานได้สองวัน ขึ้นขบวนรถไฟไปเรียนทันในรอบนี้พอดี
คอร์สนี้เหมาะกับใคร?
ชื่อคอร์สบอกว่าเป็นคอร์สเพื่อเรียนรู้พื้นฐานการทำงานแบบ Agile ซึ่งสำหรับเราคิดว่า
เหมาะกับคนที่ไม่เคยได้เห็นการทำงานแบบ Agile มาก่อน
เพราะทางเซนเซย์ทั้งสอง (Victor Nunez, Khana Chindamaikul) ที่สอนคอร์สนี้มีวิธี break the ice และสารพัด exercises ที่ดีมากๆ และยังเป็นผู้เชี่ยวชาญที่ coaching เรื่องนี้มาแบบเข้มข้น แล้วการเน้นย้ำใน value ของ Agile ที่จับต้องได้จริง use case จริงจากประสบการณ์ของผู้สอน มันทรงพลังมากพอจะทำให้พูดได้ว่า
สำหรับคนที่ทำ Agile มาก่อนแล้ว ถ้าได้เรียนคอร์สนี้ ก็ถีบตัวขึ้นไปสอนในฐานะผู้ให้ความรู้ต่อได้เลย
ก่อนเรียนเรามีพื้นฐานมาระดับไหน?
บล็อคนี้ขอข้ามไป ไม่ลงลึกเรื่อง Agile นะคะ อาจจะมีบล็อคอีกอันไว้เล่ารวมๆถึงประสบการณ์ที่เราได้มาผ่านการทำงานแบบ Agile อีกที ดังนั้นครั้งนี้อยากพูดถึง Agile ที่เราเองก็เพิ่งรู้ว่าเบื้องลึก เบื้องหลังมันเป็นเพราะอย่างนี้ หรือบางเรื่องก็รู้ทั้งรู้ว่าต้องทำแบบนี้ แต่มันหาคำมานิยามไม่ได้ ให้เหตุผลกับมันไม่ได้ ส่งผลให้ถ่ายทอดให้คนอื่นต่อไปไม่ได้ไปด้วย
เราเริ่มย่างเท้าเข้าสู่โลก Agile ผ่านการใช้งาน JIRA ก่อนจะมาใช้ JIRA เคยใช้ Asana มาก่อน แล้วมันไม่ตอบโจทย์ Software production เท่าไหร่ เลยหารือกับน้อง tech di เพื่อหาอะไรมาเปลี่ยนมัน จนพวกเรามาเจอกับ JIRA
JIRA พาให้เรามารู้จักกับ Scrum ที่ประกอบไปด้วย Roles, Ceremonies และ Artifacts ต่างๆ แน่นอนว่าเริ่มต้นเราก็ follow ส่ิงที่เรียกว่า Agile practice เหล่านี้แหละ จนกระทั่งถึงจุดที่รู้สึกว่าบางอย่างมันไม่ fit กับความเป็นทีมเรา ก็ถึงคราวต้องเปลี่ยน…
แต่มันต้องเปลี่ยนยังไงละ ถึงจะยังไม่เสียคุณค่าความเป็น Agile สาย Scrum ไป
อะไรทำได้ อะไรไม่ควรทำ เมื่อคิดได้อย่างนั้น ก็เริ่มลงลึกไปหาต้นตอของความเป็น Scrum และ Agile จนได้รู้จัก
Agile Manifesto
ได้ลงไปสัมผัส Agile value สิ่งที่การทำงานแบบ Agile ควรจะสร้างให้เกิดขึ้นให้ได้ ไม่ขอลงลึกตรงนี้ มันยาวอ่ะ 5555
หลังจากเรียนรู้แบบมวยวัดมาระดับนึง ก็เริ่มสอนมวยวัดนั้นให้น้องๆในบริษัทเพื่อได้ลองใช้ไปด้วยกัน และเพิ่งมาสัมผัสความสำเร็จแบบจริงจังก็โปรเจคสุดท้าย ถ้าถามว่าความสำเร็จนั้นคืออะไร
ทุกคนในโปรเจค ไล่ตั้งแต่ Developers, Scrum Master, PO ไปจนถึง Stack Holder ทุกคนมีรอยยิ้ม และพลังงานที่พร้อมจะลุยไปด้วยกันตลอดเวลา ไม่ใช่ว่ามันราบรื่น ไร้อุปสรรค แต่มันมีแรงที่เกื้อหนุนซึ่งกันและกัน และมัน positive
ได้เห็นสิ่งนั้น เราก็ตื้นตันอย่างบอกไม่ถูก
พูดถึงความรู้พื้นฐานที่เรามีติดตัวมาก่อนเข้าเรียนแล้ว ก็มาลงเกร็ดเล็กเกร็ดน้อยที่จริงๆเราอยากจะบันทึกไว้เตือนตัวเองต่อไปในภายภาคหน้ากันเลย
Root of Agile is Quality Management
ยังไม่ต้องพูดถึงเรื่องความเร็วในการพัฒนาหรืออะไร แต่สิ่งแรกที่คนทำ Agile ต้องการันตีให้ได้คือคุณภาพ
เราเคยมี Sprint สั้นที่สุด 3 วัน และใน 3 วันนั้น Refactor ไป 4 รอบ (อันนี้คือพลาดนะ ไม่ใช่ว่าดี ถ้าดี เราควรได้วางแผนเรื่องนี้กันตั้งแต่ Sprint Planning)
เราเคยถูกสอนมาว่า Agile เกิดมาเพื่อปรับปรุงรูปแบบการพัฒนาโปรเจคแบบ Waterfall
เพราะฉะนั้นสิ่งที่เกิดมาเพื่อปรับปรุงจุดอ่อนเรื่องความเชื่องช้ากว่าจะได้มาซึ่งผลลัพธ์ของ Waterfall ก็ไม่ควรจะลดทอนจุดแข็งที่ Waterfall ตอบโจทย์ไว้แล้วก็คือ Design ให้ชัดเจน วางแผนให้รัดกุม และทดสอบให้เข้มข้น เพื่อให้ได้คุณภาพขั้นสุด
Document the Result not the How-to
ในความเป็นจริงลูกค้าไม่ได้อยากรู้ว่าเราจะทำสิ่งนั้นๆออกมาให้เค้าได้ยังไง เค้าอยากได้ผลลัพธ์
ใน Agile Manifesto มีข้อนึงที่บอกว่า “Working Software over full documentation” ไม่ได้หมายความว่าไม่ต้องมี document เลย แต่ให้มีพอจะ implement ต่อได้ มีพอที่จะนั่งคุย Sprint planning กันแล้วเห็นความเสี่ยง เห็นภาพที่ชัดเจน
document ที่ทำจะออกไปในทางสิ่งที่ทำให้ทุกคนมั่นใจว่าผลลัพธ์ที่ได้เป็นไปตามที่ตกลงกันไว้จริง เช่น User Acceptance Testing
ROI, not only money is the investment but also energy and soul
เฮ้ย อันนี้คือสุดอ่ะ แบบว่า เราไม่เคยตอบได้ว่าทำไมเราอธิบายอะไรแล้วทีมเดฟบอกว่า “เอ้อพี่ ถ้าพูดแบบนี้ ผมเข้าใจละว่ามันสำคัญยังไง” เฮ้ย นี่ไง สิ่งที่ PO จำเป็นต้องมอบให้ Scrum team เหมือนกัน
เพราะสิ่งที่ใช้ในการพัฒนา Software ไม่ได้มีแค่เรื่องเงิน แต่มันยังมีการลงแรงของทีมงานทุกคนที่สร้างมันมา
และหน้าที่ของ Product Owner ควรจะตอบได้มากกว่าเราได้ผลกำไรเท่าไหร่ เพราะ Engineer ส่วนใหญ่ไม่ได้เรียน Business มา หากแต่ถูกหล่อหลอมให้คำนึงถึงการทำทุกอย่างให้มีประสิทธิภาพสูงสุด เพราะงั้นสิ่งที่ impact ต่อจิตใจพวกเค้ามักจะเป็น
มัน improve อะไรไปแล้วบ้าง
ถ้าคุณเป็น PO แล้วคิดไม่ออกว่าจะทำยังไงให้ทีมได้เห็นข้อนี้ พาเค้าไปหาลูกค้าค่ะ พาเค้าไปนั่งหลังห้องดูตอนคนใช้งาน ให้เค้าเห็นกับตา ว่าสิ่งที่เค้าทำมามัน gold or s**t
Ordering ≠ Prioritizing
ข้อนี้พูดถึง Product backlog เคยมั้ยคะที่เราจะทำ Product อะไรสักอย่างแล้วอยากให้ packaging สวยมากๆ จนลืมไปว่า ก่อนจะมี packaging ได้ต้องมีของข้างในให้มันห่อก่อน 5555
หรือการสร้างบ้านแล้วอยากได้ห้องครัวที่สวยมากๆ แต่มันเป็นไปไม่ได้ในความเป็นจริง ที่จะเทพื้นแล้วทำห้องครัวต่อเลยโดยไม่ทำหลังคา
หน้าที่ของ PO คือต้องใช้องค์ความรู้เฉพาะในการจัดเรียงสิ่งที่ต้องเกิดขึ้นตามลำดับ และหน้าที่ของ Scrum team คือต้องแนะนำสิ่งที่ต้องเกิดขึ้นตามลำดับในแง่การพัฒนา Software เช่นกัน สิ่งนี้เรียกว่า การร่วมมือกัน ordering
จะทำแอพพลิเคชั่น ยังไงก็ต้องมีการ Login และที่ซ่อนอยู่ภายใต้หน้านั้นคือรูปแบบการ Authentication ที่มีหลายรูปแบบให้เลือกสรร
เมื่อทุกคนเห็น “ลำดับ” ครบถ้วนเท่ากันแล้ว ก็ถึงคราว Prioritize
สิ่งที่รู้แล้วว่าต้องทำ อาจยกไปทำทีหลังได้ ถ้ามีสิ่งใดที่สำคัญต่อการ deliver value มากกว่า หรือถ้าทำสิ่งนี้ก่อนจะมีประสิทธิภาพต่อการพัฒนามากกว่า นั่นเรียกว่า Prioritizing
Gossiping is an unskillful way to provide information (feedback)
เมื่อไหร่ที่ได้ยิน ให้เก็บมาคิด แต่อย่าเอามาใส่ใจ
หนึ่งในหัวใจของการทำ Agile คือการพัฒนาอยู่ตลอดเวลา เพราะฉะนั้นการนินทาก็เป็นไปได้ที่อาจจะมีความจริงปนอยู่ในนั้น แม้จะเพียง 1% useful information แต่ก็เป็น 1% ที่เราอาจเก็บมาพัฒนาอะไรบางอย่างได้
และถ้าจะให้ดียิ่งขึ้นไป ผลักดันให้เค้าเข้าใจว่ามีพื้นที่ที่เหมาะกับการให้ feedback อยู่นะ พื้นที่นั้นเรียกว่า Retrospective
ก็จบไปแล้ว กับสิ่งที่ได้รับเพิ่มเติมมาจากคอร์สนี้ จริงๆมีอีกเยอะมากค่ะ เพราะเซนเซย์ทั้งสองนี่ตัวจริงสุดๆ
ส่วนเรื่องอื่นๆของ Agile จะเก็บไว้เขียนต่อในบล็อคหน้า รออ่านได้นะคะ (และยังมีอีกบล็อคนึงที่เอาไว้เก็บรวบรวมบทความต่างๆที่เราเขียน >> saintsitive-dev.github.io แวะเวียนไปเยี่ยมเยียนได้ค่ะ)
