Agile Thailand 2014 เป็นของทุกคน

 

โค้งสุดท้าย ก่อนจะมีงานอไจล์แห่งประเทศไทย ปี 2014 ในวันเสาร์อาทิตย์ 7-8 มิ.ย. 2014 นี้ เผื่อใครยังไม่อินกับรูปแบบของ open space อ่านที่เกลี้ยกล่อมกันมาหลายกระทู้แล้วยังงง สรุปสั้นๆ ให้เลยคือว่า

“งาน Agile Thailand 2014 เป็นของทุกคน”

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

Continue reading “Agile Thailand 2014 เป็นของทุกคน”

มางาน Open Space แบบ ATH2014 ต้องทำตัวยังไงบ้าง?

OpenSpace01

ที่มารูป : http://newtechusa.net/agile/agile-and-open-space/

งาน Agile Thailand 2014 นี้ ทีมงานเราลุยเต็มที่ ตั้งใจจะจัดเป็นแบบ Open Space อย่างอบอุ่น หลังจากเริ่มๆ ไปโพสสื่อข่าวเรื่อยๆ พบว่า คนไม่รู้เรื่องเลยครับว่ามันเป็นคืออะไร (แป่วว) เอาล่ะ ตั๋วก็ยังไม่เริ่มขาย แต่อยากขอเคลียร์กันเลยทีเดียว Continue reading “มางาน Open Space แบบ ATH2014 ต้องทำตัวยังไงบ้าง?”

Always look for one less thing to do

1780352_10152264722918690_1862834444_o

ช่วงนี้ก็ใกล้งาน 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”

Pairing is Caring

หลังจากไปงาน Agile Open Northwest ผมเพิ่งได้ไปทำสิ่งที่อยากจะลองทำมานานแล้ว คือ ไปลองจับคู่คนที่ไม่ค่อยเก่งเรื่อง pair (ผมเอง) กับคนที่เก่งเรื่อง pair มาเจอกัน แล้วก็จับคู่มาสอนวิธี pair กันจะได้เก่งกันมากขึ้นๆ

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

ความคาดหวังกับความเป็นจริง

ผมคาดหวังไว้ว่าจะต้องเจอกับคนที่เก่งโค้ดมากๆ (อ้าวเขียนเป็นสิบปีอ่ะ ต้องเก่งสิ)

แต่ในความเป็นจริงคือ เค้าเก่งโค้ดมากๆๆๆๆๆ (x5 เข้าไปจาก expectation)

แต่ที่ผมตกใจที่สุดคือ เค้ามีทักษะเรื่องการสื่อสาร ความเข้าใจ การสังเกต การสอน ที่ล้ำหน้ากว่าทุกอย่างและทุกคนที่ผมเคยเห็น ผมติด งง มึน ตรงไหน เค้าก็จะหยุดให้คุยกัน แล้วก็ให้ทดลองแก้ไขทันที (บางทีก็รู้ล่วงหน้าด้วยว่าต่อไปจะไป งง หรือ ติด ต่อตรงไหน @_@)

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

ทั้งหมดเรียนรู้ผ่านการทำงานสั้นๆ ใน 30 นาทีนี้เอง

คำถามเดียว

Pair กันจบ ก็มีเรโทรกันนิดหน่อย ผมยิงไปคำถามเดียวเลยครับ

“ทำอย่างไรผมจะเก่งได้แบบนี้บ้าง” T_T

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

คำตอบเดียว

คำตอบที่ได้คือ เค้า

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

เป็นสิบปี

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

สรุป

จากนี้ไป ผมคงจะไม่เถียงกับใครแล้วนะ ว่า pair มันดี หรือ pair มันไม่ดียังไง ใครอยากทำให้มาทำด้วยกัน ใครไม่อยากทำก็แล้วแต่ครับ

ส่วนผมคงต้องไปย่อย ทบทวนซักต่อซักหน่อยว่ารายละเอียดต่อซักหน่อยว่าเกิดอะไรขึ้นตอนนั้น

จะหวังให้แขนกับขา self-managed ได้อย่างไร?

Image

(เครดิตรูป : toonpool.com, bit.ly/LgHXSt)

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

