ตอนต่อของซีรีส์ Agile ตอนที่ 4 มาแล้วครับ ในตอนนี้จะเป็นเรื่องราวเกี่ยวกับหลักการ หรือ principles ของแนวทางการพัฒนาซอฟท์แวร์แบบ Agile ซึ่งมีทั้งหมด 12 ข้อ แต่ต้องออกตัวก่อนว่าผมคงไม่มีเวลาเขียนทั้งหมดจบในตอนเดียวด้วยงานค่อนข้างเยอะ ก็เลยจะขอตัดลงให้อ่านกันเป็นตอนๆ นะครับ คิดว่าน่าจะตอนละ 3-4 ข้อแล้วก็แล้วกัน ถ้าเคลียร์งานเรียบร้อยจะมาลงต่อให้ครับ ^^ … ว่าแล้วก็ไปต่อกันเลย

ก่อนที่จะลงไปในรายละเอียดของหลักการแต่ละข้อ ผมอยากจะย้ำว่า Agile เกิดจากประสบการณ์ของ Agile Alliance แต่ละคนมาคุยกัน แล้ว share สิ่งที่ตัวเองเคยทำแล้วมัน work จากนั้นจึงหาข้อสรุปร่วมกัน ได้มาเป็น Core Value และ Principle เพราะฉะนั้น methodology (หรือ process) ต่างๆ ของ Agile จึงมีวิธีการที่สอดคล้องกับ principle เหล่านั้น หรืออาจจะมองว่า Agile S/W development = Core Value + Principles + Methodology ก็ได้

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

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

เรื่องนี้เป็นเรื่องเล่าขำๆ ที่เปรียบเทียบกับสิ่งที่คนเราทำกันไปโดยไม่ได้สงสัยที่มาเลยว่าทำไมต้องทำแบบนี้ บางครั้งการที่คนอื่นปฎิบัติต่อๆ กันมา มันอาจจะมีที่มาหรือสาเหตุอะไรก็ได้ เช่นเดียวกับ Agile ที่มันก็มีวิธีการบางอย่างที่แปลกๆ ไม่เหมือนชาวบ้านคิดกัน เช่น วิธีการของ eXtreme Programming บอกว่า ให้ programmer 2 คน เขียนโปรแกรมด้วยกันโดยที่ใช้เครื่องเดียวกัน keyboard และ mouse ชุดเดียวกัน เป็นต้น นั่นก็เพราะมันมีที่มา บางคนเจอข้อนี้ก็บอกเลยว่า Agile ไร้สาระ ทำจริงไม่ได้หรอก แล้วก็เชื่อไปเลยโดยที่ไม่ได้ดูที่มาของวิธีการเหล่านั้น … Core Value และ Principles จะเป็นข้อสรุปเป็นหลักการและแนวทางของที่มาเหล่านั้น เพราะฉะนั้นถ้าคุณยังไม่เข้าใจ ก็อย่าไปนำมันมาใช้ หรือถ้ามันไม่เหมาะกับวัฒนธรรมของทีม ไม่เหมาะกับองค์กร หรือปัญหาที่คุณกำลังเผชิญ ก็อย่าเอาไปใช้เลยครับ เสียเวลาเปล่าๆ ครับ

แต่ถึงมันจะไม่ work กับทุกสถานการณ์ แต่ในความเห็นและประสบการณ์จากการเป็น programmer ของผม ผมเห็นด้วยกับที่ Agile Alliance สรุปไว้ว่า ถึงแม้ว่ามันจะไม่ใช่วิธีที่ดีที่สุด แต่ก็เป็นวิธีที่ดีกว่าในการพัฒนาซอฟท์แวร์ เพราะมันเปิดโอกาสให้เราแก้ไขข้อผิดพลาดได้ดีและเร็วกว่าวิธีการที่ผ่านมา

เริ่มต้นก็ยาวซะแล้ว จบเลยดีกว่า เอ๊ย ไม่ใช่ … มาดู principle ทีละข้อดีกว่าครับ ^^

Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

