ปีที่ผ่านมา (ปี 2009) ผมใช้ส่วนใหญ่ไปกับการทำความเข้าใจเรื่อง Agile Software Development เพราะเป็น topic ที่ผมเขียน paper ในบริษัทที่ผมทำงาน เมื่อทำ paper จนจบผมก็รู้สึกว่า Agile นั้น มันไม่ได้ซับซ้อนเหมือนอย่าง process อื่นๆ ที่ต้องทำอะไรให้มากมาย แต่มันเข้าท่าดี ยิ่งโดยเฉพาะคนที่โตมากับสาย programming อย่างผมแล้ว ยิ่งรู้สึกว่า Agile นี่แหละเป็นแนวทางที่ใช่เลย ธรรมชาติและเรียบง่ายสุดๆ ใครสนใจก็ลองอ่านดูครับ ผมจะพยายามเล่าโดยใช้ภาษาชาวบ้านที่สุดครับ

นี่เป็นตอนแรกของ series agile ตอนแรกกะจะเขียนให้จบเลย แต่ไม่ไหวแฮะ แค่บ่นก็ยาวเหยียดแล้ว เอาเป็นว่าทยอยเขียนดีกว่า แบบ agile ไง ส่งมอบงานแบบ iteration จะได้มีบทความให้อ่านเรื่อยๆ ไง … (อิอิ ฟังดูดีเชียว) หรือถ้าไม่มีคนอ่านก็ไม่เขียนต่อเพราะไม่ตรงกับความต้องการ (อันนี้เป็นข้ออ้างเพราะขี้เกียจ 555)

บทความนี้เคยเอามาลงใน web เก่าก่อนโดน virus ไป ยังไงจะทยอย up ขึ้นให้นะครับ และจะพยายามไม่ขี้เกียจเขียนก็แล้วกัน ^^

ปัญหาของการพัฒนาซอฟท์แวร์ในสมัยก่อน (… เอ๊ะ หรือว่าตอนนี้ก็ยังใช่อยู่เลย ^_^)

ผมว่าคนที่ทำงานด้านการเขียนโปรแกรมเนี่ยะ จะต้องเคยบ่นหรือรู้สึกว่า “เฮ้ย ทำไมเราทำงานกันมันมั่วยังงี้ฟะ” หรือ “ก็รู้ว่าเอกสารน่ะสำคัญ แต่แค่เขียนโปรแกรมก็ไม่ทันแล้ว” หรือ “ลูกค้าถามว่าโปรแกรมนี้เมื่อไหร่จะเสร็จ … อืมม 3 เดือนมั้งครับ (เอาเข้าจริง 2 ปีแล้ว)” หรือ “ทำไมไม่ว่าจะทำไปกี่งาน มันก็ต้อง late ซะทุกงานเลย” และอีกมากมาย เฮ้อ … เจอกับตัวเองมาแล้วทั้งนั้น 555

หรือเป็นเพราะว่าเราทำงานกันแบบไม่มี process?

คุณคิดว่าอะไรคือ process ครับ? ถ้าเว่ากันซื่อๆ เลย ก็ขั้นตอนในการทำงานไง … ถ้าเป็น software development process ก็ขั้นตอนในการพัฒนาซอฟท์แวร์ไง (กำปั้นทุบดินมากกกก) ครับ พูดอีกก็ถูกอีก … ย้อนถามตัวเราเอง … ทุกวันนี้เราพัฒนาซอฟท์แวร์แบบมี process ไหม?

จะว่ามีก็มีนะ ก็เก็บ requirement ก่อน ดูว่าลูกค้าจะเอาอะไร ประเมินว่าทำนานแค่ไหน ราคาเท่าไหร่ พอลูกค้าตกลงว่าจะจ้างทำก็มัดจำก่อน 30-40% เราก็มาเริ่ม design database ทำหน้าจอ เขียนโปรแกรม แล้วก็เอาไปให้ลูกค้าดู (ไม่มี test แน่นอน อย่ามาบอกว่ามีการ test ครับ ผมไม่เชื่อ เพราะผมก็ไม่ test 555) ลูกค้าดูว่า function ครบก็จ่ายมาให้เหลือซัก 20% จากนั้นก็ให้ลองใช้อีกระยะ พอคิดว่าใช้งานได้แล้วก็เก็บเงินที่เหลือ ปิดงานไป

