ตลอดเดือนมกราคมที่ผ่านมา… ผมถูกถามเรื่อง Agile และ Scrum จากสองสามการสนทนา และเป็นคนเสนอให้เพื่อนๆ จากหลายวงสนทนาไปเรียนรู้เรื่อง Agile เพื่อสร้างวัฒนธรรมองค์กรและการทำงานที่เข้ากับการเปลี่ยนแปลงที่เกิดขึ้นตลอดเวลาในปัจจุบัน… ซึ่งการพูดคุยทั้งหมดเพื่อหาแนวทางการทำงานที่ต้องเจอกับการเปลี่ยนแปลง รวมทั้งการจัดการที่ต้องปรับเปลี่ยนที่เกิดขึ้นตลอดเวลาจนกลายเป็นความปกติใหม่ หรือ New Normal ไปแล้ว
ผมเข้าสู่สายอาชีพโปรแกรมเมอร์มาตั้งแต่ยุค 90 ที่ถือว่ายังเป็นยุคการพัฒนาซอฟต์แวร์เป็นแบบ Walterfall เหมือนๆ กันทั้งโลก… Walterfall Workflow จะทำงานกันเป็นชั้นๆ ที่การไหลของงานจะเหมือนน้ำตก ไหลจากบนลงล่าง ผ่านชั้นหินระหว่างทางแล้วค่อยไหลลงชั้นต่อไป… ซึ่งถือว่าเป็นยุคมืดของนักพัฒนาซอฟท์แวร์ก็ว่าได้ ที่ต้องทำงานไม่ต่างจากช่างก่อสร้างที่ต้องเคารพแบบแผนและเป็นขั้นเป็นตอน และเกิดความผิดพลาดขึ้นมากมาย
อุตสาหกรรมซอฟต์แวร์ยุคนั้น… ขบวนการ หรือ Process แบบไล่ลำดับไปตามขั้นตั้งแต่การเก็บ User Requirements ไปจนถึงได้ซอฟต์แวร์ออกมาพอใช้งานได้… ช่างยาก ยาวนานและสิ้นเปลืองทรัพยากรทั้งที่มองเห็นและมองไม่เห็น… ทำให้มีความพยายามหาทางพัฒนาซอฟท์แวร์ด้วยเทคนิคใหม่ๆ ที่สามารถรวมการทำงานเชิงวิศวกรรมและการจัดการเข้าไปด้วยกัน เพื่อกำจัด Walterfall Process ซึ่งทุกคนเห็นเหมือนกันว่า… ช่างล้าหลังและไร้ประสิทธิภาพถึงขั้นสร้างปัญหาให้ทั้ง Product หรือตัวซอฟท์แวร์ที่กำลังพัฒนาอยู่… ทีมที่กำลังทำงานอยู่และลูกค้าที่กำลังรอด้วยความหวังว่าซอฟท์แวร์ที่ได้ จะช่วยให้งานและธุรกิจของตัวเองดีขึ้น… แต่ผลลัพธ์ส่วนใหญ่ของผลิตภัณฑ์สุดท้าย ยังคงไม่สมบูรณ์จนถึงขั้นใช้งานจริงไม่ได้บ่อยครั้ง แม้ว่าจะทำงานบน Requirement ทุกโจทย์แล้วก็ตาม… ซึ่งส่วนใหญ่เป็นความผิดพลาดจากการสื่อสารทำความเข้าใจของผลลัพธ์จากโจทย์เดียวกัน
กระทั่งวันที่ 13 กุมภาพันธ์ 2001 ณ สกีรีสอร์ตชื่อ The Lodge at Snowbird ในเทือกเขา Wasatch มลรัฐยูท่าห์ สหรัฐอเมริกา… นำโดย Jon Kern, Kent Beck, Ward Cunningham, Arie van Bennekum, และ Alistair Cockburn ซึ่งเป็นการพบกันหลังจากวาระก่อนหน้า ได้มีการพบปะกันที่ Oregon มาก่อนแล้ว… ซึ่งการพบกันที่ The Lodge at Snowbird คราวนี้… พวกเขาพร้อมแล้วที่จะประกาศสิ่งที่เรียกว่า… Agile Manifesto ซึ่งเปลี่ยนโลกของวิศวกรรมซอฟต์แวร์ไปตลอดกาล… รวมทั้ง Mindset ในการบริหารจัดการองค์กรและทีมสมัยใหม่อีกด้วย
โดยแนวคิดหลักของ Agile คือการสื่อสารกับทุกฝ่ายที่เกี่ยวข้องเพื่อปรับปรุงผลิตภัณฑ์ให้ดีขึ้นตลอดเวลา… ซึ่งขั้นตอนหรือ Process ที่เคยเป็น Waterfall มาก่อนได้ถูกบิดให้กระชับเข้าด้วยวิธีการต่างๆ ที่ขึ้นอยู่กับงาน… ซึ่งจะอธิบายเพิ่มเติมในภายหลังสำหรับวิธีดำเนินการแบบต่างๆ ในกรอบ Agile… แน่นอนว่า ผลลัพธ์ที่ได้คือความพึงพอใจของทุกฝ่ายที่เกี่ยวข้อง
วันที่ Agile Manifesto ถูกเขียนขึ้นอย่างเป็นทางการและเผยแพร่ออกไป… Agile Manifesto ถูกเผยแพร่พร้อมกับ 4 คุณค่าและ 12 หลักการ หรือ Four Foundational Values and 12 Supporting Principles หรือ The Four Values and The Twelve Principles of Agile Manifesto ด้วย… มาดูด้วยกันเลยครับว่ามีอะไรบ้าง
The Four Values of The Agile Manifesto หรือ 4 คุณค่าหลักของ Agile Manifesto
คุณค่า 4 ประการของ Agile Manifesto ที่ว่านี้… จะว่าไปก็คือแก่นของเหตุผลที่จะนำ Agile เข้ามาใข้กับทีมหรือองค์กรเพื่อทำของบางอย่างหรือพัฒนาอะไรซักอย่างนั่นเอง… ซึ่งคุณค่าทั้ง 4 ประกอบด้วย…
1. Individuals and Interactions Over Processes and Tools… เน้นการสื่อสารและปฏิสัมพันธ์ระหว่างคน เหนือกว่าขั้นตอนและเครื่องมือที่ใช้
คุณค่านี้เป็นเรื่องของการให้ความสำคัญกับคนและทีม มากกว่าจะยึดขั้นตอนที่หมายถึง ขบวนการและขั้นตอนการทำงานเปลี่ยนแปลงได้ถ้าคนคุยกัน… เครื่องมือก็เปลี่ยนแปลงได้ถ้าคนคุยกัน… ซึ่งแปลง่ายๆ ว่า ถ้าขั้นตอนหรือเครื่องมือทำงานเป็นอุปสรรค คุยกันได้ก็เปลี่ยนแปลงสิ่งอื่นได้เพื่อให้งานออกมาดี-เร็ว-จบ
2. Working Software Over Comprehensive Documentation… ทำซอฟต์แวร์หรือผลิตภัณฑ์ มากกว่าการทำเอกสาร
คุณค่านี้คือการโฟกัสงานหลัก ซึ่งกรณีของการพัฒนาซอฟต์แวร์ก็คือตัวซอฟท์แวร์… ไม่ใช่สไลด์ PowerPoint ที่จะเอามาประชุมนำเสนอ ไม่ใช่เอกสารอ้างอิงที่รวบรวมแล้วรวบรวมอีก… และหลายครั้งไม่ต้องใช้หลักฐานเชิงประจักษ์อ้างอิงมากมายเพราะอะไรก็ตามที่มี Evidence Based Practice มาก่อน ย่อมไม่ใช่ New Innovation… การเน้นทำผลิตภัณฑ์หรือ Product จึงเป็นเรื่องสำคัญที่ต้องให้ความสำคัญและรักษาคุณค่านี้ไว้
3. Customer Collaboration Over Contract Negotiation… สนองผู้ใช้งาน มากกว่าแค่ทำตามสัญญา
ข้อนี้คือ Customer Centric ของแท้ที่ตรงเข้าช่วยแก้ปัญให้ลูกค้ามากกว่าจะยึดตามกฏระเบียบ เงื่อนไขหรือสัญญาที่เขียนไว้แต่ทำให้ลูกค้าเสียประโยชน์ในตอนท้าย… ซึ่งศาสตร์ว่าด้วย Customer Centric เป็นเรื่องสำคัญที่ต้องขยายความได้ทั้งกว้างและลึกอีกมาก… ชั้นนี้ทราบไว้แต่เพียงว่า… Agile Manifesto ยึดการทำงานแก้ปัญหาร่วมกับลูกค้า ให้ผลประโยชน์ลูกค้าเป็นศูนย์กลางเหนือกว่าข้อตกลงหรือสัญญาที่เคยทำไว้
4. Responding to Change Over Following a Plan… เน้นการปรับปรุงพัฒนา มากกว่าการทำตามแผนที่วางเอาไว้
ข้อสุดท้ายเป็นเรื่องของการปรับเปลี่ยนและพัฒนาขึ้น… ซึ่งการปรับเปลี่ยนเป็นหัวใจของนวัตกรรมและความทันสมัย และอีกหลายๆ อย่างที่ตรงกันข้ามกับการอยู่เฉยๆ หรือทำตามแผนเดิม เปลี่ยนแปลงไม่ได้… อะไรก็ตามที่ทำแล้วดีขึ้นกว่าทำตามแผนเดิม ทำเลย!… อะไรที่ทำแล้วเร็วขึ้นกว่าทำตามแผนเดิม ทำเลย!… อะไรที่ทำแล้วประหยัดกว่าเดิม ก็ทำเลย!
The Twelve Agile Manifesto Principles หรือ 12 หลักการพื้นฐานของ Agile Manifesto
1. Customer satisfaction by early and continuous delivery of useful software – สร้างความพึงพอใจให้ลูกค้าโดยส่งมอบซอฟต์แวร์ที่ใช้งานได้จริงก่อนกำหนดและต่อเนื่อง… ซึ่งจะเป็นซอฟท์แวร์หรืออะไรก็ตาม ส่งงานให้ไวและบ่อยที่สุดเท่าที่จะเป็นไปได้ โดยไม่รอให้งานเสร็จทีเดียวค่อยส่ง… หากเป็นไปไม่ได้จริงๆ ก็ให้รายงานความก้าวหน้ากับลูกค้าและคนที่เกี่ยวข้องสม่ำเสมอ
2. Welcome changing requirements, even in late development – ยินดีปรับเปลี่ยน Requirement แม้จะทำให้งานล่าช้ากว่าเดิม… ซึ่งบ่อยครั้งที่ทีมหรือแม้แต่ลูกค้าเองก็อาจจะค้นพบอะไรใหม่ๆ ที่อยากได้เพิ่มเติมหลังจากเห็นงานเป็นรูปเป็นร่างแล้วก็มีอยู่บ่อยๆ การยืดยุ่นให้งานสมบูรณ์แบบกว่าเดิมให้ถือเป็นเรื่องน่ายินดีแม้จะเพิ่มภาระหลายอย่าง
3. Working software is delivered frequently (weeks rather than months) – ส่งมอบซอฟท์แวร์ถี่ๆ รัวๆ ให้ได้ดีกว่าเดือนละครั้ง… ส่วนนี้คือการสื่อสารกับลูกค้าครับ อาจจะไม่ใช่การส่งมอบโดยตรง แต่ให้ลูกค้าหรือแม้แต่ทีมได้เห็นพัฒนาการว่างานในมือท่านไปถึงไหนแล้ว
4. Close, daily cooperation between business people and developers – ปิดงานรายวันแจ้งผู้ที่เกี่ยวข้องภายใน… ข้อนี้ก็ยังอยู่ที่การสื่อสารที่เน้นการสื่อสารภายในทีมและองค์กรแบบไม่ต้องมีคนอยากรู้ต้องถามเอา หรือปล่อยให้คนไม่รู้งงต่อไปว่ามันทำอะไรอยู่
5. Projects are built around motivated individuals, who should be trusted – โครงการทุกโครงการต้องสร้างจากแรงจูงใจและความไว้วางใจ… หมายถึงงานที่มอบหมายแล้วต้องมอบงานให้พร้อมกับผลประโยชน์ที่เป็นแรงจูงใจในการทำงานนั้นให้ลุล่วง และต้องไว้ใจสมาชิกทีมที่รับผิดชอบงานอยู่
6. Face-to-face conversation is the best form of communication (co-location) – คุยกันแบบเห็นหน้ากันพูดกันเป็นวิธีที่ดีที่สุดในการสื่อสาร… ดีที่สุดคือไปเจอกันคุยกัน หรือ Video Call คุยกันเพื่อให้คู่สนทนาได้อ่านภาษากายหรือ Nonverbal Language ด้วย
7. Working software is the principal measure of progress – ซอฟต์แวร์ที่ใช้งานได้จริงคือหลักการในการวัดความก้าวหน้า… ซึ่งงานที่ไม่เสร็จในคราวเดียวที่มีการรายงานความก้าวหน้า จำเป็นต้องมีตัวชี้วัดที่ชัดเจนว่าทำแค่ไหนคือเสร็จไปเท่าไหร่… ในกรณีของการพัฒนา Software การทำงานไปแค่ไหนแล้วยังไม่ใช่ตัวชี้วัดที่ชัดเจน จึงต้องกำหนดตัวชี้วัดเพิ่มว่า Code ที่เขียนไปแล้วจนเป็นซอฟท์แวร์หรือโมดูลหนึ่งของซอฟท์แวร์… ต้องใช้งานได้ด้วย
8. Sustainable development, able to maintain a constant pace – ใช้การพัฒนาแบบยั่งยืนช่วยรักษาความสัมพันธ์ที่ไม่ขัดแย้ง… หมายถึงรักษาความสัมพันธ์ให้ยืนยาวและจัดการทุกความขัดแย้งให้ลงตัว ซึ่งประเด็นนี้ผมคิดว่าสำคัญมากทั้งกับทีมและลูกค้า และบทบาทของผู้นำมีความสำคัญเท่าๆ กับทักษะการจัดการปัญหาและความขัดแย้งโดยผู้นำ… ที่ทักษะและภาวะผู้นำ จะช่วยให้ขั้นของการพัฒนาผลิตภัณฑ์ยั่งยืนเอง… ซึ่งไม่เกี่ยวกับตัวผลิตภัณฑ์เลย แต่เป็นความสัมพันธ์ของคนล้วนๆ ก็ว่าได้
9. Continuous attention to technical excellence and good design – ให้ความสนใจอย่างต่อเนื่องกับเทคนิคที่ยอดเยี่ยมและการออกแบบที่ดี… ตรงๆ ตามนั้นเลยครับ ออกแบบให้ดี… สวยงามได้แค่ไหนใส่เต็มๆ ไปเลยครับ มีเทคนิคอะไรที่ล้ำเลิศก็อย่าได้รีรอที่จะนำมาใช้
10. Simplicity the art of maximizing the amount of work not done is essential – ใช้ศิลปะของความเรียบง่ายขั้นสุดกับงานทั้งหมด ไม่ทำแค่พอเป็นพิธี… แนะให้ทำเรื่องง่ายให้เป็นง่าย และทำเรื่องยากให้เป็นเรื่องง่าย หาวิธีทำให้ทั้งหมดเป็นเรื่องง่ายๆ อย่าเยอะ อย่าละความใส่ใจที่จะหาทางทำภาระกิจตรงหน้าให้เสร็จสมบูรณ์ด้วยความเรียบง่าย… ระมัดระวังอย่ามักง่ายก็พอ
11. Self-organizing teams – ใช้ทีมที่มีความสามารถดูแลตัวเอง… แปลว่าถ้าความสำเร็จและผลงานของทีมไม่ได้ขึ้นอยู่กับพวกเขา แต่ต้องพึ่งพาปัจจัยและตัวแปรนอกมากมาย ให้พิจารณาศักยภาพของทีม โดยจัดทีมและมอบหมายงานใหม่ให้เหมาะสม และทีมควรทำงานเข้าขากัน โดยทำลายการขัดขาขัดคอในทีมให้หมด
12. Regular adaptation to changing circumstance – ให้ยกระดับและปรับเปลี่ยนเป็นวงจรปกติ… หมายถึงการพัฒนาตัวเองและทีม โดยการเรียนรู้และเปลี่ยนแปลงให้ดีขึ้นควรเป็นเรื่องปกติ… ซึ่งส่วนใหญ่ได้มาจาก Feedback ทั้งภายในและภายนอก ที่ต้องรับฟังและปรับเปลี่ยน
ปูพื้นกันเท่านี้ก่อนครับ… ในขั้นนี้ยังถือเป็นแนวคิด Agile แบบที่ Software Engineer ใช้ทำงานกันในทีมและร่วมงานกับลูกค้าหรือคู่ค้าอยู่… แต่ผมก็พยายามตีความแบบ Reder ให้ออกมากลางๆ แต่ยังถือว่าห่างไกลจากการประยุกต์ใช้งานที่ทีมหรือองค์กรในปัจจุบัน นำมาใช้กันอย่างกว้างขวาง… พรุ่งนี้มาต่อกันเรื่อง Scrum และ Sprint ที่ถือเป็นแม่แบบขั้นปฏิบัติของการใช้ Agile กับทีมและองค์กรครับ… ขออภัยท่านที่อ่านแล้วงงๆ กับเนื้อหา ซึ่งค่อนข้างเฉพาะเจาะจง ซึ่งไม่เหมาะกับท่านที่ไม่ได้เกี่ยวข้องกับการพัฒนาอะไรใหม่ๆ เท่าไหร่… ซึ่งหากท่านสนใจจริงๆ อยากให้ผมอธิบายเพิ่มเติมเป็นการส่วนตัว หรืออยากพูดคุยลงลึก… Line id: @reder ยินดีแลกเปลี่ยนกับทุกท่านครับ
