จดบันทึก knowledge sharing เรื่องของ agile & scrum

เนื่องจากทางทีมทำงานแบบ Agile กันอยู่แล้วเนอะ ก็เลยหาความรู้จากทีมอื่นๆที่เขามา sharing ให้เราฟัง ก็เลยจดมา

Ookbee Life

วันนี้มีกิจกรรม Knowledge Sharing Session ในรูปแบบ Online ได้ ไอ๊ วิกรานต์ เพ็งแจ่ม Development Team Lead ทีม A Duang เป็น Speaker พูดคุยในหัวข้อ Agile & Scrum process เพื่ออัพเดต...

Facebook

Agenda จะมีดังนี้

• pain point และความปวดร้าวที่เราพบเจอ
• Agile & Scrum process คืออะไร
• a ดวง scrum process & planing
• ตัวอย่างการใช้ Jira และรายละเอียดต่างๆ
• การทำ Retrospective ในช่วง WFH
• Q & A

บางอย่างทางเราขอเซ็นเซอร์ดีกว่าเนอะ แหะๆ และบางอันเราก็จะเสริมของเราเข้าไปด้วยจ้า

ส่วนเกี่ยวกับ Agile Fundation นั้น สามารถอ่านได้ที่นี่เลยจ้า

จดสรุปการเรียน Agile Foundation ในเว็บ klasssi

จริงๆเจอเว็บ klasssi ในทวิตเตอร์ว่ามีคอร์สให้เรียนฟรี ทางเราหยิบมาเรียนคอร์สนึง คือ Agile Foundation โดยนอกจาก Agile แล้วยังมีเรื่อง OKRs อีกด้วย สอนโดย HR ของ KBANK

MikkiPastel StudioMinseo Chayabanjonglerd

pain point และความปวดร้าวที่เราพบเจอ

• ไม่เห็นภาพว่าอะไรได้เมื่อไหร่ และถูกเลื่อนไปเรื่อยๆ ถ้ามีอะไรถูกแทรก หรือมีปัญหาบางอย่าง เช่น อ่ะ ระดับผู้บริหารเดินมาถาม dev ที่เป็น team lead ว่าจะทำ feature นี้ตอนไหน พอถึงเวลาจริงๆคือทำไม่เสร็จ ต้องเลื่อนไปก่อน (ตัวอย่างที่นึกออก เช่น แพลนงานใน sprint หมดหล่ะ จู่ๆ PM ไปคุยกับผู้บริหาร แล้วก็เอางานมาแทรกเฉย ซึ่งผิดหลักของ agile เนอะ ควรเอาเข้า backlog เพื่อนำไปแพลนไว้ใน sprint ถัดไปมากกว่า เป็นต้น)
• การสื่อสารผิดพลาด ทำให้เข้าใจไม่ตรงกัน กว่าจะเจอก็ตอนส่งเทส ทำให้งานสะดุด เช่น ฝั่ง iOS และ Android ทำ feature นึง เสร็จหมดส่งเทส สรุปแสดงผลบางอย่างไม่เหมือนกัน แล้ว tester ก็จะหัวร้อนหัวเสีย ว่าของใครถูก ของใครผิด หรือผิดทั้งคู่
• stakeholder (ผู้มีส่วนได้ส่วนเสีย) ไม่ได้เห็นภาพเดียวกัน ไม่เจ้าใจว่าทีมทำอะไร และอนาคตจะทำอะไร เช่น หลังจากส่งเทสผ่านหมดแล้ว ปล่อยแอพ แต่ทางฝั่ง commu (ก็คือ commulity เป็นคนที่คุยกับ user นั่นแหละ) ยังไม่เห็น app version ใหม่ หรือ feature ใหม่ที่ปล่อยออกมา หรือทีม support ตอบลูกค้าไม่ได้ว่า version ใหม่มี feature อะไร และ developer ก็ตอบและแก้ไปแบบ case-by-case (ตัวอย่างที่นึกออก เช่น มีน้อง commu อยากได้ feature เสริม ซึ่งมาแทรกงานที่ developer ทำอยู่ โดยไม่ผ่าน PM แบบจะเอาอยากได้ในสองอาทิตย์แต่พวกตูทำให้ไม่ทันเฟร้ย และน้องเขาก็ได้เรียนรู้แล้วว่ามันต้อง planing เผื่อไว้นะ พวกพี่ๆจะได้ทำให้ทัน จะได้เอางานเข้า sprint กัน)

