Tôi có thể sử dụng những đối số nào để bán ra khái niệm BDD cho một nhóm miễn cưỡng chấp nhận nó?

Tôi là một chút của một người ủng hộ giọng nói của phương pháp phát triển hướng hành vi (hay còn gọi là BDD). Tôi đã áp dụng BDD được vài năm rồi và đã áp dụng StoryQ làm khuôn khổ lựa chọn của tôi khi phát triển các ứng dụng DotNet. Mặc dù tôi đã thử nghiệm đơn vị trong nhiều năm và trước đây đã chuyển sang cách tiếp cận thử nghiệm đầu tiên, tôi nhận thấy rằng tôi nhận được nhiều giá trị hơn khi sử dụng khung BDD, bởi vì các thử nghiệm của tôi nắm bắt được ý định của các yêu cầu trong tương đối xóa tiếng Anh trong mã của tôi và bởi vì các bài kiểm tra của tôi có thể thực hiện nhiều xác nhận mà không kết thúc bài kiểm tra giữa chừng - có nghĩa là tôi có thể thấy các xác nhận cụ thể nào vượt qua / thất bại trong nháy mắt mà không cần gỡ lỗi để chứng minh.

Đây thực sự là phần nổi của tảng băng đối với tôi, vì tôi cũng nhận thấy rằng tôi có thể gỡ lỗi cả mã kiểm tra và mã triển khai theo cách được nhắm mục tiêu hơn, với kết quả là năng suất của tôi tăng lên đáng kể và tôi có thể nhiều hơn dễ dàng xác định nơi xảy ra lỗi nếu xảy ra sự cố để chuyển tất cả sang bản dựng tích hợp do đầu ra đi vào nhật ký bản dựng. Hơn nữa, StoryQ api có một cú pháp lưu loát đáng yêu, dễ học và có thể được áp dụng theo một số cách đặc biệt, không yêu cầu phụ thuộc bên ngoài để sử dụng nó.

Vì vậy, với tất cả những lợi ích này, bạn sẽ nghĩ thật dễ dàng để giới thiệu khái niệm này với phần còn lại của nhóm. Thật không may, các thành viên khác trong nhóm không ngần ngại nhìn vào StoryQ để đánh giá nó một cách chính xác (chứ đừng nói đến việc giải trí ý tưởng áp dụng BDD) và đã thuyết phục nhau thử và loại bỏ một số yếu tố StoryQ khỏi khung thử nghiệm cốt lõi của chúng ta, thậm chí mặc dù ban đầu họ ủng hộ việc sử dụng StoryQ và mặc dù mã họ muốn xóa không ảnh hưởng đến bất kỳ phần nào khác trong hệ thống thử nghiệm của chúng tôi. Làm như vậy sẽ giúp tăng khối lượng công việc của tôi một cách đáng kể và thực sự đi ngược lại, vì tôi bị thuyết phục qua kinh nghiệm thực tế rằng đó là cách tốt hơn để làm việc theo cách thử nghiệm đầu tiên trong môi trường làm việc cụ thể của chúng tôi và chỉ có thể dẫn đến lớn hơn cải thiện chất lượng phần mềm của chúng tôi, cho tôi đã tìm thấy nó dễ dàng hơn để gắn bó với thử nghiệm đầu tiên bằng cách sử dụng BDD. Để làm rõ hơn, phần lớn các bài kiểm tra đơn vị chúng tôi có xu hướng khá dễ vỡ và khó bảo trì, một sự kiểm soát từ nhiều năm thử nghiệm được áp dụng kém trong đó việc miễn cưỡng tuân thủ quy trình dựa trên thử nghiệm đã thấy các nhà phát triển bỏ thói quen cũ và thực hiện tất cả các thử nghiệm của họ khi kết thúc dự án (những người này tự xưng là Agile!).

Vì vậy, câu hỏi thực sự đi xuống như sau:

