Ở 2 bài trước chúng ta đã cùng nhau tìm hiểu về Agile, về Scrum và các đặc điểm của nó. Chúng ta cũng đã nắm trược trong một Sprint sẽ cần sự kiện gì, mục đích của chúng là gì. Nhưng sẽ thật là thiếu sót nếu chúng ta không đề cập những kĩ thuật mà nhóm Scrum “cắm thêm” vào Scrum để ra được “công nghệ sản xuất” thực sự của mình.
Quản lý yêu cầu người dùng với User Story
Một trong những template quen thuộc của một User Story ( US ) là:
Là <vai trò gì đó>, tôi muốn <làm cái gì đó>, để <đạt được cái gì đó>
ví dụ:
- Là khách hàng, tôi muốn xem danh sách sản phẩm mới để lựa chọn mua
- Là khách hàng, tôi muốn mua hàng online
US được ưa chuộng nhờ sự ngắn gọn, việc sử dụng ngôn ngữ đời thường khiến nó trở nên dễ hiểu, US không phải bản mô tả đầy đủ chi tiết của tính năng. Việc tìm hiểu cụ thể về tính năng này sẽ được thực hiện thông qua trao đổi giữa team phát triển với PO và các bên liên quan.
Làm rõ một User Story
Thông thường có 2 cách để làm rõ một US
Phân tách một US thành nhiều US nhỏ hơn
Ví dụ với US: Là khách hàng tôi muốn mua hàng online
Team sẽ break nó ra thành 3 US nhỏ bao gồm:
- Là khách hàng, tôi muốn xem danh sách sản phẩm để chọn mua
- Là khách hàng, tôi muốn thêm một sản phẩm vào giỏ hàng
- Là khách hàng, tôi muốn xem danh sách sản phẩm trong giỏ hàng
Chi tiết US bằng cách thêm tiêu chí chấp nhân ( Acceptance Criteria )
Ví dụ với US: Là khách hàng, tôi muốn xem danh sách sản phẩm, để chọn mua
AC:
- Hiển thị tên, ảnh, giá sản phẩm
- Cho phép sort sản phẩm theo giá/mới, cũ/cập nhật gần nhất/sale nhiều nhất.
- Paging 20 sản phẩm 1 trang
Ai là người viết User Story ?
PO là người quản lí Product backlog và tất cả US trong đó, nhưng không có nghĩa PO là người viết tất cả US đó, thông thường PO sẽ đại diện người dùng để viết các US dưới vai trò là người dùng. Nhưng bên cạnh đó tất cả thành viên cũng đều tham gia vào việc viết US. Hoạt động này diễn ra trong suốt Sprint. Nhưng đương nhiên việc thêm mới các US vào Sprint đang chạy là việc rất rất không được khuyến khích, thứ tự ưu tiên của các task vẫn phải phục vụ mục tiêu cuối cùng là Sprint goal.
Planning Poker
Các số point này thực chất là dãy fibonaci ( có cải tiến để phù hợp với việc phát triển sản phẩm): 0,1,2,3,5,8,13,20…
Để thực hiện est cho một US team sẽ thực hiện các bước sau:
Bước 1: Xác định US cần est
Bước 2: Mỗi thành viên sẽ tự xác định điểm point tương ứng và không để các thành viên khác trong team biết được con số của mình.
Bước 2: Tất cả cùng lật con số mà mình chọn.
Bươc 4: Nếu tất cả cùng một con số, thì coi như việc estimate đã xong. Ghi lại estimate point của US đó. Nếu có sự khác nhau trong các con số, team thông thường sẽ để cho đại diện người có con số lớn nhất và bé nhất giải thích vì sao lựa chọn như thế, sau đó mọi người thực hiện vote lại cho đến khi đạt được con số thống nhất, thông thường thì sẽ không quá 3 lần vote lại, nếu vẫn chưa thống nhất thì chọn theo số đông ( vẫn có trường hợp Technical Owner đưa ra ý kiến của mình để tìm kiếm sự đồng thuận của cả team và chốt con số ).
Mô hình TDD
Có một nguyên tắc trong phát triển sản phảm đó là: Bug phát hiện càng sớm thì càng dễ để sửa chữa, bug phát hiện càng muộn thì chi phí sửa chữa càng tăng lên.
TDD (Test-Driven Development) là một phương pháp phát triển phần mềm trong đó việc viết các bài kiểm tra (test cases) diễn ra trước khi viết mã thực hiện tính năng. Quy trình TDD thường gồm ba bước chính:
- Viết bài kiểm tra (Write a Test): Bắt đầu bằng cách viết một bài kiểm tra đơn giản cho chức năng muốn phát triển, mặc dù chưa có mã nào để thực hiện chức năng đó. Bài kiểm tra này sẽ thất bại (fail) khi chạy vì tính năng chưa được hiện thực.
- Viết mã để vượt qua bài kiểm tra (Write Code to Pass the Test): Sau đó, viết mã thực hiện tính năng chỉ vừa đủ để bài kiểm tra thành công (pass). Tập trung vào việc làm sao để mã vượt qua bài kiểm tra với càng ít mã càng tốt.
- Tối ưu và cải tiến mã (Refactor): Khi bài kiểm tra đã thành công, tiến hành tối ưu hóa và làm sạch mã. Đảm bảo rằng mã vẫn giữ được tính hiệu quả, dễ đọc và có thể bảo trì.
Lợi ích của TDD cụ thể như sau:
- Thông qua kịch bản kiểm thử, developer có cái nhìn trực quan về sản phẩm ngay trước khi xây dựng mã nguồn. Sản phẩm họ tạo ra chính xác và gần gũi người dùng hơn.
- Phần mã nguồn được thêm vào chỉ vừa đủ để chạy thành công kịch bản kiểm thử, hạn chế dư thừa và qua đó hạn chế khả năng xảy ra lỗi trên những phần dư thừa.
- Bảo đảm mã nguồn luôn phản ánh đúng và vừa đủ yêu cầu phầm mềm, hạn chế được công sức tối ưu mã nguồn về sau.
Mô hình ATDD và BDD
Một dạng mở rộng của TDD là phát triển hướng kiểm thử chấp nhận ( Acceptance Test-Driven Development ). Đây là một kĩ thuật dựa vào sự cộng tác giữa khách hàng, nhà phát triển và kiểm thử viên, trong đó toàn bộ các thành viên tập trung cộng tác để thảo luận về các tiêu chí chấp nhận, sau đó chuyển chúng thành các checklist phải đạt trước khi viết code.
ATDD khuyến khích sự tham gia của khách hàng, sớm đưa ra các thiết kế của sản phẩm từ góc nhìn của người dùng, nâng cao chất lượng của sản phẩm và giúp cho các nhà phát triển hiểu rõ hơn nghiệp vụ của sản phẩm.
BDD ( behavior-driven development) phát triển hướng hành vi. Đây là mô hình phát triển trong đó kết hợp các kĩ thuật của TDD với các thiết kế hướng nghiệp vụ nhằm cung cấp các công cụ và thúc đẩy sự cộng tác của đội ngũ phát triển và những người liên quan. Một trong những lợi ích của BDD là cung cấp cách thức để quản lí quá trình phát triển sản phẩm từ hai góc độ khác nhau là người dùng và kĩ thuật.
Pair Programming ( Lập trình cặp )
Là hình thức 2 developer cùng chia sẻ một vấn đề, với một máy tính, một bàn phím, một mục tiêu: giải quyết vấn đề đó. Các thành viên sử dụng sự đồng thuận, nhưng thông qua tranh luận. Tốc độ dev có thể chậm hơn nhưng hiệu quả và chất lượng sẽ được nâng cao.
Lập trình cặp là một kĩ thuật rất tốt được sử dụng nhằm nâng cao chất lượng sản phẩm, giảm thiểu lỗi ngay từ sớm, gia tăng cộng tác trong nhóm, thúc đẩy học tập lẫn nhau và cổ xuý sở hữu và trách nhiệm tập thể.
Prototype / Mockup
Là kĩ thuật để sớm đưa ra một phiên bản của sản phẩm dưới dạng “bản mẫu” thể hiện ý tưởng và các tính năng của sản phẩm. Giúp người dùng, khách hàng có thể hình dung được sản phẩm sẽ như thế nào từ sớm, từ đó đưa ra các góp ý chỉnh sửa từ sớm.
Tích hợp liên tục
Định nghĩa lý thuyết thì tích hợp liên tục CI (là viết tắt của Continous Integration) là một thực hành trong phát triển phần mềm trong đó các thành viên của một đội tích hợp công việc của họ một cách thường xuyên, thường thì mỗi người sẽ tích hợp ít nhất là hàng ngày – dẫn tới có nhiều tích hợp trong một ngày. Mỗi sự tích hợp sẽ được kiểm định lại bởi một build tự động (bao gồm cả test) để phát hiện ra lỗi tích hợp càng sớm càng tốt. Nhiều người nhận thấy rằng hướng làm việc này giúp giảm thiểu đáng kể các vấn đề khi tích hợp và cho phép một đội phát triển có thể viết phần mềm nhanh hơn. Nói tóm lại thì CI là phương pháp được sử dụng để đảm bảo code của toàn dự án luôn build được, luôn chạy đúng (Pass toàn bộ các test case).
Kết luận
Trên đây là những kĩ thuật Agile phổ biến. Hi vọng thông qua bài viết mọi người đã có thêm nhiều kiến thức về các kĩ thuật để thực hành Agile hiệu quả.