Chúng ta có nên bỏ việc cố gắng làm nhanh nhẹn nếu QA mất 12 tuần?

Một người nào đó trong công ty của tôi gần đây đã đề xuất các thay đổi đối với sản phẩm cốt lõi của chúng tôi mà các nhà quản lý của chúng tôi cảm thấy nên kích hoạt những gì tôi đoán công ty của tôi xem xét chu trình QA đầy đủ (nghĩa là thử nghiệm toàn bộ bộ sản phẩm từ đầu). Rõ ràng QA của chúng tôi mất 12 tuần để thực hiện chu trình QA đầy đủ cho sản phẩm của chúng tôi. Vấn đề của tôi với điều này là chúng tôi đang cố gắng phát triển Agile (mặc dù chủ yếu là một nửa khẳng định). Chúng tôi sẽ thực hiện một loạt các lần chạy nước rút và sau đó thực hiện một bản phát hành, mà QA sẽ mất mãi mãi để đi qua tôi đoán. Câu hỏi thực sự là, nếu QA của chúng ta sẽ mất 12 tuần để thực hiện công việc của họ, chúng ta có nên từ bỏ việc cố gắng làm Agile không? Cái quái gì là cố gắng làm Agile trong tình huống như thế này?

Chà, câu trả lời trực tiếp cho câu hỏi của bạn sẽ là Mu Tôi sợ - không có đủ thông tin chi tiết để đưa ra dự đoán có căn cứ cho dù bạn nên hay không bỏ thử.

Điều duy nhất tôi khá tích cực là mức độ nhanh nhẹn nên được điều khiển bởi nhu cầu của khách hàng / thị trường (mà bạn không có thông tin về).

• ^{Ví dụ, là một người dùng IDE, tôi hoàn toàn hạnh phúc khi nâng cấp lên phiên bản mới một lần hoặc có thể hai lần một năm và tôi không bao giờ vội vàng làm điều đó. Tức là nếu chu kỳ phát hành của họ là 3 tháng ( 12 tuần ) thì tôi hoàn toàn hài lòng với điều đó.
   
  Mặt khác, tôi có thể dễ dàng tưởng tượng, giả sử, công ty thương mại tài chính phá sản nếu phải mất hơn một tháng để phần mềm của họ thích ứng với những thay đổi của thị trường - chu kỳ thử nghiệm 12 tuần trong trường hợp này sẽ là một con đường dẫn đến địa ngục. Bây giờ - nhu cầu sản phẩm của bạn trong vấn đề này là gì?}

Một điều khác cần xem xét là chất lượng cấp độ nào được yêu cầu để phục vụ nhu cầu khách hàng / thị trường của bạn?

• ^{Trường hợp điển hình - trong một công ty tôi từng làm việc, chúng tôi thấy chúng tôi cần một số tính năng mới trong một sản phẩm được cấp phép từ một số nhà cung cấp phần mềm. Không có tính năng này, chúng tôi phải chịu đựng khá mạnh mẽ, vì vậy, chúng tôi thực sự muốn chúng nhanh nhẹn và cung cấp cập nhật trong vòng một tháng.
   
  Và vâng, họ có vẻ nhanh nhẹn và vâng, họ đã phát hành bản cập nhật đó trong một tháng (nếu chu kỳ QA của họ là 12 tuần thì có khả năng họ đã bỏ qua nó). Và tính năng của chúng tôi hoạt động hoàn toàn tốt - đoán chúng tôi có nên hoàn toàn hạnh phúc? Không! chúng tôi đã phát hiện ra một lỗi hồi quy showstopper trong một số chức năng hoạt động tốt trước đây - vì vậy chúng tôi đã phải chịu đựng với phiên bản cũ hơn.
   
  Một tháng nữa trôi qua - họ đã phát hành một phiên bản mới: tính năng của chúng tôicũng có nhưng lỗi hồi quy tương tự cũng có: một lần nữa, chúng tôi đã không nâng cấp. Và một tháng nữa.
   
  Cuối cùng, chúng tôi đã có thể nâng cấp chỉ nửa năm sau rất nhiều vì sự nhanh nhẹn của họ.}

Bây giờ, hãy xem xét kỹ hơn một chút trong 12 tuần mà bạn đề cập.

Những lựa chọn bạn đã xem xét để rút ngắn chu kỳ QA? như bạn có thể thấy từ ví dụ trên, chỉ cần bỏ qua nó có thể không cung cấp cho bạn những gì bạn mong đợi để tốt hơn, nhanh nhẹn và xem xét các cách khác nhau để giải quyết nó.

Ví dụ, bạn đã xem xét các cách để cải thiện khả năng kiểm tra sản phẩm của mình chưa?

