Extreme Programming : From Programmer to Programmer

    ผมรับโทรศัพท์จากเพื่อนร่วมงานเก่า โทรมาถามเรื่องเกี่ยวกับ UML คุยไปคุยมา ไปจบลงที่ Extreme Programming ซึ่งเป็นเรื่องที่น่าสนใจ เลยคิดว่าเอาเนื้อหาที่คุยโทรศัพท์ มาเขียนให้อ่านกันก็น่าจะดีไม่น้อย

เริ่มต้นที่ Waterfall

       ใน Web Site นี้ ที่ผมพูดบ่อยๆ น่าจะเป็นเรื่องของ Object Oriented จริงๆ แล้วมันก็เป็นเรื่องใหญ่ไม่ใช่เล่น แต่กระนั้นก็ตาม มันดูเล็กลงไปถนัดเลยถ้าเทียบกับเรื่องที่พูดวันนี้ มันเป็นเรื่องของหลักการพัฒนาโปรแกรม (Methodology) ที่คนส่วนมากมองข้ามกัน โดยมากจะเน้นกันที่ความสามารถของผู้เขียนโปรแกรมเป็นหลัก ยึดหลักว่า ยิ่งหาคนเก่งมารวมตัวกันมากเท่าไหร่ งานก็ยิ่งดีเท่านั้น ถ้าคิดอย่างนั้น ผมว่าคิดไม่ถูก ระบบที่บริษัทระดับโลกรับทำ มีชุมนุมมังกรซ่อนพยัคฆ์อยู่เต็มไปหมด ยังพลาดท่าล้มไม่เป็นกระบวนก็บ่อยครับ ผมเปรียบเหมือนวงดนตรีที่มีคนเก่งเต็มไปหมดแต่ไม่มีผู้อำนวยเพลง ก็เล่นไปคนละจังหวะ ไปไม่รอด วันนี้เรามาดูมุมมองของการจัดการบ้างก็น่าจะดี

    ถ้าเราเขียนโปรแกรมขนาดเล็กๆ คงไม่ต้องมานั่งกังวลเกี่ยวกับเรื่องของหลักในการพัฒนาโปรแกรมให้วุ่นวาย แต่ถ้าโปรแกรมของคุณมีขนาดใหญ่ มันจำเป็นอย่างยิ่งที่เราต้องมีหลักปฏิบัติที่แน่นอน และที่สำคัญต้องเป็นหลักที่ดีด้วย มิฉะนั้น งานมันจะไม่สำเร็จ หรือสำเร็จแต่ก็ไม่ได้ตามแผนที่วางไว้

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

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

    ย้อนกลับไปในอดีต หลักการในการพัฒนาโปรแกรมแบบแรกที่เราใช้แนวคิดแบบวิศวกรรมครับ เรื่องนี้ไม่ใช่เรื่องแปลกเลย เพราะวงการแรกที่ใช้คอมพิวเตอร์ ก็คือนักวิจัย และนักวิทยาศาสตร์นั่นเอง งานที่ใช้ส่วนใหญ่จึงเป็นงานเกี่ยวกับการคำนวณตัวเลข แนวคิดแบบนี้เริ่มตั้งแต่ การหา Requirement การวิเคราะห์ออกแบบ ไปถึงการสร้าง ตามมาด้วยการทดสอบ แล้วค่อยส่งมอบ แนวคิดแบบนี้ ประสบผลสำเร็จเป็นอย่างดี มิฉะนั้นเราคงไม่มีตึกระฟ้าอย่าง World Trade Center (ถึงแม้ว่าจะเหลือเพียง Ground Zero ในทุกวันนี้ก็ตาม)

    แต่เวลาผ่านมากว่า 30 ปี มีการใช้แนวคิดแบบวิศวกรรมแบบนี้กับโปรแกรมคอมพิวเตอร์ระบบต่างๆ มากมาย ผลลัพธ์ส่วนมากที่เห็นก็คือ ถ้าไม่สำเร็จ ก็ล่าช้า น้อยรายที่ใช้วิธีนี้แล้วทำงานคุณภาพได้ทันเวลา จนคนในวงการคอมพิวเตอร์ ตั้งฉายาวิธีนี้ว่า Waterfall

    ถ้าเรามีงานเขียนระบบคอมพิวเตอร์ ตั้งเป้าไว้ว่า ต้องทำให้เสร็จภายใน 1 ปี เท่าที่เคยคุยกับบุคคลต่างๆ ผมได้ตัวเลขเฉลี่ยออกมาว่า การเก็บ Requirement และการวิเคราะห์ออกแบบนั้น ใช้เวลา 1-2 เดือน จากนั้นเริ่มเขียนโปรแกรม ใช้ไปเลย 9 เดือน จากนั้นเวลาที่เหลือเอาไว้ทดสอบและส่งมอบ ถ้าตั้งเวลากันแบบนี้ ผมแทบจะไม่เคยเห็นเลยว่า ใครจะสามารถทำได้ตามแผนดังกล่าว ส่วนพวกที่มีประสบการณ์มากหน่อย จะตั้งตัวเลขการเก็บ Requirement ไม่น้อยกว่าครึ่งหนึ่งของเวลาทั้งหมด แต่สุดท้ายก็เจ็บอยู่ดี แต่ก็ยังดีที่น้อยกว่าพวกแรก

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

    เริ่มเห็นมุมมองที่ต่างกันหรือยังครับ 1 เหตุการณ์ 2 อารมณ์ ในวงการนี้เป็นที่รู้กันว่า ผู้ชนะมักจะเป็นผู้ใช้ โปรแกรมเมอร์มักจะถูกให้ผู้ใช้บังคับให้ปรับโปรแกรมตามความต้องการ มันจึงเกิดการวนรอบ โดยการเก็บ Requirement ใหม่ วิเคราะห์ออกแบบ สร้าง ทดสอบ แล้วก็ส่งมอบอีกที โดยปกติมันไม่ได้เกิดรอบเดียว มันเกิดหลายๆ รอบ มันเลยการเป็นแสลง ที่เรียกว่า Waterfall เพราะมันจะไหลจากที่สูงสุดคือการเก็บ Requirement ไปจนกระทั่งถึงการส่งมอบซึ่งเป็นที่ต่ำที่สุด ไหลลงไปอย่างนี้ชั่วนาตาปี

    ในเมืองไทยผมเห็นมามีแย่กว่านี้อีก บางที่รับงานมา ทั้งๆ ที่ยังไม่มีทีมเลย ต้องวิ่งหาทีมกันวุ่นเลย บางทีบังคับให้ต้องใช้เครื่องมือเฉพาะที่กำหนด เช่นมีการกำหนดว่าต้องเป็น Oracle เท่านั้น ทีมที่หามาได้ไม่มีใครเป็น Oracle กัน ก็ต้องมานั่ง Train กันตามมีตามเกิด วุ่นวายมากครับ ทุกวันนี้ ถ้าพูดถึงการรับจ้างเขียนโปรแกรมแล้ว ภาพพจน์ที่คนทั่วไปมอง แย่มากครับ

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

    การแก้ปัญหาแบบนี้เป็นการแก้ที่เกาไม่ถูกที่คัน ผมไม่เชื่อว่านักวิเคราะห์ระบบมือเซียนจะมีตัวตนจริง ผมไม่เคยเห็น ผมเคยเห็นนักวิเคราะห์ระบบ ระดับเงินเดือนหลักแสนหลายคน ไม่ได้มีอะไรเก่งกว่าโปรแกรมเมอร์ที่เป็นลูกน้องเลย บ่อยครั้งที่ถูกโปรแกรมเมอร์ในสังกัดสอนมวยอยู่บ่อยๆ

    ในเมืองนอก ตำแหน่งนักวิเคราะห์ระบบมีบทบาทน้อยลงเยอะ มันมีตำแหน่งใหม่เกิดขึ้นที่เรียกว่า Developer ซึ่งคนๆ เดียวเป็นทั้งผู้ออกแบบและเขียนโปรแกรมในตัว (คนละตำแหน่งกับ Programmer Analyst ซึ่งเป็น SA ฝึกหัด ที่ยังต้องเขียนโปรแกรมอยู่) ผมค่อยๆ พูดเรื่องนี้ไปเรื่อยๆ ดีกว่า

    ย้อนกลับมาที่ Waterfall สมมุติว่าคุณใช้กำลังภายนอกและกำลังภายใน ถูลู่ถูกังจนกระทั่งผู้ใช้ยอมเซ็นจ่ายเงินให้เรา ทีนี้นรกมีจริงครับ โดยปกติแล้ว ถ้าเป็นโปรแกรมขนาดใหญ่หน่อย จะต้องมีสัญญาในการทำ Maintenance ส่วนมากไม่เกิน 1 ปี มันจะเป็นช่วงที่เหนื่อยสุดๆ เพราะผู้ใช้จะต้องระดมกำลังมาจัดการให้เราแก้โปรแกรม คุณอาจจะสงสัยว่า ถ้าโปรแกรมมีปัญหาแล้วผู้ใช้จะเซ็นผ่านทำไม ก็ไม่มีอะไรเข้าใจยากครับ ก็คนเซ็นกับคนใช้มันไม่ใช่คนเดียวกัน ผมพูดเท่านี้ คุณคงเข้าใจนะครับ

    บางเจ้าทิ้งผู้ใช้ตั้งแต่ตอน Maintenance โดยที่ไม่สนใจเงินงวดสุดท้ายที่จะได้รับ ก็ส่วนมากเงินก้อนสุดท้ายนี่ก็ไม่ใหญ่เท่าไหร่ ทิ้งดีกว่า ทำตัวเป็น Taxi เริ่มที่ 35 บาทใหม่ดีกว่า เป็นกอบเป็นกำกว่าเยอะเลย ดีกว่าเก็บเล็กผสมน้อยทีละ 2 บาท

    พอหมด Maintenance คุณเคยเจอไหมว่า พออยากได้ความสามารถอะไรใหม่ๆ ก็ได้รับ Quotation แบบแพงมหาโหด ไม่ใช่การตีหัวเข้าบ้านนะครับ อย่าเข้าใจผิดว่า เขามัดมือชก กลับตรงกันข้าม มันเป็นราคาบอกผ่านต่างหาก ทำไมถึงเป็นเช่นนั้น ก็ไม่มีอะไรมากครับ อาชีพโปรแกรมเมอร์ในบริษัท Software house ส่วนมากอยู่กันไม่ค่อยทนครับ ด้วยเหตุผลต่างๆ นาๆ เมื่อโปรแกรมเมอร์ที่รับผิดชอบโปรแกรมนั้นลาออก โปรแกรมดังกล่าวก็กลายเป็นอะไรดำๆ มืดๆ คนที่เหลืออยู่ มักไม่ค่อยมีคนกล้าแตะ เวลาผ่านไป สุดท้ายก็ตัวใครตัวมันครับ บริษัทต่างๆ จึงเลี่ยงดีกว่า กว่าจะจ้างคนใหม่มาแกะอะไรที่ดำให้มันสว่างขึ้น มันใช้เวลามาก และไม่รู้ด้วยซ้ำไปว่าจะสำเร็จหรือเปล่า

    ปัญหาเรื่องคนออกไม่ได้เกิดเฉพาะหลังส่งมอบนะครับ ในระหว่างการพัฒนาเองก็ใช่ย่อย ตบเท้ากันฝุ่นคลุ้ง อัตราการ Turn Over สูงมาก เมื่อคนออกก็เริ่มกันใหม่ หาคนใหม่มาเรียน ทำให้ส่งมอบช้าลงไปอีก บางบริษัทใช้วิธีจ้างกันมาให้เยอะๆ ในทีเดียว ด้วยหวังว่าอัตราการเติมเจ้า มีสูงกว่าอัตราการรั่วออก ตุ่มมันคงเต็มได้สักวัน ทำแบบนี้ก็ได้เหมือนกัน แต่ต้นทุนก็สูงขึ้นไปอีก

    ที่ผมเห็นมา บริษัทส่วนมาก ก็ต้องปิดตัวลง เพราะชื่อเสีย โดน Black list หนีไปเปิดบริษัทใหม่ เหล้าเก่าในขวดใหม่ มันเป็นวงจรอุบาทว์ ในความคิดของผม ไม่ใช่ว่าบริษัทไม่ดีหรอกครับ แต่หากว่า สาเหตุหลักประการหนึ่งคือเขาเลือกหลักในการพัฒนา Software ผิด เลือกผิดคิดจนบริษัทพัง ผมอยากจะเป็น Slang จาก Waterfall ที่แปลว่าน้ำตกไปเป็นวังน้ำวนครับ ใครหลงเข้ามาก็จะหนีไม่ออก

