เมื่อประมาณ 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 คน (ซึ่งดูเหมือนจะมีคนจ้องจะออกตลอด)

นอกจาก 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 ให้เขียนต่อนะครับ

ข้อดีของ Agile

• ทำให้มุมมองที่มีต่อการสร้าง Software เปลี่ยนไป (มีเอกลักษณ์เฉพาะตัว)
• กลับไปสู่ความเป็นมนุษย์อีกครั้ง (งานมีแค่เสร็จกับไม่เสร็จไม่มีเสร็จไปกี่เปอร์เซ็นต์)ข้

เสียของ Agile

• ทำ Long Estimation ไม่ได้ และยืนยันว่าจะทำตาม Plan ที่วางไว้ไม่ได้ซึ่งทำให้จ่ายเงินแบบโปรเจ็คปกติไม่ได้เช่นเดียวกัน
• ต้องเผชิญกับความกลัวในการเปลี่ยน Culture ขององค์กร

ถ้าอยากทำอาชีพอย่างวิทยากร

• เพิ่งรู้ว่าอาชีพ Coach นี่มันแบ่งเป็น 3 แขนง Organization, Team และ Technical ซึ่งการจะเป็นได้สำคัญคือแค่อ่านหนังสือไม่พอ แต่ต้องทำเป็นด้วย (Lead by example)

วิธีรับมือกับ Requirement ที่เปลี่ยนแปลงบ่อย

• ทำ Automate ให้มากที่สุดให้เห็นว่าเกิด effect กับส่วนไหนบ้าง
• มีระบบป้องกันความเสียหายจากความเปลี่ยนแปลงซึ่งการทำ Unit Test และ Continuous Integration ช่วยได้
• ต้องสร้าง Environment ที่รองรับการเปลี่ยนแปลงด้วย
• คำคม: ถ้าทุกอย่างสำคัญหมดแสดงว่าไม่มีอะไรสำคัญเลย

Scrumban = Scrum + Kanban: Managing flow in a chaotic world

สำหรับ Session นี้คนที่เป็น Speaker นั้นมาจาก Malaysia ครับเลยฟังยากนิดหน่อยโดย Speaker พาเราไปรู้จักหัวใจของ Scrum ก่อน (5 Artifact 3 Role 5 Ceremony 5 Value) หลังจากนั้นจึงพาเราไปรู้จักกับ Kanban ซึ่งประโยคหนึ่งที่กินใจมาก (เพราะตัวเองก็เพิ่งเริ่มทำ Kanban ได้ 2 อาทิตย์กว่าๆ) คือ Kanban is all around us แล้วคุณ Tze ก็ยกตัวอย่างให้ฟังเช่นเวลาคุณไปดูหนังที่โรงหนังตัวคุณนะแหละเป็น Kanban, เวลาคุณไปซื้อกาแฟ Starbuck ตัวแก้วนะแหละคือ Kanban คือทุกอย่างที่กล่าวมามันจะมี Flow ซึ่งก็คือหัวใจของ Kanban นั่นเองนอกจากนั้นยังพูดถึง Push vs Pull ซึ่งใน Kanban เราต้องบอกว่า How much I can do (ซึ่งก็คือ Pull) สุดท้ายของ Kanban คือ Identified and manage constraint ซึ่งถ้าสมมติเป็นท่อน้ำตัว Constraint ก็คือคอขวดนะแหละโดยเราต้องหาวิธียังไงก็ได้ที่จะจัดการกับคอขวดที่เกิดขึ้น

ในส่วนของ Scum + Kanban ซึ่งก็คือหัวข้อหลักที่จะคุยกันวันนี้ผมจับใจความได้สองข้อข้อแรกคือตัวบอร์ดหรือที่เรียกกันว่า Work Stage และตัว WIP Limit ใน Kanban จะเป็นตัวสะท้อนของสิ่งที่ทีมเป็นและคุณค่าในตัวของมันเอง (ไม่รู้ว่าผมเข้าใจตรงนี้ถูกรึเปล่านะ) และการเอา Kanban มารวมกับ Scrum จะเปลี่ยนพฤติกรรมของทีมแทนที่จะสร้าง Task ใหม่ๆขึ้นมาแต่จะเปลี่ยนเป็นส่งมอบ Value แทน

