ท้องฟ้าไม่มีความหมาย ถ้าไม่มีใครแหงนมองฟ้าของคนอื่น

(หัวข้อวันนี้เขียนจากที่พอจำได้ และเข้าใจ + ความเห็นส่วนตัว เนื่องจากผมเองก็ไม่ได้คลุกคลีหรือมีประสบการณ์กับวงการนี้เท่าใด ความเห็นที่เขียนในนี้น่าจะเรียกได้ว่ามาจาก "มือสมัครเล่น" ดังนั้นจึงขอน้อมรับความคิดเห็นและข้อเสนอแนะจากทุกท่าน (เป็นพิเศษ))

เมื่อก่อนโน้น (ประมาณ 10 ปีมาแล้ว) เคยสอนวิชาวิศวกรรมซอฟต์แวร์ [เพื่อความสนุก อาจลองดูเอกสารที่ทำไว้ตอนโน้น --- พยายามเปิด ตอนนี้ยังเปิดไม่ได้เพราะว่า เป็น ppt รุ่นเก่าจัด oo.o เปิดไม่ได้ ไว้จะลองเปิดด้วย powerpoint ดู] ตอนนั้น CMM กำลังเริ่มมา หนังสือ Managine the Software Process ก็เคยหามาอ่าน พอได้ลองศึกษาก็พบว่า มันเป็นเทพแห่งการเขียนเอกสารนี่นา ถึงแม้ว่าจะเป็นคนสอน แต่ตอนนั้นก็ไม่คิดว่าการพัฒนาซอฟต์แวร์ให้ดี มันจำเป็นต้องมีเอกสารขนาดนั้น (คือ พอเข้าใจในกรณีของบริษัทที่ต้องจัดการอะไรได้ถ้านักพัฒนาเข้าหรือออกจากบริษัท แต่สำหรับกรณีทั่ว ๆ ไป อาจจะไม่ไหว)

จำได้ว่าสุดท้ายสอนนิสิตว่า หลักการที่น่าจะสำคัญที่สุดในการออกแบบหรือการพัฒนา ก็คือการออกแบบเพื่อการแก้ไขเปลี่ยนแปลง (design for change)

ในอีกรอบที่สอน ก็เลยพยายามเปลี่ยนทิศทาง (ดูได้จาก comment ในหน้าวิชาเดิม)

ช่วงนั้น เพิ่งเริ่มมี UML ใหม่ ๆ (1997) คนเริ่มพูดกันถึง process ยังจำได้ตอนเรียน มีหนังสือบอกว่ามันต้องเป็น iterative ทีนี้ พอสามสหาย UML (Booch, Rumbauge, Jacobson) มาทำ UML ไม่นานก็มีการพัฒนา process ที่ใช้ UML เรียกว่า Rational Unified Process (RUP) ซึ่งแม้ว่าจะเป็นแบบ iterative เหมือนกันแต่ว่าเท่าที่เข้าใจก็ยังเน้นเอกสารอยู่ดี

หลังจากไม่ได้สอนแล้วก็ไปเรียนต่อ ผมก็ไม่ได้ติดตาม จนกระทั่งตอนนี้ เรื่องที่พูดมาแทบจะเป็น standard ไปแล้ว แนวทางดังกล่าวถูกเรียกว่าเป็นกลุ่ม discipline (น่าจะเรียกตามชื่อหนังสือของ Watts Humphrey)

แนวทางการสอนทางสาขาวิศวกรรมซอฟต์แวร์ที่ภาควิชาก็เป็นไปตามนั้นด้วย เพราะว่าอาจารย์หลาย ๆ ท่านก็มีความเชื่ยวชาญด้าน CMMI เป็นอย่างดี

อย่างไรก็ตาม สำหรับตัวผมเอง ก็ยังรู้สึกว่าไม่ค่อยจะอินกับมันสักเท่าใด

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

เมื่อไม่นานมานี้ (ความรู้สึกช้ามาก) ผมเริ่มรู้สึกว่า ผมเจอ "ค่าย" ที่ผมน่าจะพอจะจัดว่ามีรสนิยมใกล้เคียงได้ อาจจะเพราะว่าผมมีประสบการณ์ดี ๆ กับการทำ pair programming (เป็นแนวปฏิบัติหนึ่งใน extreme programming) ก็ได้ แล้วก็ได้อ่านหนังสืออีกสองสามเล่ม... ผมเลยคิดว่า อืม ค่ายนิยมความพริ้ว (agile -- ถ้าจะให้ดูเป็นทางการ longdo บอกว่าแปลว่า "ปราดเปรียว") น่าจะแนวทางที่ผมจะพอเข้าไปซุกหัวอยู่ได้บ้าง

ลองไปอ่าน คำประกาศสำหรับการพัฒนาซอฟต์แวร์แบบพริ้ว ดู ผมตัดมาไว้ที่นี่ (จะมาแปลทีหลัง ถ้ามีโอกาส)

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

คนที่ลงชื่อเต็มไปด้วยนักพัฒนา/นักคิดชื่อดัง เช่น Kent Beck, Martin Fowler, หรือจะเป็นนักพัฒนาจากค่าย Pragmatic เช่น Dave Thomas หรือ Andrew Hunt รวมไปถึง Ward Cunningham ผู้ชำนาญด้าน design pattern (เริ่มจาก paper ที่เขียนกับ Kent Beck ดูได้ที่นี่) และคนพัฒนาระบบวิกิอันแรก

การที่เรียกว่าแนวทางแบบ agile ไม่ได้หมายความว่าจะมั่ว ๆ เอาอย่างเดียว หลาย ๆ อย่างก็ต้องอาศัยวินัย (discipline) มากเอาการ เช่นการเขียน unit test อะไรพวกนี้

ผมมองว่าแนวคิดแบบ discipline (เช่น RUP, CMMI) เป็นแนวคิดที่เกิดมาจากมุมมองทางสายบริหาร คนที่คิด+นิยม เท่าที่สังเกตจะมาจากทางสายที่ปรึกษา หรือทางผู้บริหาร ส่วนทาง agile เท่าที่สังเกตมักจะมาจากทางนักพัฒนาเสียเป็นส่วนใหญ่

ที่สุดแล้ว การจัดกลุ่มจัดค่ายดังกล่าว อาจจะไม่สามารถใช้ได้ 100% หนังสือหลายเล่มพยายามจะหาจุดยืนตรงกลางของสองแนวทางนี้ ผมไม่ทราบว่าจะหาได้หรือเปล่า หรือว่าจำเป็นต้องหาหรือเปล่า?