เก็บตก Extreme Programming

    สืบเนื่องมาจากบทความที่แล้วเรื่อง Extreme Programming: From Programmer to Programmer ปรากฏว่าได้รับการตอบกลับมาค่อนข้างดี แต่หลายคนก็คงยังมีข้อสงสัยเขียนคำถามเพิ่มเติมเข้ามา พอมากเข้าก็ตอบให้เป็นการส่วนตัวไม่ไหวครับ ผมเลยเอาคำถามต่างๆ รวบรวมเอามาเขียนเป็นบทความบทนี้ให้อ่านกัน ใจจริงอยากจะเรียกว่า FAQ แต่ก็เกรงใจ เพราะที่ถามมาแต่ละคนก็ไม่ซ้ำกัน เรียกว่า JAQ (Just Asked Question) ก็น่าจะพอได้

ขอให้ช่วยอธิบายเรื่องการทำเอกสารใน XP ให้หน่อย

    ถ้าว่ากันแล้ว โดยทั่วๆ ไปที่เราศึกษากันมา เอกสารหลักที่ทางทีมเขียนโปรแกรมสร้างขึ้นมา ก็มีอยู่ 2 ส่วนหลักๆ กลุ่มแรกเรียกว่า User Manual และกลุ่มที่ 2 เรียกว่า System Manual

    ขอเริ่มที่ User Manual ก่อน User Manual เป็นเอกสารสอนวิธีการใช้งานโปรแกรม ทางทฤษฏีแล้ว ถ้าพนักงานใหม่เข้ามา พออ่านเล่มนี้จบ ก็จะสามารถเข้าใจโปรแกรมและใช้ทำงานได้ แต่ในความเป็นจริงแล้ว มันแทบเป็นไปไม่ได้ที่เราจะทำละเอียดได้ขนาดนั้น ปัจจุบัน User Manual จึงใช้เป็นแค่เพียงคู่มือเสริม เท่านั้น ผู้ที่มาใหม่ต้องผ่านการอบรมก่อน สงสัยอะไรค่อยอ่านคู่มือ การอบรมก็มีอยู่ 2 แบบ แบบแรกก็คือให้ผู้ผลิต Software มาเป็นผู้อบรมเอง ซึ่งมักจะมีค่าใช้จ่าย วันละ 5,000 ก็ไม่ใช่เป็นเรื่องผิดธรรมดา แต่มันแล้วแต่ตกลงในสัญญาครับ ส่วนแบบที่ 2 เราเรียกว่า Virus ครับ คนเก่าสอนคนใหม่ คนใหม่สอนคนที่ใหม่กว่าแบบนี้ไปเรื่อยๆ

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

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

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

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

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

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

    มาว่ากันต่อเรื่อง System Manual ครับ System Manual คือเอกสารที่ใช้อธิบายการทำงานของโปรแกรมเหมือนกัน แต่เนื้อหาไม่เหมือนกับ User Manual ครับ กลุ่มเป้าหมายของ System Manual คือโปรแกรมเมอร์นั่นเอง โปรแกรมเมอร์เป็นคนทำ โปรแกรมเมอร์เป็นคนอ่าน ดังนั้นเนื้อหาของ System Manual จึงเป็นเรื่องทางเทคนิคล้วนๆ ครับ เป้าหมายหลักของ System Manual มีเอาไว้ให้โปรแกรมเมอร์คนใหม่ (หรือแม้แต่โปรแกรมเมอร์ปัจจุบัน) ทำความเข้าใจโปรแกรมได้ครับ

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

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

    ส่วน System Manual ในส่วนที่ 2 คือส่วนรายละเอียดของแต่ละโปรแกรม XP ใช้ Refactoring ครับ เพื่อทำให้ Source Code เป็น Document ในตัว ซึ่งเป็นวิธีที่ดีมากครับ แต่ Refactoring ไม่สามารถตอบโจทย์นี้ได้ 100% คือ XP ยังขาดส่วนการอธิบายภาพรวมของโปรแกรม ด้วย Refactoring คุณสามารถอ่าน Code เข้าใจได้โดยง่าย แต่การที่ต้องดูทั้งโปรแกรมแบบ Scan เพื่อหานิยามทั้งของโปรแกรม มันเสียเวลาพอสมควร แต่ถ้ามีเอกสารอธิบายโปรแกรมอย่างคร่าวๆ (อาจจะแค่เพียง 4-5 บรรทัด) มันจะช่วยได้มากครับ

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

    Methodology บางตัวเช่น Unified Process มีการกำหนดมาตรฐานของ System Manual เอาไว้เลย ไม่ต้องคิดใหม่ทำใหม่กันเอง มันก็คือ UML ที่เรารู้จักกันดีอยู่แล้วนั่นเอง UML เปลี่ยนวิธีการทำเอกสารจากตัวหนังสือ มาใช้ Graphic ต่างๆ เข้าช่วย นอกจากมีประโยชน์สำหรับโปรแกรมเมอร์รุ่นหลังแล้ว โปรแกรมเมอร์รุ่นปัจจุบันยังสามารถใช้ประโยชน์จากมันได้ด้วย

