Chúng tôi đã kết hợp Scrum với XP ra sao?

      Đồng hành cùng DEBIT đã được 2 năm, suốt chặng đường đó, tôi đã cảm thấy ấn tượng với sứ mệnh mà nhóm đặt ra: “Nâng tầm năng lực Debiter – những thợ săn miền đất Deha”. Sứ mệnh cao cả đó cũng chính là kim chỉ nam cho mọi hoạt động của nhóm. Các giá trị nhóm tạo ra được vận hành, chuyển giao liên tục nhằm đáp ứng kỳ vọng từ tổ chức, cũng như thị trường. Chúng tôi coi việc đạt được kỳ vọng không chỉ dừng lại ở một thành tựu, tại một vị trí hay trong một thời điểm mà nó phải luôn luôn cải tiến để thích ứng với những trạng thái bình thường mới của xã hội. Để đáp ứng kỳ vọng của ban lãnh đạo, của thị trường nghề nghiệp, X1969 – nhóm kiểm thử tự động đã ra đời nhằm nâng cao vị trí của Debit trong Deha, giúp Debit vươn cao và vươn xa hơn nữa. 

    X1969 là một nhóm gồm các thành viên ở nhiều ngành khác nhau (ngôn ngữ Nhật, kỹ thuật điện điện tử ….). Các thành viên nhóm với tư duy thuật toán còn hạn chế và kỹ năng xử lý khi gặp lỗi đôi khi còn lúng túng. TC chưa có kỹ năng quản lý nhóm, tổ chức các sự kiện Scrum, không biết cách định hướng cho team. Các thành viên cũng mới chỉ học qua lớp codeception của anh Trung Béo, biết và sử dụng được các hàm cơ bản nhất vì cũng không có nhiều thời gian thực hành thực tế. Một khởi đầu đầy khó khăn, nhiều khi bàn lùi nhưng nhờ sự chăm chỉ, cần cù chúng tôi đã cùng nhau trải qua 3 tháng gian nan ấy. Hiện tại thì trình độ, kỹ thuật của  cũng đã có cải thiện nhiều hơn so với trước. Team cũng hoạt động đúng theo khung làm việc Scrum, xác định được mục tiêu Sprint để tập trung, tổ chức đúng các sự kiện Review, Retrospective để cải tiến liên tục và đạt năng suất cao hơn. Vậy nhờ đâu mà chúng tôi có thể cải thiện được vậy?

     Trước khi quan tâm đến chất lượng thì một team phải thực hiện đúng quy trình. Phải làm sao để team cùng hướng tới một mục tiêu. Tôi đọc Scrum Guide, tôi hiểu rõ hơn các sự kiện Scrum, Scrum Artifacts,… Sau đó cũng nhờ sự giúp đỡ của anh Trung mà tôi đã giúp nhóm tổ chức được các sự kiện daily scrum, sprint planning, sprint review, sprint retrospective… Nhóm đi được một sprint, cũng đã tự xác định mục tiêu của Sprint và làm mọi cách để đạt được nó nhưng chất lượng còn chưa tốt lắm, kỹ năng vẫn vậy, code rác quá nhiều, tốc độ code không cải thiện là bao. Vậy làm cách nào để cải thiện chất lượng, hiệu suất và nâng cao kỹ năng? Đúng lúc này tôi được anh Trung giới thiệu cho cuốn Scrum và XP từ những chiến hào. Tôi đã nhận thấy trong team còn thiếu những kỹ thuật gì. Trong khi Scrum chỉ chú trọng vào các vấn đề quản lý và tổ chức thì XP lại quan tâm chủ yếu vào đến các phương thức thực hành lập trình trong thực tế. Để nâng cao chất lượng và cải thiện kỹ năng thì chắc là chúng tôi phải áp dụng thêm các kỹ thuật trong XP. Kết hợp khéo léo Scrum và XP thì biết đâu vấn đề của nhóm sẽ được giải quyết.

    Sách nói gì cũng hay nhưng không áp dụng thực tế thì cũng chưa thể chứng minh được nó hay như nào. Vậy là tôi quyết định áp dụng một vài kỹ thuật trong XP với nhóm để so sánh hiệu quả trước và sau khi áp dụng. Đầu tiên là việc áp dụng tiêu chuẩn mã nguồn, sở hữu mã nguồn tập thể. Cả team không theo hướng lập trình nên gần như không biết gì về mấy cái gọi là mã nguồn. Mọi người cứ thích tên nhánh, tên biến, tên hàm… như nào thì đặt như thế, thích code theo hướng nào thì code miễn sao code nó chạy. Sau sprint đầu code rác rất nhiều, chúng tôi phải mất một tuần để sửa chữa đống code ấy. Nguyên nhân không đâu khác, chính là do chúng tôi không có một quy ước chung nào về mã nguồn, không có mã nguồn tập thể. Trong buổi retro, cả team đã cùng ngồi lại với nhau và thống nhất mã nguồn, vấn đề được giải quyết. Nếu biết trước về tiêu chuẩn mã nguồn, mã nguồn tập thể thì chúng tôi đã có thể tiết kiệm được rất nhiều thời gian.

