เริ่มต้นคลานไปกับ #AgileThailand2012

เหตุเกิดเมื่อกลุ่ม Agile66 (สามารถร่วมพูดคุยกับพวกเค้าผ่านทาง Twitter หรือ Facebook) ซึ่งเป็นกลุ่มคนไทยที่สนใจในด้านการพัฒนาซอฟต์แวร์แบบ Agile ได้จัดงานพบปะเสวนาประสาคนทำ Agile ขึ้น นั่นคืองาน Agile Thailand 2012 นั่นเอง จัดขึ้นเป็นครั้งแรก รับแค่ 66 คนเท่านั้น! (จำนวนจริงๆ ที่มาร่วมงานประมาณ 80 กว่าคน) เปิดขายบัตรราคา 200 บาท แล้วก็เต็มภายในเวลา 2 นาที ผมโชคดีได้มีโอกาสเป็นส่วนหนึ่งที่ได้เริ่มคลานไปงาน เลยอยากจะขอเอาสิ่งที่ได้รับมาเขียนบอกต่อ

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

@nattyait ภูมิใจเสนอสปอนเซอร์และตารางพูดของเหล่า speaker ทั้งหลาย

ส่วนหัวข้อที่เค้าจัดมาเสวนากันก็มีดังนี้

• การ์ดพลัง Agile และ Agile Practices โดย @juacompe
• Personal Agility & Agile Environment โดย @arunthep
• Continuous Delivery โดย Athiwat
• TDD เข้าเส้น ตอน ปฐมบทการโค้ดแบบ Agile โดย Varokas
• คุณลูกค้ากับอไจล์ (Product Owner in Agile Project) โดย @nattyait
• Kanban ตกลงมันคืออะไรกัน! โดย @kluak110
• Triple P: The Power of Pair Programming โดย @roofimon
• Release Planning & Estimation Agile Way โดย @sinapam
• Lesson Learns from Adopting Agile โดย @zyracuze
• Agile in Waterfall โดย @korn4d
• จริงหรือไม่? - อไจล์แล้วอยู่ยาก โดย @tnwt28
• Agile จาก หมากล้อม โดย Karan
• CI กับการพัฒนา Software อย่างยั่งยืน โดย @sinapam
• The Dot Game - ทำไมอไจล์จึงเร็วส์ โดย Varokas
• SCRUM 1-2-3 โดย Varokas
• ATDD โดย @kluak110 กับ @sinapam
• Agile Coaching โดย @korn4d

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

การ์ดพลัง Agile โดย @juacompe และมี @nattyait เป็นลูกมือ (สไลด์)

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

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

การ์ดในเกม Agile ตอนนี้มีอยู่ 3 แบบ คือของ Pair programming ของ Code review และของ Ace a test (ชื่อนี้เป็นชื่อที่ @juacompe ตั้งขึ้นมาเอง) มีการกำหนดว่าแต่ละการ์ดควรจะมีค่าอย่างไรบ้าง ควรมีเงื่อนไขอะไรบ้าง โดยเราจะประชุมกันว่าเราควรจะมีการ์ดอะไรบ้าง แต่ละการ์ดควรจะมีพลังอะไร แต่ละค่าพลังสามารถสื่อถึงอะไรได้บ้าง มีเงื่อนไขอย่างไร

ลองมาดูวิธีคิดค่าพลังคร่าวๆ ของการ์ดสักใบกัน ยกตัวอย่างการ์ด Pair programming โดยปกติแล้วการทำ Pair programming คือเราจะใช้โปรแกรมเมอร์ 2 คนช่วยกันทำ Story เดียวกัน โดยมีหลักว่า 2 คนรวมหัวกัน จะสามารถทำงานได้มีประสิทธิภาพมากขึ้น มีการคุยกันและการแลกเปลี่ยนความคิดกันมากขึ้น แต่อาจจะทำงานได้ช้าลง ดังนั้นการ์ดใบนี้อาจจะให้ค่า Communication ไว้สูง แต่ใช้การ์ดใบนี้ก็อาจจะทำงานได้ช้าลงจาก 2 เท่า ก็อาจจะเป็น 1.5 เท่า

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

ตอนท้ายก็ให้ทดลองเล่นเกมกัน ให้แต่ละคนในทีมเลือกการ์ดหรือไม่เลือกก็ได้ แล้วเอามาคำนวณแต้ม ใครอยากลองเล่น เชิญได้ที่นี่ครับ >>เอาการ์ดมาทำเกม<< มีคนแอบกระซิบดังๆ มาว่าตอนนี้กำลังทำแอพบน iOS อยู่ด้วย

