วันนี้ไปร่วมงาน agile thailand 2016 ถือว่าโชคดี เพราะว่าได้บัตรมาในรอบสุดท้าย ที่เป็นตั๋วหลุด 66 ใบ เพราะเห็นว่าเค้าเปิดมาเต็มแล้วเต็มอีกตั้งไม่รู้กี่รอบต่อกี่รอบ เอาจริงๆ ก็คือ บังเอิญโคจรมาเจอมากกว่า เพราะไม่เคยรู้เลยว่ามีกิจกรรมนี้ด้วย จนพี่ที่ office เอามา post ในคืนวันตั๋วหลุดนั่นแหล่ะ กด ปุ้บ จองปั้บเลย ด้วยความที่ส่วนตัวอยากรู้มานานแล้ว agile มันคืออะไรแน่ อ่านในเน็ตก็ งงๆ คนที่ office ส่วนใหญ่ก็ไม่รู้เรื่อง เจองานแบบนี้ ลุยเลยสักตั้งแล้วกัน จริงๆ ก็ถือว่าเป็นการออกจาก comfort zone ด้วยเหมือนกันเพราะว่าปกติ ไม่ค่อยอยากออกจากบ้านวันหยุดสักเท่าไร แต่ก็ตัดใจ ลองไปดูสักตั้ง แต่ทีแรก งง ว่าสัมมนาอะไรจะเช้าเวอร์ขนาดนั้น เพราะว่าเริ่มตั้งแต่ 08.30 เลย เลิกเอานู่น 18.00 แน่ะ

รูปแบบของงาน

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

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

Introduction agile

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

1. รวมใจ คนทำงาน ให้รวมเป็นหนึ่งเดียวกันให้ได้ (จริงๆ คือให้รวมไปที่เป้าหมายของงานนั้นๆ)
2. deliver คือการพยายามส่งมอบงานให้ได้เร็วที่สุดเท่าที่จะเป็นไปได้
3. reflect คือการ feedback คน งาน และอื่นๆที่เกี่ยวข้อง เหมือนเป็นกระจกสะท้อนส่องตัวเอง
4. improve คือการพัฒนาตัวเองตลอด เพราะทุกอย่างมันเปลี่ยนแปลงไปไม่เคยหยุด

*** คำเตือน เนื้อหาที่จะได้อ่านต่อจากนี้ อาจจะไม่ถูกต้องตรงตามที่บรรยายเป๊ะๆ เพราะว่าผมจะอาศัยความเข้าใจของผมใส่เข้าไปด้วย ถ้าไม่ถูกต้องก็มาแบ่งปันกันได้ด้วยความสุภาพ และเคารพซึ่งกันและกัน เราตรงไปตรงมา ไม่เสแสร้ง แต่ไม่ได้หมายความว่าจะหยาบคายได้ และเนื้อหา มาจากที่ผมเลือกเข้าฟัง บางคน อาจจะ blog เนื้อหาในช่วงเวลาเดียวกันแตกต่างกัน เพราะว่าเข้าฟังคนละห้องก็เป็นได้ (ช่วงเวลาเดียวกัน จะมีเนื้อหา 3-7 เนื้อหา บรรยายพร้อมกัน แต่คนละห้อง)***

10.00-11.00 agile by design principle [present by ThoughtWorks]

เคยมั้ยงานที่เรา deliver เป็นสิ่งที่เราบอกว่ามันเจ๋งมากแต่ว่าลูกค้า บอกว่ามันกากมาก ตัวอย่าง prompt pay ของ SCB ผู้พูดยกตัว stepper ขึ้นมา เค้าเป็นคนใส่ movement อย่างดี มี responsive ให้ด้วย แต่ส่งให้ลูกค้าดู  ลูกค้าบอกว่าเอาออกเถอะ! > เพราะว่านั่นไม่ใช่สิ่งที่ลูกค้าต้องการ คือลูกค้า ไม่ได้ต้องการดู animation ตอน signup เลย หน้าสมัคร prompt pay สิ่งที่ลูกค้ามองหา ก็คือ การสมัครได้ง่าย และเร็วที่สุดต่างหาก
นำมาสู่คำถามว่า คุณเข้าใจลูกค้าหรือเปล่า?

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

ดังนั้น ถ้างานที่เราทำ มันคืองานที่ใหญ่ ทำยาก คนใช้ต้องเยอะ แล้วทำไมเราไม่ถึงไม่อยากรู้จักลูกค้าล่ะ

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

แล้วเราจะรู้ได้อย่างไร  ง่ายมาก ก็แค่ ถาม! หรือคุยกับลูกค้า 

อีกตัวอย่าง เราทำงานโค้ดมา เพื่อให้สาขาใช้งาน เสียเวลาโค้ดไป 2 อาทิตย์ แล้วพอไปดูหน้างานจริงพบว่า หน้าจอที่สาขาใช้ 800*600 ทำให้มันรันเป็น mobile site แล้ว ก็พังเละ นี่เป็นตัวอย่างหนึ่ง ที่บอกเราว่าเราไม่รู้ว่าลูกค้าเราคือใคร ทำให้เราทำอะไรออกมาที่ไม่ใช่สิ่งที่เค้าต้องการจริงๆ (แล้วลองคิดดูว่าถ้างานนั้นต้องโค้ดนาน 6 เดือนล่ะ…..)

ต่อมา เราก็ทำความเข้าใจต่อว่า เมื่อเราเข้าใจลูกค้าแล้ว เราจะต้องรู้ว่า งานนั้นมีคุณค่าได้อย่างไร

ในแต่ละงานที่เราทำ เราเคยตั้งคำถามตัวเองมั้ยว่า

1. เรานำส่ง feature อะไร
2. รู้มั้ยว่ามีคนใช้งานเท่าไร
3. รู้มั้ยว่ามันสร้างเงินให้ได้เท่าไร

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

อีกตัวอย่าง บริษัทแห่งหนึ่ง ทำ search feature แผนออกมาว่า จะเสียเงิน $4M , 2 head count, 8 เดือน มี feature function premier มาก เมื่อ management เข้าใจ project ทั้งหมด ก็สั่งให้ re prioritize project นั้นทันที สาเหตุ search feature ที่จะทำออกมานั้น มันไม่ได้สร้างเงินสักบาทเลย สุดท้ายก็เลยไม่ได้ทำ

ให้เราลองสมมุติตัวเองว่า เป็นคนที่สร้างเก้าอี้ได้เจ๋งที่สุดในโลก แต่ว่า ลูกค้า เค้าเพียงแค่ต้องการเดินจาก A ไป B แล้ว  (ซึ่งเก้าอี้เราอยู่ที่ทางผ่านของเค้า) เรามองออกมั้ย ว่าคุณค่าของเก้าอี้ของเราคืออะไรในกรณีนี้ คำตอบคือไม่มี เพราะเค้าไม่ได้ต้องการจะนั่งเก้าอี้ไง

