Posts

เมื่อวันพฤหัสและศุกร์ที่ผ่านมาผมได้มีโอกาสโดดเรียนวิชา DSP ไปร่วมงานThailand Practical Software Engineering Conferenceที่Software Parkมาครับซึ่งงานนี้เรียกได้ว่าเป็นครั้งแรกที่จัด (ในชื่อนี้) โดยกลุ่มผู้จัดงานก็คือThailand SPINซึ่งถ้าเคยไปร่วมงานสัมมนา Agile หลายๆงานมาก็จะค้นพบว่าคือวงการเดียวกันนี่แหละเป้าหมายของงานสัมมนานี้ตามที่ผมเข้าใจจากผู้จัดงานคือมาแลกเปลี่ยนประสบการณ์เกี่ยวกับ Software Process (ซึ่ง Agile ก็เป็นหนึ่งในนั้น) ของจริงเจ็บจริงไม่ใช่งานสัมมนาเพื่อมาขายของซึ่งนอกจากผู้จัดแล้วผมก็เพิ่งค้นพบอีกว่าวงการ Software บ้านเรานั้นมันไม่ได้กว้างใหญ่เลยปีนี้ไปมาแล้ว 3 งานคือ Agile Thailand 2013, Barcamp Bangkhen และงานนี้ก็เจอแต่คนหน้าเดิมๆอาจจะเจอคนหน้าใหม่ๆบ้างแต่ถือว่าน้อยมาก (แต่ก็ยังไม่กล้าทักใครก่อนอยู่ดี T^T) ข้อเสียอย่างเดียวของงานนี้ที่นึกออกคือการไปจัดอยู่ Software Park ซึ่งมันไกลมากจากลาดกระบังแต่นับว่าเดินทางสะดวกอยู่ทีเดียวคือนั่งรถเพียงแค่ 2 ต่อ (แต่ต้องขึ้น 166 ให้ถูกคันทั้งขาไปและกลับเลย) เกริ่นมานานแล้วมาไล่ดู Session ที่ผมไปเข้ามาดีกว่า Keynote: Challenges of Managing a Complex Project - The Case Study of Landing a Rover on Mars Session นี้ถือว่าเป็น Highlight ของงานเลยครับแค่คนพูดนี่ก็สุดๆแล้วDr.Firouz Naderiผู้อำนวยการโครงการสำรวจในระบบสุริยะทั้งหมดจาก NASA JPL เรียกได้ว่าตั้งแต่ดวงอาทิตย์ยันดาวพลูโต Dr. คนนี้มีเอี่ยวหมดโดยดร.ฟิรุสมาเล่าให้ฟังเกี่ยวกับโครงการสำรวจดาวอังคารที่แกกำลังทำอยู่โดยเริ่มการค่อยๆเกริ่นจากไอเดียภาพรวมของการทำโครงการซักโครงการนึงว่า 1)เราเริ่มจากการมีความฝันแล้ว 2)เราขายฝันจากนั้นแล้วในวันถัดมา 3)เราก็เริ่มจะคิดได้ว่า “กูมองโลกในแง่ดีเกินไปแล้วนะ” ซึ่งพอผ่านจุดนี้เราจะ 4)เริ่มทำงานหนักขึ้นที่ 60 ชั่วโมงต่อสัปดาห์และ 5)เราก็จะเริ่มเครียดขึ้นอีกเรื่อยๆจากปัญหาต่างๆที่รุมเข้ามาไม่ว่าจะเป็นปัญหาทางเทคนิค, งบหรือแม้กระทั่งกำหนดส่งปัญหาเหล่านี้จะส่งผลให้ 6)เราทำงานหนักขึ้นอีกเป็น 70 ชั่วโมงต่อสัปดาห์ซึ่งเมื่อถึงท้ายที่สุดแล้วไม่มีใครบอกได้ว่า 7)โครงการที่เราทำอยู่จะประสบความสำเร็จ….. หรือล้มเหลว ...