Agile & Scrum process คืออะไร?

แนวคิดการทำงานมาใช้แก้ปัญหาต่างๆที่เจอใน waterfall เช่น วางแผนลำบาก, รู้ feedback ช้า ทำให้ต้องรื้อทำใหม่หมด ดังนั้นจะต้องทำให้ทีมยอมรับการทำงานวิธีนี้ ซึ่งเป็นแนวคิด มีแนวทางปฏิบัติและรูปแบบไม่ตายตัว มีหลายรูปแบบให้ใช้ เช่น scrum, kanban, extreme programming

แนวคิดสำคัญของ Agile

• ให้ความสำคัญในการสื่อสารในทีม แต่ไม่ใช่ว่าไม่ต้องมี document เลย คือหลักการเน้นคุยกัน ไม่เน้นทำเอกสารรัวไ แต่ก็ต้องมี document ไว้อ้างอิงเผื่อกลับมาดู
• เน้น feedback ให้เร็ว เพราะอาจจะเปลี่ยนแปลงได้ตลอดเวลา
• ส่งมอบของทีละน้อยๆ แต่บ่อยๆ โดยการแบ่งเป็น sprint โดยหลักการมันคือในทุก sprint ของที่เราทำนั้น จะต้องใช้งานได้
• กล้าผิดพลาด และเอามาปรับปรุงให้เร๋วที่สุด
• ใช้เหตุผลแก้ปัญหากัน (ไม่ใช่คุยแบบใช้อารมณ์และทรงผม และต่างๆนานา มาคุยกัน เรามาทำงานไม่ได้มาตีกันเน้อออ)

Scrum Process

• backlog : list ของงานทั้งหมดที่จะทำ
• grooming : คุยถึงงานที่เอาเข้า sprint
• planing : คุยถึงงานที่เอาเข้า sprint แต่ต่างจาก grooming ที่มีการแบ่งเป็น 2 ส่วน
• sprint backlog : ประกอบด้วย 1 scrum team โดยเวลาในแต่ละ sprint อาจจะเป็น 2-4 สัปดาห์ ขึ้นกับจำนวนคน
• daily scrum : เช่น standup meeting
• sprint review : เอางานที่ทำใน sprint มา review และดูร่วมกัน
• retrospective : กิจกรรมสุดท้ายใน sprint

มาดูว่ากิจกรรมต่างๆในแต่ละ sprint ว่าทำอะไร เมื่อไหร่ อย่างไร กันบ้าง

Grooming