ผมก็งงว่าเราทำไมต้องหวังให้ลูกน้องมาเถียงกับเรานะ จริงๆ เค้าไม่ควรจะต้องมาเถียงกับเราด้วยซ้ำ วิธีทำพูดง่าย แต่เหมือนหลายคนจะบอกว่าทำยากมากเลย นั่นก็คือ

“ก็อย่าไปเถียงกับเขาสิ”

ลูกน้องที่รักอยากได้อะไร ต้องเชื่อฟัง เคารพ และแสดงความเห็นต่างกับลูกน้องอย่างสุภาพ นะครับ

Continue reading “จะหวังให้แขนกับขา self-managed ได้อย่างไร?”

Agile Thailand 2014 ในความฝัน (ตอนที่ 2: การจัดงาน)

545471_10150863433892371_540003832_n

(เครดิตรูป : คลังภาพ Agile66)

ต่อจากอันที่แล้วที่พูดถึงภาพรวมของงาน คราวนี้มาคุยกันเรื่องของการทำงานของคณะจัดงาน ATH2014 บ้าง

ทำให้หน้าใหม่เป็นกำลังหลัก

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

แต่อยากให้เป็นผู้กำหนดทิศทางหลักของงานอไจล์ต่อไปเรื่อยๆ

ทั้งนี้จะทำแบบนี้ได้ ผมคิดว่าต้องมีสิ่งเหล่านี้เป็นอย่างน้อยนะ

Safe Environment

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

ผมคิดว่าจะทำให้เกิดตรงนี้ได้ ผมอยากให้สร้างสภาพแวดล้อมว่างาน ATH เป็น “งานของเรา” จัดในบ้านของเรา เราไม่ต้องไปเชิญแขกใหญ่โต ประธาน คนดัง มาเปิดงาน เราไม่ต้องทำยอดขายตั๋วไม่ต้องมีการไปรับปากว่าในงานนี้ มันต้องมีอะไรหรือไม่มีอะไร และไม่ต้องสนใจว่าเคยทำอะไรมาอย่างไร

ทั้งหมดเพื่อให้หน้าใหม่ (ทั้งพี่และน้อง)​ เล่นได้เต็มที่ ทดลองได้เต็มที่ว่าจะทำอะไรยังไง โดยไม่ต้องไปกลัวผลกระทบภาพลักษณ์ เพราะเป็น “งานของเรา” เราจัดกันเอง ครับ

ส่วนรุ่นพี่ๆ มีไว้คอยรับใช้ปรึกษา และก็อปของที่มันใช้งานได้ดีไปไว้ในงานอื่นๆ 🙂 เรื่องทางการ ใส่สูทเก็บไว้ตอน Agile Tour

Rewarding Experiences

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

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

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

Innovation > Tradition

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

ผมมั่นใจว่าถ้าจะทำให้ autonomy เกิด มันต้องมาพร้อมกับ authorithy ครับ

ผมขอเป็นคนแรกที่จะปล่อยอำนาจนี้ให้อยู่ในมือของคนรุ่นใหม่ที่จะมาช่วยกันทำ และมั่นใจว่ารุ่นเก่าคนอื่นๆ คงคิดเหมือนกัน

ส่วนพวกคุณปู่ๆ ก็มีหน้าที่คอยเป็น คนรับใช้ และ ที่ปรึกษา เป็นหลัก 🙂

 

Agile Thailand 2014 ในความฝัน (ตอนที่ 1: รูปแบบงาน)

Image

มาถึงเดือนมกราคม เราก็เริ่มคุยกันเรื่องจัดงาน Agile Thailand 2014 (เรียกกันว่า ATH2014 แล้วกันนะ) ก็เลยอยากจะคุยกันหน่อยว่าอยากให้งานนี้เป็นยังไงบ้าง และผมก็มีความฝันส่วนตัวเกี่ยวกับงานนี้ในอนาคต

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

และนี่คือข้อเสนอของงาน Agile Thailand 2014, #ATH2014 ในฝันของผม

