5 ปัญหาหลักของกระบวนการพัฒนาซอฟต์แวร์
5 ปัญหาหลักในการพัฒนาซอฟต์แวร์ หรือจะว่าเป็น 5 ปัญหาคลาสสิกเลยก็ว่าได้ครับ ถึงผมเองจะไม่เคยได้พัฒนาซอฟต์แวร์อย่างเต็มรูปแบบก็ตาม แต่ในช่วงเรียนปี 3 ก็พอมีอยู่บ้างเป็นโปรเจคใหญ่ที่ต้องนำมาพัฒนามีกระบวนการการทำงานต่างๆ เหมือนกับว่าเราทำงานจริงๆเลย และ อาจารย์ก็มักจะตรวจสอบความคืบหน้าของโปรเจคเราอยู่ทุกๆสัปดาห์เลย เพื่อให้อาจารย์มองเห็นปัญหาต่างๆ ในการทำงานของเรา ...และในช่วงสอบ Final เทอมหนึ่งของปีที่ 3 ก็ได้มีข้อสอบของรายวิชานึงวิชานี้จะเป็นจะมีการเรียนการสอนที่คล้ายกับ Team Software Process (TSP) ข้อสอบรายวิชานี้จะเป็นปัญหาต่างๆของเราในการพัฒนาโปรเจค ซึ่งก็คือปัญหาหลักๆ หรือปัญหาคลาสสิกของนักพัฒนาซอฟต์แวร์นั่นเอง..
มาดูปัญหาที่เกิดขึ้นกันครับ
1.) ความต้องการ (Requirement) จากผู้ใช้ (User) ที่ไม่ชัดเจน คลุมเคลือ (Unclear) ขาดความสมบูรณ์ (Incomplete) เรียบง่ายจนเกินไป จนไม่สามารถวิเคราะห์ได้ว่าต้องการอะไร (Too General) และอื่นๆ อาจมีต้นเหตุมาจากความต้องการ (Requirement) อีกมาก
>>การจากเรียนกระบวนการพัฒนาซอฟต์แวร์ในรายวิชาต่างๆ จะเห็นว่าสิ่งสำคัญที่สุดในการพัฒนาซอฟต์แวร์ให้สำเร็จโดยเกิดปัญหาน้อยที่สุด ก็คือ Requirement เป็นมันคือจุดเริ่มต้นของซอฟต์แวร์ใดๆ บนโลกนี้เลยก็ว่าได้ครับ Requirement ที่ว่าไว้ดังกล่าวจะส่งผลทำให้เกิดเป็น Defects หรือ Bugs จำนวนมากมาย ซึ่งส่งผลต่อ Project Plan ทันที เนื่องจากจะต้องเสียเวลาในการมานั่งถกเถียง หรือสรุป ถึงสาเหตุ หรือหาข้อสรุป เพื่อปิด Defects หรือ Bugs เหล่านั้นว่าอันไหนที่จะไม่แก้ เนื่องจาก Requirement ไม่บอก หรือไม่ชัดเจน หรือถ้าอันไหนจะแก้ไข ก็ต้องไปเก็บข้อมูลมาเพิ่มเนื่องจาก Requirement ไม่ชัดเจนอีกเช่นกัน
จากสถิติคราวๆ ของ Defects Originate in Project Phase
56% เกิดจาก Requirement
27% เกิดจาก Design
10% เกิดจาก Coding
7% เกิดจาก Other
จะเห็นได้ว่า Requirement เป็นส่วนสำคัญที่สุดที่สุดในการพัฒนาซอฟต์แวร์เลยก็ว่าได้ หากเรามีการเก็บ Requirement ที่ดี ติดต่อสื่อสารงานกับ User เป็นประจำ ก็จะทำให้ซอฟต์แวร์ที่เราพัฒนามีความถูกต้องสมบูรณ์ และเป็นที่ยอมรับของทั้ง 2 ฝ่าย ครับ..
2.) แผนงานโครงการไม่ดี มีลัษกณะเป็นแผนงานที่เพ้อฝัน (Unrealistic Schedule) การวางแผนไม่ได้ตั้งอยู่บนข้อมูลที่แท้จริง ทำแบบเพ้อฝันไม่คิด ขาดข้อมูลที่ได้จากการปรึกษาหารือสมาชิกในทีม ไม่ว่าจะเกิดจากสาเหตุใดๆ ก็ตาม ขาดการประสานงานย่อยที่สำคัญกับผู้ใช้หรือลูกค้า การจัดทำแผนอาศัพเพียงความรู้ความเข้าใจของตนเองเป็นหลัก
>>ยกตัวอย่างของการวางแผนที่มีลักษณะเพ้อฝัน....ในหนึ่งโปรเจค ก็จะมี Project Manager หรือ Planning Manager เป็นผู้ดูแล ควบคุมเรื่องของการจัดทำแผน หากผู้จัดทำแผนดังกล่าว ทำแผนงานเสนอไปยังลูกค้า โดยมิได้ปรึกษาในส่วนของแผนงานย่อยๆในแต่ละส่วน ที่อยู่ใน Project โดยอาศัยเพียงความเข้าใจของตัวเองเป็นหลัก รับรองได้ว่า เหนื่อยแน่แน่ !! เพราะการจะวางแผนการทำงาน หรือกำหนดการส่งโปรเจคได้นั้น จะต้องมีการปรึกษากับสามาชิกภายในทีมเพื่อประเมินระยะเวลา การเขียนโค้ด หรือ ส่วนอื่นๆก่อน จึงจะสามารถสรุปผล และส่งมอบรายละเอียดให้แก่ลูกค้าได้..
(จากประสบการในการเขียนโค้ดส่งงานอาจารย์ที่ผ่านมา แค่การ Coding ก็ใช้เวลาถึงวันกำหนดส่งแล้วครับ 55555555)
3.) การทำสอบซอฟต์แวร์ไม่เพียงพอ (Inadequate Testing) มักจะพบปัญหาในลักษณะที่ว่าซอฟต์แวร์นี้ผ่านการทดสอบมาได้อย่างไร ปัญหามากมาย ไม่มีคุณภาพทั้งในระดับระหว่างการทำงานร่วมกันในทีม หรือหลังส่งมอบให้ลูกค้าแล้ว หรือมีการทดสอบซอฟต์แวร์ที่ขาดความรอบคอบเวลาในการทดสอบไม่เพียงพอ และอื่นๆ อีกมาก
>> บ่อยครั้งที่จะได้ยินคำบ่น "Test มายังไงเนี่ย Software มีปัญหาเยอะแยะเลย" หรือไม่ก็ "โห ตอน Test ไม่เจอเลยหรือ Bug พวกนี้" หรือไม่ก็ "ผ่าน Test มาได่้ไง ไม่มีคุณภาพเลย" เป็นต้น เหล่านี้เป็นภาพสะท้อน หลังจากส่งมอบงานให้่ลูกค้าบ้าง หรือบางทีก็คนในทีมพัฒนา Software เองก็ตาม
คุณภาพของงาน หรือสินค้าใดๆ ใช่ว่าใช้เวลาเพียงไม่นานจะสร้าง หรือผลิตให้ออกมามีคุณภาพได้ เช่นเดียวกันงานทางด้าน Software Testing นั้น เป็นงานที่ต้่องใช้เวลา และความละเอียดรอบคอบในการทำงานต้องยอมรับกันเลยว่าเวลาที่ให้มาในส่วนของ Software Testing นั้น น้อยจริงๆ หรือบางครั้งได้มาเยอะ แต่ก็จะถูกเบียดบังเวลาจากงานก่อนหน้านั้น ที่ไม่เสร็จแล้วมาแอบกินเวลาของ Software Testing ไป จนหดสั้น เหลือนิดเดียว ฉะนั้นอย่าได้หวังว่า Defects หรือ Bugs จะน้อยครับ
หากลูกค้าบ่น หรือติ มาเรื่องของคุณภาพ หรือความไม่สมบูรณ์ของ Software เมื่อท่านๆ เหล่้านั้น พบว่า Software มีปัญหา หรือล่มไประหว่างใช้งาน ก็ต้องยิ้ม และก้มหน้าแก้ไขไปครับ
4.) มีการเปลี่ยนแปลงไม่จบสิ้น (Always Change) ในระหว่างที่พัฒนาซอฟต์แวร์ มักจะขอให้มีการเปลี่ยนแปลง Features หรือ Functions ไม่ว่าจะเพิ่มขึ้นหรือตัดออก มั้กจะสร้างปัญหาให้กับทีมพัฒนาบ่อยครั้งที่กระทบกระเทือนถึง Solution Design ทำให้ต้องทำงานเพิ่มหรือทำงานใหม่เกือบทั้งหมด หรือในบางครั้งถึงกับต้องออกแบบใหม่ก็มี
>> หลังจากที่ Developer เริ่มพัฒนา Software ไป ในระหว่างก็มีการขอเปลี่ยนแปลง Features หรือ Functions ไม่ว่าจะเพิ่มขึ้นมา หรือตัดออกไป ไม่ว่าจะด้วยเหตุผลใดๆ ก็ตาม ใช่ว่าจะสร้างความปวดหัว, ขุ่นเคือง หรือไม่ปลื้ม ให้กับเหล่า Developer เท่านั้น ทางทีม Software Tester ก็ได้รับผลกระทบด้วยเช่นกัน
เมื่อมีการปรับเพิ่ม หรือลด Features หรือ Functions เกิดขึ้น สิ่งที่ตามมาก็คือการต้องปรับในส่วนของ Solution Design ที่ได้ถูกออกแบบมาแล้ว โชคดีไปหากการปรับเปลี่ยน Features หรือ Functions เหล่านั้น ไม่กระทบกับ Solution Design มากเท่าไร แต่หากว่าการปรับเปลี่ยนมีผลทำให้ต้องรื้อ Solution Design ใหม่ทั้งหมด ดีไม่ดี ต้องออกแบบกันใหม่
ทางทีม Software Testing เองก็ต้องออกแบบการ Testing รวมทั้งต้องเตรียมงานต่างๆ เพื่อใช้ในการ Testing ไม่ว่าจะเป็น Test Cases, Test Data และ Test Environment ต่างๆ ซึ่งการปรับเพิ่ม หรือลด Features หรือ Functions เองก็มีผลกับทางทีม Software Testing ด้วยเช่นกัน
5.) การขาดการติดต่อสื่อสารที่ดี (Miscommunication) ปัญหาหลายอย่างเกิดขึ้นจากการไม่เข้าใจกันและมีการติดต่อสื่สารกันอย่างผิดๆ หรือไม่มีการติดต่อสื่อสารกันเลย ปัญหาเช่นว่านี้เกิดขึั้นได้ในทุกๆระดับ ทั้งระหว่างทีมพัฒนาซอฟต์แวร์ด้วยกันเอง หรือปัญหาที่ไปเกิดกับผู้ใช้
>>ปัญหามักจะเกิดขึ้นเสมอหากเราต้องทำงานร่วมกันเป็นทีม(ประสบการณ์ที่พบเจอมา) ซึ่งเป็นอีกหนึ่งเรื่องคลาสสิกก็คือ ไม่ค่อยจะคุยกัน หรือไม่ก็เข้าใจกันไปคน ละทิศ ละทาง Developer เองก็ไม่เข้าใจ หรือไม่รู้ว่าลูกค้าต้องการอะไร หรือไม่ Developer ก็พบว่าลูกค้าเข้าใจในบางเรื่องไม่ถูกต้อง ก็ไม่ชี้แจ้ง หรืออธิบาย เป็นต้น เหล่านี้ก็เลยเป็นที่มาของปัญหาในระหว่างการพัฒนา Software และก็ตามมาด้วย Defects หรือ Bugs ที่เกิดขึ้นเนื่องพัฒนา Software ออกมาไม่ตรงตาม Requirement หรือ System Design ที่ออกแบบไว้ก็ตาม
แต่ก็เช่นกันใช่ว่าจะเกิดปัญหาเรื่อวนี้เฉพาะ Developer กับลูกค้าเท่านั้น Software Tester กับ Developer เองก็เช่นกัน ไม่เข้าใจก็ไม่คุยกัน มีปัญหา หรือข้อสงสัยต่างๆ ก็ไม่คุยกัน ดังนั้นก็ก่อให้เกิด Defects หรือ Bugs ที่ไม่น่าจะแจ้งไปทาง Developer เองก็มี
ฉะนั้นหันหน้ามาคุยกัน หรือคุยกัน เมื่อพอปัญหา หรือมีข้อสงสัยใดๆ ในทีมพัฒนา Software เพื่อหาวิธีแก้ไขปัญหานั้นอย่างเร่งด่วน "อย่าลืมนัดกันมาแล้วแก้ปัญหากันจริงๆ นะค้าบบบ"
เนื้อหาทั้งหมด เป็นบทความที่ผมเขียนขึ้นหลังจากเข้าสอบในรายวิชาหนึ่งเกี่ยวกับกระบวนการพัฒนาซอฟต์แวร์ภายในทีม ซึ่งข้อสอบจะเป็นการบอกถึงปัญหาต่างๆที่เกิดขึ้น แล้วให้พวกเรายกตัวอย่างหรือหาแนวทางในการแก้ปัญหา ซึ่งผมก็ได้เขียนบทความขึ้น ทั้งจากประสบการณ์อันน้อยนิด แล้วก็การศึกษาข้อมูลจากอินเตอร์เน็ต จากผู้ที่เคยพบเจอปัญหาต่างๆนี้โดยตรง มาเพื่อใช้เขียนบทความนี้ขึ้น ผิดพลาดประการใดขออภัย ด้วยครับ ^__^
ขอบคุณข้อมูลจาก : อาจารย์ผู้ดูแลโปรเจคที่ชี้ให้เห็นพื็นฐานของปัญหาในการทำงาน และ ข้อมูลจากเพิ่มเติมจาก http://www.welovebug.com ที่แสดงให้เห็นถึงปัญหาจริงๆ