อไจล์ สกรัม แอนด์ เวิร์คโฟล
มีโอกาสได้ไป agile workshop สามวันกับสยามชำนาญกิจ ได้ความรู้เยอะมาก เยอะไปหมด เพื่อไม่ให้สิ่งที่ได้สูญไปกับเวลาและต้องการแบ่งปันสิ่งที่ได้ออกไปเผื่อใครที่อยากจะรู้ อยากจะเข้าใจกับ agile, scrum หรืออยากรู้ว่าปกติเค้าทำกันยังไง ก็จะพยายามสรุปลงในนี้เน๊อะ
ในทีมที่พัฒนาซอฟต์แวร์ให้ลูกค้า เรามีกระบวนการทำซอฟต์แวร์อยู่แล้ว นั้นคือ รับ requirements จากลูกค้า, มีการวิเคราซห์ requirements ที่ได้, design, implement, test แล้วก็ maintain ใช่ไหมละ เวลาทำงานในกระบวนการพัฒนาซอฟต์แวร์นี้
- เคยเจอไหมที่ ลูกค้าอยากได้อันนี้ อันนั้น เป็นภาพใหญ่ๆ ไม่มีรายละเอียดอะไรเลย
- หรือเคยเจอไหมที่ business team บอก requirements มาแบบมีแต่หัวข้อใหญ่ๆ อยากรู้รายละเอียดเพิ่มเติ่มก็มาถามเองสิ ต้องรอว่างก่อนด้วยนะ
- เคยเจอไหมที่ ลูกค้าบอกว่าให้ทำๆไปก่อน
- เคยเจอไหมที่จะดีพลอยงานขึ้นโปรดักชั่นอีกสามวัน แล้วมาเพิ่ม หรือเปลี่ยนสิ่งที่ทำมาทั้งเดือน
- เคยเจอไหมที่งานทุกอย่างถูก assign มาให้แล้วสถานะเป็น high priority, urgent, very very urgent ทุกอัน ไฟไหม้ตลอด
- เคยเจอไหมที่ต้องบุกป่า ฝ่าดง ทำอะไรก็ไม่รู้อยู่คนเดียว ทันหรือไม่ทันไม่เคยมีใครมาถาม
- เคยเจอไหมที่อีกสองอาทิตย์แล้วยังไม่รู้เลยว่าทีมจะส่งงานได้ครบได้ทันเวลาไหม
- หรือเคยเจอไหมที่แบบมี changes มี requirements creep แต่ก็ไม่รู้เรื่องอะไรเลย
คิดว่าหลายคนก็น่าจะเคยประสบกับบางปัญหา อยากรู้แล้วใช่ไหมละว่า agile มันจะแก้ปัญหาเหล่านี้ยังไง
ไม่, agile ไม่ได้บอกวิธีแก้ปัญหาเหล่านี้ ไม่ได้มี step 1, step 2… หรือสูตรสำเร็จให้
‘Agile’ เป็นแค่แนวคิดในการทำงานที่เป็นทางเลือกอีกทางหนึ่งที่จะช่วยให้ปัญหาเหล่านี้มันลดลงแค่นั้นเอง
“แล้วทำไมต้อง agile”
“แล้วทำไมต้องใช้อย่างอื่นละ “
ยกตัวอย่างการทำงานแบบ Waterfall การทำงานแบบ Waterfall ขั้นตอนก็มีเก็บ requirements พอเสร็จก็ไป design พอเสร็จก็ code พอเสร็จก็ test พอเสร็จก็ส่ง UAT ให้ลูกค้าทดสอบเพื่อจะเอาขึ้นโปรดักชั่น
เอาละ ลองคิดภาพ ถ้าโปรเจคนี้ 6 เดือน
- Development team ทำการโค้ตตาม requirements ทุกอย่างในเอกสารที่ business analyst ทำ โค้ตตามความเข้าใจ(ของเดฟ) แต่พอเดือนที่สามมี PM หรือBA มาดูแล้วถามว่า ยู๊ววทำอะไร requirements มันหมายถึงแบบนี้นะ แก้ด้วยด่วนน ที่ทำมาสองสามเดือนหายไปเลย
- กว่าจะส่งมาให้ทีมเทสทดสอบเดือนที่สี่ จะเกิดอะไรขึ้นถ้าทีมเทสเจอปัญหา ก็จะส่งให้ทีมเดฟแก้ กว่าจะแก้ไขก็อาจจะหลงป่างมโค้ตตัวเองเพราะโค้ตมันเยอะไปหมด แก้แล้วกระทบอีก ไม่จบสิ้นสักที
- กว่าลูกค้าจะได้ลองเล่นลองทดสอบก็เดือนสุดท้ายแน่นอนใช่ไหมละ จะเกิดอะไรขึ้นถ้าลูกค้าบอกว่ามันไม่ใช่สิ่งที่ต้องการ ไม่ใช่สิ่งที่อยากได้ หรือ requirements ไม่ใช่อย่างนี้ กว่าจะรู้ว่ามันไม่ใช่ก็… ก่อนขึ้นโปรดักชั่น
- แล้วจะเกิดอะไรขึ้นถ้าลูกค้าได้ลองเล่นลองทดสอบแล้วขอเพิ่มโน้น นั่น นี่ เอาแบบด่วน เอาไปพร้อมกัน เอ้าาา ไฟไหม้
อาการแบบนี้เค้าเรียก #รู้ตัวเมื่อสายไป 55
เป็นแบบนี้หรือคล้ายๆแบบนี้กันอยู่ไหม
แล้วถ้าเรารู้ตัวเร็วขึ้นละ ว่าปัญหามันอยู่ตรงไหน
แล้วถ้าเราสามารถทำความเข้าใจ requirements ไปพร้อมๆกันกับลูกค้าทั้งทีมทำงานละ
แล้วถ้าเราให้ทั้งลูกค้าทั้งทีมทำงานมาสุมหัวประเมิน requirements ทำได้ไม่ได้ ทันไม่ทัน ต่อลองการทำก่อนหลัง เพิ่มลดงานที่จะทำ มันจะช่วยให้ทีมมีความสัมพันธ์ มีความร่วมมือกันกันมากขึ้นไหม ทุกคนมีสิทธิ์มีเสียง ไม่รู้สึกโดดเดี่ยวเป็น no one มันจะแฮปปี้กว่าไหม
แล้วถ้าเราลดรอบการทำงานเหลือสิบวัน หรือยี่สิบวัน แต่ละรอบก็จะมีงานที่จะทำเท่านั้นเท่านี้ เวลาส่งให้ทีมเทสทดสอบก็จะดูและโฟกัสแค่ส่วนนี้ ก็จะทำให้รู้ว่ามี defects เร็วขึ้นใช่ไหมละ
แล้วพอรอบการทำงานเหลือสิบวัน หรือยี่สิบวัน ทีมก็จะเห็นว่าอะไรเสร็จ อะไรไม่เสร็จได้ชัดขึ้น แล้วจะเห็นได้ว่ามันกระทบกับ master plan ไหมได้เร็วขึ้น แล้วจะหาทางแก้ได้เร็วขึ้นจริงไหมละ
แล้วถ้าเราสามารถให้ลูกค้าเห็นงานได้เร็วขึ้นละ ก็จะช่วยแก้ปัญหาขอเพิ่ม ขอเปลี่ยนตอนสามสี่วันสุดท้าย เพราะลูกค้าเห็นงานเร็วขึ้น เราก็จะได้ feedback ได้เร็วนั้นเอง
แล้วถ้าลูกค้าต้องการเปลี่ยนหรือเพิ่ม requirements วันท้ายๆละ ก็อยากเปลี่ยนก็เปลี่ยนได้ไม่เป็นไร…
นั้นละ การมีแนวคิดแบบ agile มันจะเป็นตัวช่วยให้เกิดสิ่งเหล่านี้
มาถึงตรงนี้อาจจะงงว่า agile มันเป็นแค่แนวคิด แค่คิดแบบ agile มันจะช่วยหรอ แล้วเราจะเอาไปใช้ได้ยังไง ก่อนจะไปตอบคำถามนี้
ขอพูดถึงแนวคิดแบบ Agile ก่อน
แนวคิดแบบ Agile จะประกอบด้วยคำแถลงการณ์ 4 ประการ+หลัก 12 ประการ
Agile มีคำแถลงการณ์ดังนี้
เราค้นพบวิธีที่ดีกว่าในการพัฒนาซอฟท์แวร์
จากการลงมือทำจริงและช่วยเหลือผู้อื่น
นั่นคือ เราให้ความสำคัญกับ:คนและการมีปฏิสัมพันธ์กัน มากกว่าการทำตามขั้นตอนและเครื่องมือ
ซอฟต์แวร์ที่นำไปใช้งานได้จริง มากกว่าเอกสารที่ครบถ้วนสมบูรณ์
ร่วมมือทำงานกับลูกค้า มากกว่าการต่อรองให้เป็นไปตามสัญญา
การตอบรับกับการเปลี่ยนแปลง มากกว่าการทำตามแผนที่วางไว้ทั้งนี้ แม้เราจะเห็นความสำคัญในสิ่งที่กล่าวไว้ทางด้านขวา
แต่เราให้ความสำคัญกับสิ่งที่กล่าวไว้ทางด้านซ้ายมากกว่า
“Over ไม่เท่ากับ not have นะ”
และหลัก 12 ประการมีดังนี้
1. ให้ลูกค้าพึงพอใจโดนการส่งมอบซอฟต์แวร์ที่มีคุณค่าให้เร็วและบ่อยขึ้น เพื่อให้พวกเค้าเห็นความคืบหน้าของชิ้นงานและไม่ต้องรอ2. ยินดีให้มีการเปลี่ยนแปลงของ requirements ตลอดกระบวนการพัฒนา เพื่อเพิ่มโอกาสการต่อรองทางธุรกิจและรายได้ที่คุ้มค่า3. ส่งมอบซอฟต์แวร์ให้บ่อยขึ้น ระยะเวลายิ่งสั้นยิ่งดี 4. ทำงานร่วมกันระหว่างลูกค้าและ development team เพื่อการตัดสินใจที่ดีขึ้น เพื่อความเข้าใจที่ถูกต้อง5. เชื่อใจทีม มีการกระตุ้นให้ทีมมีแรงบรรดาลใจ และสนับสนุนทีมทั้งเรื่องสถานที่ อุปกรณ์ พัฒนาความรู้ ความสารถ และอื่นๆ6. พยายาม face-to-face interactions มีการทำงานร่วมกัน ช่วยคิด ช่วยวางแพลน นั่งทำงานด้วยกัน7. ความคืบหน้าของงานวัดจากงานที่ส่งมอบ8. ทำทีละนิดแต่ทำบ่อยๆ9. มี technical detail and design enhances ที่ดี ตั้งแต่ต้นจะเพิ่มความคล่องตัวมากยิ่งขึ้น10. อะไรที่ไม่จำเป็นก็ยังไม่ต้องทำ หากว่าไม่มีผลอะไรกับธุรกิจหรือทำแล้วก็ไม่ได้ทำให้มีรายได้เพิ่มหรือมีอำนาจการต่อรองที่เพิ่มขึ้น11. ทีมต้องสามารถ self-organizing สามารถจัดการ ออกแบบการทำงาน สามารถตัดสินใจ วางแผนการทำงานร่วมกัน และเสนอความคิดเห็นร่วมกันทั้งทีม 12. ทีมต้อง self-improvement มี process improvement เพิ่ม skills และ techniques เพื่อให้ทีมทำงานได้อย่างมีประสิทธิภาพมากขึ้น
Agile มี แนวคิดแค่นี้เอง…
ปล แปลเอง อ่านๆมาจากที่อ่านเพิ่มด้วยอ่านจะเพี้ยนๆ 55
แล้วจะเอาไปใช้ได้ยังไง
แนวคิดแบบ agile จะมีกรอบการทำงานหลายแบบเพื่อให้เรานำมาใช้งาน เช่น scrum และ extreme programming
เท่าที่ฟังมา extreme programming ค่อนข้างยาก ขอพูดแต่ scrum แล้วกัน
ตัว scrum นี้แหละที่จะทำให้เราสามารถนำแนวคิดแบบ agile ไปใช้ได้ scrum เป็น process การทำงานแบบหนึ่ง
ก่อนที่เราจะไปดูวิธีการทำงานแบบ Scrum ขออธิบายตำแหน่งในทีมก่อน
- Product Owner เป็นคนที่มีผลได้ผลเสียกับโปรดักนั้นๆ เป็นคนให้ requirements มีหน้าที่กำหนดหรือ list requirements มีหน้าที่กำหนดลำดับความสำคัญของงานนั้นๆ เป็นคนเลือกว่าอยากจะให้ทีมทำอะไรก่อนหลัง สามารถตัดสินใจได้ว่าจะทำหรือไม่ทำ โดยคำนึงจาก business value และพิจารณาทิศทางทางธุรกิจเป็นหลัก
- Development Team เป็นทีมทำงานโดยจะมีคนที่ทำหน้าที่ develop, test, design อะไรแบบนี้ ทดแทนกันได้เสมอ จะทำงานร่วมกัน ทีมมีอำนาจจัดการตัวเอง สามารถประเมินเวลาของ task ที่จะต้องทำ แจกจ่ายงานและ assign งานกันเองได้เลย
- Scrum Master เป็นโค้ชของทีม ช่วยคิดวิธีแก้ปัญหาให้ทีม หา solutionให้แต่ไปแก้กันเอง 555
“ถ้าหากเอา scrum ไปใช้ ลองคิดๆดูว่าในบริษัทพอจะมีคนแบบนี้ที่ทำแบบนี้ได้อยู่ไหม พอจะสร้างขึ้นมาได้ไหม”
และอย่าลืมว่า
PO + Development Team + SM = Scrum Team,
PO + SM = PM ,
DevelopmentTeam + SM = HERO
ต้องประกอบไปด้วยสามหน้าที่ถึงจะเรียกว่า scrum team
ถ้าเราให้คนที่เป็น PO ทำ SM ด้วย เราจะได้ PM แต่ ถ้าให้คนที่ เป็นสมาชิกใน development team เป็น SM ด้วย เราจะได้ heroที่ทำและแก้ปัญหาอะไรเองหมด”
ขั้นตอนการทำงานแบบ scrum
- เริ่มจาก product backlog คือ list ของ task ทั้งหมด (requirements, changes, enhancement, issue) ของโปรเจคนี้ โดยมี PO และผู้ช่วยเป็นคนทำขึ้นมา สามารถเพิ่มหรือตัดออกได้ตลอดเวลา และให้ team สามารถเห็นและเข้าถึงตัว product backlog ได้ง่ายด้วย
- เมื่อได้ product backlog, PO จะต้องกำหนดว่าระยะเวลาการทำงานว่าจะทำกี่เดือน มีกี่ release แล้วในแต่ละ release จะมีกี่ sprint แต่ละ sprint จะมีกี่วัน และเลือกว่า task ไหนใน product backlog จะให้ทีมทำใน sprint นี้
- เมื่อ PO ได้ task ที่อยากจะให้ทีมทำแล้ว จะนำมาอธิบายแต่ละ task ให้กับทีมอย่างละเอียด ว่า task นี้ต้องการเพราะอะไร เพื่อให้ทีมทุกคนรู้รายละเอียดไปพร้อมกัน และได้ requirements ที่ครบถ้วน และรวมไปถึงเงื่อนไขการตรวจรับงาน ขั้นตอนนี้เรียกว่า sprint planning part 1
- ต่อมาเมื่อทีมได้ task มาแล้ว ทีมก็จะมาวิเคราะห์หา solutions ร่วมกันว่าจะทำยังไง ทำเสร็จไหม แบ่งงานภายในทีม ต่อรองขอเพิ่มหรือลดงาน แล้วนำ tasks ที่ได้ ลงใน sprint backlog ขั้นตอนนี้เรียกว่า sprint planing part 2
ในขั้นตอนนี้ ถ้าหากทีมบอกว่า task นี้ไม่ทันและ PO เห็นด้วย ตัว task นี้จะกลับอยู่ใน product backlog ของ PO
5. หลังจากนั้นทีมทำ board ที่มีคอลัมน์ To Do, Doing, Done
TO DO -- Tasks ที่อยู่ใน sprint backlog
DOING -- Tasks ที่กำลังทำ
DONE -- Tasks ที่ทำเสร็จแล้ว
การจะเปลี่ยนเป็น DONE ได้นั้น ทีมต้องตกลงกันก่อนว่า potentially shippable product increment มีอะไรบ้างถึงจะเรียกว่ามันเสร็จแล้วจริงๆ เช่น จะเปลี่ยนเป็น DONE ได้ จะต้องมีสิ่งต่อไปนี้นะ- Codes
- Unit tests
- Test Cases & Results
- Automation Scripts
- SRS Document
- UAT Document & Results
- User Manual
- ER and Datadic
- ETC.
เมื่อมีทุกอย่างครบตาม list นี้ถึงจะไปเปลี่ยนเป็น DONEหากไม่ตกลงกันก่อนจะเกิดปัญหาอีกว่า DONE ของแต่ละคนมันไม่เท่ากัน พอมันไม่เท่ากัน สุดท้ายก็สรุปไม่ได้ว่ามัน DONE จริงๆไหม
ขั้นตอนนี้ก็เริ่มเข้าสู่ sprint แล้ว
ซึ่งแต่ละวันใน sprint ทีมก็จะมีการ stand up meeting โดยจะเรียกเฉพาะคนที่ทำงานใน Sprint นั้นเท่านั้น หากคนอื่นอยากฟังจะต้องยืนอยู่วงนอก ทีมจะพูดถึงสิ่งที่ตัวเองทำเมื่อวาน ติดปัญหาอะไร และวันนี้จะทำอะไร เพื่อให้ทีมเห็นความคืบหน้าตลอด
6. เมื่อเข้าสู่ sprint เมื่อผ่านครึ่งทาง ทีมจะมาคุยกันว่า งานที่ทำอยู่ ที่เหลือ หรือที่เสร็จแล้วเป็นอย่างไร จะส่งมอบทันไหม จะจบ sprint ได้ไหม ทีมสามารถต่อรองขอเพิ่มหรือลดงานกับ PO ได้ ขั้นตอนนี้เรียกว่า sprint review
Sprint review นี้จะทำให้ทีมเห็นภาพชัดขึ้นว่ามันจะเสร็จทันตามกำหนดไหมและเป็นการกระตุุ้นให้ทีมด้วยว่างานตัวเองทำไมยังอยู่ DOING ปิดไม่ได้สักทีอะไรอย่างนี้ ทีมก็จะได้ช่วยเหลือ
7. หลังจากนั้นเมื่อจบ sprint ทุกอย่างก็พร้อมให้ PO หรือลูกค้าใช้งาน แต่ถ้ามันไม่เสร็จก็จะยังปิด sprint ไม่ได้ ก็ต้องคุยและต่อรองกับ PO
หรือกรณีต้องการเพิ่ม task, เปลี่ยน, หรืออยากให้ทำ task อื่นก่อนจบ Sprint นั้นๆ ทีมจะต้องหยุดสิ่งที่ทำอยู่ task ที่เสร็จก็นำขึ้น production ส่วน task ที่ยังไม่เสร็จ ยังอยู่ ใน TO DO หรือ DOING ส่งคืน PO ไปทำขั้นตอนที่ 1–6 ใหม่
8. หลังจบ sprint จะมี sprint retrospective เพื่อมาระดมไอเดียว่า ได้เรียนรู้อะไร เจอปัญหาอะไรจาก sprint ที่ผ่านมา แล้วจะแก้ปัญหาไหนก่อน และจะแก้ยังไง แล้วตกลงวิธีการวัดผล และต้องมีการติดตามผลด้วย
9. ก็ทำ 1–8 วนๆไปจนจบ release วนๆไปจนจบ project
นี่คือทั้งหมดของการทำ scrum นี่คือวิธีการเอา agile ไปใช้
“มันจะช่วยได้จริงหรอ”
นั้นสิ! ต้องลอง! การที่จะนำเอา Scrum ไปใช้นั้น คนในทีมจะต้องเข้าใจแนวคิดและหลักการของมันก่อน และถ้าการเอาไปใช้ทั้งหมดมันดูยุ่งยากก็นำบางส่วนไปปรับใช้ และค่อยๆเพิ่มเข้าไป และคนในทีมต้องมีความคิดที่อยากจะเปลี่ยนด้วยเช่นกัน อีกอย่างจะเห็นว่า agile, scrum จะไม่เหมาะกับองค์กรที่มีโครงสร้างแบบ hierarchical structure
ทั้งหมดข้างต้นก็คือเนื้อหาได้เรียนรู้จาก agile workshop การไป workshop ครั้งนี้นอกจากจะเรียนทฤษฎีแล้ว ตัว workshop ยังทำให้ภาพได้ชัดขึ้น คุ้มค่ามาก
นอกจากจะได้ความรู้ agile, scrum แล้ว
ยังได้รู้อีกว่า การทำ unit test เฮ่ยย มันง่ายกว่าที่คิด(ทดลองโดยใช้ java)และใช้เวลาไม่นานเลย แปลกใจมากที่ devepler ไม่ยอมเขียน เพราะเขียนเสร็จ เวลาแก้อะไรก็ไม่ต้องกังวลว่าสิ่งที่แก้จะกระทบกับ function อื่น แค่ทดสอบจาก unit test ของตัวเอง ช่วยทีมเทสไปอีกแรง ช่วยเพิ่มคุณภาพของงานในภาพรวมได้แน่นอน
นอกจากนั้นแล้วก็มีเรื่อง pair programming อันนี้เคยใช้ตอนทำแลปตอนเรียน มันสนุกอยู่แล้วแหละที่ไม่ต้องทำอะไรคนเดียว ช่วยกันคิดช่วยกันทำ
นอกจากนั้นแล้วการไป workshop ครั้งนี้ก็ได้เจอเพื่อน ได้พูดคุยแลกเปลี่ยนกับคนใน workshop ในหลากหลายหัวข้อ ทั้งเรื่องงาน บริษัทที่เค้าทำ ประสบการณ์ของแต่ละคน ประสบการณ์เรียนต่อปโท feedbackของบริษัทในสายตาคนอื่นอะไรแบบนี้
ถือว่าสนุกและคุ้มค่ามาก #ขอบคุณผู้สนับสนุนหลัก #boss #pranworksacademy #เป็นบทความที่ยาวมาก #เจอกันบทความหน้า
