Posts

ถ้าหากว่าธีมของปีที่แล้วเป็นการพัฒนาตนเองในด้านร่างกาย ปีนี้คงเป็นการพัฒนาตนเองในด้านจิตใจอย่างไม่ต้องสงสัยเลย หลายอย่างที่เคยทำก็ไม่ได้ทำ หลายอย่างที่ไม่เคยทำก็ได้ทำ ถึงแม้ปีนี้จะวุ่นวายแค่ไหน แต่ปีนี้ก็ส่งพี่จั๊วะมาย้ำสิ่งสำคัญอย่างนึงซึ่งผมหลงลืมไปคือ เราทุกคนควรจะมีเพื่อน แล้วเพื่อนนี่แหละจะพาเราผ่านความยากลำบากต่างๆ นาๆ ไปได้ 🙋‍♂️ Finance 💰 ถ้าจะมีอะไรที่เป็นข้อผิดพลาดของชีวิตแล้วผมพยายามแก้ปัญหามันมาตลอดสองปีกว่าคือหนี้ครับ ผมเรียกได้เลยว่าผมใช้บัตรเครดิตได้ผิดหลักการจนมันนำไปสู่หนี้ก้อนใหญ่มาก จนผมขยับตัวไม่ได้ เรียกได้ว่ามีหนี้ปักกลางหลังจริงๆ ปีนี้ตลอดปีที่ผ่านมาผมเลยพยายามลดก้อนหนี้ให้ได้ ถึงแม้จะมีงานเสริมเข้ามานอกจากงานหลัก แต่มันก็จะมีกระเพื่อมขึ้นๆ ลงๆ ตลอด ไม่หมดไปซักที จนกระทั่งถึงจุดหนึ่งหลังจากที่ทุกคนปากเปียก ปากแฉะบอกให้ผมเก็บตังค์ซะที พอเก็บตังค์เท่านั้นแหละ ชีวิตเปลี่ยนเลยครับ พอเริ่มมีเงินเก็บ เราก็ไม่อยากให้มันหายไป และก็อยากให้มันเพิ่มขึ้นเรื่อยๆ ไม่อยากเอามาใช้ ผมก็เก็บเรื่อยๆ เดือนละนิดๆ หน่อยๆ จนวันที่ 29 ธ.ค. ที่ผ่านมาผมก็ไม่เหลือหนี้บัตรเครดิตแม้แต่บาทเดียวแล้ว แถมมีเงินเก็บอีกต่างหาก ✨ ความขึ้นๆ ลงๆ ของหนี้กับเงินที่มี (กราฟจาก YNAB) Reading 📚 ปีนี้เป็นปีที่กลับมาอ่านหนังสือเยอะมากอีกครั้ง จนถึงกับต้องซื้อชั้นวางหนังสือเพิ่มเลยทีเดียว หนังสือที่อ่านปีนี้ก็มีหลายแนวตั้งแต่ Technical, Programming, จิตวิทยา, วิทยาศาสตร์, ประวัติศาสตร์ ยัน เศรษฐศาสตร์ รวมถึงไม่ได้อ่านแค่เป็นเล่มแต่ eBook ก็เพิ่มขึ้นอย่างมีนัยยะสำคัญในปีนี้ หนังสือที่ชอบที่สุดในปีนี้มีสามเล่มคือ The Miracle of Dunkirk, Moneyball และ The little book of Hygge ...

ช่วงท้ายปีเป็นช่วงที่คนส่วนใหญ่จะนั่งนึกถึงว่าเราทำอะไรมาบ้าง ตลอดปีที่ผ่านมา แล้วจะทำอะไรต่อไปในปีข้างหน้า ปกติแล้วทุกปีช่วงท้ายๆ ปีผมจะชอบรอ Tech Radar ออกซึ่งก็จะได้รู้จัก Tools และ Techniques ใหม่ๆ ที่ Proof แล้วว่า Work เลยคิดว่า คงจะดีไม่น้อยที่เราจะได้แบ่งปันอะไรบ้าง ในมุมมองของการทำงานที่ Pronto Tools นี้ \1. pipenv 🗄 Source: https://docs.pipenv.org/ ปีนี้ถ้าจะไม่พูดถึง pipenv ก็คงจะไม่ได้ เพราะ library ตัวนี้ได้เปลี่ยน workflow ในการ develop python ไปอย่างสิ้นเชิง พร้อมกับความสามารถใหม่ๆ ที่เพิ่มเข้ามาจน Python.org ให้การรับรองว่าเป็น packaging tool ที่ควรจะใช้แทน pip ที่ใช้กันมาหลายปี จุดเด่นหลักๆ ของ pipenv คือการเพิ่ม Pipfile มาแทนที่ requirements.txt ที่เป็น pattern พื้นฐานกันมาหลายปี ด้วย syntax แบบ TOML ที่ง่ายกว่ามาก และมีความสามารถมากกว่าเช่น สามารถกำหนด version ของ Python ที่ต้องการจะใช้ run ได้, สามารถกำหนด development package ได้ ทำให้เราไม่ต้องแยก file requirements.txt สำหรับแต่ละ environment อีกต่อไป นอกจากนั้นแล้ว pipenv ยัง เพิ่ม Pipfile.lock มาด้วย​ซึ่งทำให้เรามั่นใจได้ว่าจะได้ Package ที่ถูกต้องจริงๆ จาก PyPI ...