• กิจกรรมในการเริ่มต้น sprint ว่าเราจะทำอะไรใน sprint นี้บ้าง และมี flow การทำงานยังไง และ design จะต้องนิ่งแล้ว
• แตกการ์ดมาล่วงหน้าครบถ้วนตาม design ถ้าตกหล่นสามารถ discuss และเพิ่มเติมได้
• โหวตให้คะแนนสำหรับการ์ดต่างๆ ถ้ามีอะไรขาดตกก็เติมได้ตรงนี้ เราจะให้คะแนนโดยใช้เลข fibonanci เนื่องจากตามทฤษฎีได้บอกไว้ว่าเป็นการ estimate จึงใช้ตัวเลขแบบไม่เป๊ะ
• การให้คะแนนการ์ดของทีม a ดวง จะให้คะแนน 0.5 เมื่อมีการปรับแก้ UI เพียงอย่างเดียว ไม่มีเรื่อง API มาเกี่ยวข้อง ให้ 1 เมื่อมีการแก้ UI และต่อ API ให้คะแนน 2-3 เมื่อทำมากกว่านั้น และถ้ามากกว่า 5 ก็คือการ์ดใหญ่เกินไป ควรการ์ดให้เล็กลง
• ส่วนในทีมเรานั้น จะเทียบกับเวลาที่ทำ เช่น 0.5 คือกระพริบตาเสร็จ 5 คือทำครึ่งวัน 8 คือวันนึง ประมาณนี้ หรือจะบอกความยากง่าย ซึ่งทั้งหมดเป็นการใช้ความรู้สึกมาตัดสิน แต่ถ้าเราทำบ่อยๆ เราจะ estimate งานได้แม่นยำขึ้นนะ
• เราสามารถให้คะแนนการ์ดข้ามสายงานกันได้ เช่น การ์ด backend ฝั่ง frontend ก็สามารถให้คะแนนกันได้นะ
• คนที่เข้า : Product Owner, Dev Lead, Developer, QA tester, UI/UX Designer

Planning part 1

• ทำต่อจาก Grooming ให้ PO ตัดสินใจ ว่าทั้งหมดมีกี่ point ทำทันไหมนะ ควรทำเรื่องอะไรก่อน และจะไม่หยิบอะไรมาทำใน sprint นี้ ซึ่งจะคำนวณจากคน จึงควรลางานล่วงหน้า และเรารับงานใน sprint นี้จริงๆได้เท่าไหร่ เมื่อรวมวันลาและวันหยุดแล้ว
• ใช้เวลาไม่เกิน 2 ชั่วโมง
• สุดท้ายจะได้การ์ดที่มร point และ flow ของแต่ละการ์ดว่าทำอะไร ขาดอะไรก็ note ไว้ก่อน และค่อยมา update กันทีหลัง
• คนที่เข้า สามารถเข้าได้ทุกคนเลยยิ่งดี จะได้มีอะไรช่วยเสริมกันได้

Planning part 2

• ลงรายละเอียดด้าน technical ว่าติดอะไร จะได้หา solution ร่วมกัน และมีการ note เก็บไว้ และ update กับทุกคน
• ใช้เวลาครึ่งวันถึง 1 วัน ตามความเหมาะสม
• คนที่เข้า : Dev Lead, Developer ส่วน QA tester, UI/UX Designer เป็น optional

Develop

• ทำงานหลังจาก planing กัน developer ก็ทำงานกันไป
• UI/UX Designer เขาจะทำ design ล่วงหน้ากัน 1 sprint
• Testing คือแต่ละการ์ดควรจบได้ด้วยตัวเอง เมื่อทำ feature ในการ์ดนั้นๆเสร็จสามารถส่งเทสได้เลย เมื่อมัน fail ก็ตีกลับมาแก้ ไม่ต้องรอส่งเทสปลาย sprint แล้วแก้การ์ดกันไม่ทัน
• มีกิจกรรมย่อย คือการทำ PI หรือ Product Implement จะเป็นการวางแผนในระยะยาว ทำเรื่อยๆถ้ามี requirement หรือมีเรื่องต้องคุย ใช้เวลาไม่เกิน 2 ชั่วโมง เป็น session ที่ PO, Dev Lead นั่งคุยกัน อาจจะ require UI/UX Designer และ backend เข้าด้วย

Daily Scrum

