| description |
|---|
🤔 รู้ป่าว 80% ที่โปรเจคล่มก็เพราะเรื่องนี้แหละ!! และเราเข้าใจมันถูกหรือยัง? (อธิบายเป็นภาษาคน) |
ในบทความนี้เราจะมาดูกันว่า การทำซอฟต์แวร์มันมีขั้นตอนอะไรบ้าง? รวมถึงข้อเสียถ้าเราไม่ทำหรือข้ามขั้นตอนพวกนั้นจะเกิดอะไรขึ้น?
{% hint style="success" %}
แนะนำให้อ่าน
บทความนี้เป็นส่วนหนึ่งของบทความ 👦 Agile Methodology หากเพื่อนๆสนใจอยากศึกษาการทำ Agile แบบเต็มรูปแบบก็สามารถกดลิงค์สีฟ้าๆเพื่อเข้าไปดูได้เลยนะ
{% endhint %}
เวลาที่เราทำซอฟต์แวร์ผมเชื่อว่าหลายๆคนน่าจะเคยเจอปัญหาคล้ายๆกัน เช่นเวลาที่ไปคุยกับลูกค้า เขาก็จะอธิบายว่าอยากได้ชิงช้าแบบไหน สมมุติว่าเป็นแบบรูปด้านล่างนี้ละกัน
ซึ่งแน่นอนตอนที่เราไปฟังมาแต่ละฝ่ายก็จะเข้าใจไม่เหมือนกัน เช่น หัวหน้าทีมก็อาจจะบอกว่าชิงช้า 3 ชั้นแบบนั้นจะเอาไปทำไม? มันต้องเป็นแบบนี้เฟร้ย
ถัดมาทีมออกแบบก็บอกว่า เจ้าบ้าเอ้ยแล้วมันไกวได้ยังไง? มันต้องเป็นแบบนี้ต่างหากล่ะ ถึงจะทำงานได้
ส่วนพอ developer ได้ยินก็บอกพวกตูมีปัญญาเขียนแค่นี้เท่านั้นแหละ เอาแบบนี้เถอะชิงช้าเหมือนกันนะ :)
จากที่ว่ามาทำให้งานที่เอาไปส่งลูกค้าก็เลยเป็นแบบนี้
ซึ่งในความเป็นจริงสิ่งที่ลูกค้าอยากได้อาจจะเป็นแค่นี้ก็ได้
เป็นการ์ตูนล้อเลียนที่สะท้อนปัญหาในการทำซอฟต์แวร์ได้ใกล้เคียงกับความเป็นจริงมาก โดยการ์ตูนตัวเต็มเป็นรูปด้านล่างนี้เลย
จากที่ยกตัวอย่างให้มันมีจุดที่น่าสนใจคือ รูปแรกที่อยู่บนซ้ายสุด คือสิ่งที่ลูกค้าเล่าให้ฟังว่าเขาอยากได้อะไร กับรูปสุดท้ายที่อยู่ล่างขวาสุด คือสิ่งที่ลูกค้าต้องการจริงๆ ซึ่งปัญหาของการทำซอฟต์แวร์ก็คือ สิ่งที่ลูกค้าเล่ากับของที่เขาต้องการจริงๆนั้นอาจจะเป็นคนละเรื่องกันเลยก็ได้ และ ความเข้าใจของแต่ละฝ่ายไม่ได้ตรงกันเสมอไป แม้จะเป็นทีมเดียวกันก็ตาม
จากปัญหาที่เล่ามา เราเลยต้องมารู้จักกับสิ่งที่จะช่วยแก้ปัญหาโลกแตกนี้นั้นก็คือสิ่งที่เรียกว่า Software Development Life Cycle หรือเรียกย่อๆว่า SDLC นั่นเอง
เพื่อที่จะป้องกันปัญหาที่เล่ามา ตอนที่เราทำซอฟต์แวร์เขาเลยมีขั้นตอนให้เราทำทั้งหมด 6 ขั้นตอน ซึ่งทั้งหมดนี่เราเรียกว่า SDLC ยังไงล่ะ ตามรูปด้านล่างเลย
สรุปแบบสั้นๆ: เวลาที่เราจะเขียนโปรแกรมก็ต้องมานั่งวางแผน ทำความเข้าใจตัวระบบ ออกแบบหน้าตาและการทำงานของมัน แล้วก็ค่อยเอาทั้งหมดไปเขียนให้มันทำงานได้ สุดท้ายก็เอาไปทดสอบ และรอดูว่ามีอะไรที่ต้องปรับปรุงหรือทำให้มันดีขึ้นบ้าง วนเวียนกันไปเรื่อยๆจนกว่าคนเขียนหรือคนจ้างจะเลิกแล้วต่อกัน
{% hint style="danger" %}
คำเตือน
SDLC ดูเหมือนมันไม่มีอะไรเลยแต่ คนส่วนใหญ่มักจะลืมทำหรือไม่ยอมทำเพราะคิดว่ามันไม่สำคัญนั่นเอง เลยทำให้มันมีปัญหาตามมาโดยที่เราไม่รู้ตัว เช่น Bug ผุดเป็นดอกเห็ด ยิ่งผ่านไปโปรเจคยิ่งช้าแก้ไขก็ยาก ส่งงานไม่ทัน ทำของที่ลูกค้าไม่อยากได้ และอีกสารพัดที่เราน่าจะเคยได้ยินมา ดังนั้นเลยอยากให้เพื่อนๆลองทำความเข้าใจบทความนี้ดีๆ แล้วลองทบทวนการทำงานของทีมตัวเองดูนะ
{% endhint %}
{% hint style="info" %}
SDLC Phases
ในแต่ละข้อมันมีรายละเอียดของมันเยอะมากอยู่ ผมขี้เกียจไปลงรายละเอียดไม่งั้นมันจะกลายเป็นตำราหนังสือที่ผมไม่ชอบ ดังนั้นไปหาอ่านเอาเองละกัน
{% endhint %}
จากที่ร่ายยาวไป SDLC มันก็ไม่มีอะไรเลยจริงๆนั่นแหละ มันเป็นแค่แนวคิดในการสร้างซอฟต์แวร์ ซึ่งเจ้าแนวคิดนี้ก็ถูกแตกย่อยออกมาเป็นหลายๆแบบ ซึ่งแต่ละแบบก็มีข้อดีข้อเสียและบางตัวก็เป็นบทเรียนว่าห้ามทำด้วยนะ ซึ่งเราเรียกของพวกนี้ว่า SDLC Models นั่นเอง
เย๊อะม๊วกกก เช่น Waterfall, V-Shaped, Prototype, Spiral, Iterative Incremental, Big Bang, Agile แค่เห็นก็ปวดหัวละ ซึ่งแต่ละตัวก็มีรายละเอียดของมันอีกอื้อซ่าเลย ดังนั้นไปหาอ่านเอาเองละกัน แต่เรื่องที่เราควรจะต้องรู้คือ
ตัวแรกที่คนที่เรียนสายคอมจะต้องรู้จักคือการทำซอฟต์แวร์ที่ชื่อว่า Waterfall หรือ แบบน้ำตก นั่นเอง ซึ่งส่วนใหญ่ทุกคนที่เรียนจะจำมันได้ และเอามันไปใช้ในการทำซอฟต์แวร์กัน
{% hint style="danger" %}
เรื่องตลกร้าย
ตัว Waterfall model ถูกพูดเป็นโมเดลตัวแรกในการพัฒนาซอฟต์แวร์ และสิ่งที่เขาพูดไว้คือ อย่าเอามันไปใช้นะเฟร้ยยยยย เพราะมันจะทำให้โปรเจคเราพังในระยะยาวยังไงล่ะ
{% endhint %}
เชื่อไหมเกิน 50% ของบริษัทซอฟต์แวร์นั้นใช้ Waterfall model กันอยู่และแม้แต่บริษัทเปิดใหม่ก็มีแนวโนมจะใช้มันด้วย!! ดังนั้นเรามาดูกันหน่อยว่า waterfall model มันเป็นยังไง ซึ่งก็ตามรูปด้านล่างเลย
สรุปแบบสั้นๆ: เขาก็จะทำเหมือนที่ SDLC แนะนำมาเลยนั่นแหละ (ถ้าลืมให้เลื่อนกลับไปอ่านด้านบน) แต่ในรูปแบบนี้เขาจะทำทุกอย่างให้เสร็จก่อนแล้วค่อยไปขั้นตอนถัดไป เช่น เริ่มต้นก็ไล่มันให้หมดทุกอย่างเลยว่าโปรแกรมจะต้องทำอะไรได้บ้างไล่ไม่ครบไม่ไปต่อ ถ้าครบแล้วถัดไปก็เอาทั้งหมดไปนั่งออกแบบ ออกแบบไม่ครบไม่ไปต่อ ไรงี้ไล่ไปเรื่อยๆ
เพราะมันไม่สอดคล้องกับความเป็นจริงยังไงล่ะ! เราเคยเห็นงานตัวไหนที่ลูกค้าจะไม่ขอแก้ไขเพิ่มเติมบ้างป่าว? ... ไม่มีหรอก ซึ่งถ้ามันต้องแก้นั่นหมายความว่าเราต้องไล่เก็บ requirement ใหม่ ออกแบบใหม่ หรือพูดง่ายๆทำขั้นตอนพวกนั้นใหม่นั่นเอง ... จะบร้าเหรอ! แล้วกว่างานจะได้เริ่มทำนะนู่นปาเข้าไปขั้นตอนที่ 3 (implementation) ซึ่งกว่าจะทำขั้นตอนที่ 1-2 เสร็จใช้เวลากี่เดือน? เราจะตอบลูกค้าว่า งานที่ทำอยู่ 6 เดือนผมกำลังทำความเข้าใจและออกแบบอยู่ครับได้ด้วยเหรอ? และอีกสารพัดปัญหาของมัน ดังนั้นทีมไหนที่กำลังใช้ Waterfall model อยู่จงรีบประชุมเปลี่ยนแผนโดยด่วน
หลังจากที่เห็นแล้วว่า waterfall เลวร้ายแค่ไหน ถัดมาก็จะมีคำถามว่า แล้วเราควรใช้อะไรดี? ดังนั้นก็เป็นทีของพระเอกของเรานั่นคือ Agile model นั่นเอง ซึ่งมันเกิดจากการนำ Iterative model และ Incremental model เข้ามาด้วยกัน ซึ่งมันสอดคล้องกับความเป็นจริงในการทำซอฟต์แวร์มากกว่านั่นเอง ซึ่งลักษณะการทำงานแบบ agile model ก็จะตามรูปด้านล่างเลย
สรุปแบบสั้นๆ: เราจะแบ่งการทำออกเป็นรอบสั้นๆหลายๆรอบเอา โดยในแต่ละรอบจะมีการ feedback เพื่อทำให้ทีมเก่งขึ้น เข้าใจงานมากขึ้น สามารถส่งงานตามความเร่งด่วนของงานได้ตรงกับที่ลูกค้าอยากได้มากขึ้นเรื่อยๆ และทั้งหมดนั่นคุณภาพของโค้ดก็จะดีขึ้นกว่าเดิมด้วย ได้ทั้งงาน ได้ทั้งคน แถมได้ใจลูกค้าด้วย
ในรายละเอียดของ Agile model นั้นเดี๋ยวเราจะไปอธิบายต่อในบทความถัดไปเอานะ
ถ้าเราไปดูหลักในการจัดการซอฟต์แวร์นั้นเราก็จะพบว่ามันมีอีกหลายแบบยั๊วเยี๊ยเต็มไปหมดเลย แต่ผมขอสรุปสั้นๆออกมาเป็นแบบนี้ละกันว่า ไม่ว่าจะเป็นแบบไหนก็ตามมันถูกออกแบบมาจากแนวคิด 2 อย่างคือ
- คุณภาพงานต้องมาก่อน - โดยแนวคิดนี้ถอดแบบมาจากโรงงานอุตสาหกรรม โดยมองว่าซอฟต์แวร์จะมีคุณภาพดีได้ ขั้นตอนในการทำจะต้องเป็นตามลำดับ 1234 เท่านั้น ดังนั้นใครก็ตามที่ทำตามขั้นตอนนี้ ก็น่าจะได้คุณภาพของซอฟต์แวร์ที่ดีนะ ซึ่งเราจะพบได้จาก model ตระกูลที่ใช้ ISO หรือ CMMI นั่นเอง
- ซอฟต์แวร์เป็นของที่ดิ้นได้ - โดยแนวคิดนี้มองว่าซอฟต์แวร์มันเปลี่ยนแปลงได้เรื่อยๆตามสถานการณ์ของมัน ดังนั้นเราต้องค่อยๆทำ ค่อยๆปรับตามความเหมาะสม ซึ่งเราเรียกมันว่า Research and Development หรือ R&D นั่นเอง ซึ่งเราจะพบได้จาก model ตระกูล Agile หรือ Lean นั่นเอง
จากแนวคิดทั้ง 2 แบบนี้ ในมุมมองของผมคือ การทำซอฟต์แวร์นั้นเหมาะกับ R&D มากกว่า เพราะมันต้องทำไปพัฒนาไป โดยแม้แต่ลูกค้าก็ไม่รู้หรอกว่าเขาอยากได้อะไร ดังนั้นไม่ต้องถามเลยว่า User ชอบแบบไหน เราอาจจะต้องลองทำไปก่อน แล้วค่อยเอาผลลัพท์มาวิเคราะห์เพื่อปรับแก้ตามความเหมาะสมต่างหาก
การทำซอฟต์แวร์อ่ะดูเหมือนจะไม่อยากหรอก แต่จริงๆแล้วมันเหมือนกับภูเขาน้ำแข็งแหละที่ดูแลก็ไม่มีอะไร แต่ที่เราไม่เห็นที่ถูกซ่อนไว้ใต้น้ำนั่นแหละคือสิ่งที่เราต้องเตรียมรับมือกับมัน
เพราะเราต้องจัดการกับความต้องการของลูกค้า จัดการกับทีมให้เข้าใจตรงกัน การส่งมอบงาน คุณภาพของโค้ด และอีกหลายเรื่องที่ผมสามารถเขียนได้เรื่อยๆจนคุณขี้เกียจอ่านนั่นแหละคือสิ่งที่การทำซอฟต์แวร์มันยาก เพราะถ้าเราไม่จัดการให้ดี เราจะได้ทำงานให้กับลูกค้าคนนั้นเพียงแค่ครั้งเดียว แล้วก็ต้องไปหาลูกค้ารายอื่นไปเรื่อยๆก็เป็นได้
Software Development Life Cycle (SDLC) มันเป็นแค่ขั้นตอนที่ช่วยเตือนไม่ให้เราหลงทางในการทำซอฟต์แวร์เพียงเท่านั้น สิ่งที่ทำให้โปรเจคส่วนใหญ่ล้มเหลว หรือไม่สามารถส่งมอบงานให้ลูกค้าได้ตามที่สัญญาไว้ เกือบจะ 80% ก็เกิดจากการที่เราละเมิดหรือลืมทำขั้นตอนใดซักขั้นตอนหนึ่งใน SDLC นั่นแหละ โดยต่อให้เราใช้ Agile model แต่ถ้าเราละเมิดขั้นตอนก็อาจจะพังได้เช่นกัน ดังนั้นเราควรจะต้องเรียนรู้ และ นำมันไปใช้จริงๆจนเราทำมันเหมือนเป็นการหายใจไปเลยนั่นเอง