เมื่อวานเป็นวันแรกที่ผมไปเรียนคลาส TOEIC ของสถาบันมาครับ คลาสนี้เรียนฟรีเสียแค่ค่าสอบ 700 ซึ่ง อันที่จริงแล้วผมเล็งจะเรียนมาตั้งแต่ต้นเทอมแล้ว แต่มัวแต่ไปทำอย่างอื่นอยู่เลยไปลงทะเบียนไม่ทันสุดท้ายเลยมาตกกับรอบสองซึ่งก็คือรอบนี้ แต่ถึงแม้มันจะเป็นแค่วันแรก แต่มันทำให้ผมนึกถึงอะไรหลายๆ อย่างๆ เลยทีเดียว อย่างแรกมักจะมีใครซักคนมาถามผมอยู่บ่อยๆ ว่าทำยังไงถึงจะเรียนภาษาอังกฤษเก่ง ผมเจอคำถามนี้มาแทบจะตั้งแต่อยู่ประถม ซึ่งตอนเด็กๆ ผมก็ตอบไม่ได้หรอกครับ ตอนมัธยมก็ไม่ชัวร์ แต่พออยู่มหาลัยผมพอจะรู้คำตอบแล้ว จริงๆ แล้วผมไม่ได้เก่งภาษาอังกฤษเลยนะครับ เรื่อง Grammar, Tense, Part of Speech ฯลฯ ผมไม่เคยรู้เรื่องครับ อันนี้สารภาพตามตรงเลย แต่ผมโตมาในครอบครัวที่ภาษาอังกฤษแทบจะอยู่รอบตัวตลอดเวลา คุณพ่อกับคุณแม่ผมทั้งสองท่านทำงานสถานีวิทยุ แล้วทั้งสองท่านโดยเฉพาะคุณพ่อมีรสนิยมชอบฟังเพลงสากลมาตั้งแต่ก่อนผมเกิด ตั้งแต่จำความได้นี่ผมก็ได้ยินเพลงสากลเข้ามาในหูละ ตั้งแต่ The Beatle, Bee Gees, Carpenter, Rod Stewart ฯลฯ ซึ่งทำให้ตอนผมอยู่ชั้นประถมหรือมัธยมก็รู้สึกแปลกๆ เหมือนกันที่ตัวเองชอบเพลงพวกนี้ ในขณะที่เพื่อนฟังลาบานูน, บอดี้แสลม หรือโปเตโต้ อะไรเหล่านี้ นอกจากนั้นแล้วท่านยังเป็นคนชอบดูหนังอีกด้วย และไม่แปลกเลยถ้าบ้านเราจะดูหนังที่ซับเป็นภาษาอังกฤษแต่ก็บ่อยครั้งมาก พอขึ้นมัธยมจำได้ว่าตอนมัธยมต้นช่วงนั้นกระแสเกาหลีมาแรงมาก ผมไม่เคยสนเลยครับอาจจะเป็นเพราะผมเป็นผู้ชายด้วยก็เลยไม่ค่อยกรี๊ดวงเกาหลีซักเท่าไร ซึ่งระหว่างนั้นผมก็เริ่มรู้จักซีรีย์เข้ามาในชีวิตเรื่องแรกๆ ที่ดูแล้วติดน่าจะเป็น NCIS (ซึ่งปัจจุบันก็ยังฉายอยู่) Even Steven ใน Disney Channel และอีกหลายๆ เรื่อง ซึ่งผ่านมาในชีวิตผมยันเข้ามหาลัย ที่ซึ่งไร้ซึ่งทีวีส่วนตัว แต่การมีอินเตอร์เน็ตทำให้เราหาของเหล่านี้ไม่ยากเท่าไรและแน่นอนครับว่าในสมัยนี้หนัง mkv มันฝังซับมาให้เลย เพราะฉะนั้นแล้วการเลือกดูเสียง ENG มันได้อรรถรสกว่าฟังเสียงไทยเยอะ ซึ่งในที่สุดแล้วผมก็เพิ่งมาค้นพบว่าน่าจะเป็นสิ่งเหล่านี้แหละที่เป็นเหตุผลหลักที่ผมไม่เคยรู้สึกแปลกกับภาษาอังกฤษซักเท่าไรเลย ...

