[Knowledge] Using DevOps’s board

ใน DevOps มี board สำหรับการวางแผนการทำงานในทีม และสามารถแบ่งการวางแผนต่างๆ ในแต่ละทีมได้อีกด้วย

ในบทความนี้จะพาไปเรียนรู้การใช้งาน Board โดยแบ่งเป็น 6 ข้อหลักๆ ดังนี้

1. Boards
2. Lanes
3. Flows
4. Demo
5. Issues
6. DOD vs Acceptance Criteria

Boards

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

Board จะสามารถแบ่งตัวมันเองให้สำหรับแต่ละทีมได้ด้วย ซึ่งเราจะแบ่งเป็น 2 Boards ได้แก่

1. External board — สำหรับติดต่อกับคนนอก เช่น ทีมภายในต้องการความช่วยเหลือจากทีมภายนอก หรือทีมภายนอกต้องการให้ทีมภายในทำอะไรบางอย่าง
2. Internal board — สำหรับทีมภายในคุยกันเอง

วิธีการเข้าไปที่ Boards ของทีมต่างๆ สามารถเข้าไปได้โดยวิธีการดังนี้

1. เมื่อเข้ามาที่ Project ให้เลือกเมนูจากซ้ายมือ “Boards”(1) แล้วเลือก “Boards”(2) อีกที ดังรูป (image 1)

image 1 — วิธีเข้าไปดูที่ Boards

2. เลือก Dropdown(1) เพื่อดูทีมทั้งหมด และเลือก board(2) เพื่อเปลี่ยน Board ที่ต้องการทำงานด้วย ดังรูป (image 2)

ในรูป Extern คือ External board และ Proposal Team คือ Internal board

image 2 — การเปลี่ยน Boards

Lanes

เมื่อเข้าใช้งาน Board เราจำเป็นจะต้องมีการแบ่งงาน ซึ่งเราจะเรียกตัวงานว่า work item และมีการแบ่งสถานะงานต่างๆ เช่น งานยังไม่เสร็จ งานเสร็จแล้วแต่รอตรวจสอบ เป็นต้น

ดังนั้น Lanes จะเข้ามาช่วยเรื่องสถานะงานเหล่านี้ เพื่อให้ทีมรับรู้สถานะของ work item ต่างๆ ในทีมได้ โดยจะแบ่งไว้ 6 Lanes ดังนี้

1. New — work item ใหม่ๆ ที่ถูกเพิ่มขึ้นมาจะถูกนำมากองไว้ที่ Lane นี้ โดยระบบจะจัดการนำ work item ที่เพิ่มมาใหม่ใส่ไว้ที่นี่อัตโนมัติ
2. Ready — เมื่อ work item มีการอัพเดท จนทีมสามารถทำงานได้ เช่น พูดคุยเพื่อเคลียร์ความชัดเจนของ work item เรียบร้อย, ต้องการ design จาก garphic ฯลฯ เป็นต้น แต่ยังไม่มีคนมารับผิดชอบงานตัวนี้ ทีมจะย้าย work item มาที่ Lane นี้
3. Active —เมื่อมีคนที่จะรับผิดชอบ/ทำงาน กับ work item ตัวนั้นๆแล้ว คนที่รับผิดชอบ จะย้าย work item มาที่ Lane นี้ เพื่อบอกถึงสถานะว่า work item ตัวนี้มีคนกำลังดำเนินการทำให้ work item เสร็จอยู่
4. Review —หลังจากที่ทำ work item จนเสร็จ และต้องการให้มีการตรวจสอบโดยจะเป็นคนนอกทีม หรือคนในทีมกันเอง คนรับผิดชอบจะย้ายมาที่ Lane นี้ เพื่อรอคนมาตรวจสอบ
5. Resolved — หลังจากตรวจสอบเสร็จ และไม่มีการแก้ไข work item คนที่ตรวจสอบจะย้ายมาที่ Lane นี้ เพื่อบ่งบอกว่าตรวจสอบเรียบร้อย สามารถปิด work item ที่ตรวจได้
6. Closed — เมื่อเสร็จสิ้นการตรวจสอบแล้ว คนที่รับผิดชอบงานจะย้าย มาที่ Lane นี้ เพื่อบอกกับทีมว่า work item ตัวนี้เสร็จแล้ว

โดยสรุป คือ ตั้งแต่ต้นกระบวนการทีมจะสร้าง work item ใหม่ (New lane) และนำไปพูดคุยเคลียร์ความชัดเจนของตัวเอง จนเสร็จสิ้น(Ready lane) และมีคนรับผิดชอบนำ work item ไปทำ (Active lane) จนทำงานจนเสร็จ และนำไปตรวจสอบความถูกต้อง (Review lane) เมื่อตรวจสอบแล้วผ่าน (Reslove lane) คนที่รับผิดชอบ work item จะบอกกับทีมว่าเสร็จแล้ว (Close lane) ดังรูป (image 3)

image 3 — วิธีการดำเนินการ work item ในแต่ละ lanes

Flows

วิธีดำเนินงานใน board คือ จะมีคนสร้างเคส (Issue) เพื่อแจ้งให้ทีมทราบว่าพบปัญหา หรือต้องการให้ทีมทำอะไรสักอย่าง เช่น ต้องการให้แก้ไข Document, แจ้ง bug หรือข้อเสนอแนะ เป็นต้น

แล้วเมื่อทีมสะดวกที่จะรับ Issue ไปทำ ทีมจะสร้าง work item เพื่อย่อยงานออกหลายๆ ชิ้น เพื่อที่จะดำเนินการอย่างไร Issue ที่รับมาถึงจะเสร็จ เมื่อ work item ที่ย่อยออกมาปิดหมดทุกตัว จะถือได้ว่า Issue ที่รับมานั้นเสร็จ ดังรูป (image 4)

image 4 — ภาพรวมหลักการทำงานของ board

ทีมรับ Issue ไปจัดการ

หลังจากที่มีการแจ้ง Issue เรียบร้อยแล้ว เมื่อทีมต้องการจะจัดการกับ Issue ดังกล่าว จะมีการพูดคุย เพื่อเคลียร์ความเข้าใจ/รายละเอียดกับคนที่แจ้งเข้ามา

หลังจากที่ทีมพูดคุยเพื่อเคลียร์ความเข้าใจกับคนแจ้งเรียบร้อยแล้ว ทีมจะสามารถแบ่งงานออกมาได้ 2 ประเภท ได้แก่

1. Issue ที่ไม่เกี่ยวข้องกับ Code — จะเป็นการแจ้งปัญหาที่ไม่มีการแก้ source code เช่น Document ไม่อัพเดท, ข้อเสนอแนะ เป็นต้น
2. Issue ที่เกี่ยวข้องกับ Code — จะเป็นการแจ้งปัญหาโดยที่ทีมอาจจะต้องมาแก้ไข source code เช่น พบ bug, ต้องการให้มี feature ใหม่, Test เป็นต้น

การสร้าง Issue

1. เลือก work items จาก sidemenu แล้วเลือก “New Work Item” และเลือก “Issue” เพื่อระบุว่าจะสร้าง work item ที่เป็น Issue ดังรูป (image 5)

image 5 — การสร้าง issue

2. กรอกรายละเอียด หัวข้อ(1) รายละเอียดที่ต้องการให้ทำ(2) เมื่อกรอกเรียบร้อยให้กด save (3) ดังรูป (image 6)

image 6— รายละเอียด issue

3. เมื่อสร้าง issue สำเร็จ จะได้ดังรูป (image 7)

image 7— รายการ work item ทั้งหมด หลังจากสร้าง issue สำเร็จ

การสร้าง Work Item จาก Issue

1. แบ่งงานจาก issue โดยในหน้ารายละเอียดของ issue ให้เลือก “…” แล้วเลือก “Create copy of work item” ดังรูป (image 8)

image 8— การสร้าง work item จาก issue

