ได้อะไรกลับมาบ้างจากงาน Agile Thailand 2016

งานครั้งนี้เป็นอะไรที่ใหม่และแหวกแนวกับผมมาก เค้าเรียกกันว่า open space เราไม่รู้ล่วงหน้าเลยว่าจะได้รับฟังอะไรบ้างจากใคร จะมารู้จริงๆก็ในงานตอนเช้าสุด คนที่อยากแชร์เรื่องอะไรก็จะเอา topic มาแปะบนบอร์ด พร้อมกับเกริ่นหัวข้อนิดหน่อยก่อน ก่อนแยกย้ายกันไปตามเรื่องที่ต่างคนต่างสนใจ ทุก session มีเวลา 45 นาที แบ่งออกเป็น 8 ห้อง “เริ่มเมื่อพร้อมและจบเมื่ออยากจบ” “สิ่งใดเกิดขึ้นแล้วสิ่งนั้นดีที่สุด” ไม่มีอะไรตายตัวเลย ยืดหยุ่นตาม agile style สุดๆ เอาเป็นว่าครั้งหน้าอาจจะจัดอีกประมาณ ตุลา 2559 ใครสนใจลองไปหาในกลุ่ม agile66 ใน facebook ครับ

เข้าเรื่องกันเลย! ในงานมีเนื้อหาอะไรที่ผมพอจับประเด็นได้บ้าง? เอาแบบมือใหม่ๆนะครับ ผมพึ่งเคยไปครั้งแรก บางเรื่องลึกไปเอามาเขียนแล้วผมอาจจะเขียนไม่ถูกต้องบ้าง ต้องขออภัยและ ให้ feedback กันมาได้ถ้าผิดถูกตรงไหนยินดีที่จะแก้ไขครับ

หัวข้อที่ผมเข้าไปฟังก็มี…

Agile Manifesto by คุณกรณ์