Identity ชัดเจน

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

  1. Agile Thailand – อันนี้เริ่มมาจากความอยากปล่อยพลังของทีมงาน Agile66 เอง จัดครั้งแรกปี 2012 อไจล์ล้วนๆ อย่างอื่นไม่เกี่ยว จัดตอนกลางๆปี คนมางานมากขึ้นเรื่อยๆ ค่าเข้าถูกเหมือนจะให้เข้าฟรี
  2. Thailand Practical SE – ริเริ่มโดย อ. จิรพันธ์ เป็นเรื่องของวิศวกรรมซอฟต์แวร์ แบบที่เอาคนที่ทำจริงๆ มาพูดให้ฟัง คีย์โน้ตล่าสุดเป็นผู้บริหารจากศูนย์สำรวจระบบสุริยจักรวาลของ นาซ่า มาพูดให้ฟัง เท่มาก มีทั้งคนอไจล์ ไม่อไจล์ แต่เน้นแบบเอาของที่เคยทำมาแชร์ให้ฟัง ครั้งหน้าคงจะเป็นประมาณเดือน 9
  3. Agile Tour Bangkok – เป็นงานเทศกาลอไจล์ที่จัดพร้อมกันทั่วโลก อันนี้เป็นช่วงปลายปี ประมาณเดือน 12 ข้อดีของการไปร่วมจัดเวลาใกล้ๆ กับประเทศอื่นก็คือ จะมีผู้บรรยายชาวต่างชาติบินมาเยอะมาก ล่าสุดน่าจะเกินครึ่งงาน พูดภาษาอังกฤษกันสนุกสนาน สถาณที่จัดหรูหราอลังการขึ้นเรื่อยๆ เพื่อดึงดูดให้ชาวบ้านเค้าอยากบินมา

สิ่งที่ผมฝันไว้คือ อยากให้แต่ละงานของเรา มีเอกลักษณ์ของตัวเอง มากกว่า เป็นแค่งาน copy-paste รูปแบบต่อๆกันมา มากกว่าเป็นแค่งานมานั่งฟังให้เกิดแรงบันดาลใจกันปีละสามครั้ง

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

แต่ผมอยากให้ Agile Thailand เป็นงานแห่งความอบอุ่น ความสนุกสนาน และการแลกเปลี่ยนความรู้อย่างไม่มีขีดจำกัดครับ

Open Space

Image

ขอเสนอให้จัดงานนี้เป็น open space เต็มตัว

ผมไปเจอรูปแบบงานนี้ครั้งแรกตอนงาน Agile Open Northwest 2012 ที่ Seattle ครับ ลักษณะของงานจะง่ายจนน่าตกใจ คือ เราไม่กำหนดไว้ก่อนเลยครับว่าจะมีใครมาพูดเรื่องอะไรล่วงหน้า แต่กำหนดห้องเปล่าๆไว้หลายๆ ห้อง เป็น slot ห้องละประมาณ 30 คน

แล้วถึงวันงาน ก็ให้คนออกมาประกาศกันว่าอยากจะพูดเรื่องอะไร แล้วก็เอากระดาษไปแปะใน slot ที่กำหนด แล้วคนที่เหลือก็เข้าไปดูว่าอยากจะไปทำอะไรเมื่อไหร่

ผมเรียกเองว่า มันเป็นตลาดนัดของการแลกเปลี่ยนความรู้ความเข้าใจของเรื่องอไจล์ ครับ

ทำไมต้อง open space?

เพราะมันทำให้เกิดอะไรหลายๆ อย่างที่งานอื่นไม่มี จากงาน Agile Open Northwest สิ่งเหล่านี้เป็นของที่ผมเห็นว่ามันเกิดขึ้นเองโดยธรรมชาติไม่ต้องมีใครมากำหนดบอกล่วงหน้า

  • คนที่อยากพูด ไม่ต้องเตรียมล่วงหน้ามากมาย เอา flipchart มาเขียนๆ อธิบายความเข้าใจตัวเอง เหมือนพูดให้เพื่อนฟัง
  • ใครอยากพรีเซนท์แบบเดิมๆ ก็เอา powerpoint มาปิ้งได้ ก็ไปจองห้องที่มันมี projector ซะ
  • คนที่อยากรู้เรื่องอะไรมากๆ (เช่น Agile กับ off-shore ทืม ยังไง) แต่ไม่เห็นมีใครพูด ก็เปิดห้องมา แล้วเรียกคนที่สนใจมาจับกลุ่มคุยกัน
  • ในงานมีคนนึกสนุก เอา session ที่เค้าเข้าไปฟังมาเขียนเป็น mindmap สวยๆ แปะไว้หน้างาน
  • รูปแบบอื่นๆ ก็มีหลากหลายมาก เล่นเกม​ workshop เขียนโค้ดให้ดู ติว tdd กลุ่มใหญ่ ทดลองเล่น pair programming คนมางานจัดกันเองหมด
  • บางคนก็เอาเกมอไจล์มาเล่น ผมได้ไปเล่นเรื่อง dot game ก็จากงานนี้

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

