เพิ่งอ่านอีกส่วนหนึ่งของหนังสือของ Alistair Cockburn เขาพยายามแยกแยะว่าคำว่า "วิศวกรรม" เวลาที่เรากล่าวว่าทำซอฟต์แวร์โดยใช้กระบวนการทางวิศวกรรม หมายถึงอะไร

เขาบอกว่าบางคนกล่าวว่า นั่นหมายถึง "ให้ทำซอฟต์แวร์ในรูปแบบที่ทำซ้ำได้และควบคุมได้"

Cockburn กล่าวว่านั่นเป็นความสับสนระหว่าง "ผล" (outcome) ของงานวิศวกรรมกับ "การกระทำ" (act) งานวิศวกรรม

ผลของงานวิศวกรรมคือโรงงานที่ทำงานไปตามระบบและมีคนคอยควบคุมดูแลคุณภาพ  ส่วนการกระทำงานวิศวกรรมคือขั้นตอนที่วิศวกรใช้ในการออกแบบโรงงานต่างหาก

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

กิจกรรมทางวิศวกรรมดังกล่าวนั้น Cockburn เปรียบเปรยว่าเป็น cooperative game นั่นคือเกมที่ผู้เล่นช่วยกันเล่นเพื่อนำไปสู่เป้าหมายบางอย่างร่วมกัน

เขากล่าวว่าเราน่าจะกลับมามองว่าคำว่า "วิศวกรรม" ควรหมายถึงการคิดวิเคราะห์และการหาจุดแบ่ง (trade-off) มากกว่า และสรุปว่าถ้ามองเช่นนั้นคำว่าวิศวกรรมก็ไม่ได้บอกว่าจะจัดการกับโครงงานอย่างไร

หมายเหตุ:
1. Alistair Cockburn เป็นหนึ่งในกลุ่มผู้ลงชื่อและเขียน Agile Manifesto
2. เวลาผมอ่านต้องพยายามทำใจกับการที่ Cockburn นำศัพท์แสงทางทฤษฎีเกมมาใช้อธิบาย (เช่น บอกว่าเกมมีหลายแบบ เช่นแบบ finite, infinite) เหมือนกับว่ากำลังพิจารณาสิ่งต่าง ๆ ภายใต้ทฤษฎีเกมจริง ๆ โดยไม่ได้แยกให้ชัดเจนว่าคำว่า "เกม" ที่เขาใช้หมายถึงเกมที่เป็นกิจกรรม ไม่ใช่เกมที่วิเคราะห์ได้ชัดเจนเหมือนในทฤษฎีเกม

ขยายเพิ่มเติม (1 สค 22:00)  [เพื่อตอบ comment ของ คุณ Tux-Linux และคุณ Joe]  เอาตามที่ผมเข้าใจนะครับ อย่างแรกก็คือการบอกว่าศัพท์ที่เราใช้เรียกเนี่ยะมันมีปัญหานิดหน่อย เขาพยายามเปรียบเทียบให้เห็นว่าเวลาเรากล่าวว่าใช้หลักการวิศวกรรมในการ พัฒนาซอฟต์แวร์ เราไม่น่าจะหมายถึงส่วนที่เป็นสิ่งที่คุณ Joe เรียกว่างานบริหาร  การวัดและควบคุมกระบวนการนั้น Cockburn ไม่นับว่าเป็นกิจกรรมที่เป็นงานวิศวกรรม แต่เป็นผลของงานวิศวกรรมมากกว่า อย่างที่สองที่ผมเข้าใจเอาเอง ก็คือเขาพยายามจะบอกว่าส่วนที่ควรจะเป็นกิจกรรมทางวิศวกรรมน่าจะเป็นในส่วน ของการออกแบบแล้วก็จัดการทางเลือกต่าง ๆ มากกว่า ทีนี้ในส่วนนั้นเนี่ยะ ถ้าเราพิจารณาว่า "หลักทางวิศวกรรม" คือการคิดวิเคราะห์และหา trade-off การบอกว่าให้พัฒนาซอฟต์แวร์โดยใช้กระบวนการทางวิศวกรรมก็ไม่ได้บอกอะไรมากไป กว่าการบอกว่าให้พัฒนาซอฟต์แวร์โดยการคิดวิเคราะห์และหา trade-off นั่นเอง  ซึ่งการระบุแค่นี้ไม่ได้ช่วยอะไรเราเลย

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

ผมก็อ่านเอาตีความเอาตามเรื่องครับ ไม่รู้ว่าผิดถูกมากน้อยครับ ขอบคุณสำหรับความเห็นนะครับ

Comment

Comment:

Tweet

ผมว่า การพัฒณาซอฟท์มันเป็นงานวิศวกรรมนะครับ
เพราะว่า(ประกอบไปด้วย)ขั้นตอน คือ

1. รับปัญหา รับทราบว่ามีปัญหา เข้าใจปัญหา
2. หาหนทางในการแก้
3. พิสูจน์ว่าใช่ หรือไม่
4. ทำออกมา
5. สรุปรวม เอาไว้เป็นประสบการณ์