Extreme Programming

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

 

ที่มา

    Extreme Programming เป็นผลงานของ Programmer กลุ่มหนึ่ง มันผิดกับ Methodology ตัวอื่นๆ ที่ส่วนมากสร้างโดยนักวิจัย ถ้าผมจะเปรียบเทียบ ผมว่ามันน่าจะเปรียบได้กับ ระบบเถ้าแก่ vs MBA  

    Extreme Programming (XP)มันลูกทุ่งดี เหมือนกันการลองผิดลองถูกแบบเถ้าแก่ ซึ่งการทำงานเน้นคล่องตัว ผิดกับ MBA ซึ่งเน้นหนักไปทางทฤษฏี XP พยายามล้มความคิดของการที่ต้องทำเอกสารมากมาย มาทำเฉพาะที่จำเป็น ซึ่งตรงกันข้ามกับแบบอื่นที่พยายามที่ต้องบันทึกทุกอย่างที่ทำเพื่อใช้ในการ Audit แต่มันก็เป็นดาบสองคมครับ เพราะจุดนี้เป็นจุดที่สร้างความไม่น่าเชื่อถือให้กับ XP มาก แต่นั่นแหละครับ XP เกิดจาก Programmer ธรรมชาติของ Programmer ก็ไม่ค่อยชอบทำ Document อยู่แล้ว แต่ก่อนที่จะสรุปว่าดีหรือไม่นั้น ค่อยๆ พิจารณากันก่อนครับ คุณอาจจะชอบลูกทุ่งแบบนี้ก็ได้

    XP เริ่มจริงๆ จาก Programmer 2 คนคือ Kent Beck และ Ward Cunningham ในต้นยุค 90 ทำงานอยู่ที่ Tektronics เขียนโปรแกรมโดยใช้ภาษา SmallTalk จากประสบการณ์ก่อนหน้าที่พบปัญหาจาก Waterfall มาก่อน ทั้ง 2 จึงค่อยๆ ปรับปรุงวิธีการต่างๆ จนสุดท้ายมาเป็น XP ที่เราเห็นกันทุกวันนี้ ทีมของ Tektronics ทุกวันนี้ มีชื่อโด่งดังกันหลายคน โดยเฉพาะ Erich Gamma ผู้เป็นหนึ่งในผู้ที่คิดค้น Design Patterns กับ Eclipse และ Martin Fowler ผู้โด่งดังจากการเขียนหนังสือหลายเล่ม กลุ่มนี้ถือได้ว่าเป็นปรมาจารย์ด้าน OOP ในยุคแรก

