Làm thế nào để thành công tại Hội thảo Thông số kỹ thuật của BDD?

Hôm nay chúng tôi đã cố gắng giới thiệu BDD trong quy trình phát triển phần mềm của mình bằng cách có một hội thảo đặc tả.

Đối với hội thảo này, chúng tôi đã có 2 nhà phát triển, 1 người thử nghiệm và 1 nhà phân tích kinh doanh. Hội thảo kéo dài 1h30 và đến cuối buổi, chúng tôi đã tìm ra một số kịch bản BDD cho tính năng mới của chúng tôi. Chúng tôi đã cố gắng tập trung vào việc tìm kiếm các kịch bản mà chúng tôi có thể bỏ lỡ, và những kịch bản khó khăn.

Vào cuối hội thảo, một số người thực sự không hài lòng với hội thảo.

Một nhà phát triển cảm thấy anh ta đã lãng phí thời gian của mình khi anh ta được sử dụng để đưa ra các kịch bản trực tiếp bởi nhà phân tích kinh doanh và xem xét chúng với cô ta. Nhà phân tích kinh doanh không cảm thấy tự tin với phạm vi bảo hiểm kịch bản của chúng tôi (Có cảm giác rằng chúng tôi có thể bỏ lỡ những thứ quan trọng khác) nhưng quan trọng hơn là cảm thấy rằng hội thảo này cũng lãng phí thời gian khi cô ấy có thể tự mình tìm ra tất cả các kịch bản này. và trong một khoảng thời gian ngắn hơn .

Hội thảo thử nghiệm này kéo dài 1h30 và đến cuối, chúng tôi không cảm thấy đủ tự tin về những gì chúng tôi đã làm ... chắc chắn rằng chúng tôi có thể dành nhiều thời gian hơn cho nó nhưng thật ra hầu hết mọi người đều kiệt sức sau 1h30 động não để tìm hiểu về doanh nghiệp quy tắc từ bộ não BA.

Vì vậy, câu hỏi của tôi là làm thế nào loại hội thảo thực sự có thể làm việc. Theo lý thuyết, nếu bạn có một tính năng mới để phát triển, bạn đặt cây 'amigos' (dev / test / ba) trong cùng một phòng để chúng có thể cộng tác với nhau bằng cách viết các yêu cầu khác biệt cho tính năng mới bằng cách sử dụng các ví dụ. Tôi có thể thấy tất cả những lợi ích từ đó. Đặc biệt về mặt chia sẻ kiến ​​thức và sản phẩm chung / mục tiêu cuối cùng / tầm nhìn thực hiện.

Kết luận của chúng tôi từ thí nghiệm này là thực sự hiệu quả hơn về chi phí khi lần đầu tiên có một BA tự làm việc trên các ví dụ và chỉ sau đó mới có các kịch bản được xem xét / làm lại bởi 3 'amigos'. Bằng cách để BA tự làm việc, chúng tôi thực sự cảm thấy tự tin hơn rằng chúng tôi sẽ ít bỏ lỡ công cụ hơn + chúng tôi vẫn có thể xem xét các kịch bản sau đó để kiểm tra lại. Chúng tôi không nghĩ đơn giản hơn một lần phát hiện động não / phiên khám phá có chủ ý thực sự đủ để thực hiện nghiêm túc tất cả các yêu cầu cho một tính năng mới. Các nhà phân tích kinh doanh thực sự là người tốt nhất cho loại công cụ đó. Điều tốt nhất chúng ta có thể làm là xem lại những gì cô ấy đã viết và xem nếu sau đó chúng ta có một sự hiểu biết chung (sau đó có thể dẫn đến việc viết lại một số tình huống của cô ấy hoặc thêm những tình huống mới mà cô ấy có thể đã bỏ lỡ).

Vì vậy, làm thế nào bạn có thể có được điều đó để làm việc hiệu quả trong thực tế ?

Nếu bạn có thể rút ra các kịch bản từ mô tả, bạn đã hoàn thành.

Một mô hình chống mà tôi thường thấy trong BDD là mọi người cảm thấy cần phải nói chuyện và viết ra, mọi tình huống chi tiết.

Một số kịch bản được hiểu rõ đến mức đủ để lấy chúng từ một mô tả ngắn gọn. Chẳng hạn, nếu tôi nói: "Tôi muốn tính năng đăng nhập tuần này", bạn sẽ biết nó sẽ trông như thế nào. Bạn biết rằng có những kịch bản cho đúng mật khẩu, sai mật khẩu, sai tên người dùng. Chúng tôi không thực sự cần nói chuyện qua những điều đó hoặc nắm bắt chúng một cách chi tiết.

