Agile Tour Bangkok 2013 :: งานรวมพล คนอไจล์ ส่งท้ายปี

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

http://www.derailleurconsulting.com/blog/complexity-and-noise-in-systems-development-projects

       นอกจาก 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 แทน

http://theconsciousaim.com/2013/03/15/brasilia-attempts-to-build-the-future/

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

http://discoveringurbanism.blogspot.com/2009/11/walking-paths-of-brasilia.html

       สิ่งที่เกิดขึ้นคือ มันมีคนเดินถนนครับ แล้วคนเหล่านั้นได้สร้างเส้นทางที่เห็นดังภาพข้างบนขึ้นกลางเมือง ซึ่งการที่คนจะข้ามจากทุ่งฝั่งนึงไปอีกฝั่งนึงได้ต้องผ่านถนน 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 เพลินจิต เรื่องเล็กๆ แต่ความทรงจำไหลหลั่งมาเต็มๆ