Embrace Changes

    แนวคิดของ XP และแนวคิดทางวิศวกรรม นั้นต่างกันที่สุดก็ตรงนี้ครับ แนวคิดทางวิศวกรรมพยายามที่ทำให้มั่นใจได้ว่า ทุกอย่างต้องถูกต้อง เช่นการสร้างตึกต้องมีการคำนวณโดยละเอียด สร้างแล้วไม่ถล่มลงมาเอง ทุกอย่างพลาดไม่ได้ เพราะอะไรผิดแล้วกลับมาแก้ใหม่ได้ยาก ดังนั้นจึงเน้นไปที่ขั้นตอนการวางแผน แต่พอนำมาประยุกต์กับงานเขียนโปรแกรมจึงกลายเป็น Waterfall ไป เพราะธรรมชาติของการเขียนโปรแกรมนั้นไม่เหมือนกับการสร้างตึกครับ เราไม่มีทางที่จะเค้นเอาความต้องการของผู้ใช้ออกมาได้ 100% ประกอบกับ เมื่อเวลาผ่านไปการเปลี่ยนแปลงต้องมีครับ เนื่องจาก Business Rules มีการปรับปรุงตลอดเวลา เอาง่ายๆ ที่มักนิยมกัน ก็คือเรื่องภาษี ที่มีการเปลี่ยนแปลงอยู่เสมอ ถ้าอ่านหนังสือที่คนเขียนเป็นอเมริกัน ตัวอย่างนี้จะถูกหยิบยกมาพูดถึงเสมอ เพราะคนอเมริกันคิดว่า ภาษีเป็น 1 ใน 4 อย่างของชีวิตที่หลีกไม่พ้นครับ

    XP มาแนวพุทธครับ ใดๆ ในโลกล้วนอนิจจัง ดังนั้น เราต้อง Embrace Changes คือยอมรับความเปลี่ยนแปลงอย่างหน้าชื่นตาบาน จงอย่าได้คิดเราสามารถทำให้เสร็จในทีเดียว มันต้องมีทีที่ 2 ที่ 3 ต่อไปเรื่อยๆ ตราบใดที่ชีวิตยังไม่สิ้น ความเปลี่ยนแปลงย่อมเปลี่ยนแปลงตลอด ดังนั้น เราไม่ควรมองความเปลี่ยนแปลงเป็นวิกฤต แต่หากมันเป็นโอกาสต่างหาก (ว่าเข้าไปนั่น)

    XP รองรับความเปลี่ยนแปลงอย่างไร เราค่อยๆ มาดูกัน