ข้อนี้บอกว่า สิ่งที่เค้ามองว่าสำคัญที่สุดก็คือทำให้ลูกค้าพึงพอใจ โดยส่งมอบ software ที่ “มีคุณค่าต่อลูกค้า” ตั้งแต่ “เนิ่นๆ” อย่าง “สม่ำเสมอ”

เรามาลองเจาะลึกถึง principle ข้อนี้ดู แนวคิดพื้นฐานของข้อนี้คือ Iteration นั่นเอง

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

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

คราวนี้แทนที่เราจะทำแบบครั้งเดียวเสร็จแล้วค่อยเอาไปให้ลูกค้าดู เราก็ทยอย implement ให้เสร็จเป็น feature ไปแล้วเอาไปให้ลูกค้าดูบ่อยๆ นั่นแหละคือการส่งมอบซอฟท์แวร์ที่มีคุณค่าบ่อยๆ อย่างสม่ำเสมอ และเมื่อลูกค้าเห็นบ่อยๆ , ได้ review, ได้ comment, เห็นความคืบหน้าของงานตลอดเวลา ลูกค้าก็จะพึงพอใจในสิ่งที่เราพัฒนาให้เค้า เพราะถึงแม้ว่างานอาจจะไม่ถูกต้องนัก แต่ลูกค้าก็จะเห็นความใส่ใจและตั้งใจของเรามากกว่าการที่ไม่เคยกลับไป review กับลูกค้าเลย ปัญหาอะไรที่หนักก็จะเบาลงถ้าลูกค้าพึงพอใจครับ เผลอๆ ต่อให้งานเสร็จไม่ทันตามกำหนด ลูกค้าก็อาจจะไม่ว่าอะไร เพราะเราส่งมอบงานอยู่ตลอดเวลา และที่สำคัญ งานที่จำเป็นมันเสร็จไปแล้วตั้งแต่ต้น งานที่ไม่ทันก็คืองานที่มี priority ต่ำสุด หรืองานที่ไม่มีก็ไม่เป็นไรยังไงละครับ

แต่เมื่อมีข้อดี ก็มีความเสี่ยงตามมาแน่นอน บางครั้ง (มองโลกในแง่ร้ายหน่อย) เราจะเจอกับลูกค้าที่จู้จี้หรือคอยเอาเปรียบ อยากได้ดีๆ เยอะๆ ถูกๆ ไม่ถูกใจงานอยู่เรื่อย คอยแก้งานตลอด ล้วงลูกอยู่เสมอ (เหมือนบ่นเลยแฮะ 555) ถ้าเจอแบบนี้ การทำ prototype หรือทำตัวอย่างหน้าจอ แล้วจับเซ็นสัญญา (ประมาณว่าแก้ได้แต่คิดตังนะ) ก็ยังจำเป็นอยู่ แต่การแบ่งงานเป็นรอบๆ และ review จะช่วยทำให้งานของเราเป็นไปในแนวทางที่ควรจะเป็นอยู่เสมอ

เรายังมีอีกหลายข้อที่จะมาสนันสนุนแนวคิดข้อนี้ เช่น ในข้อ 4 เราจะค่อยๆ ว่ากันไปทีละข้อครับ

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

ยอมรับและยอมที่จะเปลี่ยน requirement แม้ว่ามันจะทำให้การพัฒนาล่าช้าออกไป ถ้าการเปลี่ยนแปลงนั้นช่วยให้ลูกค้ามีความสามารถในการแข่งขันกับคู่แข่งได้มากกว่า

โอ้โห … ผมเดาว่าเจอข้อที่ 2 เข้าไป หลายคนอยากจะปิด browser เลิกอ่านไปเลย … ผมบอกได้เลยครับว่านี่เป็นอีกข้อหนึ่งที่ใครหลายๆ คนขัดใจสุดๆ มีอย่างที่ไหนยอมให้เปลี่ยน requirement ได้กลางทาง แค่ทำตาม requirement ให้เสร็จยังลำบากเลย แต่นี่เล่นบอกว่ายอมให้เปลี่ยน requirement กันเลยทีเดียว แล้วเมื่อไหร่มันจะเสร็จละคร้าบ …

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