ขอให้แสดงตัวอย่างเกี่ยวกับ Refactoring นึกภาพไม่ออก

    คุณเคยอ่าน Code ของคนอื่นแล้วอ่านไม่รู้เรื่องจนต้องเรียกเจ้าตัวคนเขียนมาอธิบายไหมครับ ถ้าเคย ลองดูว่ามันออกทำนองนี้รึเปล่า

    ผู้อ่าน: เขียนอะไรไม่รู้ 500 บรรทัดอ่านไม่รู้เรื่อง พยายามมา 10 นาทีแล้วไม่รู้เรื่องเลย อธิบายให้หน่อย
    ผู้เขียน
: เดี๋ยวนะ ทิ้งไปตั้งนานแล้ว ขอเวลาไล่ดูก่อน
   

    *** เวลาผ่าน 3-4 นาที เลื่อน หน้าจอ Editor ขึ้นลงหลายครั้ง
    ผู้เขียน: รู้แล้ว โปรแกรมนี้มันทำ .....
    ผู้อ่าน: เอาทีละส่วนดีกว่า
    ผู้เขียน
: ก็ได้


   
*** จากนั้นผู้เขียนก็เอา Mouse ลาก Highlight Code บางส่วนประมาณ 30 บรรทัดแล้วพูดว่า
    ผู้เขียน
: นี่ไง ส่วนนี้เป็นส่วนตรวจสอบดูว่ามีสิทธิรึเปล่า
    จากนั้นผู้เขียนก็ลากอีกส่วนขนาด
40 บรรทัด
    ผู้เขียน
: ส่วนนี้ก็ทำการย้ายรายการจากรายรับมาเป็นรายจ่าย
   
...
   
*** และอื่นไป ไปจนจบโปรแกรม

    นี่คือปัญหาที่เจอบ่อยครับ จะแก้อย่างไรดี ทางออกทางหนึ่ง ก็คือการเอา Comment ใส่ไว้ที่หัวของ แต่ละส่วนของ Code การทำแบบนี้ก็ดูดีขึ้น แต่ก็ติดปัญหาครับ มันจะทำให้ Code ที่รกอยู่แล้ว รกขึ้นไปอีก ทางออกที่ดีกว่า ทาง XP เสนอ Refactoring ที่ชื่อว่า Extract Method มาจัดการเรื่องนี้ เขียนดังนี้ครับ

    void close_all_account()
    {
             perform_user_permission();
             transfer_income_to_expense();
            ...
    }
     จะเห็นได้ว่า Code 70 บรรทัดข้างบน เหลือเพียง 2 บรรทัด ทั้ง 2 บรรทัดเป็นเหมือน Comment ในตัวอ่านแล้วรู้เรื่องทันที ไม่ต้องเปลืองบรรทัดในการเขียน Comment เลยครับ เราไม่จำเป็นต้องเรียกผู้เขียนมาอธิบายให้เราฟังอีกต่างหาก

    ทีนี้มาลองดูว่าถ้าโปรแกรมนี้มีข้อผิดพลาด เช่นโปรแกรมโอนรายได้มาเป็นรายจ่ายไม่ครบ เราก็สามารถเข้าไปตรวจสอบที่ฟังก์ชัน transfer_income_to_expense() เราสามารถข้าม perform_user_permission() ไปได้เลย ไม่ต้องเสียพลังงานเข้าไปดู และใน transfer_income_to_expense() อาจจะมีเพียง 3-4 บรรทัดเท่านั้น เพราะถูก Extract Method ด้วยเหมือนกัน เราก็ต้องลงลึกไปอีก แต่ในการลงลึกเป็นชั้นๆ แบบนี้ เป็นการทำลายความซับซ้อนของโปรแกรมครับ

   