Tương tự, tôi có thể nói: "Đây là hình thức đăng ký người dùng. Chúng tôi cần có khả năng tạo người dùng mới, để họ chỉnh sửa chi tiết và tự xóa, ngoại trừ việc xóa không thực sự xóa, nó chỉ nên đánh dấu họ là đã xóa để họ có thể khôi phục tài khoản nếu muốn. "

Và bạn có thể hỏi, "Có phải phục hồi tài khoản là một phần của tính năng này không?"

"Chúng có thể là hai tính năng nếu bạn muốn."

"Được rồi, vì vậy chúng tôi có các kịch bản để tạo, đọc, cập nhật, xóa; điều đó đủ dễ dàng. Hãy nói về phục hồi tài khoản; nghe có vẻ thú vị hơn."

Nói chung, nếu mô tả hành vi là đủ để nhóm nhà phát triển rút ra các tình huống, bạn không cần phải nói qua chúng. Bạn có thể làm như vậy nếu có bất kỳ nghi ngờ nào, nhưng bạn có thể chỉ muốn nắm bắt những kịch bản nào bạn cần nhớ, nếu bạn nắm bắt được bất kỳ kịch bản nào.

Nếu bạn chưa bao giờ làm điều đó trước đây hoặc bạn không chắc chắn, hãy nói qua các tình huống.

Tập trung vào các lĩnh vực không bình thường, đặc biệt nếu có những tính năng bạn chưa từng làm trước đây. Đây là những nơi tuyệt vời để trò chuyện và viết ra bất kỳ ví dụ đáng ngạc nhiên nào xuất hiện. Tôi thường có hai câu hỏi tôi đặt ra, dựa trên mẫu BDD:

Đưa ra một bối cảnh
Khi một sự kiện xảy ra
Sau đó, một kết quả sẽ xảy ra.

• Có bối cảnh nào khác, cho cùng một sự kiện, tạo ra một kết quả khác nhau không?
• Có kết quả nào khác cũng quan trọng không?

Nếu tất cả mọi người trong bàn đều cảm thấy buồn chán, tính năng bạn đang nói có lẽ được hiểu rõ. Nó thường đủ để nói, "Nó nên hoạt động như X , nhưng với Y thay vào đó." Đây là những gì Dan North gọi là mô hình Bánh gừng ; Nó giống như công thức làm bánh sô cô la, nhưng với gừng thay vì sô cô la.

Ngay cả khi các bên liên quan kinh doanh có thể tự mình rút ra các kịch bản, điều thực sự quan trọng đối với nhóm nhà phát triển là có thể nói chuyện với anh ta, tiếp thu và tiếp thu ngôn ngữ của anh ta. Ngôn ngữ đó sau đó được đưa vào mã, cho phép họ có những cuộc trò chuyện tốt hơn trong tương lai và giúp những người mới tham gia dự án hiểu những gì đang diễn ra. Nếu các nhà phát triển không nói được ngôn ngữ, họ sẽ không sử dụng ngôn ngữ đó.

Nếu các bên liên quan hoặc nhà phân tích kinh doanh thực sự không muốn dành thời gian để nắm bắt mọi thứ trong phiên, thì đúng hơn là các nhà phát triển đã viết các kịch bản hợp tác với những người thử nghiệm, sau đó yêu cầu anh ta xem xét nó. Điều này có nhiều khả năng phát hiện ra những hiểu lầm hơn so với cách khác.

Đôi khi BDD không hoạt động.

Một khả năng khác là bạn tìm thấy một kịch bản mà các bên liên quan kinh doanh không chắc chắn. "Ồ, tôi đã không nghĩ về điều đó! Tôi không chắc chắn." Thay vì cố gắng đóng đinh doanh nghiệp và trừng phạt doanh nghiệp một cách chắc chắn, có thể đáng để từ bỏ BDD vào thời điểm này và thử một cái gì đó đơn giản để nhận được một số phản hồi và cung cấp cho doanh nghiệp một cái gì đó mà họ có thể lặp lại. Giữ cho nó dễ dàng thay đổi và viết các kịch bản một khi hiểu rõ hơn về những gì đang diễn ra.

BDD thực hiện tốt có thể thực sự giúp phát hiện ra những nơi không chắc chắn. Vì mỗi giá trị dự án làm có một số khía cạnh của nó đó là mới và chưa bao giờ được thực hiện trước, có là một số không chắc chắn trong đó, ở đâu đó. Nếu bạn tập trung vào việc sử dụng các kịch bản để giúp cố tình phát hiện ra sự thiếu hiểu biết , bạn sẽ học nhanh hơn và việc học thường là một phần lớn thời gian dành cho một dự án.