ช่วงถามตอบมีคำถามซึ่งถ้าไม่มีคนถามผมก็ไม่ทันสังเกตุและเป็นสิ่งที่น่าสนใจมากคือในสไลด์บอกว่าในทีมมี Developer 9 คนแต่ทำไมตั้ง WIP ใน In Progress ไว้ 8 แล้วอีกคนทำอะไร ? คุณ Tze ตอบได้น่าสนใจมากว่าอีกคนหนึ่งนั้นมีหน้าที่ในการเดินไปทั่วและสังเกตุงานที่คนอื่นกำลังทำอยู่และเข้าไปช่วยถ้าทำได้ซึ่งจะได้อะไรมากกว่าการนั่งทำงานอยู่คนเดียวแน่นอนซึ่งก็มีคำถามตามมาอีกว่าถ้าไอ 1 คนมันไม่ยอมลุกไปไหนกูจะนั่งเล่น Hayday อยู่ตรงนี้แหละเราจะทำไงคุณ Tze แนะนำถึง Effect ของ Peer power จะมีประโยชน์มากกว่าให้ Manager มาสั่งว่าคุณต้องทำอย่างนั้นอย่างนี้นะในสถานการณ์นี้

Building high performance culture

เมื่อวันจันทร์ที่ผ่านมาผมได้ไปร่วมAgile 66 Community Eventมาซึ่งได้เชิญคุณ Henrik Kniberg มาบรรยายเรื่องCultural > Processซึ่งถ้าผมมีโอกาสก็คงจะมาเขียนเกี่ยวกับสิ่งที่ได้รับมาจากงานนั้น (ดองไว้ก่อน) ประเด็นคือในงานนั้นมีคนๆหนึ่งทักผมครับซึ่งผมมาทราบทีหลังว่าคือคุณ Arunthep ซึ่งก็คือ Speaker ของ Session ที่เรากำลังจะมาพูดถึงนี้โดยถ้ามองย้อนกลับไปไม่ว่าจะเป็น Agile Thailand หรือ TPSE ผมก็เห็นชื่อคุณ Arunthep อยู่บ่อยมากแต่ไม่เคยคิดจะเข้าเลยวันนี้เลยนึกครึ้มลองเข้าไปฟังดูและอาทิตย์นี้ดูเหมือนบรรยากาศการสร้าง Culture แทบจะอยู่รอบตัวเราหัวข้อนี้ซึ่งมีคำว่า Culture อยู่จึงล่อลวงผมเข้าไปได้ง่ายขึ้นไปอีก

ตัว Session พูดถึงโครงสร้างของ High Performance Culture ว่าประกอบด้วย 3 องค์ประกอบคือ Human Dynamic, Practices และ Environment (ซึ่ง Agile จัดอยู่ใน Practices นะครับ) หลังจากนั้นก็ตั้งคำถามว่าถ้าเราทำ Software เหมือนเดิมเป๊ะๆเลยเนี่ยเราจะทำได้เร็วขึ้น, เท่าเดิมหรือช้าลงซึ่งก็มีหลากหลายคำตอบมากในห้องแต่สรุปก็คือเร็วขึ้น 60-80% โดยทางวิทยากรพูดถึงลูปซักอย่างที่คล้ายๆกับของ Lean มากแต่ผมจำไม่ได้ว่าชื่ออะไรเป็นตัวอธิบายถึงคำตอบข้างบน ในเรื่องขององค์ประกอบในการสร้าง High Performance Team ทางวิทยากรอธิบายว่าจะประกอบด้วยหลายๆอย่างคือ

