Coach,Design,Requirement Gathering,Visualization

Design Sharing ด้วย Design Studio

สองวันที่ผ่านมาได้มีโอกาสได้ดู และมีส่วนร่วมในการทำ Product Discovery แบบจริง ๆ จัง ๆ ที่ Office เนื่องจากเริ่มมีแนวคิดที่จะเอาวิธีเก็บ Requirement วิธีคิดวิเคราะห์ Requirement รวมถึงวิธี Design ในแบบที่ทุกคนที่เกี่ยวข้องเข้ามามีส่วนร่วมกัน มาใช้ในการทำ Product จริง ๆ สักตัว ในส่วนของ Product Discovery ไว้จะมาสรุปให้ฟังอีกครั้งนึง แต่เนื่องจากวันนี้ (วันที่ 2 ของ Workshop Product Discovery) มี Session นึงที่ผมสนใจมาก เป็น Session ในส่วนของการทำ Design ร่วมกันระหว่างผู้ใช้งาน กับทีมพัฒนา ซึ่งปกติทีมที่ผมเคยทำมาก็พยายามทำเรื่องนี้ร่วมกันอยู่ แต่ส่วนมากถ้าไม่ทีมพัฒนาสร้างหน้าจอตัวอย่างมาให้ลูกค้าดู ก็จะเป็นลูกค้าออกแบบหน้าจอมาให้ทีมพัฒนาต้องทำตาม (ซึ่งเข้าใจว่าเป็นวิธีการที่ใช้กันอยู่ปกติ) ไม่ว่าจะเริ่มจากฝั่งไหนก็จบด้วยการ Reviews ร่วมกัน ซึ่งส่วนตัวมันก็สามารถตอบปัญหาได้ระดับนึง เพียงแต่ก็ยังมีบางส่วนที่ผลลัพท์ของการทำงานแบบสร้างจากฝั่งใดฝั่งหนึ่งเป็นหลัก ออกมาไม่ดีนัก พอได้เห็นวิธีการนี้จึงรู้สึกว่าน่าเอาไปลองทำดูบ้าง โค้ชหนุ่มซึ่งพาทำกิจกรรมนี้ เรียกกิจกรรมนี้ว่า Design Studio

OLYMPUS DIGITAL CAMERA

อ่านเพิ่มเติม

Agile,Engineer Pratices,Refinement,Requirement Gathering,Scale,Scrum,Visualization

เมื่อทีมเติบใหญ่ขึ้น – When your team “GROW UP”

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

TreeGrowthChart_800x550

credit image http://www.brianvellmure.com/wp-content/uploads/2014/01/TreeGrowthChart_800x550.png

อ่านเพิ่มเติม

Facilitator Skill,Requirement Gathering,Retrospective,Testing

ลองอธิบายสิ่งที่ตนเข้าใจด้วย … คำถาม

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

อ่านเพิ่มเติม

Refinement,Requirement Gathering

From Question to Specification : Specification by Example

จากวันก่อนที่พูดเรื่อง เมื่อการเทสไม่ใช่การทดสอบผลงาน แล้วก็พูดถึงวิธีการในการทำ Backlog Refinement แบบนึงให้เกิดการมีส่วนร่วม เลยรู้สึกได้ว่ายังขาดอะไรไปสักอย่างในช่วงวันแรกของ CSD เพราะทั้ง 2 หัวข้อผมลืมใส่รายละเอียดที่เกี่ยวกับกิจกรรม และการนำไปใช้อยู่พอสมควร เลยคิดว่าน่าจะเอามาพูดกันในวันนี้

อ่านเพิ่มเติม

Agile,Engineer Pratices,Refinement,Requirement Gathering,Scrum,Visualization

Collaborating in Refinement

มีสิ่งนึงที่ผมประทับใจมากในวันแรกของ Class CSD ที่ได้ไปเรียน ผมเองไปถึงเวลา 9:30 ซึ่งสายมาก ๆ และผ่านจุดที่ Terry เล่าภาพรวมของ Scrum ให้ฟังไปแล้ว และกลับมาเริ่มให้ Product Owner เล่าถึง Product ที่ทีมงานจะทำภายใน 5 วัน ที่จะอยู่ด้วยกัน โดยหลังจากเล่าภาพรวมของ Product แล้วเราจึงเริ่ม Initial Backlog Item (จริง ๆ ก็แค่เขียนมันลงไปใน Card เพราะมี หัวข้ออยู่แล้วในหนังสือ) ซึ่งหลังจากนั้นเราก็เริ่มทำ Backlog Refinement มาถึงจุดนี้มีเวลาให้เราทำกันประมาณ 1 – 2 ชั่วโมงกับการคุยกับลูกค้าเพื่อเริ่มเตรียมงานเข้า Sprint

credit image : www.castlellc.com

อ่านเพิ่มเติม

Requirement Gathering,Testing

เมื่อการเทสไม่ใช่การทดสอบผลงาน …

ใน Class CSD ที่ผมได้ไปเรียนในสัปดาห์ก่อนนั้น มีหัวข้อนึงที่น่าสนใจมากเกี่ยวกับการทำ ATDD หรือ Acceptance Test Driven Development ซึ่งว่าด้วยการคิด Acceptance Test หรือ Acceptance Criteria ก่อนที่จะเริ่มทำงาน ซึ่งแน่นอนว่าชื่อมันก็บอกอยู่แล้วว่ามันคือการ Test ในความเข้าใจของผมการ Test มันก็คือการทดสอบผลงานของเราที่สร้างขึ้นมาเพื่อ ดูว่ามันตรงกับสิ่งที่ลูกค้าต้องการหรือไม่ มันจะมีปัญหาอะไรหรือไม่ถ้ามันถูกเอาไปใช้งาน แต่ผมมาสะดุดประโยคหนึ่งประโยค ที่ Terry (ผู้สอน) พูด และเหมือนจะเป็นการให้ความหมายของคำว่า Test ได้ไม่เหมือนกับที่ผมเข้าใจมานาน จนผมต้องหยุดฟังและทำความเข้าใจ ประโยคที่ว่านั้นคือ

Test is the way to understand something that you don’t know

อ่านเพิ่มเติม