ต่อจาก โพสที่แล้ว เลยนะครับเพื่อไม่ให้เป็นการเสียเวลา Robot Framework: Generic test automation framework for acceptance testing and acceptance test-driven development (ATDD) สำหรับ Session นี้ผมถือว่าเป็น Session ที่สนุกที่สุดของงานนี้แล้วโดย Speaker เป็นพี่รูฟ @roofimon โดย Session นี้คนเยอะมากๆเข้ามาแทบไม่ขาดสายจนที่นั่งไม่พอเลยทีเดียวสำหรับ Robot Framework อธิบายง่ายๆคือเป็น Automate test framework ตัวนึงที่ช่วยให้งานของ Tester นั้นง่ายขึ้นแต่ก่อนจะเริ่มนั้นพี่รูฟถามว่า “ใครรู้สึกตัวว่าอยู่ผิดห้องมั้ยครับ ?” ประมาณ 4-5 รอบเลย พี่รูฟเริ่มต้นด้วยการอธิบายคอนเซปของ Requirement ลูกค้าว่าก็เหมือนการสอบสมัยเรียนมหาลัยโดยอาจารย์จะมีโจทย์ที่อลังการงานสร้างที่สุดเท่าที่คิดออกมาให้เราพร้อมกับ… กระดาษหนึ่งแผ่นหน้าที่ของเราคือเขียนคำตอบไปให้มันตรงกับความต้องการของอาจารย์ให้มากที่สุดโดยพี่รูฟยกตัวอย่างเช่นถ้าสมมติอาจารย์เฉลย 80 แล้วเราตอบ 160/2 แทนที่เราจะได้ซักครึ่งคะแนนแต่กลับกลายเป็นว่าเราไม่ได้เลย “สัส มึงทำผิด !!” พี่รูฟยังยกตัวอย่างข้อสอบ Tense ภาษาอังกฤษที่จะมีการ Guideline มาเป็น Passage แล้วให้เราหยอดคำลงไปในช่องว่าง (ซึ่งยังพอมั่วได้แม่นกว่า) ซึ่งถ้าเปรียบเทียบกับ S/W แล้วการที่เรามี Guideline ในการตรวจรับที่ชัดเจนจะทำให้เรามีความสุขกับงานที่ทำมากกว่า หลังจากนั้นพี่รูฟพูดถึงบริษัท Odd-e นิดหน่อยอันนี้ผมขอข้ามละกันเพราะไม่เกี่ยวกับเนื้อหาประเด็นต่อไปที่พี่รูฟพูดถึงคือถึงแม้เราจะใช้ Agile มาช่วยในการทำงานแล้วก็ตามเราก็ยังคงเจอปัญหา Requirement แบบนี้อยู่เสมอเนื่องจากเรามักจะคิดว่า “สิ่งที่เรารู้เป็นสิ่งที่ลูกค้าอยากได้” ทำให้เกิดปัญหาเมื่อถึงตอนจบแล้วลูกค้าจำไม่ได้แล้วตอบเรากลับมาว่า “ผมไม่ได้พูดอย่างนั้นนะ” ซึ่งพี่รูฟก็ได้ชี้ให้เห็นว่าแท้จริงแล้วนั้นของที่ถูกต้องมันอยู่ในมือของ Tester ไม่ใช่ Programmer แต่เนื่องจาก Programmer เป็น “สิ่งมีชีวิตที่คิดว่าตัวเองฉลาดที่สุดในโลก” มีความผยองและเป็นอย่างนี้มาหลายชั่วอายุคนปัญหานี้จึงยังเกิดขึ้นอยู่เสมอวิธีแก้คือ ให้ Programmer หา Tester มาเป็นแฟน… ไม่ใช่ !!! แต่ให้เราเขียน Test ตั้งแต่ขั้น Design กันเลยทีเดียว ...

