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

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

Engineer Pratices,Testing,Visualization

Rule, Workflow and Technical Activity on Code Reviews

สิ่งสำคัญอย่างนึงที่ได้จากคลาส CSD แบบเน้น ๆ คือทุกเช้า 9:00 – 10:00 จะมีการทำ Code Reviews ซึ่ง Terry จะเอา Code ที่เขียนเมื่อวานขึ้นจอแล้วก็เริ่มจัดการ Reviews Code ในทุก ๆ ส่วนตาม Coding Agreement ที่กำหนดกัน 4 ข้อ โดยการไปอบรมครั้งนี้ผมเกือบจะจมอยู่กับ Robot Framework อาจจะมีบ้างก็ไปทำ Jenkins ให้ Start Server Tomcat เพื่อเทสแบบ Local แต่เวลาส่วนมากจะไปอยู่ที่การเขียน Script เพื่อทำ Automate Acceptance Test ส่วนนึงอาจจะเพราะวันแรก ๆ ผมเองอยากเขียน Robot Framework เลยหยิบ Task ของ Backlog Item แรกมาทำ พอรู้ตัวว่าอยากเขียน Java ก็ไม่เหลือแล้ว หลุดออกมาจากตรงนั้นก็เจอ Task Robot ของ Item ที่ 2 รออยู่ ผมจึงเป็นคนอาภัพที่อยากเรียน CSD Java แต่ไม่ได้เขียน Java เลย (T-T) แต่สิ่งดีที่ผมได้พบคือ หลังจากที่เราเขียน Robot Framework แล้วถูกเอามา Reviews ทั้งจาก Terry และ จั๊ว ทำให้ผมมองภาพของการเขียน ATDD เปลี่ยนไปเยอะมาก ๆ

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

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

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

Visualization

แค่ซุกฝุ่นผงไว้ใต้พรม … หรือไฟที่กำลังไหม้อยู่บนฝ้า

ผมเป็นคนนึงที่มักจะได้ทำงานในองค์กรใหญ่ ๆ ที่ต้องมีการตรวจอะไรต่อมิอะไรประจำปี เช่นการตรวจ 5 ส, การตรวจวัดประเมิณการศึกษา (สมัยเป็นอาจารย์) รวมทั้งการตรวจอะไรต่อมิอะไรอย่างพวก Internal Audit ซึ่งทุกครั้งที่มีการตรวจ ผมก็จะมี Pattern เหมือน ๆ กันอย่างนึงคือ พยายามพูดในสิ่งที่เขาอยากได้ยิน เตรียมแสดงในสิ่งที่เขาอยากเห็น เพื่อให้ตัวเองรอดออกจากสภาวะกลืนไม่เข้าคายไม่ออก ของการตรวจครั้งนั้น ๆ จะเรียกว่าผักชีโรยหน้า หรือ ปัดผงเข้าใต้พรม ก็ได้ คือยอมทำให้ภาพมันดูดีไว้ก่อนถึงแม้ว่าเราจะรู้ก็เถอะว่าจริง ๆ แล้วใต้พรมมันแย่ขนาดไหน

http://topicstock.pantip.com/religious/topicstock/2012/02/Y11710532/Y11710532-15.gif

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