A Brief History of Agile — (Day 1 Agile for Software Development at RMUTT)

ช่วงนี้ได้มาช่วยสอนอาจารย์ที่มหาวิทยาลัยเทคโนโลยีราชมงคลธัญบุรี 3 วัน เรื่อง Agile for Software Development กับชาวคณะ มี Prathan D. , aj.jammy และ Nitipat Lowichakornthikun ก็ได้ทบทวนเรื่องราว อัพเดทเทคนิคการสอน และอัพเดทข้อมูลจากทางพี่หนุ่มด้วย

อาจเพราะผมไม่ได้เข้ามาร่วมทีมสัมนาของบริษัทหลายครั้ง พบว่าเทคนิคการเล่าเรื่องของพี่หนุ่มเปลี่ยนไป ฟังเพลิน เหมือนประวัติศาสตร์ ที่มันมี Timeline และการเชื่อมโยงเหตุการณ์ กับหัวข้อต่างๆ เลยอยากจั่วหัวบล็อกว่า A Brief History of Agile ดูเข้าท่าดี (ล้อชื่อหนังสือ A Brief History of Time และรำลึกถึง Stephen Hawking ผู้เขียน)

ประเด็นที่ถูกเปิดตอนเริ่มคลาสคือปัญหาเรื่องการศึกษาของไทย และความหมายของคำว่า Agility ผ่านการตั้งคำถามว่า ถ้าสิบโมงเช้าได้โจทย์ต้องเปลี่ยนระบบคิดเงินจาก VAT 7% มาเป็น 10% และต้องเสร็จภายในบ่ายสอง .. กระบวนการและระบบของเราสามารถทำแบบนั้นได้หรือไม่?

จากนั้นเล่าที่มาว่า ได้มีบุคคล 17 คน ทำการประกาศ Agile Manifesto โดยมี 4 Core Values และ 12 Principles ซึ่งบุคคลเหล่านั้นได้กลั่นจากประสบการณ์ที่ตนเองประสบมา ต้องบอกว่าบุคคลเหล่านั้นไม่ใช่ตาสีตาสานะครับ แต่เป็นระดับคนที่คิด Framweork ต่างๆ เช่น Scrum, DSDM, XP, Crystal Clear เป็นต้น

ในไทยเองมีความเข้าใจผิดเกี่ยวกับ Agile พอสมควร เช่น Agile ไม่ต้องทำเอกสาร, Agile เปลี่ยนแปลงได้ตลอดเวลา, Agile ทำให้ไวขึ้น ซึ่งถ้าฟังแบบนี้ ทาง Business ก็ชอบใจและอยากมุ่งไปทำกันหมด แต่แท้จริงแล้ว มันมีรายละเอียดมากกว่านั้น ถ้าจะทำให้เกิดได้ ซึ่งพี่หนุ่มได้ยกตัวอย่าง เช่น ..

1. Individuals and interactions over processes and tools การทำงานที่เกิดจากการทำเป็นทีม ซึ่งต้องมีคนจากหลาย Skill มารวมกัน สามารถทำทุกอย่างเองได้ ทีมดูแลกันเองได้ และถูก Dedicate ออกมาเพื่อทำงานๆหนึ่งโดยเฉพาะ
2. Working software over comprehensive documentation ซึ่ง Source Code ก็เป็นเอกสารเช่นกัน แต่ไม่ให้ความสำคัญ มันเลยไม่เป็นมิตรกับคนอ่านทุกคนเท่าไร หรือแม้แต่คนเขียนเอง (Human Readable) ตัวอย่างเช่นการตั้งชื่อ Function ควรอธิบายถึงพฤติกรรม ว่าใส่อะไรเข้าไป ทำอะไร และได้อะไรออกมา
3. Customer collaboration over contract negotiation ปัญหาของ SDLC เดิม (Waterfall) คือ พอเริ่มจากเก็บ Requirement > Analyst > Design … กว่าจะได้เห็นของที่พอใช้ได้อีกทีก็ตอน Test ซึ่งกินเวลานานมาก จึงต้องทำให้กระบวนที่ทำอย่างไรให้ทำ SDLC ครบตามเดิม แต่ย่อเวลาให้สั้นลง จึงสับออกมาเป็น เห็นของบ่อยๆในทุกระยะ หรือที่เราเรียกว่า Iteration ดังนั้นเมื่อลูกค้าเห็นของได้เร็วขึ้นและบ่อยขึ้น กระบวนการ Change และทำงานร่วมกันก็จะบ่อยขึ้นตามมา (แต่เรารู้ได้ก่อน) ผสมกับ Requirement เดิมที่ต้องนำทั้งหมดมาจัดความสำคัญใหม่ และทุกครั้งที่จบ Iteration ของที่ได้จะต้องใช้ได้และโตขึ้นเรื่อยๆ หรือที่เรียกว่า Incremental
4. Responding to change over following a plan จากผลของข้อ Customer collaboration ทำให้เกิดการคุยกัน ทำงานร่วมกัน และมีปรับปรุงตลอด ดังนั้นข้อนี้ก็จะเกิดขึ้นโดยอัตโนมัติ