ผมคิดว่า งานแบบ project based ส่วนใหญ่ก็ประมาณนี้แหละ ใช่ไหมครับ อาจจะมีดีหน่อยก็ทำเอกสารให้ชัดเจนไม่งั้นก็ไม่ทำ หรือทำหน้าจอให้ดูก่อน ลูกค้า ok แล้วค่อยทำ แต่สิ่งที่เป็นสัจจะธรรมเลยคืออะไรรู้ไหมครับ … ผมบอกได้เลยว่าส่วนใหญ่งานจะ late ทำไมครับ … ลองมาลำดับขั้นตอนกันดูดีกว่า …

Requirement -> Design -> Develop -> Test -> Deploy -> Maintenance

อันนี้คืองาน process ทั่วๆ ไปที่ทุกวันนี้ใช้กันอยู่อย่างแพร่หลาย ปัญหาที่ตามมามีมากมายเลย เช่น ถ้า requirement มันไม่ชัดเจน งานก็จะบานปลาย ต้องแก้เยอะ … หรือในขั้นตอนการ test ลองดูดีๆ ซิ … “develop” แล้ว “test” แล้ว “deploy” … อืมมม … แล้วแก้ bug ตอนไหนอะ ไม่ได้เผื่อเวลาแก้ bug … ทำไงดี … deploy เลยไง ให้ลูกค้า test เจอ bug แล้วค่อยแก้กันไป ก็มี M/A นี่ 5555…

ถ้านี่เป็นงานเหตุการณ์จริงลูกค้าคงไม่ขำกับเราแน่ ลองคิดกลับกันดูว่า ถ้าคุณซื้อบ้านหรือรถแล้วเจอแบบนี้ คุณชอบไหมครับ “พี่… อยู่ไปก่อน ถ้าหลังคารั่ว ท่อตัน หรือบ้านทรุด เดี๋ยวผมมาซ่อมให้” เอาไหมครับ … แน่นอนไม่มีใครเอาด้วย แล้วทำไมทีเราพัฒนาซอฟท์แวร์ เราทำแบบนั้นละ …

ที่แย่ไปกว่านั้นคือ บางบริษัทอาจจะไม่ได้สนใจเรื่องพวกนี้เลย ลูกค้าบอกว่า อยากได้ software ประมาณนี้ (requirement ประมาณ 1 แผ่นกระดาษ A4) เราก็บอกไปเลย … ราคา 2 แสน ซัก 3 เดือนน่าจะเสร็จ แต่เอาเข้าจริงปาเข้าไป 6 เดือน แล้วได้ซอฟท์แวร์อะไรมาก็ไม่รู้ ไม่ตรงกับที่ลูกค้าวาดภาพไว้เลย แบบนี้เรียกว่า Big Bang Approach คือรู้แต่ว่าไปพัฒนาระบบแหละ แต่ทำอะไรไม่รู้ แต่ได้ผลลัพธ์ออกมาก็แล้วกัน (ผิดหรือถูกค่อยว่ากัน)

เพื่อนผมเคยเล่าเรื่อง joke ฝรั่งให้ฟังว่า มีอยู่ 3 เรื่องที่คุณอย่าไปรู้เลยว่ามันมีขั้นตอนการผลิตยังไง คือ ซอส (รู้แล้วจะกินไม่ลง), กฏหมาย (เบื้องหลังมีแต่ผลประโยชน์) และ ซอฟท์แวร์ (อันนี้ก็รู้ๆ กันอยู่ … ทำงานกันโคตรมั่วเลย)

นี่แค่ตัวอย่างเดียวนะ ยังมีอีกมากมายเลยที่เป็นปัญหา เพราะฉะนั้นเราคงต้องรู้อะไรมากกว่าเพียงแค่เข้าใจว่า process มีแค่นั้นก็เป็น process แล้ว นั่นคือที่มาของคำว่า Methodology ครับ

Methodology

