เคยตกอยู่ในสถานการณ์ที่คนในห้องประชุมเถียงเรื่องเดียวกันติดต่อเป็นระยะเวลา 30 นาทีแล้วไม่ไปไหนไหมครับ?

ส่วนใหญ่ที่ผมเจอ มักจะเป็นเรื่องของ Technical Design ว่าจะไปในทิศทางไหนดี ซึ่งเราก็รู้กันว่าการ Design มันเป็นเรื่องของการ Trade-off หลายๆครั้งมันยากมากที่จะตอบว่าแบบไหนดีกว่า

การตัดสินใจเรื่องนี้ส่งผลกระทบในระยะยาว จึงต้องพิจารณาให้รอบคอบ แต่บางครั้ง เราก็จะเจอสถานการที่คนสองคน(หรือทีมแตกเป็นสองฝ่าย)เถียงกันไม่จบเสียที วนกลับมาประเด็นเดิมซ้ำๆ แย้งกันไปมา ไม่ไปไหน

ยิ่งถ้าประชุมก่อนพักเที่ยง ผมจะหิวข้าว ไปกินข้าวสายนี่ไม่โอเคเลย เรื่องกินเรื่องใหญ่

วันนี้ผมมีวิธีมานำเสนอ ไม่รับประกันว่าได้ผลตลอด แต่เท่าที่ใช้มานี่ได้ผลดีมาก ช่วยให้ผมไม่ต้องไปกินข้าวสายได้หลายครั้ง

สำหรับวีดีโอนี้ เราจะมาคุยกันเรื่องการ Deploy ระบบแบบให้มี High Availability คือผู้ใช้จะต้องสามารถใช้งานระบบของเราได้ตลอด และไม่ได้รับผลกระทบใดๆ เช่น ระบบช้าผิดปกติ หรือบาง Request ผิดพลาด

ส่วนแรกของวีดีโอจะคุยกันว่าระบบล่มเวลา Deploy ได้อย่างไร และส่วนที่สองจะอธิบายเรื่องการ Deploy แบบต่างๆและข้อดีข้อเสียของแต่ละแบบ

เมื่อวันก่อนมีน้องที่เป็น Project Manager โทรมาขอคำแนะนำเรื่องจะจ้างโปรแกรมเมอร์ใหม่เข้าทีม

แต่ความท้าทายคือในทีมไม่มีใครที่มีประสบการณ์เรื่องเขียนโปรแกรมเลย จะคัดเลือกคนยังไงดี

หลังจากคุยเสร็จ ก็รู้สึกว่านี่เป็นปัญหาสากลที่น่าจะมีหลายๆคนเจออยู่ แม้แต่คนที่เขียนโปรแกรมเป็น ถ้าต้องคัดเลือกคนที่ในด้านที่เราไม่มีทักษะทางด้านนั้นๆ (เช่น เขียน Frontend เป็นหลัก แต่ต้องช่วยทีมจ้าง Backend Developer หรือ Infra) เรื่องนี้ก็น่าจะยากอยู่ ยิ่งถ้านึกภาพว่าผมต้องไปสัมภาษณ์งานเพื่อคัดเลือกจ้าง Project Manager ผมเองก็คงไปไม่ถูกเหมือนกัน

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

ก็เลยเป็นที่มาของบทความนี้ครับ

ช่วงสองปีที่ผ่านมา แนวคิดหนึ่งที่ผมจับตาดูอยู่คือเรื่องของ Serverless

ตามชื่อเลย Serverless คือไม่มีเซอร์เวอร์ ซึ่งจริงๆแล้วเซอร์เวอร์ก็ไม่ได้หายไปไหน เพียงแต่ทีมพัฒนาไม่ต้องสนใจมันเหมือนแต่ก่อนแล้ว

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

ผ่านมาสองปี รู้สึกว่าเริ่มเข้าที่เข้าทางมากขึ้น จึงพึ่งได้เอามาใช้ทำโปรเจ็คจริง เลยเอามาเล่าสู่กันฟังครับ เผื่อใครอยากจะลองเอาไปใช้กัน

ผมรู้จักกับ Agile (อไจล์) เมื่อสิบกว่าปีที่แล้ว ตอนนั้นก็ไม่รู้หรอกว่ามันจะป๊อบขนาดนี้ สมัยนั้นอย่าพูดถึงอไจล์เลย ทีมไหนทำ Unit Testing ก็ถือว่าหรูแล้ว

ฝั่ง UK จะออกเสียงว่า อา-ไจล์, ฝั่ง US จะอ่านออกเสียว่า แอ-ไจล์ ในบทความนี้จะขอใช้ทับศัพท์ว่าอไจล์ซึ่งเป็นที่นิยมใช้กันนะครับ – https://dictionary.cambridge.org/pronunciation/english/agile

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

ผมเชื่อว่าผู้บริหารระดับสูงที่กล้าจะเลือกใช้อไจล์นั้นมีวิสัยทัศน์ที่ดี แต่เวลาปฏิบัติจริง ผมกลับเห็นว่าหลายที่ได้ผลลัพธ์เละเทะมาก สุดท้ายก็มาจบลงที่ว่าอไจล์ไม่ดี หรือไม่เหมาะกับองค์กร (ซึ่งก็อาจจะเป็นไปได้) หรือบางที่ก็เลือกที่จะซุกปัญหาไว้ใต้พรม แล้วทำ KPI ให้ดูสวยๆว่าผลลัพธ์ออกมาดี

สุดท้ายกลายเป็นตราบาปให้กับอไจล์ เป็นแผลเป็นให้กับพนักงานในบริษัท ที่ขยาดทุกครั้งที่ได้ยินคำนี้

ผมเลยอยากเขียนบทความนี้ไว้ให้ผู้บริหาร และหัวหน้าทีมพัฒนา (Technical Lead/ Team Lead) เพราะทัศนคติที่ถูกต้องต่ออไจล์จะส่งผลกระทบต่อการรับอไจล์เข้ามาในองค์กรมาก

บทความนี้จะพูดถึงข้อแนะนำ และตัวอย่างกรณีที่ดี/ไม่ดีแบบต่างๆ ในการนำอไจล์เข้ามาในองค์กร โดยผู้เขียนอนุมานว่าผู้อ่านรู้จักอไจล์และ Scrum แล้ว หากใครที่ยังไม่เข้าใจคำพวกนี้ แนะนำให้อ่านบทความอื่นก่อนครับ