ในชีวิตเรามักจะเจอใครซักคนมาคอยบอกเสมอว่าเราทำอย่างนั้นไม่ได้หรอกเราทำอย่างนี้ไม่ได้หรอกซึ่งในบางครั้งเสียงนั้นมันก็มาจากภายในตัวเราเองถ้านับจนถึงวันนี้ผมก็กลับมาเขียนโปรแกรมแบบจริงๆจังๆมาได้เกือบจะปีนึงแล้วคำถามคือก่อนหน้านั้นผมไปทำอะไรอยู่แล้วอะไรทำให้ผมกลับมา ถ้าใครเคยได้ดูหนังเรื่อง Ratatouille (พ่อครัวตัวจี๊ดหัวใจคับโลก) คงคุ้นเคยกับประโยคที่กล่าวไว้ว่า “ใครๆ ก็ทำอาหารได้” ซึ่งเป็นคำกล่าวของเชฟกุ๊สโตว์พ่อครัวที่เป็นแรงบันดาลใจให้เรมี่ (หนูในเรื่อง) เริ่มทำอาหารเรมี่มีข้อจำกัดทุกอย่างที่จะทำให้ตัวเองไม่สามารถทำอาหารได้รวมถึงตัวเรมี่เองนั้นเป็นหนูซึ่งสำหรับพ่อครัวแล้วหนูแทบจะเป็นศัตรูเป็นสัญลักษณ์ของความสกปรกและไม่ควรอยู่ในห้องครัวแต่มันเองก็ยังมีพรสวรรค์อยู่ข้อหนึ่งคือมีประสาทสัมผัสในการรับกลิ่นที่เหนือกว่าหนูทั่วไปสามารถแยกแยะองค์ประกอบที่อยู่ในอาหารออกมาได้ประกอบกับแรงบันดาลใจจากการแอบไปดูรายการทำอาหารในทีวีในบ้านของมนุษย์เป็นจุดเริ่มต้นให้เรมี่กล้าที่จะทำอาหารจริงๆเมื่อถึงโอกาส หลังจากเรียนวิชา Data Structure เสร็จตอนอยู่ปี 2 ตลอดสองสามปีที่ผ่านตัวผมเองนั้นแทบไม่ได้จับการเขียนโปรแกรมแบบจริงจังอีกเลยซึ่งในระหว่างนั้นสิ่งที่สนใจส่วนใหญ่ก็จะเป็นการ Config ระบบหรือบริการต่างๆบน Linux ซึ่งก็ไม่ใช่ว่างานนี้มันไม่สนุกนะครับการแก้ปัญหาในการติดตั้งระบบต่างๆให้มันเข้ากับ Environment ของเราได้นั้นเป็นเรื่องที่ท้าทายพอสมควรเลยทีเดียวต้องใช้ทักษะในการวิเคราะห์ปัญหาจากสิ่งที่ Terminal มันแสดงผลออกมารวมถึงไฟล์ Log ที่อยู่ในเครื่องฯลฯและมักจะมีบริการหรือเทคโนโลยีใหม่ๆให้มาทดลองติดตั้งเสมอจนกระทั่งเมื่อขึ้นปี 4 ถึงแม้ผมจะทำงานกับ Linux ได้ดีแต่เมื่อต้องเลือกที่จะทำ Project ทำอะไรที่เราอยู่กับมันไปหนึ่งปีเต็มผมเลือกที่จะเขียนโปรแกรมแทนซึ่งนอกจากมันจะดูท้าทายเพราะผมไม่ได้ทำอะไรเกี่ยวกับการเขียนโปรแกรมมาเกือบสองปีแล้วสาเหตุที่ผมเลือกนั้นก็แทบไม่ต่างกับเรมี่คือผมมีแรงบันดาลใจซึ่งแรงบันดาลใจที่ว่านั้นก็คืออไจล์ที่ผมพูดถึงบ่อยมากจนหลายๆคนเริ่มจะเบื่อแล้ว สิ่งที่ผมเรียนรู้มาตลอดเกือบปีที่กลับมาเขียนโปรแกรมคือใครๆก็เขียนโปรแกรมได้ครับซึ่งไม่ต่างจากการทำอาหารอย่างที่ผมกล่าวในข้างต้นเลยเวลาเรามีปัญหาที่เราต้องการจะแก้เราจะเลือกใช้โค้ดของคนอื่นที่หาได้ทั่วไปใน Internet ที่สมัยนี้แทบจะหาไม่ยากเลยเพราะมีคนแก้ไว้หมดแล้วหรือเราจะพยายามแก้ปัญหานั้นด้วยตัวเองไม่ต่างจากการที่เราจะเลือกกินบะหมี่กึ่งสำเร็จรูปที่แค่เอาน้ำใส่ถ้วยฉีกผงชูรสใส่หรือเราจะลงทุนเข้าครัวปรุงอาหารที่เราอยากกินขึ้นมาเองแน่นอนครับมันอิ่มเหมือนกันเหมือนกับที่งานเสร็จได้เหมือนกันแต่จะอร่อยมั้ยและยอมเสียเวลาทำมันมากแค่ไหนนั่นแหละครับคือสิ่งที่แต่ละคนเลือกต่างกัน ตอนเราเริ่มต้นทำอาหารถ้าเราคาดหวังว่าเราจะทำอาหารหรูระดับภัตตาคารได้ตั้งแต่ครั้งแรกที่เข้าครัวรับรองว่าตกลงมาเจ็บแน่ครับแล้วอาจจะเกลียดการทำอาหารไปเลยตลอดกาลแต่ถ้าเราเริ่มต้นจากจุดเล็กๆก่อนอย่างเช่นการทำไข่เจียวง่ายๆเชื่อมั้ยครับว่ามันสามารถเป็นแรงผลักดันให้เราทำอาหารที่ต้องใช้วิธีทำที่ซับซ้อนขึ้นได้นั่นแหละครับสุดท้ายแล้วไม่ได้ต่างจากการเขียนโปรแกรมเลย สุดท้ายแล้วความรักครับ ไม่ใช่ทุกคนครับที่รักการเขียนโปรแกรมเหมือนกับที่ผมก็ไม่ได้รักการทำอาหารซักเท่าไรแต่คนเราทุกคนมีโอกาสตกหลุมรักได้ครับถ้าเจอคนที่ใช้ในเวลาที่เหมาะผมมาเจอคนที่ใช่คืออไจล์ (อีกแล้ว) ในเวลาที่เหมาะ (ก่อนเริ่มทำโปรเจ็คหนึ่งเดือน) นั่นแหละครับเป็นสิ่งที่ทำให้ผมกลับมาเขียนโปรแกรมได้สนุกอีกครั้งและเริ่มที่จะเรียนรู้ว่าการเขียนโปรแกรมมันไม่ได้มีแค่ “การเขียนโปรแกรม” เพียงอย่างเดียวและผมยังยินดีที่จะแนะนำเธอ (อไจล์) ให้ใครก็ตามที่อยากจะรู้จักอยู่เสมอเพราะผมเชื่อว่าถ้าเขาเห็นเธอในแบบที่ผมเห็นแล้วหละก็เขาอาจจะตกหลุมรักเธอเหมือนที่ผมเป็นก็เป็นได้ Original post at: https://yothinix.blogspot.com/2014/01/anyone-can-cook.html

