แหม… ผมอ่านบทความอันนี้แล้ว สะท้อนความรู้สึกเมื่อสมัยทำ Senior Project จังเลย
" ย้อนกลับไปในอดีต หลักการในการพัฒนาโปรแกรมแบบแรกที่เราใช้แนวคิดแบบวิศวกรรมครับ เรื่องนี้ไม่ใช่เรื่องแปลกเลย เพราะวงการแรกที่ใช้คอมพิวเตอร์ ก็คือนักวิจัย และนักวิทยาศาสตร์นั่นเอง งานที่ใช้ส่วนใหญ่จึงเป็นงานเกี่ยวกับการคำนวณตัวเลข แนวคิดแบบนี้เริ่มตั้งแต่ การหา Requirement การวิเคราะห์ออกแบบ ไปถึงการสร้าง ตามมาด้วยการทดสอบ แล้วค่อยส่งมอบ แนวคิดแบบนี้ ประสบผลสำเร็จเป็นอย่างดี มิฉะนั้นเราคงไม่มีตึกระฟ้าอย่าง World Trade Center….
…
แต่เวลาผ่านมากว่า 30 ปี มีการใช้แนวคิดแบบวิศวกรรมแบบนี้กับโปรแกรมคอมพิวเตอร์ระบบต่างๆ มากมาย ผลลัพธ์ส่วนมากที่เห็นก็คือ ถ้าไม่สำเร็จ ก็ล่าช้า น้อยรายที่ใช้วิธีนี้แล้วทำงานคุณภาพได้ทันเวลา จนคนในวงการคอมพิวเตอร์ ตั้งฉายาวิธีนี้ว่า Waterfall
ถ้าเรามีงานเขียนระบบคอมพิวเตอร์ ตั้งเป้าไว้ว่า ต้องทำให้เสร็จภายใน 1 ปี เท่าที่เคยคุยกับบุคคลต่างๆ ผมได้ตัวเลขเฉลี่ยออกมาว่า การเก็บ Requirement และการวิเคราะห์ออกแบบนั้น ใช้เวลา 1-2 เดือน จากนั้นเริ่มเขียนโปรแกรม ใช้ไปเลย 9 เดือน จากนั้นเวลาที่เหลือเอาไว้ทดสอบและส่งมอบ ถ้าตั้งเวลากันแบบนี้ ผมแทบจะไม่เคยเห็นเลยว่า ใครจะสามารถทำได้ตามแผนดังกล่าว ส่วนพวกที่มีประสบการณ์มากหน่อย จะตั้งตัวเลขการเก็บ Requirement ไม่น้อยกว่าครึ่งหนึ่งของเวลาทั้งหมด แต่สุดท้ายก็เจ็บอยู่ดี แต่ก็ยังดีที่น้อยกว่าพวกแรก
…
ที่เรียกว่า Waterfall เพราะมันจะไหลจากที่สูงสุดคือการเก็บ Requirement ไปจนกระทั่งถึงการส่งมอบซึ่งเป็นที่ต่ำที่สุด ไหลลงไปอย่างนี้ชั่วนาตาปี"
เพราะอะไรก็ไม่รู้ แต่ผมมีความรู้สึกว่า Extreme Programming มันดึงหลักบางส่วนของ RAD (Rapid Application Development) มาใช้ด้วย ส่วนตัวแล้ว ผมก็ใช้ทั้งสองแบบนะ คือทั้ง SDLC และ RAD ก็แล้วแต่สถานการณ์ แต่ตั้งแต่ทำงานมานี่ รู้สึก RAD จะให้ผลดีมากกว่า เพราะผู้ใช้มักจะไม่รู้หรอกว่าจริงๆแล้วตัวเองอยากได้อะไร ดังนั้นเก็บอะไรมาได้ ก็ทำไปก่อน (เขียนแบบมีเผื่อถอยไว้ด้วย กันเหนียวๆ) มัวแต่ไปเก็บ requirement อ่ะ สุดท้าย user (แมร่ง)ก็ขอเปลี่ยนอยู่ดี เจอมาแล้ว ในโปรเจคที่มี team leader ที่เก่งที่สุดในโลกกกกก….
หวังว่าจะมีประโยชน์ และขอให้ทุกท่านมีความสุข
ปล. ผม Quote และทำ Reference แล้วนะ ไม่ถือว่าเป็นการ Plagiarise