ขั้นตอนการทำงานของ Software Developer หลัง Project Manager มอบหมายงาน

เคยสงสัยกันบ้างไหมครับว่าเวลา Software Developer ได้รับมอบหมายงานจาก Project Manager (หรือ Team Leader แล้วแต่โครงสร้างของแต่ละทีม) เขาต้องมีขั้นตอนการทำงานอย่างไรบ้าง มีลำดับอย่างไรที่จะทำให้งานสำเร็จได้ตาม Requirement ที่ได้รับมอบหมายมา ฉะนั้นในบทความนี้ก็อยากจะมาขอแชร์ข้อมูลเบื้องต้นเกี่ยวกับขั้นตอนการทำงานของ Software Developer หลัง Project Manager มอบหมายงาน เพื่อเป็นแนวทางให้ Software Developer มือใหม่หรือมือเก๋าเอาไปเป็นข้อมูลกันก็ได้ครับ

อธิบายเพิ่มเติมเกี่ยวกับบทความ

ก่อนเริ่มต้นอยากขออธิบายเพิ่มเติมเกี่ยวกับบทความนี้ก่อนสักเล็กน้อยครับ

• เราจะอธิบายในมุมมองของบทบาทการทำงานใน Coding Level (การทำงานในระดับการเขียนโค้ดโปรแกรม) เมื่อ Software Developer ได้รับงานจาก Project Manager ในแต่ละวัน ซึ่งบทบาทความรับผิดชอบงานของแต่ละทีมอาจแตกต่างกันไปครับ

• บทบาทในบทความนี้คือ Project Manager ในฐานะผู้มอบหมายงานและ Software Developer ในฐานะคนทำงาน ซึ่งแต่ละทีมอาจจะมีบทบาทอื่น ๆ ที่แตกต่างกันไปครับ

• ในที่นี้ตัวคำอธิบายงานที่ได้รับมอบหมายเราขอเรียกว่า Ticket ซึ่งอาจถูกเรียกว่า Task หรือ Card แล้วแต่ Project Management Tool (เครื่องมือตัวช่วยจัดการงาน) ที่แต่ละทีมหรือองค์กรเลือกใช้

• เราขอแบ่งขั้นตอนการทำงานเป็น 3 ช่วงตามหัวข้อหลักแต่ละข้อหลังจากนี้ประกอบด้วย ก่อน Coding, ระหว่าง Coding และหลัง Coding

• เราขอเลือกใช้ Git เป็น Version Control System ควบคู่กับ GitHub

ก่อน Coding

รับมอบหมาย Ticket จาก Project Manager

หลังจาก Software Developer ได้รับ Ticket จาก Project Manager ที่มอบหมายงานมาแล้ว คำอธิบายใน Ticket จะอธิบายถึง Requirement ที่ต้องการ ซึ่งความละเอียดของคำอธิบายใน Ticket อาจแตกต่างกันไปในแต่ละทีม ซึ่งโดยทั่วไปขั้นต่ำควรจะประกอบด้วย ให้ทำอะไร ให้ใครทำ และให้เวลาเบื้องต้นเท่าไร ซึ่งหากว่ามีข้อมูลน้อยไปกว่านี้ Software Developer ควรทักท้วงขอข้อมูลจาก Project Manager ให้ครบถ้วนตั้งแต่ต้น

ประเภทของ Ticket 

• Bug

• Tester

• Feature

• Blind API

ประเมินลำดับขั้นตอนการทำงานเบื้องต้น

เมื่อ Software Developer ได้รับข้อมูลที่ครบถ้วนจากใน Ticket แล้ว ก็ต้องมาเริ่มแยกประเภทก่อน ซึ่งการแบ่งแยกประเภทของ Ticket โดยทั่วไปเราจะอ้างอิงตาม Git Flow โดยขึ้นอยู่กับว่าในแต่ละทีมจะนำมาปรับใช้เพิ่มเติมอย่างไร ซึ่งต้องเป็นไปตามการตกลงกันระหว่างทีม Software Developer และต้องสามารถสื่อให้ Project Manager เข้าใจได้ด้วย ณ ที่นี้ขอแบ่งเป็น 3 ประเภท

• Feature: เป็นการสร้างหรือเปิดใช้งาน Feature ใหม่

• Enhance: เป็นการแก้ไข Feature ที่มีอยู่เดิม แต่เพิ่มเติมให้ดีหรือสมบูรณ์ยิ่งขึ้น

• Fix: เป็นการแก้ไขข้อผิดพลาดของ Feature

ซึ่ง Software Developer ต้องวิเคราะห์ลำดับขั้นตอนการทำงานเชิง Coding Level ออกมาให้เป็นลำดับและต้องอธิบายขั้นตอนให้ Project Manager เข้าใจได้โดยไม่ใช้ Technical Language ด้วย

รวมถึงประเมินเวลาการทำงานว่าต้องใช้เวลาเท่าไรให้เหมาะสม

แจ้งขั้นตอนการทำงานกับ Project Manager

หลังจาก Software Developer ทำการประเมินขั้นตอนการทำงานเชิง Coding Level เรียบร้อยรวมทั้งประเมินเวลาที่ใช้แล้ว ต้องแจ้งกับ Project Manager ให้เข้าใจ และต่อรองเวลาที่ใช้ทำงานให้เรียบร้อย ซึ่งหาก Project Manager มีเวลาที่ให้ไม่เท่ากับเวลาที่ Software Developer ประเมินเอาไว้ ก็อาจต้องมีการเร่งงาน หรือตัดขั้นตอนการทำงานในบางส่วนออกไปครับ รวมถึงหาก Feature ในส่วนที่จะทำมีความเกี่ยวข้องกับส่วนอื่น ๆ ใน Project ของเราซึ่งเมื่อแก้ไขเพิ่มเติมอาจมีผลกระทบเกิดขึ้น ก็มีความจำเป็นต้องแจ้งกับ Software Developer คนอื่น ๆ ที่ดูแลส่วนนั้น ๆ ให้รับทราบถึงการแก้ไขและผลกระทบที่อาจจะเกิดขึ้นไว้ด้วยครับ

ระหว่าง Coding

เลือก Environment ที่เราจะใช้

ในการทำงานโดยทั่วไปเราจะมีการแบ่ง Environment ในการทำงานออกเป็นหลายระดับ ซึ่งมีการ Config ค่าต่าง ๆ ที่ใช้ประกอบในการทำงานแตกต่างกันไปตาม Software Testing Process เพื่อให้มีการทดสอบการทำงานไปทีละขั้นเพื่อป้องกันปัญหาที่อาจจะเกิดขึ้น ณ ที่นี้ เราแบ่งออกเป็น 3 ระดับ

• Staging (STG) Environment: พื้นที่ทำงานของ Software Developer และทดสอบภายใน

• User Acceptance Test (UAT) Environment: ทดสอบการใช้งานซอฟต์แวร์โดยผู้ใช้งานจริง

• Production (PROD) Environment: ตัวงานจริง

ซึ่งโดยทั่วไปงานของ Software Developer ก็ทำงานใน Develop Environment หรือ STG ยกเว้นแต่ว่าเป็น Ticket แบบเร่งด่วนที่เราจำเป็นต้อง Hotfix โดยตรงเข้าไปที่ UAT หรือ PROD โดยตรงแล้วค่อย Merge เข้ากับ STG ภายหลังซึ่งส่งผลกับ Environment และ Config ต่าง ๆ ที่เราเลือกใช้ รวมถึงข้อมูลใน Database ที่เราจะใช้ประกอบการทำงานด้วยครับ ซึ่ง Software Developer ต้องมีความระมัดระวังอย่างมากในการที่จะเลือกใช้ Environment แต่ละแบบในการทำงานโดยเฉพาะ PROD ต้องแจ้งให้ชัดเจนกับ Project Manager และ Software Developer คนอื่น ๆ ให้เรียบร้อย

จัดการกับ Git Branch

ในส่วนนี้ Software Developer สามารถเลือกใช้เครื่องมือตามที่ถนัดในการ  Run Command ได้เลย โดยเราจะขอข้ามขั้นตอนในส่วนของการใช้งาน Command Line หรือ Git ไปเลยนะครับ