แนวคิดของ Design Pattern ที่ออกแบบก่อนค่อยเขียน มันดูเหมือนว่าขัดกับแนวคิดของ XP มีความเห็นอย่างไร

    ก่อนที่ผมจะตอบ ผมขอเกริ่นนำเกี่ยวกับ Design Pattern เผื่อว่าคนที่ไม่เคยรู้จักจะได้นึกภาพออก Design Pattern เป็นเรื่องของสูตรในการออกแบบโครงสร้าง Object Oriented สูตรอย่างไร ผมขอยกตัวอย่างเปรียบเทียบให้ฟังก็แล้วกัน ดูอย่างหลังคาบ้านครับ ถ้าเป็นแบบไทยๆ แล้วละก็ หลังคาบ้านมักจะเป็นสามเหลี่ยมหน้าจั่ว บางเผ่าโบราณก็เป็นรูปกรวยวงกลม และอื่นๆ อีกมากมาย แล้วแต่การออกแบบให้เหมาะสมกับภูมิประเทศ เราอาจจะเห็นว่าหลังคาเหล่านี้แตกต่างกันในแต่ละที่ แต่ถ้าดูดีๆ มันมีสิ่งที่เหมือนกันอยู่ครับ สิ่งที่ว่านั้นก็คือ ไม่ว่าหลังคาแบบไหน มันมักจะมีส่วนยอด แล้วส่วนยอดมันจะลู่ลงครับ ทั้งนี้ก็เพื่อให้น้ำฝน ฝุ่น หรือหิมะ ไหลลงสู่พื้น ไม่ขังตัวอยู่บนหลังคา เป็นการป้องกันไม่ให้บ้านถล่มครับ ดังนั้นหลังคาบ้านจึงต้องลู่ลง นั่นแหละครับคือสิ่งที่ผมเรียกว่าสูตร

    Kent Beck ผู้คิดค้น XP เคยอ่านหนังสือเล่มหนึ่งเกี่ยวกับสูตรในการออกแบบทางสถาปัตยกรรมที่เขียนโดยนาย Christopher Alexander เขาก็เลยคิดว่า ในการออกแบบ Software เราก็น่าจะมีสูตรอย่างว่าเหมือนกัน ดังนั้นเขาจึงนำเสนอแนวคิดเรื่องนี้ในการประชุมเกี่ยวกับ OO ที่หนึ่งให้ช่วยกันหาสูตรสำเร็จ ถ้าผมจำไม่ผิดก็น่าจะเป็นปี 89 จากนั้นพอมาปี 94 ก็มีผู้คิดค้นสูตรบางสูตรได้ โดยการที่ไปวิจัยดูการออกแบบของ Software ที่ประสบผลสำเร็จ แกะไปแกะมาจนได้มาเป็นสูตร ผลลัพธ์คือหนังสือที่ชื่อว่า Design Pattern โดยมีผู้เขียน 4 คน (เรียกติดปากกันว่า Gang of Four) หนึ่งในนั้นก็เป็นคนของทีม XP นี่แหละครับ หนังสือเล่มนี้ได้รางวัลแห่งปีจากหลายสถาบันเลย จากนั้นก็มี Design Pattern เขียนตามมาอีกหลายเล่ม จนวันนี้เยอะไปหมดแล้วครับ คำว่า Design Pattern จึงค่อนข้างที่จะดูขลังมาก

    ทุกวันนี้มีคนไม่น้อยถือเอา Design Pattern ของ Gang of Four เป็นหลักในการออกแบบโปรแกรมทุกอย่าง โดยที่คิดว่า Design ดีตั้งแต่แรก งานก็จะไม่พัง พอนึกภาพออกไหมครับ ถ้าเป็นอย่างนั้น มันก็ดูเหมือนว่าขัดกับ XP ที่ดูแล้วว่ามันไม่ได้สนใจเรื่อง Design เท่าไหร่ มาปรับเอาทีหลัง นั่นเลยเป็นที่มาของคำถามข้างต้น

    ถ้าจะให้ผมตอบ ผมว่ายังไม่ตอบ ผมขออ้างข้อเขียนของคนๆ หนึ่งดีกว่า คนๆ นี้เป็นคนเขียนหนังสือที่ชื่อว่า Design Pattern Explained นัยว่าต้นฉบับของ Gang of Four อ่านเข้าใจยาก เขาเลยมาถ่ายทอดใหม่ให้มันเข้าใจได้ง่ายขึ้น น่าเสียดายข้อเขียนตัวนี้ ผมหาไม่เจอแล้วใน Website ไม่รู้ว่าผมหาไม่เจอเองหรือถูกลบไปแล้วก็ไม่รู้ แต่ผมขอถ่ายทอดเท่านี้จำได้ก็แล้วกัน

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

        ผมขอสรุปอย่างนี้ก็แล้วกัน XP นั้นจริงๆ ไม่ได้ถือเอา Design Pattern มาเป็นหลักทำงาน แต่ก็ไม่ได้ขัดเสียทีเดียว คุณสามารถทำผ่าน Refactoring แต่การที่จะ Design Pattern ใน Refactoring นั้น คนที่สามารถทำได้ก็ต้องมีความรู้หน่อย ผมยืนยันได้ครับว่ามันทำได้ ไม่ต้องคิดอะไรอื่นไกล ก็ที่นำเสนอ Design Pattern ก็เป็นคนของ XP และผู้เขียนหนังสือ Design Pattern คนหนึ่งก็เป็นคนที่โตมากับทีม XP (Logic ผมข้างๆ คูๆ ดีไหมครับ?)

