พริ้ว

posted on 08 Jan 2008 22:24 by wonam  in softdev

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

เมื่อก่อนโน้น (ประมาณ 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% หนังสือหลายเล่มพยายามจะหาจุดยืนตรงกลางของสองแนวทางนี้ ผมไม่ทราบว่าจะหาได้หรือเปล่า หรือว่าจำเป็นต้องหาหรือเปล่า?

อ.เล่าให้ฟังว่าวืธีอย่าง cmm ออกแบบมาสำหรับโปรแกรมสำหรับธุรกิจ. ถ้าไม่ใช่ธุรกิจอาจจะต้องใช้อีกแบบ?

#1 By veer on 2008-01-09 10:35

veer: ผมใช้ agile ทำโปรแกรมสำหรับธุรกิจอยู่ แต่ scale ผมมันยังอยู่ในพวกกลางๆ ก็คิดอยู่เหมือนกันว่า ถ้าโปรเจคใหญ่มากๆ (มูลค่า software > 50 ล้าน) ต้องการคนมากๆ จะยังใช้ agile ได้ไหม

สำหรับส่วนตัว cmm มันเน้นที่ process เกินไป แต่ agile มันหันกลับมา focus ที่ value

#2 By pphetra (58.10.90.115) on 2008-01-09 12:33

เคยไปลงชื่อกับเค้าไว้เหมือนกัน

อืมม สำหรับ project ใหญ่มากๆ จะใช้ agile ได้มั้ย ผมว่าได้นะ แต่ว่าอาจจะยากหน่อยมั้ง

ส่วน cmm มันจะมีอีกอย่างคือ pcmm ที่กลับมามองที่ people มากกว่า process (จากหน่วยงานเดียวกันคือ sei) แต่ว่าดังน้อยกว่า

#3 By rawitat (202.44.135.35) on 2008-01-09 14:34

ผมฟังมาว่า ISO ก็จะออกอะไรคล้ายๆ CMMI เหมือนกัน แต่ถูกกว่า confused smile

#4 By veer on 2008-01-09 14:45

จากที่ทำงาน บ CMMI มาสองที่ question

จุดที่ทำให้มันดังคือมันสามารถ track process ได้ทุกอย่าง และคนที่ไม่ได้พัฒนาเองจะชอบมาก เพราะเค้า track ได้ อ้างอิงได้หมดทุกอย่าง และมันเข้ากับ Water fall น้ำตกเหวนรกที่ "ดูมีชาติตระกูล" ได้ดีมาก
และ CMMI เน้น process ว่าจะต้องดี

แต่ไม่ได้รับรองว่า คุณภาพ software จะดีนะเออquestion

#5 By plynoi แว่วศรี on 2008-01-09 23:28

แต่มันก็มีข้อดีตรงที่ บุคคลอื่นๆ ที่ไม่ใช่สาย IT แต่อยู่ในวงจรจะ track แล้วเข้าใจได้ง่ายครับ

#6 By plynoi แว่วศรี on 2008-01-09 23:34

สวัสดีครับ ผมเห็นด้วยทุกอย่างนะครับ

ผมเองที่มาจากสาย development พอมาเรียนโททางด้าน software engineering ยิ่งเห็นชัดเลยว่าไม่เห็นด้วยกับการใส่ใจด้าน process อย่างเดียว และโปรโมตการเข้าหา practice pattern เป็นอะไรที่เห็นผลกว่าเยอะ

แต่ process ในบางเรื่องมันก็มีข้อดีของมันบ้างนะครับ แม้ข้อเสียจะน่ากลัวกว่าเยอะเลย

ไม่ทราบว่าเคยได้ยิน RUP ตัวใหม่มั้ยครับ Essential Unified Process ตัว EssUP นี้ ตา Jacobson เป็นคนคิดครับ แนวคิดน่าสนใจนะครับ แต่ไม่รู้จะ work หรือเปล่า

Ivar บอกว่าปัญหาของ process แบบเดิมๆ คือมันพยายามจะครอบคลุมทุกอย่าง แม้ cmmi จะแยกตัว process ออกมาได้ดีกว่า cmm แล้วก็ตามแต่เอาเข้าจริงๆ boundary มันก็ไม่ชัดเจน เวลาจะ improve อะไรก็เลยต้องยกมาทั้งกระบิ สุดท้ายมันก็กลายเป็นชูชกท้องแตกตายเพราะตัวมันเอง

ตัว Essential Unified Process จะมองทุกอย่างในมุมมอง practice ครับ

แบ่งออกเป็น technical กับ cross-cutting practices

technical practice จะมี 5 practice ก็พวก iterative, usecase, architecture, component อีกตัวผมจำไม่ได้

ส่วน cross-cutting practice จะมี process improve, team practice, modeling practice

กฎของ EssUP บอกว่าใน 8 practice พวกนี้แยกอิสระจากกันชัดเจน อยากแก้ปัญหาอะไรก็หยิบตัวนั้นมาใช้ ถ้าอยากได้ iterative practice ก็เปิดดูว่ามี pattern อะไรบ้าง ก็เลือกมาสักอันสองอัน เช่น เราอาจจะเลือก Scrum มาใช้

ถ้าอยากได้ team practice ก็อาจจะค่อยๆ เลือกมาเช่นเอา pair programming มาใช้ ถ้าอยากได้ process improvement practice ก็เลือกมา แต่อย่าไปให้มันเว่อร์เหมือน cmmi ที่สำคํญคือแต่ละ practice ต้องสามารถ test ได้ verify ความถูกต้องได้

เริ่มยาวแหะ เอาที่นี้ก่อนละกันคุยแล้วติดลม โดยทฤษฏีก็น่าสนใจนะครับ แต่ในทางปฏิบัติยังไม่แน่ใจ มันค่อนข้างใหม่ทีเดียว แต่ก็ดูดีกว่าพวก process สุดโต่งเยอะเลยครับ

#7 By deans4j (124.120.130.223) on 2008-01-10 00:40

เก็บตกครับ

- ที่อ.ชอบ Agile, XP เป็น Software development life cycle นะครับ จัดอยู่เป็น practice ไม่ใช่ process ซึ่งภายในก็มี practice pattern ย่อยๆ ที่เค้าโปรโมตอีกที

แต่ก็มีงานวิจัยออกมานะครับว่าจริงๆ แล้วถ้าเอา CMMI/Six Sigma ไปจับกับ XP นะเป็นไปได้ (กลายเป็น Extreme CMMI) แล้วออกมาดีด้วย ส่วนผมก็ว่าน่าจะได้แต่แบบอะหลุ่มอะหล่วยกัน

confused smile

#8 By deans4j (124.120.130.223) on 2008-01-10 01:20

โอ้ว ขอบคุณมาก ๆ ครับ สำหรับ comment ;) ได้ความรู้เพิ่มมากมาย

#9 By wonam on 2008-01-11 09:14

ตอนนี้อ่านเจอในหนังสือ Booch (หนึ่งในคน design หลักของ UML) ที่พูดถึง agile process เดี๋ยวจะย่อ ๆ มาลงให้นะครับ เค้าเรียกแนวคิดแบบ discipline ว่า plan-driven

#10 By wonam on 2008-01-11 09:16

เข้ามางงwink

#11 By Shuu Exteen on 2008-01-11 23:13