คุณลูกค้ากับอไจล์ (Product Owner in Agile Project) โดย @nattyait และมี @juacompe เป็นลูกมือ (สไลด์)

คนส่วนใหญ่จะมองข้ามบทบาทของ Product owner ใน Agile project และจะเห็นความสำคัญของ Scrum master มากกว่า ซึ่งจริงๆ แล้ว Product owner นั้นก็มีบทบาทหน้าที่ๆ สำคัญไม่แพ้ Scrum master เลยทีเดียว ลองดูรูปข้างล่างประกอบ

รูปจาก Stuff about Scrum

มีประโยคจากหนังสือ Agile Product Management with Scrum ของ Roman Pichler เกี่ยวกับ product owner และ Scrum master ไว้สั้นๆ ดังนี้

Product Owner is responsible for the "WHAT." -- creating the right project
Scrum Master is responsible for the "HOW." -- using Scrum in the right way

ข้างต้นนี้ชี้ให้เห็นว่าต่างคนต่างมีหน้าที่ๆ แตกต่างกัน และสำคัญพอๆ กันที่จะทำให้โปรเจคที่ออกมาตรงความต้องการ และประสบความสำเร็จ

ในการทำ Scrum นั้น Product owner จะทำหน้าที่เหมือนกับลูกค้า ซึ่งถ้าเป็นลูกค้าจริงๆ ได้ยิ่งดี และเป็นเจ้าของ Requirement รวมทั้งมีส่วนร่วมในการเข้าร่วม Scrum หน้าที่หลักๆ ของ Product owner นั้นนอกจากจะเป็นคนที่ให้ Requirement ให้ Feature แล้ว ยังเป็นคนคอยจัดลำดับความสำคัญของ Feature อีกด้วย อีกทั้งเป็นคนที่เห็นว่าสุดท้ายแล้วงานจะมีหน้าตาเป็นอย่างไร ทำอะไรได้บ้าง ซึ่งก็มีสิทธิที่จะให้ผ่านหรือไม่ให้ผ่าน

การที่ Product owner จะไปเข้าร่วมกับ Agile project ได้นั้น ตัว Product owner จะต้อง Agile ด้วย งานจะไปได้อย่างราบรื่น และ Product owner นั้น ควรจะต้องเรียนรู้ที่จะทำให้ทีมได้เห็นคุณค่าและลำดับความสำคัญของงานนั้นๆ อาจจะทำโดยการสร้าง Story ขึ้นมาใส่ Backlog จัดลำดับความสำคัญของ Story จากมากไปน้อย มีการสร้างความเชื่อใจให้กับลูกค้า (ในกรณีที่ Product owner เป็น Client proxy) โดยการเพิ่มความสามารถในการ "เดา" หรือประเมินว่างานจะเสร็จเมื่อไหร่ให้ลูกค้าได้รับรู้ แล้วที่สำคัญก็อย่าลืมว่าจะต้องส่งมอบสิ่งที่มีคุณค่าต่อลูกค้าให้ อะไรที่ไม่มีคุณค่าก็เก็บเอาไว้ก่อน ตอนแรกเริ่มอย่าคาดหวังมากนักว่าจะประเมินได้แม่นยำ 100% เพราะว่าการที่จะประเมินว่างานจะเสร็จเมื่อไหร่ได้อย่างถูกต้อง จะต้องให้งานเริ่มเดินไปแล้วสักพักหนึ่งก่อน แล้วถึงจะประเมินได้แม่นขึ้นเรื่อยๆ

Continuous Delivery โดย คุณ Athiwat

ปัญหาที่มีอยู่ของ Agile จะอยู่ในส่วน Integration กับ Release คือถ้าสมมุติว่าเราทำซอฟต์แวร์เสร็จแล้ว เราอาจจะต้องเสียเวลาทดสอบอีก แล้วตอน Deploy ระบบก็อาจจะมีปัญหาขึ้นอีก วิธีแก้ปัญหาคือให้เราทำ Continuous delivery คือให้เรา Release บ่อยๆ นั่นเอง คอนเซ็ปนี้จะเป็นคอนเซ็ปเดียวกับ Lean startup คือให้เราปล่อยของออกไปก่อน แล้วรับ Feedback กลับมาปรับปรุง แล้วก็ปล่อยของออกไปใหม่ เป็น Cycle อย่างนี้เรื่อยๆ

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