Buổi retreat đầu tiên thực hiện lập trình cặp kết hợp với phương pháp Pomodoro

    Khi mã nguồn đã được quy ước, mọi thứ được thực hiện đúng với những gì team đã cam kết nhưng kỹ thuật mọi người vẫn không hề tăng, chỉ giậm chân tại chỗ, không biết gì ngoài mấy hàm fillField, click, selectOption … Tôi nhớ đến buổi retreat trước đó, mọi người thực hành lập trình cặp, số test case viết được tăng lên nhiều, biết thêm một vài hàm khác từ những thành viên trong team. Thế là tôi lại tiếp tục áp dụng kỹ thuật lập trình cặp với team. Đầu tiên chỉ có một cặp là cặp ThaoKTP – CuongNH (dev master) áp dụng. Nhờ call trao đổi, chỉ ra lỗi sai và trực tiếp giải thích câu lệnh đó dùng như nào, có ý nghĩa như nào nên chỉ vài ngày sau đó, Thảo đã biết  nhiều hàm mới, biết thêm kiến thức về code JS, thậm chí có thể pair cùng các thành viên khác khi cần support. Với 1 bạn chuyên tiếng Nhật mà bây giờ có thể gọi là thành thạo về codeception thì đấy có thể coi một thành công lớn, một sự cố gắng không ngừng. Cứ thế triển khai với các thành viên còn lại, sau vài tuần pair cùng nhau, tinh thần làm việc của nhóm tăng cao, có khó khăn là được tháo gỡ kịp thời, chất lượng code tăng, mã nguồn tốt, khả năng truyền bá và học hỏi kiến thức từ người khác cũng nhanh chóng mặt. Tuy nhiên, bên cạnh những mặt lợi thì lập trình cặp cũng rất mệt mỏi, không nên thực hành suốt, tầm 3h là tốt nhất, cũng có người không thích pair cùng thì tôi cũng không ép buộc mà chỉ đưa ra vài lợi ích để có thể thay đổi suy nghĩ của họ. Ngoài ra chúng tôi còn có những buổi học coding dojo, cùng nhau chia sẻ kiến thức JS để dần dần có thể chuyển qua code JS, khắc phục những nhược điểm của codeception. Hơn nữa team cũng đã được áp dụng TDD, viết kiểm thử trước sau đó mới viết code, code khi build lên server phải pass test đã viết trước đó. Nhưng nó vẫn chưa được áp dụng triệt để vì require thay đổi, xpath của element thay đổi.

     Những gì chúng tôi đã áp dụng giúp đạt được mục tiêu của sprint, áp dụng automation thành công với 6 dự án, kỹ năng lập trình có tăng cao, giảm tỷ lệ bug degrade. Do 1 vài dự án đặc thù nên tỷ lệ áp dụng chưa được cao nhưng chúng tôi sẽ tiếp tục cố gắng để duy trì auto ở con số 60 – 80%. Ngoài những gì chúng tôi áp dụng thì vẫn còn rất nhiều các kỹ năng khác, thời gian chạy dự án X1969 mới được 3 tháng nên tôi chưa thể giúp team kết hợp hết các kỹ thuật. Nhưng chắc chắn trong thời gian không lâu, chúng tôi sẽ làm được điều đó bởi chúng tôi đã vượt qua vòng an toàn của mình, tiếp cận với auto thành công. Debiter chúng tôi sẽ cùng nhau cố gắng “Biến điều không thể thành có thể”, xây dựng một lại một Debit mới hơn, cao cấp hơn.

    Với những gì tôi chia sẻ ở trên thì chắc chắn nó không xa lạ gì với các team phát triển. Nhưng tôi vẫn chia sẻ vì đây là thành quả mà chúng tôi có được sau một thời gian cố gắng, nỗ lực, rèn luyện chăm chỉ. Đồng thời, trong một team hay một tập thể lớn, quy trình và chất lượng là 2 thứ phải đi song song với nhau thì tổ chức mới dễ quản lý, từ đó mà năng suất và chất lượng mới tăng.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *