Dev เสร็จวันสุดท้าย QA เทสไม่ทัน

มันเนื่องมาจากโพสหนึ่งใน Agile66 fb group ซึ่งทำท่าจะยาวผมเลยเอามาลงบล็อกซะเลย:

วันนี้มีคำถามมาถามค่ะ
จะจัดการอย่างไร เมื่อ รู้ว่า งานที่เราทำไป ไม่เสร็จทัน ตามที่เราเคย commit ไว้กับ PO
เพราะ ทุกอย่างมาเสร็จในวันสุดท้ายของ iteration สุดท้าย
tester อยู่ ปลายน้ำ อีกแล้ว แง้แง้ T___T

เข้าเรื่องกันเลย วันรุ่นใจร้อน

ข้อสังเกตที่หนึ่ง เป็นไปไม่ได้ที่ทั้งทีมจะเพิ่งมารู้ว่า งานทำไม่น่าจะทันในสปรินต์(iteration) แต่น่าจะเป็นเพราะ ไม่หลอกตัวเอง คือมองโลกในแง่ดีเกินไปว่าปล่อยทิ้งไว้เดี๋ยวก็มีปาฏิหาริย์เอง ไม่ก็ มีวัฒนธรรมลงโทษคนบอกข่าวร้าย ทำให้ไม่มีใครอยากบอกว่า งานจะไม่เสร็จ

ข้อสังเกตที่สอง ทีมนี้ไม่การแบ่งโปรเซสเป็นสองขั้นคือ Dev และ QA (ซึ่งขอบอกว่า อไจล์ไม่เคยห้ามว่า ไม่ให้แบ่ง เพราะฉะนั้นแบ่งได้ หลายคนพออไจล์บอกไม่มี ก็ไปตีความว่า มีไม่ได้ อันนี้ผิด ไปคนละทางเลย กลับเข้าเรื่องดีกว่า) การที่งานเดฟเสร็จวันสุดท้าย แล้วคิวเอ ไม่ทันนี่แสดงให้เห็นถึงปัญหาการสื่อสารระหว่างกันของทั้งคู่ คนหนึ่งไม่ได้ดูเลยว่า เสร็จเมื่อไหร่ อีกคนถึงจะทำทัน ส่วนอีกคน ก็บอกว่าไม่ใช่เรื่องของฉัน ถ้ามันเสร็จให้เราไม่ทันเวลา เราก็เบลมมันซะว่า มันทำงานช้าเราเลยทำไม่ทัน เห็นได้ว่า ทั้งสองฝ่าย มีปัญหาด้านการสื่อสารรุนแรงมาก

ทางแก้ล่ะ?

1. สกรัมมาสเตอร์ ควรตบตูดการ daily scrum ด้วยคำถามที่ว่า “คิดว่าสปรินต์นี้ยังทำทันหรือไม่?” ถ้าคำตอบคือ “ทัน” ให้ถามต่อว่า “ทำไม?” เขาจะต้องอธิบายได้ว่า งานเดฟจะเสร็จเมื่อไหร่ และ คิดเอจะทำต่อได้อย่างไร และเสร็จจริงหรือไม่ ถ้าเขาตอบไม่ได้ อันนี้แสดงว่า เขามองโลกแง่ดี ให้ ถามไล่จากคิวเอว่า ต้องการเวลาเทสเท่าไหร่ แล้วนับกลับมาว่า เดฟ ต้องเสร็จเมื่อไหร่ และเป็นจริงได้หรือไม่ ถ้าไม่ได้ ก็ให้มีการ replanning ให้ตรงกับความเป็นจริง

2. สอน ทุกคนด้วย กฏข้อที่ #29 กรณีนี้จะเห็นว่า เดฟ เป็นพระเจ้าของ คิวเอ เพราะฉะนั้น เดฟทำอะไรมันก็จะกระทบกับชีวิตของ คิวเอโดยตรง เวลาเดฟทำอะไรก็ต้องคิดถึงคิวเอให้มากๆ เหมือนพระเจ้าที่รักมนุษย์ทุกคนเสมือนลูก ส่วนคิวเอก็ต้องมีความเชื่อมั่นและติดต่อกับพระเจ้ามากๆ เพื่อให้รู้ว่าพระเจ้ามีแผนให้กับเราอย่างไร เราจะได้ปฏิบัติตัวได้ถูกต้อง ส่วน คิวเอนั้นก็เป็นลูกค้าของเดฟ หมายความว่า การที่เดฟจะทำอะไรก่อนหลังอย่างไรนั้น จะต้องทำเพื่อตอบสนองความต้องการของคิวเอ เพราะเราไม่ได้ทำงานเอามัน แต่เป็นการทำเพื่อตอบสนองต่อลูกค้า สตอรีไหนคิวเอต้องการทำก่อน ต้องทำตามนั้น และ คิวเอจะรู้ว่าต้องใช้เวลาเท่าไหร่ ในการเทสก็จะทำให้เกิดจุดร่วมว่า ต้องเดฟเสร็จก่อนวันนั้น มิฉะนั้นก็จะไม่สามารถทำสตอรี เสร็จในสปรินต์ได้

