ผ่านไปแล้วอีกหนึ่งกิจกรรมของกลุ่มเราครับ … C.M.3 — User Story for Agile Development ที่เราใช้เวลาส่วนใหญ่ไปในการทำ Workshop ฮ่าๆ ส่วนตัวแล้วการพบปะพูดคุยครั้งนี้ถือว่าประสบความสำเร็จนะครับ

1. ได้รู้จักเพื่อนใหม่เพิ่มขึ้น 4 คน … ที่เหลืออีก 7 คนก็ขาประจำ
2. ได้มีโอกาสได้ถ่ายทอดแนวคิดการทำงานแบบ Agile (อย่างย่อ) ภายในเวลา 15 นาทีให้เพื่อนๆได้ฟังกัน
3. ได้มีโอกาสลงในรายละเอียดของคำว่า User Story … และกระบวนการที่จะได้มาซึ่ง User Story ที่ดี … Workshop แรกของเราได้ผลดีเกินคาด ทั้งสองกลุ่มเขียน User Story ออกมาได้ชัดเจนและถูกต้องครับ ปรบมือให้ตัวเองดังๆ 10 แปะ
4. ได้มีโอกาสนำเสนอแนวทางการ Estimate แบบใหม่โดยใช้ Story Point … Workshop ที่สอง อันนี้ก็มันส์มาก ได้เล่น Planning Poker มีการถกเถียงกันเพื่อหา Point ที่เหมาะสมของแต่ละ User Story … ผลที่ได้มาก็ยอดเยี่ยมเลย
5. ได้มีโอกาสลองทำ Project Plan แบบ Agile และมีตัวอย่าง Burndown Chart รวมถึงหลักการอ่านและตีความหมายของกราฟให้ดูกันด้วย
6. ได้มีโอกาสถาม-ตอบและแลกเปลี่ยนความคิดเห็นกันระหว่างพวกเรา
7. สุดท้าย ได้กินกาแฟอร่อย แถมราคาย่อมเยาอีกต่างหาก … ขอบคุณเจ้าของสถานที่มากๆครับ

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

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

ของฝากจากพวกเรา

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

กิจกรรมหน้า

ยังคิดไม่ออกว่าจะคุยกันเรื่องอะไรดี ใครสนใจเรื่องไหนบอกได้นะ จะพยายามจัดให้ … ที่แน่ๆก็จะเป็นประมาณสัปดาห์ที่สามของเดือนกันยายน สถานที่ก็เหมือนเดิมครับ Art Element: School of Art

ลงทะเบียนครบ 15 คนเรียบร้อย … ขอบคุณมากที่ให้ความสนใจกันนะครับ รูปแบบการจัดกิจกรรมครั้งนี้ก็จะแตกต่างไปจากเดิมนิดหน่อยตรงนี้จะมี Workshop ให้ทำกันด้วย ลองดูรายละเอียดเลยครับ

รูปแบบกิจกรรม

ช่วงแรกผมจะเล่าให้ฟังอีกรอบว่า Agile Development คืออะไรเพื่อเป็นการเกริ่นนำถึงสิ่งที่เรากำลังจะทำ Workshop กันครับ หลังจากนั้นก็จะเริ่มโฟกัสที่เรื่องของ User Story กันเลย จบแล้วก็จะแบ่งเป็นสองกลุ่มเพื่อเริ่ม Workshop ที่ 1 โดยให้ลองสร้าง User Story ของเราเองครับ ผมจะกำหนด Case Study ให้ เสร็จแล้วก็จะขอตัวแทนกลุ่มออกมานำเสนอผลงานนิดนึงนะ

ต่อไปก็จะเป็นเรื่องของ Story Point ซึ่งเป็นการทำ Estimation ในรูปแบบ Agile Development ผมจะเล่าให้ฟังถึงหลักการและกระบวนการตรงนี้ก่อนที่เพื่อนๆจะได้ลองทำ Workshop ที่ 2 ซึ่งก็คือ Planning Poker เพื่อหา Point ของแต่ละ Story ที่เขียนมากันครับ … เสร็จแล้วก็ขอตัวแทนนำเสนอผลงานเหมือนเดิม

สุดท้ายเราจะมาลองทำ Iteration Planning ร่วมกันทั้งสองกลุ่มครับ ผมจะมีตัวอย่าง Project Plan แบบ Agile Development มาให้ลองดูลองเล่นกันฮะ … แล้วก็จบกิจกรรม

