ตัว Traditional หัวใจ Agility: เทคนิคเพิ่มความคล่องตัว ปูทางสู่ Agile Journey แบบเนียนๆ

parrkiid
KBTG Life
Published in
3 min readApr 1, 2021

หากใครคลุกคลีอยู่ในวงการพัฒนาซอฟต์แวร์มาซักระยะ มักจะมีประเด็นหนึ่งที่พบได้บ่อยๆ โดยเฉพาะในบริษัทที่มีอายุหลักสิบปีขึ้นไป (หรือไม่ถึงก็พบได้) คือความกระอักกระอ่วนระหว่างระบบการทำงานแบบเดิมและแบบใหม่ (ที่ไม่ค่อยจะใหม่แล้ว)

(หากใครเข้าใจความแตกต่างระหว่าง Traditional และ Agile แล้ว สามารถข้ามไปอ่าน Section ถัดไปได้เลยค่ะ หรือถ้าต้องการทบทวนมุมมองก็อ่านต่อได้เลย)

จากเดิม ที่เคยบริหารโครงการ (สำหรับพัฒนาซอฟต์แวร์) ซักตัวด้วยแผนงานแบบ Sequence Phase หรือมีอีกชื่อว่า Traditional ที่คนส่วนใหญ่จะรู้จักกันในชื่อ Waterfall Model การทำงานแบบนี้จะเปรียบเสมือนการวิ่งผลัด โดยมีเส้นชัยเป็นการพัฒนาซอฟต์แวร์เสร็จและปิดโครงการ แต่ละคนทำหน้าที่ของตัวเองให้ดี ใช้เวลาให้น้อยที่สุด วิ่งให้เร็ว ส่งไม้ให้ดี จากนั้นก็หมดหน้าที่ ยืนดูเพื่อนที่รับไม้ไปว่าวิ่งได้ดีหรือหกล้มไหม โดยเราจะเน้นทำตามที่วางแผนมาให้เนียนที่สุด

แต่ในการพัฒนาซอฟต์แวร์แบบนี้ ส่วนใหญ่เมื่อเราวิ่งเสร็จในส่วนของเราแล้ว เราจะไม่มีเวลามายืนดูค่ะ เพราะเราจะต้องไปรับไม้อีกอัน เพื่อเอาไปวิ่งในอีกเกมนึง แล้วถ้าทำบุญมาน้อยหน่อย กำลังวิ่งๆ อยู่ อิเกมส์แรกที่ส่งไม้ไปแล้ว ดันมีประเด็นต้องกลับไปวิ่งใหม่ สวัสดี…

ด้วยลักษณะการทำงานนี้ Output จะได้ออกมาตามที่ถูกสั่งตั้งแต่ก่อนเริ่มทำ อาจจะได้หรือไม่ได้ตามที่คิดก็ว่ากันอีกที (ไม่นับ Change กลางทางที่เหล่า IT มักจะ Suffer) และซอฟต์แวร์จะ Release ในตอนท้ายของโครงการ (เข้าเส้นชัย)

และด้วยการทำงานแบบเดิม… วันเวลาผ่านไป บางที่อาจจะเกิดเหตุการณ์ขึ้นเมื่อ 7–8 ปีก่อน หรือบางที่อาจจะเมื่อปีที่แล้วนี่เอง ใครซักคน (เป็นไปได้ทั้งส่วนงานบริหารและส่วนคนทำงาน) อยากจะเปลี่ยนเป็นแบบ Iterative and Incremental หรือชื่อที่ฮอตมากๆ คงหนีไม่พ้นคำว่า Agile

ถ้าให้อธิบายแบบสั้นๆ Agile จะเหมือนการเล่นฟุตบอลหรือบาสเกตบอลแบบทัวร์นาเมนต์ กล่าวคือเมื่อถึงเวลาเล่น ทีมจะลงเล่นด้วยกัน วิ่งไปมาพร้อมๆ กัน โดยอยู่ตามตำแหน่งที่ถนัด จำเป็นจะต้องเล่นเข้าขากันตลอดเกม เพราะมีจุด Touch Point กันบ่อยมาก แม้จะมีตำแหน่งหลัก แต่อาจมีสลับตำแหน่งกันบ้างตามสถานการณ์ แถมต้องอ่านเกมคู่แข่งตลอดว่ามาไม้ไหน ต้องปรับกลยุทธ์อะไรหรือไม่ และมีเป้าหมายเดียวกัน คือยิงประตู นอกจากนั้นยังต้องรู้จักวางแผนเพื่อยืนระยะให้ได้ตลอดทัวร์นาเมนต์ มีแผนที่วางมา แต่เน้นดูหน้างานและอาจปรับเปลี่ยนแผนทันทีเพื่อเพิ่มโอกาสชนะ ดังนั้นทีมต้องมีความพร้อมและความสามารถในการเปลี่ยนแปลงแบบปุบปับ