• update งานในแต่ละวัน ว่าเรากำลังทำอะไร ถืองานอะไรอยู่ เป็นยังไงบ้าง ติดปัญหาอะไรไหม และทำอะไรต่อ
• จริงๆควรเน้นพูดว่าติดปัญหาอะไร เพื่อให้คนที่เกี่ยวข้องรับทราบและช่วยกันแก้ต่อไป
• ใช้เวลา 10-15 นาที คุยกันสั้นๆ ชื่อก็บอกอยู่ว่า standup meeting ยืนนานเดี๋ยวเมื่อยเอาน้าาา
• ช่วงเวลาที่คุยกัน แล้วแต่ทีมตกลง ส่วนตัวเคยทำตอนเช้า และตอนเย็น พบว่าตอนเช้าดีกว่าแหละ แหะๆ

Product Refinement

• เริ่มทำกิจกรรมนี้เมื่อผ่านไปครึ่งทาง หรือตามแต่ตกลง แหะๆ
• เป็นการคุยกันว่า sprint นี้ทำอะไรไปถึงไหนแล้ว ทำวางแผนกันจะทำทันใน sprint นี้ไหม เป็นการเอาการ์ดเข้ามาเพิ่ม เมื่องานน้อยเกินไป หรือเอาการ์ดออก เมื่องานมันโหลด ทำไม่ทัน ก็สามารถปรับกันได้ และมีการ update กับทีม
• ของทีมเราเข้าเฉพาะ dev lead และ developer

Tech Standard

• เป็นการคุยเรื่อง performace ที่ทีมจะนำมาปรับใช้กัน เช่น update framework ให้เป็น version ใหม่ และเรา priority เท่าไหร่ ทำเสร็จหรือยัง ใช้เวลาประมาณ 1 ชั่วโมง
• ทางทีม a ดวง ทำเป็น Google Sheet ไว้ดู ในนั้นจะมี title ว่าคืออะไร มีรายละเอียดอะไรบ้าง priority เป็นอย่างไร มี status เป็นยังไง และมีการ remark ไว้
• ส่วนตัวเรายังไม่เคยทำจ้า มีแต่เอาการ์ดใน Firebase Crashlytics ไปแก้จ้า

Bug Triage

• บัคที่เจอระหว่างทาง เช่น user เจอบัค อาจจะแจ้งผ่าน commu หรือทีม support หรือบางทีก็ไปบ่นใน social มาเพิ่มใน Google Sheet และนำมาทำใน sprint ถัดๆไป ใช้เวลาไม่เกิน 1 ชั่วโมง
• ใน Google Sheet ของ a ดวง จะมี title ว่าคืออะไร มีรายละเอียด ประเภทว่าเป็น bug หรือเป็น issue มี priority และ status และมี remark ตามหลัง อาจจะเป็นการ์ดใน Jira หรืออื่นๆก็ได้ (นึกถึง feature สร้าง issue ใน Jira เฉยเลย)
• คนเข้าน่าจะ developer เนอะ และอันนี้ทางเรายังไม่เคยทำเช่นกันจ้า

Sprint Review

• ขั้นตอนก่อนสิ้นสุด sprint เอางานที่ทำทั้ง sprint มา present จริงๆก็คือ demo app ที่เราทำนั่นแหละ ให้ skateholder ดูพร้อมกัน เพื่อเก็บ feedback ว่าต้องปรับแก้อะไรบ้าง เพื่อให้เรารู้ feedback และนำไปแก้ได้เร็ว และเป็นการ update ข้อมูลด้วย ใช้เวลาประมาณ 2 ชั่วโมง
• ดังนั้นจึงต้องเข้าทุกคน
• หลังจากนั้นก็นั่งเก็บบัคต่างๆที่เจอ เพื่อทำ hotfix
• ส่วน feedback เอาไปทำในรอบถัดไป หรืออยู่ใน backlog ก่อน
• แต่จากประสบการณ์ของเรานั้น หลังจากนี้มักจะต่อด้วย Retrospective ทันที แหะๆ

Sprint PVT (Product Verification Testing)

