[Knowledge] Using DevOps’s board
ใน DevOps มี board สำหรับการวางแผนการทำงานในทีม และสามารถแบ่งการวางแผนต่างๆ ในแต่ละทีมได้อีกด้วย
ในบทความนี้จะพาไปเรียนรู้การใช้งาน Board โดยแบ่งเป็น 6 ข้อหลักๆ ดังนี้
- Boards
- Lanes
- Flows
- Demo
- Issues
- DOD vs Acceptance Criteria
Boards
สำหรับการวางแผนงานต่างๆ สิ่งที่จะช่วยคือ Board ที่สามารถจัดแจงการแบ่งงานต่างๆ ได้ โดยการค่อยๆ ย่อยงานให้เล็กลงไปจนเหมาะสม แล้วนำไปวางไว้ใน Board นั้นคือการใช้งาน Board
Board จะสามารถแบ่งตัวมันเองให้สำหรับแต่ละทีมได้ด้วย ซึ่งเราจะแบ่งเป็น 2 Boards ได้แก่
- External board — สำหรับติดต่อกับคนนอก เช่น ทีมภายในต้องการความช่วยเหลือจากทีมภายนอก หรือทีมภายนอกต้องการให้ทีมภายในทำอะไรบางอย่าง
- Internal board — สำหรับทีมภายในคุยกันเอง
วิธีการเข้าไปที่ Boards ของทีมต่างๆ สามารถเข้าไปได้โดยวิธีการดังนี้
- เมื่อเข้ามาที่ Project ให้เลือกเมนูจากซ้ายมือ “Boards”(1) แล้วเลือก “Boards”(2) อีกที ดังรูป (image 1)
2. เลือก Dropdown(1) เพื่อดูทีมทั้งหมด และเลือก board(2) เพื่อเปลี่ยน Board ที่ต้องการทำงานด้วย ดังรูป (image 2)
ในรูป Extern คือ External board และ Proposal Team คือ Internal board
Lanes
เมื่อเข้าใช้งาน Board เราจำเป็นจะต้องมีการแบ่งงาน ซึ่งเราจะเรียกตัวงานว่า work item และมีการแบ่งสถานะงานต่างๆ เช่น งานยังไม่เสร็จ งานเสร็จแล้วแต่รอตรวจสอบ เป็นต้น
ดังนั้น Lanes จะเข้ามาช่วยเรื่องสถานะงานเหล่านี้ เพื่อให้ทีมรับรู้สถานะของ work item ต่างๆ ในทีมได้ โดยจะแบ่งไว้ 6 Lanes ดังนี้
- New — work item ใหม่ๆ ที่ถูกเพิ่มขึ้นมาจะถูกนำมากองไว้ที่ Lane นี้ โดยระบบจะจัดการนำ work item ที่เพิ่มมาใหม่ใส่ไว้ที่นี่อัตโนมัติ
- Ready — เมื่อ work item มีการอัพเดท จนทีมสามารถทำงานได้ เช่น พูดคุยเพื่อเคลียร์ความชัดเจนของ work item เรียบร้อย, ต้องการ design จาก garphic ฯลฯ เป็นต้น แต่ยังไม่มีคนมารับผิดชอบงานตัวนี้ ทีมจะย้าย work item มาที่ Lane นี้
- Active —เมื่อมีคนที่จะรับผิดชอบ/ทำงาน กับ work item ตัวนั้นๆแล้ว คนที่รับผิดชอบ จะย้าย work item มาที่ Lane นี้ เพื่อบอกถึงสถานะว่า work item ตัวนี้มีคนกำลังดำเนินการทำให้ work item เสร็จอยู่
- Review —หลังจากที่ทำ work item จนเสร็จ และต้องการให้มีการตรวจสอบโดยจะเป็นคนนอกทีม หรือคนในทีมกันเอง คนรับผิดชอบจะย้ายมาที่ Lane นี้ เพื่อรอคนมาตรวจสอบ
- Resolved — หลังจากตรวจสอบเสร็จ และไม่มีการแก้ไข work item คนที่ตรวจสอบจะย้ายมาที่ Lane นี้ เพื่อบ่งบอกว่าตรวจสอบเรียบร้อย สามารถปิด work item ที่ตรวจได้
- Closed — เมื่อเสร็จสิ้นการตรวจสอบแล้ว คนที่รับผิดชอบงานจะย้าย มาที่ Lane นี้ เพื่อบอกกับทีมว่า work item ตัวนี้เสร็จแล้ว
โดยสรุป คือ ตั้งแต่ต้นกระบวนการทีมจะสร้าง work item ใหม่ (New lane) และนำไปพูดคุยเคลียร์ความชัดเจนของตัวเอง จนเสร็จสิ้น(Ready lane) และมีคนรับผิดชอบนำ work item ไปทำ (Active lane) จนทำงานจนเสร็จ และนำไปตรวจสอบความถูกต้อง (Review lane) เมื่อตรวจสอบแล้วผ่าน (Reslove lane) คนที่รับผิดชอบ work item จะบอกกับทีมว่าเสร็จแล้ว (Close lane) ดังรูป (image 3)
Flows
วิธีดำเนินงานใน board คือ จะมีคนสร้างเคส (Issue) เพื่อแจ้งให้ทีมทราบว่าพบปัญหา หรือต้องการให้ทีมทำอะไรสักอย่าง เช่น ต้องการให้แก้ไข Document, แจ้ง bug หรือข้อเสนอแนะ เป็นต้น
แล้วเมื่อทีมสะดวกที่จะรับ Issue ไปทำ ทีมจะสร้าง work item เพื่อย่อยงานออกหลายๆ ชิ้น เพื่อที่จะดำเนินการอย่างไร Issue ที่รับมาถึงจะเสร็จ เมื่อ work item ที่ย่อยออกมาปิดหมดทุกตัว จะถือได้ว่า Issue ที่รับมานั้นเสร็จ ดังรูป (image 4)
ทีมรับ Issue ไปจัดการ
หลังจากที่มีการแจ้ง Issue เรียบร้อยแล้ว เมื่อทีมต้องการจะจัดการกับ Issue ดังกล่าว จะมีการพูดคุย เพื่อเคลียร์ความเข้าใจ/รายละเอียดกับคนที่แจ้งเข้ามา
หลังจากที่ทีมพูดคุยเพื่อเคลียร์ความเข้าใจกับคนแจ้งเรียบร้อยแล้ว ทีมจะสามารถแบ่งงานออกมาได้ 2 ประเภท ได้แก่
- Issue ที่ไม่เกี่ยวข้องกับ Code — จะเป็นการแจ้งปัญหาที่ไม่มีการแก้ source code เช่น Document ไม่อัพเดท, ข้อเสนอแนะ เป็นต้น
- Issue ที่เกี่ยวข้องกับ Code — จะเป็นการแจ้งปัญหาโดยที่ทีมอาจจะต้องมาแก้ไข source code เช่น พบ bug, ต้องการให้มี feature ใหม่, Test เป็นต้น
การสร้าง Issue
- เลือก work items จาก sidemenu แล้วเลือก “New Work Item” และเลือก “Issue” เพื่อระบุว่าจะสร้าง work item ที่เป็น Issue ดังรูป (image 5)
2. กรอกรายละเอียด หัวข้อ(1) รายละเอียดที่ต้องการให้ทำ(2) เมื่อกรอกเรียบร้อยให้กด save (3) ดังรูป (image 6)
3. เมื่อสร้าง issue สำเร็จ จะได้ดังรูป (image 7)
การสร้าง Work Item จาก Issue
- แบ่งงานจาก issue โดยในหน้ารายละเอียดของ issue ให้เลือก “…” แล้วเลือก “Create copy of work item” ดังรูป (image 8)
2. เลือก work item type เป็น Feature หรือ User Story ซึ่งขึ้นอยู่กับการคุยภายในทีมแล้วว่าจะระบุชนิดงานนี้ว่าเป็นระดับใด (ตัวอย่างจะสร้างเป็น User story) ดังรูป (image 9)
อย่าลืมเลือก “Include existing links” เพื่อให้ work item มี relate กับ Issue ที่กำลังเลือกอยู่ (ถ้า Issue มีรูป ให้เลือก “Include existing attachments” ด้วย)
3. ในขั้นตอนนี้ ระบบกำลังจะสร้าง work item โดยมีข้อมูลคัดลอกมาจาก Issue ครบถ้วนแล้ว แต่สามารถเปลี่ยนแปลงได้ขึ้นอยู่กับผู้สร้าง ในส่วน Related Work จะเห็นว่ามี relation กับ Issue ก่อนหน้านี้ ดังรูป (image 10)
4. เมื่อสร้างสำเร็จ จะมีรายการ work item ใหม่ ดังรูป (image 11)
จากตัวอย่าง “การสร้าง Issue” และ “การสร้าง Work Item จาก Item” จะถูกนำมาเป็นเคสตัวอย่าง ในการดำเนิน flow หลายๆ แบบ
ดำเนิน Flow โดย Issue ไม่เกี่ยวข้องกับ Code
- แบบที่ 1 — ดำเนินการสำเร็จ
จากรูป (image 12) จะเห็นการทำงานตามแต่ละ lanes ดังนี้
- work item ใหม่ที่ถูกเพิ่มเข้ามาจะอยู่ที่ New lane (สร้าง work item (task) เพื่อแบ่งขั้นตอนว่าต้องทำอะไรบ้าง work item (user story) นี้จึงจะถือว่าเสร็จ
- หลังจากที่พูดคุย/เคลียร์ความชัดเจน จนสามารถพร้อมนำไปทำงานต่อได้ ทีมจะย้ายมาที่ Ready lane
- เมื่อมีคนต้องการทำ work item ดังกล่าว คนรับผิดชอบจะย้ายมาที่ Active lane และดำเนินงานต่อจนเสร็จ (ทำ work item ภายในนั้นให้เสร็จทั้งหมด)
- หลังจากที่ทำงานจนเสร็จ (Task สำเร็จครบทุกตัว) จะเลื่อนไปที่ Review lane เพื่อให้คนมาตรวจสอบ
- หลังตรวจสอบผ่านเรียบร้อย จะเลื่อนมาที่ Resolved lane
- ผู้รับผิดชอบงาน จะเลื่อนมาที่ Close lane เพื่อบอกว่างานถือว่าสำเร็จเรียบร้อย
- แบบที่ 2 — Review แล้วไม่ผ่านต้องกลับมาแก้ไขให้เรียบร้อยถึงจะปิดงานได้
จากรูป (image 13) จะมีการดำเนินงานเหมือนเคสก่อนหน้านี้ แต่คราวนี้ Review ตรวจสอบแล้วไม่ให้ผ่านต้องนำกลับไปแก้ไขให้เรียบร้อย จึงจะเสร็จงาน ดังนี้
- Review ไม่ให้ผ่าน ผู้รับผิดชอบงานจะเลื่อนกลับมาที่ Active lane แล้วแก้ไขงาน (อาจจะเพิ่ม work item แก้ไขงานจาก review) ให้เรียบร้อย
- เมื่อแก้ไขตามที่ผู้ตรวจบอกเรียบร้อยแล้ว จะเลื่อนมาที่ Review lane อีกรอบ เพื่อตรวจสอบใหม่อีกครั้ง หากถ้าไม่ผ่าน ก็ต้องกลับไปแก้ไขอีกครั้ง จะวนระหว่าง ข้อ 1 และ 2 แบบนี้ไปเรื่อยๆ จนกว่าจะตรวจสอบผ่าน
- หลังจากที่ตรวจสอบผ่านเสร็จแล้ว จะเลื่อนมาที่ Resolve lane ตามปกติ แล้วดำเนินการตาม flow ปกติต่อได้เลย
เมื่อดำเนิน flow จนจบกระบวนการ (work item เสร็จหมดทุกตัว) ทั้งแบบที่ 1 และแบบที่ 2 ให้ผู้รับผิดชอบงานกลับไปแจ้ง issue ด้วยว่างานเสร็จสิ้นแล้ว และให้ปิด issue ตัวดังกล่าว (เปลี่ยน state เป็น “Closed”) ดังรูป (image 14)
ดำเนิน Flow โดย Issue เกี่ยวข้องกับ Code
สำหรับการทำงานที่มีความเกี่ยวข้องกับ source code จะมีขั้นตอนเพิ่มเติมเข้ามา คือ การ Fork repo และ Pull-request ดังรูป (image 15) ซึ่งรายละเอียดมี ดังนี้
- Fork repo — สร้าง repo ส่วนตัวขึ้นมาใหม่ โดย clone ของทั้งหมดจาก repo หลัก เพื่อป้องกันไม่ให้ผู้รับผิดชอบงานสามารถแก้ไข repo หลักโดยตรงได้
- Pull-request — หลังจากที่แก้ไข/เปลี่ยนแปลง source code จาก repo ส่วนตัวเสร็จเรียบร้อย จะมีการ pull-request เพื่ออัพเดทสิ่งที่แก้ไขรวมกับ repo หลัก ซึ่งในส่วนนี้จะมีการตรวจสอบ (Code Review) และเมื่อผ่านแล้ว ระบบจะรวม source code เข้ามาที่ repo หลักให้อัตโนมัต
Fork repo
- เลือก “Repos” (1) เลือก repo ที่ต้องการ fork (2) ต่อมาเลือก “…” (3) แล้วเลือก “Fork” (4) ดังรูป (image 16)
2. ตั้งชื่อ repo ที่จะสร้างขึ้นมาใหม่ (1) ต่อมาเลือก fork ไปยัง project ใด (2) และเลือก “All branches” (3) แล้วเลือก “Fork” (4) ดังรูป (image 17)
3. เมื่อ fork สำเร็จ โดยจะมีข้อสังเกต คือ ชื่อ repo(1) และที่อยู่ของ project (2) จะมีการเปลี่ยนแปลง ดังรูป (image 18) ซึ่งต่างจากรายละเอียดของ repo ตั้งต้น (image 16)
Pull-request
- เลือก “Pull-requests” (1) แล้วเลือก “New pull-request” (2) ดังรูป (image 17)
ในกรณีที่มีการ push งานขึ้นใน branch ต่างๆ ระบบจะแสดงให้เห็นว่ามี update อันใหม่เข้ามา แล้วสามารถกด “Create a pull-request” (3) จากตรงนี้ได้เลย
2. ตรวจสอบความถูกต้องของ fork repo เพื่อที่จะนำเข้า repo หลัก (1) ต่อมาใส่หัวข้อ (2) และรายละเอียด(3) ในการ pull-request ครั้งนี้ เมื่อเสร็จแล้วให้เลือก work item ที่เกี่ยวข้อง (4) แล้วกด “Create” (5) ดังรูป (image 18)
ความถูกต้อง (1) ในตัวอย่าง
fork repo — ชื่อProposal.demo.fork และ branch ที่จะนำไปอัพเดท ชื่อ demo
Repo หลัก — ชื่อ Proposal และ branch ที่จะถูกอัพเดท ชื่อ main
3. เมื่อสร้าง pull-reuqest สำเร็จ จะได้ตาหน้าดังรูป (image 19) ในส่วนของ Discussion (1) จะเป็นการพูดคุยระหว่างคนที่สร้าง pull-request นี้ และคนที่มาตรวจสอบ (Reviewer) เพื่อที่จะพูดคุยทำความเข้าใจของงานกัน และบางกรณีที่ไม่ให้ผ่าน Reviewer จะใส่เหตุผล และ comment code ลงมาในส่วนของ discussion ได้ด้วย
สำหรับการทำงานกับ Issue ที่เกี่ยวข้องกับ code จะแตกต่างจากเดิมเล็กน้อย แต่พื้นฐานใช้ board และ flow แบบเดียวกัน ดังตัวอย่าง
- แบบที่ 1 — ดำเนินการสำเร็จ
จากรูป (image 20) จะเห็นว่าดำเนินจะเหมือนเดิมกับที่ผ่านมา แต่จะแตกต่างจากเดิมเล็กน้อย ได้แก่
- เพิ่มการ Fork repo ส่วนตัวออกมา เพื่อให้ไม่กระทบกับ repo หลัก
- หลังจากที่ดำเนินการมาเรื่อยๆ จนปิด work item ครบแล้ว จะต้องทำ pull-request ก่อนเสมอ แล้วค่อยเลื่อนไป Review lane เพื่อที่จะให้คนมาตรวจสอบ source code
- หลังจากที่ผู้ตรวจสอบให้ผ่านเรียบร้อย ระบบจะรวม source code เข้ามาด้วยกัน และ work item จะถูกเลื่อนไปยัง Closed lane โดยอัตโนมัตด้วยตัวระบบเอง
- แบบที่ 2 — Review แล้วไม่ผ่านต้องกลับมาแก้ไขให้เรียบร้อยถึงจะปิดงานได้
จากรูป (image 21) ในกรณที่ pull-request แล้ว review ไม่ผ่าน ผู้รับผิดชอบงานจะต้องนำกลับไปแก้ไขใหม่ (1) แล้วนำไปให้ตรวจสอบใหม่ (2) เรื่อยๆ จนกว่าจะ review ผ่าน (3) จึงจะจบ flow การทำงาน เหมือนเคสข้างต้นที่เคยกล่าวมาทั้งหมด
ในส่วนนี้จะเพิ่มการใช้ Tag เข้ามาเพื่อเสริมการบอกสถานะงาน เช่น
- need:more-info — เป็นการบอกว่าต้องการข้อมูลเพิ่มเติมก่อน จึงจะเลื่อน work item จาก New lane ไปยัง Ready lane ได้
- Wait:Review — work item นี้กำลังรอ การตรวจสอบอยู่ (ให้ผู้ตรวจสอบรับทราบ)
- Wait:Owner — review เสร็จเรียบร้อยแล้ว แต่มีของที่ต้องนำกลับไปแก้ไข (ให้ผู้รับผิดชอบรับทราบ)
การใส่ Tag
ในแต่ละ work item สามารถมี tag ได้หลา่ยตัว ดังรูป (image 22) ซึ่งการใช้ tag จะขึ้นอยู่กับข้อตกลงของทีม ว่าจะใช้ keyword อะไรบ้าง และแต่ละตัวมีความหมายว่าอะไรบ้าง
- แบบที่ 3 — จำเป็นต้องให้คนอื่นมาช่วยงานบางส่วน จึงสามารถจบงานได้
จากรูป (image 23) เมื่อเราทำงานไปถึงระดับนึง แล้วพบว่าต้องมีการทำงานอีกอย่าง ซึ่งเราไม่สามารถทำได้ เช่น ไม่เคยทำ/ทำไม่เป็น หรือไม่มีเวลาทำในส่วนนั้น เป็นต้น เราจะวิธีการรับมือเหตุการณ์ดังกล่าว ได้แก่
- สร้าง work item ขึ้นมา เพื่อให้ติดตาม issue ที่เรากำลังจะสร้างใหม่ และสร้าง issue ใหม่ขึ้นมา โดยใส่ tag HelpNeeded เพื่อบอกว่าต้องการให้คนอื่นมาช่วยเหลือใน issue ตัวนี้ ส่วนคนอื่นก็จะมาติดต่อขอทำ issue ตาม flow ปกติที่เคยกล่าวมาข้างต้น
- เมื่อคนรับ issue ไปทำจนเสร็จ work item ที่เอาไว้ติดตามจะถือว่าเสร็จด้วย และเมื่อ work item ทุกตัวเสร็จ ค่อยทำ pull-request แล้วส่งไปให้ตรวจสอบ
- เมื่อตรวจสอบแล้วผ่าน จะถือว่าปิดงานตาม flow ปกติ
- แบบที่ 4 — จำเป็นต้องให้คนอื่นมาช่วยงานบางส่วน จึงสามารถจบงานได้ และเมื่อทำ pull-request ไปแล้ว Review ไม่ผ่านต้องกลับมาแก้ไขให้เรียบร้อยถึงจะปิดงานได้
ในกรณีนี้จะแบ่งออกเป็น 2 เคส ได้แก่
- จบได้ด้วยทีมเอง — ถ้าหากทีมสามารถแก้ไขตามสิ่งที่ผู้ตรวจสอบบอกได้ จะสามารถทำได้เหมือนในกรณีของ “ดำเนิน Flow โดย Issue เกี่ยวข้องกับ Code แบบที่ 2”
- ต้องให้คนอื่นมาช่วยแก้ — อาจเกิดขึ้นได้ เป็นผลต่อเนื่องจาก “ดำเนิน Flow โดย Issue เกี่ยวข้องกับ Code แบบที่ 3” ซึ่งเราไม่ได้เป็นคนทำงานนั้น จำเป็นต้องให้คนที่ทำ issue เข้ามาแก้ไข เราก็จะสร้าง issue ใหม่ เพื่อให้เขากลับมาแก้งานแล้วค่อย pull-request ใหม่อีกรอบ วนแบบนี้จนจบ flow
Demo
เมื่องานมีการอัพเดท เปลี่ยนแปลงแล้ว ทีมต้องการจะ demo ของที่ทำมา ทีมสามารถทำได้โดย
Management board — เป็น board กลางที่สำหรับ share resource ระหว่าง project ซึ่ง board นี้จะอยู่ภายใต้ share resource project ตามที่ทีมคุยกันไว้
- สร้าง issue ไว้ที่ Management board เพื่อเป็นการแจ้งทุกทีมว่าจะมีการ demo
- ในรายละเอียดจะต้องมีการ link work item ที่เกี่ยวข้องในการ demo ด้วย
- สร้าง work item จาก issue ตาม flow ปกติ เพื่อให้ดำเนินงาน demo ไปได้ใน Management board
- หลังจาก work item เสร็จสิ้น จะถือว่า issue ที่สร้างมาเสร็จเช่นกัน
- feedback ที่ได้จากการ demo ให้นำไปสร้าง issue ใน board ที่เกี่ยวข้อง
วิธี link work item เข้ากับ issue
เราสามารถ link work item ที่เกี่ยวข้องได้ตามรูป (image 24)
- ที่ “Related Work” ให้กด “Add link”
- เลือกประเภทในการ link
- กรอก id ของ work item ที่เกี่ยวข้อง
- รายการ work item ที่เกี่ยวข้องทั้งหมด
- บันทึก
Issues
จะมีข้อบังคับที่ผู้สร้าง issue จะต้องปฏิบัติตาม เมื่อมีคนมารับ issue ไปทำงานต่อ ได้แก่
- เปลี่ยนผู้รับผิดชอบ — โดยปกติคนรับผิดชอบจะเป็นคนสร้าง ซึ่งถูกตั้งค่ามาให้จากระบบอัตโนมัต และเมื่อมีคนต้องการนำ issue นั้นๆ ไปทำงาน จำเป็นจะต้องเปลี่ยนคนรับผิดชอบ เพื่อสามารถบอกได้ว่าใครรับงานไปทำ
- กด follow หลังเปลี่ยนคนรับผิดชอบ — หลังจากเปลี่ยนคนรับผิดชอบเรียบร้อยแล้ว ให้คนสร้าง issue กด follow เพื่อติดตามความคืบหน้า
วิธีการเปลี่ยน และกด follow สามารถทำได้ ตามรูป (image 25)
DOD vs Acceptance Criteria
ใน board จะมีสิ่งที่เรียกว่า Definition Of Done (DOD) และ Acceptance Criteria อยู่ ซึ่งจะแตกต่างกัน ดังนี้
- Definition Of Done — จะเป็นกำหนดในการเลื่อน work item ไปยัง lane อื่นๆ ใน board เช่น จะเลื่อนจาก Active laneไปที่ Review lane ต้องให้ work item เสร็จทั้งหมดเท่านั้น จึงจะเลื่อนไปที่ Review lane ได้
- Acceptance Criteria — จะเป็นข้อกำหนดว่าต้องทำอะไรบาง จึงจะถือว่างานชิ้นนี้เสร็จ ซึ่งจะถูกระบุไว้ใน work item นั้นๆ ตามรูป (image 26)
Summary
โดยภาพรวมแล้ว Board ใน DevOps เป็นเครื่องมือชนิดหนึ่ง ที่จะช่วยให้ทีมทำงานร่วมกันง่ายขึ้น ได้แก่ การแจ้งว่ามีงานอะไรบ้าง การกระจายงาน การติดตามงานในแต่ละส่วนเพื่อสามารถมองเห็นถึง progress ของงานภาพรวมได้ เป็นต้น
ใน Board จะมีการแบ่ง Lanes กันเพื่อบอกสถานะของแต่ละงานได้ และแสดงให้เห็นถึง Flow การใช้งานของ Board ตั้งแต่ต้นจนจบได้
สรุปแล้ว เมื่อมีเครื่องที่สามารถทำให้ทีมทำงานได้สะดวกขึ้น คนในทีมก็จำเป็นจะต้องทำตามข้อตกลงกันได้ จึงจะทำให้ทีมมีประสิทธิภาพได้มากขึ้น