เรื่องที่สาม ก็คือ เข้าใจคนที่เกี่ยวข้องกับ project นั้น หรือเรียกง่ายๆว่า คนที่เอาคอขึ้นเขียง ซึ่งอาจจะเป็น หัวหน้า หรือ เจ้าของ project ที่ involve มาแต่ตั้งแต่เริ่ม หรือว่าลูกค้าที่เค้าจ้างเรา

ลองสังเกตุเรื่องหนึ่ง เวลาที่หัวหน้าเดินเข้ามาหาเรา เค้าเข้ามาด้วย ปัญหา หรือแนวทาง? ถ้าหัวหน้าเรา มองหา cheaper/faster/more efficient people เค้าจะเปลี่ยนไปจากเราทันที เมื่อเค้าเจอคนที่ ถูกกว่า เร็วกว่า ดีกว่า เร็วกว่า

ดังนั้น เราต้อง define ตัวเองให้ออก ว่าเราเป็นเครื่องจักรที่ทำงานให้เค้า หรือว่าเป็น partner ให้เค้า (เพื่อไม่ให้เจอปัญหาข้างต้น)

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

don’t finish your project ตัวอย่าง facebook google twitter ก็ไม่เคยจบ เพราะว่ามันเป็น value driven

ตัวอย่างหนึ่งที่เอามาโชว์ ก็คือ woolworth improve by thoughtwork เค้ามาทำ agile ที่หน้างานเลย โดยตั้งโต๊ะทำงานที่ shop เลย แล้ว ก็มาดูว่าลูกค้าต้องการอะไร มาพิสูจน์ว่า สิ่งที่นายจ้างต้องการจะทำน่ะ มัน work กับลูกค้าที่มาซื้อสินค้าเค้าหรือเปล่า แล้วเค้าก็ลอง implement prototype แล้ว เอาให้ลูกค้าใช้งานเลย จากนั้น ก็เก็บ feed back เลย แล้ว ก็ปรับกันตรงนั้นเลย ไม่ว่าจะดีหรือไม่ดี ลูกค้าก็จะบอกเลย

เช่น idea ตั้งต้นนายจ้างก็คือ เค้าจะยิง scan barcode เพื่อให้ซื้อสินค้าได้ง่าย และได้รายละเอียดสินค้าครบจากหน้าจอมือถือเลย แล้วให้ลูกค้าลองทำจริง แล้วพบว่า มันไม่ work เลยที่จะเป็นอย่างนั้น เพราะว่าบางคนมาซื้อ แล้วไปเลย หรือว่าต้องแบกตะกร้า และเอามือถือมายิงอีก ดังนั้นสรุปว่าอย่าทำแบบนั้นจะดีกว่า แต่ถ้าเป็นชีวิตจริง ที่เราๆท่านๆเจอ ก็คือ เค้าก็จะจ้างให้เราทำจนจบ เพราะเค้าคิดมาแล้ว ว่าเอาแบบนี้แหล่ะคิดมาดีแล้วลูกค้าต้องชอบ…. อย่างกรณีตัวอย่างนี้ ก็กลับมาคุยกันใหม่ ว่าเค้าต้องการอะไร สรุปคือ เค้าจะ increase sale อย่างเช่น ซื้อไก่อบ แล้ว ซื้อเครื่องปรุงมาทำกับข้าว เค้าก็เอาเมนูมาให้กดเลย พอกดแล้ว มันก็จะมีไฟขึ้น เพื่อบอกว่าเลยว่าเครื่องปรุงไหนบ้าง ที่เค้าจะต้องเลือกซื้อไปสำหรับเมนูนั้นๆ ก็เพิ่มยอด sale ได้จริง

สรุปก็คือ
เข้าใจ your user
เข้าใจ your value creation
เข้าใจ your stakeholder
นี่คือ design principle แต่ว่าถ้าเราทำได้ทั้งหมดนี้แล้ว นั่นแปลว่าเราเข้าใจ agile แล้ว

ทีนี้ ลองมาดูว่า designer ใน agile นั้นเป็นอย่างไร

designer’s role in agile
การทำงานของ designer นั้น สิ่งที่เราต้องทำก็คือ การแก้ ณ ตอนนี้ เวลานี้เลย เพราะว่านั่นจะเป็นราคาที่ถูกที่สุด การรอทำในอนาคต มันจะแพงกว่านี้แน่นอน แต่ว่าเมื่อเราทำแล้ว เราต้องไม่ลืม มองย้อนกลับไปด้วย ว่ามัน improve ได้เพิ่มมาขึ้นหรือน้อยลงอย่างไร

ดังนั้น สรุปแล้ว agile = value driven แล้วให้ยึดมั่นเอาไว้เลย ว่า value driven นั้นคือฝั่งที่ business ต้องการแน่นอน

Q : เวลาที่ designer ไปคุยกับ programmer เพื่อขอปรับอะไรบางอย่างแล้ว programmer ไม่พอใจ ทำอย่างไร
A: การทำ agile ทุกคนต้องรวมใจเป็นหนึ่งเดียวกัน โดยให้มองไปที่ end point เดียวกัน ก็คือ มองว่า product เรามันจะดีขึ้น งามขึ้น สวยขึ้น ขายได้มากขึ้น ดังนั้น ทุกคนจะต้องรวมใจกัน เพื่อให้มองที่ outcome ของ product เป็นหลักเลย ไม่ใช่การสบายใจของตัวเราเอง (ถ้าแค่ทำเพื่อเป็นความฟินส่วนตัว ก็สมควรโดนมองเคือง)

Q: แล้วเราจะสร้างแนวคิดเหล่านั้นขึ้นมาให้ทีมได้อย่างไร
A; agile คือ mindset ไม่ใช่ framework แต่ว่า scrum ต่างหากที่เป็น framework ดังนั้น มันคือการสร้าง culture เรื่องนี้ เราต้องอธิบายให้ทีมงานเข้าใจ ว่า agile จะมาช่วยเค้าได้อย่างไร ตัวอย่างเช่น เราจะสร้าง space ที่ปลอดภัยต่อความล้มเหลว แล้วเราก็ต้องมองว่า KPI จะเป็น KPI ของทีมนะ ไม่ใช่ไปตั้ง KPI ว่า ต้องสวยนะ ต้องทำ task ได้เยอะนะ ดังนั้น การสร้าง culture เป็นเรื่องที่สำคัญที่สุด อาจจะกินข้าว party ให้ดอกไม้กัน เป็นเรื่องที่สำคัญนะ

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

Q: เวลา ที่เราจะ bid งาน เราจะได้ feature มาซึ่งมัน fix เลย แล้วมาเอาเข้า agile อย่างไร
A: ก็ต้องไปหาให้เจอว่า ลูกค้าต้องการอะไร วัดผลอย่างไร มองหาอะไรอยู่ เค้าถูกอะไรบีบอยู่ ดังนั้นเราต้องไปแคะออกมาให้ได้ ทำ trust ให้เกิดขึ้นระหว่างเค้ากับเรา แล้วเก็บเอา KPI ของตัวเค้า (หรือสิ่งที่เข้าต้องการอยู่เบื้องหลัง) มาเช็ค list กับ สิ่งที่เราจะต้องทำ ถ้าเรารู้แบบนี้ เราจะง่ายเลย

Q: ถ้าเป็นงาน bid รูปแบบเก่าๆ เราจะแก้อย่าไร
A: เราต้องพยายามประยุกต์ใช้ เพราะทุกอย่างมันไม่ได้ตรงไปตรงมาทั้งหมด

Q: การคุยกับ user เราจะมีเทคนิคอย่างไร เพราะว่า เวลาที่เราคุยกับ user มันอาจจะได้ feedback แบบหนึ่ง แต่ว่า ลูกค้าตัวจริง อาจจะไม่ได้ใช้ก็ได้ (user เป็นนายจ้าง แต่ลูกค้าตัวจริงหรือคนใช้จริงๆคือลูกน้องของนายจ้างนั้นอีกที)
A: นั่นเป็นสิ่งที่สำคัญว่าเราต้องมี UX ในทีม เพราะว่า นั่นจะเป็นคนที่บอกเบื้องต้นได้ว่า อะไรที่เป็นสิ่งที่ควรทำ หรือไม่ควรทำ หากเราไม่สามารถเข้าถึงผู้ใช้งานตัวจริงได้

เราอาจจะยึดหลักพื้นฐานก็ได้เช่นพวก user persona, user qualitative เพื่อเป็นแนวทางเบื้องต้นก่อน แล้วเราก็ไปดูตัวจริงเพื่อหาข้อมูลออกมาจาก focus group ต่างๆ จะทำให้เราได้ข้อมูลที่กลั่นออกมาจาก user จริงๆ

11.00-12.00 introduction to agile [presented by คุณปลา Thomson Reuters]

agile เริ่มต้นมาจาก สิ่งที่คนทำ software เค้ามาคุยกันว่าทำอย่างไร ที่จะทำให้มันดีขึ้น ทำให้เกิดคำนึงก็คือ agile manifesto โดยมุ่งหมายก็คือ ตอบสนองต่อ ความต้องการของลูกค้า

manifesto ประกอบด้วยสี่เรื่องหลัก 

• response to change ทุกอย่างต้องเปลี่ยนแปลง เพราะว่ามันคือ growth ซึ่งก็จะมาจาก change เพราะถ้าเราทำ software ตัวหนึ่งแล้วใช้งานได้สิบปี แบบนั้นไม่มีจริงหรอก
• customer collaboration ก็คือคุยกับลูกค้าว่าต้องเป็นอย่างไร ต้องการอะไร ชอบอะไร ไม่ชอบอะไร
• deliver ไม่ใช่ว่าสั่งแล้วหายไปทำ 6 เดือน แล้วก็มาเงิบกันทีหลังตอนส่งมอบ
• individual ก็คือ mindset ที่ทุกคนต้องมาทำงานร่วมกัน ไม่ได้ขึ้นอยู่กับ ผู้คุมกฏ

อ่านตัวจริงได้จาก http://www.agilemanifesto.org/iso/th/  เป็นภาษาไทย ดังนั้น เราจะเห็นว่า เราต้อง balance กัน ไม่ใช่ว่าทำสามตัดออกหนึ่ง เราต้องมีทั้งหมดนี้ แค่นี้แหล่ะคือ agile ที่แท้จริง ส่วนที่เหลือ ไม่ว่าจะเป็น kanban, scrum และอื่นๆ มันเป็นเครื่องมือ ที่ช่วยสนับสนุนการทำ agile เท่านั้นเอง แต่ไม่ได้แปลว่า หยิบมาใช้ปุ้บ แล้วบอกว่า นี่แหล่ะ ทีมเราเป็น agile แล้ว

scrum หรือ waterfall?

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

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

แต่ว่า waterfall จะ work ถ้าเราเริ่มทำสิ่งที่มีอยู่ใหม่อีกรอบหนึ่ง ตัวอย่างคือ release iOS ไปแล้วรอบหนึ่ง ถูกใจลูกค้าแล้ว ถ้าต้องการทำบน android ด้วย ก็ยก android มาทำเป็น waterfall เลยเพราะเรามองเห็นหมดแล้ว ว่า app บน android ต้องการอะไรบ้าง จาก learning ตอนทำ iOS แต่ถ้าแนะนำก็คือ agile ตลอดเลยจะดีที่สุด  อีกสิ่งที่เป็นการตัดสินใจว่าจะเลือกใช้แนวทางไหนก็คือ ต้องมี learning มั้ย ถ้าต้องมี ก็ agile ไปเลย แต่ว่า waterfall จะเป็นสิ่งที่เรามองเห็นฉากจบ รวมทั้ง requirement ชัดเจนมากๆ

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

การทำ scrum

เราต้องรู้ว่ามีใคร ทำอะไรบ้าง แล้วจะได้อะไรออกมา

ใคร – มีสามแบบ

product owner (PO) คือคนที่จะบอกได้ว่า ความต้องการมีอะไรบ้าง แล้วเป็นคนเรียง priority มาให้เราได้ด้วย ว่าอะไรทำก่อนหลัง ซึ่งเราเรียกว่า product backlog โดยชิ้นบนๆ จะเป็นชิ้นที่ต้องทำงานละเอียด เพราะว่า developer จะต้องเอาไปทำงานต่อแล้ว ซึ่งต้องมี acceptant criteria โดยชิ้นงานนี้จะต้องเสร็จในหนึ่ง cycle เราจะเรียกมันว่า story ซึ่งมันจะคลุมด้วย epic อีกที โดยทั่วไป จะเป็น epic > feature > backlog > task

ถ้าเป็นบริษัทใหญ่ๆ ควรจะเป็น business analyst , project manager มาทำตรงนี้ หรือถ้าบริษัทเล็กก็อาจจะเป็น CEO เองเลย เพราะจะเป็นคนที่บอกได้ว่าต้องการอะไร แล้ว ปัญหาเค้าคืออะไร ซึ่งข้อสำคัญคือเค้าต้องรู้จริงๆว่าลูกค้าต้องการอะไร

คนนี้ ถึงแม้ว่าจะไม่ได้เป็นลูกค้าตรงๆ ก็จะต้องเป็นคนที่เข้าใจลูกค้าทั้งหมด ว่าเค้าต้องการอะไร อย่างบางงาน ก็จะใช้ BA (ทำตัวเองเป็น product owner) คุยกับลูกค้าตรงๆ แล้ว product owner ก็จะมาบอก team ว่าต้องทำอย่างไรบ้าง

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