ด้วยการทำงานลักษณะนี้ Output ที่ออกมาอาจจะไม่ได้ตามแผนที่วางตอนต้น แต่อาจได้ตามแผนที่มีการปรับเปลี่ยนระหว่างที่พัฒนา เพื่อเพิ่มโอกาสบรรลุตามเป้าหมายที่ตั้ง หรือ Outcome มากขึ้น โดยมีตัวชี้วัด (การยิงประตู) ว่าที่ทำไปในแต่ละช่วงเวลาโอเคแล้วหรือควรปรับเปลี่ยน

การเปลี่ยนจาก Traditional มา Agile หากเริ่มจากส่วนงานบริหาร ส่วนใหญ่มักจะมาด้วยเหตุผลที่ว่าอยากได้ของที่เร็วขึ้น เพื่อเพิ่มโอกาสแข่งขันทางธุรกิจ หรือถ้าเริ่มจากคนทำงาน ก็มักจะเป็นเพราะไปเจอ Technical Practices อะไรบางอย่างที่ทำให้ชีวิตการทำงานในแต่ละวันดีขึ้น สนุกขึ้น ยืดหยุ่นขึ้น

ทั้งนี้ไม่ว่าจะเริ่มต้นมาจากคนกลุ่มไหนก็ตาม ระหว่างช่วงปรับเปลี่ยน (Transform) ความกระอักกระอ่วนที่ภาบอกไว้ตอนต้นมีมาเยือนแน่นอนค่ะ เพราะมันคือการตีลังกาคิด และการให้ Value ในคนละส่วนกัน ซึ่งเราหลีกเลี่ยงไม่ได้ ที่จะต้อง Unlearn และ Relearn เยอะมากๆ และแน่นอนว่าจะมีทั้งคนที่ต่อต้าน และคนที่ดึงดันอยากเปลี่ยนจาก 1 ไป 100 ภายใน X วัน หรือ X เดือน

จากประสบการณ์ที่ภาได้พูดคุยกับทั้ง 2 มุม และรวมถึงตัวภาเองที่เคยเป็นแบบหลัง (ตะบี้ตะบัน ฉันจะเปลี่ยน!) ด้วยความที่ภาโตมากับองค์กรที่พร้อมจะไป และเพื่อนร่วมทีมก็เป็นแบบคนฝนตกกองมารวมกัน จนกระทั่งทำงานไปเรื่อยๆ ได้พบเจอกับหลายวัฒนธรรม หลายกระบวนการ และพยายาม Empathy ด้วยการนำตัวเองไปลงงานแบบ Traditional

ภาพบว่า มันยากจริงค่ะคุณกิตติ!

ในหลายครั้ง โดยเฉพาะบริษัทใหญ่ๆ จะมีการจ้าง Consultant หรือ External Coach มากมายเพื่อเข้าไป “Transform” องค์กร และยัดคำว่า Agile เข้าไปในกลยุทธ์หรืออะไรอีกมากมาย แต่คนหน้างานจริงๆ แม้ใจจะอยากไปแค่ไหน ด้วยผลลัพธ์แบบเดิม ความเชื่อแบบเดิม และ Value แบบเดิมที่ยังให้ความสำคัญกันอยู่ ไหนจะทั้ง KPI / OKR ที่ค้ำคอ หรือจะเป็น Timeline, Charging Model, Process ที่ทำกันมานาน อีกทั้งทักษะของคน ทั้ง Hard Skill และ Soft Skill แล้วยังไม่รวมศัพท์แสงที่พยายามใส่ลงไปให้ทีม

แค่ฟังก็ดูเยอะมากแล้วใช่ไหมคะ เวลาภาเจอเองก็มึนมาก บอกตรงๆ 555 สุดท้ายก็ค่อยๆ ทำไปค่ะ ด้วยโจทย์ที่ได้รับสุดท้ายภาสรุปออกมาได้เป็น 7 ข้อที่อยากแชร์ให้อ่านกันตามนี้