แต่ทั้งนี้ 4 Core Values ยังจับต้องไม่ได้ ต้องไปดูที่ 12 Principals เพิ่มเติมว่า หลักปฏิบัติมีอะไรบ้าง ตรงนี้ เป็นความท้าทายอย่างหนึ่งของผู้นำไป Implement เพราะจะทำอย่างไรล่ะ ที่จะเชื่อมโยงแต่ละข้อเข้ากับ Practice และทำให้เกิดผลได้ ยกตัวอย่าง เช่น

ข้อ 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. ดังนั้น Software ต้องเป็นชิ้นเล็กๆ ขยับขยาย เปลี่ยนแปลง นำเข้า นำออก เพื่อส่งมอบได้ตลอดเวลา เช่น ต้องเขียนด้วย OOP เป็นต้น ทั้งนี้ จะได้ Software แบบนั้น นอกจากต้องมีการวางสถาปัตยกรรมที่ดี ยังต้องรู้จักการจัดสรรงานที่ดีด้วย เพื่อให้ Software ที่ส่งมอบได้บ่อยๆนั้น สามารถใช้งานได้จริงด้วย

ข้อ 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. การทำงานแบบ Agile จะไม่เร็วในทันที แต่กลับช้าลงกว่าเดิมด้วย เพราะต้องจูนคนในทีมให้เข้าใจกัน Skill มีพอเพื่อทำงานออกมาได้ ดังนั้นต้องมี Practice ต่างๆ เพื่อปรับทีม, ถ้าเทียบการทำ SDLC แบบเก่า เหมือนการวิ่งผลัด ที่ต่างคนต่างวิ่ง และส่งไม้ต่อ บางคนช้า บางคนเร็ว แต่สุดท้ายต้องดูที่เวลารวม แต่กระบวนการที่ต้องทำงานเป็นทีม เหมือนคนผูกขาวิ่งไปด้วยกัน แรกๆจะขัดๆ ช้าๆ แต่พอทำบ่อยๆ ก็จะเข้าขากันได้

ข้อ 7 Working software is the primary measure of progress. จะต้องทำให้เป็น Iterative & Incremental เพื่อให้ส่งงานได้บ่อย เห็นงานได้ไว และใช้งานได้จริง

ข้อ 9 Continuous attention to technical excellence and good design enhances agility. ข้อนี้สำคัญ เป็นเรื่องทางเทคนิคอลที่จะทำส่งเสริมให้เกิดข้อต่างๆ ซึ่งมี 4 ข้อพื้นฐานที่ควรทำได้ คือ

1. Source Code Management
2. Coding Standard
3. Automate Build
4. Automated Test

ซึ่งทั้งหมดนี้ในต่างประเทศทำเป็นเรื่องปกติ แต่ในไทยยังไม่ได้ใช้กันมากนัก

จาก 4 Core Values และ 12 Principals นี้ คุณ Alistair Cockburn ได้สรุปให้เข้าใจออกมาเป็น 4 ข้อ เป็น The Heart of Agile

Photo: http://alistair.cockburn.us/Rediscovering+the+Heart+of+Agile

ในช่วงบ่ายได้ให้อาจารย์เล่น Coin Game เพื่อให้ได้สัมผัสกับการทำงานเป็นรอบ การประเมินงาน การจัดสรรงาน

และหลังจากเต็มอิ่มกับทฤษฎีและได้เห็นแนวทางคร่าวๆผ่านเกมส์ จึงได้ให้อาจารย์เริ่มลงงานจริง ด้วยการบอกโจทย์ ว่าเราต้องการทำระบบ e-Wallet ซึ่งให้อาจารย์ลองคิด Feature กันเองด้วยเครื่องมือ Fishbone และให้เขาเลือกหยิบมาทำ 1 Feature ก็คือ การโอนเงิน

จากนั้นนำเรียงให้เห็น Business Flow และทำการกำหนด Test Case ตัวอย่างขึ้นมา คือเคสโอนเงินจากบุคคลหนึ่งไปยังบุคคลหนึ่งได้สำเร็จ โดยให้อาจารย์เขียน Test Data ขึ้นมาด้วยในการใช้ตรวจรับ ซึ่งสิ่งที่เราได้ทั้งหมดเป็นส่วนของ Customer Visible ในเครื่องมือที่ชื่อว่า A-DAPT Blueprint นั่นเอง

วันแรกทั้งหมด เหมือนเราเพิ่งมาทำความรู้จักกับอาจารย์ ได้เห็นวิธีคิด ความแม่นยำในเรื่องทฤษฎี และความเป็นห่วงเป็นใยกับอนาคตของชาติอยู่พอสมควร ซึ่งก็เหมือนกับพวกเราเวลาอ่านข่าวว่า บุคคลากรไอทีขาดแคลน ปัญหาเหล่านี้ ผมก็เพิ่งได้เห็นว่าอาจารย์เองก็พยายามขบคิดพัฒนาตัวเองกันอย่างเร่งด่วน เพื่อให้เสริฟความต้องการของภาคธุรกิจได้ โดยที่ผมรู้สึกว่าพวกท่านไม่ได้เป็นน้ำเต็มแก้ว แถมยังมีไฟอยากทำนู่นนี่อีกเยอะเลย