1. Tôi có thể sử dụng những lý lẽ nào để thực sự lái xe về nhà rằng nhóm này sẽ tốt hơn khi sử dụng StoryQ, hoặc ít nhất là áp dụng phương pháp của BDD?
2. Bạn có thể chỉ cho tôi bất kỳ bằng chứng giai thoại nào mà tôi có thể sử dụng để hỗ trợ cho lập luận của mình để áp dụng BDD làm phương pháp lựa chọn tiêu chuẩn của chúng tôi không?
3. Những đối số truy cập nào bạn có thể nghĩ về điều đó có thể gợi ý rằng mong muốn của tôi để khuyến khích nhóm áp dụng BDD có thể bị lỗi? Có, tôi rất vui khi được chứng minh là sai với điều kiện là một lý lẽ hợp lý.

LƯU Ý : Tôi không ủng hộ rằng chúng tôi viết lại toàn bộ các thử nghiệm của mình, mà chỉ đơn giản là bắt đầu làm việc theo cách khác cho tất cả các công việc thử nghiệm trong tương lai và tốt nhất là theo cách chúng tôi thu hút khách hàng.

Và đối với những người bạn muốn tìm hiểu thêm về BDD, các liên kết sau có thể hữu ích:

• http://dannorth.net/int Giới thiệu-bdd /
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Intesistion

_{Đối với những người quan tâm đến nhiều chi tiết hơn, chúng tôi là một nhóm nhỏ gồm 4 người đang thực hiện khoảng 5 dự án lớn. "Thử nghiệm thí điểm" cho BDD ban đầu được thực hiện trong khoảng 2 tháng, với khoảng thời gian khoảng 4 tháng sau đó. Nhóm chấp nhận rằng tôi nên tiếp tục làm việc theo cách này và được thực hiện thử nghiệm của riêng họ. Tôi đã bị BDD khoảng 2 năm kể từ khi thử nghiệm kết thúc, trong khi những người khác đã trở nên rất giỏi trong việc giải quyết vấn đề. Thay vì buộc phải "đối đầu" về vấn đề này, tôi đang tìm cách để nhẹ nhàng thuyết phục đội thoát khỏi hậu phương tập thể của họ và dành thời gian để làm việc của họ.}

Những đối số nào tôi có thể sử dụng để thực sự lái xe về nhà rằng sẽ tốt hơn nếu sử dụng StoryQ, hoặc ít nhất là áp dụng phương pháp của BDD?

"Khách hàng muốn nó."

IMO bạn muốn bán BDD cho khách hàng / chuyên gia tên miền của mình ít nhất là cho nhóm phát triển.

BDD là một quá trình hợp tác bên ngoài nơi có nhiều bên liên quan. Lợi ích của BDD không chỉ là các nhà phát triển tự động suy ra mã kiểm tra của họ từ các thử nghiệm chấp nhận, mà còn nằm trong sự hợp tác sáng tạo diễn ra giữa các nhân viên kỹ thuật và doanh nghiệp để tạo ra các thông số kỹ thuật có giá trị, được xác định rõ về hành vi dự định của hệ thống.

Cho phép khách hàng / nhà phân tích kinh doanh truy cập vào một giao diện nơi họ có thể chạy từng đặc tả thực thi, kiểm soát trạng thái của họ và xem tiến trình triển khai của họ thường được đánh giá cao.

Có bài thuyết trình của Dan North về cách bạn có thể bán BDD cho doanh nghiệp: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. Trong một nhóm miễn cưỡng chấp nhận BDD, có thể không có "đối số" nào mà bạn có thể sử dụng để "chuyển đổi" đồng nghiệp của mình thành áp dụng toàn diện.
    
   Tôi nghĩ điều tốt nhất bạn có thể làm là thuyết phục họ dùng thử ("thử khói", "chạy khô", "dự án thí điểm") - đặc biệt nếu bạn nói rõ rằng bạn sẽ bỏ ý tưởng nếu thử nghiệm kết quả là tiêu cực.