Hoặc, bạn đã xem xét giải pháp vũ phu chỉ cần thuê thêm QA? Tuy nhiên, có vẻ đơn giản, trong một số trường hợp, đây thực sự là con đường để đi. Tôi đã thấy quản lý thiếu kinh nghiệm đang cố gắng khắc phục các vấn đề về chất lượng sản phẩm bằng cách thuê một cách mù quáng ngày càng nhiều nhà phát triển cao cấp, nơi chỉ cần một cặp kiểm thử viên chuyên nghiệp trung bình là đủ. Khá thảm hại.

Điều cuối cùng nhưng không phải là ít nhất - tôi nghĩ người ta nên nhanh nhẹn về việc áp dụng các nguyên tắc nhanh nhẹn. Ý tôi là, nếu các yêu cầu của dự án không nhanh nhẹn (ổn định hoặc thay đổi chậm), thì tại sao phải bận tâm? Tôi đã từng quan sát quản lý hàng đầu buộc Scrum trong các dự án đang hoạt động hoàn hảo mà không có. Thật là một sự lãng phí. Không chỉ không có cải tiến trong việc giao hàng của họ mà tệ hơn, tất cả các nhà phát triển và người thử nghiệm đều trở nên không hài lòng.

cập nhật dựa trên sự làm rõ được cung cấp trong các ý kiến

Đối với tôi, một trong những phần quan trọng nhất của Agile là có một bản phát hành có thể chuyển đổi vào cuối mỗi lần chạy nước rút. Điều đó ngụ ý một số điều. Đầu tiên, một mức độ thử nghiệm phải được thực hiện để đảm bảo không có lỗi hiển thị nếu bạn nghĩ rằng bạn có thể phát hành bản dựng cho khách hàng ...

Shippable phát hành tôi thấy. Hừm. Hừm. Cân nhắc thêm một hoặc hai Lean vào ly cocktail Agile của bạn. Ý tôi là, nếu đây không phải là nhu cầu của khách hàng / thị trường thì điều này chỉ có nghĩa là lãng phí tài nguyên (thử nghiệm).

Tôi không thấy tội phạm gì khi coi việc phát hành cuối Sprint chỉ là một số điểm kiểm tra thỏa mãn nhóm.

• ^{dev: yeah rằng một cái nhìn đủ tốt để vượt qua người thử nghiệm; QA: yeah rằng một cái có vẻ đủ tốt cho trường hợp nếu cần thử nghiệm thêm shippable - thứ như thế. Nhóm (dev + QA) hài lòng, đó là nó.}

... Điểm quan trọng nhất mà bạn đưa ra là vào cuối câu trả lời của bạn về việc không áp dụng nhanh nhẹn nếu các yêu cầu không nhanh nhẹn. Tôi nghĩ rằng đây là tại chỗ. Khi chúng tôi bắt đầu làm nhanh, chúng tôi đã quay số và hoàn cảnh có ý nghĩa. Nhưng kể từ đó, mọi thứ đã thay đổi đáng kể và chúng tôi đang bám vào quá trình mà nó có thể không còn ý nghĩa nữa.

Bạn đã nhận nó chính xác. Cũng từ những gì bạn mô tả, có vẻ như bạn đã đạt đến trạng thái (sự trưởng thành của nhóm / quản lý và mối quan hệ khách hàng) cho phép bạn sử dụng phát triển mô hình lặp thường xuyên thay vì Scrum. Nếu vậy thì bạn cũng có thể quan tâm để biết rằng theo kinh nghiệm của tôi trong các trường hợp như lặp đi lặp lại thường xuyên đó cảm thấy năng suất hơn Scrum. Năng suất cao hơn nhiều - đơn giản là có quá ít chi phí, đơn giản là việc tập trung vào phát triển dễ dàng hơn nhiều (để QA tương ứng tập trung vào thử nghiệm).

• ^{Tôi thường nghĩ về điều đó của Ferrari (như lặp đi lặp lại thường xuyên) so với Landrover (như Scrum).
   
  Khi lái xe trên đường cao tốc (và dự án của bạn dường như đã đến đường cao tốc đó ), Ferrari đã đánh bại Landrover.
   
  Đó là off-road nơi một người cần xe jeep không phải xe thể thao - Ý tôi là nếu yêu cầu của bạn không thường xuyên và / hoặc nếu kinh nghiệm làm việc nhóm và quản lý không tốt, bạn sẽ phải chọn Scrum - đơn giản vì cố gắng đi thường xuyên sẽ giúp bạn bị mắc kẹt - như Ferrari sẽ bị mắc kẹt ngoài đường.}