Ngoài ra, tôi thấy rằng các nhóm phát triển cộng tác theo cách này càng nhiều, doanh nghiệp càng sẵn sàng tin tưởng họ với sự không chắc chắn và càng có nhiều sự đổi mới bắt đầu xảy ra. Các công ty sáng tạo, về bản chất, có rất nhiều sự không chắc chắn trong các dự án của họ.

Tôi đã viết một bài đăng trên blog một thời gian trước trên Cynefin , điều mà tôi thấy thực sự giúp tôi hiểu nơi các cuộc hội thoại sẽ hiệu quả nhất. Nếu bạn đọc nó và hiểu bốn miền, đây là các quy tắc tôi sử dụng:

• Những thứ đơn giản và phức tạp (được biết đến) thường được hiểu rõ và bạn không cần phải nói chi tiết về các tình huống.

• Những thứ rất phức tạp (chưa biết) hoàn toàn không được hiểu. Bạn có thể khám phá điều này bằng cách nói chuyện qua các kịch bản. Sự thiếu chắc chắn có nghĩa là BDD sẽ không hoạt động ở đây, vì vậy hãy lặp đi lặp lại một cái gì đó dễ thay đổi và nhận phản hồi nhanh thay thế. Bất kỳ thực hành nào giữ lại các tùy chọn của bạn, như thử nghiệm AB, cũng rất tuyệt trong không gian này.

• BDD hoạt động rực rỡ trong không gian ở giữa (có thể biết) như một cơ chế truyền đạt kiến ​​thức và khám phá hai không gian còn lại. Nó không phải là một cái búa, và không phải tất cả mọi thứ là một cái đinh. Trên thực tế, nếu bạn có thể tập trung thời gian dành cho việc trò chuyện vào bất cứ điều gì, thì đó không phải là về những ví dụ bạn có thể tìm thấy; đó là về việc tìm kiếm những ví dụ bạn không thể .

Thời lượng của cuộc họp không phải là vấn đề của bạn. Sẽ ổn thôi nếu những cuộc họp đó diễn ra trong một thời gian dài. NHƯNG tất cả mọi người nên đi ra khỏi nó cảm thấy tự tin. Rằng họ không phải là vấn đề của bạn.

Tôi sẽ đề nghị một cuộc họp ngắn để thảo luận về một yêu cầu. Lên lịch một cuộc họp thứ hai một vài ngày sau đó, vì vậy mọi người đều biết rằng họ phải được chuẩn bị trước đó.

Sau đó, BA và người kiểm tra nên đưa ra các kịch bản của họ, bởi vì cả hai đều nhìn vào phần mềm theo những cách rất khác nhau. Yêu cầu họ viết chúng lên thẻ và dán tất cả lên bảng ở đâu đó, ít nhất một ngày trước cuộc họp thứ hai, để mọi người nhìn qua trong thời gian riêng của họ và suy nghĩ kỹ. Vứt bỏ mọi bản sao, dán lên bất kỳ kịch bản nào không được xem xét.

Đừng vứt bỏ bất cứ điều gì bạn không đồng ý, nhưng đánh dấu nó là gây tranh cãi. Nếu một cuộc trò chuyện ngắn với người viết nó sẽ giúp ích, hãy làm điều đó, nhưng chủ yếu là lưu nó.

THEN có cuộc họp lập kế hoạch / thiết kế của bạn. Có một chương trình nghị sự vững chắc cho cuộc họp đó (bắt đầu với đống thẻ, đặt những thứ gây tranh cãi lên hàng đầu) và không cho phép nó đi lang thang ngoài đường. Hãy chắc chắn rằng bạn đi ra khỏi cuộc họp đó với tất cả các điểm tranh chấp được giải quyết.

Luôn đảm bảo mọi người trong cuộc họp được chuẩn bị cho chủ đề của cuộc họp đó!

Đừng bao giờ sử dụng một cuộc họp để "động não" bất cứ điều gì cùng nhau. Nó lãng phí thời gian của mọi người.

Công thức chung cho các cuộc họp hiệu quả:

• có ai đó chuẩn bị các mục để thảo luận
• yêu cầu tất cả những người tham gia đã nghiên cứu (không chỉ đọc) cho họ những mục đó
• thu thập ý kiến ​​trước và yêu cầu tất cả người tham gia đã nghiên cứu (không chỉ đọc) chúng
• tổ chức cuộc họp để đưa ra quyết định

Về Khiếu nại ...

Hãy bắt đầu với những điều sau:

Một nhà phát triển cảm thấy anh ta đã lãng phí thời gian của mình khi anh ta được sử dụng để đưa ra các kịch bản trực tiếp bởi nhà phân tích kinh doanh và xem xét chúng với cô ta.