1. ทำการเริ่มงานด้วยการเข้ามาที่ Branch ที่เราจะทำงานโดยอิงตาม Environment ที่เราเลือกใช้ ณ ที่นี้คือ Develop Branch

`` git checkout <branchName> ``

`` git checkout develop ``

2. ทำการอัปเดต Code ปัจจุบันจาก Remote Branch มาที่ Local Branch

`` git pull --rebase ``

3. ทำการแยก Local Branch ออกมาเพื่อใช้เป็น Branch ในการทำงาน

`` git checkout -b <branchName> ``

`` git checkout -b feat/create-user ``

เริ่มลงมือทำงาน

เริ่มลงมือทำงานโดยที่ Software Developer แต่ละคนอาจมีลักษณะวิธีการทำงานและวิธีการ Coding ที่แตกต่างกันไป ซึ่งอาจทำให้เกิดปัญหาขึ้นบ้างในการทำงานรูปแบบทีม ซึ่งสามารถแก้ไข้ด้วยการวาง Tech Standard และ Coding Standard ให้ชัดเจนไปในแนวทางที่ใกล้เคียงกัน และทำให้งานให้สำเร็จตาม Focus Case ที่เราตั้งในแก้ปัญหาตาม Requirement ใน Ticket ที่ Project Manager มอบหมายมา

ทดสอบการทำงาน

นอกจากการทดสอบการทำงานใน Focus Case ที่เราสนใจแล้ว Software Developer ต้องมีการป้องกันปัญหาที่จะเกิดขึ้นด้วยการทำ Testing เพื่อทดสอบการทำงานของ Software ให้ครบถ้วนสมบูรณ์ ซึ่งในส่วนของการ Testing ในระดับของที่ Software Developer จะทำด้วยตัวเอง อาจมีความครอบคลุมมากหรือน้อยขึ้นอยู่กับการตกลงกันในแต่ละทีมตามที่ตกลงกันไว้ตาม Tech Standard ซึ่งอาจอิงตามหลักการ Test Driven Development (TDD) การ Testing หากมากไปก็อาจทำให้ Project Manager ต้องปวดหัวขึ้นเพราะเวลาในการทำงานแต่ละ Ticket ก็จะมากขึ้นตาม แต่ถ้ายิ่ง Testing ละเอียดมากแค่ไหน ก็จะป้องกันปัญหาได้มากเท่านั้น

ตรวจสอบและแก้ไข

เมื่อทำการแก้ไข เรียบร้อยแล้วให้ทำการ อัพ Code ในส่วนที่แก้ไขขึ้น โดยขั้นตอนการอัปเดตโค้ดมีดังนี้

1. Add Tracking changes files และ Commit

`` git add . ``

`` git commit -m <commitMessage>``

`` git commit -m "feat(users): Create feature create user" ``

2. กลับเข้ามาที่ Develop Branch

`` git checkout develop ``

3. ทำการอัพเดท Code ปัจจุบันจาก Remote Branch มาที่ Local Branch

`` git pull --rebase ``

4. กลับเข้าไปที่ Working Local Branch

`` git checkout -b feat/create-user ``

5. Merge Code จาก Develop Branch เข้ากับ Working Local Branch และแก้ไข Conflict

`` git merge develop ``

หลัง Coding

สร้าง Pull Request

1. Push Code เข้าไปที่ Remote Repository

`` git push -u origin <branchName> ``

`` git push -u origin feat/create-user ``

2. สร้าง Pull Request โดยใส่คำอธิบายให้เรียบร้อยตามที่ตกลงกันในแต่ละทีม และร้องขอการ Review การแก้ไข Code จาก Team Leader หรือ Software Developer ด้วยกันเอง และอาจให้ Project Manager เข้ามาตรวจดูคำอธิบายว่าตรงตาม Ticket หรือไม่ ตามแต่การตกลงกันของแต่ละทีม