หลายคนอาจจะเดาออกแล้ว ครับ … หลักการสำคัญที่จะทำให้เรื่องนี้เป็นจริงได้ก็คือ Iteration อีกนั่นแหละ ด้วยแนวคิดของ Iteration และการจัดลำดับ priority บวกกับการ implement feature ตาม priority ที่สูงกว่าให้เสร็จเป็นงานๆ ไป จะช่วยให้เราปปรับเปลี่ยนงานของเรากลางทางได้ ทำได้ยังไง ลองดูตัวอย่างครับ

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

• บอกไปว่า ระยะเวลาที่เราวางแผน 1 ปีนั้นมันพอดีแล้ว ค่าใช้จ่ายก็คิดที่ resource 1 ปี เพราะฉะนั้นถ้าเพิ่ม requirement เข้ามา ลูกค้าก็ต้องเลือกครับ ว่าจะยืดเวลารวมของ project ออกไปหรือไม่? ถ้ายอมยืดเวลาส่งมอบออกไปได้ ก็จำเป็นที่จะต้องมีค่าใช้จ่ายเพิ่มตามระยะเวลาที่มากขึ้นครับ
• หรือถ้าไม่อยากเพิ่มเงินหรือเวลา ก็ทำได้ โดยเลือกตัด feature บางตัวออก เพื่อให้งานเสร็จทันใน 8 เดือนที่เหลือ (แบบนี้ไม่เพิ่มเงิน) ระบบทั้งหมดจะสามารถทำงานได้ในเวลา 1 ปีเหมือนเดิม ส่วน feature ที่ตัดไปก็ค่อยทำหลังจากนั้น แต่ feature เหล่านั้นก็เป็น feature ที่มี priority ต่ำสุด (เช่นหน้าจอ จังหวัด อำเภอ ไม่มีก็ได้) เพราะฉะนั้นจะไม่กระทบภาพรวมทั้งหมด จากนั้นก็เลือกได้เลยว่า requirement ใหม่ที่เพิ่มเข้ามาสำคัญขนาดไหนเมื่อเทียบกับ requirement ที่ยังไม่ได้เริ่มทำ
• หรือทางสุดท้ายถ้ายังไงก็ไม่รับฟังเหตุผลกัน ก็ปิด project มันตอนนั้นเลย เพราะสิ่งที่เสร็จแล้ว 4 เดือนสามารถเอาไปใช้ได้แล้ว ตัดจบคิดเงินเลย แล้วเริ่ม phase 2 ต่อไป หรือจะจ้างทีมอื่นมาทำต่อก็ว่ากันไป แต่อย่างน้อยงานที่ทำมาไม่เสียเปล่าแน่นอน

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

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

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

ข้อนี้บอกว่า ส่งมอบ software ที่ “ใช้ได้” และ “ส่งมอบบ่อยๆ” อาจจะทุกๆ 2-3 สัปดาห์ถึงทุกๆ 2-3 เดือน โดยไม่เว้นระยะให้นานเกินไป

ย้อนกลับไปที่ 2 ข้อที่แล้ว จะเห็นว่าถ้าเราสามารถ implement งานแต่ละ feature ให้ใช้ได้จริงทีละเรื่อง และส่งมอบบ่อยๆ เราจะสามารถรับมือกับความเปลี่ยนแปลงได้มากกว่าแบบที่จะต้องรอจนเสร็จทั้งหมด ข้อนี้จึงบอกว่า เราควรที่จะส่งมอบงานให้บ่อยๆ เพราะเมื่อระยะเวลามันสั้น เราทำอะไรเยอะๆ ไม่ได้หรอกครับ ลองนึกดูว่าระยะเวลา 2-3 สัปดาห์ เราจะทำอะไรได้มากมายหรือครับ ไม่เลย อาจจะได้แค่ 2-3 เรื่องเท่านั้น แต่เพราะระยะเวลามันสั้น ทีมพัฒนาก็จะไม่มีเวลาไม่ห่วงเรื่องอื่นมากนัก เอาแค่ทำเรื่องที่พอจะทำเสร็จได้ใน 2-3 สัปดาห์ก็พอ เพราะฉะนั้น สมาธิของทีมก็จะจดจ่ออยู่กับงานไม่กี่ชิ้น พยายามทำให้เสร็จไปเลย ถ้ามันเสร็จได้ เราก็จะไม่ต้องมาพะวงกับมันอีก