เมื่อเย็นนี้ผมกับน้องๆในชมรมมีโอกาสไปกินเนื้อย่างมาครับจริงๆแล้วจุดประสงค์ของการไปกินเนื้อย่างครั้งนี้ไม่มีอะไรเลยนอกจากความอยากอยากและอยากที่สั่งสมมานานหลายสัปดาห์ระหว่างที่กินๆอยู่มีน้องคนหนึ่งพูดขึ้นมาว่า “กินเนื้อย่างนี่มันอไจล์มั้ยพี่” ซึ่งหลังจากคุยกันในวงเนื้อผมสรุปคร่าวๆได้ว่าการกินเนื้อย่างกับน้องๆหรือเพื่อนมันไม่ต่างอะไรกับการทำโปรเจ็คซอฟท์แวร์เลยครับ เรามามองที่ฝั่งเนื้อย่างก่อน ตอนที่เราเข้ามาในร้านทุกคนจะเลือกตำแหน่งที่จะนั่ง ที่ตัวเองจะกินได้สบายที่สุด บางคนเลือกที่จะนั่งตรงข้ามคนที่กินเก่งที่สุดเพราะ ถ้าอิ่มเมื่อไรมันจะได้กินแทนเรา ในกรณีนีนี้ผมไปกันห้าคน แบ่งกันเป็น 2 เตา ซึ่งน่าจะเดาไม่ยากว่าเตาหนึ่งก็จะมี 2 คนรับผิดชอบเป็นหลัก และมีน้องคนหนึ่งเป็นตัวเสริมอยู่ระหว่าง 2 เตานี้ พอเลือกที่นั่งได้แล้วพนักงานก็จะมารับออเดอร์ซึ่งการกินแบบบุฟเฟ่เราก็สั่งในสิ่งที่เราอยากกิน มากน้อยแล้วแต่ศรัทธา พนักงานก็รับออเดอร์ไป แล้วหลังจากนั้นเราก็รอ ระหว่างนี้เราจะตัดกลับมาที่โปรเจ็คซอฟท์แวร์กันก่อน ในโปรเจ็คซอฟท์แวร์ทีมๆ หนึ่งจะประกอบไปด้วยคนที่เชี่ยวชาญในแต่ละสาขาที่แตกต่างกัน จริงอยู่ที่ Agile มักจะบอกไว้ว่า Role ในทีมมันเป็นแค่สิ่งสมมติ แต่ถ้าเรามองในความสามารถจริงๆ ก็จะมีคนที่เชี่ยวชาญแต่ละสาขาอยู่นอกจากนั้นยังมีเรื่องของ Senior กับ Junior อีกซึ่งก็คล้ายๆ กับการที่เราเลือกนั่งตรงข้ามกับคนที่กินเก่งกว่าในเตาเดียวกัน เมื่อเราฟอร์มทีมขึ้นมาได้แล้วสิ่งต่อไปคือรับงานจากลูกค้า ในกรณีนี้มันจะกลับกันเลยขอข้ามกลับไปที่ฝั่งกินเนื้อย่างกันต่อ พอเนื้อที่สั่งมาถึง ซึ่งมันก็มักจะมากันในปริมาณมากๆ พร้อมๆ กันหลายอย่าง ตามที่แต่ละคนสั่งไป ซึ่ง ก็ขึ้นอยู่กับสไตล์ในการกินของแต่ละคนว่าชอบกินอะไรก่อน กินอะไรหลัง หรือบางคน กินอย่างละนิดอย่างละหน่อย ให้รสชาติเปลี่ยนไปเปลี่ยนมาในปาก ก็แล้วแต่สไตล์ ทุกคนจะรับผิดชอบในสิ่งที่ตัวเองสั่งมาในกรณีที่อิ่มแล้ว และเลือกที่จะช่วยกันกินในสิ่งที่คนอื่นกินไม่ไหวแล้ว ถ้ายังไหวอยู่นะ (ซึ่งก็อุดมคติมาก เพราะถ้าอิ่มจริงๆ ก็มักจะเกี่ยงกันหรือในกรณีที่เห็นวันนี้ย่างให้แล้วส่งให้ถึงจานเลย) เวลาเราเก็บ Requirement จากลูกค้ามา ซึ่งก็สารภาพตามตรงว่าผมก็ไม่เคยเก็บจากลูกค้าจริงๆ เพราะทำแค่โปรเจ็คของปีสี่ แต่สิ่งที่เกิดขึ้นและคล้ายกันคือสไตล์การทำงานมันไม่ต่างอะไรกับสไตล์การกินเลย เราเลือกในสิ่งที่เราชอบทำก่อน (หรือในบางกรณี ทำในสิ่งที่ง่ายกว่าก่อน) ในกรณีเวลาเราทำ Scrum เราต้องทำ Sprint Planning ซึ่งมักจะเลือก Requirement ที่สำคัญที่สุดมาทำก่อนคนเลือกคือใคร คือลูกค้า แต่ในกรณีนี้ลูกค้าคือตัวเองถามว่าจะเลือกอะไร แว็บนี้แหละที่แนวคิดแบบ Scrum มันโผล่เข้ามาและเห้ย มันจริง เราทำมันอยู่ทุกวันแหะ เราเลือกสิ่งที่เราอยากกิน (หรืออยากทำ) มาทีละนิดใส่ลงไปในเตาแต่ละรอบ ไม่ต่างจากการเลือกงานมาทำในแต่ละ Sprint เลย ซึ่งในเตาแรกเนี่ย จะคล้ายๆ เป็นการประเมินว่าในเตาหนึ่งมันวางเนื้อได้สูงสุดกี่ชิ้น รอบต่อไปเราจะกะได้โดยประมาณว่าจะวางได้เท่าไร ไม่ว่าเนื้อนั้นจะมาแบบลูกเต๋า เป็นแผ่น หรือเป็นเนื้อคนละชนิดก็ตาม ...