ก็เป็นตอนที่ 3 แล้วสิ่งที่ผมจะมาพูดถึงในวันนี้คือหนึ่งในเรื่องที่ตัดสินใจยากที่สุดตั้งแต่ตอนเริ่มทำ Project I แล้วคือการหา Project Management Tool ครับย้อนกลับไปในเดือนกรกฎาคมปี 2013 เป็นช่วงเวลาที่โปรเจ็คเริ่มตั้งไข่หลังจากส่ง Proposal และได้รับการอนุมัติแล้วในช่วงเวลานั้นผมยังคงยอมรับว่าผมยังคงใหม่กับ Agile Practice มาก (จนถึงตอนนี้ก็ยังยอมรับว่ายังใหม่อยู่) และสิ่งที่มือใหม่ Agile มักจะทำกันจากที่ผมสังเกตมาหลายคนที่ศึกษาเองคือหาเครื่องมือที่เหมาะสมกับตัวเองและทีมเพื่อที่จะใช้ Agile ได้อย่างสมบูรณ์แบบ (แต่ผมก็ไม่ได้บอกว่าวิธีการนี้เป็นวิธีการศึกษาที่ดีนะครับจริงๆพอมามองย้อนกลับไปผมน่าจะไปศึกษาแนวคิดให้มันแน่นกว่านี้แต่อย่างว่ามือใหม่มักจะตื่นเต้นกับ Tools มากกว่าหลักการจริงๆเสมอ) Release Backlog แรกสุดที่ทำ มีแค่ Excel ผมเริ่มต้นการศึกษาหลักการนี้จากงาน Agile Thailand 2013 แล้วต่อยอดมาอ่านAgile SamuraiและScrum Primerซึ่งสุดท้ายแล้วก็เลือกที่จะนำเอาแนวคิด Scrum มาใช้ในการทำ Project อย่างที่ท่านๆได้เคยเห็นไปแล้วในบล็อกตอนก่อนๆเครื่องมือที่ใช้ในช่วงแรกๆนั้นมีแค่ Excel, Post-It และ Whiteboard แค่นั้นในการทำ Backlog Grooming ครั้งแรกซึ่งการคุยกันครั้งแรกสามารถแตก User Story บางเรื่องที่ไม่เคยคิดว่าจะใหญ่ออกเป็นก้อนเล็กๆได้และสามารถคิด Feature เพิ่มขึ้นมาได้หลายอย่างด้วยพอเรียงลำดับความสำคัญกันเสร็จผมและทีมก็ประสบปัญหาทันทีคือจะเอามันไปไว้ตรงไหนให้ดูได้ตลอด Story ในเวลานั้นก็เลยย้ายไปติด Product Backlog ไว้มุมห้องมุมหนึ่งซึ่งสรุปในเวลาต่อมาไม่นานว่าแทบไม่มีใครดูเลยเพราะมันติดกันอัดแน่นมากผมจึงเริ่มมองหาเครื่องมือใหม่อีกครั้ง โชคไม่ดีที่หลังจากนั้นไม่นานผมและทีมตัดสินใจที่จะเปลี่ยนหัวข้อการทำ Project ใหม่สิ่งที่ส่งผลตามมาคือทุกอย่างที่เราเคยทำไว้ก่อนหน้านี้ถือว่าเซตซีโร่, ยกเข่งทำใหม่หมดช่วงนั้นหนึ่งในเรื่องพื้นฐานที่สุดที่ต้องเปลี่ยนคือเราต้องการ Tool ที่ทุกคนสามารถที่จะเข้าไปดูความคืบหน้าของแต่ละคนได้และสามารถรองรับแนวคิด Scrum ที่เรากำลังยึดถือกันอยู่ได้ความต้องการแค่นี้หลังจากนั้นเป็นการหาข้อมูลและผมค้นพบว่ามีการถกเถียงกันอย่างกว้างขวางในเรื่องของ Tools ในสังคม Agile หลายๆที่ไม่ว่าจะเป็นใน Stack overflow, ตามบล็อกอิสระทั่วไปหรือแม้กระทั่งในกลุ่มAgile66เองแต่นอกจากแนวคิดที่ใช้แค่ Post-It กับกระดานบอร์ดนั้น Tools ที่ใช้มีหลักๆที่คนแนะนำอยู่ไม่กี่ตัวหนึ่งในนั้นคือ Trello ...