Sản phẩm đầy đủ của chúng tôi thực sự được tạo thành từ nhiều bộ phận nhỏ hơn mà tất cả có thể được nâng cấp độc lập. Tôi nghĩ rằng khách hàng của chúng tôi rất sẵn lòng nâng cấp những thành phần nhỏ hơn thường xuyên hơn. Dường như với tôi rằng có lẽ chúng ta nên tập trung vào việc phát hành và QA'ing những thành phần nhỏ hơn đó vào cuối nước rút thay vào đó ...

Trên âm thanh như một kế hoạch tốt. Tôi đã làm việc trong một dự án như vậy một lần. Chúng tôi đã phát hành các bản phát hành hàng tháng với các bản cập nhật được bản địa hóa trong các thành phần rủi ro thấp nhỏ và đăng xuất QA cho những bản này dễ dàng như nó có được.

• ^{Một điều cần lưu ý cho chiến lược này là có một xác minh có thể kiểm chứng được rằng sự thay đổi được bản địa hóa ở nơi dự kiến. Ngay cả khi điều này có liên quan đến việc so sánh tệp từng bit một cho các thành phần không thay đổi, hãy tiếp tục hoặc bạn sẽ không vận chuyển nó. Điều quan trọng là, QA là người chịu trách nhiệm phát hành chất lượng chứ không phải chúng tôi là nhà phát triển.
   
  Điều đau đầu của người kiểm tra là đảm bảo rằng những thay đổi bất ngờ đã không xảy ra - bởi vì thật lòng mà nói, với tư cách là một nhà phát triển, tôi có đủ thứ khác để lo lắng về điều đó quan trọng hơn với tôi. Và vì điều đó, họ (những người thử nghiệm) thực sự cần bằng chứng chắc chắn rằng mọi thứ đang được kiểm soát với việc phát hành mà họ đã thử nghiệm.}

Oh, tôi cảm thấy nỗi đau của bạn. Có một số thay đổi nghiêm trọng bạn cần thực hiện cho nhóm QA để việc này hoạt động.

Lời khuyên của tôi là chia đội thành ba đội:

Kiểm tra tính năng - Quay vòng nhanh để kiểm tra các phát triển mới.

Kiểm tra hồi quy - Kiểm tra đầy đủ sản phẩm trước khi ra khỏi cửa. Điều này không nên mất 3 tháng, ngay cả sau khi giảm quy mô đội vì hầu hết các lỗi sẽ được tìm thấy bởi đội đầu tiên.

Kiểm tra tự động - Viết một bộ đầy đủ các bài kiểm tra hồi quy để tăng tốc công việc của nhóm kiểm tra hồi quy.

Đội thứ ba là một phần thưởng, nhưng nếu bạn không thể có hai đội đầu tiên thì bạn cũng có thể là thác nước.

Bằng cách minh hoạ:

Lưu ý rằng nhóm QA của bạn có thể đang hoạt động bên ngoài vòng tròn (ATDD) và bạn đang làm việc bên trong.

Tôi nghĩ làm việc theo cách đó là ổn; nếu bạn có thể chứng minh trong các bài kiểm tra tự động của mình rằng bạn đang đáp ứng các yêu cầu của khách hàng trên mỗi lần chạy nước rút, bạn có thể cho phép QA thực hiện các bài kiểm tra của họ một cách thoải mái và đến với bạn với những khiếm khuyết, sau đó bạn có thể làm việc trong lần chạy nước rút tiếp theo.

Có vẻ như bạn có vấn đề "Định nghĩa Xong".

Cho rằng nhóm QA của bạn là bên ngoài và chỉ liên quan đến các bản phát hành của khách hàng, bạn không thể dựa vào họ để phản hồi kịp thời về các vấn đề. Điều đó có nghĩa là nếu bạn muốn phản hồi nhanh chóng, bạn sẽ phải mang một mức độ thử nghiệm "nội bộ" nào đó cho nhóm.

Hãy đối xử với Nhóm QA như thể họ không tồn tại. Đạo luật là nếu bản phát hành của bạn vào cuối giai đoạn nước rút sẽ được triển khai đến môi trường quan trọng nhất của bạn vào ngày hôm sau. Phần mềm không được thực hiện cho đến khi nó sẵn sàng đến tay khách hàng.

QA không nên tìm gì cả.

Điều này sẽ khó hơn để có được. Bạn có thể sẽ có một số điều lén lút trong vài lần đầu tiên. Kiểm tra chấp nhận tự động và kiểm tra "hồi quy" là những người bạn tốt nhất của bạn ở đây. TDD sẽ giúp bạn xây dựng phần lớn các bộ như vậy. Bạn sẽ có thể biết - một cách nhanh chóng - nếu bạn đã phá vỡ bất cứ điều gì.