ข้อมูลเพิ่มเติม

สำหรับเพื่อนๆที่ยังไม่คุ้นเคยกับ Agile Development ผมแนะนำว่าถ้ามีเวลาก็ลองอ่านบทความข้างล่างดูครับ

Agile Manifesto: การ์ตูนเรื่องนี้ชี้ให้เห็นถึงปัญหาที่พวกเราเจอกันอยู่ประจำใน Software Development Project และเป็นแรงบันดาลใจของคำประกาศ 4 ข้อซึ่งเป็นพื้นฐานของ Agile Development

Waterfall, Iterative, or Agile: เป็นบทความที่เปรียบเทียบความเหมือนความต่างระหว่าง Software Development Life Cycle ที่ได้รับความนิยม 3 ประเภทครับ อ่านแล้วเพื่อนๆจะได้ข้อมูลมากขึ้นว่า Agile Development คืออะไร เหมาะกับงานแบบไหน

Extreme Programming (XP): บทความนี้จะเล่าให้ฟังว่าการทำงานด้วย Extreme Programming (XP) นั้นเป็นอย่างไร มีข้อดีอะไรบ้างกับตัวคนทำงานและองค์กร หลายคนอาจจะสงสัยว่า XP คืออะไร? … มันคือรูปแบบการทำ Software Development ที่ประยุกต์ใช้หลักการของ Agile Development เข้ามา

Agile Development – Videos: เป็น Screencast ที่ผมพูดถึงหลักการที่สำคัญของ Extreme Programming (XP) เอาไว้ครับ ดูวิดีโอแล้วเพื่อนๆจะเข้าใจมากขึ้นว่า User Story คืออะไร

การเดินทาง

สุดท้ายขอฝากวิธีเดินทางไปยังจุดนัดหมายที่ Art Element: School of Art อย่างละเอียดครับ

แบบประหยัดก็รถเมล์

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. จากนั้นเดินตรงไปแยกคลองเตยแล้วเลี้ยวซ้ายจะเจอป้ายรถเมล์ให้ขึ้นรถเมล์
3. สาย 22 / 45 / 46 /115 / 116 / 149 / 507 ได้หลายสายครับ บอกเค้าลงตรงป้ายองค์การโทรศัพท์ (รถมันจะผ่านจุดสังเกตทางด้านซ้ายมือเรียงลำดับดังนี้ 1.โชว์รูม BMW 2.สี่แยกเกษมราษฎร์ 3.คาร์ฟูร์ พระรามสี่ ฝั่งขวาเป็นโลตัส 4 สถานีโทรทัศน์ช่องสาม ตึกมาลีนนท์)
4. พอถึงตึกมาลีนนท์ก็กดกริ่งลงได้เลยครับ
5. จากนั้นให้เดินข้ามถนนเข้ามาที่ซอยอุทัยฟาร์มซึ่งจะอยู่ระหว่างองค์การโทรศัพท์กับตึก Green Tower ถ้าข้ามสะพานลอยให้หน้าเข้าป้ายรถเมล์แล้วเลี้ยวมาทางขวามือแล้วเดินตรงมาจะเจอซอยแรกเลยครับ (ก่อนถึงตึก Green Tower)
6. เดินเข้ามาประมาณ 50 เมตรก็เจอแล้วครับ อยู่ทางซ้ายมือ

แบบด่วนก็มอเตอร์ไซค์

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. จากนั้นเดินตรงไปแยกคลองเตย เจอวินมอเตอร์ไซค์ ขึ้นเลยบอกว่าไปซอยอุทัยฟาร์มตรงตึก Green Tower ครับ 30 บาท

แบบมาเป็นกลุ่มก็แท๊กซี่

1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
2. เรียก Taxi แล้วดูตามแผนที่ครับ บอกว่าไปตรงข้ามช่อง 3

แบบขับรถมาเอง

1. มาตามเส้นทางข้างบน
2. จอดรถที่ตึก Green Tower หน้าปากซอย ชั่วโมงละ 20 บาทครับ

เจอกันเสาร์นี้ครับ

