1. Agile Software Development: case of small team and small project เกริ่น แม้บทความนี้จะเขียนขึ้นเพื่อเสนอวิธีการพัฒนาซอฟต์แวร์ขนาดเล็กแบบ Agile แต่ผมต้องขอออกตัวก่อนว่าข้อเสนอส่วนใหญ่นั้นเกิดจากจากสังเคราะห์ข้อมูลที่ศึกษามาจากแหล่งต่างๆ ผมยังไม่ได้ทดลองวิธีการเหล่านี้ด้วยตัวเอง ดังนั้นความถูกต้องของข้อเสนอเหล่านี้ย่อมถูกจำกัดด้วยความคิดความเข้าใจไม่ใช่ประสบการณ์ตรง อย่างไรก็ตามผมเองได้มีประสบการณ์การพัฒนาซอฟต์แวร์ที่แบบไม่ Agile มาพอสมควรและประสบปัญหาต่างๆ ที่เกิดจากความไม่ Agile นี้ สาเหตุใหญ่ที่ผมเขียนบทความนี้ขึ้นก็เพื่อเป็นสรุปแนวทางวิธีการพัฒนาซอฟต์แวร์สำหรับตัวเองในงานครั้งถัดๆ ไปเพื่อไม่ให้พบกับปัญหาเหล่านั้นอีก ดังนั้นหากข้อเสนอต่างๆ ในบทความนี้สามารถลดปัญหาในการพัฒนาซอฟต์แวร์ของผู้อ่านได้บ้างก็ถือว่าบทความนี้ได้ประสบความสำเร็จเกินจุดประสงค์ของมันแล้วครับ ทำความรู้จัก Agility การพัฒนาซอฟต์แวร์แบบ Agile เป็นแนวคิดเกิดขึ้นไม่นานนี้นั้นคือปี ค.ศ. 2001 หลังจากนั้นก็มีการให้คำอธิบายผ่านเว็บไซต์และหนังสือมากมาย แต่ความหมายของ Agility ที่ผมคิดว่าเป็นการสรุปความที่ดีและขอยกมาในที่นี้คือ
The ability to move faster than those things that can harm your project…
Agility คือความสามารถในการจัดการความเปลี่ยนแปลงก่อนนี้ความเปลี่ยนแปลงนั้นจะส่งผลเสียต่องานของเรานั้นเอง เราสามารถสังเกตได้ว่าความเปลี่ยนแปลงในวงการพัฒนาซอฟต์แวร์นั้นเกิดขึ้นในหลายระดับพร้อมๆ กัน ตั้งแต่การเปลี่ยนแปลงที่เกิดขึ้นจากตัวเราเอง (แก้บั๊กโปรแกรม) จากผู้ใช้/ลูกค้า (เปลี่ยน Requirement) และจากโลกภายนอก (เปลี่ยน OS ภาษา เทคโนโลยีใหม่ๆ ทุกปี) ด้วยความถี่และความหลากหลายของความเปลี่ยนแปลงนี้เองเป็นเหตุผลหลักที่ทำให้การทำงานแบบ Agile มีความจำเป็นกับคนในวงการพัฒนาซอฟต์แวร์มากกว่าในวงการอื่นๆ ตาราง SEQ ตาราง ARABIC 1 เปรียบเทียบความเปลี่ยนแปลงในระดับต่างๆ ในแต่ละวงการ ความเปลี่ยนแปลงจากผู้ทำงาน(ทำงานผิดพลาด บั๊ก)จากลูกค้า/ผู้ใช้(เปลี่ยนฟีเจอร์ / Requirement) จากโลกภายนอก(ความรู้ใหม่ ทักษะใหม่ๆ)การก่อสร้างX--การออกแบบกราฟฟิคXX-การพัฒนาซอฟต์แวร์XXX เข้าสู่ Agility ทีมที่จะสามารถทำงานแบบ Agile จำเป็นต้องมีจุดมุ่งหมายที่จะทำงานให้สำเร็จที่ตรงกันก่อน นั้นคือมีความกล้า ความกระตือรือร้น และเปิดกว้างที่จะรับความคิดใหม่ๆ มิฉะนั้นข้อปฏิบัติต่างๆ จะกลับสร้างความล้มเหลวมากขึ้น และต่อไปนี้คือข้อเสนอต่างๆ ซึ่งออกแบบมาสำหรับทีมพัฒนาซอฟต์แวร์งานซีเนียร์โปรเจค (เป็นซอฟต์แวร์ขนาดเล็ก ทีมไม่เกิน 4 คน ระยะเวลางานไม่เกิน 1 ปี) อย่างไรก็ตาม ผมเชื่อว่าข้อเสนอเหล่านี้สามารถประยุกต์ใช้ในสถานการณ์อื่นๆ ได้ Release ถี่เดือนละครั้ง การพัฒนาซอฟต์แวร์ให้สามารถออกเวอร์ชั่นที่ใช้งานได้ตั้งแต่เนิ่นๆ มีประโยชน์ในหลายๆ ด้าน แก้ปัญหาการ Integration และ Deployment ได้ตั้งแต่ปัญหายังเล็ก เพราะการ release แต่ละรอบเป็นการตรวจสอบปัญหาดังกล่าว และทำให้เกิดความมั่นใจได้ว่าถ้าสุดท้ายมีปัญหาด้านการ Integration หรือ Deployment เรายังสามารถนำเอางานเวอร์ชั่นก่อนมาใช้ได้ ประสิทธิภาพด้านเวลา การออกเวอร์ชั่นในแต่ละเวอร์ชั่นนั้นเราจะบังคับให้เราคัดทำแต่สิ่งที่สำคัญที่สุดในเวลาที่เหลือ การแบ่งเวอร์ชั่นย่อยๆ ทำให้เรามองเห็นเป้าหมายที่อยู่ไม่ไกล และเกิดแรงผลักดันในการทำงานที่มองเห็นเป้าหมายใกล้ๆ ประเมินผลงานได้บ่อย เพราะแต่ละรอบที่ release ความรู้ความเข้าใจในเกี่ยวกับโปรเจคเราจะเพิ่มขึ้นมากกว่าก่อนเริ่มงานที่ยังไม่เห็นภาพอยู่มาก เราสามารถนำความเข้าใจตรงนี้ไปใช้ในการออกแบบรายละเอียดหรือเพิ่ม/ลดความสำคัญในประเด็นต่างๆ (เช่น การเพิ่มประสิทธิภาพการจัดการหน่วยความจำและลดความเร็ว) ความมั่นใจว่างานจะไม่เสียในตอนสุดท้ายในตอน Deployment และการเห็นงานค่อยๆ ก้าวหน้าขึ้นทุกๆ เดือนจะทำให้เราทำงานอย่างมีความสนุกมากขึ้น สิ่งที่ควรทำเพื่อให้สามารถ release ได้อย่างสะดวกมากขึ้นคือการทำ automation installer เพื่อให้ทดสอบการ deployment ได้อย่างรวดเร็ว Design แค่ภาพรวมเพื่ออ่านกันเอง การออกแบบสิ่งที่ไม่ทำไม่ได้ เพราะการพิจารณาเปรียบเทียบข้อดีข้อเสียของโครงสร้างของระบบและความสัมพันธ์ระหว่างส่วนย่อยของระบบนั้น จะทำให้เราเกิดความเข้าใจในงานของเรามากขึ้น แต่ถ้าเราออกแบบไปถึงรายละเอียด Method, data type, parameters หรือลำดับการทำงานต่างๆ ที่แน่ชัด เราจะพบว่าสิ่งที่ออกแบบไว้ยังดีไม่พอเมื่อเขียนโค้ดจริงไปถึงส่วนที่ออกแบบไว้ เพราะเมื่อได้เขียนโค้ดเราจะมีความเข้าใจในงานมากขึ้นมาก โดยเฉพาะในงานที่ใช้เทคโนโลยีที่ยังไม่คุ้นเคยมาก่อน เราจึงไม่ควรเสียเวลาออกแบบอย่างละเอียดหรือทำเอกสารที่เป็นทางการไปกว่าเขียนคร่าวๆ ลงกระดาษหรือไวท์บอร์ดตั้งแต่เริ่มต้นงาน การออกแบบที่ควรมีลักษณะดังนี้ กำหนดเพียงทิศทางในการพัฒนา เช่น พิจารณา Class ที่น่าจะมีและระบุชื่อ หน้าที่ และความสัมพันธ์กับ Class อื่นในงานต่างๆ Reversibility นั้นคือสามารถแก้ปรับเปลี่ยนส่วนต่างๆ ในภายหลังได้โดยกระทบต่อระบบอื่นๆ เพียงเล็กน้อย Simple นั้นคือไม่ทำงานอะไรเกินจากสิ่งที่จำเป็น เพื่อใช้เวลาอย่างมีประสิทธิภาพ เขียน Test นักพัฒนาซอฟต์แวร์จำนวนมากปฏิเสธการเขียน Test ด้วยเหตุผลต่างๆ แต่ที่จริงแล้วการ Test ไม่ว่าจะเขียนก่อนหรือหลังการโปรแกรม นั้นมีผลต่อความสำเร็จในหลายๆ ด้าน ได้แก่ เพิ่มคุณภาพ Code ช่วยลดบั๊กในโปรแกรม เป็นผลโดยตรง เราสามารถ refactor code ได้โดยไม่เสียเวลาตรวจสอบบั๊กเอง แก้บั๊กได้เร็วขึ้น เพราะมี Test คอยบอกอาการ เพิ่มคุณภาพ Design ถ้าเราเขียน Design ก่อน Test เมื่อพบว่า method ใด Test ลำบากแสดงว่า method นั้นซับซ้อนเกินไป ถ้าเราเขียน Test ก่อน Design เรามักจะ Design ได้งานที่ไม่ซับซ้อนเกินการใช้งานจริง (เหมือนที่การออกแบบโดยเริ่มด้วยออฟเจคมักจะเป็น) เพิ่มคุณภาพ Document เพราะ Test ที่ดีจะสื่อถึงการทำงานของ method นั้นอย่างครอบคลุมเราสามารถเอา ข้อมูล Test ไปทำเอกสารได้ดี เครื่องมือในการเขียน Test ในมีอยู่ในเกือบทุกภาษาให้เลือกใช้ เครื่องมือหลักที่ใช้ Test ได้แก่ Unit Test ใช้ Test ส่วนที่ไม่มี side-effect หรือไม่เกี่ยวข้องกับส่วนอื่นๆ และเขียน Mock เพื่อ Test ส่วนที่จำเป็นต้องติดต่อกับส่วนอื่นๆ การเขียน Test ทำให้เราทราบปัญหาและเข้าไปแก้ได้เร็วขึ้นมาก ตั้งแต่ตอนเขียน Test เสร็จและหรือตอน refactor ในภายหลัง และยังเกิดผลพลอยได้ที่คำคัญทั้งในด้าน design และ documentation เขียน Code ให้เอาไปใช้ต่อง่าย โปรแกรมแต่ละส่วนที่เราเขียนหนึ่งครั้ง จะถูกอ่านต่อหลายต่อหลายครั้ง โดยเฉพาะเวลาทำงานเป็นทีม การลงทุนให้เวลากับการ Coding ให้สะอาดและสวยงามหนึ่งครั้งจึงคุ้มค่าเมื่อเทียบกับผลที่สามารถเพิ่มประสิทธิภาพในการ maintain code ได้เป็นอย่างดี ซึ่งหลักการเขียน Code โดยย่อมีดังนี้ อ่านง่าย code ให้เข้าใจว่าโปรแกรมส่วนนี้ “ทำอะไร” ได้เองโดยไม่ต้องอ่าน comment comment ให้เข้าใจว่าโปรแกรมส่วนนี้ “มีเพื่ออะไร” (ในหลายๆ แพลตฟอร์มเราสามารถทำ documentation จาก comment ได้อัติโนมัติ เช่น .NET ใช่ nDoc Java ใช้ Javadoc) ใช้ enum ไม่ quick hack ให้โปรแกรมทำงานได้โดย +1 -1 โดยผู้อ่านไม่สามารถเข้าใจได้ ไม่พยายามเขียนให้ดูฉลาดหรือเน้นด้านประสิทธิภาพเกินไปจนอ่านได้ยาก Test ง่าย แยกส่วนที่เป็น query(ส่วนที่ให้สถานะของออปเจค) ออกจาก command(ส่วนที่เปลี่ยนแปลงสถานะของออปเจค) และ query จะต้องไม่มี side-effect กับส่วนอื่น ทำให้ Test ง่าย เขียน Class ที่เล็กไม่ซับซ้อนหรือรับหน้าที่หลายอย่าง method แต่ละ method ควรทำงานแค่อย่างเดียวในระดับของ abstraction นั้นๆ Debug ง่าย Handle หรือ propagate exception ให้ครอบคลุม (ไม่ทำการ catch ว่างเปล่าทิ้งไว้) ใส่ error message ที่เป็นประโยชน์เอาไว้ใน exception เพื่อทราบสาเหตุของปัญหาอย่างรวดเร็ว เราอาจแยกประเภทของ error message เพื่อให้ทราบวิธีรับมือกับปัญหาที่เกิดขึ้น ได้แก่ Program defects ผู้พัฒนาต้องกลับไปแก้โปรแกรมเท่านั้น Environment problems ผู้ดูแลระบบสามารถแก้ไขได้ User Error ไม่ต้องแก้ไขใดๆ ผู้ใช้เพียงใส่ค่าใหม่ในรูปแบบที่ถูกต้อง ข้อปฏิบัติเหล่าจะช่วยเพิ่มประสิทธิภาพในการ maintain โปรแกรม และทำให้ไม่เกิดปรากฏการณ์ที่ทุกคนคุ้นเคย นั้นคือ “แก้ยังไงก็ได้ อย่าเข้าไปแตะ class/method นั้น” ตามทันความเปลี่ยนแปลงด้วยการสื่อสาร ในการพัฒนาซอฟต์แวร์แบบที่ไม่ Agile ใช้ลงทุนในการทำ documentation ที่สมบูรณ์ตั้งแต่ต้นเพื่อใช้เป็นเครื่องมือสื่อสารในการทำงานให้ตรงกันในทีม แต่เราจะเห็นได้ว่าการออกแผนงานที่ละเอียดเกินไปตั้งแต่แรกมีโอกาสสูงที่จะพบว่าควรเปลี่ยนแผนเพื่อคุณภาพที่ดีขึ้นหรือแผนใช้ไม่ได้ จึงพัฒนาซอฟต์แวร์แบบ Agile จึงหลีกเลี่ยงการทำ documentation ที่ในอนาคตจะไม่ได้ใช้ ผลที่ตามมาคือเราจำเป็นต้องมีเทคนิคการสื่อสารแบบอื่นๆ ที่สามารถสร้างความเข้าใจให้ตรงกันได้เกี่ยวกับแผนงานและรายละเอียดของงานได้เหมือนเอกสาร ขณะที่มีความยืดหยุ่นสามารถเปลี่ยนแปลงได้ตลอดเวลา และมีประสิทธิภาพสูง เทคนิคในการสื่อสารแบบ Agile เช่น Stand up meeting คือการประชุมที่กำหนดให้เจอหน้ากันเป็นประจำ เช่น อาทิตย์ละ 2 ครั้ง โดยในที่ประชุมทุกคนจะต้องยืนเพื่อเป็นกลวิธีให้ทุกคนใช้เวลาพูดคุยอย่างมีประสิทธิภาพ โดยสิ่งที่ทุกคนต้องพูดคือการตอบคำถาม 3 ข้อคือ ก่อนเข้าประชุมได้ทำอะไรไปบ้าง จะทำอะไรให้บ้างก่อนประชุมครั้งต่อไป การที่ทำมามีปัญหาอะไรเกิดขึ้นบ้าง เวลาในการประชุมไม่เกินควรคนละ 3 นาที อย่างไรก็ตามสามารถนัดคุยเพิ่มเติมเพื่อข้อความช่วยเหลือหรือรายละเอียดหลัง stand up meeting ได้ Project Management Software โดยในที่นี้จะขอแนะนำ PivotalTrakcer เพราะเป็นเครื่องมือที่ออกแบบมาเมื่อการพัฒนาซอฟต์แวร์แบบ Agile มีข้อดีต่างๆ ดังนี้ สนับสนุนการ Design ให้เป็นสัดส่วนและเล็กด้วยการแบ่งงานเป็น user story สนับสนุนให้ให้ความสำคัญกับงานที่เกิดประโยชน์จริงต่อผู้ใช้ ด้วยการไม่ให้แต้มการทำงานกับงานที่ไม่เกิดประโยชน์ต่อผู้ใช้ หรืองานแก้บั๊กของตัวเอง สนับสนุนการ review code สามารถประเมินความเร็วในการทำงานและช่วยแสดงแนวโน้มที่จะทำงานเสร็จทำกำหนดการ รูป SEQ รูป ARABIC 1 ตัวอย่างการใช้งานบน PivotalTracker Mailing list เพื่อใช้ส่งประเด็นข้อมูลต่างๆ เพื่อให้สร้างความเข้าใจและใช้เป็นพื้นที่แชร์ความรู้ เช่น ส่ง CRC Design แบบใหม่ๆ ที่เขียนใส่กระดาษแล้วสแกนเข้ามา ส่งคำอธิบายหรือลิงค์วิธีการแก้ปัญหาที่คนในทีมต้องการ Message ใน version control เป็นสิ่งที่ควรทำอยู่แล้ว เราใช้ Stand up meeting เพื่อสื่อสารเรื่องความคืบหน้าของงานและคนในทีมในปัจจุบัน ใช้ PivotalTracker เพื่อสื่อสารภาพรวมของความคืบหน้าตั้งแต่อดีตจนถึงอนาคต และใช้ mailing list เพื่อสื่อสารแนวคิดความรู้ความเข้าใจเกี่ยวกับงานที่ค่อยๆ วิวัฒนาการตามการทำงานของเราไป สรุป ผมหวังว่าบทความนี้จะช่วยทำให้การพัฒนาซอฟต์แวร์ของทีมขนาดเล็กที่พัฒนาซอฟต์แวร์ขนาดเล็กมีประสิทธิภาพที่ดีขึ้นหลังจากนำเอาข้อเสนอต่างๆ ไปปฏับัติ และหวังว่าจะช่วยกระตุ้นความสนใจเกี่ยวกับการพัฒนาซอฟต์แวร์แบบ Agile ให้กับทุกๆ คนด้วย เทคนิคการพัฒนาซอฟต์แวร์แบบ Agile นั้นยังมีอยู่อีกมาก ที่ไม่ได้กล่าวถึงในบทความนี้ เช่น เทคนิคสร้างบรรยากาศการทำงานให้เหมาะกับการทำงานแบบ Agile, เทคนิคการตามให้ทันเทคโนโลยีที่เปลี่ยนแปลงอย่างรวดเร็ว, วิธีการรับมือการกับการทำจริงกับลูกค้าที่มักเปลี่ยนแปลง requirement หรือการตรวจสอบโปรแกรมแบบ pair programming เป็นต้น เราสามารถคัดเลือกเอาวิธีการต่างๆ เหล่านี้มาประยุกต์ใช้ตามสภาพแวดล้อมที่ต่างกัน (ขนาดทีม ขนาดโปรเจค ลักษณะองค์กร) ได้อย่างเหมาะสมในรูปแบบที่ต่างๆ กันได้ ธัชพล ษรานุรักษ์9 สิงหาคม 2552