3. ทุกอย่างมันเดินทางมาถึงจุดที่ไม่สามารถแก้ไขได้แล้ว จงคลานเข่าไปหา PO แล้วเล่า เรื่องทุกอย่างให้ฟังว่าทุกคนทำผิดพลาดอย่างไร และ แต่ไปจะแก้ไขอย่างไร และจงรับการลงโทษซะ อย่างแรงที่สุดคือ เขาบอกว่า จะไม่ให้ทีมเราทำงานให้เขาแล้ว ก็จงยอมรับมัน เพราะเป็นความผิดพลาดของเราเอง (แต่ไม่ค่อยเกิดหรอกนะ สำหรับความผิดครั้งแรก แต่ถ้าสัญญาแล้วทำไม่ได้หลายครั้งนี่ อาจจะมีได้) ถ้าได้โอกาสแล้ว สปรินต์ใหม่ ไม่ต้องทำแพลนนิ่ง ให้เอาแผนเดิมที่ทำไม่เสร็จนั่นแหละ มาทำต่อ โดย ให้ทั้งทีม ทุกคนช่วยกันทำให้เสร็จทีละสตอรี จากบนลงล่างตามลำดับความสำคัญ การทำอย่างนี้จะช่วยให้ทีมเริ่มสื่อสารและมีความเป็นเจ้าของร่วมกันขึ้น (collective ownership) มันอาจจะเป็นการดูแล้วเสียเวลาแต่รับรอง ผลลัพธ์ในระยะยาวนั้นคุ้มค่ายิ่งนัก

หวังว่าจะให้ความกระจ่างไม่มากก็น้อย

ป.ล. มีหลายคอมเมนต์ที่ผมเห็นแล้วขัดใจ ขอนำมาแก้ตรงนี้

– ATDD (Acceptance Test Driven Development) ไม่สามารถช่วยแก้ปัญหาการไม่สื่อสารกันของคนในทีมได้ มันเป็นส่วนขยายของการสื่อสารภายในให้ก้าวออกไปสู่ภายนอกคือลูกค้าต่างหาก ผมกล้าพูดอย่างนี้เพราะว่าเป็นคนแรกที่นำเรื่องนี้มาเผยแพร่ (อาจจะไม่ถึงชั้นในประเทศไทยแต่ค่อนข้างมั่นใจว่าเป็นคนแรกในกรุ๊ปอไจล์๖๖นี้-ใครไม่เชื่อลองไปหาต้นตอดูสิ)
– Dev ไม่ได้เก่งกว่า QA หรอกนะ ต่างคนต่างมีหน้าที่ เดฟจะรู้เรื่องเทคโนโลยีมากกว่าซึ่งก็ดีแล้วเพราะจะทำให้โค้ดมีคุณภาพมากขึ้น แต่ก็ต้องยอมรับว่า คิวเอมีความเข้าใจในธุรกิจและความต้องการของลูกค้ามากกว่า เพราะฉะนั้นคิวเอจะรู้มากกว่าเดฟว่าอะไรคือสิ่งที่ลูกค้าต้องการจริงๆ เพื่อป้องกันปัญหาทำแล้วกลายเป็นดีเฟกต์ เดฟจะต้องยอมรับฟังความคิดเห็นของคิวเอให้มาก การถือดีของเดฟนำมาซึ่งความฉิบหายแก่ทีมมานักต่อนักแล้ว (คิวเอคนไหนยังทำตัวเป็น clicker คือคอยเทส แบบคลิกเมาส์ตามคำสั่งชาวบ้าน โดยไม่สนใจลูกค้าก็เตรียมตกงานได้เลยนะ โลกยุคใหม่ไม่ต้องการคุณ)
– อไจล์อาจจะมี QA ก็ได้นะ อไจล์ไม่เคยพูดถึงตำแหน่งคิวเอก็จริง แต่ไม่เคยเลยที่จะห้ามว่ามีไม่ได้ การที่ใครสักคนบอกว่าห้ามมี อาจเป็นเพราะเขามาจากสภาพแวดล้อมที่ดีมากๆ ซึ่งอาจจะยากที่จะนำวิธีการแบบนี้มาปรับใช้ในสภาพแวดล้อมปรกติได้

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s