Bạn có đại diện khách hàng / chủ sở hữu sản phẩm có thể thấy một bản phát hành nhất định trước khi QA được thực hiện với nó và cung cấp cho bạn sự phản hồi có thẩm quyền về nó không? Nếu vậy, bạn có thể làm và có hầu hết lợi ích của các phương pháp nhanh nhẹn trong khi coi QA là nguồn phản hồi thứ yếu, hơi chậm. Một bản phát hành sẽ chỉ "chính thức sẵn sàng" sau khi QA hoàn thành, nhưng bạn sẽ không phải đợi họ trước khi bắt đầu bản tiếp theo.

Nhưng nếu các quy tắc của công ty nói rằng khách hàng không được xem bản phát hành trước khi QA được thực hiện với nó, thì bạn có thể quên đi việc nhanh nhẹn, cho đến khi bạn thay đổi các quy tắc đó.

Quá trình bạn mô tả không phải là một quy trình nhanh. Các đội có mức độ nhanh nhẹn cao có thể cung cấp các bản dựng đáng tin cậy và có khả năng đáng tin cậy mỗi lần chạy nước rút. Trong hầu hết các triển khai nhanh, chức năng QA được xây dựng trong nhóm nhanh nhẹn giúp đạt được mục tiêu này.

Nếu bạn, người dẫn đầu dự án của bạn, chủ sở hữu sản phẩm của bạn và nhà phát triển không làm việc cùng nhau và bạn không có kế hoạch cải tiến (hồi tưởng) thì hãy đặt tên cho quy trình của bạn một cái gì đó khác và tiếp tục. Có vẻ như các vấn đề của nhóm bạn không phải là lỗi của người quản lý hoặc QA. Họ dường như đang phản ứng với một số vấn đề mang tính hệ thống phát ra từ tổ chức phát triển. Tất cả không bị mất nếu nhóm sẵn sàng chịu trách nhiệm và bắt đầu làm việc với các bên liên quan.

Bạn có thể thử ba điều. Một, đảm bảo mỗi bên liên quan có vai trò được xác định chính xác và mỗi người hiểu trách nhiệm của họ. Hai, ổn định bản dựng và sau đó nhận được tín hiệu từ QA mà không đưa ra nhiều thay đổi. Ba, viện kiểm tra tự động hóa. Nhóm QA sẽ yêu bạn vì điều đó.

Thật đáng tiếc khi thông tin phản hồi mất quá nhiều thời gian nhưng tôi không nghĩ rằng nó đáng để dừng lại với sự nhanh nhẹn. Vào cuối cuộc đua nước rút (hoặc một vài) bạn phát hành một sản phẩm mà bạn tự tin rằng nó có thể được đưa ra thị trường. Đối với nhóm của bạn nhanh nhẹn mang lại khả năng tập trung vào công việc sẽ được thực hiện và giữ cho sản phẩm đáng tin cậy. Khi QA tìm thấy các vấn đề, tôi đề nghị tạo báo cáo lỗi cho các vấn đề này và giải quyết chúng trong lần chạy nước rút tiếp theo (nếu chúng có mức độ ưu tiên đủ cao).

Các thử nghiệm lĩnh vực sản phẩm của chúng tôi mất 8 tuần cộng với việc chúng tôi phụ thuộc vào người trồng bên ngoài. Tuy nhiên, bằng cách làm nhanh nhẹn, chúng tôi có thể tập trung vào công việc trong tay và tạo ra một phiên bản mới thực sự nhanh chóng khi cần thiết.

Vấn đề nằm (trong mắt bạn) với bộ phận QA vấn đề có thể được giải quyết ở đó không? Bạn đã thảo luận về nó?

12 tuần là dài, nhưng hy vọng QA có thể cung cấp cho bạn thông tin phản hồi và báo cáo lỗi trong thời gian đó (thay vì sau ba tháng).

Sau đó, bạn vẫn có thể trả lời các vấn đề quan trọng nhất một cách nhanh nhẹn và có thể khắc phục nhiều vấn đề nếu không phải tất cả trước khi chúng kết thúc!

Những người QA đang làm gì trong khi bạn đang thực hiện nhiều lần chạy nước rút? Âm thanh như họ cảm thấy cần phải kiểm tra mọi thứ sau mỗi thay đổi (Đó là lý do tại sao họ chờ đợi cả đống thay đổi.).

Nhóm phát triển nhanh nhẹn, nhưng phần còn lại của công ty thì không.

Bất cứ ai chịu trách nhiệm về QA đều không biết anh ấy / cô ấy đang làm gì hoặc họ đã thực hiện một trò ảo thuật tâm trí Jedi cho quản lý cấp trên và được phép dành thời gian ngọt ngào của họ. Làm thế nào QA có thể mất nhiều thời gian hơn phát triển?