Đó là những gì ông đã làm trong hội thảo. Vì vậy, đó có vẻ như là một cái cớ buồn và xấu cho tôi. Tôi nghi ngờ nhà phát triển này không thích một trong hai (hoặc cả hai) sự giám sát của hội thảo và các ràng buộc về lịch trình của nó.

Nhà phân tích kinh doanh không cảm thấy tự tin với phạm vi bảo hiểm kịch bản của chúng tôi (Có cảm giác rằng chúng tôi có thể đã bỏ lỡ những thứ quan trọng khác)

Làm thế nào điều này khác với khi cô ấy làm điều đó về phía mình và nó đã được xem xét bởi một nhà phát triển, ngoài thực tế là nhiều người nhìn vào nó? Tôi nghi ngờ đây chỉ là kết quả của hội thảo có thể hơi hỗn loạn. Bạn sẽ có được sự tự tin rằng bạn có đủ các bài kiểm tra bằng cách thực hiện chúng và tích hợp chúng. Bạn không bao giờ có thể chắc chắn rằng mình đã tìm thấy tất cả các lỗi và khi nói đến phạm vi bảo hiểm, cách tốt nhất là lập sơ đồ cho chúng trong các câu chuyện người dùng của bạn.

nhưng quan trọng hơn là cảm thấy rằng hội thảo này cũng lãng phí thời gian vì cô có thể tự mình tìm ra tất cả các kịch bản này và trong một khoảng thời gian ngắn hơn.

Vâng, và hoàn toàn một mình, trong khu vườn có tường bao quanh và không chia sẻ kiến ​​thức. Trong khi đó, bằng cách thực hiện các hội thảo trong tương lai này có thể có năng suất cao hơn vì tất cả những người tham gia đã có được một chút kiến ​​thức về cách tiếp cận những điều này.

Có lẽ cuộc họp diễn ra chậm chạp, điều đó không có nghĩa là nó sẽ luôn diễn ra. Và với tư cách là một cá nhân bên ngoài, tôi đã được đào tạo để có được điều này, tin tưởng hơn rằng phạm vi bảo hiểm sẽ tốt hơn trong một hội thảo với 3 người tham gia với những suy nghĩ khác nhau với một nhà độc tài.

Ngoài ra, nếu đã có nhu cầu cho nhà phát triển xem xét các kịch bản này với cô ấy, tôi chắc chắn rằng việc quay lại nhanh hơn và hiệu quả hơn trong hội thảo hơn là sử dụng "Tôi làm công việc của mình một mình và đưa công cụ vào bạn, bạn xem xét nó một mình và quay lại với tôi và hãy làm điều này một lần nữa ".

Gợi ý

• Hãy tích cực và nhấn mạnh rằng nếu quy trình là đúng, bạn sẽ trở nên tốt hơn.

• Cố gắng hợp lý hóa hội thảo và theo dõi nó.

• Có thể dành một số chỗ cho phân tích "sói đơn độc", bằng cách bắt đầu hội thảo với mọi người tự thiết kế một vài kịch bản (thậm chí tốt hơn, trước hội thảo), sau đó phân loại và hợp nhất chúng.

Và nếu bạn không nghĩ làm điều đó là cần thiết, thì tốt thôi: hãy để BA làm việc một mình, nhưng sau đó hãy xem xét lại như một hội thảo, ít nhất là. Càng nhãn cầu thì càng tốt, để trích dẫn Eric S. Raymond 's Luật Linus' :

Given enough eyeballs, all bugs are shallow.

Bạn đã có một số câu trả lời khá hay ở đây rồi, vì vậy tôi sẽ tập trung vào một khía cạnh nhỏ mà cho đến nay đã bị bỏ qua. Vai trò của mỗi trong số ba Amigos sẽ có thể cung cấp cho phiên. Mỗi người cung cấp giá trị theo những cách khác nhau, mỗi người họ hiểu một tập các ràng buộc khác nhau.

Nói chung, BA sẽ có thể mang lại con đường hạnh phúc chính cho phiên, họ cũng có thể cung cấp các kịch bản thất bại chính từ góc độ kinh doanh. Chuyên môn kiểm tra sẽ có thể xác định các trường hợp cạnh và kịch bản bổ sung cần thiết để chứng minh hệ thống hoạt động trong mọi tình huống. Công việc của nhà phát triển không thực sự là thêm các kịch bản, mặc dù họ thường sẽ gặp sự cố kỹ thuật, công việc của họ cũng đảm bảo hiểu biết đầy đủ về các yêu cầu để họ truyền đạt ý nghĩa và thực hiện yêu cầu với mức tối thiểu của giao tiếp bổ sung.