team ก็คือ developer ที่ release feature ออกมา ให้ไปอ่านเพิ่มเติมจากเอกสารที่ http://www.scrumguides.org/ โดยเค้าแนะนำว่า ประมาณ 7-9 คนกำลังพอดี ในการ manage รวมทั้ง กำลัง OK ที่กำลังถกกัน เยอะที่สุดคือ 14 คน ซึ่งถ้าทีมใหญ่ขนาดนี้ แต่ทุกคน mindset ได้ ก็จะไม่มีปัญหาเลย

โดยทีม ถ้าเป็น pure agile จะรวม skill ทุกอย่างอยู่ในทีม และแต่ละคน ก็ควรจะเป็น multi functional skill ในคนเดียวได้ ก็จะดีมากๆ เพราะว่า มันจะช่วยกันได้รวมทั้งเป็น backup กันได้ด้วย หรือว่าอาจจะใช้การสอนคนในทีมกันเอง เช่น ถ้าเจ็บป่วย ก็จะได้แทนกันได้ หรือว่าถ้าเป็นถึง SA เองก็จะช่วยทีมได้มาก เพราะว่าจะรู้เรื่องอะไรมากมายหลายอย่าง

ทำอะไร – สิ่งที่เราต้องทำ

กำหนด sprint โดยแนะนำก็ประมาณ 2 week กำลังดีเลย โดยเราจะ commit ชิ้นงานเล็กๆออกมา จาก epic โดยใช้ PO + Team รวมกันทำเอามาใส่เป็น product backlog แล้วเราก็จะต้องวัดขนาดงานพวกนี้ด้วย เราเรียกว่ามันคือ story point ซึ่งมันคือการเทียบ feature หนึ่งกับ อีก feature หนึ่ง apple กับ apple โดยตัวเลขจะเป็นแบบ Fibonacci 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55 …. อาจจะเริ่มต้นตั้งแต่ 2 ขึ้นไป จากประสบการณ์ไม่ควรเกิน 13 เพราะว่า มันจะใหญ่เกินไปอาจจะทำไม่เสร็จในหนึ่งสัปดาห์ และอาจจะนำมาซึ่งทำไปแล้ว ไม่เสร็จ อาจจะกลายเป็นเสียเวลาแล้วทำให้ sprint fail โดย point นี้ ก็จะเป็นต่อคน อาจจะต้องแตก story อีก ประโยชน์ของมันก็คือ ใช้เพื่อลดเวลาในการถกกันในเรื่องตัวเลขละเอียดๆด้วย ว่าอะไรยากกว่าอะไร และเลขนี้ก็ไม่ใช่ manday โดยเราอาจจะกำหนดเอาไว้ว่า งาน 2 point เนี่ย คืออะไร ตั้งเอาไว้ เช่น งาน 2 point เราจะได้ new feed card หนึ่งกล่อง เพื่อใช้เป็น benchmark กับงานอื่นๆ ถ้าเราต้องการทำงานที่คล้ายๆกับ new feed card แบบนี้อีก ก็คือ 2 point เท่ากันนี่แหล่ะ แต่ถ้าเราเอา new feed card มา render เป็นหน้า จัดเรียง รวมทั้ง ทำ pagination ก็อาจจะเป็น 3 point ส่วน 1 point อาจจะกันเอาไว้เป็น งานที จิ้มสองที หรือแค่ครึ่งวันเสร็จเป็นต้น

ส่วนนี้ เราจะต้องทำ product backlog grooming ต้องเริ่มก่อน sprint planning สัก 1 สัปดาห์ อย่างเช่นวันพฤหัส ก่อน เริ่มสัปดาห์ต่อไป โดยเมื่อเราทำสอบ 1-2 sprint เราจะนับได้แล้วว่า สัปดาห์หนึ่ง เราจะทำงานได้รวมทั้งทีมกี่ point แล้ว ต่อรอบ จะทำให้เราพอมองออกว่า velocity team เป็นเท่าไร พอจะเอาไปบอกคนอื่นได้ ในการที่เราจะต้องประเมินแบบคร่าวๆ (ย้ำอีกที point ไม่ใช่ man day แต่เราต้องเอางานมาแตกเป็น story point ก่อน แล้วดู velocity team จึงจะบอกได้ว่า ต้องใช้เวลานานเท่าไร)

และ แต่ละวัน เราก็จะมี daily standup อยู่ โดยให้แต่ละคนมายืนอธิบาย ว่าทำอะไรไปแล้ว และกำลังจะทำอะไร โดยสำคัญก็คือ ติดอะไรอยู่มั้ย เพราะว่า fast feedback บางทีมาจาก เราช่วยเหลือกันนี่แหล่ะ โดยทุกคนต้องร่วมมือกันทำ เพื่อให้งานมันเสร็จได้ นี่แหล่ะ ที่ประโยชน์และเกิดจาก mindset จริงๆ โดย standup ก็ไม่ควรไม่เกิน 15 นาที เพื่อ update กันเท่านั้น บางคนอาจจะมี whiteboard เสริม ก็ว่ากันไป แต่อย่าให้ยาว และ ห้ามนั่ง เพราะนั่งเมื่อไร ยาวแน่นอน

จากนั้น จะเป็น sprint review จะมี product owner เข้ามาดูของ แล้ว response เก็บ feed back แล้วก็ไป improve หรือ ถ้าผ่าน ก็ทำงานส่วนอื่นกันต่อไป

สุดท้ายก็คือ sprint retrospective เพื่อมา feedback กันเองในทีมงานว่า อะไรที่ทำดีอยู่แล้ว , อะไรที่ต้องปรับปรุง , อะไรต้องควรทำ ตรงนี้ต้องทำให้เป็น safe space ให้ได้เราต้องรับฟังซึ่งกันและกัน บางคนเจอน้องเงียบก็อาจจะให้ post it แทนว่ามีเรื่องอะไร แล้ว พอเข้ามาก็มาแปะ ว่าอะไรชอบ ไม่ชอบ ต้องแก้ แล้วมา pitch แล้ว vote ว่าอะไรคือ สิ่งที่ต้องแก้อย่างเร็วที่สุด และ หา owner ในการแก้ด้วย อาจจะไม่ใช่ scrum master ที่รับเละและทำทุกอย่าง โดยจุดมุ่งหมาย คือ อยากให้ individual improve กันไปตลอด ตัวอย่างหนึ่งที่วัดได้ว่าทีมมี mindset ได้แล้วหรือยังก็คือเมื่อ scrum master ลาวันที่จะต้องมี sprint review แล้ววันนั้นก็ไม่มี sprint review เกิดขึ้นนั่นแปลว่า failure , agile culture ยังไม่เกิด

Q: บริษัทที่มี QA PM SA ยังต้องมีคนเหล่านี้มั้ย ถ้าเราจะทำ agile
A: เราอาจจะใช้การยืดหยุ่น เช่น มี proxy ตรงกลาง เพื่อเอาไว้คุยกับเค้าเยอะๆ หรือ dedicate BA กับเค้าไปเลยก็มี