ต่อเนื่องจากบทความเก่าที่ว่าด้วยเรื่องของ Change สาเหตุหนึ่งที่ผมกล่าวถึงในนั้นก็คือบางครั้งการทำ Requirement Analysis และ Software Design ที่ไม่ครอบคลุมจะมีผลทำให้เกิด Change ตามขึ้นมาได้ (มากบ้าง น้อยบ้าง) นี่คือที่มาของบทความนี้ครับ … มันคงดีถ้าเรามี Requirement Analysis และ Software Design ที่มีประสิทธิภาพมากกว่าเดิม

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

1. ไม่มีเวลาพอที่จะทำ Analysis และ Design … ไม่แปลก เวลาเขียนโค๊ดก็แทบจะไม่มีอยู่แล้ว
2. คุยแล้วก็ไม่ค่อยละเอียดเท่าไร … ก็ไม่รู้ว่าต้องใส่ใจเรื่องอะไรบ้างนี้ บางทีตอนนั้นก็นึกไม่ออกด้วย
3. บางครั้งคิดได้แล้วนะ แต่ก็ลืม … ไม่มีเวลามานั่งทำ Design Document เล่มใหญ่ๆหรอก

แล้วก็มาถึงวิธีแก้ไขในความคิดผม จะผิดจะถูกก็แล้วแต่วิจารณญาณของเพื่อนๆครับ

เรื่องของเวลา

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

ทำไมผมถึงแนะนำแบบนี้? จำกฎ 80/20 ได้มั้ยครับ? “มีคนแค่ 20 % ในห้องประชุมที่มีส่วนร่วมอย่างจริงจัง (ฟัง พูด อ่าน เขียน) … ที่เหลือ 80% เข้ามาทำไม?!!” การประชุมเป็นเรื่องที่กินเวลามากเลยถ้าบริหารจัดการไม่ดีซึ่งการทำ Requirement Analysis และ Software Design ก็เป็นรูปแบบหนึ่งของการประชุม (ไม่ว่าจะเป็นทางการหรือไม่เป็นทางการ) ดังนั้นแบ่งกลุ่มซะครับ เลือกเฉพาะคนที่จำเป็นต้องรู้ จำเป็นต้องทำ จำเป็นต้องตอบคำถามจริงๆในการคุยเรื่องนี้ ที่เหลือก็ปล่อยเค้าไปตั้งกลุ่มพูดคุย Requirement อื่นๆครับ การจะทำแบบนี้ได้ตั้งอยู่ด้วยพื้นฐานสองข้อที่ต้องยอมรับ

1. ทุกคนไม่จำเป็นต้องรู้ในรายละเอียดทุกเรื่อง และ
2. ต้องแบ่งงานให้เล็กลงในระดับที่เหมาะสม … ถ้าโอเคหละก็ลองใช้วิธีนี้ได้ครับ

เรื่องของมุมมอง

ส่วนตัวมองว่ามันหมดยุคที่แบ่งแยกงานระหว่าง Developer กับ Tester ขาดออกจากกันแล้วนะครับ ประเภทที่ว่าฉันมีหน้า Design + Code + Unit Test ไปเธอไม่ต้องมายุ่ง เจ้าตัว Tester ก็ไม่สนเรื่องอื่น นั่งรอรับของมาทำ System Test อย่างเดียวมันล้าสมัยไปแล้วอะครับ ทำไมหนะหรอ? ก็เพราะว่ามันพิสูจน์มาแล้วว่า Developer ไม่ใช่พระเจ้าที่จะ Design หรือ Code อะไรแล้วถูกต้องหมด เห็นออกจะบ่อยที่ Developer บอกกับ Tester หลังเจอบั๊กว่า “อ่าว เออ ต้องมีแบบนี้ด้วยหรอ ไม่ได้คิดไว้เลยอะ โทษทีๆ” … แล้วก็ต้องเสียเวลาแก้กันอีก ในมุมกลับกัน มีหลายครั้งที่ Tester ไม่ได้เทสบางส่วนแล้วมันก็กลายเป็นบั๊กที่หลุดไปถึงลูกค้า และ Tester ก็มาบอกเหมือนกันว่า “อ่าว เออ ต้องเทสแบบนี้ด้วยหรอ ไม่ได้คิดไว้เลยอะ โทษทีๆ” ฮ่าๆ