เมื่อหลายวันก่อนมีรุ่นน้องมาถามผมว่าใช้ Tools ตัวนี้ๆ ดีรึเปล่าสำหรับ Project Management ซึ่งผมก็ตอบไปตามทรรศนะและประสบการณ์ และเมื่อวานนี้ก็มีรุ่นพี่ที่รู้จักได้ยกเรื่องคล้ายๆ กันนี้มาพูดอีกครั้ง ผมก็ยังแนะนำไปตามประสบการณ์ที่เคยใช้งานมา พอดีผมได้มีโอกาสอ่านหนังสือ “ใช้ความสุขทำกำไร” (Delivery Happiness) เป็นเรื่องราวของบริษัทขายรองเท้าออนไลน์ Zappos ซึ่งมีการกล่าวถึง ค่านิยมหลัก 10 ข้อของบริษัท Zappos และเป็นตัวบ่งบอกความเป็นวัฒนธรรมองค์กรของบริษัทนี้ ประเด็นอยู่ที่ว่าผมไปสะดุดกับข้อ 2)เปิดรับและขับเคลื่อนความเปลี่ยนแปลง 4)พร้อมผจญภัย สร้างสรรค์ และเปิดกว้าง และ 10)รู้จักถ่อมตน ทั้ง 3 ข้อนี้ทำให้ผมคิดถึง Agile Manifesto 2 ข้อคือ Individuals and interactions over processes and tools Responding to change over following a plan ในหลักปรัชญาแบบ Zen ได้มีการกล่าวถึงความคิดของผู้เริ่มต้น (Beginner’s mind) ไว้ว่า ในความคิดของมือใหม่ โอกาสมีอยู่มากมาย แต่ในความคิดของมืออาชีพ โอกาสมีอยู่ไม่มากนัก มันทำให้ผมหันกลับมามองย้อนดูตัวเองว่าหลายๆ ครั้งที่เราศึกษาอะไรซักอย่างมาอย่างยาวนาน มันมักจะทำให้เรามีความมั่นใจในตัวเองสูงในเรื่องดังกล่าวซึ่งก็เป็นเรื่องดีเพราะมันทำให้เรากล้าที่จะถ่ายทอดไปได้อย่างเต็มที่ แต่บางครั้งมันก็เป็นหลุมพราง (Pitfall) ที่ทำให้เราพลาดที่จะเรียนรู้สิ่งใหม่ๆ และไม่กล้าที่จะเปิดใจลองสิ่งใหม่ๆ เหมือนตอนที่เราเริ่มต้นศึกษามันก็เป็นได้ ความต้องการแต่ละคนนั้นแตกต่างกัน การเลือกใช้ Tools ใดๆ ก็ตามก็ต้องคำนึงถึงจุดนั้นด้วย คุณไม่สามารถจะใช้ Tools ตัวเดียวกันในทีมที่แตกต่างกัน แม้ว่าความแตกต่างนั้นจะน้อยมากก็ตาม สิ่งที่ผู้ถามต้องการกับสิ่งที่ผู้ตอบต้องการบางครั้งก็ไม่ใช่สิ่งเดียวกัน บางทีมอาจจะต้องการเครื่องมือในการประเมิน เพื่อปรับปรุงความสามารถในการทำงานของทีมอย่างต่อเนื่อง, บางทีมต้องการเพียงแค่บอร์ดงานเพื่อจะได้รู้ว่างานทำไปถึงไหนแล้ว สิ่งเหล่านี้คือความแตกต่างของความต้องการในแต่ละทีม ในฐานะผู้ตอบบางครั้งจากประสบการณ์เพียงอย่างเดียวก็ไม่สามารถตอบโจทย์ผู้ถามได้ และสิ่งที่ควรทำก็คือหาความต้องการของทีมและหาเครื่องมือที่ดีที่สุดให้เขาไป ซึ่งบางครั้งสุดท้ายแล้วอาจจะจบลงด้วยการใช้แค่ Post It กับ Whiteboard เกลี้ยงๆ แค่นั้นก็ได้ ...

