tnpl.me

team

ผมพบว่ามีหลายวิธีที่จะ manage source code และ manage pull request (หรือ merge request) แต่ผมยังไม่เจอว่ามีใครเขียนรวบรวมไว้

ผมจะ focus ในเรื่องที่เกี่ยวกับ การ Approve code การ Run CI และการ Merge code

การ Approve code

การ review สามารถทำได้ทั้ง offline และ online เช่น

  • review offline แบบ pair programming
  • review offline แบบ mob programming
  • review online ผ่านระบบ เช่น GitHub, GitLab

กฎเกณฑ์ในการ approve code มีหลายแบบที่สามารถเลือกใช้ได้ ไม่ว่าจะ review แบบ offline หรือ online เท่าที่ผมรู้จักมีประมาณนี้

Read more...

หลังจากได้ฟัง Clubhouse ของต่างชาติเกี่ยวกับการทำงานของ Product & Engineer ก็มีประเด็นที่เค้าพูดกันถึง Retrospective มักจะ focus ผิดจุด เลยอยากเขียนเอาไว้เตือนความจำ

Retrospective ควรจะ focus ว่าเราจะ deliver value ให้ customer ได้เร็วขึ้นอย่างไร มี process ตรงไหนที่ทำให้ deliver value ช้า เช่น build นาน, ต้องรอ manual test, รอ review code นาน, แก้ code หลายรอบ, product spec ไม่เคยนิ่ง, ติด breaking change deploy ไม่ได้ ฯลฯ

ทำไมต้อง focus แค่ deliver value?

High-performance team กับ normal team ต่างกันตรง speed ในการ deliver value ทีมที่ deliver ได้เร็วกว่าจะมีเวลามากกว่าในทุกๆ เรื่อง เช่น เมื่อส่ง feature ได้เร็ว ทีมก็จะมีเวลาในการแก้ไขปัญหาได้เร็วด้วยเช่นกัน สามารถทดลอง idea ได้มากกว่า iterate ได้เร็วกว่า

ปัญหาของการทำ Retrospective แบบทั่วๆ ไป

  1. Retrospective ส่วนใหญ่ focus แค่ feeling ของคนในทีม ไม่ได้ focus เรื่องการ improve process ให้ deliver value ได้เร็ว
  2. มีแต่ปัญหา list ออกมา แต่ไม่มี solution/action ออกมา
  3. มี solution/action แต่ไม่มี ownership ที่ชัด
  4. มี ownership แต่ไม่มีการ follow up progress และ action ไม่เกิด
  5. มี action และ ownership แต่ปัญหาต้องการ buy-in จากคนอื่นๆ ซึ่ง owner ไม่มี power มากพอ
  6. มี action มี power แต่ปัญหาถูกแก้ช้าเกินไป ไม่ถูกทำให้มีความสำคัญ

ถ้าทำ retrospective ที่ focus on improve deliver process และมีการแก้ไขปัญหาได้เร็ว ทีมจะทำงานได้เร็วขึ้น สนุกขึ้น มีความสุขมากขึ้น และด้วย speed นี้จะทำให้ team ทิ้งห่างจากทีมอื่นๆ ได้เร็วยิ่งขึ้น

#agile #team