จงทำให้มันเกิดขึ้น

ความอบอุ่น และ open space

Image

ผมขอมั่วเข้าข้างตัวเองว่า งาน Agile Thailand 2012 เป็นงานอไจล์ที่อบอุ่นที่สุดในโลก

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

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

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

นั่งล้อมวงกัน แล้วจัดมาได้เลย

ปล.​ ใครไม่เชื่อว่าความอบอุ่นมีจริงลองไปดูใน อัลบั้มรูปงาน Agile Thailand 2012 ได้

Success Criteria

งานนี้จะสำเร็จยิ่งใหญ่มากน้อยแค่ไหน ผมคิดว่ามีตัวชี้วัดหลักที่จะถามจากคนเข้างาน แค่สามข้อเอง

  • มางานนี้แล้วได้ทำอะไรตรงกับที่อยากจะได้ทำหรือไม่ (1 – 5 ดาว)
  • มางานนี้แล้วได้เรียนรู้อะไรตรงกับที่อยากจะได้เรียนรู้หรือไม่ (1 – 5 ดาว)
  • มางานนี้แล้วรู้สึกอบอุ่นแค่ไหน (1-5 ดาว)

สรุปนะ

ผมฝันว่า Agile Thailand จะเป็นตลาดนัดของความรู้เรื่องอไจล์ครับ ของคนที่มีความรู้ และคนที่อยากจะรู้ มาแลกเปลี่ยนพูดคุยกันอย่างอบอุ่นเป็นกันเองอย่างไม่มีขีดจำกัด

#ATH2014 #openspace #ตลาดนัดความรู้ #อบอุ่น #กันเอง #คุณกำหนดได้

References

เครดิตรูปขอบคุณช่างภาพทุกคนที่อัพโหลดเข้าคลังรูปของ Agile66 ครับ

มีอะไรเพิ่มเติม เสนอแนะ ติชม หรือ สงสัยอะไรเป็นพิเศษอยากให้ขยาย บอกมาในคอมเมนท์ได้เลยครับ

แรงเสียดทาน กับ การทำงาน