• Trust คือการยอมที่จะรับความเสี่ยงและให้โอกาสคนอื่น ต้องขอโทษเป็นและไม่มีการเมืองภายใน โดยได้โยงไปถึง Spiral Trust หรือความจริงของ Trust ว่ามันไม่ได้สร้างยากและเสียไปยากเลย ถ้าเราให้โอกาสคนอื่นและคนอื่นก็ให้โอกาสกับเราเหมือนกัน ยกตัวอย่างเช่น US vs THEM ซึ่งเป็นวัฒนธรรมที่ไม่มีใครได้มีแต่เสียกับศูนย์ (Zero Sum) โดยเราจะพยายามปกป้องตัวเอง (+1 US) และไปโทษคนอื่น (-1 THEM)
• Commitment อันนี้ยกตัวอย่างง่ายๆ คือเราต้องกล้าที่จะบอกว่าทำได้หรือทำไม่ได้ (ไม่ใช่ YES หมด (อันนี้ใน REWORK พูดถึงด้วย)) และยังมีวิธี Fixing breaking commitment เป็นสเตปดังต่อไปนี้- ยอมรับตามตรงว่าทำไม่ได้- ขอโทษ- จะทำอะไรให้มันดีขึ้นบ้าง- ครั้งต่อไปจะไม่เกิดขึ้นอีก
• Accountability อันนี้จะกลับกันกับ Commitment ซึ่งผมคิดว่าทางวิทยากรได้พูดไว้ในเรื่อง Personal Response Pyramid นะครับ ซึ่งผมก็หาภาพที่ตรงกับ Slide ไม่ได้แต่จะไล่จากฐานพีระมิดคือ Self -> Clarity -> Ask -> Agree -> Call
• Common Goal หัวข้อนี้คงไม่ต้องอธิบายอะไรมาก
• Conflict เป็นอะไรที่แปลกมากแต่ผมก็คิดว่าจริงคือ ทีมที่ดีคือทีมที่ทะเลาะกัน (เพราะถ้ามันไม่พูดกันนั่นก็เกินเยียวยาแล้ว) ถ้านั้นยังไม่เห็นภาพทางวิทยากรให้ทุกคนในห้องจับคู่กันแล้วมองตากันโดยไม่ต้องพูด 1 นาทีหลังจากนั้นแล้วถามความรู้สึก ซึ่งหลายคนก็รู้สึกตรงกันว่า แม่งฮามาก แต่วิทยากรก็อธิบายว่ามนุษย์เรามักจะเลี่ยงที่จะเผชิญหน้ากันเสมอ ซึ่งถ้าเราจัดการข้อจำกัดข้อนี้ไปได้ จะทำให้การแก้ปัญหาความขัดแย้งมันง่ายขึ้น

หลังจากนี้เป็นพักเที่ยงครับซึ่งบุฟเฟ่อร่อยมากไม่รู้จะบรรยายยังไงไปดูรูปที่เพจAgile Tour Bangkokก็คงจะเข้าใจมากขึ้นนะครับ

No Reuse Before Use

Session แรกตอนบ่ายนี่เลือกยากระดับนึงเลยครับแต่ผมก็ตัดสินใจเข้า Session นี้ซึ่งผมจัดให้เป็น Session ที่ฮาที่สุดของงานนี้แล้ว (แม้จะฟังออกบ้างไม่ออกบ้าง) โดยคุณ Terry Yin มาเล่าให้เราฟังเรื่อง Software Reuse ซึ่งเป็น Term ที่ผมได้ยินมาบ่อยมากแต่ไม่เข้าใจว่ามันคืออะไรแต่พี่แกเล่นตัดบทโดยบอกว่าเราจะมาพูดถึง Software Use แทน

วิทยากรเริ่มพาเราจินตนาการไปกับผังเมือง Brazilia เมืองหลวงของประเทศ Brazil ซึ่งเพิ่งรู้ว่านอกจากจะออกแบบเพื่ออนาคตเมื่อกว่า 60 ปีที่แล้วเองนั้นตัวเมืองยังออกแบบให้เป็นรูปเหมือนนกอินทรีและที่สำคัญไม่มีไฟแดงครับ !! แต่ปัญหาก็คือในอนาคตที่คนออกแบบผังเมืองมองไว้นั้นไม่มีคนเดินถนน (Pedestrian) ครับเพราะเขาสันนิษฐานว่าคนในอนาคตคงใช้รถกันหมดทุกคนแล้วซึ่งปัจจุบันมันเกิดสิ่งนี้ขึ้นครับ

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