1. Start with Understanding

สำหรับคนที่ไม่ได้อยู่กับทีมตั้งแต่ต้น เป็นคนใหม่ที่เพิ่งเข้ามาในทีมเพื่อรับหน้าที่นำทีมให้มี Agility มากขึ้น หากนึกอะไรไม่ออก ให้จับทุกอย่างแบออกมาก่อน ทุกอย่างเริ่มต้นที่ความเข้าใจค่ะ ถ้าในแง่ของศาสตร์โค้ชที่ต้องการพาผู้คนไปข้างหน้า นอกจากเป้าหมายแล้วนั้น ต้องเข้าใจสถานการณ์ปัจจุบัน (และอดีตบ้าง) หรือแม้กระทั่ง Consultant ที่เข้ามา ร้อยทั้งร้อย สิ่งแรกที่มักจะทำคือ Assessment พูดง่ายๆ ก็คือ ดูสภาพปัจจุบันก่อนเลย นอกจากนี้อีกสิ่งหนึ่งที่อยากไฮไลท์ คือการฝึกใช้การอธิบายเป็นภาพหรือ Diagram แทนการอธิบายเป็นคำพูดหรือตัวหนังสือยืดยาวค่ะ

ความท้าทาย

ทุกองค์กรมีศัพท์แสงและกระบวนการทำงานไม่เหมือนกัน ดังนั้นจำเป็นที่จะต้องหน้าด้านหน้าทน ล้วง แคะ แกะ เกา คลุกวงใน สัมภาษณ์ทั้งทางการ ไม่ทางการ แอบดู แอบสังเกต ดูลู่ ดูลม ใครเป็นใคร และจบที่ Confirmation อันนี้ขาดไม่ได้ เพราะถ้าเข้าใจโจทย์ผิด ก็เลือก Solution ผิดแน่นอน

2. Be Transparent

ไม่แปลกใจที่วัฒนธรรมเกี่ยวกับความโปร่งใสมักถูกชูขึ้นมาไฮไลท์เสมอๆ เพราะเป็นอีกเรื่องที่ขาดไม่ได้ หากต้องการได้ผลลัพธ์ข้อแรกอย่างเต็มที่ ซึ่งเรื่องนี้จะต้องมาพร้อมกับข้อแรก หากใครสงสัยว่าสำคัญยังไง? เปรียบเหมือนเราพยายามเข้าใจใครซักคน แต่เขาเอาแต่พูดโกหก เราก็คงไม่สามารถเข้าใจเค้าได้จริงๆ ทำอะไรก็ผิดไปหมด นอกเสียจากโชคดี แทงหวยถูกบ่อย ก็อาจจะยื่น Solution ได้ตรงพอดี

ความท้าทาย

เราไม่สามารถบอกทีมเราให้ Transparent ได้ ถ้าทุกครั้งที่อ้าปากบอกคือถูกตำหนิหรือไล่บี้ตลอดเวลา ทำให้รู้สึกตัวเล็กลงๆๆ จนสุดท้าย “ช่างแม่ง” แบบนี้น่ากลัวมาก วิธีการหนึ่งที่ภาได้เรียนรู้จากนายเก่า คุณทิวา อดีต CEO Kaidee คือ Lead by Example คุณทิวาคือ Leader ที่กล้ายกมือเมื่อทำผิด กล่าวขอโทษทีม และตนเองจะกล่าวคำขอบคุณทีมเสมอ เวลาที่ทีมกล้าพูดออกมา เพราะทั้งหมดทั้งมวลอยู่บนพื้นฐานความเชื่อว่าทุกคนหวังดีกับองค์กร และไม่ว่าจะพูดออกมาหรือไม่ สิ่งนั้นเกิดขึ้นแล้ว ดังนั้นการบอกออกมาและช่วยกันมองอย่างรวดเร็ว ย่อมดีกว่าการซ่อนปัญหาไว้จนบานปลายกลายเป็นมะเร็งขององค์กรแน่นอน

3. Encourage the Single Source of Truth

