Software Development Team

หลังจากทำงานมาสี่ปี เจอปัญหามามากมาย ได้แก่

• Component ต่างๆ ไม่มีใครสามารถเล่าได้ หรือรันให้ดูเป็นส่วนว่ามันทำงานอย่างไร ต้องเข้าไปอ่าน Code แล้วลองรันดูเอง ถึงจะรู้
• จะรันโค้ดส่วนต่างๆ ได้ต้อง setup นู่นนี่นั่น ขึ้นมาก่อนถึงจะรัน test ได้
• รันแล้วยังคงไม่รู้อยู่ดีว่ามันทำงานยังไง เพราะตอนรันไม่มีคนมาอธิบาย ตอนอธิบายก็คือเป็นการสอนกลุ่มใหญ่ ดูสไลด์เอา
• บางครั้งถึงกับรันไม่ได้เลย จนเหนื่อยใจเลิกรัน test กันไป
• เมื่อมีการแก้ไข Component ไม่สามารถรู้ได้ว่าสิ่งที่เพิ่มไป ทำให้ของเก่าพังหรือป่าว ต้องถึงมือ QA ก่อนถึงจะรู้!
• เมื่อถึงมือ QA แล้วกลับมาแก้ก็ไม่รู้ไปพังส่วนไหนอีก
• ตอนทำงานพร้อมกันหลายๆ ส่วนแล้วเอามารวมกัน ไม่สามารถรู้ได้ว่าทำให้โค้ดคนอื่นพังป่าว
• เวลา Merge version ใหญ่ๆ ไม่สามารถบอกได้เลยว่าทุกอย่างยังทำงานถูกต้อง
• Code แต่ละคนแม้ส่วนใหญ่จะใช้รูปแบบเหมือนกัน แต่เวลามีน้องใหม่เข้ามาทำงาน ไม่มีการบอกกล่าวก็เจอรูปแบบประหลาดไปเต็มๆ
• เนื่องจาก แก้แล้วแก้อีก เพราะแก้เสร็จก็ทำให้เกิดปัญหาอีกอย่าง ทำให้งานไม่เสร็จซักที

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

• Lead, Architect: เป็นคนที่ออกแบบระบบตาม Requirement ทุกอย่าง
• Customer: จะบอกว่าเป็นลูกค้าก็ไม่ถูกจริงๆ คือคนให้ Requirement นั่นแหละ
• QA: เป็นคนที่ทดสอบระบบว่า ทำตาม Requirement ได้ถูกต้องหรือป่าว มีอะไรที่ขาดไปบ้าง
• Developer: ก็คนเสกระบบขึ้นมานั่นแหละ

ที่ต้อง define role ไว้ก่อนเพราะ เพราะจะได้รู้ว่าใครทำอะไรได้บ้าง โดยเฉพาะ QA ที่ตอนนี้เริ่มถูกคุกคามจากการเขียนโปรแกรม จากผลของ Selenium แต่จะให้ Developer คอย maintain ให้ QA ก็อาจตายได้ ช่วงนี้เลยพยายาม balance งานส่วนนี้อยู่ด้วยไม่ให้ทั้ง QA และ Developer ตาย

มาถึง Process ที่ตอนนี้พยายามทำเพื่อแก้ให้ปัญหาด้านบนๆ มันหมดไป

1. เริ่มจากไปเจรจาเรื่อง Requirement ก่อนเลย ตัดเป็นส่วนๆ และช่วงว่าจะทำอะไรก่อนหลัง กำหนดเวลาตายตัวว่า ช่วงเวลานี้จะมีอะไรให้เล่นบ้าง
2. แปลง Requirement เป็น Component และ Input/Output ต่างๆ แบบละเอียดที่สุดเท่าที่จะทำได้ เพื่อเอาไปคุยกับ Developer และ Architect
3. เนื่องจากเข้ามากลางทางแล้ว มีบาง Component ที่ทำไปแล้ว (และมี Test แค่อันเดียว! แอบสิ้นหวังตอนนั้น) Architect design ส่วนประกอบต่างๆ ไปแล้วรวมทั้ง flow อย่างยิ่งใหญ่มา ตอนเข้ามาเลยไล่ flow ทั้งหมดแล้วตัด requirement ส่วนต่างๆ ทิ้งพร้อมกำหนดเวลา
4. หลังจากได้ flow มาตอนนี้ก็ไปประกบกับ Developer เลยเป็น flow ย่อยเริ่มจาก
   1. เอา Flow ของ Case ต่างๆ ให้ Dev เขียน Component แล้วดูว่า Process เดิมและ code ของน้องหน้าตาเป็นอย่างไรบ้าง
   2. Review code ที่ได้มา นั่งประกบ แก้ไข แยกเป็นส่วนๆ เขียน Test ให้ดู แล้วให้แก้ส่วนที่เหลือ
   3. แก้เสร็จ Review code ซ้ำ ทำเหมือนข้อสองเป๊ะ จนดูดี ก็ย้ายไป component ถัดไป จากนั้นเข้า loop เดิม
   4. ทำจนครบทุก Component code ดูสวยงามก็ลดเวลานั่งประกบลง ยังคง review code เหมือนเดิม
   5. ทำเสร็จแต่ละวันก็ Merge รวมกัน รัน test ดูว่าอะไรพังจากนั้นก็แก้ให้ครบ เตรียมย้ายไป Requirement ถัดไป

Process นี้ลองทำมาสองหรือสามสัปดาห์ ผลลัพธ์ที่ได้ตอนนี้ก็ถือว่าน่าพอใจนะ และก็ได้เรียนรู้อะไรหลายอย่างไปพร้อมกันด้วย เช่นการที่เรารู้อะไรพวกนี้ (TDD, Design Pattern, …) ใช่ว่าจะคุยกันอย่างเดียวแล้วจบ เพราะมันกระตุ้นได้แค่บางคนเท่านั้น อย่างน้องที่เข้ามาใหม่จะให้เข้าใจต้องนั่ง Pair เขียน Code แยกให้ดูเลยว่า การทำเป็น Pattern นี้มันดียังไง Test ง่ายผลมันดียังไง หรือบางอย่างที่น้องรู้มากกว่า ก็จะได้รู้ไปด้วยเลย (จริงๆ เป็นความฝันส่วนตัวว่าอยากได้คนมา Pair คู่ Review code ตัวเองบ้าง คอยอธิบายบ้างว่าทำอย่างนี้ดีอย่างไร Component นี้ทำงานยังไง ต้องการอะไรจาก Requirement นี้) ตอนนี้งานส่วนใหญ่ก็เลยเป็นพวก ต่อรอง Requirement, จัด scope, กดดันให้เสร็จ รวมทั้งเขียนเองด้วย, pull code มา review, บ่นๆ, mergeๆ, จัดตารางเวลาตาม progress ของแต่ละวัน ทำเสร็จก็หมดวันแล้ว จริงๆ มีพวกปัญหาจาก Project ปัจจุบันที่ต้องคอยแว๊บไปดูเป็นช่วงเวลาด้วย แต่ช่วงนี้เร่ง Process นี้ให้ชินก่อน ถ้า Team นี้ทำจนชินและสำเร็จ ก็คงย้ายไปดู Team อื่นเรื่อยๆ แล้วพยายามชักชวนดู ถ้าผลลัพธ์เป็นอย่างที่คิดจริง ปัญหาทั้งหมดด้านบนในย่อหน้าแรกควรจะหมดไป (หวังว่านะ) และจะได้มีเวลามีคนไปแก้ปัญหาจริงๆ เสียที