TanThai.Com

Story#8 Paradox ของสายการผลิตซอฟต์แวร์

Visit: https://codingugly.com/?p=46

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

Tool ที่ป็อปปูล่ามากๆในสายนี้คือ JIRA ซึ่งเป็นบอร์ดที่ทีมงานต้องดูทุกวัน กล่าวคือทีมจะพยายามทำงาน และ move งานไปทางด้านขวาไปหา “done” ให้ได้มากที่สุด แต่ปัญหาคืองานบนบอร์ดไม่สามารถแสดงถึงความสัมพันธ์ของแต่ละงานได้อย่างถูกต้องนัก งานบางอย่างมีความต่อเนื่องกับงานก่อนหน้าและงานถัดๆไปในลักษณะ feedback loop ก่อนที่แต่ละงานจะย้ายเข้าไปอยู่ในช่อง “done“ ได้อย่างแท้จริง

ถึงแม้มันจะช่วยเรา visualize งานที่กำลังทำอยู่ว่าเสร็จไปถึงไหนแล้ว หรือแม้กระทั่งดูว่างานตอนนี้เยอะไปหรือเปล่าก็ตาม แต่ก็ไม่สามารถจะ visualize ความสัมพันธ์ที่ว่าได้ ยกตัวอย่างเช่นงานที่ต้องทำการทดลอง เช่นทดลอง feature ใหม่ๆที่จะเป็นอนาคต ของบริษัท เหมือนอย่างที่ startup ทั่วไปทำ MVP (minimum viable product) คือมันยากมากที่จะเอางานมาวางเรียงกันบน JIRA board แล้วลงมือทำ และสิ่งที่อยู่ในบอร์ดก็ช่วยเราได้แค่แสดงว่างานเสร็จไปถึงไหนแล้วแค่นั้น หากเกิดกรณีนี้ สิ่งที่ต้องทำควบคู่กันไปคือการเน้นการใช้ story หรือใบงาน (ticket) บน JIRA ให้เป็นเหมือนการเล่าเรื่อง (narrative) และสร้างความสัมพันธ์ของแต่ละงานด้วยการ linked แต่ละ tickets เข้าหากัน ดังนั้นสิ่งที่ต้องทำ คือการส่งเสริมให้ทีมงานมีการพูดคุยแบบ face to face ภายในทีมให้มากและช่วยกันบันทึกความสัมพันธ์นั้นๆลงใน tickets

สมมติว่าเรากำลังต้องวางแผน epic เกี่ยวกับ performance improvements แน่นอนว่าเราคงไม่มองบอร์ดแล้วพยายามหาว่าเราจะ deliver features อะไรใน release นี้ เราจะมองว่าเราจะ improve อะไร และอะไรคือ feedback ที่จะเติมกลับเข้ามาใน release ถัดไป หากเรามอง JIRA บอร์ดแล้วพยายามมองเป็นสายพานการผลิตเพื่อ delivery ชิ้นงาน ก็จะไม่ต่างจากไลน์การผลิตในโรงงานเท่าไร

ยิ่งเรามอง swim lane ทั้งวันเพื่อดูว่างานของ sprint นี้ไปถึงไหนแล้ว ดู backlog และ roadmap ถัดๆไปว่าเป็นอย่างไร ยิ่งส่งเสริมให้เราทำงานด้วย mindset แบบไลน์การผลิตมากยิ่งขึ้น โดยไม่มองถึงความสัมพันธ์ใดๆฃองแต่ละงานเลย และนอกจากนี้ยังทำให้เกิดความคิดที่ว่าหากเราทำได้เยอะๆยิ่งดี บ่อยครั้งการทำน้อยๆ หรือการทำไปเรียนรู้ไป ลบทิ้งทำใหม่เพื่อ improve งาน กลับได้ผลลัพธ์ที่ดีกว่าในเชิงคุณภาพ