สืบเนื่องมาจาก ตลอดทั้งอาทิตย์ที่ผ่านมา หัวหน้าผม (พี่โน) ได้ส่งน้องๆ ในทีม ทั้งหมดไปเข้าคลาสเรียนที่มีชื่อว่า Collective Code Ownership ซึ่งจัดสอนโดย
พี่ ๆ จาก Odd-e
คลาสนี้ ใช้ระยะเวลาเรียนทั้งหมด 5 วัน
มีจำนวนประชากรในคลาส ประมาณ 20 คน (ไม่รวมผู้สอน) กลุ่มแรกเป็นพนักงานในทีม Agile จากสำนักงาน ก.ล.ต. (สำนักงานคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์) อีกกลุ่มเป็นน้อง ๆ จากบริษัท ODDS
สำหรับผู้สอนในคลาสนี้ ที่เป็นทั้งโค้ชและถือ Role เป็นหัวหน้าคณะตลกด้วย มุกไหนไม่ฮา แสดงว่าน้องไม่ตั้งใจเรียน มีด้วยกัน 3 คน ได้แก่พี่แอร์ พี่โป๊งเหน่ง และพี่ดิว
ก่อนอื่น ผมขอเล่าถึงกระบวนการเรียนการสอนในคลาสก่อนนะครับ ว่าเราเรียนและทำกิจกรรมอะไรกันบ้าง
ประการแรกเลย อยากได้อะไร ต้องทำเอง บริหารจัดการตัวเอง (Self-organization) ทั้งเรื่องมื้อเที่ยง และของว่างในแต่ละวัน ใครอยากกินอะไร เขียน post-it ไปแปะไว้ที่ผนังได้เลย มีช่องทางเตรียมไว้ให้แล้ว ส่วนจะแบ่งหน้าที่จัดการกันอย่างไร ทีมก็ไปคุยกันเอาเอง
ประการที่สอง เนื้อหาที่เป็นบรรยาย (Lecture) คุณอยากจด อยากวาดรูป หรืออยากทำอะไร แล้วแต่ใจปรารถนาเลยครับ คลาสนี้เปิดกว้างต่อผู้เรียนทุกรูปแบบ และเมื่อสอนจบในแต่ละเรื่อง ผู้สอนจะมีเกมมาให้เล่นเสมอ แต่ละเกมจะมุ่งเน้นให้ทุกคนได้มีโอกาสแสดงความคิดเห็น มีโอกาสได้พูด บอกเล่าความรู้สึก ความรู้ความเข้าใจ ในหัวข้อที่เพิ่งเรียนไป
ส่วนกิจกรรมที่เป็นภาคปฏิบัติ (Workshop) ทุกคนจะแยกย้ายกันไปทำงานตามกลุ่มที่ได้เลือกกันไว้ โดยกิจกรรมที่เป็นภาคปฏิบัติ จะสอดรับกับเนื้อหาที่เป็นภาคบรรยาย กล่าวคือ ถ้าเพิ่งเรียนเรื่อง DoD หรือ Definition of done จบ ทุกคนก็จะมารวมตัวกันเพื่อประชุม Sprint planning I และช่วยกันกำหนด Definition of done ร่วมกับ PO (Product owner) เป็นต้น
ประการที่สาม สุ่มในสุ่มในสุ่ม แม้ว่าตอนนั้นจะยืนอยู่ใกล้เพื่อนแค่ไหน เดี๋ยวสักพักจะโดนจับแยกด้วยรูปแบบกิจกรรมนั้น ๆ อยู่ดี แต่การสุ่มแบบนี้ เป็นเรื่องที่ดีนะ ทำให้เรามีโอกาสรู้จักคนใหม่ ๆ ได้พูดคุยกับคนที่เราอาจไม่ค่อยมีโอกาสได้พูดคุย ทำให้รู้จักกันมากขึ้น
ประการที่สี่ หลังจากเรียนจบในแต่ละเรื่อง พี่ ๆ จะมี สรุปเนื้อหาไปแปะตามจุดต่าง ๆ ของห้อง เมื่อจบวัน ทุกคนจะมารวมตัวกัน และแบ่งกลุ่มเล็ก ๆ 3–5 คน เพื่อทำสิ่งที่เรียกว่า Gallery walk กล่าวคือ ผลัดกันเดินชมตามจุดต่าง ๆ ที่มีสรุปเนื้อหาของวันนั้นและวันที่ผ่านมา ทุกคนจะใช้ช่วงเวลาสั้น ๆ สนทนากัน ใครมีอะไรที่สงสัย ก็สามารถถามไถ่กันได้เลย เช่น จำหัวข้อนี้ไม่ได้ ว่าพูดถึงอะไร หากคนที่อยู่บริเวณนั้น สามารถอธิบายได้ ก็จะช่วยอธิบายให้คนที่สงสัยได้เข้าใจมากขึ้น
ประการสุดท้าย หลังจากเสร็จ Gallery walk กันแล้ว ทุกคนจะมายืนล้อมวงกัน เพื่อพูดถึงสิ่งที่ตัวเองชอบหรือประทับใจ ไม่ว่าจะเป็นหัวข้อที่เรียนใน Lecture หรือกิจกรรมที่ทำในระหว่างวัน ประเด็นที่จะพูดกัน มีสองเรื่องหลัก ๆ คือ ชอบเรื่องไหน ? และชอบเพราะอะไร ? ส่วนใครจะพูดก่อน หรือพูดหลัง อันนี้ใช้วิธีการที่เรียกว่า Pop นั่นคือ ใครยกมือก่อน ก็พูดเลย แต่ถ้ายกมือพร้อมกัน ถือว่าเป็นโมฆะ ให้เอามือลง แล้วยกมือใหม่อีกรอบ
ทั้งนี้ทั้งนั้น เรื่องไหนที่ต้องตัดสินใจร่วมกัน ก็จะต้องใช้มติเสียงข้างมาก
ความคาดหวังของคลาสเรียนนี้คือ
ซอฟต์แวร์ ที่ใช้งานได้จริงจากพวกเรา
สำหรับเนื้อหาหลัก ๆ ของคลาส มีดังนี้
# Day 1
- Scrum
- Planning I
- Requirement workshop (ATDD)
- Definition of done
- Planning II
# Day 2
- Test driven development
- Working in team
- CI/CD (Continuous Integration/Continuous Delivery)
- Collective code ownership
# Day 3
- Code smell
- Refactoring
- Mocking
- Unit testing in java script
# Day 4
- Thinking about design
- Good unit testing
- Working with legacy code
# Day 5
- Craftsmanship
- Review
- Retrospective
- Summarize
รายละเอียดของแต่ละหัวข้อ ค่อนข้างมีรายละเอียดเยอะพอสมควร ผมขอแยกออกไปเป็นบทความใหม่แทนนะครับ (จะรีบหาเวลาลงให้ไวที่สุดครับ)
สำหรับบทความนี้ ผมขอสรุปในมิติของ Scrum Roles แทนนะครับ
มิติของ Product Owner
Product owner นั้นมีหลายแบบ อย่างน้อย ๆ ถ้าทำงานมาสักระยะ น่าจะต้องมีโอกาสได้สัมผัสกับความสามารถเฉพาะตัวของเหล่า PO ต่อไปนี้
- PO ที่เป็นดั่งร่างทรง หมายความว่า PO คนนี้ จะไม่มีอำนาจในการตัดสินใจอะไรด้วยตัวเอง ทุกอย่างขึ้นอยู่กับ เสียงจากเบื้องหลัง ซึ่งเสียงเหล่านั้น อาจจะเป็นใครก็ได้ แต่ที่แน่ ๆ มีผลต่อการตัดสินใจของ PO เสียงเหล่านั้นจะไม่สะท้อนความต้องการออกมาตรง ๆ แต่จะยืมร่าง PO มาพูดแทน ฮ่า ๆ
- PO ที่ไม่รู้อะไรเลย แม้กระทั่งว่าตัวเองต้องการอะไร ความหมายตรงตัวเลยครับ ไม่ต้องอธิบายอะไรเพิ่มเติม
- PO ที่รู้ว่าตัวเองต้องการอะไร นี่ล่ะ คือ PO ที่ Strong เท่าที่โลกเคยมีมา เขาจะบอกได้ว่า อะไรคือสิ่งที่เขาอยากได้ และเขาสามารถจัดลำดับความสำคัญได้ด้วยว่าเขาอยากเห็นอะไรก่อน-หลัง
แต่ในชีวิตจริงของโลกแห่งการทำงาน บาง Product อาจจะไม่ได้มี PO แค่คนเดียว นั่นหมายความว่า เมื่อ PO มีมากกว่า 1 คน อย่างน้อยที่สุด จะต้องมี PO ที่เป็นบอสใหญ่ เพื่อตัดสินใจและจัดลำดับความสำคัญของงานที่ต้องการได้ (making decisions and prioritizing work)
ทำไมถึงต้องมีบอสใหญ่ ? ในเมื่อ PO คนไหน ก็ตัดสินใจแทนกันได้
เพราะถ้า PO ทุกคน เกิดเสียงแตก คุยกันไม่จบ ผลเสียที่จะเกิดขึ้นตามมาก็คือ ทีมจะไม่สามารถโฟกัสได้เลยว่าจะต้องฟังใคร หรือที่แย่ยิ่งกว่านั้น สิ่งที่เคยตกลงกันไว้ว่าเป็น Definition of Done อาจจะไม่มีความหมายเลยก็ได้ เพราะทีมไม่ได้มองภาพเดียวกัน
เพื่อให้เกิดความโปร่งใส (Transparency) PO จึงควรยึดหลัก
1 Product owner = 1 Sprint backlog
มิติของ Scrum Master
สำหรับในมิติของ Scrum master ผมขอสรุปให้เข้าใจง่าย ๆ โดยเอาส่วนหนึ่งมาจากในคลาสเรียน และอีกส่วนมาจากแหล่งข้อมูลภายนอก
- The Scrum Dude พูดให้เข้าใจง่าย ๆ คือ เป็นมือใหม่หัดขับนั่นเอง ประสบการณ์ยังน้อย เป็นเสมือนเลขาฯ ของทีม
- The Scrum Mom ผมเพิ่งได้ยินคำว่า Scrum Mom ครั้งแรก จากคลาสเรียนนี้เลยล่ะครับ สำหรับ Scrum Mom นั้น เป็นเสมือนคุณแม่ ที่มีความกระตือรือร้นที่จะดูแลปกป้องลูก ๆ ในทีมเสมอ จุดที่ดีคือ ทีมที่มี Scrum Mom คอยดูแล จะทำงานออกมาได้ดี แต่จะมีจุดพลาดตรงที่ Scrum Mom มักจะไม่ค่อยเปิดโอกาสให้ทีมได้เจอความท้าทายใหม่ ๆ อาจเป็นสาเหตุให้ทีมเกิดความรู้สึกเฉื่อยชา จนหมดไฟในการทำงานได้
- The True Scrum Master คือ Scrum Master ที่แท้จริง ที่ทำให้ทีมสามารถทำงานร่วมกันได้อย่างดี มีกล่องเครื่องมือที่พร้อมจะหยิบของออกมาใช้ให้ถูกกับสถานการณ์เสมอ ผมขอยกตัวอย่างจาก เหตุการณ์ที่เกิดขึ้นจริงในคลาสเรียน และมีพี่แอร์ ถือ Role เป็น Scrum master ในวันนั้น
… ณ ตอนนั้น ทุกคนกำลังสุมหัวประชุม Sprint Planing I กันอยู่ สักพักหนึ่ง ก็มีคำแนะนำจาก Scrum master ลอยแว่วมาเบา ๆ ว่า พวกเรากำหนด Time-box กันหรือยัง ว่าจะประชุมเสร็จเมื่อไหร่ ทุกคนจึงได้ตระหนักว่า เอ๊าาาาา นี่เราจะประชุมกันแบบนี้ไปเรื่อย ๆ ไม่ได้นะ !!! หลังจากนั้น ทีมจึงมาตกลง Time-box ร่วมกัน ว่าจะใช้เวลาถึงกี่โมง จึงจะเลิกประชุม เพื่อไปทำกิจกรรมอย่างอื่นตาม Agenda ของวันนั้น
นี่เป็นสิ่งที่สะท้อนให้เห็นชัดเจนว่า Scrum master เลือกที่จะ “ถาม” ได้อย่างถูกจังหวะ พอเหมาะพอดี ผลลัพธ์คือ หลังจากวันนั้นเป็นต้นมา ทุกครั้งที่พวกเราทำงาน ไม่ว่าจะเป็นกิจกรรมอะไรก็ตาม จะกำหนด Time-box ก่อนเสมอ
มิติของ Team
ในมิติของ Team ผมขอลงรายละเอียดเยอะหน่อยนะครับ
ประการแรก ผมอยากพูดถึง เรื่องของการทำ Acceptance Test-Driven Development (ATDD) ก่อน เพราะหลายคนที่เคยทำ Test-Driven Development (TDD) อาจจะสงสัยว่า แล้วสองอย่างนี้ มันเหมือนหรือแตกต่างกันอย่างไร ?
ถ้าพูดถึงการเขียน Test ก่อนลงมือเขียนโปรแกรมบอกได้เลยว่า TDD กับ ATDD ไม่ต่างกัน แต่ถ้าต้องการ Test เชิง Business เพื่อเป็นการยืนยันว่าโปรแกรมทำงานตรงตามสิ่งที่ลูกค้าต้องการหรือไม่ ตรงจุดนี้จะเห็นแล้วล่ะว่า TDD กับ ATDD เริ่มต่างกัน
สิ่งที่เป็นตัวบ่งบอกว่า ตรงหรือไม่ตรงกับความต้องการของลูกค้า เราเรียกว่า Acceptance Criteria ซึ่งจะเกิดขึ้นในจังหวะของการทำ Sprint Planing I หลังจากที่คุยกับ PO เสร็จแล้ว และได้ DoD ที่ชัดเจน
ในคลาสเรียน ผู้สอนเน้นย้ำอยู่เสมอว่า ให้เราทุกคนเขียน Test ไม่ใช่เพียงแค่ว่าเป็นหน้าที่ที่ต้องทำ แต่อยากให้เขียนเพื่อให้เกิดความมั่นใจ และทำให้เป็นนิสัย
ประการที่สอง ความเป็นเจ้าของร่วมกันของโค้ด (Collective Code Ownership) กล่าวคือทีมเป็นเจ้าของโค้ดร่วมกัน ทุกคนสามารถแก้ไขโค้ดส่วนใดก็ได้ ซึ่งปัจจัยที่จะทำให้เกิดความเป็นเจ้าของร่วมกัน ยกตัวอย่าง เช่น
- การ Integrated code ผ่าน Source control
- การทำ Pair programming
- การทำ Code review
- การเขียน Test
ประการสุดท้าย ผมอยากพูดถึง T-shaped skills ซึ่งผม ได้ยินจากที่คลาสนี้ เป็นครั้งแรกอีกเช่นกัน
ทีมจะแข็งแกร่งขึ้นมากหรือน้อยนั้น ปัจจัยหนึ่งที่สำคัญและมีผลมาก ๆ นั่นก็คือ ความรู้ นั่นเอง จากภาพ T-shaped skills แสดงให้เห็นว่า ยิ่งเรารู้กว้างมากเท่าไหร่ แขนของตัว T จะยิ่งกว้างมากขึ้นเท่านั้น และเช่นเดียวกันกับ ขาของตัว T ยิ่งเรารู้ลึกมากเท่าไหร่ ขาของตัว T จะยิ่งดิ่งลงเรื่อย ๆ
เมื่อเราพัฒนาทั้งความรู้กว้างและความรู้ลึก ตัวอักษร T ของเราจะหยิ่งหนาขึ้น ๆ ดังนั้นผู้ที่มีทักษะการเรียนรู้แบบ T-shaped skills จึงเป็นคนที่มีความสามารถในการผนวกองค์ความรู้ต่างๆ เข้าด้วยกันเป็นอย่างดี สามารถนำไปประยุกต์ใช้ในงานที่ตัวเองเชี่ยวชาญได้อย่างแท้จริง
สรุป
ความประทับใจต่อการมาเรียนคลาสนี้
- อาหารมื้อเที่ยงในแต่ละวัน คือที่สุดของที่สุดเลยล่ะครับ กินหรู อยู่สบาย … พร้อมเอนกาย หลังบ่ายโมง ฮ่า ๆ
- การเดินทางมาเรียน สะดวกครับ พวกเราเรียนกันที่ Geeky Base สามารถนั่ง BTS มาลงสถานีมหาวิทยาลัยเกษตรศาสตร์ แล้วหาวินมอเตอร์ไซค์แถวนั้นนั่งมาลงที่ตึกเรียนได้ครับ หรือถ้าอยากออกกำลังกาย สามารถเดินได้นะครับ ระยะทางประมาณ 1 กิโลเมตร จาก BTS ถึงที่เรียน (สำหรับ BTS สถานีกรมป่าไม้ ยังไม่เปิดให้บริการนะครับ)
ซอฟต์แวร์ที่ต้องส่งมอบ
งานไม่เสร็จตามที่ Commit ไว้กับ PO แต่ก็เกินความคาดหมายที่ PO ตั้ง Goal ไว้ครับ
สาเหตุที่ทำให้งานไม่เสร็จตามที่ Commit ไว้ คือ
- เวลาที่เขียนโปรแกรมจริง ๆ มีแค่วันเดียว
- วันอื่น ๆ ยังพอเขียนโปรแกรมได้บ้าง แต่เขียนไปได้สักพัก จะมีบรรยาย (Lecture) หรือกิจกรรมอื่น ๆ เข้ามาแทรก ทำให้เวลาเขียนโปรแกรมน้อยลงไปอีก (เพราะทีมผู้สอน ตั้งใจจะแทรกกิจกรรมเข้ามาตลอด)
สุดท้ายนี้ …
- จากที่กล่าวไปแล้วว่า ทีมผู้สอน ตั้งใจจะแทรกกิจกรรม ทำให้เราทำงานไม่ทัน
(พี่ ๆ เขาเฉลยในวันสุดท้าย ตอนทำ Sprint Review) ปัญหาในลักษณะนี้ มีโอกาสเกิดขึ้นจริง หรือที่เรียกว่า งานแทรกระหว่าง Sprint นั่นเอง เพราะฉะนั้นแล้ว สิ่งที่เราควรทำคือ ต้องวางแผนให้ดี เริ่มตั้งแต่การทำ Sprint Calendar เอาปฏิทินมากางเลย ใน Sprint ที่จะมาถึง มีสมาชิกในทีมอยู่ครบกันไหม ? ใครจะลาไปไหนหรือเปล่า ? จะได้วางแผนและประเมินคะแนนของงานได้ถูกต้อง และหากทีมรู้ตัวว่า กำลังจะทำงานไม่เสร็จตามที่ Commit ไว้กับ PO เราควรแจ้ง PO ให้เร็วที่สุด - Scrum master ไม่ใช่พระเจ้า ที่จะเข้าใจทุกเรื่อง! เรื่องไหนหรือเหตุการณ์ใดก็ตามที่ยากต่อความเข้าใจของ Scrum master เป็นหน้าที่ของทั้งทีม ที่จะต้องค่อย ๆ อธิบายสิ่งเหล่านั้นให้ Scrum master รับทราบ และทำความเข้าใจ จนกว่า Scrum master จะมีข้อมูลมากพอที่จะสามารถตัดสินใจได้ ว่าต้องสื่อสารกับ PO อย่างไรต่อ
- กิจกรรมที่ทำมาทั้งหมด โดยเฉพาะส่วนที่เป็น Engineering Practice ทั้งหลาย ผู้สอนเลือกใช้วิธีการสอนแบบ ให้ลงมือปฏิบัติจริงก่อน จากนั้นค่อยสอนทฤษฎีตบท้าย สำหรับผมนะ ผมชอบการเรียนการสอนในลักษณะนี้ เพราะทันทีที่ผมมองย้อนกลับไปถึงสิ่งที่เพิ่งทำลงไป แล้วจับชนเข้ากับทฤษฎี ผมสามารถเห็นภาพ และเข้าใจได้ทันที
ต้องขอขอบคุณพี่โน หัวหน้าของพวกผม ที่เปิดโอกาสให้พวกเราทุกคนในทีมได้มีโอกาสออกไปเรียนรู้สิ่งใหม่ ๆ ร่วมกัน บอกได้เลยว่า หัวหน้าไม่ผิดหวังแน่นอน !!!
พวกเราตั้งใจเรียนและทำทุกกิจกรรมกันอย่างเต็มที่ ผมเชื่อว่า ทุกคนได้รับความรู้กลับมาแน่นอน และพร้อมที่จะนำมาประยุกต์ใช้ในการทำงานจริง เพื่อส่งมอบซอฟต์แวร์ที่มีคุณภาพให้กับลูกค้าต่อไป
ขอบคุณที่ติดตามอ่านจนจบนะครับ