ในยุคที่มีการเปลี่ยนแปลงตลอดเวลาขนาดนี้ สิ่งสำคัญอย่างหนึ่งคือเรื่องของข้อมูลที่จะต้องอัพเดตกันให้ไวและทั่วถึง วิธีการที่ภาสนับสนุน (กึ่งบังคับทีม) คือให้ทุกคนสามารถเข้าถึงข้อมูลจากแหล่งเดียวกันให้มากที่สุด ลด ละ เลิก การส่งไฟล์ผ่านอีเมล์ (หรือแฟลชไดรฟ์!) เพื่ออัพเดตเวอร์ชั่นไปเรื่อยๆ เพราะแบบนี้จะมีปัญหาทันที เมื่อมีคนไม่ได้โหลดเวอร์ชันใหม่มาใช้ทำงาน แล้วต้องมาตามหาจุดต่าง จากนั้นก็มา Rework กันใหม่ มีแต่เสียกับเสียค่ะ นี่ยังไม่นับว่าไฟล์นั้นมีคนทำหลายคน ต้องมาตามหาอีกว่าใครทำตรงไหน แล้วเอามา Merge กันอีก

ความท้าทาย

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

4. Discuss with Visualization

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

ความท้าทาย

บางคน (โดยเฉพาะหนุ่มๆ) มักคิดว่าลายมือตัวเองไม่ค่อยสวย หรืออาจเข้าขั้นอ่านไม่ออก จนรู้สึกไม่อยากจับปากกาซักเท่าไหร่ ขอจับคีย์บอร์ดและเม้าส์เหมือนเดิมดีกว่า อันที่จริงรูปพื้นฐานที่เราใช้นั้นมีอยู่ไม่กี่อย่างเลยค่ะ สามเหลี่ยม สี่เหลี่ยม วงกลม ลากเส้น ลูกศร แต่ถ้าไม่ถนัดจริงๆ เดี๋ยวนี้เรามีเครื่องมือออนไลน์ที่ช่วยอำนวยความสะดวก และมีไอคอนให้เลือกใช้เต็มไปหมด ทั้งนี้อย่าลืมว่าจุดประสงค์คือเพื่อช่วยทำความเข้าใจ ส่วนเรื่องความสวยงาม เราค่อยให้ยอดฝีมือเสกขึ้นมาหลังจากได้ข้อสรุปแล้วก็ได้

5. Spread Project Management Skill to Everyone

คนมักจะพูดถึง Agile ในแง่ที่ว่าเราต้องเพิ่มอำนาจ (Empower) ให้กับทีม แต่ในบางสถานการณ์ ภาอยากเสนอให้ตั้งสติ แล้วเริ่มที่ตรวจทานว่าทีมเข้าใจและมีทักษะ Project Management เพียงใด ไม่ต้องถึงขนาดสอบได้ Cert หรือเก่งจนมาแย่งงาน Project Manager แต่แค่เข้าใจถึง Component ของโปรเจคว่าเราให้ความสำคัญกับมุมใดบ้าง และเราในฐานะสมาชิกของทีม นอกจากทำงานแล้ว ยังจะต้องจัดการงานตัวเองยังไงบ้าง การ Breakdown งาน จัดลำดับความสำคัญ รับผิดชอบตาม Commitment หรือยกมือเมื่อมีปัญหา หลายคนคงเคยได้ยินว่าคนหน้างานรู้ดีที่สุด ซึ่งภาก็เชื่อแบบนั้นค่ะ ดังนั้นถ้าเราติดทักษะบริหารงานให้เค้าไปด้วยก็จะดีมาก ซึ่งสิ่งนี้จะช่วยนำไปสู่ Empowerment และ Agility ต่อไปแน่นอน

ความท้าทาย

เรารู้กันดีว่าคนทำงานมักจะจมกับงานที่ทำจนไม่ได้เงยหน้า สิ่งที่ช่วยเขาได้คือการแบ่งงานเป็นชิ้นที่เล็กลง ทำให้งานเสร็จได้บ่อยขึ้น ทำให้เงยหน้าได้บ่อยขึ้น จากนั้นหยิบเรื่อง Visualization ขึ้นมา โดยอาจจะเอา Physical Tool หรือ Online Tool ผนวกไปกับจัดเวลา Catch up กันเล็กๆ เพื่อเปิดโอกาสให้ทีมได้อัพเดตกันเอง รวมถึงคนที่เกี่ยวข้อง ให้เห็นว่าใครทำอะไร ทับกันไหม ทั้งในส่วนกระบวนการงาน และปัญหาต่างๆ นอกจากจะช่วยเรื่อง Project Management แล้ว ยังช่วยให้เค้ามีความสุขกับชัยชนะเล็กๆ ด้วยค่ะ

