10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ ตอน กล้าๆ หน่อย

Have-Courage

เดินทางมาถึงข้อที่ 4 จาก 10 ข้อปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ สำหรับข้อที่ 4 นี้ ส่วนตัวผมจะมุ่งเน้นเรื่องของความกล้าของตัวบุคคลที่เป็นสมาชิกของทีมพัฒนาซอฟต์แวร์ ความกล้าของทีมพัฒนาซอฟต์แวร์และความใจถึงของลูกค้าด้วยเช่นกัน

ความผิดพลาด คำนี้แลดูจะเป็นคำอันศักดิ์สิทธิ์สำหรับหลายต่อหลายคน เคยมีใครสักคนกล่าวไว้และมีคนนำมาแชร์ลงบน Facebook ผมจำได้คราาวๆ ว่า “คนที่ไม่เคยผิดพลาด คือ คนที่ไม่เคยทำอะไรเลย”

พื้นที่สบายๆ ของหนู (Comfort Zone) ผมว่าทุกๆ คนมีพื้นที่กันหมด ผมก็มี คุณก็มี อาม่า อากง อาแป๊ะ บลา บลา บลา ก็มี ถ้าไม่มีอะไรสักอย่างเกิดขึ้นเราก็เลือกที่จะนั่งๆ นอนๆ อยู่ในพื้นที่สบายๆ ของหนูไป หากนั่งๆ นอนๆ นานมากไป พื้นที่สบายๆ ของหนู จะกลายเป็น สุสานของหนู ไปด้วยเช่นกัน

ความกล้า เราพูดกันเยอะ ลองมาดูความกล้ากับงานพัฒนาซอฟต์แวร์ในเรื่องของคุณภาพและการทำงานร่วมกัน

การพัฒนาซอฟต์แวร์ด้วยแอจไจล์ (Agile) นั้นเน้นเรื่องความกระฉับกระเฉ่ง ว่องไว พร้อมปรับตัวกับการเปลี่ยนแปลงต่างๆ ที่เกิดขึ้น เน้นส่งมอบซอฟต์แวร์ที่ทำงานได้ตรงตามความต้องการพร้อมคุณภาพตามที่ตกลงกันไว้และทำงานเป็นทีมเดียวกัน ดังนั้นต้องอาศัยความกล้าเป็นอย่างมากสำหรับการปรับตัวของแต่ละบุคคลและการปรับตัวของทีมพัฒนาซอฟต์แวร์

พวกเรา (We) ทีมเรา (Team)

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

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

เรื่องแรกสุดของความกล้า เมื่อมาทำงานร่วมกันเป็นทีม

  • กล้าพอไหมที่จะเปิดอกบอกเล่า อะไรที่ชอบ อะไรที่ไม่ชอบ ในการทำงานร่วมกัน
  • กล้าพอไหมที่จะพร้อมรับฟังคำแนะนำ ติเพื่อก่อ ของสมาชิกในทีม
  • กล้าพอไหมที่จะกล่าวคำว่า ขอบคุณ และขอโทษ กับสมาชิกในทีม
  • กล้าพอไหมที่จะไว้เนื้อเชื่อใจ ร่วมหัวจมท้าย กับสมาชิกในทีม

ทีมไม่ใช่แค่กลุ่มคนที่มานั่งกองๆ รวมกัน ณ สถานที่หนึ่งแล้วก็ตัวใครตัวมัน…

กล้าที่จะบอกไหมที่จะ

การพัฒนาซอฟต์แวร์แบบแอจไจล์ (Agile) นั้น เรื่องที่สำคัญมากๆ คือ ผลการตอบสนองกลับที่รวดเร็ว เพื่อทำให้เราสามารถตรวจสอบได้ว่า ใช่หรือไม่ใช้ ถูกหรือผิด ไม่มีผลกระทบหรือมีผลกระทบ ดังนั้นในเรื่องของคุณภาพของซอฟต์แวร์ผมจะเน้นเรื่องของการทำงานเชิงรุกเพื่อคุมกำเนิด Bug หรือ Defect ที่จะเกิด มากกว่า จะนั่งค่อยๆ คุ้ย แคะ แกะ เกา แงะ งัด และขี้ช้างจับ Bug หรือ Defect ที่เกิดขึ้นในซอฟต์แวร์ที่กำลังพัฒนาและต้องส่งมอบให้ลูกค้า

ดังนั้น

