ปัญหาสำคัญอันดับที่หนึ่งในการพัฒนาซอฟแวร์ก็คือเรื่องความเสี่ยง การพัฒนาซอฟแวร์นั้นไม่ใช่งานที่ตรงตัวแบบ หนึ่งบวกหนึ่งต้องได้สอง มีความไม่แน่นอนมากมายสุดท้ายก็เกิดเป็นความเสี่ยงที่จะทำให้โปรเจ็คล้มเหลว เราลองมาดูกันว่า XP มองปัญหาเรื่องความเสี่ยงในการพัฒนาซอฟแวร์ไว้อย่างไรบ้าง
ตัวอย่างความเสี่ยงในการพัฒนาซอฟแวร์
- Schedule slips ประมาณว่าถึงกำหนดส่งแล้ว หรือใกล้กำหนดแล้วรู้แน่ๆ ว่า ให้ตายยังไงก็เสร็จไม่ทัน อีกสิบวันจะต้องส่ง แต่อยากได้อีกสองเดือน อย่างนี้ก็ทำอะไรไม่ได้นอกจากขอเลื่อนกำหนดส่ง
- Project canceled หลังจากขอเลื่อนมากหลายรอบ ในที่สุดก็ทนกันไม่ไหว ลูกค้าหรือไม่ก็ stakeholder สั่งยกเลิกโปรเจ็ค ไม่ต้องทำกันแล้วเพราะอาจจะไม่คุ้มหรือตลาดเปลี่ยนทิศไปแล้ว
- System goes sour อันนี้ขอแปลว่า ‘ระบบเน่า’ คือดันกันจนเอาขึ้นโปรดักชั่นได้ แต่พอเวลาผ่านไปจะแก้อะไรทีก็มีแต่คนบ่น โค้ดอ่านไม่รู้เรื่อง แก้ตรงนี้ก็ไปพังตรงโน้น แก้สองบั๊กแต่ที่แก้นั้นทำให้เกิดบั๊กใหม่อีกสาม เพราะ โค้ดแย่เกินกว่าจะเยียวยา หลายครั้งต้องยอมแก้แบบปะผุเพราะไม่งั้นต้องเขียนใหม่ทั้งหมด
- Defect rate หรือไม่งั้นพอดันขึ้นโปรดักชั่นได้ ลูกค้าเริ่มใช้งานจริงก็เจอบั๊กตรงโน้นตรงนี้เต็มไปหมด ต้องตามแก้กันไม่จบไม่สิ้น จนสุดท้ายไม่มีใครยอมใช้งาน
- Business misunderstood หรือไม่ก็พอเอาขึ้นโปรดักชั่นแล้ว ก็ปรากฏว่าเข้าใจ business ของลูกค้าผิด ที่โปรแกรมนั้นทำงานตามที่ลูกค้าต้องการไม่ได้
- Business changes หรือไม่ก็กว่าจะทำเสร็จ เอาขึ้นไปแล้ว ปรากฏว่าลูกค้าบอกว่า “ผมเข้าใจว่านี่คือสิ่งที่ผมบอกให้ทำ แต่นั่นมันหกเดือนที่แล้ว ตอนนี้ระเบียบมันเปลี่ยนไปแล้ว” สรุปว่าก็ใช้งานไม่ได้อยู่ดี
- False feature rich นู่นก็ดีนี่ก็หรู ทำไปทำมาระบบ ดูหวือหวาซับซ้อนเอาการ แต่ลูกค้าใช้งานจริงไม่ได้ เพราะไม่ตรงจุดที่จะสร้างผลกำไรให้ลูกค้าได้ (ดู Office 2007 เป็นตัวอย่าง ว่ามีจุดไหนที่ทำให้ทำงานเสร็จเร็วขึ้นได้บ้าง)
- Staff turnover สุดท้ายแล้วปิดโปรเจ็คได้ แต่คนรุ่นแรกที่ทำมันขึ้นมาออกหมด ปล่อยให้คนรุ่นสองรุ่นสามเข้ามาแก้เป็นมรดกตกทอดกันไป สุดท้ายแล้วก็ไม่มีใครเข้าใจว่า แต่ละส่วนของซอฟแวร์อันนั้นสร้างขึ้นมาทำไม จะแก้ทีก็ปะผุต่อๆ กันไปเรื่อยๆ
ถ้าคุณอ่านเรื่องพวกนี้แล้วหัวเราะก๊ากแต่อยากร้องไห้ในเวลาเดียวกันเหมือนผมแล้วล่ะก็ คุณมาถูกทางแล้ว มาดูกันว่า XP จะแก้ปัญหาเหล่านี้ได้อย่างไร
- Schedule slips XP จะสร้างซอฟแวร์ที่ใช้งานได้จริง (แต่อาจมีฟีเจอร์ที่ยังไม่สมบูรณ์ จะต้องทำ word processor แต่รอบแรกเอาแค่ทำงานได้เท่า notepad ไปก่อน) ทุกๆ สองถึงสามเดือน เรียกว่า Release โดยที่แบ่งเป็นรอบทำงานสั้นๆ เรียกว่า Iteration รอบละหนึ่งถึงสีสัปดาห์ โดยจะจำกัดจำนวนฟีเจอร์ที่จะทำให้ลูกค้าในรอบนั้น และเมื่อจบรอบเราก็ได้เห็นความคืบหน้าของผลงานได้ชัดเจน ซึ่งในรอบงานหนึ่งๆ นั้นเราจะแบ่งฟีเจอร์ออกเป็นงาน(task) ย่อยๆ โดยที่งานหนึ่งๆ จะต้องสามารถทำเสร็จได้ในหนึ่งถึงสามวัน เพราะฉะนั้นถ้ามีปัญหาอะไรเกิดขึ้นทีมก็ยังจะสามารถแก้มันได้ในรอบงานนั้นเลย โดยไม่ต้องคอยจนถึงรอบงานหน้า คือถ้าเราทำเป็นเฟสเล็กๆ อย่างการทำงานแบบ iterative waterfall, testing จะอยู่ตอนท้ายทำให้ ถ้าเราไม่เอาบั๊กไปแก้รอบงานหน้าก็ต้องยืดเวลารอบงานนี้ซึ่งทั้งสองอันก็จะทำให้เกิดการเลื่อนของงานอยู่ดี ก็คืแก้ไขปัญหาเรื่องการ slip ไม่ได้นั่นเอง และสุดท้าย XP นั้นบังคับให้เลือกงานที่จะให้ประโยชน์กับลูกค้ามากที่สุดขึ้นมาทำก่อน เพราะฉะนั้นตอนท้าย ถึงแม้จะล่าช้ากว่ากำหนด ส่วนที่ยังไม่เสร็จก็เป็นส่วนที่สำคัญน้อยกว่า หรือไม่สำคัญสำหรับลูกค้า (ก็คือขอเลื่อนหรือขอตัดง่ายไง)
- Project canceled เนื่องจาก XP เปิดโอกาสให้ลุกค้าเลือก ทำส่วนเล็กที่มีคุณค่ามากก่อน และเอาขึ้นโปรดักชั่นไปกำทำกำไรได้ทันที เมื่อเล็กโอกาสผิดพลาดก็น้อย เมื่อขึ้นไปได้เร็วก็ปิดประตูถูกยกเลิกโปรเจ็คไปได้เลย
- System goes sour XP บังคับให้จำเป็นต้องสร้างชุดเครื่องมือสำหรับทดสอบระบบ (Test suite) ซึ่งสามารถรันทดสอบได้วันละหลายครั้ง ทำให้มั่นใจได้ในเรื่องคุณภาพของโค้ดได้ตลอดเวลา เพราะโค้ดแย่ๆ(Cruft) จะถูกกันไม่ให้เข้าไปฝังตัวจนเจริญเติบโตได้(ยังกะเชื่อโรคแน่ะ)
- Defect rate เนื่องจากชุดทดสอบใน XP สร้างจากทั้งมุมมองของทั้ง User และ Programmer (คือทั้ง business และ technical) โอกาสที่จะเกิดความผิดพลาดตกค้างจนใหญ่เป็นเรื่องใหญ่ตอนขึ้นโปรดักชั่นก็น้อย
- Business misunderstood XP ดึงเอาลูกค้ามาเป็นส่วนหนึ่งของทีมด้วย ข้อกำหนดของระบบ(specifications) จึงถูกกลั่นกรองอยู่ตลอดเวลาที่พัฒนาซอฟแวร์ ทำให้ยิ่งทำงานไปทีมก็มีความเข้าใจในธุรกิจและระบบมากขึ้นอย่าต่อเนื่อง
- Business changes รอบการ Release ใน XP นั้นสั้น โอกาสเกิดความเปลี่ยนแปลงทางธุรกิจก็น้อย หรือถึงแม้มีการเปลี่ยนแปลงจริง ก็ไม่ใหญ่โตนัก และลูกค้ายังสามารถเลือกสลับฟังก์ชันที่ยังไม่ทำหรือยังไม่เสร็จกับฟังก์ชันสำคัญที่เพิ่มเข้ามาใหม่ด้วย
- False feature rich XP เลือกทำเฉพาะฟีเจอร์ที่ให้ผลกำไรมากก่อน เพราะฉะนั้นฟีเจอร์ประเภทหวือหวาแต่ไร้แก่นสารจึงเข้ามาในรอบการทำงานไม่ได้
- Staff turnover XP เปิดโอกาสแกมบังคับให้โปรแกรมเมอร์เป็นคนประมาณการ(estimate) และลงมือทำงานเอง และยังให้ฟีดแบ็กแก่ทีมว่าทำได้ดีแค่ไหน จุดใดที่สามารถปรับปรุงให้ดีขึ้นได้อยู่ตลอดเวลา นอกจากนี้ยังมีกฏว่าใครจะสามารถ estimate หรือ re-estimate ได้อย่างชัดเจนจึงปิดโอกาสที่ทีมจะถูกของให้ทำในสิ่งที่เป็นไปไม่ได้ และ XP ยังเน้นให้สมาชิกทำงานร่วมกัน ซึ่งทำให้งานนั้นสนุก สมาชิกที่เข้ามาใหม่จะได้รับงานที่มีความรับผิดชอบน้อย และค่อยๆ เพิ่มขึ้นเป็นลำดับ และได้รับงานประคับประคองจากเพื่อนร่วมทีมไปจนกว่าจะพร้อม
ทั้งหมดนี้จะเป็นว่าถึงแม้ ‘ความเสี่ยง’ จะเป็นปัญหาหลักในการพัฒนาซอฟแวร์ แต่ด้วย XP เราจะสามารถควบคุมและบริหารความเสี่ยงได้ และนำไปสู่การพัฒนาซอฟแวร์ที่สำเร็จและยั่งยืน