หลักการหลักๆ ในการทำคือ โปรเซสในการ Release จะต้อง Repeatable และ Reliable สามารถทำ Automate ได้ทุกอย่าง อะไรที่เสี่ยงหรือทำได้ยากนั้นให้เราทำบ่อยขึ้น ทดสอบให้มากขึ้น เก็บทุกอย่างใน Source control ทุกคนมีส่วนร่วมในการ Release ซึ่งโดยปกติแล้วทีมแต่ละทีมไม่ว่าจะเป็นทีมพัฒนาหรือทีมทดสอบระบบจะมีจุดมุ่งหมายต่างกัน มีความต้องการต่างกัน ดังนั้นเวลา Release เราจะต้องมาคุยกัน มาประชุมกัน และตั้งเป้าหมายให้ตรงกัน

หัวใจสำคัญอย่างหนึ่งของ Continuous delivery คือ Deployment pipeline ซึ่งเป็นขั้นตอนของการทดสอบ และจะต้องผ่านขั้นตอนเหล่านี้ให้ครบก่อนถึงจะ Release ได้ เส้นประแต่ละเส้นหลังจากที่เรา Commit เข้า Version control แล้วก็คือการทดสอบระบบด้วยเทคนิคและวิธีต่างๆ กัน ลองดูรูปข้างล่างนี้

รูปจาก Wikipedia

จากรูปข้างบน กล่าวคือเริ่มต้นเรา Check-in ไปที่ Version control แล้วก็ต่อด้วย Build & unit tests ถ้าเกิดข้อผิดพลาด (สีแดง) ระบบก็จะแจ้งเตือนกลับมาหาเรา (เราได้รับ Feedback) พอเราแก้เสร็จก็ให้ทำขั้นตอนเดิมกลับไป ทำจนกว่าจะผ่าน (สีเขียว) ซึ่งถ้าไปติดสีแดงอีก เราก็จะกลับมาทำใหม่ ทำแบบนี้ไปเรื่อยๆ จนทุกอย่างผ่าน เป็นสีเขียวหมด

Release planning & Estimation the Agile Way โดย @sinapam (สไลด์)

หนังสือ Agle Estimation and Planning โดย Mike Cohn เป็นหนังสือเล่มหนึ่งที่ @sinapam แนะนำให้ผู้เริ่มต้นจะทำ Agile อ่าน

ปัญหาในการวางแผนแบบเก่า เนื่องจากเป็นการวางแบบตาม Acitivity ซึ่งไม่เกี่ยวข้องอะไรกับ Feature เลย และไม่เน้นไปท่ี่การทำ Feature ด้วย ตามความเป็นจริงแล้ว Activity นั้นไม่เคยเสร็จก่อนเวลา (หรือมีโอกาสน้อยมากที่จะทำโปรเจคนั้นเสร็จก่อนเวลา) อีกทั้งยังมี Dependencies เยอะ เช่น ถ้าอันไหนช้า อันอื่นก็จะช้าตาม ดังนั้นการวางแผนแบบนี้เหมือนเป็นการหลอกตัวเอง ไม่รองรับการเปลี่ยนแปลงใดๆ ที่สำคัญคือการวางแผนแบบนี้ไม่รวมถึงความไม่แน่นอนในการทำงานเข้าไปด้วย

การวางแผนแบบ Agile มีสิ่งที่เหนือกว่า คือมีการอัพเดทเปลี่ยนแปลงอยู่เรื่อยๆ ไม่มีการวางแผนล่วงหน้าไปไกลเกินไป การวางแผนแบบนี้มีการแยกเวลาการทำงานกับ Effort ที่ใช้แยกออกจากกันอย่างชัดเจน แผนงานมีความโปร่งใส ลูกค้าสามารถตรวจสอบได้ว่างานไหนเสร็จ งานไหนยังไม่เสร็จ ที่สำคัญคือเราวางแผนตาม Feature และเราให้ความสำคัญกับสิ่งที่สำคัญ (สิ่งที่มีคุณค่าต่อลูกค้า)