2. เลือก work item type เป็น Feature หรือ User Story ซึ่งขึ้นอยู่กับการคุยภายในทีมแล้วว่าจะระบุชนิดงานนี้ว่าเป็นระดับใด (ตัวอย่างจะสร้างเป็น User story) ดังรูป (image 9)

อย่าลืมเลือก “Include existing links” เพื่อให้ work item มี relate กับ Issue ที่กำลังเลือกอยู่ (ถ้า Issue มีรูป ให้เลือก “Include existing attachments” ด้วย)

image 9— selecting type of work item

3. ในขั้นตอนนี้ ระบบกำลังจะสร้าง work item โดยมีข้อมูลคัดลอกมาจาก Issue ครบถ้วนแล้ว แต่สามารถเปลี่ยนแปลงได้ขึ้นอยู่กับผู้สร้าง ในส่วน Related Work จะเห็นว่ามี relation กับ Issue ก่อนหน้านี้ ดังรูป (image 10)

image 10— creating work item (user story)

4. เมื่อสร้างสำเร็จ จะมีรายการ work item ใหม่ ดังรูป (image 11)

image 11— รายการ work item หลังจากสร้าง work item (user story) ใหม่สำเร็จ

จากตัวอย่าง “การสร้าง Issue” และ “การสร้าง Work Item จาก Item” จะถูกนำมาเป็นเคสตัวอย่าง ในการดำเนิน flow หลายๆ แบบ

ดำเนิน Flow โดย Issue ไม่เกี่ยวข้องกับ Code

• แบบที่ 1 — ดำเนินการสำเร็จ

image 12 — ดำเนินการได้ตามปกติ (แบบไม่เกี่ยวข้องกับ Code)

จากรูป (image 12) จะเห็นการทำงานตามแต่ละ lanes ดังนี้