XP Life Cycle

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

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

    เท่านั้นยังไม่พอ (อีกที) ถ้าเป็นบริษัทที่ดีหน่อย เมื่อทำโครงการจนเสร็จ เขาก็ไม่สามารถทิ้งได้เลย ต้องตาม Maintenance จะทำอย่างไรได้ครับ เขาต้องทิ้งคนไว้อย่างน้อย 2 คน เพื่อดูแลระบบ เวลาผ่านไป จำนวนคนจะบวมขึ้นไปเรื่อยๆ

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

    XP เห็นปัญหาเหล่านี้ จึงออกแบบวิธีการพัฒนาโปรแกรมเสียใหม่ โดยที่พยายามเริ่มเขียนโปรแกรมให้เร็วที่สุด แต่ก็ไม่ใช่เร็วแบบไม่มีสาระนะครับ XP บอกว่า จะทำการ Survey เบื้องต้นก่อน อาจจะใช้เวลาเพียง 2 อาทิตย์ แล้วเริ่มเขียนโปรแกรมเลย แต่โปรแกรมที่เขียนนั้น ไม่ได้ครบถ้วน เขียนเพียงคร่าวๆ เช่นจำนวน Field มีเพียง 4-5 fields ก็พอ (ถ้าเต็มรูปอาจมีถึง 50-60 fields) ตั้งใจไว้ว่า ใช้เวลา 2-6 อาทิตย์เท่านั้น จะส่งมอบได้ แต่ไม่ใช่ว่าเสร็จเพียงโปรแกรมเดียวแล้วส่งนะครับ โปรแกรมจะต้องไหลตั้งแต่ต้นจนจบ ถ้าทำระบบคลังสินค้า ก็ต้องมีโปรแกรมตั้งแต่การรับเข้า ไปจนกระทั่งปิดบัญชีไปเลย โปรแกรมต้องไหลตั้งแต่ต้นจนจบเสมอครับ

    จากนั้นก็ส่งมอบโปรแกรม แน่นอนครับ โปรแกรมมันยังไม่สมบูรณ์ แต่ก็พอมองเห็นภาพคร่าวๆ ซึ่งธรรมชาติแล้ว จะต้องถูกผู้ใช้ Comment กันเพลินครับ ไม่เป็นไร อย่าทิ้ง Comment ของ User ไปเสียเปล่าๆ ครับ XP กำหนดให้มีกระดาษแข็งขนาดเท่ากับบัตรรายการที่ใช้ในห้องสมุด ให้ผู้ใช้เขียนเอาเลยครับ ว่าอยากให้ปรับปรุงโปรแกรมอย่างไรบ้าง 1 เรื่องต่อหนึ่งใบครับ ซึ่ง XP เรียกสิ่งนี้ว่า User Story

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

    นั่นคือ 1 รอบของวงจรชีวิตแบบ XP  ในการทำงานจริงๆ จำนวนรอบไม่แน่นอนครับ แต่ยังไรก็ตาม แต่ละรอบ ก็จะมีหน้าตาแบบนี้ครับ คือทำงานตาม User Story ที่กำหนด เสร็จแล้วส่งมอบให้ผู้ใช้เลือก User Story อีก จริงๆ แล้วผู้ใช้มีสิทธิเขียน User Story ได้ทุกเวลาครับ