• ของเสร็จหมดแล้ว ใกล้จะ submit app หล่ะ ให้ tester เทสรอบสุดท้ายก่อน submit app ถ้าไม่ผ่านก็เอาไปแก้จนผ่าน จึงจะ submit app ได้ อย่างฝั่ง Android จะอัพแอปในส่วนของ alpha ใน Play Store เนอะ

Retrospective

• ทำวันสุดท้ายของ sprint จริงๆคือกิจกรรมสุดท้าย เป็นการจบ sprint
• ทำเพื่อให้ทีมมีเวลาคุยกัน ปรับความเข้าใจกัน นั่งสะท้อนสิ่งที่เกิดขึ้นใน sprint ที่ผ่านมา ว่าทำอะไรไปบ้าง อะไรที่ดี อะไรที่ไม่ดี ควรปรับปรุงอะไร
• เน้นพูดคุยถึงปัญหาและ solution ไม่ blame ที่ตัวบุคคล ตัวอย่าง นายเอทำงานช้าจัง อันนี้ blame เนอะ ควรจะเป็น เพราะอะไรบางอย่างจึงทำให้นายเอทำงานช้า มากกว่า เช่น ทำงานช้าเพราะต้องรอ service เป็นต้น
• มี process ให้โหวต มีรายละเอียดเพิ่มเติม อ่านต่อที่หัวข้อ การทำ Retrospective ในช่วง WFH

a ดวง scrum process & planing

ทีม a ดวง จะมี sprint ละ 3 อาทิตย์ โดยจะมีส่วนที่เป็น sharing knowleage ในทีม และ zero estimate

สำหรับ designer จะทำงานล่วงหน้า developer 1 sprint โดย designer ทีมนี้ใช้ Figma นาจา และมีการระบุว่าทำใน sprint ไหน

และในการทำงานในรูปแบบนี้ จะต้องมีการคำนวณแรงงานคนในทีมเพื่อวางแผนงานใน sprint นั้นๆ ดังนั้นเราจะต้องลาพักร้อน ลากิจ ล่วงหน้านิดนึง (ส่วนลาป่วยก็ไม่น่าจะล่วงหน้าได้เนอะ แหะๆ) โดยจะลงไปใน calendar ของทีม และใช้ LINE Notify ในการแจ้งเตือนในแต่ละวันว่าวันนี้มีใครลาไหม เป็นการ summary (เนื่องจากทีมเราก็ใช้ Discord เหมือนกัน เดี๋ยวเราจะลองทำบอทใน Discord แบบนี้ดูดีกว่าเนอะ)

ตัวอย่างการใช้ Jira และรายละเอียดต่างๆ

ใน Jira จะมีโปรเจก 2 แบบ คือแบบปกติ กับแบบ next-gen ซึ่งก็ใช้แบบ next-gen กันเนอะ

• มี roadmap ใส่ epic ได้ว่างานส่วนนี้เราจะทำตอนไหน
• backlog แตกการ์ดให้ย่อยที่สุด (แต่ก็อย่าย่อยจนละเอียด ทีมเจอมาแล้ว ฮือออ) และเข้าเอา sprint มี point, status และระบุว่าอยู่ใน epic ไหน
• ใช้ story ใน epic แบ่ง success กับ fail case
• ใน story จะมี test case ที่ tester เขียนไว้ในส่วนของ checklist และการ์ดที่ fail จะเป็น subtask ใน story เพื่อให้การ์ดจบด้วยตัวมันเอง (ซึ่งทุกที่ tester ต้องเป็นคนเขียน test case มาให้เนอะ ซึ่ง developer จะเขียน test case ก็ตอนทำ unit test แหละค้าบ เพื่อให้มันครอบคลุมได้ให้มากที่สุด)
• discover scope ของที่ตกหล่นว่าต้องรีบแก้เลยไหม และไม่ควรเอาไปแทรกงานเดิม ถ้าไม่กระทบมาก เช่น พิมพ์ผิด ก็อาจจะแก้ได้เลย