นักพัฒนาซอฟต์แวร์ ไม่ว่าจะเรียกขานตัวเองว่าเป็น Programmer หรือ Developer ไม่ว่าจะทั้งชั่วโมงบินต่ำๆ หรือชั่วโมงบินสูงๆ กล้าพอไหมที่จะ

  • บอกว่าตัวเองไม่รู้เรื่องอะไรบ้าง ไม่ว่าจะเป็นความต้องการของลูกค้า โครงสร้างระบบต่างๆ ขั้นตอนการออกแบบซอฟต์แวร์ กระบวนการทดสอบซอฟต์แวร์ และอื่นๆ
  • จะขอความช่วยเหลือจากสมาชิกในทีมเพื่อสอน หรือฝึก เรื่องที่ตัวเองไม่รู้
  • เริ่มเรียนรู้สิ่งใหม่ๆ เพื่อเข้ามาช่วยในการพัฒนาซอฟต์แวร์ ควบคุมดูแลคุณภาพ เพื่อส่งมอบซอฟต์แวร์ให้กับลูกค้าอย่างมั่นใจ เช่น แนวทางปฏิบัติ Test-First การเขียน Automate Testing ด้วยแนวคิดและการปฏิบัติแบบ Test-Driven Development และอื่นๆ

ผู้เชี่ยวชาญในการควบคุมดูแลและทดสอบซอฟต์แวร์ ไม่ว่าจะเรียกขานตัวเองว่า Tester หรือ QA กล้าพอไหมที่จะ

  • บอกตัวเองว่าไม่รู้เรื่องอะไรบ้าง
  • ถามในสิ่งที่ตัวเองไม่รู้และไม่เข้าใจจากความต้องการของลูกค้ารวมทั้งเอยปากขอตัวอย่างข้อมูล
  • เดินเขาไปขอความช่วยเหลือต่างๆ จากนักพัฒนาซอฟต์แวร์
  • เริ่มเรียนรู้สิ่งใหม่ๆ เพื่อเข้ามาช่วยในการพัฒนาซอฟต์แวร์ ควบคุมดูแลคุณภาพ เพื่อส่งมอบซอฟต์แวร์ให้กับลูกค้าอย่างมั่นใจ เช่น แนวทางปฏิบัติ Test-First การเขียน Automate Testing ด้วยแนวคิดและการปฏิบัติแบบ Acceptance Test-Driven Development และอื่นๆ

ผู้จัดการ นามเรียกขานว่า Manager กล้าพอไหมที่จะ

  • ให้เกิดข้อผิดพลาดเกิดขึ้น และให้ทีมได้เรียนรู้จากข้อผิดพลาดนั้นๆ เพื่อการพัฒนาและเติบโตขึ้น
  • ที่จะเอาฆ้อมไปทุบ Silo ต่างๆ แล้วให้สมาชิกของทีมมาทำงานร่วมกันโดยไม่มีค่าย ไม่มีฝ่าย
  • ที่จะทำตัวเองเป็น Role Model ในเรื่องของวินัยการทำงาน

จริงๆ ยังมีความกล้าอีกหลายๆ อย่างที่ส่วนตัวผมคิดว่าจะต้องมีและต้องกล้าที่จะลงมือทำ

Fail Fast, Learn Fast

Fail Fast, Learn Fast สำหรับผมถือว่าเป็น คำขวัญ ที่ถูกอ้างอิงถึงค่อนข้างมากในสังคมแอจไจล์ (Agile) องค์กรเองพร้อมที่จะให้เกิดการเรียนรู้จากความผิดพลาดที่เกิดขึ้นหรือไม่?

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

นำมาซึ่งสิ่งที่เรียกว่า Monitor and Control แปลเป็นไทยว่า จับตามองและควบคุม ฟังดูแล้วขนลุก

แทนที่จะพยายามป้องกันไม่ให้เกิด แต่สุดท้ายมันก็เกิด

กระบวนการของการบริหารจัดการโครงการไม่ว่าจะค่ายไหน จะมีส่วนของการทำ Project Closer และหนึ่งในนั้นคือการทำ Lesson Learned

ทำไมไม่ลองเปลี่ยนมุมมองนิดนึงให้ เกิดความผิดพลาดให้เร็วที่สุด เพื่อจะได้รู้ หยุดเพื่อปรับแก้ไข และสร้างความตระหนักเพื่อป้องกันไม่ให้เกิดขึ้นอีกหรือน้อยลง