Feature ที่กล่าวไป เราจะนำมาเขียนเป็น User story ซึ่งเป็น Requirement จากมุมมองของลูกค้า เขียนให้เป็นภาษาที่สามารถเข้าใจได้ง่าย พยายามอย่าให้มีเรื่อง Technical มาเกี่ยวข้องให้เยอะเกินไป สิ่งที่สำคัญใน User story ที่ดีคือจะต้องบอกว่า ใคร (Who) อะไร (What) และทำไม (Why) ทุกคนในทีมจะได้เข้าใจตรงกันว่าใครต้องการอะไรแล้วทำไปเพื่ออะไร สิ่งที่สำคัญอย่างอื่นคือ Exit criteria, Estimate และ Discussion

Story ที่ดีจะต้อง I.N.V.E.S.T.

• Independent - จบได้ด้วยตัวเอง
• Negotiable - ต่อรองเจรจากันได้ ปรับเปลี่ยนได้
• Valuable - มีคุณค่าต่อลูกค้า
• Estimable - ประเมินได้
• Small - เล็กที่สุดเท่าที่จะทำได้ ในเวลานั้นๆ ในอนาคตอาจมีการเปลี่ยนแปลงได้ Story นี้อาจจะแตกเล็กต่อไปได้อีก
• Testable - สามารถทดสอบได้

การ Estimate ตัว Story แต่ละตัว ให้มองว่าเป็นกี่เท่าๆ จะ Estimate ได้ง่ายกว่าบอกค่าจริงๆ ในการคิด แล้วก็ควรจะให้ Developer กับ Tester มานั่งปรึกษากันด้วย แล้วมาตกลงกันว่าจะใช้ชุดลำดับของตัวเลขอะไรในการ Estimate ชุดลำดับของตัวเลขที่นิยมใช้กันก็เช่น เลขลำดับ Fibonacci เป็นต้น ถ้าใช้ลำดับเลขธรรมดาล่ะ? เช่น 1, 2, 3, ... ลำดับพวกนี้อาจจะเกิดปัญหาเวลาเราเลือกค่า สมมุติเลือก 5 กับ 6 เราจะบอกความแตกต่างได้ค่อนข้างลำบาก เราอาจจะเถียงกันไม่จบไม่สิ้นว่างานนี้ควรจะเป็น 5 หรือ 6 ดี แต่ถ้าเป็นเลข Fibonacci จะเป็นเลข 5 กับ 8 เราจะเห็นความแตกต่างกันชัดเจนมากขึ้น

ในการที่จะตกลงกันว่า Story แต่ละอันจะมีค่าเท่าไหร่ มีวิธีหนึ่งคือใช้ Planning poker คือประมาณว่าให้ทุกคนลงไพ่ของตัวเองออกมาพร้อมกัน โดยตัวเลขบนไพ่นั้นคือ ค่า Estimate ของ User story นั้นๆ ถ้าคิดไม่ตรงกันก็จะได้คุยกัน แล้วก็ให้โหวตใหม่ จนกว่าทุกคนจะเห็นพ้องต้องกัน ได้เลขเดียวกัน วิธีแบบเก่าคือให้บอกเลขมาทีละคน ซึ่งวิธีนี้คนที่บอกเลขทีหลังอาจจะถูกครอบงำความคิดโดยคนที่บอกก่อน ดังนั้นวิธี Planning poker มีข้อดีคือ ต่างคนต่างจะได้ใช้ความคิดของตัวเองในการ Estimate ไม่ถูกครอบงำโดยความคิดของคนอื่น

คำที่เจอกันบ่อยในการทำ Agile คือ Velocity ซึ่งเป็นค่าเฉลี่ยของจำนวน Story point ที่ทำได้ใน 1 Iteration ตอนแรกอาจจะยังไม่รู้ แต่พอได้ทำไปสักพักก็จะสามารถรู้ได้เอง จะค่อยๆ แม่นยำมากขึ้น เราสามารถนำค่านี้ไปประเมินแล้วบอกได้ว่า Release ครั้งต่อไปจะเสร็จเมื่อไหร่

ในการแสดงให้ลูกค้าเห็นถึงความโปร่งใสของการทำงานของเรา เราจะใช้ Burn down chart (ดูรูปข้างล่างประกอบ) โดยมีแกน Y คือจำนวน Point ของ User story (หรืออาจจะเป็นจำนวน Story ที่เหลือใน Backlog ก็ได้) และแกน X คือจำนวน Iteration สิ่งที่เห็นชัดๆ คือเวลาที่มี Requirement เพิ่ม กราฟจะพุ่งขึ้น การทำแบบนี้เราก็สามารถ Estimate ในขณะนั้นได้ว่างานเราจะเสร็จเมื่อไหร่ กราฟ Burn down นี้จะเปลี่ยนแปลงตลอดเวลาหลังจากเสร็จทุกๆ Iteration หรือ Release นั้นๆ

