7LAB sử dụng JIRA để tối ưu quy trình như nào?
Giới thiệu
Kể từ thời điểm bắt đầu là 3 năm trước, bọn mình đã sử qua nhiều Software Development Tool khác nhau từ Visual Studio Team Services, Trello, Pivotal Tracker và JIRA.
Visual Studio Team Services hay bây giờ đã được đổi tên thành Azure DevOps: Thời điểm bọn mình dùng thì nó còn khá sơ khai, các chức năng hơi khó sử dụng. Hơn nữa, bọn mình không có sử dụng thêm các service khác của MS nên không phát huy hết sức mạnh từ hệ sinh thái của nó.
Trello: Quá basic, không đủ đáp ứng được với dự án lớn như 7-Eleven khi số lượng ticket lên đến hàng trăm, hàng ngàn.
Pivotal Tracker: Một tool thiết kế cho team sử dụng Agile/Scrum thuần túy. Nó có đầy đủ chức năng cơ bản để sử dụng cho một team nhỏ, dự án ngắn. Điểm mạnh của nó là có đầy đủ chức năng để giúp một team đi theo Process chuẩn mực nhưng điểm yếu là nó rất khó để tùy chỉnh để phù hợp với từng team. Và hơn nữa, nó … xấu 🤣 j/k.
Qua nhiều lần thay đổi, thảo luận lẫn cả tranh cãi và cuối cùng, JIRA và các sản phẩm khác của Atlassian hiện tại đang được team mình sử dụng do phù hợp với team mình nhất. Sơ qua về JIRA thì nó là một tool hỗ trợ nhiều loại kiểu dự án khác nhau, cách quản lý khác nhau, cho phép tùy chọn tối đa và các chức năng cực kì hữu dụng khác mà các tool khác chưa có hay làm chưa tốt như: Multi-board, Report, Query… Ngoài JIRA, bọn mình còn sử dụng cả Confluence, Bitbucket, Jira Ops và đang thử nghiệm cả JIRA Service Desk.
Trong bài này, bọn mình muốn chia sẻ cách bọn mình setup, sử dụng JIRA như nào để đạt hiệu quả.
Tùy chỉnh lại Status, Workflows để phù hợp với team
7-Lab không sử dụng workflows có sẵn trên JIRA mà đã điều chỉnh lại để phù hợp với team. Cụ thể như define dưới đây.
- TODO: Khi ticket mới được khởi tạo.
- IN PROGRESS: Developer đang làm việc trên ticket đó. Status này, bọn mình sử dụng trigger từ việc branch được tạo từ Bitbucket.
- TO REVIEW: Ticket đã làm xong, đang đợi để review code bởi team lead hoặc các thành viên khác trong nhóm. Status này được gán trigger là khi Pull Request (PR) được tạo tới từ developement branch.
- TO TEST: Ticket cần kiểm thử bởi QA.
- TEST FAILED: Khi QA kiểm thử có lỗi, sai yêu cầu…
- TEST PASSED: Khi QA đã hoàn thành kiểm thử và đạt yêu cầu. Tips: Bọn mình setup khi Developer kéo ticket sang status này thì ticket sẽ tự động assign cho người tạo vì đa số trường hợp thì người mở ticket chính là QA nên việc tự động assign ngược vậy cũng đỡ một phần công việc cho Developer rồi.
- TO PRODUCTION: Ticket được chọn để để đưa bản vào Release tiếp theo.
- MERGED: Ticket đã được merge vào branch release. Status này cũng được gán trigger là khi pull requestđã được merged vào branch Release.
- CLOSED: Ticket đã được hoàn thành kiểm thử trên branch release sau khi hoàn thành kiểm thử tích hợp (Integration Test) và kiểm thử hồi quy (Regression Test).
Tách biệt giữa Development Sprint và Release
Tại 7-Lab có 3 mốc thời gian riêng biệt. Mỗi 2 tuần để Development, 1 tuần để Regression Test và 1 tuần để User acceptance test (UAT)
Mục đích của việc chia như vậy để bọn mình có thể đảm bảo:
- Toàn bộ những đoạn code, thay đổi khi chưa được test ổn định thì không được phép có trên production. Trước khi điều này bọn mình gặp khá nhiều khi những ticket đó làm không kịp hay thời gian bắt buộc release bị thay đổi.
- Có đủ thời gian cho người dùng thực sự có thời gian UAT để đưa ra các yêu cầu thay đổi nếu cần. Và đôi khi cũng là thời gian để bọn mình làm tài liệu để hướng dẫn cho người dùng nếu cần thiết.
- Việc release sẽ không ảnh hưởng tới việc developement. Release có thể gần như chạy hoàn toàn độc lập với developement, nghĩa là bạn có thể delay việc deploy đó lên production mà không làm dừng việc developement hay làm xáo trộn sprint.
Để phục vụ cho việc này, bọn mình đã tạo ra 2 board riêng biệt. Development board sử dụng Scrum và Release board sẽ là Kanban. Các bạn có thể tìm hiểu sự khác biệt giữa Scrum & Kanban tại đây.
Khi kết thúc một sprint, PO sẽ vào Release Board và chọn ra những ticket đang ở trạng thái “TEST PASSED” tại Backlog để chuyển sang status “TO PRODUCTION” để dánh dấu ticket đó sẽ được release. Tại bước ngày, việc tách board phát huy hiệu quả nhất.
Ví dụ, bọn mình có chức năng ABC, chức năng này cần có cả 3 components là A, B, C nghĩa là mình cần 3 phần code riêng biệt cho từng component đó. Tại thời điểm release, nếu như A, B đã xong nhưng C thì chưa thì PO sẽ không pick A và B lên, đồng nghĩa chức năng có thể được giữ lại sprint sau mà không lo đến việc A & B vẫn được nằm trên production mặc dù C chưa sẵn sàng.
Sau khi hoàn tất, developer phụ trách việc merge các branch sẽ vào release Board, kiểm tra những ticket nào đang nằm trong status đó rồi merge. Sau khi merge branch của ticket đó, ticket sẽ tự động chuyển sang trạng thái “MERGED” nhờ vào trigger.
Sau khi hoàn tất các bước merge chúng ta sẽ có phiên bản Release Candidate, nghĩa là phiên bản bao gồm toàn bộ những phần việc đã làm xong của toàn bộ Sprint trước. QA sẽ kiểm thử tích hợp (Integration Test) và kiểm thử hồi quy (Regression Test) trên các phiên bản đó.
Quản lý Versioning
Vào đầu mỗi sprint, PO sẽ là người lập planning để ra các version và những phần có thể release sắp tới, từ đó đưa các version vào trong ticket. Đứng từ góc độ người quản lý, mình thích nhìn màn hình này nhất vì nó cho một cái nhìn tổng quan nhất về trạng thái của đợt release như nào.
Việc quản lý chặt chẽ release version giúp 7-Lab có thể kiểm tra lại khi cần. Ví dụ như muốn xem một chức năng bắt đầu chạy trên production từ khi nào thì chỉ cần xem ticket đó có version là gì, từ version là sẽ biết ngày deploy, rất tiện.
Có 1 tip cho các bạn muốn tạo release notes từ version qua Confluence bằng cách chọn Create -> Report -> Change logs. Confluence sẽ tự động generate cho bạn một release notes với toàn bộ thông tin của ticket trong đó, bạn chỉ cần điền các thông tin còn thiếu vào nữa là xong.
Kết
Hãy sử dụng tool để phục vụ cho mình chứ đừng áp đặt mình phải làm theo nó. Có thể tool đó được thiết kế dựa trên một quy trình chuẩn, được nghiên cứu, phát triển từ rất nhiều năm nhưng không có nghĩa là nó đúng, ngay cả cái quy trình đó cũng chưa chắc là đúng. Do vậy, hãy mạnh dạn thay đổi để tìm ra quy trình tốt nhất cho team, công ty của mình.
Bên trên là những chia sẻ về process và cách áp dụng JIRA vào công việc. Còn các bạn đang dùng tool gì để quản lý, có ý kiến nào hay hoặc có khúc mắc gì không? Hãy cùng chia sẻ với bọn mình nhé.