Small Release

    เรามาวิเคราะห์วงจรนี้กัน จะเห็นได้ว่า วงจรนี้เป็นการพัฒนาโปรแกรมแบบก้นหอย ไม่ใช่แบบน้ำตก พัฒนาแบบเพิ่มเติมทีละนิด หรือที่เรียกว่า Continuous Integrate ผมขอเรียกว่าแบบก้นหอยก็แล้วกัน เมื่อพบปัญหาว่าเราหลงทาง ก็พร้อมที่จะรื้อทิ้งได้เลยในรอบแรกๆ ซึ่งเราจะไม่ต้องเสียดายอะไรมากนัก ผิดกับ Waterfall หลังจากรอบแรกออกไปแล้วหลงทาง โปรแกรมเมอร์แทบกระอักเลือดครับ

    วิธีแบบก้นหอยแบบนี้  Methodology สมัยใหม่ทุกตัวใช้ครับ ไม่มี Methodology ใหม่ๆ ตัวใดเลยที่มีแนวคิดแบบ Waterfall ถนนทุกสายมุ่งมาทางนี้หมดครับ

    การนำเอาโปรแกรมให้ผู้ใช้ได้เห็น (ถึงแม้ว่าโปรแกรมยังไม่สมบูรณ์ก็ตาม) มีข้อดีหลายข้อครับ ข้อแรกคือผู้ใช้จะเห็นว่าเราคิดอย่างไร เราแปลงเอาความคิดของเขา มาเป็น Model ทางคอมพิวเตอร์อย่างไร ถ้าผิดไปเลย ก็ไม่มีปัญหาครับ โปรแกรมเมอร์น้อมรับกลับไปรื้อทิ้ง แล้วกลับมาพร้อมกับ Model ที่ถูกต้องใกล้เคียงความเป็นจริงขึ้นในรอบต่อๆ ไป วิธีนี้เป็นวิธีที่ดีที่ทำให้ผู้ใช้เปิดปากบอกความต้องการครับ ถ้าเขาไม่เห็นอะไรเลย ก็จะนึกภาพไม่ออก  ก็เลยไม่รู้ว่าจะบอกอะไรเราดี เขาจะต้องพูดทำนองว่า ไปทำมาได้ดูก่อน  แต่ถ้าเขาเห็นโปรแกรม เขาจะ Comment ได้สบายเลยครับ

    แต่คำว่า Small Release นี่เป็นคนละเรื่องกับ Prototype นะครับ Prototype มันเป็นเพียงต้นแบบ อาจจะมีเพียงหน้าจอให้ผู้ใช้ดู ให้เห็นภาพรวมว่า โปรแกรมจะออกมามีลักษณะหน้าตาอย่างไร แต่มันเป็นการจำลองเหตุการณ์ในอนาคต ทำงานไม่ได้จริง ผิดกับก้นหอยแบบนี้นะครับ โปรแกรมทำงานได้จริงๆ เพียงแค่ไม่ครบถ้วน ถ้าเป็นงานทางธุรกิจ เราสามารถทดลองโปรแกรมจนออกรายงานตัวสุดท้ายได้ เพียงแต่ว่าข้อมูลที่แสดงมันอาจจะดูด้วนๆ เท่านั้น

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

    เรื่องก้นหอยนี้ ไม่ใช่เป็นเรื่องใหม่ในโลกของคอมพิวเตอร์นะครับ ถ้าใครเคยเขียนเรียนเรื่อง Heuristics ก็ขอให้รู้ว่ามันก็คือเรื่องเดียวกัน แนวคิดของเรื่อง Heuristics เป็นแนวคิดของการไต่เขาครับ เคยมีคนสงสัยว่า มันไต่ได้อย่างไร เรื่องนี้ผมเองก็ไม่เคยปีนเขาจริงๆ กับเขา ก็เอาเป็นว่าฟังคนอื่นแล้วมาเล่าต่อ ผิดถูกก็อย่าต่อว่ากันนะครับ

    ลองนึกภาพดูนะครับ ถ้าคุณต้องการปีนภูเขาที่มีหิมะขาวโพลน ทัศนวิสัยแย่มาก เพราะหิมะกำลังตกหนัก แทบมองไม่เห็นอะไรเลย เป็นคุณ คุณจะทำอย่างไร เครื่องมือพื้นฐานที่คุณมีก็คือ เข็มทิศ และเครื่องมือวัดความสูง (Altimeter) จากนั้นคุณก็เดินไปสักช่วงเวลาหนึ่ง เช่น 5 นาที จากนั้นคุณต้องเอาเครื่องมือทั้ง 2 มาตรวจดูว่ายังถูกอยู่หรือไม่ บางที คุณอาจจะเดินขึ้น แต่เดินขึ้นแบบเฉียงๆ นอกจากทำให้ช้าแล้ว ยังต้องย้อนเดินชดเชยอีก ถ้าคุณเดินแล้วนับก้าว คุณจะได้ระยะทางคร่าวๆ เมื่อคำนวณร่วมกับเข็มทิศและเครื่องมือวัดความสูง คุณจะรู้ได้ทันทีว่ายังตรงเป้าหรือไม่ หรือเอียงซ้ายขวาไปเท่าไร รอบต่อไปจะได้ปรับทิศทางได้ถูก จะเห็นว่าการทำงานนั้นเป็นรอบๆ เช่นเดียวกันกับวิธีก้นหอยข้างต้น

    วิธีนี้ก็เป็นวิธีเดียวกันกับวงจร PDCA (Plan Do Check Action) ที่โด่งดังมากจาก ระบบ ISO 9002:2000 และ TQM วงจรนี้เริ่มจากการวางแผนก่อน เมื่อวางแผนแล้ว ก็ลองทำดู พอทำแล้ว ก็ตรวจสอบว่ามันได้ตามแผนหรือไม่ แล้วถ้ามันดี ก็ทำเป็นกฎใช้งานเลย แต่ถ้าไม่ดี ก็เริ่มวงจรนี้ให้ ทำไปเรื่อยๆ ครับ เห็นได้ว่า มันก็เรื่องเดียวกันกับก้นหอยครับ ซึ่งมันเป็นวิธีที่ตะล่อมเข้าหาเส้นชัยครับ ซึ่งผิดกับ Waterfall คือเรามุ่งไปที่เส้นชัยเลย หลับหูหลับตามุ่งไป เช่น ถ้าคุณอยากไปเชียงใหม่ คุณรู้แล้วว่าต้องไปทิศนี้ คุณก็มุ่งไปเลย แผนที่ หรือป้ายข้างทางไม่มีไม่สน มุ่งอย่างเดียว สุดท้ายคุณอาจจะไปโผล่ที่นราธิวาสก็ได้

    การทำงานเป็นรอบยังมีจุดแข็งอีกอย่างครับ คือผู้ใช้และโปรแกรมเมอร์นี้ มีความสัมพันธ์ที่ดี ผู้ใช้จะเห็นความคืบหน้าตลอดเวลา ไม่ใช่หายหัวไป 1 ปี กลับมาจำหน้ากันไม่ได้แล้ว ความรู้สึกมันดีกว่ากันครับ ผมขอนอกเรื่องหน่อย ผมเคยเขียนโปรแกรมให้ลูกค้า มันต้องทำการคำนวณอะไรสักอย่าง ใช้เวลาประมาณ 1 นาที ผู้ใช้บ่นอุบเลยครับ ว่ารอนานมาก แต่พออีกโปรแกรม ผู้ใช้คนเดิม ผมมี Progress Bar แสดงความคืบหน้าเป็นระยะ โปรแกรมตัวนั้น 3 นาที แต่ผู้ใช้ไม่บ่นเลย คงเห็นนะครับว่าผมต้องการสื่ออะไร

 