ทางทีดีเราควรเปิดโอกาสให้ทุกคนที่มีส่วนร่วมกับงานตรงนี้ได้มีสิทธิมีเสียงในการแสดงความคิดเห็นตั้งแต่ต้น นั่นก็คือให้โอกาสเค้าร่วมทำ Requirement Analysis และ Software Design ด้วยกันเลย การรวมกลุ่มตรงนี้จะประกอบไปด้วย Developer + Tester + Product Manager (หรือตัวแทนลูกค้าที่ตอบคำถามในเรื่อง Requirement ได้) + Domain Expert (ผู้เชี่ยวชาญด้านต่างๆ เช่น Database Expert, Security Expert หรือ Network Expert) ด้วยหลักการหนึ่งข้อคือ “ทุกคนในกลุ่มต้องมีหน้าที่ของตัวเอง” ต้องไม่มีใครที่เข้ามานั่งจ๊อง ฟังเฉยๆ ไม่พูด ไม่จด ไม่ออกความเห็น … แบบนี้ห้ามครับเพราะมันเสียเวลาเค้าเปล่าๆ ทำแบบนี้จะเป็นการเปิดมุมมองใหม่สำหรับ Requirement Analysis และ Software Design เมื่อประกอบกับการที่เรามีหลักการในการพูดคุย (แนะนำ Operational Concept) แล้วด้วย ผลที่ได้น่าจะดีขึ้นครับ

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

1. เด็กสมัยนี้เก่งนะ มุมมองกว้างกว่าเราด้วยในบางเรื่อง เช่น Technology การให้โอกาสเค้าจะเป็นการแก้ปัญหามุมมองที่ตีบตันของตัวเราเองได้ครับ
2. เป็นการพัฒนาทักษะและความสามารถให้น้องๆในทีมด้วย ทั้งเรื่องของ Technical Skill เรื่องของการทำงานเป็นทีม ฝึกการเป็นผู้นำ ฝึกการเป็นผู้ตาม และอีกมากมาย

เรื่องของเอกสาร

เรื่องนี้พูดเท่าไรก็ไม่จบเนอะ ฮ่าๆ … ปัญหาอยู่ที่ว่าความสมดุลอยู่ที่ไหน? ครั้นจะตะบี้ตะบันทำเอกสารเล่มหนาปึ้กก็เสียเวลาและไม่มีอะไรมารับประกันได้ว่าจะไม่มีอะไรเปลี่ยนแปลงภายหลัง ส่วนครั้นจะไม่ทำเลยก็จะมีปัญหาอีกว่า แล้วจะเอาอะไรเป็นตัวอ้างอิงเวลาทำงานกันหละ บางครั้งคนเราก็หลงๆลืมๆ พูดอย่างทำอีกอย่างก็บ่อยไปเนอะ ทางออกสำหรับเรื่องนี้มีอยู่ว่า …

ก่อนอื่นเราต้องบอกตัวเองว่า “เราจะทำเอกสารเท่าที่จำเป็นจริงๆ” แค่นั้นพอ มาดูกันว่าอะไรที่จำเป็นจริงๆบ้างหละ? เอกสารที่จำเป็นก็จะต่างกันไปสำหรับแต่ละ Project นะ  ยกตัวอย่างง่ายๆก็เช่น

1. Business View ซึ่งเป็นที่มาของ Workflow ที่คนทำงานควรจะต้องรู้ รวมถึงการเชื่อมโยงของงานส่วนนี้กับระบบโดยรวมทั้งหมด
2. ตัวแทนของ State Diagram ที่จะบอกเราได้ว่าทางเข้า-ทางออกของการทำงานตรงนี้คืออะไร เช่น ก่อนจะสร้าง User ได้ต้องมีเงื่อนไขอะไรบ้าง ถ้าสร้าง User สำเร็จขั้นตอนต่อไปคืออะไร แล้วถ้าสร้างไม่สำเร็จจะทำยังไง ประมาณนี้
3. ประเภทของ Input – Output ของแต่ละส่วน ซึ่งอาจจะเชื่อมโยงไปในเรื่องของการออกแบบ Database
4. หน้าจอ User Interface คร่าวๆว่าจะมีกี่ Textbox จะเป็น Dropdown list หรือ Radio Button ประมาณนี้
5. เรื่องอื่นๆ เช่น Security, Performance, และ Constraints ต่างๆที่ต้องคำนึงถึงด้วย
6. Acceptance Criteria ที่ควรจะต้องมีสำหรับงานส่วนนี้
7. อื่นๆ