Q: การ change จาก waterfall หรือทำงานแบบเก่าๆ จะเริ่มได้อย่างไร
A:reuters เริ่มต้นจากทีมเล็กๆทำ แล้วปรากฏว่า management ชอบ นี่แหล่ะ จะช่วยได้ คือเราต้อง get buy in, get sponsor นี่แหล่ะ ที่จะช่วยได้มาก เราอาจจะหาคน pilot ที่จะมาช่วยได้ โดยเรา อาจจะยก บาง project มาลอง หาคนสนับสนุนให้ได้ (คืออนุญาตให้ทำ) แล้วมันจะไปต่อได้ง่าย เพราะว่า agile มันทำให้เค้าเห็นของได้เร็วอยู่แล้ว

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

จุดหนึ่งที่เริ่มได้ ก็คือการเข้าไปแก้ไข pain point ซึ่งเรื่องหนึ่ง คือ time to market นี่แหล่ะที่จะเอา agile เข้ามาใช้ได้ และปัญหาหนึ่งก็คือ release ที่ยาวนานเกินไป

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

13.00-14.00 running with agile รักจะซิ่ง ต้องวิ่งให้เป็น [presented by คุณ อู @chonla]

agile manifesto ก็เป็นเหมือน principle ที่เราต้องเดินตามแนวทาง

โดยที่ผ่านมา เราคงเรียนรู้มาว่า เราต้องทำแบบนี้นะ แบบนั้นนะ แต่ไม่มีใครบอกว่า ไม่ควรทำแบบนี้นะ แบบนั้นนะ

agile ไม่ใช่ silver bullet แต่เราจะต้องเอามาปรับและประยุกต์ใช้ เพื่อให้เข้ากับบริษัทของเรา

การทำงานมีสองแบบ คือ pre defined process กับอีกแบบคือ empirical process ซึ่งเราคาดเดาไม่ได้
โดย agile จะเป็น empirical process คือเรายังไม่รู้ว่าตลอดเส้นทาง มันจะเป็นอย่างไร แต่ว่า เราจะต้องคอยแก้ปัญหาซึ่งๆหน้าไปตลอดทาง และเราก็คาดเอาไม่ได้ด้วย ว่า เราจะต้องเจออะไรที่ตอนไหน
ตัวอย่าง project ระดับ สองสามปี เราจะ fail มั้ย ใครบอกได้? ดังนั้น มองว่า agile น่าจะเหมาะกว่า เพราะเราก็จะได้พร้อมปรับตัวกับการเปลี่ยนแปลงตลอดเวลา

ปัญหาหนึ่งก็คือ เวลาที่ project มี bug มันจะกลับมากระทบกับ sprint ของเรา เพราะว่า sprint ก็คือ ส่วนงานที่เราได้ plan เอาไว้แล้ว แต่ว่า bug ก็จำเป็นที่จะต้องแก้ไขด้วย ตรงนี้ก็ต้องหาทางปรับแก้กันไป

แต่อย่างไรก็ตาม เราก็ต้องรู้จักความเร็วของตัวเองด้วย เราต้องประเมินตัวเองให้ออก ว่าเราจะทำได้อย่างไร ด้วยความเร็วเท่าไร

ตัวอย่าง project นึง ประเมิน 6 เดือน แล้วรับไม่ได้ ก็ขอ 2 เดือน แบบ บีบคนทำงาน ปรากฏว่า ทำเสร็จ แต่ bug กระจาย แล้วสุดท้ายก็แก้ bug กันไปมาไปมา จนท้ายที่สุด ก็ใช้เวลา 6 เดือนอยู่ดี

อีกตัวอย่างหนึ่ง ก็คือ เวลาเริ่มต้น project ใหม่ อาทิตย์แรก ก็เริ่มอัดกันอย่างเร็วเลย เร็วกว่าความเป็นจริงด้วย แต่พอซิ่งไปสักพัก ก็จะกลายเป็นว่า speed จะตกตอนท้ายที่สุด แล้ว นั่นจะนำมาซึ่งความเสี่ยงในตอนท้ายอยู่ดี

การแบ่งงานตามความสำคัญ นั่นเป็นหัวใจมากที่ต้องมองให้ออก ว่าอะไรคือ core ตัวอย่าง สิ่งที่มักจะเริ่ม dev ตอนต้น project เสมอๆ ก็คือ หน้า login ซึ่ง จริงๆ นั่นไม่ใช่ core value ,core product เลย เพราะว่าเมื่อเราเริ่มต้นที่หน้า login แล้ว เราก็อาจจะต้องต่อไปที่ user management ต่อ แล้วอื่นๆที่เกี่ยวข้องกับหน้า login ซึ่งถามแบบตรงไปตรงมาว่า งานที่ business สั่งมาเช่นระบบขายสินค้าน่ะ หน้า login คือสิ่งที่ user ต้องการจริงๆหรือเปล่า? ไม่ใช่! ต้องมองให้ออก เพราะว่า งานเล็กๆน้อยๆนี่แหล่ะ ที่ไม่ได้สำคัญเลย แล้วมักจะถูกเอามาทำตอนแรกมากมายหลายอัน แล้วแรงจะไปตกตอนท้าย เพราะว่า หน้า login เนี่ย มันเป็นแค่ copy paste ก็เสร็จแล้ว

PO คือคนที่ดูแลเรื่อง priority ต่างๆ ถ้าเราทำงาน scrum PO จะเป็นคนที่ทำหน้าที่ จัดเรียง task ต่างๆ และอธิบายได้ว่าแต่ละ task นั้นต้องการเห็นอะไร ต้องการได้อะไร

การเริ่มต้น แนะนำว่า ให้ทำตามที่คนอื่นแนะนำ ให้ลองทำตาม to do list ดู ตามแนวทาง agile ที่เค้าทำๆกัน ตัวอย่าง standup meeting เนี่ย ก็มีเพื่อให้คนทำงานได้คุยกัน แต่ไม่ได้หมายความว่า เป็นสิ่งที่ดีที่สุด เราก็ควรเอามา adapt กับองค์กรเราอีกที

ส่วนเรื่อง standup meeting ทำไมต้องตอนเช้า ก็เพระาว่า สมองเราแล่นดีทีสุด คิดได้ดีที่สุด

เรื่องความยาวของ sprint เนี่ย ความยาว 1-4 week แต่ว่า เราเองต่างหากที่จะเอามาปรับให้เหมาะกับองค์กรของเรา ตัวอย่างเช่น เราเริ่มนัดทุกสัปดาห์ แล้วรันไปปรากฏว่าลูกค้าสะดวกบ้าง ไม่สะดวกบ้าง ก็เอาใหม่ เปลี่ยนเป็น สองสัปดาห์ครั้งก็ได้ เพียงแต่ว่าเราต้องพูดคุยกัน เพื่อกำหนดร่วมกันอย่างชัดเจนเท่านั้นเอง

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

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

