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

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

Advertisements
Agile,TDD

ครั้งแรกกับอไจล์(เกรียน) เป็นยังไงเหรอ ?

พอดีวันนี้มีเพื่อนสมัยปริญญาตรีที่ยังอยู่ในสายงาน Software Development ทักมา ถามว่าผม “เปิดอบรมเรื่อง อไจล์ ด้วยใช่ไหม” แน่นอนว่าผมตอบกลับไปแบบทันทีว่า “บารมีผมยังไม่พอ” ยังไม่รู้จักมันอย่างแท้จริงสักเท่าไหร่ ที่ทำ ๆ อยู่ตอนนี้ก็แค่ทดลองตามหลักการที่ดูน่าเชื่อถือ และดูเหมือนมันเป็นจริงยิ่งกว่าสิ่งที่ทำมา ก็เลยแนะนำเพื่อนไปว่ามีคนรู้จักเปิด Train อยู่แล้วก็ให้เบอร์ติดต่อไป …

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

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

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

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

Engineer Pratices

4 Rules : Certified Scrum for Developer

ช่วงอาทิตย์ที่ผ่านมาได้มีโอกาสไปเรียนรู้ Scrum ที่ลงไปในด้านที่เกี่ยวกับ Engineering  Practices ซึ่งใน Class มีสิ่งนึงที่เขาเน้นมาก ๆ ทุกครั้งที่คุย ทุกครั้งที่ Review Code จะกลับมาที่ กฏที่เขาตั้งไว้สำหรับทำงานใน Class กฏทั้งหมดมีด้วยกัน 4 ข้อ ดังนี้

4 Rules

1.  Test First : ก่อนจะเขียน Code หรือ Implement อะไรให้เขียน Test ก่อนเสมอ

2.  Make It Simple : กฏข้อนี้ตรงตัว แต่ในความคิดเห็นของผมมันน่าจะแปลว่า “อย่าคิดซับซ้อน คิดให้เข้าใจง่ายไว้ก่อน” แต่เป็นกฏที่เขาย้ำนักย้ำหนาว่า “มันเป็นกฏที่ยากส์ในการทำมากส์ที่สุด”

3.  Show your intent in your code : ว่าด้วยการเขียน Code ให้พยายามสื่อสารให้ได้ว่าเรา ตั้งใจ ให้ Code เราทำอะไร เขามักจะพูดร่วมกับอีกคำคือ “code intention important than code style”

4.  No Duplicate : เคยได้ยินกฏประมาณว่าถ้าเมื่อไหร่ที่คุณต้องทำอะไร แล้วคิดโดยเริ่มจากการ Copy ของเก่ามาแก้นิดหน่อยเนี่ย นั่นแหละ Duplicate Code

จริง ๆ ก็ไม่รู้จะอธิบายยังไง แต่สิ่งที่ได้จากการไป csd คือการลงมือทำใน env ของ scrum จริง ๆ และมักจะโดน Comment กันเรื่อง 4 Rules นี้เสมอ ๆ ใน Session Code Reviews ช่วงเช้า … มีโอกาสจงไป