การทำ Retrospective ในช่วง WFH

เดิมทีการทำ Retrospective นั้น ก็จะทำกันสุดท้ายเพื่อเป็นการจบ sprint เนอะ ทุกคนในทีมก็จะอยู่ในที่ที่นึง เขียน good bad try ลงใน post-it แล้วนำมาแปะบนกำแพง จากนั้นก็จะเริ่มไล่เลียงถามกันเนอะ เป็นการทบทวนตัวเอง ทบทวนทีมว่า sprint นี้เจออะไรมาบ้าง และปรับความเข้าใจกัน

แต่ในสถานการณ์ที่ Work From Home กันอยู่นั้น (หรือในทีมที่มีคน remote เข้ามาก็ตาม) เราจะกระทำกิจกรรมนี้แบบปกติไม่ได้ ดังนั้นต้องมี tool มาช่วย

บางคนใช้ Miro เนอะ มี template ทำ retrospective โดยเฉพาะเลย ตอนแรกนำเสนอในทีมแหละ แต่พี่บี ซึ่งเป็นหัวหน้าของเราน้าน บอกว่าทางทีม a ดวง ใช้ easy retro ซึ่งมี function ที่มากกว่าตรงที่สามารถเบลอการ์ดที่คนอื่นเติมเข้าไปได้ กันลอก, สามารถ map card ที่อยู่ในกลุ่มเดียวกัน หรือเหมือนกัน เข้ามารวมกันได้ และสามารถโหวตการ์ดใน bad และ try เพื่อนำไป take action ต่อได้ ใน sprint ถัดไปนั่นเอง

โดยการนำการ์ดที่ผ่านการโหวตอย่างเป็นประชาธิปไตยสูงสุด ที่นำมา take action ต่อ จะต้อง assign คนมาเพื่อ follow-up ดูว่า สิ่งนั้นถูกแก้ไปหรือยัง

ตัวอย่างการ์ดของทีมเราเอง แฮร่

และอันนี้ของทีมเรา เซนเซอร์ดีกว่า

ข้อเสียในความฟรีของมัน คือ ใช้ได้ฟรีแค่ 3 board ซึ่งแต่ละ sprint ก็ใช้ 1 board ดังนั้นจำใจต้องลบของเก่าออก 1 เพื่อเอาไปใช้ได้ต่อไป ฮือออออ

Q & A และอื่นๆที่นึกออก

• เรื่องการให้คะแนนการ์ด ทีม a ดวง ใช้ bot ใน discord ในการโหวตการ์ด โดยทุกคนจะต้องอยู่ใน voice room ที่ link กันกับห้องนี้ ของทีมเราใช้ async poker ก็คือหยิบการ์ดทั้งหมดมาให้คะแนน โดยรอบนึงได้มากสุด 30 การ์ด เมื่อให้คะแนนเสร็จหมดปุ๊ปก็มาคุยกันและให้คะแนนตามดุลยพินิจของฮิปโปในน้านนน

• มีใส่ release tag reversion ในแต่ละการ์ด เพื่อ track ได้ว่าถูกเทสผ่านที่ version ไหน ถูกบิ้วไปเมื่อไหร่ จะได้ย้อนกลับมาดูได้
• เรื่องโคลนการ์ดแยกระหว่าง iOS และ Android ทำได้ 2 วิธี คือโคลนดื้อๆเลย กับ import excel เข้ามา ซึ่งถ้ามีรูปมันก็ import ไม่มาอีก
• วันเริ่ม sprint แน่นอนว่าเราจะเริ่มและจบวันไหนก็ได แต่นิยมจบวันศุกร์ และเริ่มใหม่วันจันทร์ เพื่อให้มีเวลาพักผ่อนเนอะ จะได้ไม่เหนื่อยเกินไป
• แต่ละการ์ดจะมี design แนบอยู่ ถ้าใช้ Figma ก็ลง link ไป ของ Zeplin ก็แปะหน้าในการ์ดได้ ถ้าสนใจวิธีทำบอกน้า จะได้เอาไปเขียนบล็อกได้ อิอิ

