[T]issues 2.1

มีนักวิทยาศาสตร์ท่านหนึ่งเสนอ Software Development Process ชื่อว่า Chaos Model – เนื้อหาย่อๆมีดังนี้

การพัฒนา software project ขึ้นมาซักโครงการ มีวิธีพัฒนาให้เลือกใช้มากมายหลายสกุล ทั้งแบบศักดินาอย่าง waterfall แบบโมเดิร์นอย่าง iterative หรือ agile ไปจนกระทั่งวัยรุ่นอย่าง extreme programming

แต่กระบวนการทั้งหลายแหล่ให้ความสนใจกับ

• “ขั้นตอนการทำงาน” ว่าควรจัดลำดับความสำคัญทำอะไรก่อนหลัง (Design, Code, Integration, Test)
• “ความต่อเนื่องของการทำงาน” เช่น waterfall ทำเป็นขั้นๆไป ทำให้เกิดปัญหาคอขวด พวกกระบวนการที่ตามมาหลังๆก็ปรับให้ทำงานได้ smooth ขึ้น โดยซอยขั้นตอนการทำงานให้เล็กลง พอดีคำ – ทำให้สามารถทำแบบขนานได้ (parallel) เป็นกลุ่มๆ
• “ผลลัพธ์ของแต่ละกระบวนการทำงาน” เช่นชิ้นงาน (workproduct) ที่จะออกมาในแต่ละขั้น

กระบวนการเหล่านี้ตั้งสมมุติฐานว่าการพัฒนา software เป็น “ศาสตร์” มากกว่า “ศิลป์” ซึ่งต่างพยายามเข้ามา “ควบคุม” เพื่อลดความเสี่ยงของโครงการ

คงไม่มี project manager คนไหนอยากทำงานกับโปรแกรมเมอร์อ๊าตตัวพ่อ วันนี้ไม่มีอารมณ์ กูไม่ทำ…

[อ่ะ บอกว่าจะย่อ ยังไม่เข้าเนื้อหาเลย -_-']

ไอ้เจ้า chaos model เนี่ย เขามองว่ามันมีขอบบน/ล่างอยู่

• ขอบบน คือระดับ highest level ของโครงการ เช่นจะทำเว็บขายบ้าน มันต้องสมัครสมาชิกได้ ต้องใส่รายละเอียดบ้านได้ ฯลฯ
• ขอบบน (ลงมาหน่อย) คือระดับ design เช่นมี entity อะไรบ้างในระบบ มีความสัมพันธ์กันยังไง ฯลฯ
• ขอบล่าง (ลงมาหน่อย) คือระดับ implementation technique เช่น entity User ในเมทอด findBelongedHouse ต้องไปหา record จากฐานข้อมูล ด้วย query blah blah
• ขอบล่าง คือระดับ lowest level เช่นในบรรทัดหนึ่งๆจะเขียนโค้ดอะไรบ้าง

โดยเจ้าพวกขอบต่างๆเนี่ย เขาบอกว่าเป็นสิ่งที่ stakeholder ในโครงการเข้าใจดีว่าตัวเองต้องทำอะไร ยังไง เรียกว่าทำความเข้าใจกับสิ่งเหล่านี้ง่ายเพราะใกล้ตัว และควบคุมได้* (กาดอกจันไปร้อยดอกเลยนะครับ) – สังเกตไหม อะไรหายไปเอ่ย?

ตรงกลางไงครับ…

ช่องว่างระหว่างคนคิด (Designer) กับ คนทำ (Implementer)

chaos model อธิบายถึงธรรมชาติของ software development คือความไม่แน่นอน – เพราะชีวิตเรามีอะไรให้ตื่นเต้นเสมอ เช่นวันพรุ่งนี้จะส่ง build เทสกันมานานนมก็ไม่เจอปัญหา แต่พอหกโมงเย็น ได้เวลาเลิกงาน กลับเจอปัญหาตัวเป้งที่ตัดสินความเป็นตายของโครงการได้เลย เป็นต้น

[ประสบการณ์ตรง สดๆร้อนๆ]

ทีนี้ chaos model พยายามจะบอกว่า “ความไม่แน่นอนคือความแน่นอน” เอ๊ะหรือ “ความแน่นอนคือความไม่แน่นอน”

[หรือความน่านอนคือความแน่นอน]

ทฤษฎีนี้น่าสนใจ เพราะมันอาจช่วยเราอธิบายได้ว่าทำไม๊ ทำไม

• Software Development มัน so unpredictable
• Design สุดท้ายไม่ค่อยจะตรงกับที่ implement

แล้วไว้มาพูดถึง Chaos Strategy ต่อ

References:

• Raccoon (1995) The Chaos Strategy [ACM paper]
• Wikipedia – Chaos Model [Wiki]