สิ่งที่เราจะได้จาก retrospective ก็คือ inspect & adapt ซึ่งมันจะต้องมีเรื่องพื้นฐานหนึ่งก็คือ team parency หรืออีกกิจกรรมหนึ่งก็เอามาใช้งานได้ก็คือ fish blow ก็ย้อนไปเรื่องเดิม คือเราต้องยอมรับเรื่อง fact คือความจริงให้ได้ โดยเราต้องข้ามการตีความ แต่ให้มองที่ fact จริงๆ ตัวอย่างเช่น sprint ที่ผ่านมา คุณไม่ได้ช่วยอะไรเลย ทำให้ sprint fail แบบนี้ เราตีความเองแล้วดันใส่เข้ามาด้วย ซึ่งที่ควรทำก็เพียงแค่เปลี่ยนคำพูด ให้ดีขึ้น เช่น sprint ที่ผ่านมา ผมไม่ค่อยสบายใจ อยากขอความช่วยเหลือ แต่ว่าผมไม่เห็นว่า ใครช่วยผมเลย > แต่ เรื่องนี้ก็เป็นเรื่องของศิลปะตัวบุคคล > ความเป็นจริง จากประสบการณ์ ก็คือ ถ้าเปิดมาคนแรกดี มันจะดีตลอด ถ้าเปิดมาเละ มันจะเละตลอดในรอบนั้นเหมือนกัน ดังนั้น scrum master ต้องมองให้ออกว่าใครพูดดี ให้ใครเปิดดี ก็ให้คนนั้นแหล่ะเปิด คือเราก็ต้องมองว่า ทีมเราเนี่ย เป็นครอบครัวเดียวกัน ดังนั้น ผัวเมียทะเลาะกัน เป็นเรื่องธรรมดา

คือเราต้องมองว่า ทุกคนเป็นครอบครัวเดียวกัน เพราะไม่งั้นถ้าทุกคนเงียบ แล้วรอระเบิด นั่นคือ บริษัทสูญเสียมากมายแน่นอน ดังนั้น ทุกคนต้องรวมใจกันได้ เพื่อให้มุ่งไปที่ project ดังนั้น retro จะเป็นจังหวะที่ได้ใส่กันเต็มที่ ส่วนใหญ่ retro จะประมาณ 1-2 ชั่วโมงไม่เกินนี้ ขึ้นอยู่กับขนาดของทีม

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

สรุปก็คือกิจกรรมที่มากมายในแต่ละ sprint เนี่ย มันมีมาก และเราก็ต้องปรับไปเรื่อยๆ บางครั้งอาจจะเกิด over head บ้างแต่ถ้าทำแล้ว result มันได้ ก็ OK ตัวอย่างเช่น standup meeting ที่เป็น over head ก็จริง แต่ว่างานที่เราจะต้องทำ มันต้องทำร่วมกันไปอีกนาน ดังนั้น เราจึงต้องปรับปรุงการทำงาน ที่เกิดมาจากทีมที่ทำงาน ร่วมกันสร้างมันขึ้นมาเองนั่นแหล่ะ

14.00 – 15.00 agile project management [present by ThoughtWorks]

ไม่แปลไทยนะครับ เดี๋ยวเพี้ยน (จริงๆคือ ถ้าจดมาแบบแปลไทย จะฟังไม่ทัน 555 เพราะต้องสลับไปสลับมาแล้ว งง)

management – is manage work , process, people that involve in that project
it have different between leader and manager
first thing is great team!
second thing is servant leadership – trust,balance,appropriate,action

project management – the four things (but it have 6 list)
1 what a great team wins, every times
2 keep people nourished and productive
3 own and maintain vision – create , maintain , make sure everyone can support you by to do their jobs
4 shield from unnecessary diversion – protect from high manager to direct command to team. we need to findout what requirement are necessary or unnecessary we need to protect team from that interrupt so we need to balance it, that not mean stop the word.
5 obstacle removal and prevention
6 overly simplistic

agile is continue improvement everyday

project mangement that is to do the right thing to make everyone make successful project so that is not strict to do only in your role, sometime you are feeder the food to your team

Q:in scrum team it no need the PM role so we still need them?
A: project manager not require in team because of team need to be work on cross function so scrum master can responsible for that but for the first phase of transition it still need to make everyone has multi skill and then we can fade PM out from team later

Q:some company require the specific spec and deliver before start project how we can deal with it by agile?
A:sometime we need to do that by the law force you but you need to discuss with customer to make them understand by that you want to do maybe not important when pass the 3 month from now that mean after 6 month (project finished) you will get product that not meet with your require, you want that?

the first to involve every person to help you is make more trust because many people will work with you long time (at least until project done)

* lose cotnrol of the daily detail to gain greater control of the outcome
* the first transparent method of project governance
* simply the most effective way to manage risk on a project
* In a way, it’s micromanagement, without the power structure

15.00-16.00 installing self management [Presented by Verokas]

สิ่งที่เราควรทำก็คือการกระจาย management ลงไปในรากหญ้ามากขึ้น ไม่ใช่การเพิ่ม PM ที่มากขึ้น เพราะว่า เมื่อเรากระจาย การ manage ลงไป เราก็ไม่ต้องจ้างคนข้างบนเพิ่มขึ้น

ถ้าเรายังยึดติดกับสิ่งแบบเดิมอยู่ project manager จะเป็นคอขวดทันที ตัวอย่างหนึ่ง คือ PM คนนึง บอกว่าห้ามเลื่อน card จนกว่าจะบอกเค้า (และอนุญาต) แต่สุดท้ายเค้าพบว่า มันก็ไปรอเค้าคนเดียว ที่ทำให้เป็นคอขวดอยู่

สิ่งที่เราต้องทำก็คือ distributed management skills คือการกระจายการจัดการลงไปสู่ระดับล่าง

ก่อนอื่น เราต้องมองให้ออก ก่อนคือ manager ทำอะไร แล้ว เราก็เอาสิ่งนั่นแหล่ะ กระจายลงไปในระดับล่าง

มันมีคำถามหนึ่ง คือ people vs technical? ก็คือ เป็นคำถามว่า เราบริหารคน หรือ บริหารเรื่อง technical

เรื่องต่อจากนี้จะเป็นเรื่องที่เราสามารถถ่ายทอดให้กับทีมงานของเราได้ (กระจายการจัดการลงสู่รากหญ้า)

Time Management

มันไม่ใช่การจัดการเวลาให้มีมากขึ้นหรือน้อยเลย แต่ว่า จริงๆ มันคือ การ prioritization ต่างหาก ดังนั้น เรื่องนี้ เมื่อแต่ก่อนเราก็ทำยังไม่เป็น แต่เดี๋ยวนี้เป็นแล้ว (หรือก็ยังไม่เป็น?) เรายังเรียนรู้ได้ ดังนั้นเราก็เอาเรื่องนี้แหล่ะ ไปสอนได้
เรื่องเวลา มันมีสองเรื่องที่เป็นกฏ