1. work item ใหม่ที่ถูกเพิ่มเข้ามาจะอยู่ที่ New lane (สร้าง work item (task) เพื่อแบ่งขั้นตอนว่าต้องทำอะไรบ้าง work item (user story) นี้จึงจะถือว่าเสร็จ
2. หลังจากที่พูดคุย/เคลียร์ความชัดเจน จนสามารถพร้อมนำไปทำงานต่อได้ ทีมจะย้ายมาที่ Ready lane
3. เมื่อมีคนต้องการทำ work item ดังกล่าว คนรับผิดชอบจะย้ายมาที่ Active lane และดำเนินงานต่อจนเสร็จ (ทำ work item ภายในนั้นให้เสร็จทั้งหมด)
4. หลังจากที่ทำงานจนเสร็จ (Task สำเร็จครบทุกตัว) จะเลื่อนไปที่ Review lane เพื่อให้คนมาตรวจสอบ
5. หลังตรวจสอบผ่านเรียบร้อย จะเลื่อนมาที่ Resolved lane
6. ผู้รับผิดชอบงาน จะเลื่อนมาที่ Close lane เพื่อบอกว่างานถือว่าสำเร็จเรียบร้อย

• แบบที่ 2 — Review แล้วไม่ผ่านต้องกลับมาแก้ไขให้เรียบร้อยถึงจะปิดงานได้

image 13 — ดำเนินการไม่ผ่าน ต้องแก้ไขใหม่ (แบบไม่เกี่ยวข้องกับ Code)

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

1. Review ไม่ให้ผ่าน ผู้รับผิดชอบงานจะเลื่อนกลับมาที่ Active lane แล้วแก้ไขงาน (อาจจะเพิ่ม work item แก้ไขงานจาก review) ให้เรียบร้อย
2. เมื่อแก้ไขตามที่ผู้ตรวจบอกเรียบร้อยแล้ว จะเลื่อนมาที่ Review lane อีกรอบ เพื่อตรวจสอบใหม่อีกครั้ง หากถ้าไม่ผ่าน ก็ต้องกลับไปแก้ไขอีกครั้ง จะวนระหว่าง ข้อ 1 และ 2 แบบนี้ไปเรื่อยๆ จนกว่าจะตรวจสอบผ่าน
3. หลังจากที่ตรวจสอบผ่านเสร็จแล้ว จะเลื่อนมาที่ Resolve lane ตามปกติ แล้วดำเนินการตาม flow ปกติต่อได้เลย

เมื่อดำเนิน flow จนจบกระบวนการ (work item เสร็จหมดทุกตัว) ทั้งแบบที่ 1 และแบบที่ 2 ให้ผู้รับผิดชอบงานกลับไปแจ้ง issue ด้วยว่างานเสร็จสิ้นแล้ว และให้ปิด issue ตัวดังกล่าว (เปลี่ยน state เป็น “Closed”) ดังรูป (image 14)

image 14 —ปิดงาน issue

ดำเนิน Flow โดย Issue เกี่ยวข้องกับ Code

สำหรับการทำงานที่มีความเกี่ยวข้องกับ source code จะมีขั้นตอนเพิ่มเติมเข้ามา คือ การ Fork repo และ Pull-request ดังรูป (image 15) ซึ่งรายละเอียดมี ดังนี้

1. Fork repo — สร้าง repo ส่วนตัวขึ้นมาใหม่ โดย clone ของทั้งหมดจาก repo หลัก เพื่อป้องกันไม่ให้ผู้รับผิดชอบงานสามารถแก้ไข repo หลักโดยตรงได้
2. Pull-request — หลังจากที่แก้ไข/เปลี่ยนแปลง source code จาก repo ส่วนตัวเสร็จเรียบร้อย จะมีการ pull-request เพื่ออัพเดทสิ่งที่แก้ไขรวมกับ repo หลัก ซึ่งในส่วนนี้จะมีการตรวจสอบ (Code Review) และเมื่อผ่านแล้ว ระบบจะรวม source code เข้ามาที่ repo หลักให้อัตโนมัต

image 15 — ขั้นตอนเพิ่มเติม เมื่อทำงานกับ source code

Fork repo

1. เลือก “Repos” (1) เลือก repo ที่ต้องการ fork (2) ต่อมาเลือก “…” (3) แล้วเลือก “Fork” (4) ดังรูป (image 16)

image 16 — เลือก repo Fork repo

2. ตั้งชื่อ repo ที่จะสร้างขึ้นมาใหม่ (1) ต่อมาเลือก fork ไปยัง project ใด (2) และเลือก “All branches” (3) แล้วเลือก “Fork” (4) ดังรูป (image 17)

image 17 — รายละเอียดการ fork repo

3. เมื่อ fork สำเร็จ โดยจะมีข้อสังเกต คือ ชื่อ repo(1) และที่อยู่ของ project (2) จะมีการเปลี่ยนแปลง ดังรูป (image 18) ซึ่งต่างจากรายละเอียดของ repo ตั้งต้น (image 16)

image 18 — รายละเอียด repo หลังจาก fork เสร็จแล้ว

Pull-request

1. เลือก “Pull-requests” (1) แล้วเลือก “New pull-request” (2) ดังรูป (image 17)

ในกรณีที่มีการ push งานขึ้นใน branch ต่างๆ ระบบจะแสดงให้เห็นว่ามี update อันใหม่เข้ามา แล้วสามารถกด “Create a pull-request” (3) จากตรงนี้ได้เลย

image 17 — create new pull-request

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

image 18 — รายละเอียดในการสร้าง pull-request

3. เมื่อสร้าง pull-reuqest สำเร็จ จะได้ตาหน้าดังรูป (image 19) ในส่วนของ Discussion (1) จะเป็นการพูดคุยระหว่างคนที่สร้าง pull-request นี้ และคนที่มาตรวจสอบ (Reviewer) เพื่อที่จะพูดคุยทำความเข้าใจของงานกัน และบางกรณีที่ไม่ให้ผ่าน Reviewer จะใส่เหตุผล และ comment code ลงมาในส่วนของ discussion ได้ด้วย

image 19 — รายละเอียดของ pull-request

สำหรับการทำงานกับ Issue ที่เกี่ยวข้องกับ code จะแตกต่างจากเดิมเล็กน้อย แต่พื้นฐานใช้ board และ flow แบบเดียวกัน ดังตัวอย่าง

• แบบที่ 1 — ดำเนินการสำเร็จ

image 20 — ดำเนินการได้ตามปกติ (แบบเกี่ยวข้องกับ Code)

จากรูป (image 20) จะเห็นว่าดำเนินจะเหมือนเดิมกับที่ผ่านมา แต่จะแตกต่างจากเดิมเล็กน้อย ได้แก่

1. เพิ่มการ Fork repo ส่วนตัวออกมา เพื่อให้ไม่กระทบกับ repo หลัก
2. หลังจากที่ดำเนินการมาเรื่อยๆ จนปิด work item ครบแล้ว จะต้องทำ pull-request ก่อนเสมอ แล้วค่อยเลื่อนไป Review lane เพื่อที่จะให้คนมาตรวจสอบ source code
3. หลังจากที่ผู้ตรวจสอบให้ผ่านเรียบร้อย ระบบจะรวม source code เข้ามาด้วยกัน และ work item จะถูกเลื่อนไปยัง Closed lane โดยอัตโนมัตด้วยตัวระบบเอง

• แบบที่ 2 — Review แล้วไม่ผ่านต้องกลับมาแก้ไขให้เรียบร้อยถึงจะปิดงานได้

image 21 — ดำเนินการไม่ผ่าน ต้องแก้ไขใหม่ (แบบ่เกี่ยวข้องกับ Code)

จากรูป (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 อะไรบ้าง และแต่ละตัวมีความหมายว่าอะไรบ้าง

image 22 — วิธีใส่ Tag ใน work item

• แบบที่ 3 — จำเป็นต้องให้คนอื่นมาช่วยงานบางส่วน จึงสามารถจบงานได้

image 23–ต้องให้คนอื่นมาช่วยงานบางส่วน จึงสามารถจบงานได้

จากรูป (image 23) เมื่อเราทำงานไปถึงระดับนึง แล้วพบว่าต้องมีการทำงานอีกอย่าง ซึ่งเราไม่สามารถทำได้ เช่น ไม่เคยทำ/ทำไม่เป็น หรือไม่มีเวลาทำในส่วนนั้น เป็นต้น เราจะวิธีการรับมือเหตุการณ์ดังกล่าว ได้แก่

1. สร้าง work item ขึ้นมา เพื่อให้ติดตาม issue ที่เรากำลังจะสร้างใหม่ และสร้าง issue ใหม่ขึ้นมา โดยใส่ tag HelpNeeded เพื่อบอกว่าต้องการให้คนอื่นมาช่วยเหลือใน issue ตัวนี้ ส่วนคนอื่นก็จะมาติดต่อขอทำ issue ตาม flow ปกติที่เคยกล่าวมาข้างต้น
2. เมื่อคนรับ issue ไปทำจนเสร็จ work item ที่เอาไว้ติดตามจะถือว่าเสร็จด้วย และเมื่อ work item ทุกตัวเสร็จ ค่อยทำ pull-request แล้วส่งไปให้ตรวจสอบ
3. เมื่อตรวจสอบแล้วผ่าน จะถือว่าปิดงานตาม flow ปกติ

• แบบที่ 4 — จำเป็นต้องให้คนอื่นมาช่วยงานบางส่วน จึงสามารถจบงานได้ และเมื่อทำ pull-request ไปแล้ว Review ไม่ผ่านต้องกลับมาแก้ไขให้เรียบร้อยถึงจะปิดงานได้

ในกรณีนี้จะแบ่งออกเป็น 2 เคส ได้แก่

1. จบได้ด้วยทีมเอง — ถ้าหากทีมสามารถแก้ไขตามสิ่งที่ผู้ตรวจสอบบอกได้ จะสามารถทำได้เหมือนในกรณีของ “ดำเนิน Flow โดย Issue เกี่ยวข้องกับ Code แบบที่ 2”
2. ต้องให้คนอื่นมาช่วยแก้ — อาจเกิดขึ้นได้ เป็นผลต่อเนื่องจาก “ดำเนิน Flow โดย Issue เกี่ยวข้องกับ Code แบบที่ 3” ซึ่งเราไม่ได้เป็นคนทำงานนั้น จำเป็นต้องให้คนที่ทำ issue เข้ามาแก้ไข เราก็จะสร้าง issue ใหม่ เพื่อให้เขากลับมาแก้งานแล้วค่อย pull-request ใหม่อีกรอบ วนแบบนี้จนจบ flow

Demo

เมื่องานมีการอัพเดท เปลี่ยนแปลงแล้ว ทีมต้องการจะ demo ของที่ทำมา ทีมสามารถทำได้โดย

Management board — เป็น board กลางที่สำหรับ share resource ระหว่าง project ซึ่ง board นี้จะอยู่ภายใต้ share resource project ตามที่ทีมคุยกันไว้

1. สร้าง issue ไว้ที่ Management board เพื่อเป็นการแจ้งทุกทีมว่าจะมีการ demo
2. ในรายละเอียดจะต้องมีการ link work item ที่เกี่ยวข้องในการ demo ด้วย
3. สร้าง work item จาก issue ตาม flow ปกติ เพื่อให้ดำเนินงาน demo ไปได้ใน Management board
4. หลังจาก work item เสร็จสิ้น จะถือว่า issue ที่สร้างมาเสร็จเช่นกัน
5. feedback ที่ได้จากการ demo ให้นำไปสร้าง issue ใน board ที่เกี่ยวข้อง

วิธี link work item เข้ากับ issue

เราสามารถ link work item ที่เกี่ยวข้องได้ตามรูป (image 24)

1. ที่ “Related Work” ให้กด “Add link”
2. เลือกประเภทในการ link
3. กรอก id ของ work item ที่เกี่ยวข้อง
4. รายการ work item ที่เกี่ยวข้องทั้งหมด
5. บันทึก

image 24 — วิธี link work item ใน issue

Issues

จะมีข้อบังคับที่ผู้สร้าง issue จะต้องปฏิบัติตาม เมื่อมีคนมารับ issue ไปทำงานต่อ ได้แก่

1. เปลี่ยนผู้รับผิดชอบ — โดยปกติคนรับผิดชอบจะเป็นคนสร้าง ซึ่งถูกตั้งค่ามาให้จากระบบอัตโนมัต และเมื่อมีคนต้องการนำ issue นั้นๆ ไปทำงาน จำเป็นจะต้องเปลี่ยนคนรับผิดชอบ เพื่อสามารถบอกได้ว่าใครรับงานไปทำ
2. กด follow หลังเปลี่ยนคนรับผิดชอบ — หลังจากเปลี่ยนคนรับผิดชอบเรียบร้อยแล้ว ให้คนสร้าง issue กด follow เพื่อติดตามความคืบหน้า

วิธีการเปลี่ยน และกด follow สามารถทำได้ ตามรูป (image 25)

image 25 — วิธีเปลี่ยนคนรับผิดชอบ และกด follow

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)

image 26 — ตัวอย่าง Acceptance Criteria ใน work item

Summary

โดยภาพรวมแล้ว Board ใน DevOps เป็นเครื่องมือชนิดหนึ่ง ที่จะช่วยให้ทีมทำงานร่วมกันง่ายขึ้น ได้แก่ การแจ้งว่ามีงานอะไรบ้าง การกระจายงาน การติดตามงานในแต่ละส่วนเพื่อสามารถมองเห็นถึง progress ของงานภาพรวมได้ เป็นต้น

ใน Board จะมีการแบ่ง Lanes กันเพื่อบอกสถานะของแต่ละงานได้ และแสดงให้เห็นถึง Flow การใช้งานของ Board ตั้งแต่ต้นจนจบได้

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