กระบวนท่ากระบวนยุทธ์ต่างๆ ของสำรักต่างๆ ในยุทธภพของแอจไจล์ ต่างเน้นเรื่องของ การพัฒนาและส่งมอบซอฟต์แวร์ที่ทำงานได้จริงบ่อยๆ และอย่างต่อเนื่อง ดังนั้นยิ่งทีมพัฒนาซอฟต์แวร์สามารถแปลงร่าง ความต้องการ (Requirement) เป็น ซอฟต์แวร์ ทีละเล็กทีละน้อยอย่างต่อเนื่อง ยิ่งรอบการพัฒนาซอฟตฺแวร์สั้นเท่าไร การได้รับผลตอบรับว่า ใช่หรือไม่ใช่ ผิดหรือถูก กระทบหรือไม่กระทบ ก็จะกลับมาได้เร็วขึ้นเท่านั้น เพื่อจะได้หยุด แล้วนำความผิดพลาดที่เกิดขึนนั้นมาวิเคราะห์ด้วยกันทั้งทีม วางแผนดำเนินการเพื่อป้องกันร่วมกันทั้งทีม และลงมือทำด้วยกันทั้งทีม

ระดับฝ่ายบริหารกล้าพอไหมที่จะสร้าง Fail Fast, Learn Fast ในองค์กร

ขยายพื้นที่สบายๆ ของหนูออกไป

การได้มาซึ่งผลตอบกลับที่รวดเร็วนั้นโดยเฉพาะในเรื่องของการควบคุมและทดสอบคุณภาพของซอฟต์แวร์ Automate Testing นั้นต้องถูกนำมาใช้ให้ได้มากที่สุด อย่างเหมาะสม อย่างเพียงพอ และถูกจังหวะเวลา ซึ่งทุกๆ คนที่อยู่ในทีมพัฒนาซอฟต์แวร์

หลายๆ คนจะบอกว่าให้ลุกแล้วก้าวออกไปจาก พื้นที่สบายๆ ของหนู (Comfort Zone) ผมเองก็เคยพูดแบบนั้นเช่นกัน

แต่ลองมาคิดใหม่ว่าจริงๆ แล้ว เราแค่ขยายพื้นที่สบายๆ ของตัวเองออกไปน่าจะใช่มากกว่า

ดังนั้น

นักวิเคราะห์ นักพัฒนาซอฟต์แวร์ และผู้เชี่ยวชาญในการดูแลควบคุมและทดสอบซอฟต์แวร์ จะต้องเริ่มเรียนรู้และฝึกฝนทักษะต่างๆ ที่เกีย่วกับ Automate Testing ร่วมกัน อย่างต่อเนื่อง สม่ำเสมอ ด้วยกัน

เริ่มต้นจากการหาช่วงเวลาที่สมาชิกในทีมได้ฝึกฝนร่วมกัน โดยหาเวลาให้แต่ละวันให้ได้สัก 30 นาที — 45 นาที ณ ช่วงเวลาเดียวกันทุก วัน เพื่อเริ่มฝึกไปด้วยกัน ไม่ว่าจะเริ่มจากอ่านหนังสือ อ่าน Paper ทุกๆ คนไปหาเรื่อง Automate Testing มานำเสนอ ฝึกเขียน Automate Testing ฝึกออกแบบการทดสอบ และอื่นๆ ที่เกี่ยวข้อง

ทำมันต่อเนื่อง 20 วัน แล้วกลับมาดูว่า ตนเองและทีมได้พัฒนาอะไรขึ้น และวางแผนเพื่อเรียนรู้และฝึกฝนต่อไป

สรุป

สำหรับข้อที่ 4 สำหรับผมจะต้องอาศัยความกล้าจากทุกๆ ภาคส่วน เพื่อที่จะให้เกิด Fail Fast, Learn Fast ลองเอาเรื่องความกาก ความผิดพลาด ต่างๆ ของแต่ละคนมานั่งเล่า นั่งบอก ให้กับสมาชิกในทีมได้ฟัง และเราเองได้เรียนรู้อะไรจากความผิดพลาดนั้นๆ รวมทั้งขยายพิ้นที่สบายๆ ของหนูออกไปให้ใหญ่ขึ้น เพื่อเรียนรู้ เพื่อฝึกฝน เพื่อเติบโต

ไม่มีทีมพัฒนาซอฟต์แวร์ด้วยแอจไจล์ทีมใดๆ ที่จะประสบความสำเร็จได้หากไม่ก้าวเดินไปด้วยกัน ร่วมทุกข์ร่วมสุขด้วยกัน และไม่ใช้ Automate Testing

วันอังคารที่ 12 พฤษภาคม พ.ศ. 2558 เวลา 9:19น.
บางรัก กรุงเทพมหานคร
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.