หนึ่งในวิชาบังคับที่ผมต้องเรียนให้ผ่านก่อนจบปี 4 คือวิชาสัมมนาครับเป็นวิชาที่นศในชั้นปีที่ 4 จะต้องแบ่งกลุ่มกันแล้วไปเชิญวิทยากรมาจัดงานสัมมนาหรือพูดง่ายๆมาบรรยายนั่นเองครับโดยในสัปดาห์นี้เป็นความรับผิดชอบของกลุ่มผมกับเพื่อนอีก 10 ชีวิตได้ช่วยกันจัดงานขึ้นมาในเช้าวันนี้ซึ่งวิทยากรก็ไม่ใช่คนที่ไหนไกลก็คือคุณกุลวัฒน์วงศาโรจน์หรือพี่ปอมจากกลุ่ม Agile66 นั่นเองครับ ระหว่างที่กลุ่มอื่นก็จัดงานสัมมนาไปในช่วง 2 เดือนที่ผ่านมานับว่าผมโชคดีมากที่มีงานสัมมนาเกี่ยวกับ Software จัดขึ้นมาตลอดทุกเดือนไม่ว่าจะเป็นThailand Practical Software Engineering ConferenceและAgile Tour Bangkok 2013ซึ่งนอกจากจะไปหาความรู้มาประดับตัวจากงานแล้วทั้งสองงานยังมีจุดประสงค์แฝงคือการไปทาบทามวิทยากรซึ่งก็คือพี่ปอมทั้งสองงานซึ่งก็น่ายินดีที่พี่ปอมตอบตกลงตั้งแต่ครั้งแรกที่เจอกันเลยซึ่งหลังจากติดต่อกันหลังจากนั้นไม่กี่ครั้งก็ถึงวันงานซึ่งก็คือวันนี้ ระหว่างรอวิทยากรมาทางกลุ่มก็ได้เปิดวิดีโอไปสอบถามกลุ่มตัวอย่างว่า “อไจล์คืออัลไล” ซึ่งได้ไปถ่ายทำและทำการสอบถามมาในสัปดาห์ก่อนหน้านี้บอกตามตรงว่ารู้สึกดีมากที่ได้เห็นหลายๆคนยิ้มกับความดิบในคลิปโดยไม่ได้ตัดต่อแต่อย่างใดซึ่งอันที่จริงแล้วก็ถือว่าเป็นความผิดพลาดของผมเองเพราะในตอนแรกตั้งใจไว้ว่าจะตัดต่อให้ดูดีเหมือน VRZO แต่ด้วยข้อจำกัดทางเวลารวมถึงติดปัญหานิดหน่อยทำให้สุดท้ายแล้ววิดีโอก็ไม่ได้ตัดไม่ได้ใส่ซับเลยออกมาเป็นไฟล์ดิบๆอย่างที่เห็นในงาน โดยส่วนตัวแล้วตั้งแต่เลิกผมเลิกทำกิจกรรมก็แทบจะไม่ได้พูดต่อหน้าคนมากๆอีกเลยวันนี้เป็นอีกหนึ่งวันที่พิสูจน์ว่า “ถึงจะซ้อมมาแค่ไหนก็สั่นได้” ถึงแม้คนที่มาร่วมจะเป็นเพื่อนร่วมภาคเดียวกันแต่ก็ยังมีน้องๆจากภาควิชาอื่นและก็ยังมีนศ. มาจากคณะอื่นด้วยไม่สั่นก็ไม่รู้จะพูดยังไงแล้วครับพอแนะนำวิทยากรเสร็จก็ปล่อยให้เป็นหน้าที่ของพี่ปอมแล้วครับ ข้อเสียของการเป็นคนจัดงานคือไม่มีโอกาสจดครับเพราะต้องตั้งใจฟังแล้วก็เป็นหน้าม้าบ้างในบางโอกาสแต่มีคำพูดบางประโยคที่ผมจำได้จากการบรรยายผมอาจจะถ่ายทอดคำพูดไม่ได้เป๊ะๆนะครับแต่ประมาณว่า “อไจล์มันเป็นแค่แนวคิดคือจะเอาไป Adapt กับอะไรก็ได้แทบทุกอย่าง” ซึ่งผมเห็นด้วยจริงๆมันเหมือน Zen คือเอามาประยุกต์ใช้ได้กับทุกเรื่องแต่ผมนับถือ Agile มากกว่าจริงๆแล้วอาจจะเป็นเพราะผมเป็นคนทำซอฟท์แวร์ด้วยเลยเข้าใจความรู้สึกในความหมายของคำๆนั้นก็อาจจะไม่ผิดนัก อีกหนึ่งเรื่องเด่นๆที่ทุกคนเกือบทั้งห้องน่าจะสนใจคือตอนที่พี่ปอมพูดถึงทักษะที่จำเป็นที่สุดของโปรแกรมเมอร์ (ที่ไม่มีใครบอกคุณ) โดยทักษะที่ทุกคนสนใจที่สุดเห็นจะเป็น “การตั้งชื่อตัวแปรและเมธอด” เพราะไม่มีใครสอนในวิชาโปรแกรมมิ่ง (จริงๆแล้วอาจจะมีแต่พอเขียนจริงๆก็ลืมกัน) ซึ่งก็จะโยงมาหาอีกทักษะหนึ่งก็คือ “การทำงานเป็นทีม” ครับหลังจากนั้นพี่ปอมก็อธิบาย Agile Manifesto กับอไจล์คืออะไรซึ่งเป็นหนึ่งในเรื่องที่ผมอยากฟังคำอธิบายมากที่สุดในวันนี้แต่น่าเสียดายที่ผมต้องออกไปคุยกับอาจารย์แว็บนึงเลยพลาดจุดนี้ไป พอกลับมาจากคุยกับอาจารย์พี่ปอมก็พาเล่น Ball Point Game โดยตอนแรกว่าจะเล่นข้างหน้าหอประชุมแต่เสียงดังมากเลยย้ายกลับมากระจายกันเล่นอยู่ทั่วพื้นสโลป โดยเกมส์นี้จะแบ่งกลุ่มออกเป็นกลุ่มละ 10 คนในที่นี้และเกมนี้มีกฏอยู่ 3 ข้อคือ ต้องทำการส่งบอลผ่านทุกคนในทีมถึงจะนับเป็น 1 แต้ม ถ้าตกไม่นับ บอลต้องมีการผ่านอากาศคือส่งต่อๆ มือต่อมือไม่ได้ ห้ามส่งให้คนที่นั่งติดกัน โดยจะให้เวลา 2 นาทีแรกในการวางแผนแล้วก็ Estimate ว่าคิดว่ากลุ่มจะทำได้กี่แต้มหลังจากผ่าน 2 นาทีแล้วก็จะเล่นจริง 2 นาทีซึ่งจุดนี้เป็นอะไรที่สนุกมาก (แต่เป็นคนจัดงานก็ไม่ได้เล่นด้วย T^T) ที่เห็นเพื่อนตอนแรกๆงงๆเริ่มที่จะคุยกันเล่นแล้วยิ้มกันหัวเราะกันออกมาเห็นการ Estimation ผิดเห็นแนวคิดการ Retro แบบต่างๆกันแต่ละกลุ่มพัฒนาการและเทคนิคที่ซับซ้อนของแต่ละกลุ่มผมไม่รู้ว่าเพื่อนที่เล่นอยู่สนุกมั้ยแต่ผมรู้สึกดีมากที่ได้เห็นกิจกรรมแบบนี้รู้สึกดีจริงๆบรรยายไม่ถูกเลย ...

