เคยเจอปัญหาแบบนี้มั้ยครับ?
เช้าวันหนึ่ง ณ บริษัทซอฟท์แวร์เฮ้าส์
พี่ PM: น้อง QA พี่เพิ่งได้อีเมล์จากลูกค้ามาขอเพิ่ม requirement มาตัวนึง กับแก้ของเก่าตัวนึง
น้อง QA: หรอพี่ แล้วทางฝั่ง Dev เค้าว่าไงหละฮะ?
พี่ PM: ทางนั้นเค้าก็ไม่อยากทำหรอกนะเพราะ release date ก็ใกล้เข้ามาแล้ว แต่มันก็เลี่ยงยาก
น้อง QA: ถ้ามันเลี่ยงไม่ได้ ทางผมเองก็คงต้องเอางานมาดูแล้ว estimate effort ใหม่ก่อนฮะ
พี่ PM: คือ … จริงๆแล้ว ผู้ใหญ่เค้าก็กำชับมาว่าห้ามเลื่อนวัน release อยู่ดีอะน้อง
น้อง QA: อ่าว …
การเปลี่ยนแปลงหรือเพิ่ม Requirement เป็นเรื่องปกติมากๆในการทำ software development project ครับ ผมมั่นใจว่าเพื่อนๆทุกคนคงจะเคยเจอปัญหาแบบนี้มาแล้ว นั่นคือลูกค้าขอเพิ่มนั่นเพิ่มนี่ … แต่ให้เวลาทำเท่าเดิม จริงๆมันไม่ยุติธรรมเอาซะเลย แต่มันคือสัจจธรรมครับ ฮ่าๆๆ เอาน่าๆ ทุกปัญหามีทางออกครับ เราลองมาดูรูปนี้กันก่อน
ความท้าทายที่เรากำลังเผชิญอยู่ก็คือ งานเพิ่ม (scope increases) แต่ต้องเสร็จให้ตรงตามเวลาเดิม (time fixes) งั้นเอาไงดีครับ ว่ากันตามทฤษฎีบวกกับประสบการณ์ของผมก็มีวิธีแก้ไขหรือผ่อนหนักให้เป็นเบาอยู่ 3 วิธีดังนี้ครับ
เพิ่ม Resource ได้ทันใจ
อย่างแรกที่ผมจะทำก็คือเอา Developer มาช่วยงานซะเลย ข้อนี้ผมคิดว่าพอจะทำได้นะครับ เพราะว่าเท่าที่ลองสังเกตดู พอ Developer ส่งงานให้ QA แล้ว ปริมาณงานหลักก็จะลดลงมากครับ งานที่เหลือก็คือ standby รอรับแก้บั๊ก มันคงดูไม่ดีที่จะให้ dev มานั่งเฉยๆใช่ปะ? งั้นก็ขอให้ Developer มาช่วยหน่อย แล้วจะช่วยตรงไหนได้บ้าง? ที่ผมจะเสนอก็คือให้มาช่วย Run Test ครับ เพราะว่าการเขียน Test Spec เตรียม Test Data ยังไงก็ควรจะเป็น QA ที่ต้องทำครับเพื่อให้ Test Spec ออกมาด้วยมุมมองของ QA จริงๆ ผมมีหลักในการเลือก Developerที่จะมาช่วยทำอยู่เล็กน้อยคือ
- เลือกคนที่ดูแล้วว่าจะต้องแก้บั๊กน้อย ที่สุด คือใครที่รับผิดชอบงานที่อาจจะเกิดบั๊กเยอะๆก็อย่าให้เค้ามาช่วยครับ ให้เค้าเตรียมตัวให้พร้อมไว้สำหรับแก้บั๊กดีกว่า จะได้ไม่ต้องมาสลับปรับเปลี่ยนคนระหว่างทางให้วุ่นวาย
- ถ้าเป็นไปได้ก็หาน้องใหม่ของทีมมาช่วย ครับ เพราะว่านอกจากจะได้ช่วยให้ project เสร็จตรงเวลาแล้ว ผลพลอยได้ที่สำคัญยิ่งคือ น้องๆก็จะได้เรียนรู้งานของตัวเองไปในตัวครับ อันนี้เห็นผลชัดเจนเลยฮะ
ข้อควรระวังก็คือเราต้องชั่งน้ำหนักให้ ดีๆครับว่าเราจะไม่เสียเวลามากเกินไปกับการ Train ให้ Developer เข้าใจกระบวนการ Run Test ครับ ไม่งั้นจากที่จะเร็วขึ้นจะกลายเป็นช้าลงซะเปล่าๆ
ลด Quality อย่างมีสไตล์
ผมคิดว่าถ้าถึงช่วงวิกฤต จริงๆ เราก็ควรจะพิจารณาลดคุณภาพของงานลงมาบ้างเพื่อจะได้ส่งงานทันเวลาครับ แต่การลดคุณภาพครั้งนี้ก็ควรทำอย่างมีหลักการด้วย หนึ่งในตัวเลือกที่พอจะทำได้คือการตัดการทำ Cross Platform Testing ออกไปบ้าง ดูตัวอย่างจากรูปครับ
สมมติว่าเราทำระบบที่เป็น Web Application ซึ่งการ Test ส่วนใหญ่จะเกิดขึ้นที่สองส่วนคือ Server (support Linux กับ Solaris) กับ Client (support IE กับ Firefox) เพื่อคุณภาพที่ดีที่สุดเราจะทำการ Test ทุกๆ Test Case กับทั้ง 4 สายงานครับ ซึ่งแน่นอนต้องกินเวลามาก แต่ตอนนี้เวลาเราจำกัดมากแล้ว ดังนั้นเราก็ลองออกแบบ Test Strategy ใหม่ครับ โดยการไม่ต้องทำแบบ Full Cross Platform Testing แต่เราจะเลือก Test เฉพาะส่วน (Features) สำหรับแต่ละสายงานครับ หลักสำคัญคือเมื่อเอาทุกสายงานมารวมแล้วทุก Test Case จะต้องถูก Run ครับ
เราควรจะ Test ให้เยอะๆกับ Feature ที่ซับซ้อนและถูกใช้งานบ่อยๆ อีกจุดหนึ่งที่สำคัญก็คือเราควรจะเน้นเป็นพิเศษกับ Third Party ที่ release ใหม่ เช่น Linux หรือ Solaris version ใหม่หรือออก Patch ใหม่มา รวมถึงพวก Browser version ใหม่ๆ เพราะว่าโอกาสที่จะเจอบั๊กที่เีกี่ยวกับ Third Party เหล่านี้ก็มีสูงครับ … เราเจอเองย่อมดีกว่าให้ลูกค้าเจอแน่นอน
เพิ่ม Time ด้วยการลด Time
อย่าเพิ่งงงไปครับ ความหมายที่ผมต้องการจะสื่อก็คือเราสามารถหาทางเพิ่มเวลาทำงานที่จำเป็นได้ โดยลดเวลาทำงานที่ไม่จำเป็นลงไป ข้อนี้จะประยุกต์ใช้ได้กับเพื่อนๆที่ต้องทำงานโดยมี process มากมายหลายขั้นตอนมาควบคุม เช่น Developer เขียนโค๊ดเสร็จแล้ว แต่กว่าจะเอามา Test ได้ต้อง review, approve, issue Test Spec ก่อน ถัดมาก็ต้อง create baseline เพื่อเก็บ reference ไว้อีก แล้วถ้าเอามา Test แล้ว Fail หละ ก็ต้องกลับไปทำแบบเดิมอีกรอบ … เสียเวลาจริงๆ
ทำไงดีครับแบบนี้ ข้อแนะนำก็คือให้ QA เดินมาเคาะประตูหลังบ้าน Developer เลยครับ … ถ้างานเสร็จแล้วก็ขอ software มา Test ก่อนเล้ยยย ไม่ต้องรอครับ เอามาเพื่อ Test ดูกับ Environment จริงว่าที่แก้มารอบเนี่ยะ ยังพังอยู่มั้ย ถ้า Fail อีกก็จะได้บอกให้ Developer กลับไปแก้ได้เลยฮะ ไม่ต้องเสียเวลากับ process เพิ่ม ถ้าไม่พังแล้ว ก็ดีเลยครับ ค่อยมาตามเก็บพวก process ทีหลัง แบบนี้เราก็เหมือนได้เวลาทำงานที่เป็นประโยชน์จริงๆเพิ่มมาแล้วหละครับ อิอิ
ปล. อย่าให้ Manager กับ SQA รู้ละกันนะ ฮ่าๆ
แก้ปัญหานี้แบบไหนดีครับ?
เช้าวันหนึ่ง ณ บริษัทซอฟท์แวร์เฮ้าส์
พี่ PM: น้อง QA พี่เพิ่งได้อีเมล์จากลูกค้ามาขอเพิ่ม requirement มาตัวนึง กับแก้ของเก่าตัวนึง
น้อง QA: หรอพี่ แล้วทางฝั่ง Dev เค้าว่าไงหละฮะ?
พี่ PM: ทางนั้นเค้าก็ไม่อยากทำหรอกนะเพราะ release date ก็ใกล้เข้ามาแล้ว แต่มันก็เลี่ยงยาก
น้อง QA: ถ้ามันเลี่ยงไม่ได้ ทางผมเองก็คงต้องเอางานมาดูแล้ว estimate effort ใหม่ก่อนฮะ
พี่ PM: คือ … จริงๆแล้ว ผู้ใหญ่เค้าก็กำชับมาว่าห้ามเลื่อนวัน release อยู่ดีอะน้อง
น้อง QA: เพื่อนๆจะตอบว่าอะไรครับ
ที่มา http://www.chapterpiece.com/project-management/2010/01/09/how-to-test-in-short-time