• • ไปที่ GitHub ของเรา

  • คลิกที่โปรไฟล์ เลือก Your Repository หรือหากเป็นองค์กร ให้เลือก Your Organizations แล้วไปเลือก Repository ของ Project 

  • คลิกที่ Tab Pull Request

  • คลิกที่ New Pull request

  • เลือกสร้าง Pull Request จาก Working Branch (feat/create-user) เข้าไปที่ Environment Branch ที่เราดูแลทำตาม Ticket (develop)

  • ตรวจสอบรายละเอียดการแก้ไข หรือเพิ่มเติม Code

  • ใส่ชื่อ Pull Request และคำอธิบายให้เรียบร้อยตาม Tech Standard ที่ตกลงกันไว้ในแต่ละทีม โดยต้องให้ Project Manager และ Software Developer คนอื่น ๆ สามารถอ่านได้และเข้าใจว่ามีการทำอะไรไป

  • เพิ่มชื่อของ Reviewer เข้าไปอาจเป็น Team Leader, Project Manager หรือ Software Developer ด้วยกันเองตามที่แต่ละทีมตกลงกัน

  • คลิกที่ Create Pull request

  • ทำการแชร์ลิงก์ของ Pull Request ให้ Reviewer เข้ามาตรวจสอบ

3. หากมี Comment จุดที่ต้องแก้ไขเพิ่มเข้ามา ให้ Software Developer ทำการแก้ไขจาก Local Branch และทำซ้ำตามขั้นตอนในข้อ 1 อีกครั้ง

4. เมื่อมีการ Approved ให้การแก้ไขผ่านก็ทำการ Merge เข้าไปและอย่าลืมลบ Working Branch ที่ใช้งานเสร็จแล้วออกเพื่อความเรียบร้อย ลดความสับสนระหว่าง Software Developer ด้วยกันเอง

• • ไปที่ Pull Request ของเรา

  • คลิกที่ Merge Pull Request หรือ Squash and Merge กรณีรวมหลาย Commit

  • ตรวจสอบ Commit Message อีกครั้งหากเป็นการ Commit Squash and Merge

  • คลิกที่ Delete Branch

5. เมื่อทำการ Merge แล้วอาจมีการทำตาม CI/CD ตามที่ตั้งค่าไว้ในแต่ละ Project จน Deploy สำเร็จ

แจ้งผลการทำงานให้กับ Project Manager และ Software Developer Team

1. เมื่อทำการ Deploy สำเร็จแล้ว Software Developer ให้ทำการแจ้งกับ Project Manager ให้รับทราบให้เรียบร้อยว่ามีการแก้ไขและนำขึ้นสู่ Environment นั้น ๆ ตามแต่ละ Ticket เรียบร้อยแล้ว

2. หาก Ticket ของเราเป็นการแก้ไข หรือทำงานในส่วนใด ๆ ที่มีความเกี่ยวข้องกับงานที่ Software Developer คนอื่น ๆ รับผิดชอบดูแลอยู่ Software Developer อย่างเรา ๆ ต้องมีการแจ้งการแก้ไขและผลกระทบที่จะเกิดขึ้นให้รับทราบด้วย อาทิเช่น ทางด้าน Backend Software Developer มีการแก้ไข Response Object ของ Api ต้องทำการแจ้ง Frontend Software Developer ให้มีการปรับการ Response จาก Api นั้น ๆ ตามด้วย เป็นต้น

ก่อนจากกันไป หวังว่าข้อมูลขั้นตอนการทำงานของ Software Developer หลัง Project Manager มอบหมายงาน ในบทความนี้จะเป็นประโยชน์กับผู้ที่แวะเวียนเข้ามาอ่าน หากว่ามีข้อมูลที่ผิดพลาดไปประการใด ขออภัยมา ณ ที่นี้ด้วยครับ ขอบคุณครับ

แหล่งอ้างอิง

• Version Control System คืออะไร?

• Git คืออะไร?

• GitHub คืออะไร?

• Project Management Tool เครื่องมือตัวช่วยจัดการงาน คืออะไร?

• Git flow คืออะไร?

• Pull Request คืออะไร?

• Test Driven Development คืออะไร?

• Unit Testing คืออะไร?

• Functional Testing คืออะไร?

• API คืออะไร?

• CI/CD คืออะไร?