เมื่อระยะเวลาสั้น ลูกค้าก็มีโอกาส review ได้เร็ว เพราะระยะเวลา 2-3 สัปดาห์ได้งาน 1-2 ชิ้น แค่นั้นก็ review ได้เลย ลูกค้าก็ไม่จำเป็นต้องรอจน project จบจึงจะได้เห็น และลูกค้าก็อาจจะใช้เวลา review เพียงแค่ 1-2 ชั่วโมงก็ review จบแล้ว (ก็งานที่เสร็จมีแค่นี้เอง) และถ้ามันผิดหมดเลย มันก็เป็นงานที่ใช้เวลาทำแค่ 2-3 สัปดาห์เท่านั้น โยนทิ้งไปแล้วทำใหม่ก็เสียเวลาแค่ 2-3 สัปดาห์ … จริงไหมครับ

ข้อนี้จะเป็นจริงได้ ต้องเปลี่ยนวิธีการทำงานในขั้นพื้นฐานพอสมควร เพราะที่ผ่านมาคุณอาจจะ design database เพื่อให้ cover ทุก feature แต่แนวทางแบบนี้จะออกแบบเฉพาะเท่าที่จำเป็นสำหรับ feature ที่เราเลือกมาทำใน 2-3 สัปดาก์นั้นเท่านั้น แน่นอนว่าการออกแบบจะต้องรู้ว่าต่อไปต้องมีอะไรมาเสริม มันต้องคิดเผื่ออยู่แล้ว แต่เมื่อลงมือทำจริงก็ทำเฉพาะงานตรงหน้าก่อน table อะไรที่ไม่เกี่ยวก็อย่าเพิ่งออกแบบ เพราะ Agile ไม่เชื่อว่าการออกแบบครั้งเดียวเสร็จมันจะสมบูรณ์จริง สุดท้ายก็ต้องแก้อยู่ดี แล้วจะออกแบบให้เสร็จไปทำไมกัน (คำๆ นี้ฝรั่งจะเรียกว่า design up-front ครับ)

ในแง่ของการเขียน code ก็เปลี่ยนไป เพราะเมื่อมีการต่อยอดงานเดิม แน่นอนมันก็ต้องมีการกลับมาแก้งานเก่าบ้างไม่มากก็น้อย มันต้องมีอะไรบางอย่างมาตรวจสอบได้ว่าอะไรที่เคย work อยู่แล้ว มันจะยังคง work เหมือนเดิมหรือไม่ สิ่งที่จะช่วย programmer ได้มากเลยก็คือ การเขียน unit test หรือการเขียน code เพื่อ test code นั่นแหละครับ ถ้ามี unit test ครอบ code ของเราเอาไว้แล้วเกิดมีการแก้ไข code เดิมแล้วมีปัญหาขึ้นมา พอเรา run unit test ซ้ำมันจะเกิด error เราก็จะรู้ได้ทันทีว่า code จุดนั้นมีปัญหา ทำให้แก้ได้ถูกจุดอย่างรวดเร็ว

ผมคิดว่าคนที่เข้ามาอ่าน web นี้ ส่วนใหญ่น่าจะเป็น programmer Delphi กัน ผมบอกได้เลยว่า แนวทางการพัฒนาซอฟท์แวร์ด้วย Delphi นั้น ไปกันไม่ได้กับ Unit Test เพราะ style การพัฒนาด้วย Delphi คืออาศัย component ล้วนๆ น้อยมากที่จะมีใครเขียน code โดยไม่ได้ใช้การลาก component มาปะบน form (ลองนึกถึงการ connect database มีใครเขียน db := dbConnection.Create(self); เองบ้าง แล้วมันก็ไม่ผิดด้วย เพราะแนวทางของการพัฒนาด้วย Delphi ถูกวางมาแบบนั้น) เมื่อ code ทั้งหมดมันกลืนกันไปกับ UIและ component แล้ว เราจะไม่สามารถเขียน unit test ได้เลย เพราะมันกลายเป็นเนื้อเดียวกันไปแล้วนั่นเอง unit test จึงเหมาะกับการเขียนโปรแกรมที่ไม่ต้องพึ่ง wizard มากนัก เน้น coding และเขียน code แยก layer ของ application ได้ง่ายๆ อย่างเช่นพวก .net หรือ Java นั่นเอง