เมื่อประมาณ 6 เดือนที่แล้วมีงาน Event หนึ่งที่เปลี่ยนชีวิตผมไปตลอดกาลงานนั้นคือ Agile Thailand 2013 อย่างที่ผมพูดถึงมาหลายๆครั้งและตลอดหลายเดือนที่ผ่านมาความรู้ความเข้าใจในอไจล์นั้นก็เพิ่มขึ้นตามเวลาเป็นเหมือนขนมที่กินเท่าไรก็ไม่เบื่อ (อย่างน้อยก็ตอนนี้) และกินมาตลอดหลายเดือนด้วยความเอร็ดอร่อยในวันนี้ความรู้สึกหลังจากไปงานAgile Tour Bangkok 2013มาคือผมรู้สึกสดใหม่อีกครั้งผมก็ไม่รู้จะบรรยายยังไงให้เข้าใจว่ามันฟินมากเพื่อไม่ให้เสียเวลาไปมากกว่านี้ข้างล่างคือสรุป Session ที่ผมไปนั่งฟังมาในงานวันนี้ครับ Software must build for CHANGE not build for LAST เหตุผลที่ผมเข้า Session นี้สารภาพตามตรงว่าเพราะคนพูดครับแฮร่จะว่าเป็นแฟนคลับก็ไม่เชิงซะทีเดียวแต่ผมรู้สึกทุกครั้งหลังจากเข้า Session ของพี่รูฟ+Twin Panichsombatผมมักจะได้ของเล่นและพลังอะไรบางอย่างกลับมาซึ่งทำให้การทำอไจล์นั้นไม่เคยน่าเบื่อเลยครั้งนี้ก็เช่นกันครับของเล่นใหม่ที่ผมได้มามันเรียกว่า Fishbowl ครับ Fishbowl คือรูปแบบการประชุมที่แหวกจากขนบการประชุมแบบดั้งเดิมโดยจะให้คนที่อยู่ในที่ประชุมทุกคนสามารถเขียนคำถาม/หัวข้อที่ต้องการสนทนาลงในการ์ดซึ่งคนที่ทำหน้าที่เป็นคนจัดก็จะเก็บลงใน Fishbowl จากนั้นเราก็จะทำการสุ่มคำถาม/หัวข้อที่จะสนทนาขึ้นมาพูดกันเป็นเวลา 5 นาทีซึ่งเมื่อหมดก็จะให้ผู้เข้าร่วมทั้งหมดตัดสินว่าเราจะคุยกันต่อ (Like) หรือเราจะไปคุยเรื่องอื่น (Dislike) แต่ส่วนสำคัญอีกส่วนหนึ่งของ Fishbowl ก็คือทุกคนมีสิทธิที่จะพูดหรือตอบในหัวข้อที่เลือกมาได้โดยจะจัดเก้าอี้ไว้ 4-5 ตัวซึ่งจะต้องมีคนที่ร่วมการประชุมใครก็ได้นั่งอยู่แต่เหลือไว้ 1 ที่เพื่อที่จะเปิดโอกาสให้คนที่ไม่ได้อยู่ในวงสนธนา (คนฟัง) มีสิทธิที่จะเข้ามาแสดงความคิดเห็นได้ซึ่งเมื่อมีคนเข้ามา 1 คนก็จะต้องมีคนออกไป 1 คน (ซึ่งดูเหมือนจะมีคนจ้องจะออกตลอด) src: https://www.scrum-tips.com/agile/stacey-complexity-model/ นอกจาก Fishbowl แล้ว Session นี้ยังทำให้ผมได้รู้จักกับ Stacey Matrix ซึ่งเป็นกราฟในการประเมินรูปแบบของ Software Project ว่าเราอยู่ในสภาพไหนและเราควรจะใช้ Process อะไรมาจับโดยแบ่งเป็น 3 แกนคือ Requirement, People และ Technology ยกตัวอย่างเช่นถ้า Requirement ของโปรเจ็คเราแทบไม่เปลี่ยนแปลงเลยและ Technology ที่ใช้ก็คาดเดาได้เราก็จะตกอยู่ในโซน Simple ซึ่ง Process ที่แนะนำให้ใช้ก็คงจะเป็น Waterfall นะโดยแต่ละโซนจะมี Process ที่น่าจะรองรับได้เช่น Agile จะอยู่ในโซน Complicated แต่ถ้าไปตกอยู่ในโซน Anarchy ก็บอกได้คำเดียวว่า “วอดวาย” สุดท้ายพี่รูฟสรุปด้วยประโยคที่ว่า “Software is Business, Business is never stop” จริงๆมันยาวกว่านี้แต่ผมจำได้แค่นี้ความหมายประมาณว่าขนาดธุรกิจยังไม่เคยหยุดที่จะเปลี่ยนแปลงเลยตัวซอฟท์แวร์ก็เช่นเดียวกันคำถามที่เหลือใน session นี้ผมขอสรุปไว้เป็น bullet ดีกว่าเพราะว่ายังมีอีกหลาย session ให้เขียนต่อนะครับ ...

