Behaviour Driven Development. Có thực sự tốt hơn cho Agile? (Phần I)

Hay chỉ là 1 bước đi tự nhiên đúng hướng tiếp theo?

Vài tháng qua, chúng tôi đã đặt các ngón chân của chúng tôi vào vùng biển rộng rãi chưa được biết đến của Behaviour Driven Development, viết tắt BDD. Bài đăng này khám phá một số trong những điều chúng tôi đã học được trên đường đi; Nó là gì? Quan tâm đến những gì? Giải quyết những vấn đề gì? Những vấn đề gì không giải quyết được? Bạn nên quan tâm đến những gì?

Agile là đủ, vậy tại sao phải rắc rối với BDD?

Trước tiên BDD không thay thế Agile mà chỉ đơn thuần cải thiện nó, giới thiệu thêm 1 vài công cụ nữa vào trong bộ công cụ Agile của bạn. Bạn có thể hỏi cái gì cần được cải thiện? Sau nhiều năm vận hành các dự án Agile chúng ta bắt đầu thông báo 1 vài thứ:

1. Các User story tập trung rất nhiêu vào mỗi user riêng lẻ và những gì chúng đang cố gắng đạt được. 1 User story không nhất thiết phải tập trung vào lý do tại sao nghiệp vụ này là cần thiết đối với tính năng mới. Điều này có thể bị bỏ qua tại các sprint planning metting và các dev quyết định với những user này thì nghiệp vụ này là không cần thiết.

2. Các dự án đang vận hành 1 thời gian dài công việc được thực hiện theo 1 User story có thể dễ dàng bị thay thế bởi 1 user story tiếp sau. Được rồi, nhưng các đặc điểm kỹ thuật tổng thể của sản phẩm là gì? Các công cụ trong bộ công cụ Agile thường rất ít liên quan đến việc sở hữu các đặc tả kỹ thuật này và luôn cập nhập nó.

3. Tiêu chí chấp nhận, thật vớ vẩn nếu cho rằng bạn biết 1 User story là 1 chức năng hoàn chỉnh, có thể là ngẫu nhiên và chất lượng không ổn định. Đây cũng là 1 vấn đề nếu User story đang chi phối công việc kiểm thử, bởi vì chúng ta đã nói, 1 User story là có tính chất tạm thời và có thể bị thay thế về sau này. Điều này tạo ra 1 vấn đề về khả năng tạo vết và rất nhiều việc rắc rối để giữ mọi thứ tiến triển. 4. Có 1 vài công cụ trong bộ công cụ Agile mà sẽ giúp bạn khám phá. Team technical pre-sales của bạn sẽ không nói cùng 1 ngôn ngữ giống như team dev của bạn. Ở giai đoạn cơ hội kinh doanh, làm thế nào bạn quyết định bạn nên cố gắng giải quyết vấn đề gì trước hoặc thậm chí là chỉ ra các vấn đề đó? 5. Trong nhiều trường hợp các team Agile chấp nhận “Test Driven Development” (TDD). Vấn đề với TDD là nó là 1 cách tiếp cận tốn kém, bạn có thể kết thúc hàng trăm bài test ở các cấp độ nuts và bolt mà không bao giờ có 1 bài test mà chứng minh rằng bạn đã tạo ra 1 tính năng thực sự mang lại giá trị hứa hẹn.

Chúng ta đã thấy rằng BDD cố gắng giải quyết tất cả vấn đề này và nhiều hơn nữa. Trong khi nó vẫn duy trì trường hợp “there is no silver bullet”, BDD đi 1 bước xa hơn trong việc giải quyết 1 số khoảng trống và định hướng quá trình Agile.

Với chúng tôi, nó đã mang lại giá trị mới ngay tức khắc bằng cách giới thiệu chúng tôi với các khái niệm sau:

• Đặc điểm kỹ thuật bằng ví dụ

• Chính thức hóa tiêu chí chấp nhận

• Tài liệu sống

• Bản đồ ảnh hưởng và khám phá thận trọng

Business benefit