แต่ไม่ต้องกังวลว่าไม่ทำ unit test แล้วจะเอา Agile ไปใช้ไม่ได้ มันไม่จำเป็นขนาดนั้นครับ เพราะ unit test เป็นเทคนิคนึงเท่านั้น ไม่ได้เป็นจิ๊กซอว์สำคัญในหลักการของ Agile ซะหน่อย จริงไหมครับ ^^

4. Business people and developers must work together daily throughout the project.

ข้อนี้เป็นอีก 1 ข้อที่สำคัญเช่นกัน คนที่อยู่ฝั่ง business อาจจะเป็นลูกค้า หรือ user ก็แล้วแต่ จะต้อง “ทำงานด้วยกันเป็นทีมเดียว” กับทีมพัฒนา “ทุกวัน” ตลอดช่วงของการพัฒนา

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

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

บางคนบอกว่าเป็นไปไม่ได้หรอกที่ลูกค้าจะมานั่งกับคุณที่ office คุณตลอดเวลา เค้าก็ต้องทำงานเค้า ก็จริงครับ แต่ถ้าเป็นไปได้ ควรจะ assign ใครซักคนทำหน้าที่เป็นตัวแทนของลูกค้ามาทำงานร่วมทีมกับเรา ถือว่าเป็นสมาชิกในทีมนะครับ ซึ่งอาจจะไม่ต้องมานั่งกับเราก็ได้ แต่คนๆ นั้นต้องรู้นะว่า “หน้าที่” ของเค้าคือ จะต้องว่างให้ถามตลอดเวลาทำงาน และถือเป็น priority สูงสุด อะไรที่เค้าตอบไม่ได้ เค้าก็จะต้องรู้ว่าจะต้องไปถามกับใคร เป็นต้น คือเป็นตัวแทนของ user เลย เพราะจากตัวอย่างข้างต้นก็เห็นได้ขัดเจนอยู่แล้ว ซึ่งแน่นอนว่าจะต้องได้รับความร่วมมือจากลูกค้าด้วย เราก็ต้องย้ำให้ลูกค้าเข้าใจว่า เราที่เป็นนักพัฒนาให้ความสำคัญกับงานมาก ทางลูกค้าเองก็ต้องให้ความสำคัญเช่นกัน เพราะถ้างานล่าช้าออกไปมันก็กระทบกับทุกฝ่ายครับ ไม่ใช่เฉพาะกับเราที่เป็นนักพัฒนา และที่สำคัญ คนๆ นี้จะเป็นคนที่รู้ว่าเราทำอะไรอยู่ เรากำลังมีปัญหาอะไร อะไรเป็นอุปสรรคของทีมในการทำงานด้วย นั่นหมายความว่า เค้าจะเป็นคนที่ช่วยทำให้คำพูดของทีมมีน้ำหนักมากขึ้นเมื่อทีมพัฒนาไปคุยกับลูกค้าในทุกๆ เรื่องครับ (… ยังไงก็เลือกให้ดีๆ นะครับ ^^)

ตอนต่อไป

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

ตอนนี้ผมรีบลงให้อ่านก่อนเพราะงานเริ่มจะรัดตัวอีกแล้ว เดี๋ยวจะทิ้งช่วงนานไป มีอะไรผิดพลาดก็ช่วยแจ้งด้วยนะครับ ตรงไหนอ่านไม่รู้เรื่องก็บอกครับ (ไป post ใน forum ก็ได้ ผมตามอ่านอยู่) ในตอนต่อไปก็ยังคงเป็นเรื่องของ principle อยู่ ยังมีอีก 8 ข้อครับ ไม่จบง่ายๆ แล้วจะรีบมาลงต่อให้อ่านกัน มีคำถามอะไรก็ post ทิ้งไว้ได้ครับ