• หัวข้อนี้อธิบายถึงที่มาที่ไปว่า agile เกิดมาได้อย่างไร? ก็เกิดมาจากที่ว่าการจัดการ project แบบ waterfall มันทำให้ product ที่ออกไปมีความเสี่ยงที่จะให้ผลลัพธ์ที่ไม่ตรงตามความต้องการจริงๆ แล้วทำอย่างไรถึงจะ deliver งานออกไปที่ละ lot ได้เพื่อที่จะได้รับ feedback กลับมาแก้ไขให้ถูกต้องได้เร็วที่สุด ซึ่งถ้ากลับไปใช้ waterfall ผู้ใช้งานจะไม่มีทางรู้ได้เลยว่าของที่กำลังพัฒนากันอยู่นั้นตรงกับความต้องการจริงๆหรือไม่ จะรู้อีกทีก็ตอน project เสร็จซึ่งอันตรายมาก
• เมื่อเกิดปัญหานี้ขึ้น จึงมีกลุ่มคนที่ร่วมกันคนหาแนวทางใหม่ที่ต่างจากเดิม จึงเกิด website agilemanifesto.org ขึ้นมา
• agile ให้ความสำคัญกับปัจเจกบุคคล(individual) คนทุกคนไม่เหมือนกัน เพราะฉะนั้นการทำงานกับคนแต่ละคน “ไม่มีอะไรทดแทนได้” ดังนั้นการทำ document แบบ generalize ยาวๆ ไม่ได้ช่วยให้การสื่อสารดีขึ้น เพราะระดับความเข้าใจของแต่ละคนต่างกัน
• การที่สมองรับรู้และถ่ายทอดออกมาเป็นตัวหนังสือสามารถถ่ายทอดข้อมูลออกมาได้แค่ 7% เพราะฉะนั้นการเอาแต่เขียน document จึงไม่ใช่สิ่งที่นำเอา requirement ออกมาถ่ายทอดได้ทั้งหมด
• บริษัทที่มี resource pool คอยย้ายคนในทีมไปทำตรงนั้นทีละ 4 เดือน แล้วก็ย้ายไปเรื่อยๆ ทำให้ประสิทธิภาพการพัฒนาโปรเจคลดลง เพราะกว่าที่คนใหม่จะเข้าใจงานเดิมแบบไร้รอยต่อเป็นไปได้ยากมาก ทุกอย่างมันใช้เวลา มันมี learning curve แม้แต่จะทำ document ให้ละเอียดขนาดไหนก็ตามก็ทำงานแบบไร้รอยต่อ(seamless)ไม่ได้
• ป้องกันคนไม่ให้ลาออก จ่ายน้อยกว่าปล่อยให้คนลาออก
• ความสำเร็จของ software ไม่ได้วัดกันที่ document การที่บอกว่าเขียน requirement spec เสร็จแล้วถือว่าโปรเจคคืบหน้าไป 10%–20% ไม่มีประโยชน์
• สิ่งที่เป็นความคืบหน้า software จริงๆก็คือ software ที่ทำออกมาได้ถูก validate ด้วยคนใช้งานแล้วว่ามันใช้งานได้จริง
• agile ให้ความสำคัญกับการเปลี่ยนแปลงมากกว่าทำตามแผน คุณกรณ์ยกตัวอย่างว่า วันนี้วางแผนไว้ว่าจะซักผ้า แต่ฝนดันตก ผลลัพธ์ก็คือไม่ได้ซัก ถามว่า เราผิดหรือแผนผิด?…. ตอบ แผนผิด … แล้ว software วางไว้ 4 เดือนจะเสร็จ ผ่านไปไม่เสร็จใครผิด? …. เราผิด (อ้าว…)
• agile บอกว่าไม่มีใครรู้หรอกว่าอนาคตจะเป็นยังไงต่อให้คุณเขียนแผนมาดีก็ตาม ทางที่ดีก็คือปรับแผนทุก 2 สัปดาห์
• ถ้าเรา estimate เวลาได้ตรงตามความเป็นจริง เราก็ไม่ใช่โปรแกรมเมอร์ แต่เราเป็น estimator
• ค่าใช้จ่ายในการ estimate แพงกว่าการลงมือทำจริง
• ส่วนใหญ่ฝ่าย management ชอบยึดแผนแรกซึ่งในโลกความเป็นจริงการวางแผนทำไว้เพื่อประเมิน แต่ในโลก software การวางแผนมีไว้เพื่อเชือดคน ทั้งๆที่ในตอนแรกฝั่ง business ก็ไม่รู้ว่าต้องการอะไรแบบชัดเจน
• การทำ software แบบตั้ง budget ทำให้ได้ software ที่ไม่มีประสิทธิภาพเพราะจริงๆแล้ว software เป็นอะไรที่ dynamic ทำแล้วก็ปรับแก้ให้ดีขึ้นเรื่อยๆ ไม่ต่างจากการทำงานตำแหน่งอื่นๆ แต่ถ้าจำกัดกันด้วยวงเงินเมื่อเงินหมดก็ต้องรีบปิดงาน ก็(อาจจะ)ไม่ได้สิ่งที่ตอบสนองความต้องการได้จริง
• (ผมสรุปเอง)สุดท้ายทางออกก็คือแบ่งงานทำทีละน้อยแล้วรีบ deliver งานออกมาเพื่อ validate ความต้องการกับคนใช้งานจริงๆว่ามัน work ไหม แล้วเอากลับมาแก้ไขทำให้ software มีประสิทธิภาพที่สุด อย่าเสียเวลาทำเอกสารแบบเอาเป็นเอาตาย

ถ้าช้าไม่เป็นก็เร็วไม่ได้ by คุณหนุ่ม@สยามชำนาญกิจ

