#priwlearning Agile Development [SET]

คอร์สเรียน https://elearning.set.or.th/SETGroup/courses/833/info

• เราอยู่ในยุคของการผลิตซอฟต์แวร์
• คุณ Marc Andreessen บอกว่าซอฟต์แวร์กำลังกินทุกภาคส่วนของโลก (บทความนี้ผ่านมาแปดปีแล้ว)
• เมื่อก่อนบริษัทแบ่งเป็นแผนกๆ มีการทำงานเป็น Silo ซึ่ง IT ที่อาจจะเคยเป็นแผนกเล็ก ก็กลายเป็นแผนกใหญ่ ครอบคลุมทั้งองค์กร
• สิ่งที่ยากที่สุดของการทำซอฟต์แวร์คือ เราไม่รู้ว่าเราอยากได้อะไร (Software Crisis)
• Conway’s Law ระบบที่ถูกออกแบบขึ้นมาก็จะมีรูปร่างหน้าตาเหมือนการวางโครงสร้างการสื่อสารภายในองค์กร เช่น มีลำดับชั้นสูง = มี Feature ซ้ำกัน หรือ Feature ไม่เหมาะสมสำหรับการใช้งาน
• สิ่งที่ต้องมองเป็นหลักคือ ปรับองค์กรอยู่รอบ Value ที่ลูกค้าต้องการ (ที่เปลี่ยนไปเรื่อยๆ) คีย์สำคัญคือ ยุบลำดับชั้นขององค์กรให้บางสุดเท่าที่จะบางได้ เหลือเพียงแค่ คนดู Product Vision, คนดูแล Area ต่างๆ ที่ย่อยลงมา และทีมพัฒนา
• วิธีการทำงานที่เปลี่ยนไป คนทั้งองค์กรมีกิจกรรมที่เหมือนกันทั้งองค์กร เช่น วันที่หนึ่งจะวางแผนกัน แยกย้ายไปทำงานกันสองสัปดาห์ เอางานมารวมกัน ดูว่าของพร้อมแพ็คไปใช้งานไหม
• ถ้า Direction เปลี่ยน คนทั้งองค์กรจะได้ยินที่จังหวะเดียวกัน
• แบ่งทีมให้มาอยู่ด้วยกัน ไม่ได้แบ่งตาม Silo
• พนักงานมีความรู้ ความคิดที่สามารถตัดสินใจเองได้ คนทำงานเป็น Knowledge Workers
• Head of product group: ทำไมต้องทำสิ่งนี้ ทำเพื่ออะไร ลำดับความสำคัญเป็นอย่างไร
• ทีมพัฒนา: ทำอย่างไร ทำเท่าไหร่ในกรอบเวลาสองสัปดาห์

เคสตัวอย่าง

• ปัจจุบันมือถืออาจถูกเรียกว่า “โทรศัพท์มือถือที่มีล้อ”
• BMW มีอายุยืนยาวกว่า 100 ปี เป็นผู้นำในธุรกิจยานยนต์ ซึ่งพอรูปแบบเปลี่ยนจากฟอซซิลเป็นพลังงานไฟฟ้า องค์ความรู้สันดาปที่เคยมีเปลี่ยนไป BBW เลือกที่ละทิ้งแล้วใส่ความรู้ใหม่

• ยุคที่ 2–5 คือ Software
• และต้อง Release ออกไปให้บ่อยที่สุดเท่าที่จะบ่อยได้ (Continuous Delivery)
• จะออกของใหม่ได้เร็วๆ ก็ต้องปรับโครงสร้างองค์กรด้วย จากที่เคยมีชั้นหนามากประมาณ 7–8 ชั้น ใช้เวลาประมาณ​ 6 เดือนกว่าการสื่อสารจะลงมาถึงคนทำงาน BMW เลือกที่จะเปลี่ยนโครงสร้างองค์กร เหลือประมาณ 5 ชั้น คนทำงานเป็น Team-based
• ทุกทีมทำงานภายใต้เฟรมเวิร์ค ที่มีเวลาจำกัด เก็บของที่ต้องทำใน Product Backlog เรียงตาม Priority → PO ดึงชิ้นงานมาอธิบายใน Planning → ทีมทำงานสองสัปดาห์ → เอาของมาให้ PO ดูว่าใช่ที่อยากได้ไหม
• ทีมทำงานเป็น cross-functional จะไม่มีการแบ่งเป็นแผนก
• เมื่อก่อนใช้คนทำงานภายนอกเยอะมาก จาก customer provider เปลี่ยนเป็น campus ไม่ treat เป็น vendor แต่เป็น partner เอาคนเหล่านี้มาทำงานร่วมกัน ทำงานให้เสร็จ ไปทดลองใช้ เก็บข้อมูล วิเคราะห์ข้อมูล
• เห็น feedback loop เร็วขึ้น
• PO ไม่ต้องรอให้ CEO สั่งว่า direction จะเป็นยังไง ใน Area ที่ตัวเองดูแล สามารถตัดสินใจ ทดลอง bundle แล้วก็ release ได้เลย
• BMW สามารถออกของใหม่ๆ ได้ทุกปีเหมือนมือถือ
• การเปลี่ยนแปลงนี้มีข้อดีคือ เปลี่ยนได้เร็ว ส่งผ่านข้อมูลได้ไว คนทั้งหมดจะเห็นว่าทำไมต้องทำสิ่งนี้ สิ่งที่ทำส่งผลยังไงกับตลาด (ลูกค้า) วิธีการสื่อสารเข้มข้นขึ้น คนเข้าใจในทุกการเปลี่ยนแปลงที่เกิดขึ้น

