XP101 : 1 – Risk – The Basic Problem

ปัญหาสำคัญอันดับที่หนึ่งในการพัฒนาซอฟแวร์ก็คือเรื่องความเสี่ยง การพัฒนาซอฟแวร์นั้นไม่ใช่งานที่ตรงตัวแบบ หนึ่งบวกหนึ่งต้องได้สอง มีความไม่แน่นอนมากมายสุดท้ายก็เกิดเป็นความเสี่ยงที่จะทำให้โปรเจ็คล้มเหลว เราลองมาดูกันว่า 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 เราจะสามารถควบคุมและบริหารความเสี่ยงได้ และนำไปสู่การพัฒนาซอฟแวร์ที่สำเร็จและยั่งยืน

Links
http://en.wikipedia.org/wiki/Cruft

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s