แต่ต่อให้ทำแค่นี้ก็อาจจะเสียเวลาแปลงจากคำพูดและข้อตกลงในห้องประชุมมาเป็นเอกสารอยู่ดีแหละ ผมมีแนวคิดมาช่วยจัดการปัญหาตรงนี้นิดหน่อยครับ ด้วยความต้องการที่ว่า “มันน่าจะดีถ้าเราได้เอกสารออกมาทันทีหลังจากจบการประชุมเลยเนอะ” … ทำได้นะครับถ้าเรากำหนดไปเลยว่า Output ที่เราต้องการหลังจากจบการประชุมนอกเหนือจากข้อสรุปแล้วก็คือเอกสารตรงนี้แหละ โดยเรามอบหมายให้สมาชิกแต่ละคนที่เข้าประชุมรับผิดชอบเอกสารไปคนละแบบสองแบบ เช่น Developer 1 รับผิดชอบเขียน Workflow กับ UI รวมกับ Developer 2 เขียน State Diagram กับ Input/Output ส่วน Tester ก็รับ Acceptance Criteria ไป พยายามใช้บอร์ด กระดาษ ปากกา ดินสอ ขีดเขียนวาดรูปให้เยอะๆครับ เอาว่าให้อ่านแล้วเข้าใจกันได้ ถ่ายรูปแล้วเก็บไว้ … นี่ก็เป็น Design Document รูปแบบหนึ่งที่พอเพียงและใช้ได้จริง เราไม่ต้องไปเสียเวลาแปลงให้เป็น Word หรือ Visio ครับ

ยังไม่หมด ฮ่าๆ … ขั้นตอนสุดท้ายก็คือการบอกข้อมูลการ Design อย่างละเอียด (สุดๆ) ไว้ด้วยการ Comment Code ครับ ถ้าตรงนี้ทำได้ดีมันจะเป็น Design Document ที่มีประสิทธิภาพที่สุดเพราะว่าก็เห็นๆอยู่ว่า Code มันเขียนไว้แบบนี้แหละ อีกจุดหนึ่งที่สะท้อนให้เห็นถึง Design ก็คือ Acceptance Criteria หรือว่า Test Case ของเรานั่นเองครับ ถ้ามี Comment ไว้ด้วยก็จะดีมากเช่นกันครับ

เรื่องของ Change

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

หลังจากคิดอยู่นาน … สรุปว่า Chapterpiece.Meeting.3 จะพูดคุยกันเรื่อง User Story for Agile Development ครับ เหตุผลที่เลือกหัวข้อนี้ก็เพราะ:

• เป็นการต่อยอดความรู้จาก Chapterpiece.Meeting.1: Agile Development — First Chapter
• User Story เป็นเรื่องที่มีข้อสงสัยในความหมาย ประโยชน์และกระบวนการให้ได้มาซึ่งสิ่งนี้มากทีเดียว
• เป็นโอกาสอันดีที่เราจะได้ทำ Workshop กันครับ … เปลี่ยนบรรยากาศไปด้วย

สำหรับเพื่อนๆที่สนใจเข้าร่วมกิจกรรมครั้งนี้ ถ้าใครมีพื้นฐานเรื่อง Agile Development มาก่อนแล้วจะดีมากเลยครับ จะได้มาช่วยกันแชร์ประสบการณ์ ฮ่าๆ แต่ไม่ต้องกังวลไปสำหรับมือใหม่ (อยาก) หัดใช้ Agile … ผมจะเล่าที่มาที่ไปและหลักการของเจ้าวิธีการพัฒนาซอฟท์แวร์แบบใหม่นี้ให้ฟังกันก่อนครับ เอาแบบคร่าวๆนะ ใช้เวลาไม่เกิน 10 นาที

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

เรื่องสถานที่ ต้องขอบคุณ Art Element: School of Art ที่อำนวยความสะดวกให้เราได้ใช้สถานที่ฟรีเช่นเคย มีทั้งห้องแอร์ โปรเจกเตอร์ และมีร้านกาแฟข้างล่างด้วย … ไม่ต้องซื้อกาแฟจากข้างนอกเข้ามานะ