ATH2016 {Chapter1 => ถ้าช้าไม่เป็นก็เร็วไม่ได้}
มาต่อกันจาก
{Chapter 0 => Let’s start, How Docker can make you move agile}
ถ้าช้าไม่เป็นก็เร็วไม่ได้
by พี่หนุ่ม (ประธาน) @ สยามชำนาญกิจ
Quote สุดฮ็อตของงาน Agile Thailand 2016 “ถ้าช้าไม่เป็นก็เร็วไม่ได้”
จากประสบการณ์ของพี่ประธานเวลาเข้าไปเสนอขายบริการ(agile coach) ให้กับ องค์กรต่างๆ ให้ CEO ฟัง ส่วนใหญ่จะคิดว่า
“ถ้าเราจ้าง Agile Coach แล้ว Developer กากๆ อยู่เมื่อวานจะเก่งขึ้น ภายในช่วงข้ามคืน” — พี่หนุ่ม @ สยามชำนาญกิจ
งั้นเรามีวิดีโอมาให้ดูกันซะเล็กน้อยก่อนเริ่ม Session
Q: ทำไมคนที่ทำงานในวิดีโอถึงสามารถทำงานได้คล่องขนาดนั้นละ
A: เค้าทำงานซ้ำๆ จนเกิดความชำนาญ ถูกไหมครับ?
ลองนึกถึงครั้งแรกของคุณ (อย่าคิดลึกนะครับ)
- ครั้งแรกที่คุณเริ่มเล่นกีฬา
- ครั้งแรกที่คุณเริ่มเล่นดนตรี
- ครั้งแรกที่คุณเริ่มทำอาหาร
มันช้าไหมครับ
แล้วปัจจุบันเป็นไงครับ (ถ้าไม่ท้อเลิกทำไปก่อน) เพราะอะไรละ ? เพราะคุณฝึกฝนซ้ำๆ ใช่ไหม ทำบ่อยๆ ใช่ไหม ?
“แล้วการทำ Software ละ คุณทำแบบนั้นไหม”
สิ่งสำคัญในการนำ Agile เข้าไปใช้คือ…
เอ่ออออออ
เปลี่ยนใหม่ดีกว่าเราจะขอใช้คำว่า Agility แทนละกัน เพราะทุกครั้งที่เราพูดถึง Agile ทุกคนก็จะมองมันเป็น Scrum / Kanban กันไปหมด
Agility = Skills + Discipline — Jim Highsmith
การที่เราจะทำอะไรได้อย่างคล่องตัวได้คุณต้องมี ทักษะ และการฝึกฝนที่ดี (หรือวินัยที่ดีนั่นเอง)
เราไม่สามารถเปลี่ยนวิธีการทำงานจากแบบเดิมเป็นแบบใหม่ โดยให้ความเร็วเท่าเดิมได้
เหมือนคุณหัดกีต้าร์อยู่ แต่อยู่ๆ วันนี้ต้องไปตีกลองนั่นแหละ
เมื่อวานเป็น Waterfall แล้ววันนี้เป็น Agile ไม่ว่ายังไงคุณก็จะ
ช้ายิ่งกว่าเดิม แน่นอนครับ ซึ่ง Management ส่วนใหญ่รอไม่ได้ ?
หัวใจสำคัญของ Agile โดย Alistair Cockburn (โค-เบิ้ลนะครับ)
อย่าอ่านชื่อเค้าผิดนะ อันตรายจ้า
มีองค์ประกอบอยู่ด้วยกัน 4 เรื่อง
- Collaborate เอาคนมาทำงานร่วมกันให้ได้
- Deliver ส่งมอบของให้เป็นรอบสั้นๆ เพื่อให้ได้ feedback loop ที่เร็ว
- Reflect มองย้อนกลับว่าเราควรปรับอะไร
- Improve พัฒนาสิ่งที่ขาดหายไปตอน Reflect
การทำงานร่วมกัน
อะเอาคนมาทำงานร่วมกัน PM Shopping จ้า ไหนๆ เอาคนไหนดี นี่… นี่… นี่… ละกัน ซึ่งแต่ละคนมีความรู้ความสามารถไม่เท่ากันทำไงครับ พังสิครับ
หากเราไม่ปรับพื้นฐานของแต่ละคนให้เท่ากันสิ่งที่ได้คือ ประสิทธิภาพในการทำงานของเราจะมีอัตราเร่งเท่ากับคนที่ช้าที่สุดในทีม ซึ่งหากเราอยากให้ประสิทธิภาพการทำงานของทีมเราดีขึ้นทำยังไงละ
ปรับพื้นฐานสิครับ แต่แน่นอนตอนเริ่มทำอะไร ตอนแรกมันต้องช้าลงอย่างแน่นอน
มันก็เหมือนวิ่งมาราธอนแหละครับ ถ้าเราโดยไม่ฝึกซ้อม คิดว่าจะวิ่งถึงไหม ?
Myths: agile != process
ไหนๆ Scrum ว่าดีลองเอามาใช้สิ
ใช้ไปซัก 1–2 Sprint เออวะ ดูเข้าท่า เข้าสู่ Sprint 3 เอ๊ะ ทำไมมันช้ากว่าปกติอีกละ สาเหตุส่วนใหญ่ก็คงจะเป็น
- พื้นฐานการเขียนโค้ดไม่แข็งแรงพอ
- ประยุกต์ใช้ Automated ไม่เป็น
- แก้โค้ดชาวบ้านไม่ได้
- นี่! โค้ดข้าใครอย่าแตะ!
แต่ถ้าจะปรับพื้น ก็จะเจอข้ออ้างสุดฮิตของ Developer
โอ๊ยยย เทรนนิ่งเสียเวลาาาา ไม่มีเวลาแล้วเนี่ยยยย
แต่หลายๆ ครั้งเราก็จะเห็นนั่งเล่นเฟสบุ๊คกันอยู่
การฝึกฝนบ่อยๆ ซ้ำๆ เป็นสิ่งสำคัญ
ใช้เวลาซักอย่างน้อย 30–45 นาทีก็ดีนะ
หากใครเคยเป็นนักกีฬาประเภททีม (Basketball, Baseball, Football etc)
วันๆหนึ่งคุณต้องทำอะไรบ้างครับ วิ่ง, ฝึกพื้นฐาน (Basic ต่างๆ) ซ้อมทั้งวัน
ลงซ้อมแข่งชั่วโมงเดียว
การฝึกฝนพื้นฐานซ้ำๆ เพื่อให้กล้ามเนื้อจดจำการเคลื่อนไหว
แล้วการพัฒนาซอฟต์แวร์ละ เหมือนกันไหม ?
ยิ่งรอบการพัฒนาของเราสั้น พื้นฐานต้องแน่น เพราะงานต้องส่งเร็วขึ้น
พื้นฐานไม่ดี
ข้อแก้ตัวของ Developer ที่จะพบเวลาทำงานไม่เสร็จ
requirement ไม่ชัด requirement ไม่เคลียร์ requirement ไม่ละเอียด
งั้นเราต้องลองให้ Developer มาโชว์หน่อยสิว่า req. ที่ชัดเป็นยังไง ถ้ารู้ว่าอันไหนไม่ชัด แสดงว่า รู้ว่าชัดเป็นยังไง สอนให้ Developer เข้าใจกระบวนการของ req. และการได้มาซึ่งเอกสารต่างๆ ว่าทำไมต้องทำ
ถ้าพื้นฐานด้าน req ของ Developer งานก็จะออกมาดี ถามว่า management รอได้ไหม ?
Tester จะต้องไม่อยู่หลังกระบวนการ Develop เสร็จ ต้องก้าวออกมานำหน้า Dev ต้องไม่ Test งานด้วยตัวเอง ต้อง Design Test Case กับวิเคราะห์ Requirement ให้ได้ เอา Automated Testing มาใช้กับ Tester ซึ่งปกติกลุ่มคนเหล่านี้ไม่ชอบเขียนโค้ดอยู่แล้ว ทำให้ Tester ต้องใช้เวลาฝึกฝนตัวเองหนักมากขึ้นไปอีก ถามว่า
Management รอได้ไหม ?
Tips: Automation Tools ไม่ใช่คำตอบหากไม่รู้ว่ามันใช้ยังไง
จริตคนไทย กับคนยุโรปไม่เหมือนกัน
แล้วคิดว่า Scrum จะตอบโจทย์ปัญหาของคนไทยได้เลยไหม ตอบเลย ยากกกกกก
Great power Comes with Great Responsibilities
Agile ให้พลังอำนาจแก่ทีมในการตัดสินใจต่างๆ ทั้งทีมต้องใช้ความรู้ความสามารถในการแปลงจากเอกสารกระดาษ ไปเป็น Software โดยที่ไม่มี BA หรือ SA
แต่แน่นอนครับ ครั้งแรกที่ใช้พลังเรายังควบคุมมันไม่ได้แน่นอน
คุย req ไม่รู้เรื่องแน่นอนเพราะไม่เคยทำ
ก่อนคุณจะเริ่มใช้ Agile สิ่งสำคัญที่คุณจำเป็นต้องดูมี 3 อย่าง
- ทักษะของคนในทีมเป็นอย่างไร
- เทคโนโลยีที่ใช้
- มีความรู้ความเข้าใจใน business ของงานที่ทำไหม ?
Automation เกิดจากสมองไม่ใช่เงิน — พี่หนุ่ม @ สยามชำนาญกิจ
ฉะนั้นเขียนเริ่มฝึกเขียน Test Case เถอะครับเพื่อชีวิตที่ดีขึ้น
Developer ผู้ใดที่เป็นคนเขียนโค้ดส่วนใด มันผู้นั้นก็ต้องเขียนเทสส่วนนั้น
Tester ไม่ได้มีหน้าที่ Tracking defect ต่างๆ ที่เกิดขึ้น
“แต่ว่าพี่ Developer เค้าไม่มีเวลานะ Track ให้เค้าหน่อยไหม” — Tester ท่านหนึ่ง
“ถ้าไม่มีเวลาก็ อย่าให้เกิด Defect” — พี่หนุ่มกล่าวไว้
จะได้สมการที่ว่า
Develop = Code + Test
จะส่งของเร็วๆ รอบสั้นๆ ได้จะต้องมีวิธีการตรวจสอบว่าสิ่งที่เราทำมันถูก เช็คไงดีละ
- Requirement นี้ ทดสอบยังไง
- Demo ยังไง
กลับมามองตัวเอง
เรากากตรงไหน เราต้องปรับปรุงตัวเองตรงไหน
เขียนโค้ดอะไรออกมา อย่าลืมเขียนเทส แต่พอเขียนเทสแล้วรับรองได้เลยว่าเวลาในการทำงานเพิ่มขึ้นมหาศาล management รอได้ไหม?
Agile Journey
Shuhari (守破離) เป็นแนวคิดที่แบ่ง stage ของการเรียนรู้สิ่งต่างๆ จาก Beginner ไปจนถึง Master
- Shu — เรียนรู้พื้นฐานของสิ่งที่จะทำ เป็นช่วงที่ช้าที่สุด เพื่อให้ได้เห็นภาพรวม ปรับรอบการทำงานให้เร็วขึ้นเพื่อให้เกิดความเคยชิน
A: อาจารย์ได้โปรดรับข้าเป็นศิษย์ด้วย
B: งั้นเจ้าจงไปตักน้ำวันละ 10 ถัง
- ha — เรียนรู้และหาเทคนิคที่สามารถนำมาปรับใช้ได้อย่างเหมาะสม แต่ละเทคนิคมี trade-off ของตัวเองอยู่แล้ว
- ri — นำความรู้ทั้งหมดมาออกแบบเคล็ดวิชาเป็นของตัวเอง
- kokoro (หัวใจ)— สูงสุดคืนสู่สามัญ เข้าใจถึงแก่น
การเปลี่ยนแปลงมีลักษณะอยู่ด้วยกัน 2 แบบ
Outside in —เอา process มาครอบให้ process ชัดเจนแล้วมาหวังผลกับ culture ทีหลัง
Inside out — ทำให้เค้ามี inner ร่วมกับทีมให้ทำงานร่วมกันด้วยดี
เราจะเร็วขึ้นได้ เมื่อทักษะและการฝึกฝนดีขึ้น
พี่หนุ่มฝากข้อคิดไว้ 3 ข้อก่อนจากกัน
- ปัจจุบันทำไมเราต้องใช้ agile
- คนทั้งองค์กรเห็นภาพ agile ตรงกันไหม
- ปัญหาที่มีคืออะไร ที่ต้องการแก้ไข อย่าเพิ่งเอา process มาครอบ
ติดตามชมตอนต่อไป ATH2016 {Chapter 2 => Agile Transformation}