จากเรื่องข้างบนพาเราย้อนกลับมาถึง Software Reuse ซึ่งเกิดคำถามขึ้นว่าเราจะรู้ได้ไงว่าส่วนไหนควรจะ Reuse ถ้าเรายังไม่ Use มันด้วยซ้ำวิทยากรพูดถึง Duplication หรือการทำซ้ำว่าเป็น Root of all evil in Software และการ Refactoring นั้นควรจะทำก็ต่อเมื่อสิ่งที่เราเขียนลงไปนั้นมันทำงานได้แล้วไม่ใช่ทำก่อนซึ่งจะทำให้การ Refactoring เป็นการเปลี่ยนแปลงตัว Structure ภายในส่วนนั้นไม่ใช่เปลี่ยน Output ที่ออกมาแต่ถ้าเราเขียนทุกอย่างตามหลักการ Once and only once ปัญหาพวกนี้ก็จะเกิดขึ้นน้อยลงจริงๆแล้วยังมีอีกหลายเรื่องใน Session นี้แต่ผมจับใจความไม่ได้เลยขอทิ้งท้ายด้วยประโยคที่ว่า "Design from perspective of use ratherthan implementation" ครับ

Building Software Development Culture for Any Scale

ผมสังเกตุเห็นสิ่งหนึ่งที่เกิดขึ้นตลอดสัปดาห์ที่ผ่านมาคือมีคนพูดถึงเรื่อง Culture ในองค์กรเยอะมากๆในวันนี้มีถึง 2 Session เลยซึ่งสารภาพตามตรงว่าผมมา Session นี้เพราะโดนกล่อมครับฮ่าพอดีตอนเที่ยงได้มีโอกาสสนทนากับพี่แอมป์+Tanawat Tassanaรวมถึงที่พี่แกมาโฆษณาใน Session ตอนเช้าด้วยเลยตัดสินใจไม่ดู Real Agile#2 ละ (ซึ่งโชคดีมากเพราะ Session นั้นมีคนอัดวิดีโอไว้ที่ >>  http://www.youtube.com/watch?v=zWIALP-vqEk)

Session นี้เริ่มด้วยคำถามว่าทำไมถึงต้องมี Culture โดยยกตัวอย่างสมาชิกใหม่ที่เข้ามาทำงานในทีมว่าเขาไม่ได้เรียนรู้จากกฏแต่เรียนรู้จาก Culture ที่มีอยู่เช่นถ้ามีคนบ่นเกี่ยวกับกฏสักพักเดี๋ยวก็มีคนบ่นตามเป็นต้นคำถามต่อมาคืออะไรคือ Culture คำตอบคือCulture = set of mindsetsทีนี้มันก็จะเกิดคำถามแล้วว่าแล้วกฏหล่ะปรากฏว่า Rules มันคือ Set of behaviors ครับคือรูปแบบพฤติกรรมที่กำหนดมาซึ่งกำหนดได้แค่พฤติกรรมครับแต่ในใจนั้นอีกเรื่องซึ่งทั้งสองอย่างทั้ง Culture และ Rules ต่างมุ่งไปที่เป้าหมายสุดท้ายเดียวกันคือ Bahaviors นี่แหละครับ

ทีนี้เนี่ยเราจะทำวัฒนธรรมที่เราสร้างให้มันเข้มแข็งได้อย่างไรมี 2 ข้อครับข้อแรกคือต้องเปิดรับการเปลี่ยนแปลง (คล้ายๆ Agile แหะ) เพื่อที่จะพัฒนาตัวมันเองรวมถึงต่อต้านความเปลี่ยนแปลงอะไรก็ตามที่ทำให้เกิดผลเสียต่อมันข้อสองพูดถึง Self-Selecting อารมณ์จะประมาณ Natural selection คือแน่นอนว่าไม่ใช่ทุกคนที่จะเห็นคล้อยไปตามวัฒนธรรมที่เกิดขึ้นซึ่งเมื่อส่วนน้อยเห็นไม่ตรงกับส่วนใหญ่เขาก็มีทางเลือกอยู่หลายทางจะทนอยู่, จะสู้หรือจะออกไปประมาณนั้นครับ

พอพูดถึง How หรือการสร้างวัฒนธรรมให้เกิดขึ้นได้อย่างไรสิ่งสำคัญคือสภาพแวดล้อมครับเพราะสภาพแวดล้อมสามารถส่งเสริมให้พฤติกรรมมันเติบโตได้ (ถ้าดูสไลด์ในส่วนนี้คือต้นไม้ที่มีโครงครับ) ซึ่งก็เกิดคำถามว่าแล้วถ้าสภาพแวดล้อมไม่ดีมันเป็นไงก็เหมือนต้นไม้โตโดยเอากระถางครอบข้างบนมันครับมันโตก็จริงแต่โตได้แค่ในกระถางที่ครอบมันอยู่และในข้อนี้ยังทิ้งท้ายโดยเตือนไว้อีกว่า "ถ้าหากเราไม่สร้างวัฒนธรรมของเราขึ้นมาแล้วก็จะมีใครซักคนสร้างมันขึ้นมาแทน"