Có lẽ sự thay đổi đơn giản nhất chúng ta đã làm khi di chuyển kết quả của chúng ta vào BDD là tái sắp xếp lại các User story của chúng ta. Có 1 vài mẫu user story, nhưng 1 cái mà chúng ta đã sử dụng gần đây là “As a <role> I want <feature> so that I can <benefit>”. Trong khi BDD là rất tốt với điều này, nó đề xuất 1 giải pháp thay đổi luân phiên : “In order to <realise benefit> as a <role> I want <feature>.

Chúng tôi đã thấy rằng việc tập trung tăng cường BDD vào các mục đích của nghiệp vụ và giá trị nghiệp vụ nó có ý nghĩa thay đổi điểm nhấn của các user story ra khỏi user và tôn lên các đề xuất có giá trị.

Thay đổi này là khôn ngoan và nó có rất nhiều ý nghĩa; nó có thể tạo ra sự khác biệt nhỏ đối với 1 dev nhưng nó hữu ích cho nghiệp vụ liên quan để thao luận các user story theo cách này. Nó đảm bảo cách giá trị của nghiệp vụ là luôn luôn được thảo luận và hiểu rõ trước các planning metting. Nó cũng vượt qua được các cám dỗ và kết thúc với các user story mà heo hình thức đơn giản “As <user> I want <feature>”, có thể thường trở thành các case.

Các ví dụ

BDD đặt trọng tâm vào việc sử dụng các ví dụ cụ thể để cố gắng và che giấu sự mơ hồ. Chúng được sử dụng cả trong quá trình khám phá và khi viết tiêu chi chấp nhận.

Bạn đã đọc đặc điểm kỹ thuật của 1 đơn hàng bao nhiêu lần và không thể làm nó được từ đầu đến cuối? Bạn đã có 1 cuộc trò chuyện với khách hàng hoặc nhà cung cấp bao nhiêu lần và chỉ phát hiện ra rằng những thứ mà bạn đã chấp nhận có đến 2 version khác nhau?

Các ví dụ là ma trận giải thuật trong các team BDD mà đảm bảo rằng mọi người đang hát cùng một bài hát. Không những họ chỉ ra rõ ràng cho tất cả các bên về sự hiểu biết hiện tại của họ là gì, họ cũng khám phá ra những khoảng cách. Một ví dụ có thể tạo điều kiện cho một cuộc trò chuyện có thể khám phá ra chức năng bị thiếu hoặc giả định. Cuộc hội thoại có thể đặt câu hỏi tại sao một tính năng đặc biệt ở đó lại có ở đó. Có lẽ có một cách tốt hơn?

Để giúp đảm bảo các ví dụ này được truyền đạt rõ ràng nhất có thể, 1 cú pháp chính thức được giới thiệu với cái mà chúng viết. Điều này được gọi là Gherkin (bởi vì tất cả những thứ tốt xứng đáng được đặt tên) và sử dụng nó để truyền đạt chính thức các kịch bản và tiêu chí chấp nhận có hai ưu điêm:

1. Các tính năng khác biệt của ứng dụng có thể được truyền đạt hiệu quả giữa tất cả các member của nhóm dự án, từ chủ sở hữu sản phẩm đến các nhà phân tích nghiệp vụ tới các kỹ sư phát triển phần mềm và các kỹ sư kiểm thử.
2. Một cú pháp cho phép sử dụng công cụ tự động. Nếu 1 máy tính có thể dễ dàng xử lý và hiểu cú pháp, thì các công cụ có thể được phát triển để viết các bài test dựa trên các ví dụ này hoặc tạo ra tài liệu về chúng.

Một ví dụ của kịch bản BDD được viết trong Gherkin, sử dụng cú pháp “Given, When, Then"

Kịch bản: Tìm lộ trình tối ưu giữa các trạm trên cùng một đường

Given các đoàn tàu phía tây nam rời Portsmouth Harbour tới London Waterloo vào lúc 07:13, 07:24, 07:29, 07:45, 07:55 When tôi muốn đi từ Portsmouth Harbour tới London Waterloo vào lúc 07:15 Then tôi nên được thông báo về các chuyếnn tàu vào 07:24, 07:29, 07:45

Tham khảo: https://medium.com/the-reading-room/behaviour-driven-development-a-better-agile-778d2d2a7ab5