Ngày Đầu Vào Công Ty Phần Mềm, Không Ít Dev Mới Bối Rối Vì Một Cách Làm Việc Lạ Lẫm
Ngày đầu đi làm, một bạn học viên cũ của chúng tôi đứng hình khi nghe trưởng nhóm nhắc đến “sprint Agile”. Đó là ngay trong buổi họp sáng đầu tiên. Bạn ấy giỏi code, từng làm vài dự án cá nhân khá ổn. Nhưng chưa bao giờ nghe ai gọi công việc lập trình là một “sprint”. Cả buổi họp, bạn chỉ gật đầu. Bạn không hiểu vì sao mọi người đứng nói vài câu rồi giải tán. Đúng mười lăm phút là kết thúc.
Chuyện này không hiếm. Phần lớn công ty phần mềm ở Việt Nam hiện nay làm việc theo Agile. Có nơi gọi quy trình này là Scrum, có nơi gọi là Kanban. Nếu chưa từng nghe qua trước khi đi làm, bạn sẽ mất khá nhiều thời gian chỉ để đoán. Với dev mới, khoảng trống đó dễ khiến bạn ngại hỏi. Rồi bạn lặng lẽ làm sai quy trình, mà không ai kịp sửa.
Chúng tôi viết bài này từ góc nhìn của người từng đứng lớp cho hàng trăm bạn mới ra trường. Có bạn học rất giỏi thuật toán. Nhưng ngày đầu đi làm lại loay hoay, không hiểu vì sao task của mình cứ bị chia nhỏ. Hiểu Agile trước khi vào công ty, bạn sẽ tiết kiệm được đúng những ngày bỡ ngỡ ấy. Đây không phải chuyện khoe kiến thức. Chúng tôi chỉ muốn bạn đỡ mất sức vào những thứ lẽ ra nên biết trước.
Chúng tôi từng gặp một bạn xin nghỉ việc chỉ sau hai tuần thử việc. Lý do đưa ra là công ty làm việc thiếu tổ chức, hôm nay giao việc này, mai đổi việc khác. Sau này mới biết, bạn chỉ chưa hiểu vì sao việc chia theo sprint như vậy.
Agile Là Gì Và Vì Sao Nó Trở Thành Cách Làm Phần Mềm Phổ Biến
Nói dễ hiểu, Agile là cách làm phần mềm theo từng đợt ngắn. Thay vì làm một mạch từ đầu đến cuối rồi mới cho khách xem, đội ngũ chia nhỏ công việc ra. Mỗi đợt ngắn đó gọi là một sprint. Sprint thường kéo dài một đến hai tuần, tùy đội tự thống nhất. Có công ty chọn sprint hai tuần cho ổn định, có startup rút ngắn còn một tuần để ra bản mới liên tục. Không có con số bắt buộc, miễn đội thấy nhịp đó vừa sức. Hết sprint, đội ngũ có một phần sản phẩm chạy được, dù còn nhỏ. Phần đó đủ để demo cho khách xem và lấy phản hồi ngay lập tức.
Cách làm cũ, gọi là Waterfall, đi theo trình tự khá cứng nhắc. Gom hết yêu cầu, thiết kế toàn bộ, code toàn bộ, rồi mới test và giao hàng. Nghe có vẻ chặt chẽ. Nhưng phần mềm thực tế hay đổi yêu cầu giữa chừng, khách hàng đổi ý là chuyện thường. Làm theo Waterfall, đến lúc phát hiện sai hướng thì đã tốn quá nhiều công sức. Muốn quay đầu lúc đó cũng khó, vì mọi thứ đã làm gần xong. Agile sinh ra để giải đúng bài toán này. Làm từng phần nhỏ, xem phản hồi sớm. Sai thì sửa ngay ở sprint sau, không phải chờ đến tận cuối dự án mới biết.
Một Lần Đội Chúng Tôi Bắt Lỗi Sớm Nhờ Làm Theo Từng Sprint
Chúng tôi từng theo sát một đội làm ứng dụng đặt lịch cho phòng khám. Sprint đầu, đội làm màn hình đặt lịch, nhưng đặt sai vị trí nút xác nhận, người dùng thử bấm nhầm liên tục. Nhờ demo ngay cuối sprint, lỗi này lộ ra sớm, chưa kịp lan sang các màn hình khác. Sprint sau, đội sửa lại, đồng thời rút kinh nghiệm cho những màn hình còn lại trong backlog. Đó chính là ý nghĩa của việc cải thiện liên tục, thay vì chờ đến lúc ra mắt mới phát hiện sai.
Một vài từ bạn sẽ nghe suốt ngày, nếu làm ở đội theo Agile:
- Backlog: danh sách toàn bộ việc cần làm cho sản phẩm, xếp theo độ ưu tiên, việc quan trọng nằm trên đầu.
- Sprint: một đợt làm việc ngắn, có mục tiêu rõ ràng riêng cho đợt đó, không lẫn sang việc khác.
- Standup: cuộc họp đứng mỗi sáng, mỗi người nói hôm qua làm gì, hôm nay làm gì, đang vướng chỗ nào.
- Retrospective: buổi họp cuối sprint, cả đội nhìn lại việc gì nên giữ, việc gì cần đổi cho đợt sau.
Vai Trò Và Công Cụ Bạn Sẽ Dùng Chung Với Cả Đội
Trong một đội Agile, thường có thêm hai vai trò bạn nên biết sớm. Product Owner là người quyết định việc gì làm trước, đại diện tiếng nói của khách hàng trong đội. Scrum Master không phải sếp, mà là người giúp đội chạy đúng nhịp. Họ gỡ vướng khi ai đó bị chặn giữa sprint. Dev mới biết rõ ai giữ vai trò nào, sẽ biết nên hỏi ai khi gặp vấn đề. Thay vì hỏi lung tung cả nhóm, mất thời gian của mọi người.
Trong lúc chạy sprint, đội ngũ thường tách nhánh code riêng cho từng task. Xong việc thì gộp lại vào nhánh chính. Vì vậy, nắm chắc cách quản lý phiên bản code khi làm việc nhóm gần như là điều kiện đi kèm. Nó khó tách rời khỏi Agile trong thực tế ở công ty.
Vì Sao Nắm Cách Làm Này Trước Giúp Dev Mới Vào Việc Nhanh Hơn
Lý do đầu tiên rất thực tế: phỏng vấn. Không ít nhà tuyển dụng vẫn hỏi thẳng bạn từng làm Agile hay Scrum chưa, kể cả khi phỏng vấn vị trí fresher. Trả lời được vài câu cơ bản về sprint, về backlog, là đủ. Người phỏng vấn sẽ thấy bạn có chuẩn bị, chứ không chỉ biết code đơn thuần. Bạn không cần trả lời như đọc sách giáo khoa. Chỉ cần kể ngắn gọn: Agile là cách chia nhỏ việc theo từng đợt, làm xong sớm để nhận phản hồi, rồi điều chỉnh dần. Trả lời vậy vừa đúng, vừa cho thấy bạn hiểu bản chất chứ không học vẹt định nghĩa.
Lý do thứ hai nằm ở chỗ hòa nhập nhóm. Một đội đang chạy Agile có nhịp làm việc riêng của mình. Họp đầu sprint để chia việc, họp đứng mỗi sáng, demo cuối sprint. Nếu bạn không hiểu vì sao có những cuộc họp này, bạn dễ coi chúng là thủ tục rườm rà. Vô tình bạn tỏ ra thiếu hợp tác, dù không hề cố ý như vậy.
Hai Tình Huống Dev Mới Hay Vấp Khi Chưa Nắm Quy Trình
Chúng tôi từng mentor một bạn intern làm ở một công ty outsource nhỏ. Sprint đầu tiên, bạn được giao ước lượng “story point” cho một tính năng. Nhưng bạn chưa hiểu khái niệm này, nên áng chừng đại theo cảm tính. Kết quả, task bị trễ gần gấp đôi thời gian dự kiến. Cả sprint bị kéo lụt tiến độ theo, đội trưởng phải họp thêm để gỡ. Về sau bạn mới hiểu, story point không phải là số giờ làm việc. Nó là độ khó tương đối, so với các task khác đội từng làm qua. Hiểu đúng khái niệm này ngay từ đầu, bạn đã tránh được cả một sprint bị nhắc nhở giữa cuộc họp.
Một sai lầm khác dev mới hay mắc: nghĩ Agile nghĩa là “làm nhanh, khỏi cần tài liệu”. Đây là hiểu sai khá phổ biến, kể cả với vài bạn đã đi làm một thời gian. Agile không bỏ tài liệu. Nó chỉ ưu tiên trao đổi trực tiếp, và tài liệu gọn hơn so với cách làm cũ. Muốn tránh hiểu lầm này, bạn cứ hỏi thẳng đội trưởng ngay tuần đầu. Đội mình ghi chú yêu cầu ở đâu? Cập nhật task ở công cụ nào? Hỏi sớm một câu, đỡ phải đoán mò cả tháng trời sau đó.
Khi Cách Làm Này Áp Dụng Cho Dự Án Thật Của Khách Hàng
Nhiều công ty phần mềm hiện nay không chỉ làm sản phẩm nội bộ theo Agile. Họ còn nhận dự án cho khách hàng bên ngoài. Chẳng hạn dựng cả một hệ thống thiết kế website bán hàng chuyên nghiệp, rồi giao dần từng phần chức năng. Đội ngũ giao theo từng sprint, để khách xem và góp ý ngay trong lúc làm, không phải chờ đến lúc xong hết. Dev mới hiểu quy trình này sẽ hình dung được vì sao khách hàng luôn có mặt ở buổi demo cuối mỗi đợt. Chứ không phải chỉ đợi đến ngày bàn giao mới gặp lần đầu.
Nếu bạn đang ôn lại kiến thức nền trước khi ứng tuyển, việc này cũng đáng làm song song. Bạn có thể xem thêm phần nền tảng lập trình từ cơ bản đến nâng cao mà chúng tôi đã tổng hợp. Agile chỉ là cách tổ chức công việc. Kỹ năng code vững vẫn luôn là gốc, quy trình chỉ giúp cái gốc đó phát huy đúng lúc.
Điều Chúng Tôi Muốn Dev Mới Nhớ Trước Buổi Làm Việc Đầu Tiên
Đừng đợi vào công ty rồi mới học Agile qua loa, trong một buổi onboarding vội vã. Bạn hoàn toàn có thể tự áp dụng ngay, cho đồ án tốt nghiệp hoặc dự án cá nhân. Chia việc thành từng đợt một tuần. Tự đặt mục tiêu rõ ràng cho từng đợt đó. Cuối tuần tự hỏi mình đã làm được gì, chỗ nào cần đổi cách làm. Làm quen dần với nhịp này, khi vào công ty thật, bạn sẽ thấy quen chứ không lạ lẫm nữa.
Agile không phải một kỹ thuật lập trình. Cũng không phải thứ để khoe trong CV cho có. Nó là cách một đội ngũ cùng nhau làm sản phẩm, mà không bị lạc hướng giữa chừng. Dev mới hiểu được điều này trước khi vào công ty sẽ tự tin hơn hẳn trong tuần đầu. Hòa nhập nhanh hơn với đồng nghiệp xung quanh. Và quan trọng nhất, biết mình cần chuẩn bị gì cho từng chặng tiếp theo trong nghề. Muốn đi xa hơn, bạn có thể tham khảo thêm lộ trình học lập trình theo từng giai đoạn mà chúng tôi đã tổng hợp. Ở đó có gợi ý sau Agile thì nên học tiếp gì.