ถ้าคุณอยากรู้ความหมายเป็นทางการก็ลองไปค้นดูใน Wikipedia ดู แต่เอาเข้าจริงๆ แบบลูกทุ่ง ความหมายของคำๆ นี้สำหรับการพัฒนาซอฟท์แวร์ มันก็คือ process นั่นแหละครับ แต่เป็น process ที่อธิบายลงในรายละเอียดมากขึ้น ซึ่งในแต่ละ methodology จะมีเอกลักษณ์ของตัวมันเอง เช่น Waterfall ที่เป็นพื้นฐานของทุกๆ methodology ก็มีขั้นตอนอย่างที่ว่ามา เพราะมันง่ายและชัดเจน คุณอาจจะเคยได้ยินคำว่า Spiral (สไปรอล) หรือ Incremental (อินครีเม็นทอล) ซึ่งมีจุดเด่นในแง่ของการทำทีละน้อยๆ เสร็จส่วนหนึ่งก็ทำต่อไป เป็นต้น Agile เองก็ประมาณนั้นนั่นแหละครับ

Agile ไม่ work หรอก …

ก่อนที่จะลงไปดูรายละเอียดของ Agile ผมจะบอกว่ามีคนเข้าใจผิดเกี่ยวกับ agile เยอะมาก เมื่อคุณอ่านจบแล้วลองกลับมาอ่านหัวข้อนี้อีกที คุณจะเห็นว่าใครที่เข้าใจไปในแนวนี้แสดงว่าเค้าไม่เข้าใจ agile เลย ลองดูว่าคนที่ไม่เข้าใจเค้าว่ากันยังไง

• เข้าใจว่า Agile ไม่มี process … ถ้าแค่ “Agile” ละก็ ใช่ครับมันไม่มี process เพราะคุณต้องศึกษา “methodology ในกลุ่ม Agile” ด้วย (เดี๋ยวอ่านไปก็เข้าใจเองครับว่ามันเป็นยังไง)
• เข้าใจว่า Agile ไม่ต้องมีเอกสาร ที่จริงก็ต้องมีครับเพราะไม่มีใครจำทุกอย่างได้หรอก แต่มันไม่ต้องบ้าทำมากมายน่ะ
• เข้าใจว่า Agile ไม่ต้องออกแบบทั้งหมด ออกแบบเฉพาะที่กำลังจะทำ เดี๋ยวค่อยไปแก้เอาข้างหน้า … ก็ไม่จริงทั้งหทดครับ แค่ไม่ต้องลง detail หรือออกแบบเผื่อมากมายต่างหาก
• ให้เขียน test ก่อน เป็นไปไม่ได้หรอก … เป็นไปได้ครับ
• ปล่อยให้ลูกค้าแก้ตลอด งานก็ไม่เสร็จซะทีนะซิ … ครับ แต่มีทางป้องกันอยู่ เราไม่แก้ฟรีแน่นอน
• รู้ Agile แล้วแก้ได้ทุกอย่าง ดีกว่า methodology อื่นๆ … มันไม่มีอะไรที่ใช้ได้ทุกสถานะการณ์หรอก (ในตำราฝรั่งเรียกว่า there is no silver bullet คือ ไม่มีหรอกกระสุนเงินที่ปราบผีได้ทุกประเภทน่ะ) แต่กลุ่ม Agile Alliance ที่ประกาศ Agile บอกว่า แม้มันจะไม่ใช่วิธีที่ดีที่สุด แต่เราพบว่ามันเป็นวิธีที่ดีกว่าที่ผ่านมา

นี่เป็นเพียงตัวอย่าง ก็ยังมีอีกมากมายเลยครับ ส่วนใหญ่ก็คือไม่เข้าใจและใช้ไม่ถูก หรือคาดหวังว่ามันต้องแก้ปัญหาได้ทุกเรื่อง ซึ่งมันก็ไม่เสมอไปครับ

ในตอนต่อไป…

เริ่มจะยาวแล้วครับ พอก่อนดีกว่า ในหัวข้อต่อไปผมจะมาเล่าต่อเกี่ยวกับ Iteration และ Incremental ที่เป็นแนวคิดพื้นฐานของการพัฒนาซอฟท์แวร์สมัยใหม่ เพราะถ้าเริ่มอธิบายเรื่อง Agile Core Value และ Principle เหมือนทั่วไปละก็ มันจะรู้สึกเหมือนตัวเองเป็นหมอสอนศาสนายังไงไม่รู้ (ประมาณกล่อมคนให้เข้าลัทธิ Agile 555) เพราะฉะนั้น ก็เอาเรื่อง Iteration & Incremental ก่อนดีกว่า เรื่องแนวคิดค่อยว่ากันทีหลัง รออ่านกันนะครับ