# Software Development Life Cycle

ในบทความนี้เราจะมาดูกันว่า การทำซอฟต์แวร์มันมีขั้นตอนอะไรบ้าง? รวมถึงข้อเสียถ้าเราไม่ทำหรือข้ามขั้นตอนพวกนั้นจะเกิดอะไรขึ้น?

{% hint style="success" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของบทความ [👦 Agile Methodology](https://saladpuk.gitbook.io/learn/basic/agile-methodology) หากเพื่อนๆสนใจอยากศึกษาการทำ Agile แบบเต็มรูปแบบก็สามารถกดลิงค์สีฟ้าๆเพื่อเข้าไปดูได้เลยนะ
{% endhint %}

## 😢 ปัญหา

เวลาที่เราทำซอฟต์แวร์ผมเชื่อว่าหลายๆคนน่าจะเคยเจอปัญหาคล้ายๆกัน เช่นเวลาที่ไปคุยกับลูกค้า เขาก็จะอธิบายว่าอยากได้ชิงช้าแบบไหน สมมุติว่าเป็นแบบรูปด้านล่างนี้ละกัน

![](/files/-M1lfxwkrilVF0unW451)

ซึ่งแน่นอนตอนที่เราไปฟังมาแต่ละฝ่ายก็จะเข้าใจไม่เหมือนกัน เช่น หัวหน้าทีมก็อาจจะบอกว่าชิงช้า 3 ชั้นแบบนั้นจะเอาไปทำไม? มันต้องเป็นแบบนี้เฟร้ย

![](/files/-Lr2pf_PrQl6tHQaBNRj)

ถัดมาทีมออกแบบก็บอกว่า เจ้าบ้าเอ้ยแล้วมันไกวได้ยังไง? มันต้องเป็นแบบนี้ต่างหากล่ะ ถึงจะทำงานได้

![](/files/-LnFU9cl-QGjZBIXQs60)

ส่วนพอ developer ได้ยินก็บอกพวกตูมีปัญญาเขียนแค่นี้เท่านั้นแหละ เอาแบบนี้เถอะชิงช้าเหมือนกันนะ :)

![](/files/-LugnJB3I8Zc1N2lpSC0)

จากที่ว่ามาทำให้งานที่เอาไปส่งลูกค้าก็เลยเป็นแบบนี้

![](/files/-LoQX_Sm88AWreEborZ6)

ซึ่งในความเป็นจริงสิ่งที่ลูกค้าอยากได้อาจจะเป็นแค่นี้ก็ได้

![อะไรก็ได้มาให้ตูนั่งแล้วไกวได้ก็พอใจแล้ว](/files/-LpJ9JklI9OHvO03nIZJ)

เป็นการ์ตูนล้อเลียนที่สะท้อนปัญหาในการทำซอฟต์แวร์ได้ใกล้เคียงกับความเป็นจริงมาก โดยการ์ตูนตัวเต็มเป็นรูปด้านล่างนี้เลย

![https://makerkit.co/blog/how-important-is-customer-feedback](/files/-Lzg7UN1229MGdU0mlnX)

จากที่ยกตัวอย่างให้มันมีจุดที่น่าสนใจคือ รูปแรกที่อยู่บนซ้ายสุด คือสิ่งที่ลูกค้าเล่าให้ฟังว่าเขาอยากได้อะไร กับรูปสุดท้ายที่อยู่ล่างขวาสุด คือสิ่งที่ลูกค้าต้องการจริงๆ ซึ่งปัญหาของการทำซอฟต์แวร์ก็คือ **สิ่งที่ลูกค้าเล่ากับของที่เขาต้องการจริงๆนั้นอาจจะเป็นคนละเรื่องกันเลยก็ได้** และ **ความเข้าใจของแต่ละฝ่ายไม่ได้ตรงกันเสมอไป** แม้จะเป็นทีมเดียวกันก็ตาม

จากปัญหาที่เล่ามา เราเลยต้องมารู้จักกับสิ่งที่จะช่วยแก้ปัญหาโลกแตกนี้นั้นก็คือสิ่งที่เรียกว่า **Software Development Life Cycle** หรือเรียกย่อๆว่า **SDLC** นั่นเอง

## 🔥 Software Development Life Cycle (SDLC)

เพื่อที่จะป้องกันปัญหาที่เล่ามา ตอนที่เราทำซอฟต์แวร์เขาเลยมีขั้นตอนให้เราทำทั้งหมด 6 ขั้นตอน ซึ่งทั้งหมดนี่เราเรียกว่า SDLC ยังไงล่ะ ตามรูปด้านล่างเลย

![](/files/-Lo6_8RBX8xY3c2AUS5G)

**สรุปแบบสั้นๆ:** เวลาที่เราจะเขียนโปรแกรมก็ต้องมานั่งวางแผน ทำความเข้าใจตัวระบบ ออกแบบหน้าตาและการทำงานของมัน แล้วก็ค่อยเอาทั้งหมดไปเขียนให้มันทำงานได้ สุดท้ายก็เอาไปทดสอบ และรอดูว่ามีอะไรที่ต้องปรับปรุงหรือทำให้มันดีขึ้นบ้าง วนเวียนกันไปเรื่อยๆจนกว่าคนเขียนหรือคนจ้างจะเลิกแล้วต่อกัน

{% hint style="danger" %}
**คำเตือน**\
SDLC ดูเหมือนมันไม่มีอะไรเลยแต่ **คนส่วนใหญ่มักจะลืมทำหรือไม่ยอมทำ**เพราะคิดว่ามันไม่สำคัญนั่นเอง **เลยทำให้มันมีปัญหาตามมาโดยที่เราไม่รู้ตัว** เช่น Bug ผุดเป็นดอกเห็ด ยิ่งผ่านไปโปรเจคยิ่งช้าแก้ไขก็ยาก ส่งงานไม่ทัน ทำของที่ลูกค้าไม่อยากได้ และอีกสารพัดที่เราน่าจะเคยได้ยินมา ดังนั้นเลยอยากให้เพื่อนๆลองทำความเข้าใจบทความนี้ดีๆ แล้วลองทบทวนการทำงานของทีมตัวเองดูนะ
{% endhint %}

{% hint style="info" %}
**SDLC Phases**\
ในแต่ละข้อมันมีรายละเอียดของมันเยอะมากอยู่ ผมขี้เกียจไปลงรายละเอียดไม่งั้นมันจะกลายเป็นตำราหนังสือที่ผมไม่ชอบ ดังนั้นไปหาอ่านเอาเองละกัน
{% endhint %}

จากที่ร่ายยาวไป SDLC มันก็ไม่มีอะไรเลยจริงๆนั่นแหละ มันเป็นแค่แนวคิดในการสร้างซอฟต์แวร์ ซึ่งเจ้าแนวคิดนี้ก็ถูกแตกย่อยออกมาเป็นหลายๆแบบ ซึ่งแต่ละแบบก็มีข้อดีข้อเสียและ**บางตัวก็เป็นบทเรียนว่าห้ามทำ**ด้วยนะ ซึ่งเราเรียกของพวกนี้ว่า **SDLC Models** นั่นเอง

## 🤔 SDLC Models มีอะไรบ้าง ?

เย๊อะม๊วกกก เช่น Waterfall, V-Shaped, Prototype, Spiral, Iterative Incremental, Big Bang, Agile แค่เห็นก็ปวดหัวละ ซึ่งแต่ละตัวก็มีรายละเอียดของมันอีกอื้อซ่าเลย ดังนั้นไปหาอ่านเอาเองละกัน แต่**เรื่องที่เราควรจะต้องรู้**คือ

### 💀 Waterfall Model

ตัวแรกที่คนที่เรียนสายคอมจะต้องรู้จักคือการทำซอฟต์แวร์ที่ชื่อว่า **Waterfall** หรือ **แบบน้ำตก** นั่นเอง ซึ่งส่วนใหญ่ทุกคนที่เรียนจะจำมันได้ และเอามันไปใช้ในการทำซอฟต์แวร์กัน

{% hint style="danger" %}
**เรื่องตลกร้าย**\
ตัว Waterfall model ถูกพูดเป็นโมเดลตัวแรกในการพัฒนาซอฟต์แวร์ และสิ่งที่เขาพูดไว้คือ **อย่าเอามันไปใช้นะเฟร้ยยยยย** เพราะมันจะทำให้โปรเจคเราพังในระยะยาวยังไงล่ะ
{% endhint %}

เชื่อไหมเกิน 50% ของบริษัทซอฟต์แวร์นั้นใช้ Waterfall model กันอยู่และแม้แต่บริษัทเปิดใหม่ก็มีแนวโนมจะใช้มันด้วย!! ดังนั้นเรามาดูกันหน่อยว่า waterfall model มันเป็นยังไง ซึ่งก็ตามรูปด้านล่างเลย

![](/files/-LpJzGOTFjK7xuTXuUe5)

**สรุปแบบสั้นๆ:** เขาก็จะทำเหมือนที่ SDLC แนะนำมาเลยนั่นแหละ (ถ้าลืมให้เลื่อนกลับไปอ่านด้านบน) แต่ในรูปแบบนี้เขาจะทำทุกอย่างให้เสร็จก่อนแล้วค่อยไปขั้นตอนถัดไป เช่น เริ่มต้นก็ไล่มันให้หมดทุกอย่างเลยว่าโปรแกรมจะต้องทำอะไรได้บ้างไล่ไม่ครบไม่ไปต่อ ถ้าครบแล้วถัดไปก็เอาทั้งหมดไปนั่งออกแบบ ออกแบบไม่ครบไม่ไปต่อ ไรงี้ไล่ไปเรื่อยๆ

#### 🤔 แล้วมันไม่ดียังไง ?

เพราะมันไม่สอดคล้องกับความเป็นจริงยังไงล่ะ! เราเคยเห็นงานตัวไหนที่ลูกค้าจะไม่ขอแก้ไขเพิ่มเติมบ้างป่าว? ... ไม่มีหรอก ซึ่งถ้ามันต้องแก้นั่นหมายความว่าเราต้องไล่เก็บ requirement ใหม่ ออกแบบใหม่ หรือพูดง่ายๆทำขั้นตอนพวกนั้นใหม่นั่นเอง ... จะบร้าเหรอ! แล้วกว่างานจะได้เริ่มทำนะนู่นปาเข้าไปขั้นตอนที่ 3 (implementation) ซึ่งกว่าจะทำขั้นตอนที่ 1-2 เสร็จใช้เวลากี่เดือน? เราจะตอบลูกค้าว่า งานที่ทำอยู่ 6 เดือนผมกำลังทำความเข้าใจและออกแบบอยู่ครับได้ด้วยเหรอ? และอีกสารพัดปัญหาของมัน ดังนั้นทีมไหนที่กำลังใช้ Waterfall model อยู่จงรีบประชุมเปลี่ยนแผนโดยด่วน

### ❤️ Agile Model

หลังจากที่เห็นแล้วว่า waterfall เลวร้ายแค่ไหน ถัดมาก็จะมีคำถามว่า แล้วเราควรใช้อะไรดี? ดังนั้นก็เป็นทีของพระเอกของเรานั่นคือ **Agile model** นั่นเอง ซึ่งมันเกิดจากการนำ **Iterative model** และ **Incremental model** เข้ามาด้วยกัน ซึ่งมันสอดคล้องกับความเป็นจริงในการทำซอฟต์แวร์มากกว่านั่นเอง ซึ่งลักษณะการทำงานแบบ agile model ก็จะตามรูปด้านล่างเลย

![](/files/-LpkYNeLhI-gjRWPTOgN)

**สรุปแบบสั้นๆ:** เราจะแบ่งการทำออกเป็นรอบสั้นๆหลายๆรอบเอา โดยในแต่ละรอบจะมีการ feedback เพื่อทำให้ทีมเก่งขึ้น เข้าใจงานมากขึ้น สามารถส่งงานตามความเร่งด่วนของงานได้ตรงกับที่ลูกค้าอยากได้มากขึ้นเรื่อยๆ และทั้งหมดนั่นคุณภาพของโค้ดก็จะดีขึ้นกว่าเดิมด้วย ได้ทั้งงาน ได้ทั้งคน แถมได้ใจลูกค้าด้วย

ในรายละเอียดของ Agile model นั้นเดี๋ยวเราจะไปอธิบายต่อในบทความถัดไปเอานะ

## 🤔 Agile ดีที่สุดแล้วเหรอ ?

ถ้าเราไปดูหลักในการจัดการซอฟต์แวร์นั้นเราก็จะพบว่ามันมีอีกหลายแบบยั๊วเยี๊ยเต็มไปหมดเลย แต่ผมขอสรุปสั้นๆออกมาเป็นแบบนี้ละกันว่า ไม่ว่าจะเป็นแบบไหนก็ตามมันถูกออกแบบมาจากแนวคิด 2 อย่างคือ

* **คุณภาพงานต้องมาก่อน** - โดยแนวคิดนี้ถอดแบบมาจากโรงงานอุตสาหกรรม โดยมองว่าซอฟต์แวร์จะมีคุณภาพดีได้ **ขั้นตอนในการทำจะต้องเป็นตามลำดับ** 1234 เท่านั้น ดังนั้นใครก็ตามที่ทำตามขั้นตอนนี้ ก็น่าจะได้คุณภาพของซอฟต์แวร์ที่ดีนะ ซึ่งเราจะพบได้จาก model ตระกูลที่ใช้ **ISO** หรือ **CMMI** นั่นเอง
* **ซอฟต์แวร์เป็นของที่ดิ้นได้** - โดยแนวคิดนี้มองว่าซอฟต์แวร์มันเปลี่ยนแปลงได้เรื่อยๆตามสถานการณ์ของมัน ดังนั้นเราต้องค่อยๆทำ ค่อยๆปรับตามความเหมาะสม ซึ่งเราเรียกมันว่า **Research and Development** หรือ **R\&D** นั่นเอง ซึ่งเราจะพบได้จาก model ตระกูล **Agile** หรือ **Lean** นั่นเอง

จากแนวคิดทั้ง 2 แบบนี้ ในมุมมองของผมคือ **การทำซอฟต์แวร์นั้นเหมาะกับ R\&D** มากกว่า เพราะมันต้องทำไปพัฒนาไป โดยแม้แต่ลูกค้าก็ไม่รู้หรอกว่าเขาอยากได้อะไร ดังนั้นไม่ต้องถามเลยว่า User ชอบแบบไหน เราอาจจะต้องลองทำไปก่อน แล้วค่อยเอาผลลัพท์มาวิเคราะห์เพื่อปรับแก้ตามความเหมาะสมต่างหาก

## 🤔 ทำซอฟต์แวร์มันยากตรงไหน ?

การทำซอฟต์แวร์อ่ะดูเหมือนจะไม่อยากหรอก แต่จริงๆแล้วมันเหมือนกับภูเขาน้ำแข็งแหละที่ดูแลก็ไม่มีอะไร แต่ที่เราไม่เห็นที่ถูกซ่อนไว้ใต้น้ำนั่นแหละคือสิ่งที่เราต้องเตรียมรับมือกับมัน

![https://pastorkylehuber.com/?p=15935](/files/-LugliP7F6ZP8EvSder6)

เพราะเราต้องจัดการกับความต้องการของลูกค้า จัดการกับทีมให้เข้าใจตรงกัน การส่งมอบงาน คุณภาพของโค้ด และอีกหลายเรื่องที่ผมสามารถเขียนได้เรื่อยๆจนคุณขี้เกียจอ่านนั่นแหละคือสิ่งที่การทำซอฟต์แวร์มันยาก เพราะถ้าเราไม่จัดการให้ดี **เราจะได้ทำงานให้กับลูกค้าคนนั้นเพียงแค่ครั้งเดียว** แล้วก็ต้องไปหาลูกค้ารายอื่นไปเรื่อยๆก็เป็นได้

## 🎯 บทสรุป

Software Development Life Cycle (SDLC) มัน**เป็นแค่ขั้นตอนที่ช่วยเตือนไม่ให้เราหลงทางในการทำซอฟต์แวร์เพียงเท่านั้น** สิ่งที่ทำให้โปรเจคส่วนใหญ่ล้มเหลว หรือไม่สามารถส่งมอบงานให้ลูกค้าได้ตามที่สัญญาไว้ เกือบจะ 80% ก็เกิดจากการที่เราละเมิดหรือลืมทำขั้นตอนใดซักขั้นตอนหนึ่งใน SDLC นั่นแหละ โดยต่อให้เราใช้ Agile model แต่ถ้าเราละเมิดขั้นตอนก็อาจจะพังได้เช่นกัน ดังนั้น**เราควรจะต้องเรียนรู้ และ นำมันไปใช้จริงๆจนเราทำมันเหมือนเป็นการหายใจไปเลย**นั่นเอง


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.saladpuk.com/basic/agile-methodology/sdlc.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.