วันที่ 9 ที่ผ่านมาวันคล้ายวันเกิดผมเองครับ แต่ละปีผ่านไปเราถูกบอกว่าเราแก่ขึ้นแล้วนะ ภาระความรับผิดชอบเยอะขึ้นแล้วนะ นั่นคือสิ่งที่เราดำเนินไปและกำลังดำเนินต่อไปทุกวินาทีที่เราใช้ชีวิตอยู่ สิ่งหนึ่งที่ผมเรียนรู้เกี่ยวกับ Agile มาคือ การมองย้อนกลับไปหรือที่ชุมชนชาว Agile เรียกกันว่า Retrospective ไม่ใช่เรื่องเสียเวลาเลย ไม่ใช่การมองอดีตจะเป็นการเสียเวลาอย่างเดียว แต่เป็นการทำให้เรารู้ว่าเราเคยทำอะไรดีๆ มาบ้าง, เคยผิดพลาดตรงไหน และเราจะปรับปรุงมันได้อย่างไร ฟังดูคุ้นๆ ใช่มั้ยครับ Good, Bad, Try นั่นเอง แต่เราจะพูดถึงสิ่งนี้ทีหลัง ปีที่ผ่านมานับตั้งแต่เดือนตุลาคมปีที่แล้ว ถ้านับเป็นเวอร์ชั่นของ Software คงเรียกได้ว่าเป็น Major Change เลยทีเดียว ลองไล่ดูว่าเกิดอะไรขึ้นบ้าง Foreign Student Internship Program 2013 @ U.S. Embassy Bangkok เรื่องนี้นับว่าเป็นเรื่องใหญ่ที่สุด จริงๆ แล้วผมตั้งใจจะเขียนเรื่องฝึกงานเต็มๆ ซักตอนนึงเลย แต่ไม่มีโอกาสซักที ตอนนี้เลยเอาแบบย่อๆ ไปก่อน คือ ช่วงประมาณปลายเดือนกันยายน ของปีที่แล้ว เป็นเรื่องธรรมดาของนักศึกษาปี 3 ทีต้องเริ่มหาที่ฝึกงานแล้ว ซึ่งจริงๆ ในตอนนั้นผมก็เล็งไว้หลายที่มาก แต่จนแล้วจนรอดก็ยังไม่ได้สมัครที่ไหน โครงการ FNSIP2013 ผมรู้จักจากคนใกล้ตัวนี้เอง ซึ่งบอกตามตรงว่าไม่เคยคิดว่าจะมีโปรแกรมแบบนี้อยู่ในโลก อาจจะเป็นเพราะการที่เราเรียนในสายวิศวกรรมศาสตร์ ทำให้ไม่ค่อยสนใจ การฝึกงานในองค์กรอะไรแบบนี้นัก เพราะส่วนใหญ่มักมุ่งไปแต่เอกชนอย่างเดียว ...