XP เน้นให้ผู้ใช้สามารถร้องขอการแก้ไขได้ตลอด แบบนี้เมื่อไหร่จะจบ

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

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

    แต่ถ้าเจอผู้ใช้ที่เรื่องมาก ผมว่ามันไม่ได้อยู่ที่ Methodology มันต้องอาศัยอย่างอื่นช่วย เช่นเทคนิคการเจรจาต่อรองเป็นต้น

 

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

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

 

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

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

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

ช่วยแนะนำแหล่งข้อมูล XP สำหรับศึกษาเพิ่มเติม

    หนังสือ Extreme Programming explained ของ Kent Beck   ISBN:0-201-61641-6
        หนังสือเล่มนี้ถือได้ว่าเป็นหนังสือเปิดโลก XP ครับ หนังสือเล่มนี้เป็น Overview ของ XP พลาดไม่ได้ครับหนังสือเล่มนี้ หนังสือเล่มนี้เป็นหนังสือที่ช่วยในการตัดสินใจว่าจะเลือก XP หรือไม่

    หนังสือ Extreme Programming installed ของ Ron Jeffried และคณะ ISBN 0-201-70842-6
        ถ้าใครอ่านหนังสือของ Beck แล้วตัดสินใจว่าเอา XP แน่ๆ แล้ว ก็ลองอ่านเล่มนี้ครับเป็นเล่มที่ 2 หนังสือเล่มนี้ จะลงในเนื้อหา บอกถึงหลักปฏิบัติต่างๆ เพื่อให้สามารถนำไปใช้งานได้อย่างมีประสิทธิภาพ

    หนังสือ Refactoring ของ Martin Fowler ISBN: 0-201-48567-2
        สำหรับเรื่อง Refactoring ไม่ว่าคุณจะใช้ XP หรือ Methodology ใดๆ แม้แต่ Waterfall คุณสามารถใช้ประโยชน์จาก Refactoring ได้เสมอครับ ผมแนะนำให้คุณซื้อหนังสือเล่มนี้เลยครับ ไม่ว่าคุณจะเลือกใช้ XP หรือไม่ก็ตาม

   
    Website: http://www.refactoring.com 
        Website นี้เป็น Website ทางการของ Refactoring ครับ เนื้อหาภายในก็คือมี Refactoring Pattern ใหม่ๆ ที่ไม่มีในหนังสือ คาดว่าซักวันก็คงรวบรวมไปใส่ไว้ในหนังสือ Edition ต่อไป ใน Website นี้ยังมีตัวอย่างของการทำ Refactoring อย่างยาวให้อ่านอีกด้วย

    Website: http://www.objectmentor.com
        Website นี้เป็น Website ที่มีรายละเอียดเกี่ยวกับ XP อยู่เป็นจำนวนมาก และ Methodology อีกตัวคือ Agile ลองเข้าดูครับแล้วจะชอบ
 

    Website : http://www.extremeprogramming.org
            ภาพรวมของ XP ก็ต้องที่นี่ครับ

    ผมเพียงแนะนำทางเข้าให้เท่านั้นนะครับ ลองตาม Link Website ต่างๆ ของ Website เหล่านี้ มันจะพาคุณไปอีกหลาย Website ที่ล้วนแล้วแต่เนื้อหามากมายทั้งนั้นครับ
      

นอกจาก XP แล้วยังมี Methodology อื่นอีกไหมที่เป็นทางเลือก

    มีครับ มีอีกหลายตัวเลยทีเดียว ตัวที่ดังไม่น้อยหน้า XP เลย นั่นก็คือ Unified Process ที่คิดค้นโดย Rational (ปัจจุบันโดน IBM ฮุบไปแล้วครับ) Unified Process ก็ดังไม่ใช่เล่นนะครับ ทีมผู้คิดค้นก็เป็นทีมเดียวกันกับทีมที่ออกแบบ UML นั่นเอง เราเรียกติดปากกันว่า Three Amigos

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

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

    ถ้าผมมีโอกาส ผมจะเขียนบทความเกี่ยวกับ Unified Process แต่มันคงจะยาวน่าดู นอกจาก 2 ตัวนี้ยังมีอีกหลายตัวครับ ที่ดังๆ ก็มี Agile ลองไปหาข้อมูลดูครับ

Supoj

08-FEB-03