1. งานจะเยอะกว่าเวลาที่มีเสมอ
2. busy != productive และห้ามใช้เวลาแก้ปัญหาเด็ดขาด เพราะว่า เวลา เป็นสิ่งที่ซื้อคืนมาไม่ได้ คนไทยค่อนข้างจะมีปัญหาเรื่องนี้อยู่

say no and offer alternative เป็นทางหนึ่ง ที่เราต้องสอน ถึงมันเป็นศิลปะ แต่ว่ามันก็สอนกันได้

ยกตัวอย่าง เราจะทำเว็บ amazon ให้ได้ ภายในสัปดาห์เดียวได้มั้ย แน่นอนว่า มันเป็นสิ่งที่ทำไม่ได้ ดังนั้น เราต้องนำเสนอ alternative plan ว่ามันมีทางออกไหนได้บ้างเพื่อให้ไปถึงตรงนั้นได้ ซึ่งเรื่องนี้ ก็จะผูกกับ goal setting อีก

goal setting

1. expect not well defined work อย่าไปคิดว่าทุกคนจะทำงานได้ดีอย่างที่เราคิด
2. ask question if (1) == true ดังนั้น เราก็ต้องถามคำถามเพื่อให้เข้าใจ ไม่ใช่ว่า ครับๆอย่างเดียว ซึ่งเรื่องเนี้ยเราต้องฝีกกระบวนการคิดให้เด็กๆ ให้คิด แล้วตั้งคำถาม ไม่อย่างนั้น เราต้องเป็นคนตอบตลอดไป
3. constantly verifying ยืนยัน ว่าสิ่งที่เราทำมันเป็นไปได้จริง อย่างความต้องการตามเป้าหมาย เพื่อให้มั่นใจว่า เข้าใจตรงกัน

solve problem 

1. generate solution ก็เสนอทางออก อาจจะใช้การ brain storm ก็ได้
2. decide what to do

effective brainstorming เราก็ต้องสอนว่า มันมีวิธีไหนบ้าง เพราะอยู่ดีๆบอกให้ทำแล้วเดินจากไป มันทำไม่ได้หรอกแค่นั้นอ่ะ

group decisions ถ้าทำแล้ว ไม่จบทำอย่างไร เราควรตั้งกฏขึ้นมากฏหนึ่ง ก็คือ กฏ 10 นาที ก็คือ เมื่อครบ 10 นาทีแล้ว เถียงกันไม่จบ ก็ต้องเชื่อว่าเค้าก็เก่งเราก็เก่ง เราก็เชื่อเค้าไป แล้วลองทำกันดู (agile ต่อเลยไง)

manage process

1. look and what’s wrong
2. fix it

ตัวอย่าง เราอยากให้มี skill retrospective มันก็ไม่ใช่การเดินเข้ามาสั่งว่า ให้ทำ retro แล้วเดินจากไป มันจะเป็นอย่างนั้นไปได้อย่างไร เราก็ต้องบอก อธิบายให้เค้าเข้าใจ แล้วทุกคนก็จะทำได้เป็น

Hiring เป้าหมายก็คือ เข้ากับทีมได้หรือเปล่า

1. find the best possible talents
2. verify team compatibility

planning 

effective meeting เราต้องตั้ง goal ขึ้นมา ว่า เราจะได้อะไรจาก meeting นั้น

tracking ทำอย่างไรให้มัน distribute ได้ เช่น ทำ kanban board, standup meeting

ทั้งหมดนี้เราจะทำอย่างไรล่ะ?

responsibility and authority

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

Monitoring > approving
Coaching > commanding
Learning > blaming
Examples > Abstracts

พยายามทำฝั่งซ้ายให้มากกว่า ฝั่งขวา เราต้องเชื่อว่า คนเราพัฒนาได้

ดังนั้น เริ่มทำไปเลย แล้วก็มาทำ retro กัน ก็กลับกลายมาเป็น agile นั่นเอง

ทำทั้งหมดนี้แล้ว มี Pitfall มั้ย

มี ตัวอย่าง ก็คือ ถ้าเราทำงานเป็น centralize จะได้ consistency ดี แตว่า availability จะห่วย เพราะว่าทุกอย่างผ่าน management อย่างเดียว เหมือนอย่าง SQL ปกติ แต่ถ้าเราเปลี่ยนเป็น Casandra ก็จะดีอย่างตรงที่ว่า ทุกคนรู้ตาม unit ที่ตัวเองรู้ แต่ว่า กระจายกันรู้ แม้ว่าจะไม่รู้ทั้งหมดก็จริง แต่ว่า ไม่ใช่หัวหน้าตายแล้วทีมก็ตายไปเลย

จงจำไว้ว่า You are limited by what you think you can do ก็คือ เราอย่าไปคิดว่า น้องจะทำไม่ได้ เพราะว่าถ้าเราคิดว่า ทำไม่ได้ ก็จะไม่ได้จริง

ตอนที่เริ่มแรกๆ ผู้ใหญ่ก็คิดว่า อย่าทำเลย คิดว่า ไม่น่าจะ work แต่ก็ตอบไปเลย รู้ได้อย่างไรล่ะ ยังไม่มี data เลย เริ่มก่อนเลย แล้วถ้าเริ่มแล้ว มันไม่ work ก็ค่อยมาสรุปและเปลี่ยนแปลงกันอีกทีว่ามันไม่ work

16.00-17.00 BDD , behavior driven development [presented by tanjai.me]

ถ้าเราเคยเจอปัญหาว่า technical spec ไม่ตรง กับการ test กับ ที่ business ต้องการ นั่นคือปัญหาที่ต้อง solve

ตอนนี้มี TDD , BDD , ATDD จะมาช่วยเราแก้ไขปัญหาเหล่านี้ได้
BDD เราต้องหาให้เจอว่า สิ่งที่เราจะทำคืออะไร criteria acceptant คืออะไร ต้องการอะไร แล้วเอามาเขียนเป็น BDD ได้

เริ่มต้นด้วย การตั้งคำถามว่า มันจะต้องทำงานอย่างไร อะไรต่างๆ เป็นรายละเอียด สิ่งที่ต้องได้ ออกมา ก็คือ concrete example ก็คือ ต้องได้ออกมาอย่างชัดเจน
เช่น ใช้อะไรกับ facebook บ้าง, ต้อง input อย่างไร , แล้วทำงานยังไง แล้วผลลัพท์เป็นอะไร ซึ่งทั้งหมดนี้ ได้ถามรายละเอียดแล้วหรือยัง ว่ามันจะต้องทำงานได้อย่างไร ไม่อย่างนั้นเราจะไม่ได้ acceptant criteria ในการทำงานในครั้งนั้น

ทั้งหมดนี้จบแล้ว ในเรื่องของ BDD

