หลายๆ คนที่อยู่ในวงการ software development คงจะเคยได้ยินคำว่า agile กันแล้ว และหลายๆ คน คงบอกใครๆ แล้วว่า ทีมหรือบริษัทของเราได้ทำงานเป็น agile แล้ว
เวลามีคนมาบอกอย่างนี้ ผมมันจะถามต่อเสมอว่า
Agile ของคุณมีหน้าตาเป็นอย่างไร?
และคำตอบที่ได้ก็มันจะเป็น scrum ซึ่งผมก็มักจะถามคำถามต่อว่า
scrum ของคุณหน้าตาเป็นอย่างไร?
ก่อนอื่นเลย ผมอยากบอกคุณเหมือนกับที่หลายคนอาจจะบอกคุณแล้ว ว่า
Agile ≠ Scrum
ชั่งเรื่อง scrum ไปก่อน ผมมีวิธีเช็คง่ายๆ ว่าทีมหรือบริษัทของคุณเป็น Agile Team หรือยัง นั่น คือ กลับไปหารากของมัน คือ Agile Manifesto และ Agile Principle
Agile Manifesto
เป็นค่านิยม หรือ ผมเรียกมันว่า Goal Setting ของ Agile ซึ่งเราจะมองกัน 4 เรื่อง คือ
1.Individuals and interactions over process and tools
ใช่ครับ หลายๆ ที่เปิดมาข้อแรกก็แตกเลย ดันวิ่งไปหาเครื่องมือก่อนเลย แทนที่จะมาวิเคราะห์ว่า ทีมปัจจุบันเป็นอย่างไร กำลังเจอปัญหาเรื่องอะไร อะไรทำได้ดี อะไรยังทำไม่ได้
2.Working software over comprehensive documentation
ข้อนี้ง่ายๆ software จะต้อง ready to production เท่านั้น ในการทำงานจริงที่เจอมา ส่วนใหญ่ ทำไม่ได้
หนักกว่านั้น คือ ตัดเอกสารที่จำเป็นออกไปด้วย เช่น System Design, Database design API Documents สิ่งเหล่านี้สร้างปัญหาให้ในอนาคตเมื่อต้องเปลี่ยนมือคนทำ
ถ้าหากยังไปถึง production ไม่ได้ ก็ต้องกลับมาวิเคราะห์ดูหน่อยว่าทำไมทีมหรือบริษัทของเรายังทำไม่ได้
ส่วนเรื่องเอกสาร อะไรที่ไม่จำเป็นต้องทำก่อน หรือ ทำทีหลังได้ก็ยกไปทำทีหลัง หลังจากที่มั่นใจแล้วว่าสิ่งนั้นได้ไปต่อ
3.Customer collaboration over contract negotiation
ข้อนี้หลายๆ บริษัททำได้สบายมาก แต่ก็มีหลายบริษัทเหมือนกันที่มองว่าสิ่งเหล่านี้ไม่จำเป็น สิ่งที่เรามักทำผิดพลาดเสมอ คือ เราเลือกตัวแทนของลูกค้ามาผิด แน่นอนว่า คนที่มาจ้างให้เราทำ software คือ ลูกค้า แต่คนที่บอกว่า software ที่เราทำนั้นถูกหรือผิด คือ คนที่ใช้งานมัน
บ่อยครั้งที่พบว่า ตัวแทนลูกค้า มักจะให้ requirements ผิดพลาด เพราะฉนั้นข้อนี้ ควรบอกว่า Customer = Stakeholder = ทุกคนที่เกี่ยวข้องกับมัน คนจ้าง, หัวหน้า, และคนที่ต้องใช้งานมัน
4.Responding to change over following a plan
ข้อนี้ง่ายที่สุดแล้ว การทำ software ที่ใช้งานได้และตรงใจลูกค้าเป็นสิ่งสำคัญ เมื่อเราเจอว่าสิ่งที่ทำมันไม่ตรงกับความต้องการของลูกค้า ก็แค่ปรับเปลี่ยนมันให้ตรงกับที่ลูกค้าต้องการ
แต่เราต้องเข้าใจด้วยว่า การเปลี่ยนเปลี่ยนความต้องการของลูกค้า ส่งผลกับกรอบเวลาที่ต้องส่งมอบ หรือ สิ่งที่เราจะส่งมอบให้ด้วย ซึ่งสิ่งนี้ต้องสื่อสารให้ชัดเจน
Health Checks 4 ข้อแรกแล้ว ทีมคุณยังเป็น Agile หรือเปล่า?
บอกไว้ก่อนว่าทั้ง 4 ข้อนี้เป็นเป็น Goal กว้างๆ ที่ให้เราได้ focus ในการทำงานเท่านั้น วิธีการทำจริงๆ มันจะมีรายละเอียดมากกว่านี้
ดังนั้น เราไปต่อกันเลย
Agile Principle
ในเมื่อเรามี goal แล้ว Agile ไม่ได้ใจร้าย ที่จะบอกแค่นั้นแล้วให้เราไปหากันเอง เขาจึงสรุป สิ่งที่เรียกว่า วิธีปฏิบัติ (Principle) ให้พวกเราได้ทำตามกันไว้ด้วย ซึ่งมีทั้งหมด 12 ข้อ
ลองเช็คกันดูหน่อยว่า เรามีกี่ข้อกัน สำหรับผมมีทั้งหมดถือว่า ยอดเยี่ยม แต่ถ้าได้ 8-10 ข้อ ถือว่า โอเคแล้ว เพราะบางอย่างมันปรับทันทีไม่ได้
1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
แปลว่า เราให้ความสำคัญสูงสุดกับการสร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบซอฟต์แวร์ที่มีคุณค่าอย่างต่อเนื่องและรวดเร็ว
keyword: ความพึงพอใจ, ต่อเนื่อง, รวดเร็ว
ความพึงพอใจ
มัน คือ ส่งมอบสิ่งที่ตรงกับความต้องการจริงๆ ของลูกค้า ส่วนนี้เราจะมองได้ทั้งภาพระยะสั่นและภายปลายทาง
ภาพระยะสั่น คือ การส่งมอบแต่ละรอบการทำงาน ซึ่งขึ้นอยู่กับแต่ละบริษัท ลักษณะการทำงาน และความสามารถของทีมว่าใช้เวลาส่งมอบได้เร็วที่สุด คือ เท่าไหร่ ในระยะสั้น เราจะโฟกัสที่การหาความต้องการของลูกค้าจริงๆ ไม่ใช่แค่สิ่งที่ลูกค้าบอกในวันแรก
ภาพระยะยาว หรือ ปลายทาง คือ มองที่ปลายทางของโปรเจคนั้นๆ เลยว่า สิ่งที่ลูกค้าจะได้รับคือ software ที่ตรงกับความต้องการของลูกค้าจริงๆ ซึ่งมันอาจจะเป็นคนภาพกับตอนแรกที่ลูกค้าอยากได้เลย
2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
ยินดีรับการเปลี่ยนแปลงความต้องการ แม้กระทั่งในช่วงท้ายของการพัฒนา ในกระบวนการแบบ Agile ช่วยใช้ประโยชน์จากการเปลี่ยนแปลงเพื่อสร้างความได้เปรียบในการแข่งขันให้กับลูกค้า
keyword: ยอมรับความเปลี่ยนแปลง, สร้างความได้เปรียบ
ข้อนี้ตรงตัวเลย ปัญหาจากการทำงานแบบ waterfall (ที่ถูกทำให้กลายเป็นผู้ร้าย) คือ เราจะยึดตามเอกสาร requirements ตั้งต้น ว่าเราคุยกันแบบไหน โดยที่ปิดไม่ให้สามารถเปลี่ยนแปลงได้ แต่สำหรับ agile แล้ว เราโฟกัสไปที่ high value ได้ประโยชน์ หรือ ได้เปรียบ ที่ลูกค้าจะได้รับ
สิ่งที่ต้อง trade-off กับการยอมรับเปลี่ยนนี้ คือ การที่เราจะไม่สามารถส่งได้ทั้งหมดตามที่ตกลงกันไว้ หรือ อาจจะเป็นเวลาที่เพิ่มขึ้น ซึ่งสิ่งเหล่านี้ต้องสื่อสารให้ลูกค้ารับรู้และรับทราบ เพราะถ้าไม่มีการเทรดออฟเรื่องเหล่านี้แล้ว ทีมจะถูกกดดันให้ทำทั้งหมดให้เสร็จภายใต้กรอบเวลาที่เป็นไปไม่ได้ สุดท้ายก็จะหลุดจากสิ่งที่ agile ต้องเป็นนั้น คือ การส่งมอบ working software (ของที่ใช้งานได้จริงมีประโยชน์จริงๆ ไม่ใช้ส่งได้แต่ใช้ประโยชน์จริงไม่ได้)
3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
ส่งมอบซอฟต์แวร์ที่ใช้งานได้จริงอย่างสม่ำเสมอ โดยมีระยะเวลาตั้งแต่สองสามสัปดาห์ถึงสองสามเดือน โดยควรเลือกช่วงเวลาที่สั้นกว่าเป็นหลัก
keyword คือ working software, บ่อย และ สม่ำเสมอ
ปัญหาใหญ่ที่มันเจอในข้อนี้คือ เรามันเซ็ตกรอบการส่งมอบงานตาม คนอื่น โดยไม่ดีความสามารถของทีมหรือบริษัทตัวเองว่าจริงๆ แล้ว เราใช้เวลาเท่าไหร่ ถึงจะส่งมอบ working software ได้
working software คือ ของที่พร้อมใช้งาน ประเมินง่ายๆ คือ ถ้าทีมบอกว่างานเสร็จแล้ว ให้ลองถามไปเลยว่า จะเอาขึ้นให้ลูกค้าใช้เลยได้ไหม ถ้าคำตอบ ว่า ต้องเตรียมนู่น ต้องทำนี่ก่อน ยังขาดอันนั้นอันนี้ แปลว่า ยังไม่ใช่ working software
เพราะฉนั้น ไม่ต้องกังวัล ถ้าหากการส่งมอบ working software จะใช้เวลา 1 เดือน เพราะนั้นคือ ความเร็วที่ทีมของเราทำได้ และเราค่อยปรับปรุงให้เร็วขึ้นในอนาคต
4.Business people and developers must work together daily throughout the project
ฝ่าย business กับ ทีมพัฒนา จะต้องทำงานร่วมกันทุกวันตลอดโครงการ ข้อนี้เป็นอะไรที่ง่าย แต่หลายๆ บริษัทก็ทำกันไม่ได้ เนื่องจากโครงสร้างองค์กร
keyword: ทำงานร่วมกัน, ทุกวัน
หลายๆ ครั้งที่เรามักจะเจอสถานะการณ์ตีกันระหว่าง business ที่อยากทำอะไรบ้างอย่าง กับ ทีมพัฒนา ที่พยายามบอกว่า มันทำไม่ได้
ปัญหานี้จบลงง่ายๆ ด้วยการมาคุยร่วมกัน และกำหนดเป้าหมายร่วมกัน
ซึ่งเราต้องยอมรับก่อนว่า
- business ไม่ได้เข้าใจ system ดีเท่าทีมพัฒนา
- ทีมพัฒนา ไม่ได้เข้าใจ business ดีเท่าทีม business
ดังนั้นการแชร์มุมมองของแต่ละฝ่ายร่วมกันจะทำให้การทำงานมีประสิทธิภาพมากขี้น
บางช่วงบางเวลา bussiness อาจจะทำ technical บางเวลา technical อาจจะนำ bussiness เราถึงจะได้ทีมและผลิตภัณฑ์ ที่ตรงกับความต้องการและใช้งานได้จริง
ข้อควรระวัง: พยายามอย่าให้ฝ่ายใดฝ่ายหนึ่งถืออำนาจเหนือกว่า เพราะมันมักจะกลายเป็นสั่งงานอีกฝ่ายหนึ่งแทน ถ้าอีกฝ่ายไม่มีปากเสียงด้วยแล้ว ข้อนี้จะเกิดขึ้นไม่ได้เลย
5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
สร้างโปรเจคโดยใช้บุคคลที่มีแรงจูงใจเป็นหลัก มอบสภาพแวดล้อมและการสนับสนุนที่พวกเขาต้องการ และไว้วางใจให้พวกเขาทำงานให้สำเร็จ
keyword: แรงจูงใจ, สภาพแวดล้อม, เชื่อใจ
ข้อนี้มันเป็นเรื่องของ trust ของทีม โดยทั่วไปแล้ว หากเรามีทีมที่ไว้ใจได้ เรามักจะไม่ค่อยลงไปจัดการอะไรมาก และเรามักจะได้งานที่ดีออกมา
แล้วปัญหาส่วนใหญ่ มักเกิดจากการที่ทีมไม่สามารถสร้าง trust ให้ได้ ซึ่งมักเกิดจากการไม่สื่อสารสิ่งต่างๆ ให้กัน เช่น ปัญหาและอุปสรรคที่เจอ ความเสี่ยง หรือ feedback ต่างๆ
การที่ทีมขาด trust จะทำให้เกิดการ micro manage จากทาง bussiness ขึ้น และเมื่อมันเกิดขึ้นแล้ว มันจะกลายเป็นการตามงานในทันที และมันจะกลายเป็นสภาพแวดล้อมที่กดดัน แล้วแรงจูงใจจะหายไป
6.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
วิธีการถ่ายทอดข้อมูลที่มีประสิทธิภาพและประสิทธิผลมากที่สุดทั้งภายใน และ ภายนอกทีมพัฒนา คือ การสนทนาแบบตัวต่อตัว
keyword: ถ่ายทอดข้อมูล, face-to-face
ยอมรับเถอะว่า หลายๆ บริษัทที่ปรับมาให้พนักงานกลับไปทำงานแบบ on site ส่วนหนึ่งเป็นเพราะการสื่อสารที่ตกหล่น ไม่มีประสิทธิภาพ
การส่งต่อข้อมูลต่างๆ ที่มีประสิทธิภาพที่สุด คือ การคุยกันต่อหน้า เพราะมันสามารถสื่อสารได้ตลอดเวลา และคนอื่นๆ รับรู้ไปพร้อมกัน ต่อให้ไม่ได้เกี่ยวก็ตาม (กด mute ไม่ได้)
อีกอย่าง การสือสารด้วยการพูด ดีกว่า การพิมพ์อยู่แล้ว เพราะเราจะได้รายละเอียดที่มากขึ้น และคุยกันหลายๆ ประเด็น การพิมพ์นั้นมักจะทำให้เราคิดไปคนละทางกันได้ และมักตกหล่นรายละเอียดเล็กๆ หน่อยๆ เสมอ รวมถึงเสียเวลาอธิบายข้อความที่พิมพ์ไปอีกด้วย
7.Working software is the primary measure of progress
ซอฟต์แวร์ที่ใช้งานได้จริง คือ ตัวชี้วัดความก้าวหน้าที่สำคัญที่สุด
keyword: ตัวชี้วัดที่สำคัญ, ใช้งานได้จริง
agile ให้ความสำคัญกับข้อนี้มาก สังเหตุได้ว่ามันจะแทรกอยู่ในหลายๆ ข้อเลย
โดยทั่วไปแล้ว เรานิยามคำว่า งานเสร็จ ไว้ยังไง เวลาที่ทีมพัฒนาบอกว่างานเสร็จ มันหมายถึง งานของเขาเสร็จ, งานของทีมเสร็จ หรือ งานขึ้นไปให้ลูกค้าใช้งานแล้ว
ถ้าหากงานเสร็จ หมายถึง การเขียน code เสร็จแล้ว สิ่งนี้ไม่อาจเรียกว่างานเสร็จได้ เพราะเมื่อถึงวันที่ต้องเอาไปให้ลูกค้าใช้งาน ทีมก็จะถูกดึงกลับมาให้เอางานชิ้นนั้นขึ้น production ซึ่งเป็น task สุดท้ายของ features นั้น ดั้งนั้น ไม่จะเรียกว่า งานเสร็จไม่ได้ ในเมื่อเรายังต้องกลับมาทำมันให้เสร็จจริงๆ
8.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
กระบวนการแบบ Agile ส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุน ผู้พัฒนา และผู้ใช้ควรจะสามารถรักษาจังหวะการทำงานที่คงที่ได้ตลอดไป
keyword: ความยั่งยืน, รักษาจังหวะ
ปัญหาที่พบในการพัฒนา software ส่วนใหญ่ คือ เรามักจะเจองานเร่งเข้ามาเป็นระยะๆ หลายๆ ที่อาจจะเจอแต่งานเร่งเลยก็ว่าได้
ซึ่งเมื่อเจอสถานการณ์นี้ ทุกๆ ทีมมักเข้า โหมดเอาตัวรอด (ผมเรียกมันว่าอย่างนั้น) เพราะทุกคนจะละทิ้ง process ละทิ้งความละเอียด ละทิ้งการวางแผน เปลี่ยนเป็นการปั่นให้มันเสร็จ ทั้งๆ ที่เราควรจัดการให้มันอยู่ในจังหวะของเราและบริหาร scope แทน
สิ่งที่ต้องระวัง คือ ทีมมักจะถอดสมองแล้วทำงานตามสัญชาติยาน ซึ่งสิ่งที่นำมาซึ่งความผิดพลาดและผลลัพธ์ที่ส่งผลไม่ดีแก่ลูกค้ารวมถึงคนในทีมได้
9.Continuous attention to technical excellence and good design enhances agility
การให้ความสำคัญอย่างต่อเนื่องกับความเป็นเลิศทางเทคนิคและการออกแบบที่ดีจะช่วยเพิ่มความคล่องตัว
keyword: การให้ความสำคัญกับ technical และ design
ปัญหาใหญ่ๆ ที่หลายๆ ที่เจอคือ เมื่อเราทำงานเป็นรอบสั้นแล้ว เรามักเจอปัญหาเรื่องของการออกแบบไม่ทัน และสิ่งที่หลายๆ ทีมทำ คือ การตัดมันทิ้ง และให้คิดไปทำไป ซึ่งสิ่งที่ได้มา คือ software ที่ใช้งานได้ (มั้ง) และ technical dept
แน่นอนว่าในช่วงต้นของโปรเจค เราจะไม่เห็นผลกระทบตรงนี้เท่าไหร่ แต่เมื่อเวลาผ่านไป เราจะพบว่า การจะเพิ่มอะไรสักอย่างเข้าไป มันทำได้ยากขึ้น เช่น
"จะเพิ่มอันนี้ ต้องไปแก้ตรงนั้นก่อน "
"จะทำอันนี้ ทำไม่ได้ ระบบไม่ได้ออกแบบมาให้ทำอย่างนั้น"
และ ประโยคอื่นๆ อีกมากมาย ที่ทำให้เราทำงานได้ช้าลง
10.Simplicity–the art of maximizing the amount of work not done–is essential
ความเรียบง่าย เป็น ศิลปะแห่งการลดปริมาณงานที่ไม่ต้องทำ และ เป็นสิ่งสำคัญยิ่ง
keyword: ความเรียบง่าย, ศิลปะ, การลดปริมาณงาน
โดยทั่วไปแล้ว ในการทำโปรเจคหนึ่งตัว มักมี want อยู่เสมอ เช่น อยากให้มีลูกเล่นอย่างนั้น อยากให้มีการเก็บอันนี้เพื่ออนาคต เป็นต้น
สิ่งเหล่าน้ี แทบจะไม่จำเป็นเลย สำหรับ software ที่เรายังไม่รู้เลยว่าจะมีคนใช้งานจริงหรือเปล่า (ถ้ายังไม่มีคนใช้งาน)
ดังนั้นในช่วงแรกของการพัฒนาเราควรโฟกัสไปที่ working software ก่อน ที่จะไปสนใจ want ต่างๆ ที่อยากจะให้มันมี
แน่นอนว่า สิ่งนี้ไม่สามารถใช่ pattern เดียวกันทั้งหมดได้ มันเลยบอกว่าเป็นศิลปะยังไงละ
11.The best architectures, requirements, and designs emerge from self-organizing teams
สถาปัตยกรรม ความต้องการ และการออกแบบที่ดีที่สุด มักเกิดขึ้นจากทีมที่จัดการตนเองได้
keyword: ทีมที่จัดการตัวเองได้
ข้อนี้ง่ายๆ เลย ถ้าหากทีมของเราไม่สามารถตัดสินใจอะไรเองได้ ออกแบบงานเอง คิดเอง หรือ เลือกหยิบงานเองไม่ได้ ก็จบแล้ว
การที่ต้องมีใครสักคนต้องมาค่อย assign งานให้ ต้องมาลงรายละเอียดงานให้ มันเป็นทีมที่ไม่มีประสิทธิภาพ และโดยทั่วไปเมื่อทีมเป็นแบบนี้ trust ของทีมก็จะน้อยลง
การที่ทีมคิดเองไม่เป็น ไม่พูด ไม่ต่อรอง ไม่สื่อสาร รับงานมาทำอย่างเดียว ไม่ส่งผลดีกับผลิตภัณธ์และบริษัทเลย
เพราะเราจะขาดคนช่วยคิด ช่วยบริหารจัดการงาน และขาดความเชื่อใจกันและกัน
12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
ทีมงานจะทบทวนวิธีการทำงานให้มีประสิทธิภาพมากขึ้นเป็นระยะ จากนั้นจึงปรับปรุงและแก้ไขพฤติกรรมให้เหมาะสม
keyword: ทบทวน, ปรับปรุง
การทบทวนและปรับปรุงการทำงานจะช่วยให้เราลดข้อผิดพลาดของงานและช่วยเพิ่มความสามารถในการทำงานให้ดีขึ้น
หลายๆ ที่เอากิจกรรม retrospective มาใช้ แต่ทีมไม่ได้ปรับปรุงอะไรเลย สิ่งที่ผิดพลาดก็ยังผิดพลาดอยู่ สิ่งที่เป็นปัญหาก็ไม่ได้แก้ หรือที่เลวร้ายที่สุด คือ ทุกคนมองว่าทีมทำได้ดีแล้ว ทั้งๆ ที่การส่งมอบงาน มีปัญหาเต็มไปหมด
เพราะเฉพาะลองเช็คทีมของคุณดูว่าเป็นอย่างนั้นหรือเปล่า ถ้าใช่แสดงว่า คุณกำลังทำแค่พิธีกรรม ไม่ได้ปรับปรุงการทำงานจริงๆ
เอาหละจบทั้ง 12 ข้อแล้ว ได้กี่ข้อกัน แล้วแต่ละข้อทำได้ดีที่สุดแล้วหรือยัง หรือแค่มี แต่ยังไม่ได้เท่าที่ควรจะเป็น
หากยังไม่ดีเท่าที่ควรจะเป็นคุณก็เอาสิ่งนั้นไปปรับปรุงให้มันดีขึ้น ค่อยๆ ทำ ค่อยๆ ปรับ แล้วเราจะได้ทีมที่เป็น agile ตามที่เราคาดหวังไว้
Agile ไม่ใช่ Process หรือ เครื่องมือ อะไรทำนองนั้น จริงๆ แล้ว Agile เป็นเพียง Badge ที่บอกว่า ทีมของคุณเป็นทีมที่มีประสิทธิภาพที่สุดหรือยัง โดยทีมสามารถทำตาม checklist เหล่านี้ได้