เอนทรี่นี้ถ้าจะให้พูดตามตรงก็เหมือนภาคต่อของTDE&W (3) :: Team Foundation Serviceเลยทีเดียวเพราะในเอนทรี่ดังกล่าวผมทิ้งท้ายไว้ว่าปัจจุบันผมไม่ได้ใช้ TFS แล้วอย่างไรก็ตามเอนทรี่นี้ก็ไม่ใช่สิ่งที่ผมตั้งใจจะเขียนแต่แรกเพราะผมอยากจะพูดถึง Process ด้วยเพียงแต่ว่าวัฒนธรรมของเราที่ AdWise ยังคงมีวิวัฒนาการอย่างต่อเนื่อง, เปลี่ยนแปลงและเพิ่มขึ้นอย่างมากในช่วง 2 เดือนที่ผ่านมาทำให้ผมคิดว่าเรื่องกระบวนการทำงานผมรอให้ใกล้ๆจบ Project II ค่อยพูดถึงน่าจะดีกว่าวันนี้เราจะมาพูดถึงบอร์ดกันครับ สมัยตอนท้าย Project I เป็นช่วงที่เราเริ่มจะจริงจังกับการทำ Scrum เป็นอย่างมากและหนึ่งในเครื่องมือที่ช่วยให้เราทำ Scrum ได้ประสบความสำเร็จในระดับหนึ่งโดยจะไม่พูดถึงไม่ได้เลยก็คือ TFS ซึ่งหน้าตาก็เป็นดังรูปที่แปะอยู่ข้างล่างนี้แหละครับ เสียดายไม่เคยแคปหน้าจอไว้ตอนทำงานแต่ก็จะหน้าตาประมาณนี้ทีนี้เนี่ยพอปิดเทอมไปเราก็ไปพัฒนา Technical Skill แยกกันไปซะส่วนใหญ่และยังไม่มีการใช้บอร์ดร่วมกันเลยเป็นโอกาสที่ผมได้ทดลองหาเครื่องมือใหม่ๆหลายตัวอีกครั้งแต่ไม่ว่าผมจะพยายามหาเพียงแค่ไหนมันก็ยังสนองความต้องการไม่ได้ผมต้องการเพียงแค่บอร์ดง่ายๆที่สามารถเอาไว้ดูงานได้ไม่ต้องมีฟีเจอร์หรูหรายุ่งยากซึ่งในที่สุดผมก็กลับมาสู่จุดเริ่มต้นที่ผมทำ Agile นั้นคือEidosครับ ตัว Eidos เองเนี่ยตอนใช้แรกๆผมแฮปปี้กับมันมากครับมีฟีเจอร์แค่บอร์ด, ตัวจัดการ Backlog แล้วก็ Burndown ซึ่งเพียงพอกับความต้องการแล้วดูเหมือนจะมีความสุขใช่มั้ยครับไม่ครับผมประสบปัญหากับการลากแล้วค้างบ่อยมาก (วิธีแก้คือกด Refresh แล้วลากใหม่) ซึ่งแรกๆก็ทนใช้ได้ครับแต่นานๆไปมันเป็นปัญหาเกินไปแล้วนะผมเลยตัดสินใจเราต้องเปลี่ยนแล้วกระบวนการค้นหาจึงเริ่มต้นขึ้นอีกครั้งแต่ก็เหมือนครั้งที่แล้วไม่ว่าเราพยายามจะค้นหาแค่ไหนเราก็ไม่เคยเจอกับสิ่งที่ตรงกับที่เราต้องการจริงๆ (รอบนี้รู้สึกจะลองJIRAด้วยยิ่งใช้ยากหนักขึ้นไปอีก) สุดท้ายครับเราตัดสินใจกลับคืนสู่สามัญสู่จุดเริ่มต้นที่เราเคยได้ลองเพียงน้อยนิดและประสบความล้มเหลวกับ Project ก่อนหน้าไปและเราไม่ได้ใช้มันอีกเลยเรากลับมาลองมันอีกครั้งนั่นคือจุดเริ่มต้นที่เรากลับมาใช้Physical Board ครับ ...

จริงๆ ตอนแรกผมว่าจะไม่เขียน ตอนที่ 2 นี่แล้วเนื่องจากเหตุผลหลักเลยขี้เกียจและงานยุ่งมาก แต่พอวันหนึ่งผมเปิดเช็คยอดวิวของบล็อกอันนี้ ผมถึงเห็นว่ายังมีคนรออยู่ นอกจากนั้นแล้วการได้ยินเสียงตอบรับจากน้องที่เคยสอนการใช้ Git ไปว่ายังใช้ไม่ค่อยเป็น ทำให้ผมตระหนักว่าต้องกลับมาเขียนมันจริงๆ ถึงมันจะเป็นเรื่องเบสิกมากๆ ก็จริงๆ ในมุมมองเรา แต่สำหรับบางคนบางครั้งมันเป็นเรื่องใหม่สำหรับเขา เพราะฉะนั้นแล้วเนี่ยแทนที่เราจะนั่งเฉยๆ ปล่อยให้เขาล้มหายตายจากไป ผมคิดว่าอย่างน้อยเราก็ควรจะแบ่งปันความรู้ไว้บ้าง และเป็นการทวนความรู้ตัวเองจริงๆ อีกด้วยว่ารู้จริงรึเปล่า จากตอนที่แล้วผมบุ่มบ่ามมาพูดถึง Workflow ทั้งๆ ที่คนอ่านนั้นอาจจะไม่รู้เลยด้วยซ้ำว่าการแตก Branching หรือการรวม Merging และจากประสบการณ์ไปสอนกลุ่มย่อยๆ 2 กลุ่มทำให้รู้ว่า เรื่อง Branching/Merging เป็นเรื่องที่สอนให้คนเข้าใจจริงๆ ยากที่สุด และมีเวลาสอนน้อยสุดเพราะเป็นเรื่องหลังๆ เลยงั้นคราวนี้ ผมจะไล่ใหม่ทีละหัวข้อ รวมถึงเอาประสบการณ์มาสอดแทรกไว้ด้วยถ้ามีโอกาส (การใช้งานผมใช้ SourceTree เป็นหลักนะครับ ถ้ามีใครเป็นสิงห์ Git Command มาก็ขอนับถือในความสามารถมา ณ ที่นี้ครับ) Clone/New สิ่งนี้เป็นสิ่งแรกที่ต้องทำเมื่อเราจะใช้งาน Git กับ Project ใดๆ ก็ตามไม่ว่าจะทำเองหรือทำกับทีม สิ่งสำคัญ 2 สิ่งสำหรับการ Clone ก็คือ Source Path กับ Destination Path โดย Source Path จะเป็น link ของ Remote repository ไว้สำหรับเก็บ Source code นอกเครื่องเรา (ที่เราเรียกว่า Local repository) โดยส่วนใหญ่มักจะอยู่ในรูป http url หรือ ssh url เช่น https://github.com/user/project.gitพอเราได้ลิงค์มาแล้วแปะไว้โปรแกรมจะสร้าง Destination Path ซึ่งเป็นโฟลเดอร์ที่เราจะใช้ในการเก็บไฟล์ที่เรา Clone มานี้และเป็นโฟลเดอร์หลักที่เราจะใช้ในการทำงานในโปรเจ็คนี้นะครับ โดยถ้าไม่พอใจก็เปลี่ยนได้ซึ่งส่วนใหญ่ก็จะเปลี่ยนอยู่แล้วเพราะคงไม่มีใครไปนั่งพัฒนาเว็บอยู่ใน My Document หรอกจริงมั้ยครับ ...