เครื่องมือ

เล่าถึง 4 Agile Manifesto

1. Individuals and interactions over processes and tools — สิ่งสำคัญคือคน รู้ว่าลูกค้าหรือเพื่อนร่วมงานต้องการอะไร รวมถึงการสร้างทักษะให้ทีมที่กำลังพัฒนา Product
2. Working software over comprehensive documentation — ส่งของที่มีคุณค่าออกไปอย่างต่อเนื่อง balance การทำงานของแต่ละกิจกรรม
3. Customer collaboration over contract negotiation — การใช้ contract บีบบังคับกันทำให้การทำงานมันเลวร้าย เปลี่ยนเป็นการส่งมอบ Value กับลูกค้าให้บ่อยมากขึ้น เจอกันหน้ากันให้บ่อย เก็บ feedback กันให้บ่อย
4. Responding to change over following a plan — แผนระยะยาวที่เอาไว้ขอ budget ไม่สามารถเอามาทำ product ได้ ต้องฟังลูกค้า ฟังการเปลี่ยนแปลงของตลาดแล้วเอามาปรับเปลี่ยน

12 Principles

1. อะไรที่พิสูจน์แล้วว่าสิ่งนี้ลูกค้าอยากได้ เราจะทำ
2. PO จะไม่รีบด่วนตัดสินใจ จะตัดสินใจวินาทีสุดท้ายก่อนจะเริ่มทำงาน เพื่อ Deliver Value นั้น
3. ส่งเสริมให้ทีมยอมรับความเปลี่ยนแปลง การเปลี่ยนแปลงเป็นเรื่องธรรมชาติ
4. คนที่รู้ความต้องการของลูกค้า (business people) กับทีม ต้องทำงานใกล้ชิดกัน ก่อนโควิดเราเชื่อว่าต้องนั่งอยู่ในบริเวณเดียวกัน เดินหากันได้
5. สร้างสภาพแวดล้อมที่ปลอดภัยมากพอให้ทีมสามารถทดลองและล้มเหลวได้ในกรอบเวลาที่สั้น เพื่อให้ได้ความรู้จากการล้มเหลวนั้นแล้วเอามาปรับปรุงให้ดีขึ้นในรอบถัดไป
6. การสื่อสารของคนที่อยากได้ของกับทีมพัฒนา ให้เดินมาคุยกันแบบ Face2Face
7. วิธีการวัด progress คือ จำนวน features ที่ลูกค้าอยากได้ ที่ทำงานได้จริง
8. คนทำงานทุกคนควรทำงานในความเร็วที่คงที่ ไม่เร็วมากไปจน burnout หรือน้อยไปจนไม่มีอะไรทำ ทุกคนรู้ว่าตัวเองมีความสามารถในการ deliver งานได้มากน้อยแค่ไหน
9. สิ่งที่เรากำลังทำ ต้องมีการพักซ่อมดูแลปรับปรุงเพื่อให้ใช้งานได้เต็มที่ ไม่ใช่เอาแต่ผลิต โดยไม่ดูว่าของใกล้จะพังแล้วหรือยัง
10. อย่าเน้นจำนวนงานที่ทำ ให้เปลี่ยนเป็นทำงานน้อยลงแต่เสร็จมากขึ้น เช่น รับแปดแต่ไม่มีอะไรเสร็จ เปลี่ยนเป็น รับสี่แล้วทำเสร็จครบสมบูรณ์
11. สถาปัตยกรรม, Requirement, Design ให้ทีมเป็นคนตัดสินใจเลือกด้วยตัวเอง พัฒนาปรับปรุงไปเรื่อยๆ
12. ให้คนทำงานหยุดพิจารณากลับไปว่า ที่ทำมามีอะไรต้องปรับปรุงบ้าง ให้เค้าได้เลือกว่าเค้าจะปรับปรุงสิ่งไหน เพื่อให้เกิดการเรียนรู้ และทำให้ดีขึ้น

Retrospective คือการเชิญเพื่อนร่วมงานมาล้อมวง ในสภาพแวดล้อมที่ปลอดภัย แชร์ข้อสังเกตกันว่ามีอะไรต้องปรับปรุงบ้าง อะไรสำคัญสุดก็เลือกมาแก้ปัญหา (เลือกมาอย่างเดียว) จากนั้นก็ดูว่ามี Activity หรือ Practices อะไรที่เอาไปแก้ปัญหาได้ ตกลงร่วมกันว่าในอีกสองสัปดาห์ข้างหน้าเราจะแก้ปัญหานี้ พอจบรอบการทำงาน ก็มาทำสิ่งนี้อีก

ในบทเรียนยกตัวอย่าง Template ของ Sailboat

แล้วก็อธิบาย Practices ที่อาจนำมาช่วยแก้ปัญหาได้

• Standup meeting: sync up progress and problem ด้วยสามคำถาม
• Kanban board กับช่องมาตรฐานคือ To do / Doing / Done
• Timebox
• Retrospective
• Team capacity
• Co-located

อะไรมีประโยชน์เก็บไว้ อะไรที่เป็นภาระก็ไม่ต้องเก็บไว้

4P ในการ Transform องค์กร

1. Principles
2. Process
3. Practices
4. People

พอเรียนเสร็จก็จะมีแบบทดสอบเพื่อวัดความรู้ให้ทำ ซึ่งถ้าตั้งใจฟังก็ไม่ได้ยากอะไร

ขอบคุณคอร์สเรียนฟรีๆ จาก SET ค่ะ