ผู้ใช้เลือก User Story

    ถ้ามีคนถามคุณว่า ระหว่าง เครื่องคอมพิวเตอร์ Desktop กับ Note Book คุณอยากได้อะไร ผมเชื่อว่าเกือบทุกคนคงตอบว่า Note Book แต่ถ้าผมเปลี่ยนคำถามว่า Desktop ราคา 30,000 บาท กับ Notebook ราคา 90,000 บาท คุณจะเลือกอะไร ผมเชื่อว่าเสียงเริ่มแตก บางคนยังยืนยัน Note Book แต่บางคนเปลี่ยนใช้ไปซื้อ Desktop เงินมันทำให้คนรอบคอบขึ้นครับ

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

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

Onsite Customer

    ถ้าอ่านมาถึงตรงนี้ คุณจะเห็นได้ว่าผมไม่ได้พูดถึงคำว่า System Analyst เลยครับ เพราะ XP ถือว่าคำนี้เป็นคำฟุ่มเฟือย ไม่ควรใช้ XP ไม่มีตำแหน่งนี้ครับ มีแต่คำว่า Developer ซึ่งในที่นี่ผมใช้คำว่าโปรแกรมเมอร์นั่นเอง XP ถือว่าโปรแกรมเมอร์ทุกคนเป็นผู้ออกแบบด้วย ไม่มีคนใดคนหนึ่งที่รับผิดชอบเรื่องการออกแบบโดยเฉพาะครับ ปัญหาก็คือว่า มันจะสมบูรณ์หรือ

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

    มาถึง XP สิ่งที่ XP ทำทดแทนความสามารถของ SA ก็คือ การดึงเอาผู้ใช้มาเป็น SA แทนเลย XP ใช้ User Story เป็นเครื่องมือดูดข้อมูลของผู้ใช้ ซึ่งต้องรวมไปถึงการที่ผู้ใช้เห็นโปรแกรมเป็นรอบๆ มันเป็นการกระตุ้นให้เข้ามากลมกลืนกับทีมโดยไม่รู้ตัว และ User Story นี่เองใช้แทนใบ Spec ที่ได้จาก SA ครับ

Pair Programming

    มาถึงปัญหาที่เจ้าของโครงการมักจะเจอ คือโปรแกรมเมอร์ลาออก จะทำอย่างไร สำหรับ XP แล้ว วิธีเบื้องต้นที่คนอื่นเห็นก็คือ การใช้ Pair Programming มันคืออะไร

    Pair Programming คือการที่ให้โปรแกรมเมอร์ 2 คนจับคู่กันเขียนโปรแกรม แต่ไม่ใช่จับคู่แบบธรรมดานะครับ XP บอกว่า จับคู่กันแล้ว ใช้จอเดียว เครื่องเดียว และ Keyboard เดียว นั่นหมายความว่า คนหนึ่งเขียน แต่อีกคนดูครับ

    งงดูไหมครับ ถ้าคิดตามคณิตศาสตร์อย่างง่าย ปริมาณผลงานมันอาจจะหาร 2 เลย แต่ทาง XP บอกว่า การทำอย่างนี้ นอกจากมันจะไม่ได้หาร 2 แล้ว มันอาจจะมากกว่าคูณ 2 เสียอีก ทำไมถึงเป็นเช่นนั้น

    XP บอกว่า 2 หัวดีกว่าหัวเดียว ถ้าใช้คนเดียวเขียน อาจจะคิดนาน ผลงานไม่ดี แต่ถ้าใช้ 2 คนเขียน ผลงานมันจะดีขึ้น เพราะมันจะหล่อหลอมมาจากความคิดของ 2 คน อะไรที่ยากกลับทำให้ง่ายลงเยอะ แถมการเขียนโปรแกรมยังเป็นระเบียบแบบแผนขึ้น มีการขัดเกลา Code ให้มันดูอ่านง่ายขึ้น

    แต่เรื่อง Pair Programming มันเป็นศาสตร์ที่ยากมากครับ คุณจะจับเอาโปรแกรมเมอร์ 2 คนที่ความรู้ต่างกันมาก ก็ไม่ประสบผลสำเร็จ  ถ้า Ego สูงกันทั้งคู่ ก็ไม่สำเร็จ เรื่องนี้ผมยอมรับครับว่า เป็นเรื่องที่ยากที่สุด เป็นสิ่งที่ผมลองทำดูแล้วไม่ประสบผลสำเร็จ สุดท้ายต้องยกเลิกไป เป็นตัวใครตัวมันเหมือนเดิม อาจจะเป็นเพราะผมยังบริหารมันไม่ดีพอก็ได้ ถ้าใครลองดูได้ผลเป็นอย่างไร ช่วยบอกด้วยครับ

 