6. Technical Skill is a Must

เราทำซอฟต์แวร์ค่ะ ห้ามลืม 5555 แม้ว่าเราจะพยายามวางทุกอย่าง แต่ถ้าเราไม่ปรับ Technical Practices เราก็จะไปไม่ถึงดวงดาว แถมพังกว่าเดิมแน่นอน ยกตัวอย่างง่ายๆ สุดคลาสสิค หากเป้าหมายของเราคือต้องการ Release Software บ่อยขึ้น แปลว่าเราต้องเตรียม Deploy และต้องทำ Regression Test บ่อยขึ้น ถ้าด้วยวิธีที่เราทำในปัจจุบัน ยังใช้เวลา Deploy ยาวนานตลอดคืน แถมมี Human Error เพียบ ไหน Testing Phase ของเรายังจะยาวนานและเจอ Defect มากมาย ถ้ายังไม่หาทางออกให้เรื่องพวกนี้ ก็นึกไม่ออกว่าเราจะสามารถ Release Software บ่อยๆ ได้ยังไง

ความท้าทาย

“งานก็ยุ่งจะตาย ไม่มีเวลาเรียนรู้เลย” เรามักจะมองว่าเวลาเป็นสาเหตุของปัญหา แต่เราสามารถทำให้ปัญหานี้เบาบางลงได้ด้วยการจัดสรรเวลาให้ดี ภามีพี่ชายคนหนึ่งเป็นเจ้าของเว็บ somkiat.cc ทำให้ภาตระหนักเรื่องนี้ว่าวินัยไม่ได้เกิดจากการให้เวลามาก แต่เกิดจากการให้เวลาสม่ำเสมอ และวินัยจะช่วยให้เราสามารถสร้างทักษะใหม่ๆ ได้เสมอค่ะ เช่น ทีมเดฟทีมหนึ่งเคยใช้เวลาก่อนเริ่มงาน 8:30–9:00 ฝึกทำโจทย์ต่างๆ กันด้วย เพื่อพัฒนาการคิด Algorithm หรืออีกบริษัทหนึ่งจัดให้มื้อกลางวันทุกวันพฤหัสบดีมีคนในทีมผลัดกันเตรียมความรู้ใหม่ๆ มาแชร์ทุกคน (บริษัทสนับสนุนอาหาร) ฯลฯ ทั้งหมดนี้เป็นเพียงตัวอย่างจากร้อยพันไอเดีย ภามั่นใจว่าทุกคนมีเวลาเพียงพอสำหรับการเรียนรู้อย่างแน่นอนค่ะ เพราะขนาดคุณกระทิง Chairman ของ KBTG ยังสามารถเรียนออนไลน์คู่ขนานไปกับการทำงาน (ที่ยุ่งมากๆๆๆ) จนจบหลักสูตรได้เลย นี่ยังไม่นับหนังสือที่อ่านปีนึงเป็นร้อยๆ เล่มอีกนะคะ สุดยอดจริงๆ แม่ทัพของเรา :)

7. Keep Calm and Take a Look Back

และข้อสุดท้ายซึ่งเป็นหัวใจสำคัญอย่างยิ่งยวด ไม่ว่าจะอย่างไรก็แล้วแต่ อยากให้เราหันมาให้ความสำคัญของการ “เช็คระยะ” กันเป็นช่วงๆ ค่ะ อย่ารอประเมินปลายปี เพื่อฟีดแบ็คกันทีเดียว หรือบางทีได้แค่ฟัง แต่ไม่ได้ถูกเปิดโอกาสให้พูดด้วยซ้ำ ลองนึกถึงการเป็นสามีภรรยาหรือการมีแฟนก็ได้ค่ะ คงไม่ใช่เรื่องสนุกและมีโอกาสเลิกราสูงแน่ๆ หากเราไม่เปิดใจพูดคุยกัน ย้ำว่า “พูดคุยกัน” หมายถึงได้พูดทั้ง 2 ฝ่าย ก็คือผลัดการเป็นผู้พูดและผู้ฟัง