ทั้งห้าข้อ ต้องอาศัยการ วัด/วิเคราะห์/สังเกต/สังเคราะห์
และ ทั้งห้าข้อนี้ มันแทรกอยู่ใน ทุกเฟสของการทำ

ผมมองว่า ที่ครบองค์ประกอบห้าข้อดังกล่าว จัดได้ว่าเป็นกระบวนการทางวิศวกรรม เสมอ แต่ถ้าขาดข้อใดใด ไป ก็จะนับไม่ได้เลย
จริง ๆ แล้วน่าจะคล้อยไปทาง คำว่า กระบวนการวิทยาศาสตร์ แต่ปัญหาของกระบวนการทางวิทยาศาสตร์นั้นมันขาด ข้อ 4 ได้ (เช่น การเหมาเอาว่า การทำอนุกรมวิธาน การศึกษาพฤติกรรม การตรวจโรค เป็นกระบวนการทางวิทยาศาสตร์ สังเกตว่า เราไม่ต้อง implement แค่ทำให้วิธีการเป็นที่พอฟังว่าสมเหตุผลแล้วก็หยุดได้ แต่งารวิศวกรรม ไม่ได้)


ถ้าจะนับเอาตามความหมายของ CockBun ผมว่า เค้าแยกเรื่อง กระบวนการทำงาน ออกจากการบริหารงาน มากกว่านะครับ เถ้าแก่กับ นายช่าง เกมที่ทั้งสองฝ่ายต้องเล่นก็คือ การต่อรองหาจุดสมดุล นายช่างอยากทำงานให้สำเร็จ เถ้าแก่ก็อยากให้สำเร็จ แต่ถ้าเถ้าแก่ไม่คุม ก็จะเสี่ยงต่อการขาดทุน ขณะนายช่าง ก็ต้องยกเหตุผลออกมาแย้งให้ได้ว่า ทำไมต้อง n วัน m คน x บาทต่อวัน

#6 By devidedByZero on 2009-07-02 19:29

ถ้าวิศวกรรมเป็นการวิเคราะห์และหา trade-off แล้วมันจะไม่ไปเหมือนกับเศรษฐศาสตร์หรือครับ? เพราะสาขานั้นก็ศึกษาในสิ่งเดียวกันเพียงแต่มีการนำไปใช้ทางด้านเงิน และทางสังคมซะมาก
ดังนั้นการตีความหมายแบบนี้ก็ยังมีปัญหาอยู่หรือเปล่า?

ถ้าต้องการเพิ่มความชัดเจนของนิยามนั้นแล้ว นอกจากการวิเคราะห์และหา trade-off แล้วยังต้องอิงกับพื้นฐานทางวิทยาศาสตร์ด้วย (แต่ยังไงก็ตามเศรษฐศาสตร์ก็อิงวิทยาศาสตร์เหมือนกัน?)

นอกจากนี้ผมก็ไม่มั่นใจว่างานทาง "วิศวกรรมซอฟท์แวร์" ที่เราใช้ๆกันนั้น (โดยเฉพาะส่วนการเขียน requirement) เป็นกระบวนการทางวิทยาศาสตร์ซักเท่าไหร่ เพราะจากที่ผมได้ลองเรียนในบางวิชาแล้วผมมองว่ามันไม่เห็นจะเป็น "วิศวกรรม" เหมือนสาขาอื่นๆเลย

แต่ตอนนี้ผมยังสับสนอยู่ว่าวิศวกรรมนั้นมันคืออะไรกันแน่

#5 By ABZee (134.91.230.161) on 2008-08-02 19:09

ขอบคุณความรู้ใหม่ๆ เช่นกันครับ

#4 By Tux-Linux (203.159.36.13) on 2008-08-02 01:12

คุณ Tux-Linux และคุณ Joe ผมไปเขียนขยายเพิ่มเติมตามที่ผมเข้าใจไว้ในตัวเนื้อเรื่องนะครับ ไม่รู้ว่าจะมั่วไปหรือเปล่า อิอิ ขอบคุณสำหรับ comment นะครับ

#3 By wonam on 2008-08-01 22:10

อ่านแล้วก็แอบงงด้วยคน embarrassed

แล้วจุดมุ่งหมายในการแยกแยะคำว่า "วิศวกรรม" นี่เพื่ออะไรเหรอครับ?

หรือว่าเค้ามองว่าเราเอาความคิดด้านวิศวกรรม มาใช้กับงานที่ไม่ใช่วิศวกรรม (งานบริหาร?) ?

#2 By Joe (203.159.36.12) on 2008-08-01 20:16

สรุปว่ามันคือการ optimize การสร้าง software ให้ออกมาคุ้มค่าในข้อจำกัดต่างๆ หรือเปล่าครับ อ่านแล้วแอบงงนิดนึงembarrassed

#1 By Tux-Linux (203.159.36.10) on 2008-08-01 10:44