• ความเชี่ยวชาญเกิดจากการทำอะไรซ้ำๆ ฝึกฝนต่อเนื่อง การฟังอะไรแล้วกลับไปทำเลยคิดว่าจะเทพขึ้นไหม ตอบว่าไม่.. ทุกอย่างก็ต้องกลับไปฝึก เริ่มต้นอาจจะช้าลงด้วยซ้ำ แต่ทำไปเรื่อยๆจะทำให้ไวขึ้นเอง
• agility = skill + discipline
• agile ทำให้ไว แต่ถ้าไม่เคยทำ agile เริ่มแรกถ้าเอาไปใช้ มันต้องช้ากว่าเดิมแน่นอนกว่าจะเข้าใจ และเอามาทำได้จริงมันต้องใช้เวลา
• ความเร็วในทีม = คนที่ช้าที่สุด
• พื้นฐานสำคัญมากนักกีฬาทุกคนฝึกซ้อมพื้นฐานตลอดกว่าจะได้ลงสนามฝึกรวม
• tester สมัยนี้ต้องเอา automate มาใช้ได้แล้ว
• เท่าที่พูดมา ทุกอย่างช้าลงหมดเพราะต้องกลับไปที่พื้นฐานของแต่ละคนในทีม ซึ่งเป็นสิ่งที่ทุกคนละเลย ทุกวันเข้าไปทำงานต่างฝ่ายก็ทำงานของตัวเอง ไม่มีใครมีเวลากลับไปทำเรื่องพื้นฐาน คำถามคือฝั่ง management รอได้ไหม?
• คนส่วนใหญ่กระโดดเข้ามาใช้ framework โดยไม่เข้าใจพื้นฐาน มันจะไปต่อได้จริงไหม?
• คุณหนุ่มยกตัวอย่างว่าหลายๆครั้งโปรแกรมเมอร์ไม่เข้าใจ business ที่ทำเลย ที่โปรแกรมเมอร์รู้ก็คือว่าจะตะบี้ตะบันเอา angular ไปยัดในโปรเจคใหม่ได้ยังไง แต่พอถามว่าทำไมต้อง angular พวกเขาก็กลับตอบว่าไม่รู้(ขาดพื้นฐาน)
• automation สำคัญมาก อะไรที่มันทำงานแทนเราได้ ต้องเอามาทำ ไม่อย่างนั้นกระบวนการ agile ก็ไม่สำเร็จ
• ใครเขียนโปรแกรมคนนั้นต้อง test เอง ไม่ใช่หน้าที่ tester มา report defect log
• เมื่อมี requirement เข้ามาสิ่งแรกที่ต้องคิดคือ เราจะทดสอบมันยังไงว่า work และจะ demo/review มันยังไงกับคนที่ใช้งานมันจริงๆ
• unit test เป็นเรื่องที่โปรแกรมเมอร์ต้องทำ
• ถ้าจะเอา agile ไปใช้ในองค์กร ให้เริ่มทีละทีมทำให้ดีที่สุด อย่าไปปรับทีเดียวทั้งองค์กร
• ฝ่าย management ต้องรู้ว่าเอา agile ไปใช้แล้วจะช้าลงแค่ไหน?
• คนใหม่เข้ามาอย่าปฏิเสธประสบการณ์ของเขา ให้รับฟังเผื่อเอามาใช้
• ฝากให้คนที่มาฟังกลับไปตั้งคำถามว่าทำไมต้องมาใช้ agile
• (ผมสรุปเอง) สุดท้าย session นี้จะบอกว่าการเอา agile ไปใช้ต้องใจเย็นๆ ในตอนเริ่มต้น productivity คุณอาจจะลดลงด้วยซ้ำเพราะทุกคนต้องกลับไปที่พื้นฐาน แต่ถ้าทำอย่างมีวินัย และเพิ่มทักษะไปเรื่อยๆทีมคุณจะแข็งแกร่งขึ้นเองและเมื่อนั้นมันถึงจะไปได้ไว

จริงๆมีอีกหลายเรื่องที่ฟัง แต่ขอเล่าแต่เรื่องที่ผมพอจะจับประเด็นได้ แล้วนำมาใช้งานกับตัวเองได้ครับ ยังไงก็ติดตามข้อมูลกลุ่ม agile66 ได้ครับ ขอบคุณทีมงาน staff ขอบคุณวิทยากรทุกท่าน ขอบคุณ go soft แล้วก็ขอบคุณเพื่อนร่วมงานทุกคนที่ได้มาเจอและแลกเปลี่ยนกันครับ

..ณัฐวุฒิ สิงห์ถม..