ku-xlarge
(ที่มารูป: http://io9.com/5758541/no-one-can-escape-friction-not-even-in-a-vacuum)

ใครเคยเรียนฟิสิกส์แล้วจำได้ มันจะมีเรื่องของ แรงเสียดทาน ภาษาอังกฤษเค้าเรียกว่า friction ที่เราเรียนมามันจะมี friction สองอย่าง คือ static friction กับ kinetic friction ถ้าใครต้องเข็นของหนักๆ คงจะเข้าใจเรื่องนี้ดี

ตอนแรกเราเริ่มเข็นของ ก็ใช้พลังงานไปเยอะมาก ต้องออกแรงดันเยอะๆ มากๆๆ แต่พอมันเริ่มเคลื่อนที่ไปได้ จะเข็นไปต่อก็เป็นเรื่องง่ายๆ ออกแรงไม่เยอะเท่าตอนแรก

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

สุดท้าย ก็คือ เราไม่สามารถทำลาย แรงเสียดทานเริ่มแรก นี้ได้ กลายเป็นสิ่งที่เราเรียกว่า ผัดวันประกันพรุ่งนี่เอง

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

วิธีทำลายแรงเสียดทาน มีหลายวิธี หลายเทคนิค วันนี้เอาอันที่ง่ายที่สุดมาเขียนก่อนแล้วกัน

หนึ่งในนั้นคือ การบอกตัวเองว่า ทำแค่ 5 นาทีก็พอ

  • บอกว่าเก็บห้องแค่ 5 นาที ก็พอ
  • บอกว่าออกไปวิ่ง แค่ 5 นาที ก็พอ
  • วันนี้จัดการโทรไปจัดการธุระ แค่ 5 นาทีก็พอ

แล้วถ้ามันเพลินจนทำไปนานกว่านั้น ก็ปล่อยมันไปตามความสนุกของเรา ตามแรงเสียดทานที่ลดลงตามมา

Agile Secret: If it is painful, do it more often

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

If it is painful, do it more often
– ถ้าอะไรมันเจ็บปวด ก็ทำมันบ่อยๆ –

Not a sadist suggestion!

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

เค้าแปลว่า อะไรที่มันเป็นสิ่งที่เราจะไม่อยากทำน่ะ สัญชาติญาณความขี้เกียจของเราก็มันจะพยายามปัดๆ ไปค่อยแก้ๆ กันวันหลังใช่มั๊ย เราทุกคนก็คงอยากทำอะไรที่สนุก อะไรที่มันไม่สนุกก็หมักๆ กองๆ มันไว้ทำเป็นไม่เห็นก็ได้

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

Do it early, do it often

สรุปคือ อะไรที่ไม่ชอบทำให้ “ทำบ่อยๆ มันจะได้ไม่สะสม” เป็นชุดใหญ่

ใครเข้าใจอันนี้ได้ ก็จะเข้าใจอไจล์ไปได้เยอะเลยครับ เพราะอไจล์เป็นเรื่องของการเก็บ feedback และปรับปรุงตัวเองบ่อยๆ

ยิ่งทำบ่อย ก็ยิ่งเห็นข้อผิดพลาดได้เร็ว ข้อแก้ไขก็มีทีละนิด แทนที่จะสะสมมาเยอะๆ

Do everything more often

ลองมองดูมันมีอยู่เต็มไปหมด ทั้งด้าน management และ technical

  • “ลูกค้าจู้จี้ ตรวจงานทีมีรายการแก้ทีใหญ่ยาว แก้โน่นแก้นี่” –> ก็เอาไปให้เค้าดูบ่อยๆ สิ รายการแก้จะได้มีทีนะนิด (Release Often)
  • “เอาโค้ดมารวมกันที วอดวายไปเป็นวัน” –> Integrate มันทุก commit นะแหละ จะได้รู้ว่าอะไรเป็นต้นเหตุทำให้มันพัง (Continuous Integration)
  • “รีลีสที นอนบริษัทไป 3 วัน” –> ก็ไม่เคยจะซ้อมรีลีสเลยนิ มาทำเอาทีเดียวใกล้ๆ จบ –> ก็ซ้อมรีลีสกันบ่อยๆ สิ ทำมันทุกครั้งที่เช็คอินเลย รีลีสไปที่ UAT environment นี่แหละ (Continuous Deployment)
  • “เทสทีก็พังเป็นแถบ ไม่รู้ว่าพังตรงไหน” –> เขียนเทสทีละนิด รันมันบ่อยๆ สิ จะได้รู้ว่าอะไรพัง (Automated Tests/TDD)
  • “ขี้เกียจแก้โค้ดตาม code review แก้เยอะแยะไปหมด” – ก็ code review มันบ่อยๆสิ บ่อยมากๆ จนเป็น (Pair Programming) ก็ได้
  • “ส่งเมล์ไปมากว่าจะเข้าใจ เฮ้อ” – เวลาสื่อสารกัน ก็หาอะไรที่มันโต้ตอบกันได้ไวๆ สิ ไม่เข้าใจจุดไหนก็ถามกลับมาได้เลย จนกลายเป็น (face-to-face communication) ก็ยิ่งดี
  • … (และอื่นๆอีกมากมาย) …

One more thing

สุดท้าย .. แถม …​”merge นรก กลุ้มใจ” – ก็กองโค้ดที่ไม่ได้รวมกับคนอื่นเค้า (branch / uncommitted code) เอาไว้เยอะๆ เองนิ –> merge มันบ่อยๆ merge มันทุกลมหายใจ จนกลายเป็น (Trunk Development) เลยก็ได้