สิ่งสำคัญของเรื่องนี้คือการเปิดโอกาสให้เราให้ลองพิจารณาเรื่องราวที่ผ่านมา หรือได้พูดถึงสิ่งที่พบที่เจอภายในระยะเวลาที่เรายังจำได้ จากนั้นได้แลกเปลี่ยนและหาทางออกร่วมกัน เพื่อให้เราสามารถเดินไปด้วยกันราบรื่นขึ้น ดีขึ้นเรื่อยๆ เพราะการไม่เคยย้อนกลับมามองและพูดคุยกันนั้นไม่ต่างอะไรกับการฝึกดีดกีต้าร์แล้วไม่ได้ยินเสียง เราจะไม่มีทางรู้เลยว่าสิ่งที่ทำไปดีหรือไม่ดี เพราะฉะนั้น เรามาเริ่ม “เปิดโอกาส” ให้ได้เรียนรู้และเป็นทีมที่ดีขึ้นเรื่อยๆ กันนะคะ

ความท้าทาย

Soft Skill ของคนรันกิจกรรมนี้สำคัญมากกก และการ Follow up หลังจบกิจกรรมก็สำคัญมากกกเช่นกันค่ะ ภาพบว่าหลายครั้งกิจกรรมนี้กลายเป็นการทะเลาะกันแทน เพราะเราไม่สามารถควบคุมอุณหภูมิและเรื่องราวที่พูดคุยกันได้ สิ่งหนึ่งที่ต้องเคลียร์ให้ชัดเจนคือเราไม่ต้องการหาคนผิดหรือโทษกัน แต่จุดประสงค์คือเพื่อการพัฒนาไปข้างหน้า หากเลี่ยงไม่ได้ที่จะถามหาคนทำ ควรพูดให้ชัดว่าเพื่อทำความเข้าใจสถานการณ์ ไม่ใช่เพื่อคาดโทษ และเมื่อจบกิจกรรม อย่าลืมหาเจ้าภาพในการแก้ไขหรือ Follow up แต่ละประเด็นจนสำเร็จลุล่วงนะคะ เพราะถ้าปล่อยลอยๆ แล้วไม่มีผลลัพธ์อะไรจากกิจกรรมนี้ คนก็ถอดใจ จากเดิมที่อาจท้อแท้คนเดียว กลายเป็นท้อแท้ทั้งคณะแทน

จะสังเกตว่า 7 ข้อข้างต้น ภาไม่ได้ใส่ศัพท์เฉพาะในโลก Agile ลงไปเลย แต่เป็นเรื่องทั่วไปที่สามารถทำความเข้าใจได้ แม้ว่าทีมเรากำลังทำงานเอนเอียงไปทางแบบ Traditional ก็สามารถนำเรื่องเหล่านี้ไปพิจารณาเพื่อค่อยๆ สอดแทรกความ Agile ลงไปในทีมแบบเนียนๆได้ค่ะ (กว่าจะรู้ตัวอีกที ก็อยู่บน Journey ของ Agile แล้ว) และภามั่นใจว่าทีมของเราจะค่อยๆ มีความคล่องตัวขึ้นเรื่อยๆ แล้ววันนึงเราอาจจะมี Agility ส่งมอบซอฟต์แวร์ออกไปสู่ลูกค้าได้ไวขึ้นและมีคุณภาพมากกว่าทีมที่ใช้คำว่า Sprint ซะอีกนะคะ ;)

สุดท้ายขอปิดด้วยการขาย 4 Core Values ต้นตำรับของคำว่า Agile กันหน่อย และหากใครสนใจ สามารถอ่านต้นฉบับได้ที่ URL ใต้รูป รวมถึง 12 Principles ที่จะช่วยซัพพอร์ต Core Values ได้นะคะ

จุดเริ่มต้น >> https://agilemanifesto.org/

บทความนี้ค่อนข้างยาวพอสมควร ถ้าอ่านจบถึงตรงนี้ ต้องขอบคุณมากๆ เลยค่ะ ภาพยายามกลั่นกรองออกมาเพื่อให้มุมมองและแชร์ประสบการณ์กับทุกคน และหากเป็นประโยชน์ได้ก็จะยินดีมากๆ นะคะ หากใครมีข้อสงสัยใดๆ สามารถสอบถามเพิ่มเติมได้ เผื่อเป็นไอเดียสำหรับบล็อกถัดไปของภาค่ะ :D

สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech

--

--

parrkiid
KBTG Life

ผู้หญิงในวิถีและวงล้อม Agile และ Software Development/ พี่สาวของน้อง / ลูกสาวของแม่ / สมาชิกครอบครัว SCK / ป้าของเกรียนส์ IT / Regional Agile Coach ของ KBTG