ช่วงเวลาสองสัปดาห์ที่ผ่านมาหลังสอบไล่ Project I เสร็จหลาย คนอาจจะเริ่มอ่านหนังสือสอบไล่ตัวอื่นกันบ้างแล้ว ผมก็สอบครับ แต่สอบน้อยกว่าคนอื่น (3 ตัว) ช่วงเวลาที่หยุดระหว่างสอบ นอกจากจะอ่านหนังสือ แล้วสิ่งที่ผมไม่อาจลืมได้คือ Project II เหลือเวลาให้ Implement กับ Testing เพียงแค่ 4 เดือนโดยประมาณนับจากนี้ ซึ่งสิ่งที่ยากไม่ใช่เวลา แต่เป็นคนครับ ผมตั้งคำถามกับตัวเองว่าทำยังไงถึงจะให้คน 3 คนทำงานใน Project เดียวกันได้ เร็วที่สุด จุดประสงค์ที่ผมเขียนเอนทรี่ในชุด Team Development Environment & Workflow (ตอนต่อๆ ไปจะเรียกมันว่า TDE&W นะครับ) ก็เพื่อที่จะรวบรวมคำถามและวิธีการที่ผมเคยสงสัยมาตลอดในการสร้าง Software ออกมาตัวนึง เพื่อเก็บไว้ใช้อ่านทวนทีหลัง และที่สำคัญไว้เผยแพร่ความรู้ให้กับคนที่ยังไม่รู้เหมือนผมก่อนหน้านี้ จริงอยู่ถ้าในโลกการทำงานแล้วเรื่องแบบนี้บางครั้งเป็นเรื่องที่ Basic มากแต่ถ้ามองย้อนกลับมาในระดับการศึกษาผมค้นพบว่า น้อยคนที่จะเรียนรู้ลำดับการทำงานแบบนี้ซึ่งสามารถช่วยให้ทำงานได้อย่างเป็นระบบและมีประสิทธิภาพสูงขึ้นมาก Git Workflow คำถามแรกที่ผมถามตัวเองอย่างที่ผมได้บอกไปแล้วผมคิดถึง Git ก่อนเลยครับเนื่องจากมีประสบการณ์การทำงานกับมันมาบ้างใน Project ที่ใช้ Rails แต่สิ่งสำคัญอย่างนึงที่ผมยังไม่รู้คือ Git Workflow ครับโชคดีที่มีคนเขียนแนะนำเรื่องนี้ไว้แล้วในบทความเรื่องA Successful Git branching model src: https://nvie.com/posts/a-successful-git-branching-model/ ...

ขณะกำลังทำ Sprint Planning ไหนๆ วันนี้ก็ได้ Applied Scrum เข้ากับ Project อย่างเต็มตัววันแรกละ ขอเขียนอะไรไว้เป็นที่ระลึกหน่อย จริงๆ ผมตั้งใจไว้ว่าจะสอนทีม Senior Project ทำ Agile Methodology มาซักพักแล้ว ไอเดียนี้มันติดใจมาตั้งแต่ครั้งไปร่วมงาน Agile Thailand 2013 แต่ติดปัญหาอยู่สองสามข้อ อย่างแรกคือ ผมยังมีความรู้พื้นฐานเรื่อง Agile ไม่มากพอ อย่างที่สอง ผมยังมองภาพรวมของ Project ตัวเองไม่ออก อย่างที่สามสำคัญสุดขี้เกียจ เวลาผ่านไปเดือนกว่าๆ ถ้าไม่นับเรื่องเชียร์ เร่งส่ง Proposal และก็หาข้อมูลเกี่ยวกับ Data Mining ถ้าผมว่าง ผมก็จะพยายามหาความรู้เพิ่มเติมเกี่ยวกับ Agile มาโดยตลอด แรกๆ ก็หา Tools บ้างแต่ยังไม่ครบเพราะได้ Tools มาก็ใช้ไม่เป็น แถมมีคนแขวะ ไว้อีกว่า Collaboration more than tool เพราะฉะนั้นจะไปสนทำไม (แต่ก็ยังสนอยู่) จนกระทั่งผมค้นพบหนังสือ The Agile Samurai ซึ่งผมคิดว่าเป็นหนังสือที่อ่านง่าย อ่านสบาย เกี่ยวกับ Agile เล่มนึง แต่ผมอ่านจบไปแค่ Part II เพราะเจียดเวลามาอ่านไม่ได้จริงๆ เนื้อหา Data Mining บีบ ทำให้ผมต้องรีบหาวิธีทำ Agile แล้วมาประยุกต์ใช้กับทีมให้เร็วที่สุด ก่อนที่ทีมจะทำงานไปมากกว่านี้ ...