สิ่งหนึ่งที่เป็นเรื่องที่เกิดขึ้นเสมอเมื่อคุณทำงานร่วมกับคนอื่นก็คือ “ดราม่า” ครับไม่ว่าทีมคุณจะห่วยแตกจะเข้ากันดีมากจะสมบูรณ์แบบแค่ไหนอย่างน้อยต้องมีสักครั้งที่เกิดเรื่อง “ดราม่า” ขึ้นในทีมซึ่งการเกิดดราม่าในทีมไม่ใช่สิ่งที่แย่เสมอไปจริงอยู่มันอาจจะทำให้ทีมเกิดปัญหาเสียจังหวะหรือโมเมนตัมที่กำลังดำเนินอยู่ไปเพราะความเห็นต่างหรือการไม่พอใจเพียงอย่างใดอย่างหนึ่งก็ตามแต่สุดท้ายแล้วถ้าคุณเป็นอไจล์ทีมสิ่งหนึ่งที่คุณควรจะทำเมื่อเกิดเหตุการณ์เหล่านี้ขึ้นคือ Retrospective ครับ Retrospective คืออะไร ตามทำเนียมการทำสกรัม (ซึ่งเป็นกลวิธีแบบอไจล์แบบหนึ่ง) การทำ Retrospective เป็นการกระบวนการรูปแบบหนึ่งที่ใช้ในการตรวจสอบและปรับปรุงการทำงานของทีมโดยมักจะทำเมื่อสิ้นสุดทุกๆสปรินต์ (2 สัปดาห์) การทำ Retrospective จะช่วยให้ทีมเห็นปัญหาที่เกิดขึ้นในการทำงานของทีมได้อย่างชัดเจนยิ่งขึ้นซึ่งจะช่วยให้ทีมนั้นสามารถปรับปรุงขั้นตอนการทำงานที่เป็นปัญหาอยู่และส่งผลให้สามารถทำงานได้อย่างมีประสิทธิภาพมากยิ่งขึ้น ผมรู้จักการทำ Retrospective ครั้งแรกในวันเดียวกับที่ผมรู้จัก Agile เป็นครั้งแรกที่งาน Agile Thailand 2013 ในวันนั้นมี Session หนึ่งที่ผมไปเข้าในตอนบ่ายชื่อว่า Retrospective: The art of continuous improvement ซึ่งสิ่งที่ดีที่สุดใน Session นี้นอกจากได้รู้ว่า Retrospective คืออะไรแล้วยังได้ฟังประสบการณ์จริงๆด้วยว่าทำแล้วเกิดอะไรขึ้นต่อมาและนั้นคือเหตุผลให้ผมอยากทำมาตลอดแต่ไม่มีโอกาสและที่สำคัญไม่มีดราม่า Drama นั้นสำคัญไฉน การเกิดดราม่าอย่างที่ผมบอกไปมักเกิดจากความเห็นที่แตกต่างหรือความไม่พอใจในระดับปัจเจกบุคคลซึ่งเราไม่สามารถบอกได้ชัดเจนว่าดราม่าเกิดตรงไหนบางครั้งมันเป็นการสั่งสมมานานบางครั้งมันเป็นการปะทะกันภายในเวลาไม่กี่ชั่วโมงแต่เมื่อเกิดดราม่าขึ้นแล้วถ้าคุณเป็นฝ่ายก่อดราม่า (ซึ่งในกรณีผมผมเป็นคนก่อดราม่า) สิ่งแรกที่ควรทำคือเอาอารมณ์ออกจากความคิดให้หมดแน่นอนว่ามันเป็นสิ่งที่ทำได้ยาก (จริงๆแล้วโคตรยากเลย) แต่เมื่ออารมณ์และบรรยากาศมาคุได้ผ่านพ้นไปแล้วหลายครั้งที่คุณจะค้นพบว่าบางครั้งปัญหาที่ทำให้เกิดดราม่ามันไม่ใช่เรื่องใหญ่และซับซ้อนเลยและในเมื่อคุณเริ่มจะมีเหตุผลขึ้นแล้วสิ่งที่ควรทำต่อมาคือเรียนรู้จากมันและการที่เราเป็นอไจล์ทีมแล้วการปรับปรุงการทำงานของทีมก็เป็นส่วนหนึ่งที่เราควรจะทำอย่างสม่ำเสมอ Good Bad Try จริงๆแล้ววิธีการทำ Retrospective นั้นมีหลายแบบมากๆแต่ที่ผมรู้จักและเลือกที่จะเอามาใช้คือ Good Bad Try ครับจริงๆแล้วผมบอกตามตรงเลยว่าผมไม่รู้ว่า Good Bad Try แบบจริงๆตามหลักการนั้นทำยังไงนอกจากมีคำว่า Good Bad Try และให้ทุกคนในทีมเอากระดาษโพสอิทไปแปะแต่สิ่งที่ผมจะกล่าวต่อไปคือขั้นตอนการทำ Good Bad Try ในแบบฉบับของทีมผมเอง ...