2. Cách tiếp cận của bạn để tìm bằng chứng giai thoại hoàn toàn phù hợp với ý tưởng của nhóm thuyết phục để thử. Vì thế, tôi chỉ đơn giản là tìm kiếm trên web một cái gì đó như "Câu chuyện thành công phát triển theo hướng hành vi" và chọn những gì tôi cảm thấy dễ sử dụng hơn.
3. Có một số đối số mà tôi có thể nghĩ ra có thể gợi ý rằng mong muốn của bạn để chuyển đổi các nỗ lực của nhóm thành BDD có thể bị lỗi.
    
   Không ai trong số này đặc biệt mang tính xây dựng, đặc biệt là từ quan điểm của "người ủng hộ thay đổi", nhưng thật không may, bạn có thể sẽ phải đối phó với chính xác các biện pháp tu từ này ( BTDTGTTS ):
    
   • bạn không thể đảm bảo rằng năng suất chung của nhóm sẽ được cải thiện
   • bạn không thể đảm bảo rằng những nỗ lực đầu tư vào việc áp dụng BDD sẽ mang lại ROI đáng kể
   • nhóm đã làm đủ tốt mà không có BDD, nguy cơ thay đổi cách tiếp cận hiện tại là không chính đáng
   • Google (hoặc Microsoft hoặc IBM - chỉ cần điền vào tên của bất kỳ nhà cung cấp phần mềm "đáng kính" nào) sẽ ổn nếu không có BDD, điều đó "chứng minh" rằng BDD là không cần thiết
   • phương pháp tiếp cận không phải là BDD không có cơ hội công bằng trong thử nghiệm so sánh
   • BDD có thể nói chung là ổn nhưng đối với điều này và mô-đun / dự án đó thì không thể áp dụng

Theo kinh nghiệm của tôi, cách ít đau đớn nhất để giải quyết các đối số truy cập như được liệt kê ở trên là bằng cách thực hiện một lần chạy thử có kiểm soát hạn chế cho một thay đổi được đề xuất.

Trạng thái "Thử nghiệm có giới hạn" về cơ bản vô hiệu hóa ba trong số bốn đối số ở trên, ngoại trừ một về "nhà cung cấp đáng kính", có thể chống lại bằng cách cung cấp bằng chứng giai thoại về câu chuyện thành công (bằng chứng giai thoại có thể sẽ không có tác dụng cho "thay đổi lớn" kiểm tra hạn chế nó là đủ tốt).

Nếu thay đổi thực sự đáng giá và việc chạy thử được sắp xếp hợp lý, bạn sẽ nhận thấy sự thay đổi tích cực trong thái độ của đội ngũ và quản lý, giúp việc chuyển đổi sang thay đổi toàn diện diễn ra suôn sẻ và không gây đau đớn.

Một lợi ích khác của việc chạy thử hạn chế là nó cho phép bạn làm rõ và điều chỉnh chi tiết quy trình mục tiêu mà không gây ra quá nhiều rắc rối và có nguy cơ "thiệt hại danh tiếng" thấp hơn cho ý tưởng. Mỗi lần tôi tham gia vào các lần chạy thử như vậy , tôi rất ngạc nhiên khi thấy việc chuyển sang áp dụng quy mô đầy đủ sẽ có những chi tiết quan trọng nhất được đặt ra và làm rõ trong quá trình chạy thử.

Nó có thể là thời gian để tuyển dụng quản lý. Nếu bạn đã thử và thấy kết quả chắc chắn, nhưng nhóm đang chùn bước, ban quản lý có thể phải tham gia.

Điều này đặc biệt đúng nếu họ đang làm tổn thương các thành viên nhóm làm việc hiệu quả nhất. Hãy chuẩn bị cho phản ứng dữ dội. Bạn có thể bắt đầu bằng cách tiếp cận quản lý và tìm cách để nhóm ngừng bảo vệ bạn bằng cách loại bỏ các trường hợp thử nghiệm của bạn.