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 มันจะเปลี่ยนไปเรื่อยๆ ความรู้สึกท้าทายก็จะเข้ามา ไม่แปลกหรอกครับ ก็คนออกแบบหลักนี้เป็นโปรแกรมเมอร์ ก็ย่อมต้องเข้าใจหัวอกโปรแกรมเมอร์ด้วยกัน
ไม่มีความคิดเห็น:
แสดงความคิดเห็น