Technical work ในสกรัม
Product backlog items ในสกรัมมี 4 ประเภท คือ ฟีเจอร์, บั๊ก, technical work และ knowledge acquisition
Technical work เป็นไอเท็มประเภทหนึ่ง เรียกง่าย ๆ ว่าเป็นงานเทคนิคที่ product owner อาจจะไม่ได้เข้าใจรายละเอียดเท่าไหร่ เป็นทีมที่ขายไอเดียให้ product owner ว่าควรทำนะ
ตัวอย่างของ technical work อาจจะเป็นการ setup test automation ขึ้นมา เพื่อให้ cost ของการ execute regression test ลดลง จะได้สามารถ test ได้บ่อยขึ้น ทำให้การควบคุมคุณภาพทำได้ดียิ่งขึ้น
technical work ลักษณะนี้ อาจจะไม่มี dependency กับฟีเจอร์ใบไหน สามารถทำเมื่อไหร่ก็ได้ หลังจากทำแล้ว ทีมก็มีสามารถเริ่มทำ automate test ได้
อีกตัวอย่างของ technical work อาจจะเป็นการ setup database บน test environment ซึ่งใบนี้จะต้องทำก่อนฟีเจอร์ใด ๆ ที่จำเป็นต้องเก็บลงฐานข้อมูลเป็นต้น
สรุปแล้ว จากมุมมองของ product owner ไอเท็มประเภท technical work คืออ่านไม่รู้เรื่อง ต้องคอยฟังทีมว่าทำแล้วได้ประโยชน์อะไร คุ้มค่าไหมเพื่อตัดสินใจเรียงความสำคัญ
Task ทุก task สามารถ split ออกมาเป็น technical work ได้
product owner อ่านทั้ง task และ technical work ไม่รู้เรื่องเหมือนกัน ความต่างคือ technical work นั้นถูก split ออกมาอยู่บน product backlog ก่อน sprint จะเริ่ม ส่วน task นั้นถูก break down ออกมาจากฟีเจอร์บน sprint backlog ระหว่าง sprint
หลีกเลี่ยงการใช้ technical work
ถ้าไม่จำเป็น ผมแนะนำให้หลีกเลี่ยงการใช้ technical work โดยเฉพาะเวลาที่มันทำให้ความโปร่งใสระหว่าง business กับ technical ลดลง เช่นในเหตุการณ์ต่อไปนี้
ซ่อนไอเท็มที่ carry over
จริง ๆ แล้วในสกรัมไม่มีคำว่า carry over ไอเท็ม เพราะทุกไอเท็มควรเสร็จตาม definition of done ก่อน sprint review
ถ้ามันมีความเสี่ยงที่จะไม่เสร็จ ทีมสกรัมที่ดีควรสื่อสารความเสี่ยงนี้ให้ product owner ทราบก่อนจะเริ่มทำไอเท็มนั้น ๆ
การตัดสินใจเริ่มทำไอเท็มที่อาจจะไม่เสร็จโดยไม่เปิดโอกาสให้ product owner ได้ตัดสินใจ take ความเสี่ยงนั้นเป็นการขโมย ownership ในการเลือก priority ของไอเท็มใน sprint ถัดไป
การที่ทีมปล่อยให้มี carry over ไอเท็มไป sprint หน้าแล้วให้ product owner เลือกระหว่างจะทำต่อเพราะเสียดาย หรือจะยอมทิ้งเพื่อจะได้ความคล่องตัวเท่าเดิมเป็นการทำร้าย product owner รุนแรงที่สุดเลย
ในทางกลับกัน product owner ก็ทำร้ายทีมรุนแรงที่สุดเวลาแย่งอำนาจในการตัดสินว่าจะทำแค่ไหนใน sprint นี้ไปจากทีมเช่นกัน
ถ้า product owner ไม่มีสิทธิ์ในการเลือก priority เต็ม ๆ มันยุติธรรมไหมที่จะให้เค้ารับผิดชอบ return of investment ของ product?
ถ้าทีมไม่ได้เลือกเองว่าไหวแค่ไหน มันยุติธรรมไหมที่จะไปทวงถาม commitment จากเค้าตอนจบ sprint?
พอเรารู้ว่า carry over มันร้ายแรงขนาดไหน บางทีมที่เริ่มทำไอเท็มที่เสี่ยงจะไม่เสร็จไปแล้วตอนท้าย sprint แล้วก็ทำท่าจะไม่เสร็จจริง ๆ ก่อน review ก็เลยไปเจรจากับ product owner เพื่อ split ฟีเจอร์ที่ไม่เสร็จนี้ออกเป็น technical work 2 ใบ คือครึ่งแรกที่ทำทันใน sprint นี้ และ ครึ่งหลังที่ทำไม่ทัน เอากลับไปใส่ product backlog เพื่อให้ product owner มีอิสระในการเรียง priority อย่างเต็มที่ใน sprint หน้า
แล้วทีมก็นั่งสงสัยว่า product owner เค้าโมโหอะไรนะ แล้วทำไมเค้าถึงไม่ไว้ใจทีม ทำไม product owner ถึงทำเหมือนกับทำงานกับทีมที่มี carry over ไอเท็มประจำ ๆ เลย ผมอยากบอกว่า เพราะจริง ๆ แล้วทีมนี้ก็ carry over แต่หลอกตัวเองอยู่ไง
อีกกรณีที่ไม่ควรใช้ technical work คือ…
หลอกระยะเวลาของ sprint
มีทีมหนึ่ง เป็น cross functional ทีมที่มีสกิล UX, เขียนโค้ด, เทส ไปจนถึง deploy ของเลย ทีมนี้ทำ sprint 1 สัปดาห์ แต่พวกเค้ามักจะ split ฟีเจอร์ออกเป็น 4 ใบ เช่น ฟีเจอร์โอนเงินจะแบ่งเป็น
- UX โอนเงิน,
- โค้ดโอนเงิน,
- เทสโอนเงิน และ
- deploy โอนเงิน
ซึ่ง sprint แรกก็จะเอา UX โอนเงินไปทำก่อน และอาจจะมีงานโค้ด, เทส และ deploy ของฟีเจอร์อื่น ๆ
sprint ต่อมาก็เอา UX ที่ review กันใน sprint ที่แล้วมาโค้ด แต่ตอน review อาจจะเละ ๆ หน่อยนะ เพราะยังไม่ได้เทส ต้องรอ sprint หน้า
มองจากมุมผู้ใช้งาน ทีมนี้ไม่ต่างอะไรกับทีมที่ทำ sprint 4 สัปดาห์เลย เพราะไอเดียใหม่ ๆ ที่อยากได้วันนี้ ก็ต้องคอยอย่างน้อย 4 สัปดาห์กว่าจะเห็นของอยู่ดี
สกรัมคือลูกแก้ววิเศษของหมอดู
สกรัมเป็นเหมือนลูกแก้วหมอดู ที่จะช่วยให้เราเห็นอนาคตของ release ถัดไปราง ๆ ใน sprint review
จะจบ sprint แบบเสร็จครึ่ง ๆ กลาง ๆ จะจบ sprint แบบของไม่มีคุณภาพ เราก็จะได้เห็นเงาราง ๆ ว่า release หน้ามันจะออกมาแบบนี้แหละ อยู่ที่ทุกคนที่ได้เข้าร่วมใน sprint review ละ ว่าอยากจะทำอะไรกับมันไหม ถ้าไม่ทำอะไร แล้ว release ออกมาเละเหมือนตอน review ก็ถือว่าสกรัมได้ทำหน้าที่ของมันอย่างสมบูรณ์แล้ว
ถ้าเราเป็นหมอดู เราก็อยากได้ลูกแก้วใส ๆ มากกว่าลูกแก้วหม่น ๆ จริงไหม
ฉะนั้นอย่าเอา technical work มาซ่อนปัญหา เพราะความบาดตาที่เราเห็นใน sprint review นั่นแหละคือกลไกการทำงานของสกรัมที่กำลังเตือนให้เราปรับแผนการ