Collective Ownership

    ที่ผมเกริ่นนำไปเรื่อง Pair Programming ส่วนมากจะเข้าใจว่า Pair Programming ออกแบบมาเพื่อลดปัญหาการลาออก มันก็ใช่ครับ แต่มันก็เป็นส่วนเล็กน้อยเท่านั้น เพราะถ้าลาออกไปทั้งคู่ โปรแกรมที่ทั้งสองดูแล ก็จะกลายเป็นสีดำ มืดๆ เหมือนเดิม

    ทางออกที่แหวกแนวของ XP ก็คือการใช้วิธีที่เรียกว่า Collective Ownership มันคืออะไร น่าสนใจ หลักการของมันก็คือ โปรแกรมแต่ละตัวจะไม่มีเจ้าของอย่างแท้จริง แต่ไม่ใช่ไม่มีเจ้าของนะครับ ใครทำ คนนั้นก็เป็นเจ้าของ

    ฟังดูแปลกไหมครับ หลักการของ XP ก็คือ พอผู้ใช้เลือก User Story แล้ว XP ใช้วิธีอาสาครับ ไปจับคู่ Pair Programming มา จะคู่กับใครก็ได้ในรอบนี้ แล้วเอา User Story ไปทำ จะเห็นได้ว่า คู่ก็เปลี่ยนไป โปรแกรมก็เปลี่ยนไป ดังนั้น แต่ละคนก็จะได้จับทุกส่วนของโปรแกรม ทำให้ถ้ามีใครลาออก ผลกระทบจะน้อยมาก และ XP ก็ไม่ได้ห้ามการถามข้าม Pair นะครับ ถามกันได้ตลอด

    การทำอย่างนี้ นั่นก็คือทุกๆ รอบที่ทำ ทุกคนจะเป็น SA ช่วยกันทั้งหมด หลายหัวดีกว่าหัวเดียวครับ และที่สำคัญก็คือ มันไม่ซ้ำซากครับ ถ้าเราใช้วิธี Waterfall เราต้องจับโปรแกรมใดโปรแกรมหนึ่งไปตลอด จนเบื่อกันไปข้างหนึ่ง แต่สำหรับ XP มันจะเปลี่ยนไปเรื่อยๆ ความรู้สึกท้าทายก็จะเข้ามา ไม่แปลกหรอกครับ ก็คนออกแบบหลักนี้เป็นโปรแกรมเมอร์ ก็ย่อมต้องเข้าใจหัวอกโปรแกรมเมอร์ด้วยกัน

    มาถึงคำถามที่ว่า แล้วเป็นไปได้หรือไม่ ที่ User Story 2 ใบ จะแก้โปรแกรมตัวเดียวกัน เป็นไปได้ครับ อาจจะมี 2 ทีมที่แก้โปรแกรมเดียวกัน ก็แก้ไปครับ สุดท้ายเราก็เอามา Merge กันได้ครับ XP บังคับเลยนะครับว่าเราต้องทำ Software Configuration Management ถ้าไม่รู้จัก ก็พูดง่ายๆ ว่าก็โปรแกรมจำพวกคุม Version ของ Program อย่าง Sourcesafe หรือ CVS นั่นเอง ถ้าเราทำแล้วเราสามารถตรวจติดตามดูประวัติย้อนหลังได้ ว่าใครเป็นคนแก้ และแก้เพราะอะไร การเขียนเพิ่มเติมก็เป็นไปได้ และโปรแกรมมันจะไม่กลายเป็นสีดำ ครับ

Refactoring

    แนวคิดของ Collective Ownership ก็ดูเหมือนว่าจะดี แต่ถ้าใครคิดลึกหน่อย ก็ต้องคำถามว่า มันจะเป็นไปได้หรือในทางปฏิบัติ การทำ Collective Ownership เป็นการนำเอา Code ของคนอื่น มาปรับปรุงต่อยอด ว่าแต่ว่า มันจะอ่านรู้เรื่องหรือ อย่าว่าแต่ Code ของคนอื่นเลย Code ที่ตัวเองเขียนแท้ๆ ทิ้งโปรแกรมไปสัก 3 เดือน ตัวเองเขียนเอง ยังอ่านไม่รู้เรื่องเลย

    XP หาทางออกให้ครับ คือเราต้องทำ Coding Standard มาสุมหัวกันเลย ว่าต่อไป กาตั้งชื่อต่างๆ จะเอาอย่างไร การเขียน Comment ต้องมีอะไรบ้าง และอื่นๆ ที่ทำให้เวลาที่เราดูโปรแกรม เราดูไม่ออกเลยว่าโปรแกรมนี้ใครเขียน ตัดเอาความเป็นตัวตนของตัวเองออกจากโปรแกรมไปครับ

    เท่านั้นยังไม่พอ ถ้า Code เรามีมาตรฐานแล้ว แต่ยังอ่านยุ่งยากมากพันกันไปหมด XP จึงสร้างสิ่งที่เรียกว่า Refactoring มาให้เราใช้ ทาง XP ได้รวบรวมวิธีที่ทำให้ Code อ่านง่าย เป็น Document ในตัว ใครเขียนก็ต้องออกมาแนวเดียวกัน เหล่านี้รวบรวมมา แล้วเอามาตั้งชื่อครับ เป็น Pattern ต่างๆ เรื่องนี้ดีจริงๆ ครับ ผมเคยมี Code ขนาด 400 บรรทัด ให้ใครทำความเข้าใจ ต้องใช้เวลามาก แต่พอเอามาทำ Refactoring แล้ว ปรากฏว่า Code อ่านรู้เรื่องเลยครับ ตัว Code เป็น Document ในตัว มาอ่านกี่ทีใครๆ ก็รู้เรื่องครับ

    เครื่องมือ Editor สมัยใหม่หลายตัวเลยครับ ที่มีความสามารถของ Refactoring เช่น Eclipse ของ IBM (ไม่น่าแปลกใจครับ เพราะหนึ่งในทีมพัฒนา ก็เป็นทีม Extreme เก่า) เพียงแค่เลือกชื่อของ Refactoring จากนั้นมันปรับ Code ของเราให้อ่านรู้เรื่องเลยครับ นั่นเป็นสิ่งที่ XP รู้ครับ ว่า โปรแกรมเมอร์ไม่ชอบเขียนเอกสาร ดังนั้นจึงหาวิธีใช้ Code ให้เป็นเอกสารในตัว ยอดเยี่ยมมากครับ

    Pair Programming มีส่วนเสริมทำให้ การ Refactoring มีประสิทธิภาพเพิ่มขึ้นครับ