ในส่วนสุดท้ายพูดถึงGood Software Development Cultureที่พี่เขาแนะนำโดยสามารถไปดูได้ในสไลด์ที่แปะลิงค์ไว้ข้างล่างนะครับแต่ข้อที่ผมชอบที่สุดคือIntegrityหรือการซื่อสัตย์กับตัวเองต้องยอมรับผิดถ้าเราผิดไม่ใช่แถให้ตัวเองชนะโดยหนีเหตุผลที่เรายืนหยัดเพื่อมันในตอนแรกCross Pollenationซึ่งก็คือสิ่งที่ผมคิดว่าตัวเองทำอยู่บ่อยๆคือหาของเล่นใหม่ๆที่เห็นคนอื่นทำแล้วดีมาทำกับทีมตัวเองบ้างและสุดท้ายFocus on GOAL not SOLUTIONอันนี้โดนทีมจังๆเลย

(ลิงค์สไลด์ >> http://slid.es/amptanawat/building-sw-dev-culture-for-any-scale)

Introduction to Scrum (A.K.A Agile 101)

หลังเบรคสำหรับ Session สุดท้ายนี่ผมไม่รู้จริงๆครับว่าจะเข้า Session ไหนคือเดินไปเหลือบมันทุกห้องจนมาหยุดที่ห้องนี้ (ซึ่งตอนแรกไม่มีในตาราง) สิ่งที่ผมได้รับจาก Session นี้ส่วนใหญ่เป็นสิ่งที่รู้หรือคิดว่าตัวเองรู้อยู่แล้วทั้ง Agile Manifesto, Agile Principle, Scrum, Kanban ฯลฯจึงไม่ได้จดอะไรเลยแต่ Session นี้ทำให้ผมคิดอะไรได้อย่างนึงคือในหลายๆครั้งเราก็ควรยกหัวโขนว่าตัวเองรู้อยู่แล้ววางไว้หน้าห้องแล้วทำตัวเป็นมือใหม่ไม่รู้อะไรเลยจะทำให้เรามองอะไรได้ชัดเจนยิ่งขึ้นและเปิดโอกาสให้เราได้เก็บเกี่ยวในสิ่งที่เราไม่เคยคิดว่ามันมีอยู่กลับมาด้วย

Panel-Discussion

หลังจากจบทุก Session สุดท้ายแล้ว Panel Discussion ซึ่งคราวนี้คือการทำ Fishbowl กันอีกรอบแต่รอบนี้ดีกว่ารอบใน Session เพราะได้เห็นกรณี dislike ชัดเจนกว่าส่วนเรื่องที่สนธนาก็เป็นคำถามที่หลากหลายมากและผมมัวแต่ฟังแบบฟินๆเลยไม่ได้จดอะไรมาเลย

Conclusion

สุดท้ายขอบคุณAgile66ที่จัดงานดีๆอย่างนี้ถึงแม้เป้าหมายที่ผมตั้งไว้ให้ตัวเองคือรู้จักคนใหม่ๆเพิ่มขึ้นมันจะไม่สำเร็จแต่อย่างน้อยผมก็ได้สนทนากับคน 2-3 คนซึ่งดีขึ้นกว่างานที่แล้วที่แทบไม่ได้คุยกับใครเลย (เพราะไปคนเดียวด้วยส่วนนึง) น่าเสียดายที่ Session หนึ่งมีเวลาแค่ 45 นาทีเพราะรู้สึกว่ามันจบเร็วเกินไปหลายๆอันยังค้างคา (แต่ก็ยังดีกว่า Barcamp ที่มีแค่ 30 นาที)

ปล.วันนี้เป็นครั้งแรกนับตั้งแต่ฝึกงานที่ได้ลง BTS เพลินจิตเรื่องเล็กๆแต่ความทรงจำไหลหลั่งมาเต็มๆ

Original post at: https://yothinix.blogspot.com/2013/12/agile-tour-bangkok-2013.html