ส่วนเรื่อง tools จะเป็นของ cucumber ซึ่งจริงๆ ตัวต้นกำหนด BDD คือ RSpec(Ruby) แต่ที่ตัวนี้น่าสนใจก็เพราะว่าใช้เทส mobile app/ web ได้และยังเป็นต้นแบบให้ภาษาต่างๆด้วย ไม่ว่าจะเป็น behat(ของ PHP) และภาษาอื่นๆ (เขียนได้หลายภาษา)

feature file คือ file ที่เขียนบอกว่า สิ่งที่เราพัฒนาอยู่คืออะไร
แล้วเรายังเอามาเขียนเป็น scenario ได้อีกด้วย โดยพิมพ์บอกได้เลย ว่า given คือเริ่ม, when ก็คือ event, action ที่เราใส่เข้าไป then ก็บอกผลลัพท์ ว่าต้องได้อะไร ถ้ายาว ก็เติม and เข้าไปได้

จากนั้นเราก็เขียน step file ซึ่งมันจะเป็น programming language โดยปกติแล้ว tester ไม่ต้องการเขียน program อยู่แล้ว แต่ว่ามีทางออก ก็คือหา programmer นั่นแหล่ะมาช่วยเรา เราอาจจะรบกวนสั้นๆ วันละชั่วโมงก็ได้

จากนั้น สร้าง pom file เพื่อไปสร้าง selenium webdriver , junit และไปกำหนด dependencies

ถ้าอยากให้เริ่มง่ายๆ ก็คือ ให้ทีม test กับ dev มานั่งเขียน given when then แล้วไปนั่ง pair กับ programmer เลย เค้าจะได้ช่วยเรา เราก็สอนเรื่องการทำ test ให้เค้า ก็เป็นการ improve กันไปทั้งคู่

ตอนที่ pair programmer เราอาจจะค่อยๆหาเวลาวันละชั่วโมง ได้วันละ scenario สิบวัน ก็น่าจะได้สัก feature นึงแล้ว

โดยสิ่งที่เปลี่ยนแปลงก็คือ tester ก็จะต้องเข้าไปคุยกับ programmer , BA มากขึ้น เพื่อให้เราเข้าใจความต้องการที่แท้จริง

ก่อนที่เราจะเริ่ม cucumber เราจะต้อง

• รู้จักระบบ , feature ทั้งหมด และจะมาใหม่
• ทดสอบทีละ feature
• feature ไหนใช้บ่อย เอามาเขียน automate ก่อน

ตัวอย่าง login จะมี scenario ยังไงบ้าง เราต้องคิดให้ครบ แล้วหลังจากนั้น เราก็ค่อยเริ่มสร้างทีละ scenario แล้วแล้วทดสอบให้ผ่านในอันนั้นไปก่อน ก่อนจะไปเพิ่ม scenario ใหม่ (เพราะ tester ไม่ใช่ programmer ที่เขียนโค้ดเอง)

tools ที่ช่วย intele J, มันจะช่วยเราได้ระดับหนึ่งในการแปลงไปเป็น step file หรือว่า sublime แต่ว่าก็จะเขียนแล้ว run อีกทีนึง (มี plug in cucumber) หรือว่า ใช้ groovy หรือว่า selenium + java ถ้าเป็น mobile app ใช้ appium ทำงาน ซึ่งมันจะไปเรียก simulator อีกทีนึงเพื่อให้ทำงานต่อได้

หนังสือที่แนะนำ

• the cucumber book (ruby)
• cucumber recipes
• the cucumber for java book
• specification by example

Q: ตอนที่เขียนทดสอบนี้ ใช้ account ชุดไหน
A: จะใช้ test account , test data เก็บเอาไว้ใน step code อยู่แล้ว แต่ว่า บางอย่าง ให้ใช้ service virtualization ไม่ใช่ของจริง เพราะว่า เราไม่มีโอกาสไป commit งานของจริง (เช่นงานของ bank เราไป commit การฝาก ถอนจริงๆไม่ได้)

Q: ถ้าเป็น scenario ที่ต้องรอผลลัพท์นานๆ ก่อนดำเนินการขั้นต่อไป ทำอย่างไร
A: เขียนใน step file ให้ wait ได้ โดยเราก็เริ่มจาก wait น้อยๆก่อนแล้วค่อยเพิ่มเวลาหากว่าไม่ผ่าน เพราะว่าปกติการ wait พวกนี้จะมีผลกระทบต่อผู้ใช้งานด้วย ว่าต้องรอนานแค่ไหน

Q: อีกตัวที่ใช้ได้ก็คือ robot test tools ตัวนีต่างกันอย่างไร
A: cucumber นี้จะช่วยแก้ปัญหาเรื่อง communication ได้ด้วย เพราะว่า ตัวนี้จะมีการเขียน scenario เลย ดังนั้นเราเอาไปให้ programmer ใช้งานต่อได้เลย ซึ่งตัว robot มันจะทำงานแบบเจาะจงที่เขียนโค้ดแล้วลุยเลย ไม่ได้ solve เรื่อง communication แต่ก็เลือกใช้ได้ตามความเหมาะสม

Q: ถ้า element ตัวหนึ่ง มี test case ไปผูกอยู่ แล้ววันหนึ่ง programmer เปลี่ยนก็พังรัวๆ
A: ต้องมีการคุยกับ programmer ก่อน ว่า เราจะใช้ login แบบไหนอย่างไร เช่น email login , phone login อีกอย่างคือ อย่าเขียน feature file เดียว มีหลาย test case เพราะว่า เวลาแก้ไข จะได้ง่าย

---

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

นี่เป็นครั้งแรกของผม ที่เข้ามาในโลกของ agile จริงๆ เพราะว่าก่อนนี้ ก็พยายามอ่าน แต่ไม่เข้าใจ เพราะไม่เคยทำจริง ไม่เคยเห็นรูปแบบจริงๆ เห็นแต่แบบปะติดปะต่อ (ภาพ post it ลอยมา, ภาพ standup meeting ลอยมา, ภาพ kanban board ลอยมา แค่นั้น แต่ไม่รู้ว่ามันมีความเชื่อมโยงกันยังไง รู้ว่า อ๋อ ทำหมดนี้ก็น่าจะเรียกว่า agile มั้ง ไม่รู้ว่าไปเอาความเชื่อผิดๆแบบนี้มาจากไหน) แล้วเราเอามาเชื่อมโยงทั้งหมดไม่ได้ นี่เลยเป็นโอกาสครั้งแรกที่ทำให้เข้าใจภาพรวม ทั้งภาพกว้างและภาพลึกของ agile ในวันเดียว แบบฟรี! (อย่างที่บอก ครั้งหน้าเก็บเงินเพื่อคัดกรองคนเถอะครับ)

ก็ต้องกราบขอบพระคุณผู้สนับสนุนอีกครั้ง รวมทั้งทีมงานด้วยที่จัดงานนี้ขึ้นมาครับ ครั้งหน้า ไม่น่าจะพลาด ถ้าไม่ได้ติดงานอะไรด่วน และยังลงทะเบียนทันนะครับ 555