Test before Write

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

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

    ทีม XP จึงสร้างเครื่องมือช่วยทำตัวทดสอบ ตัวแรกถ้าผมจำไม่ผิด ตั้งชื่อว่า SUnit สำหรับภาษา Smalltalk จากนั้นก็เป็น JUnit สำหรับ Java ครับ ส่วนของ .NET ใช้ได้กับทุกภาษาบน .NET มีชื่อว่า NUnit ไปหา download ได้ครับ

    โปรแกรมนี้ใช้สบายครับ เขียนโปรแกรมเสร็จ ถ้าลองรันตัวทดสอบดู ถ้าเป็นสีแดง ก็คือไม่ผ่าน แต่ถ้าเป็นเสียเขียวก็ฉลุยครับ

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

Forty-hour week

    XP บอกว่า โปรแกรมเมอร์ไม่ควรทำงานเกิน 40 ชั่วโมงต่อ 1 อาทิตย์ นั่นหมายความว่า OT หรือเสาร์อาทิตย์ไม่ต้องทำ จะได้ไม่เครียดเกินไป มีเวลากลับบ้านเลี้ยงลูก เรื่องนี้ผมไม่แปลกใจเลย ก็เล่นเอา Programmer มาออกแบบระบบ มันก็ต้องออกมารูปนี้ ก็เช่นกันครับ ถ้าให้คนขับรถเมล์มาออกแบบระบบจราจร ผมเชื่อว่า การจราจรมันจะไม่เป็นอย่างที่เราเห็นทุกวันนี้ครับ

    XP บอกว่า การที่เราต้องทำ OT เราต้องย้อนกลับไปคิดแล้วว่า มันต้องมีอะไรผิดพลาด มันน่าจะเป็นที่ระบบ มากกว่าตัวบุคคล XP เชื่อว่า ถ้าเราทำตามกติกาที่ระบุไว้ข้างบนนี้ครบถ้วน 40 ชั่วโมงต่ออาทิตย์ เป็นไปได้ครับ

    ตามประสบการณ์ของผม ส่วนมากแล้ว ในเมืองไทย เวลาเข้างานของโปรแกรมเมอร์ตาม Software House ส่วนมากจะยืดหยุ่นครับ หมายความว่า จะมากี่โมงก็ได้ แต่ต้องทำให้ครบ 8 ชั่วโมง อย่า! อย่านึกว่านั่นคือสิ่งที่ดี นั่นคือวิธีการเลี่ยง OT แบบหนึ่ง ผมเชื่อว่าถ้าใช้ระบบนี้ คุณจะอยู่เกิน 8 ชั่วโมงแน่นอน

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

    การทำงานแบบฝรั่งทำอย่างไร ทั่วๆ ไป งาน Consult (คอมพิวเตอร์ก็ถือว่าเป็นงาน Consult แบบหนึ่ง) บริษัทจะอาศัยชื่อเสียงครับ รับงาน มา เป็นเลข 8 หลักถือว่าเป็นเรื่องธรรมดา จากนั้น ก็จ้างคน ให้เงินเดือนสูง แต่คนน้อยนิดเดียว ทำไปให้ตายไปข้างหนึ่ง ถ้าจะประท้วงก็เอาเงินปิดปาก สรุปแล้ว ใช้เงินไปไม่ถึง 10% อีก 90% เข้ากระเป๋าไป

    ของไทยเรารับเอาแนวคิดแบบนี้มาใช้ครับ ซ้ำร้ายบางคนทำร้ายกว่านั้นอีก เช่น Deadline 4 เดือน ก็ไปบอกโปรแกรมเมอร์ว่า 3 เดือน ให้ปั่นกันเกือบตาย พอไม่ทัน แล้วบอกว่าเลื่อนได้ แบบนี้น่ากระโดดถีบเป็นอย่างยิ่ง

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

สรุป

    ดูดีไหมครับ ผมว่าไม่เลวเลย แต่ผมเองก็ไม่สามารถทำทุกอย่างได้ตามนี้หมด คงโทษตัวเองครับที่ยังมีศาสตร์ยังไม่พอ แต่เมื่อเปรียบเทียบกับ Methodology อื่นๆ จะเห็นได้ว่า มันค่อนข้างจะคล่องตัว เน้นทางด้านบริหารมากกว่า Technique ต่างๆ ไม่มีการพูดถึง UML หรือ Design Pattern ถ้าอยากจะใช้อะไร คุณมีสิทธิที่เลือกใช้ตามความเหมาะสม ในวงการจึงเรียก XP ว่าเป็น Light-Weighted Methodology แต่ผมอยากจะเรียกมันว่าการทำทีมแบบหมาป่า มันมุ่งเข้าหาเป้าหมาย แล้วก็รุมกันล่า น่าสนใจครับ

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