ประสบการณ์การทำงานแบบ Agile ของเจ้าของบล็อก

ตอนทำงานที่แรกก็เป็น waterfall แหละ แต่พอบริษัทลูกค้าใช้ Agile ก็ใช้ตาม ต้องไปศึกษาเอาเอง แบบงงๆ

แต่ที่ใช้ Agile แบบสุดๆก็คือที่ Fungjai เนอะ ก็จะมีเปิด sprint เอา backlog ลง sprint ว่าเราต้องทำอะไรบ้าง บางทีถ้าวางก็จะมีให้ point กับการ์ดบ้าง และมี sprint refining ช่วงครึ่ง sprint ว่าทำไปครึ่ง sprint แล้วเป็นยังไงบ้าง ทำทันไหม จากนั้นพอหมด sprint ก็จะมีการทำ sprint review โดยการ demo ขิงกันระหว่าง iOS และ Android เอ้ยย งานที่ทำไปเป็นยังไงบ้าง และจบด้วย retrospective ลง post-it ก็จะมี good bad try และ thank ว่าขอบคุณใคร โดยจะรีบทำก่อนที่จะลงไป townhall แหะๆ

เอ้ออแล้วส่วน design เขาจะมีการทำ UX Research กันมาก่อนแล้วเป็นเดือนๆ พร้อมออกแบบ UI ซึ่งพองานลง sprint เราก็สามารถทำงานได้เลย ไม่ต้องรอ designer และ UI จะไม่ต้องปรับแก้อะไรระหว่างทางด้วย เนื่องจากมันต้องนิ่งก่อนที่จะถูกนำไป develop เนอะ

พอมาที่ Ookbee ทีมก็ใช้ Agile แหละ แต่อาจจะไม่ใช่ทุกทีมงี้ เช่น ทีมเก่า design ไม่นิ่ง developer ต้องคอยมาปรับแก้ มีงานแทรกระหว่าง sprint บ้าง พอทำงานระหว่างทีมก็จะเจอปัญหาในการทำงานกันหล่ะ พอมาทีมปัจจุบันก็ adapt จากทีม a ดวงด้วย มี grooming และ planing กันวันแรกของ sprint มี refining ตอนครึ่ง sprint และมี sprint review และ retrospective กันวันสุดท้ายของ sprint เนอะ

ซึ่งการ knowleage sharing ในวันนี้แต่ละคนที่เข้าก็น่าจะนำไปปรับใช้ในทีมได้เนอะ ก็ขอบคุณพี่ไอ๊ที่แชร์เรื่องนี้นะคะ คนเข้ามาเยอะมากๆ ทั้งทีม dev เองและมีทีมอื่นด้วยแหละ เห็นบางคนแบบไม่คุ้นจริงๆ หวังว่าทุกๆคนจะมีความรู้ความเข้าใจเกี่ยวกับ Agile ไม่มากก็น้อยเนอะ

สรุป Agile เป็นแนวคิด ไม่มีกฏตายตัว อยู่ที่ทีมจะตกลงและสื่อสารร่วมกันจ้า

ส่วนใครที่เจอ solution แนะนำ หรือ workๆ ก็สามารถแนะนำมาได้จ้า กิ๊งๆ~~

download แอพอ่านบล็อกใหม่ของเราได้ที่นี่

MikkiPastel - Apps on Google Play

First application from “MikkiPastel” on play store beta feature- read blog from https://www.mikkipastel.com by this application- read blog content by chrome custom tab- update or refresh new content by pull to refresh- share content to social network

Apps on Google PlayMikkiPastel Studio

ติดตามข่าวสารและบทความใหม่ๆได้ที่

และช่องทางใหม่ใน Twiter จ้า