โค้งสุดท้าย ก่อนจะมีงานอไจล์แห่งประเทศไทย ปี 2014 ในวันเสาร์อาทิตย์ 7-8 มิ.ย. 2014 นี้ เผื่อใครยังไม่อินกับรูปแบบของ open space อ่านที่เกลี้ยกล่อมกันมาหลายกระทู้แล้วยังงง สรุปสั้นๆ ให้เลยคือว่า
staff ทั้งหมดที่จะใส่เห็นเสื้อสีดำในวันงาน หน้าที่เป็นเบ้เฉยๆ เอาไว้ จัดโต๊ะ เตรียมสถาณที่ แจกเสื้อ และซื้อข้าวกลางวัน ขนม น้ำ มาให้ทุกคนกินเท่านั้น
ที่มารูป : http://newtechusa.net/agile/agile-and-open-space/
งาน Agile Thailand 2014 นี้ ทีมงานเราลุยเต็มที่ ตั้งใจจะจัดเป็นแบบ Open Space อย่างอบอุ่น หลังจากเริ่มๆ ไปโพสสื่อข่าวเรื่อยๆ พบว่า คนไม่รู้เรื่องเลยครับว่ามันเป็นคืออะไร (แป่วว) เอาล่ะ ตั๋วก็ยังไม่เริ่มขาย แต่อยากขอเคลียร์กันเลยทีเดียว Continue reading “มางาน Open Space แบบ ATH2014 ต้องทำตัวยังไงบ้าง?”
ช่วงนี้ก็ใกล้งาน Agile (Open) Thailand 2014 เข้ามาเต็มที่แล้ว ก็เลยเอาโน้ตเก่าๆ ลายมือไก่เขี่ย อ่านรู้เรื่องบ้างไม่รู้เรื่องบ้าง ที่เคยไปในงาน Agile Open Northwest มาอ่านดู ก็มาสะดุดกับที่ประโยคนี้พอดีครับ Diana Larsen พูดกับทุกคนในงานว่า คำขวัญของการจัดงานสัมนาแบบ open space เนื่ยคือ “Always look for one less thing to do” Continue reading “Always look for one less thing to do”
หลังจากไปงาน Agile Open Northwest ผมเพิ่งได้ไปทำสิ่งที่อยากจะลองทำมานานแล้ว คือ ไปลองจับคู่คนที่ไม่ค่อยเก่งเรื่อง pair (ผมเอง) กับคนที่เก่งเรื่อง pair มาเจอกัน แล้วก็จับคู่มาสอนวิธี pair กันจะได้เก่งกันมากขึ้นๆ
ผมโชคดี ในฐานะที่เป็นคนเริ่มเสนอ ก็ไปเจอเอาระดับตัวจริงเลย คือ พวกนี้ทำอไจล์มาเป็นสิบ ปีแล้ว ประมาณว่ารับการถ่ายทอดพลังมาโดยตรงจากพวกที่เซ็นต์ Agile Manifesto อ่ะครับ คือ พลังมันแน่นมากๆ เค้าก็ยิ้มๆ พยักหน้า แล้วบอกว่า “มาเจอกันได้”
ผมคาดหวังไว้ว่าจะต้องเจอกับคนที่เก่งโค้ดมากๆ (อ้าวเขียนเป็นสิบปีอ่ะ ต้องเก่งสิ)
แต่ในความเป็นจริงคือ เค้าเก่งโค้ดมากๆๆๆๆๆ (x5 เข้าไปจาก expectation)
แต่ที่ผมตกใจที่สุดคือ เค้ามีทักษะเรื่องการสื่อสาร ความเข้าใจ การสังเกต การสอน ที่ล้ำหน้ากว่าทุกอย่างและทุกคนที่ผมเคยเห็น ผมติด งง มึน ตรงไหน เค้าก็จะหยุดให้คุยกัน แล้วก็ให้ทดลองแก้ไขทันที (บางทีก็รู้ล่วงหน้าด้วยว่าต่อไปจะไป งง หรือ ติด ต่อตรงไหน @_@)
สลับกันไปมา สุดท้ายหลังจากที่แพร์กันแล้ว โค้ดผมสะอาด เข้าใจง่าย เทสครอบคลุม และแบ่งเป็นส่วนๆ แบบไม่คิดว่าจะเคยเห็นผลงานตัวเองเป็นแบบนี้มาก่อน (ปกติผมภูมิใจว่าโค้ดตัวเองสวยพอสมควรนะ) รวมถึงได้เข้าใจ TDD ลึกซึ้งขึ้นไปอีก
ทั้งหมดเรียนรู้ผ่านการทำงานสั้นๆ ใน 30 นาทีนี้เอง
Pair กันจบ ก็มีเรโทรกันนิดหน่อย ผมยิงไปคำถามเดียวเลยครับ
“ทำอย่างไรผมจะเก่งได้แบบนี้บ้าง” T_T
ความรู้สึกตอนนั้นมันอธิบายยากหน่อยนะ มันเหมือนโลกที่มีอยู่มันเปลี่ยนไปเลยอ่ะ มันขยายขึ้น มันกว้างขึ้น สิ่งที่เราเคยเข้าใจว่ามันเป็นไปไม่ได้ ไม่เคยมีอยู่ คือ มันเป็นไปได้ และ มันมีอยู่จริง ผมเข้าใจ (ไปเอง) มาตลอดว่า เทพ มันต้องมี เก่งเรื่องคน การจัดการ กับ เก่งเรื่องโค้ด แยกกัน แต่นี่มันเทพทุกอย่างจริงๆ นะ แบบไม่เคยเห็นมาก่อนอ่ะครับ
คำตอบที่ได้คือ เค้า
เป็นสิบปี
ผมเลยเข้าใจในทันทีเลยว่า ในระหว่างที่คนอื่นเน้นพัฒนาทักษะของการเขียนโปรแกรมอยู่เป็นหลักด้านเดียว เขาพัฒนาการเขียนโปรแกรมไปพร้อมกับการเรียนรู้การสื่อสารอย่างทะลุประโปร่งกับคนอื่น ไปพร้อมๆ กันเป็นสิบปี
จากนี้ไป ผมคงจะไม่เถียงกับใครแล้วนะ ว่า pair มันดี หรือ pair มันไม่ดียังไง ใครอยากทำให้มาทำด้วยกัน ใครไม่อยากทำก็แล้วแต่ครับ
ส่วนผมคงต้องไปย่อย ทบทวนซักต่อซักหน่อยว่ารายละเอียดต่อซักหน่อยว่าเกิดอะไรขึ้นตอนนั้น
(เครดิตรูป : toonpool.com, bit.ly/LgHXSt)
ช่วงนี้ Agile66 ก็กลับมาทุ่มเถียงกันกับปัญหาคลาสสิก เรื่อง ลูกน้องไม่ยอมพูดแสดงความคิดเห็นกับหัวหน้า (อีกแล้ว) เรื่องมันก็เดิมๆ คำตอบมันก็คล้ายๆ เดิม ไปๆ มาๆก็ลากไปถึงว่าจะทำอย่างไรให้เขาเถียงกับเรามากขึ้น?
ผมก็งงว่าเราทำไมต้องหวังให้ลูกน้องมาเถียงกับเรานะ จริงๆ เค้าไม่ควรจะต้องมาเถียงกับเราด้วยซ้ำ วิธีทำพูดง่าย แต่เหมือนหลายคนจะบอกว่าทำยากมากเลย นั่นก็คือ
“ก็อย่าไปเถียงกับเขาสิ”
ลูกน้องที่รักอยากได้อะไร ต้องเชื่อฟัง เคารพ และแสดงความเห็นต่างกับลูกน้องอย่างสุภาพ นะครับ
Continue reading “จะหวังให้แขนกับขา self-managed ได้อย่างไร?”
(เครดิตรูป : คลังภาพ Agile66)
ต่อจากอันที่แล้วที่พูดถึงภาพรวมของงาน คราวนี้มาคุยกันเรื่องของการทำงานของคณะจัดงาน ATH2014 บ้าง
ลุงๆ ป้าๆ ที่จัดงานอไจล์กันทุกปี ก็มีเรื่องกลุ้มใจอยู่อย่างเปิดเผย แต่อาจจะไม่เคยบอกออกมาตรงๆ ก็คือ เราอยากให้คนหน้าใหม่เป็นกำลังหลักครับ คือ ไม่ใช่แค่รอตามคำสั่ง หรือ ไม่ใช่คอยเป็นกำลังสนับสนุนยกของ ลงมติความเห็นอย่างเดียว
แต่อยากให้เป็นผู้กำหนดทิศทางหลักของงานอไจล์ต่อไปเรื่อยๆ
ทั้งนี้จะทำแบบนี้ได้ ผมคิดว่าต้องมีสิ่งเหล่านี้เป็นอย่างน้อยนะ
อันนี้ก็ไม่ใช่หลักการประหลาดอะไร ทีมอไจล์หลายๆ ทีมก็รู้อยู่แล้วว่าอยากจะให้เกิดการบริหารจัดการเองได้ ก็ต้องสร้างสภาพแวดล้อมที่เรารู้สึกปลอดภัย รู้สึกว่าถ้าพลาดไปมันก็ไม่ใช่เรื่องใหญ่ เรียนรู้กันได้ ปรับกันใหม่ได้เรื่อยๆ
ผมคิดว่าจะทำให้เกิดตรงนี้ได้ ผมอยากให้สร้างสภาพแวดล้อมว่างาน ATH เป็น “งานของเรา” จัดในบ้านของเรา เราไม่ต้องไปเชิญแขกใหญ่โต ประธาน คนดัง มาเปิดงาน เราไม่ต้องทำยอดขายตั๋วไม่ต้องมีการไปรับปากว่าในงานนี้ มันต้องมีอะไรหรือไม่มีอะไร และไม่ต้องสนใจว่าเคยทำอะไรมาอย่างไร
ทั้งหมดเพื่อให้หน้าใหม่ (ทั้งพี่และน้อง) เล่นได้เต็มที่ ทดลองได้เต็มที่ว่าจะทำอะไรยังไง โดยไม่ต้องไปกลัวผลกระทบภาพลักษณ์ เพราะเป็น “งานของเรา” เราจัดกันเอง ครับ
ส่วนรุ่นพี่ๆ มีไว้คอยรับใช้ปรึกษา และก็อปของที่มันใช้งานได้ดีไปไว้ในงานอื่นๆ 🙂 เรื่องทางการ ใส่สูทเก็บไว้ตอน Agile Tour
ลักษณะของคนที่เข้ามาช่วยจัดงานอไจล์ทุกปี ไม่ใช่คนที่ถูกขับดันด้วยปัจจัยภายนอก เช่น เงินตอบแทน(ไม่มีให้) หรือ การได้เข้างานฟรี แต่เข้ามาเพราะอยากเรียนรู้สิ่งใหม่ๆ ทำให้ตัวเองมีประสบการณ์มากขึ้น และเติบโตขึ้นซะมากกว่า
อย่างที่บอก เรามีคำขวัญอย่างไม่เป็นทางการของงานว่าเรา “ใช้อไจล์จัดงานอไจล์” ซึ่งก็ดูเป็นที่ดึงดูดรุ่นใหม่ๆ มาได้เรื่อยๆ โดยเฉพาะคนที่ไม่เคยทำอไจล์มาก่อนก็จะได้มาทำกันจริงๆ อันนี้ผมคิดเองว่าเป็นจุดที่น่าจะเก็บไว้
นอกจากนี้ก็อยากทำให้คนจัดได้เกิดความภูมิใจในสิ่งที่ตัวเองทำ เก็บไว้เป็นที่ระลึกตลอดไป ซึ่งอาจจะเป็นสิ่งของเล็กน้อย เช่น เสื้อสตาฟ หรือ การเจาะลึกให้เห็นเบื้องหลังการทำงานของคณะทำงาน ที่ทำให้คนมางานเห็นว่า กว่าจะเป็นงานอไจล์แต่ละปีได้ คณะทำงานต้องฝ่าฟันอะไรบ้าง และสุดท้ายได้เรียนรู้อะไรกันบ้าง
สรุปแล้วงานนี้อยากให้คนรุ่นใหม่ เข้ามาเล่นสนุกกับการออกแบบงานและจัดงานได้เต็มที่ ไม่ต้องสนว่างานอื่นเค้ามีอะไรหรือเคยทำอะไรมา เพราะเป็นงานของเรา ไม่ใช่งานที่ต้องเอาใจใคร และรางวัลของการทำงานนี้จะมาจากการที่ได้ประสบการณ์มากขึ้น เติบโตขึ้น และได้ทดลองสิ่งต่างๆ อย่างเป็นอิสระ
ผมมั่นใจว่าถ้าจะทำให้ autonomy เกิด มันต้องมาพร้อมกับ authorithy ครับ
ผมขอเป็นคนแรกที่จะปล่อยอำนาจนี้ให้อยู่ในมือของคนรุ่นใหม่ที่จะมาช่วยกันทำ และมั่นใจว่ารุ่นเก่าคนอื่นๆ คงคิดเหมือนกัน
ส่วนพวกคุณปู่ๆ ก็มีหน้าที่คอยเป็น คนรับใช้ และ ที่ปรึกษา เป็นหลัก 🙂
มาถึงเดือนมกราคม เราก็เริ่มคุยกันเรื่องจัดงาน Agile Thailand 2014 (เรียกกันว่า ATH2014 แล้วกันนะ) ก็เลยอยากจะคุยกันหน่อยว่าอยากให้งานนี้เป็นยังไงบ้าง และผมก็มีความฝันส่วนตัวเกี่ยวกับงานนี้ในอนาคต
แต่เนื่องการจัดงานนี้ทั้งหมดเป็น self-managed ตั้งแต่ต้นจนจบ (เราภูมิใจมากกับสโกแกนไม่เป็นทางการว่า ใช้อไจล์จัดงานอไจล์) ดังนั้นเลยไม่มีหัวหน้างาน นายใหญ่ หรือ ท่านผู้นำอะไรทั้งนั้น ในฐานะคนที่เริ่มจัดงานของ Agile66 มาตั้งแต่งานแรกจนถึงงานนี้ ถึงจะแม้ว่าผมนับเป็น “รุ่นเก่า” ก็ไม่สามารถกำหนดเด็ดขาดถึงรูปแบบของงานนี้ได้ ขึ้นอยู่กับทีมทั้งหมดว่าจะตัดสินใจให้มันเป็นอย่างไรต่อไป แต่ผมมีข้อเสนอครับ
และนี่คือข้อเสนอของงาน Agile Thailand 2014, #ATH2014 ในฝันของผม
Identity ชัดเจน
สิ่งที่น่าดีใจคือปีๆ หนึ่งเราช่วยจัดงานหลักอย่างน้อยๆ สามงานด้วยกัน อันนี้แบบที่ช่วยจัดเป็นทางการเลยนะ ไม่นับอันที่ไปแจม ไปป่วน
สิ่งที่ผมฝันไว้คือ อยากให้แต่ละงานของเรา มีเอกลักษณ์ของตัวเอง มากกว่า เป็นแค่งาน copy-paste รูปแบบต่อๆกันมา มากกว่าเป็นแค่งานมานั่งฟังให้เกิดแรงบันดาลใจกันปีละสามครั้ง
ผมอยากให้เก็บงาน Agile Tour และ TPSE มันเป็นคงรูปแบบของงานที่เป็นอารมณ์ของงานอินเตอร์ หรูหรา ธุรกิจ ทางการ เข้าถึงคนจำนวนมาก เสริมสร้างแรงบันดาลใจ อันนี้ผมว่าดีแล้ว และควรทำอย่างนี้ต่อไป
แต่ผมอยากให้ Agile Thailand เป็นงานแห่งความอบอุ่น ความสนุกสนาน และการแลกเปลี่ยนความรู้อย่างไม่มีขีดจำกัดครับ
Open Space
ขอเสนอให้จัดงานนี้เป็น open space เต็มตัว
ผมไปเจอรูปแบบงานนี้ครั้งแรกตอนงาน Agile Open Northwest 2012 ที่ Seattle ครับ ลักษณะของงานจะง่ายจนน่าตกใจ คือ เราไม่กำหนดไว้ก่อนเลยครับว่าจะมีใครมาพูดเรื่องอะไรล่วงหน้า แต่กำหนดห้องเปล่าๆไว้หลายๆ ห้อง เป็น slot ห้องละประมาณ 30 คน
แล้วถึงวันงาน ก็ให้คนออกมาประกาศกันว่าอยากจะพูดเรื่องอะไร แล้วก็เอากระดาษไปแปะใน slot ที่กำหนด แล้วคนที่เหลือก็เข้าไปดูว่าอยากจะไปทำอะไรเมื่อไหร่
ผมเรียกเองว่า มันเป็นตลาดนัดของการแลกเปลี่ยนความรู้ความเข้าใจของเรื่องอไจล์ ครับ
ทำไมต้อง open space?
เพราะมันทำให้เกิดอะไรหลายๆ อย่างที่งานอื่นไม่มี จากงาน Agile Open Northwest สิ่งเหล่านี้เป็นของที่ผมเห็นว่ามันเกิดขึ้นเองโดยธรรมชาติไม่ต้องมีใครมากำหนดบอกล่วงหน้า
งานแบบนี้เปลี่ยนให้งานประชุมเป็นของทุกคน ไม่ยึดติดกับรูปแบบแค่ผู้พูด-ผู้ฟัง คุณอยากฟังอะไร คุณอยากพูดอะไร คุณอยากให้มีอะไร คุณมีสิทธิและอำนาจทั้งหมดที่จะทำให้มันเป็นงานอย่างที่คุณอยากให้มันเเป็น
จงทำให้มันเกิดขึ้น
ความอบอุ่น และ open space
ผมขอมั่วเข้าข้างตัวเองว่า งาน Agile Thailand 2012 เป็นงานอไจล์ที่อบอุ่นที่สุดในโลก
มันเป็นงานครั้งแรกของเรา ที่เราเริ่มจากอะไรง่ายๆ จากทุกอย่างที่มีอยู่ ไม่ต้องมีอะไรมากมาย ไม่ต้องคิดถึงแขกบ้านแขกเมือง เชิญคนนั้นคนนี้ หรือต้องมีประชาสัมพันธ์ยิ่งใหญ่ ถึงแม้ว่ารูปแบบเป็นงานประชุมปกติ มีคนพูด-คนฟัง มีแต่พวกเรากันเองมานั่งพูดคุยเล่าเรื่องกันให้ฟัง มันให้อารมณ์เหมือนนั่งกินข้าวคุยกัน แล้วก็เจรจาถกเถียงกัน
มันอาจจะเข้าใจยาก และอธิบายยาก แต่ผมเรียกปัจจัยที่จับต้องไม่ได้นี้ว่า ความอบอุ่น นะ และไม่ว่างาน ATH จะโตขึ้นเท่าไหร่ หรือ จะเป็นอย่างไร ก็อยากให้เก็บสิ่งเหล่านี้ไว้
และถ้างานนี้เป็น open space ผมคิดว่าเราตอบโจทย์นี้ได้ ด้วยรูปแบบที่เราเอื้อให้ทุกคน ถอดยศ ตัวเองเก็บไว้ที่บ้านครับ ที่ทำงานเคยเป็นใครใหญ่แค่ไหน มางานนี้กลายเป็นผู้ร่วมงานคนหนึ่ง เหมือนกับทุกๆ คน อยากรู้ อยากถาม อยากแบ่งปันอะไร อยากให้มีอะไร ทำให้โดยไม่ต้องกลัวครับ ทุกคนมีสิทธิจะพูดและทำเหมือนกัน เวทีไม่ใช่เป็นแค่ของคนไม่กี่คนที่กำหนดไว้
นั่งล้อมวงกัน แล้วจัดมาได้เลย
ปล. ใครไม่เชื่อว่าความอบอุ่นมีจริงลองไปดูใน อัลบั้มรูปงาน Agile Thailand 2012 ได้
Success Criteria
งานนี้จะสำเร็จยิ่งใหญ่มากน้อยแค่ไหน ผมคิดว่ามีตัวชี้วัดหลักที่จะถามจากคนเข้างาน แค่สามข้อเอง
สรุปนะ
ผมฝันว่า Agile Thailand จะเป็นตลาดนัดของความรู้เรื่องอไจล์ครับ ของคนที่มีความรู้ และคนที่อยากจะรู้ มาแลกเปลี่ยนพูดคุยกันอย่างอบอุ่นเป็นกันเองอย่างไม่มีขีดจำกัด
#ATH2014 #openspace #ตลาดนัดความรู้ #อบอุ่น #กันเอง #คุณกำหนดได้
References
เครดิตรูปขอบคุณช่างภาพทุกคนที่อัพโหลดเข้าคลังรูปของ Agile66 ครับ
มีอะไรเพิ่มเติม เสนอแนะ ติชม หรือ สงสัยอะไรเป็นพิเศษอยากให้ขยาย บอกมาในคอมเมนท์ได้เลยครับ
(ที่มารูป: http://io9.com/5758541/no-one-can-escape-friction-not-even-in-a-vacuum)
ใครเคยเรียนฟิสิกส์แล้วจำได้ มันจะมีเรื่องของ แรงเสียดทาน ภาษาอังกฤษเค้าเรียกว่า friction ที่เราเรียนมามันจะมี friction สองอย่าง คือ static friction กับ kinetic friction ถ้าใครต้องเข็นของหนักๆ คงจะเข้าใจเรื่องนี้ดี
ตอนแรกเราเริ่มเข็นของ ก็ใช้พลังงานไปเยอะมาก ต้องออกแรงดันเยอะๆ มากๆๆ แต่พอมันเริ่มเคลื่อนที่ไปได้ จะเข็นไปต่อก็เป็นเรื่องง่ายๆ ออกแรงไม่เยอะเท่าตอนแรก
ไม่รู้ว่ามันเกี่ยวยังไง แต่ผมว่ามันเหมือนกับเราตอนเริ่มทำงานอะไรซักอย่างเลย โดยเฉพาะของที่เราไม่ชอบ เบื่อ ไม่อยากทำ เราก็พยายามจะผลัดมันไปเรื่อยๆ กว่าจะเข็นตัวเองให้ทำได้ มันเป็นเรื่องที่นานมาก เช่น คนที่ไม่ชอบออกกำลังกาย ก็จะหาเหตผล จะไม่ไปยิมอยู่เรื่อย หรือ คนที่ไม่ชอบทำความสะอาดห้อง ก็จะผลัดไปเรื่อยๆ เป็นขั้นหนักขึ้นก็คือ พยายามหาอย่างอื่นที่เราชอบมากว่ามาทำก่อน แล้วบอกว่าเรายุ่ง ไม่มีเวลา
สุดท้าย ก็คือ เราไม่สามารถทำลาย แรงเสียดทานเริ่มแรก นี้ได้ กลายเป็นสิ่งที่เราเรียกว่า ผัดวันประกันพรุ่งนี่เอง
แต่พอวันหนึ่งเราเกิดมีอารมณ์ลุกขึ้นมาทำปุ๊บ พอเริ่มไปได้ซักพัก มันก็กลับไปได้เรื่อยๆ ของที่ดูยาก พอเริ่มลงมือทำ มันก็ไม่ได้ยากอย่างที่เราคิดหรือจินตนาการไว้เลย
วิธีทำลายแรงเสียดทาน มีหลายวิธี หลายเทคนิค วันนี้เอาอันที่ง่ายที่สุดมาเขียนก่อนแล้วกัน
หนึ่งในนั้นคือ การบอกตัวเองว่า ทำแค่ 5 นาทีก็พอ
แล้วถ้ามันเพลินจนทำไปนานกว่านั้น ก็ปล่อยมันไปตามความสนุกของเรา ตามแรงเสียดทานที่ลดลงตามมา
อยู่ดีๆ ก็อยากจะเขียนเรื่องนี้ มาลองดูกันว่ามันเกี่ยวกับอไจล์มั๊ย ยังไง
Continue reading “Learning is not linear”
คนที่เคยอ่านๆ เกี่ยวกับอไจล์ โดยเฉพาะเกี่ยวกับเรื่องแถวๆ Continuous Integration คงจะเคยได้ยินประโยคข้างต้นมาบ้าง ผมก็ไม่แน่ใจเหมือนกันว่าใครเป็นคนพูดคนแรก พยายามไปหาก็ยังไม่มีบอกเหมือนกันว่าเป็นใคร แต่เป็นหลักการที่เป็นหมัดเด็ดของอไจล์ (แต่ไม่ค่อยมีคนแถวนี้พูดถึงเลยแฮะ) มันคือ
If it is painful, do it more often
– ถ้าอะไรมันเจ็บปวด ก็ทำมันบ่อยๆ –
ไม่ได้แปลว่าให้เป็นพวกชอบความเจ็บปวด ย้ำๆลงไปจุดที่เจ็บๆ จะได้ทรมานแล้วดิ้นรนหาวิธีมาแก้ไขนะ (มีคนแปลอย่างนั้นจริงๆ นะ แล้วแบบไปไกลเลย)
เค้าแปลว่า อะไรที่มันเป็นสิ่งที่เราจะไม่อยากทำน่ะ สัญชาติญาณความขี้เกียจของเราก็มันจะพยายามปัดๆ ไปค่อยแก้ๆ กันวันหลังใช่มั๊ย เราทุกคนก็คงอยากทำอะไรที่สนุก อะไรที่มันไม่สนุกก็หมักๆ กองๆ มันไว้ทำเป็นไม่เห็นก็ได้
ทีนี้โค้ดรกมันก็ไม่เหมือนห้องรกน่ะสิ มันมองไม่ค่อยเห็นว่ามันรกยังไง รู้ตัวอีกทีก็ตอนที่เราต้องไปนั่งไล่หาบั๊กอยู่เป็นวันๆ แล้วก็บ่นกันว่าใครเขียนโค้ดแถบส่วนนี้ขึ้นมา (วะ) แล้วทำไมตอนแรกไม่ทำให้มันดีๆ (วะ) จะมาเก็บกวาดตอนนี้ก็รกเหลือทนต้องเสียเวลาแก้ไขไปนานเลย แทนที่จะเสียเวลาค่อยๆทำทีละนิดๆ
สรุปคือ อะไรที่ไม่ชอบทำให้ “ทำบ่อยๆ มันจะได้ไม่สะสม” เป็นชุดใหญ่
ใครเข้าใจอันนี้ได้ ก็จะเข้าใจอไจล์ไปได้เยอะเลยครับ เพราะอไจล์เป็นเรื่องของการเก็บ feedback และปรับปรุงตัวเองบ่อยๆ
ยิ่งทำบ่อย ก็ยิ่งเห็นข้อผิดพลาดได้เร็ว ข้อแก้ไขก็มีทีละนิด แทนที่จะสะสมมาเยอะๆ
ลองมองดูมันมีอยู่เต็มไปหมด ทั้งด้าน management และ technical
สุดท้าย .. แถม …”merge นรก กลุ้มใจ” – ก็กองโค้ดที่ไม่ได้รวมกับคนอื่นเค้า (branch / uncommitted code) เอาไว้เยอะๆ เองนิ –> merge มันบ่อยๆ merge มันทุกลมหายใจ จนกลายเป็น (Trunk Development) เลยก็ได้