รูปจาก Wikipedia

สุดท้ายหัวใจของการทำ Agile คือการทำ Priorization เราต้องจัดลำดับความสำคัญของ Feature โดย Feature ที่มีคุณค่ากับลูกค้ามากที่สุดอยู่อันดับแรก หรือจัดลำดับตามของที่มีความเสี่ยงสูงให้อยู่อันดับแรกก็ได้

Continuous Integration การพัฒนา Software อย่างยั่งยืน โดย @sinapam

การทำ Continuous integration (CI) ก็ถือว่าอยู่ในส่วนของ Continuous delivery ด้วย คนส่วนใหญ่จะมีความเชื่อที่ว่า "Integration มันยาก เก็บไว้ทำทีหลังก็แล้วกัน" ความเชื่อแบบนี้ทำให้เกิดปัญหาตามมาเยอะพอสมควร เช่น การ Test ไม่ผ่าน และพอเวลาซอฟต์แวร์ทำงานผิดพลาด เราก็จะหาไม่เจอว่าผิดตรงไหน (เนื่องจากเราไม่ได้ Integrate กันบ่อยๆ การหาข้อผิดพลาดจะทำได้ยากขึ้น)

ประเด็นก็คือว่า ถ้าเราทำบ่อยๆ ทีละน้อย เราจะเห็นความแตกต่างกันได้ดีกว่า นานๆ ทำที หรือรอให้งานใหญ่ๆ ก่อนแล้วค่อย Integrate กัน ในการ "ทำ" CI เราต้องพึงระลึกไว้อยู่เสมอว่าเราจะต้อง Integrate โค้ดเป็นประจำ ส่วนการ "ใช้" CI จะเป็นแค่การใช้ Tool ที่เกี่ยวข้องกับ CI เท่านั้น ในส่วนนี้ชี้ให้เห็นได้ชัดว่าตัว "คน" เป็นสิ่งสำคัญที่สุดที่จะทำให้เกิดผล ไม่ว่าเราจะใช้ Tool ดีแค่ไหน ถ้าคนไม่มีวินัยหรือไม่ทำตาม สุดท้ายแล้วก็ไม่สามารถแก้ปัญหาได้อยู่ดี

ในการสร้าง Environment ของ CI ก็คือให้เรามี Robot ไว้ตัวหนึ่ง ไว้คอยถามอยู่ตลอดเวลาว่าโค้ดของเราที่ commit ไปนั้นมีอะไรเปลี่ยนแปลงบ้าง ถ้ามีแล้ว Test ผ่านหมดหรือไม่ ถ้าไม่ผ่านก็จะแจ้งเตือนกลับมายัง Developer

เช่าทีม โดย @juacompe และมี @nattyait เป็นลูกมืออีกเช่นเคย 😀 (Session นี้จะเน้นการแชร์ประสบการณ์กัน อยากให้รอดูวีดีโอจากทีมงานดีกว่า)

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

ขอพูดถึงงานนี้บ้าง

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

สุดท้ายก็ขอขอบคุณทีมงาน Agile66 ทุกคน แล้วก็ขอรบกวนให้จัดปีหน้าด้วยนะครับ ฮะๆ

ขอบคุณรูปจาก @zyracuze ครับ -/\-

สไลด์ของ Session อื่น

• PPP: The Power of Pair Programming
• TDD เข้าเส้น ตอน ปฐมบทการโค้ดแบบอไจล์
• The Dot Game - ทำไมอไจล์จึงเร็วส์
• SCRUM 1-2-3
• Agile จาก หมากล้อม
• Kanban ตกลงมันคืออะไรกัน!

ส่วนวีดีโอทั้งหมดสามารถหาดูได้ที่ Agile66 - YouTube ครับ

ส่วนใครที่แวะมาอ่านบล็อกผมแล้ว ขอเชิญให้ไปแวะบล็อกชาวบ้านด้วยนะครับ 😉

• Power of Pair Programming: Agile Thailand 2012

สุดท้ายนี้สำหรับคนที่ไปงานมา ขอเชิญไปเขียน Retrospect กันด้วย เค้าจะได้เอาไปปรับปรุงแก้ไขนะจ๊ะ