Scrum - Nhà phát triển làm việc bên ngoài Sprint

Nhóm Scrum

• 3 x Nhà phát triển
• 2 x Người thử
• 1 x Nhà phân tích kiểm tra tự động hóa

Chúng tôi không phải là một nhóm đa chức năng trong đó các nhà phát triển không thử nghiệm và những người thử nghiệm không phát triển. Tôi tin rằng đây là nguyên nhân gốc rễ của vấn đề.

Chúng tôi hiện đang chạy nước rút hai tuần.

Khi bắt đầu chạy nước rút, mọi người đều bận rộn, các nhà phát triển bắt đầu công việc phát triển và những người thử nghiệm đang chuẩn bị thử nghiệm (viết các trường hợp thử nghiệm, v.v.)

Khi người kiểm tra đã hoàn thành việc chuẩn bị của họ, bây giờ họ đang chờ công việc phát triển hoàn tất HOẶC công việc phát triển hoàn tất và các nhà phát triển đang chờ phản hồi / lỗi.

Các nhà phát triển bị ngứa chân ở đây và bắt đầu làm việc với các mục trong hồ sơ tồn đọng bên ngoài nước rút hiện tại. Điều này đã tạo ra một ảnh hưởng kỳ lạ, theo đó chúng tôi luôn phát triển các lần chạy nước rút tiếp theo trong giai đoạn nước rút hiện tại. Đối với tôi điều này không cảm thấy đúng.

Từ quan điểm quản lý, họ muốn các nhà phát triển làm việc hơn là ngồi vào bàn làm việc mà không làm gì nhưng đồng thời tôi cảm thấy mục tiêu của nhóm Scrum và chỉ nên tập trung vào nước rút hiện tại. Tôi muốn nhóm của chúng tôi là đa chức năng nhưng tiếc là nó không thể đạt được. Những người thử nghiệm không có các kỹ năng cần thiết để thực hiện công việc phát triển và phần lớn các nhà phát triển có ý kiến ​​rằng thử nghiệm nằm bên dưới họ.

Đây có được coi là một vấn đề trong scrum? Có một giải pháp cho điều này? Scrum chỉ làm việc với các nhóm đa chức năng?

Tôi muốn biết kinh nghiệm của những người khác với điều này nếu có thể :)

Đó là một vấn đề khá phổ biến, gây ra bởi đường ống . Nhóm nghiên cứu là đa chức năng, nhưng tất nhiên có các silo bên trong làm giảm hiệu suất.

Đầu tiên tôi muốn lưu ý một vài điều mà tôi nghĩ là quan trọng:

1. Nếu các nhà phát triển của bạn làm việc lặp lại trước, họ sẽ làm trống trước cuộc họp lập kế hoạch của bạn. Người quản lý sản phẩm của bạn và nhóm cần thảo luận về những gì có giá trị nhất cho lần lặp tiếp theo đúng. Ưu tiên không nên được thực hiện một cách hiệu quả bởi các nhà phát triển vì họ không có gì tốt hơn để làm.

2. Cho dù bạn phân chia và sắp xếp các lần lặp như thế nào, bạn thực sự không thể khiến tất cả mọi người bị chiếm dụng mọi lúc và có một nhóm duy nhất với một cuộc họp lập kế hoạch miễn là nhóm của bạn có các chuyên gia làm việc trong các silo. Ngay cả với cách tiếp cận thác nước thuần túy, bạn vẫn sẽ cần phải "ném đồ lên tường" và chờ phản hồi.

3. Bạn cũng có một vấn đề là thường một câu chuyện cần phải có giai đoạn phát triển, tiếp theo là giai đoạn thử nghiệm, tiếp theo là giai đoạn sửa lỗi, tiếp theo là ... điều này thực sự có thể khiến nhóm của bạn hoạt động kém hiệu quả - đặc biệt là nếu chúng hoạt động trước , bởi vì họ cần chuyển đổi ngữ cảnh.

Rõ ràng có một chi phí rất thực tế cho tình huống này: nhóm không hợp tác. Tôi đã gặp phải điều này mỗi khi có một nhóm QA tham gia, vì vậy tôi đã có một ít thời gian để thử nghiệm các giải pháp khác nhau.

Điều làm việc rất tốt cho tôi là hai công cụ này:

1. Nhấn mạnh nguyên tắc rằng toàn đội chịu trách nhiệm hoàn thành công việc. Từ chối các câu chuyện "dev xong", vì chúng là một cách để các nhà phát triển nói rằng "không phải vấn đề của tôi nữa", cả hai đều không mang tính xây dựng và sai lầm một cách rõ ràng. Nếu một nhóm không cung cấp một câu chuyện mà họ chấp nhận, đó là toàn bộ nhóm đã không phân phối.

2. Để chiếm thời gian của cả nhà phát triển và QA, hãy ghép nối chúng . Đây là cách tốt nhất để chia sẻ kiến ​​thức chuyên môn và kiến ​​thức tên miền mà bạn có thể chọn. Các nhà phát triển có thể giúp người kiểm tra tự động hóa các nhiệm vụ của họ. Người kiểm thử có thể chỉ cho nhà phát triển nơi cần kiểm tra mã vì nó dễ vỡ. Cả hai hợp tác và làm việc nhanh hơn không.

Sử dụng hai kỹ thuật này, nhóm sẽ bớt im lặng và hiệu quả hơn. Trong khi những người thử nghiệm và nhà phát triển rất khó có khả năng trao đổi công việc, họ sẽ có thể làm việc theo nhóm và giải quyết vấn đề trong nội bộ, thay vì đổ lỗi cho nhau.

Không có vấn đề gì với cách bạn đang làm việc liên quan đến SCRUM và chạy nước rút, miễn là nó sẽ được ghi nhận vào thời điểm đánh giá rằng công việc của nhà phát triển đã kết thúc trong thời gian ngắn hơn (và mất ít thời gian hơn) sau đó lên kế hoạch. Điều này sẽ cho phép nhóm đảm nhận nhiều điểm câu chuyện hơn cho lần chạy nước rút tiếp theo. Rốt cuộc, quan điểm của nước rút là để có kế hoạch tốt hơn. Rõ ràng bạn vẫn còn chỗ để cải thiện.

chúng tôi luôn phát triển các lần chạy nước rút tiếp theo trong giai đoạn nước rút hiện tại

Ái chà! Đây là kỹ thuật không thể có trong Scrum. Bạn không biết các mục tồn đọng sẽ là gì trong lần chạy nước rút tiếp theo, nghĩa là sẽ được thiết lập khi bắt đầu lần chạy nước rút tiếp theo trong phiên lập kế hoạch nước rút.

Thật thú vị khi tìm hiểu về những cách sáng tạo mới mà các tổ chức phát minh ra để phá hoại Scrum.

Scrum tối ưu hóa cho nhóm , không phải cá nhân. Toàn bộ quan điểm của scrum là để nhóm trở nên hiệu quả. Nếu các nhà phát triển bắt đầu làm việc với những thứ bên ngoài nước rút hiện tại, thì họ đang làm cho nhóm trở thành một kẻ bất đồng. Nó cũng cho thấy rằng bạn thất bại phần nào trong quá trình lập kế hoạch của mình, nếu bạn không lập kế hoạch cho đủ công việc để lấp đầy mùa xuân.

Nếu các nhà phát triển đã hết nhiệm vụ phát triển, họ hoàn toàn nên tham gia và giúp đỡ những người thử nghiệm hoặc các nhà văn công nghệ hoặc nhà thiết kế - bất kỳ ai trong nhóm. Họ không nhất thiết phải viết các bài kiểm tra thực tế (mặc dù, họ nên ), nhưng họ vẫn có thể tham gia vào quá trình kiểm tra. Họ có thể viết các kịch bản giúp người kiểm tra hiệu quả hơn hoặc họ có thể thảo luận đơn giản với người kiểm tra xem thử thách của họ là gì và giúp họ vượt qua những thách thức đó (ví dụ: thêm thuộc tính id vào các yếu tố trang web, cung cấp móc hoặc API mà người kiểm tra có thể sử dụng trong các thử nghiệm của họ, vv).

Tôi nghĩ cốt lõi của vấn đề là nếu các nhà phát triển của bạn không luôn làm việc trong giai đoạn nước rút hiện tại, thì họ vẫn chưa làm việc theo nhóm. Chủ scrum của bạn nên chú ý và hướng tới việc nhóm làm việc như một đơn vị thay vì tập hợp các cá nhân.

Tôi cũng đề nghị rằng đây là một vấn đề quản lý. Nếu họ đang gây áp lực lên các nhà phát triển để luôn bận rộn thì họ đã không chấp nhận hoàn toàn scrum. Đây là một điều khác mà chủ scrum có thể giúp đỡ. Họ có thể làm việc với ban quản lý để giúp họ hiểu cách thức hoạt động của scrum để họ có thể giúp hỗ trợ và khuyến khích các nhóm phát triển thay vì lật đổ họ.

Tôi nghĩ vấn đề chính ở đây là:

phần lớn các nhà phát triển có ý kiến ​​rằng thử nghiệm nằm bên dưới họ

Cách chúng tôi xử lý việc này trong công ty của chúng tôi là chúng tôi đã hỏi các nhà phát triển làm thế nào họ có thể nói rằng họ thực sự đã hoàn thành công việc nếu họ không thể chứng minh điều đó. Tất nhiên, cách duy nhất để chứng minh điều đó là chứng minh rằng mã họ viết thực sự hoạt động và điều này được thực hiện thông qua thử nghiệm. Cần phải chỉ ra cho họ rằng nếu họ đồng ý tham gia thử nghiệm thì việc kiểm tra sẽ được thực hiện nhanh hơn và họ sẽ có nhiều thời gian hơn để mã hóa các chức năng bổ sung (cũng cần phải được kiểm tra).

Đặt điểm kiểm tra mã của bạn không nằm dưới cấp độ nhà phát triển. Nó là một phần không thể thiếu trong quá trình phát triển. Nó không thể được tách ra khỏi chỉ mã hóa. Bất cứ ai cũng có thể mã. Không phải ai cũng có thể viết mã và chứng minh rằng những gì họ mã hóa thực sự hoạt động.

Một cách khác để giữ cho các nhà phát triển bận rộn là để họ làm việc trên các mã kiểm tra tự động cho các chức năng mà họ đã phát triển trong giai đoạn nước rút. Những thử nghiệm sau đó có thể được sử dụng để kiểm tra hồi quy sẽ được chạy định kỳ.

Dù bằng cách nào, làm điều gì đó không được lên kế hoạch khi bắt đầu nước rút là một điều không nên. Không nên làm gì hơn là làm những việc không theo kế hoạch. Chức năng mà họ viết trong những trường hợp đó rất có thể không đáp ứng tiêu chí DoD (Định nghĩa Hoàn thành), vì có lẽ nó không được kiểm tra tốt, vì những người kiểm tra đã bận rộn bằng cách kiểm tra những gì đã được lên kế hoạch ban đầu. Đây là một cách chắc chắn để giới thiệu các lỗi và làm giảm chất lượng sản phẩm, sau đó đưa nhóm vào vòng xoáy xuống của các vấn đề hồi quy và chuyển đổi ngữ cảnh, dẫn đến căng thẳng, giảm vận tốc và cuối cùng, rời khỏi nhóm vì nó.

Về lý thuyết, tất cả các thành viên của một nhóm SCRUM nên có cùng kiến ​​thức, để mỗi thành viên có thể nhận mọi nhiệm vụ từ mọi thành viên khác. Nếu không, bạn nên truyền bá kiến ​​thức.

Nhưng trong thực tế luôn có một số loại chuyên môn. Phần mềm có thể phức tạp, thành viên trong nhóm có các kỹ năng khác nhau, v.v. Việc chia nhóm thành nhà phát triển và người thử nghiệm chỉ là một ví dụ (rất phổ biến) về chuyên môn hóa.

Truyền bá kiến ​​thức có thể mất nhiều thời gian hơn quản lý muốn chấp nhận.

Theo kinh nghiệm của tôi, bạn có thể làm một số điều:

• Đừng làm cho nhóm quá nhỏ. Ví dụ, nếu bạn có 4 nhà phát triển và 4 người thử nghiệm thì việc chuyển một tác vụ sang nhà phát triển hoặc người thử nghiệm khác sẽ dễ dàng hơn rất nhiều khi chỉ có 3/2 như trong ví dụ này.
• Cố gắng tách ra các nhiệm vụ lớn hơn. Nếu bạn có nhiều nhiệm vụ nhỏ hơn, bạn sẽ linh hoạt hơn.
• Xác định một số nhiệm vụ tùy chọn có thể được thực hiện nếu còn thời gian.

Những đề xuất này có thể không phải là lý thuyết SCRUM 100%, nhưng trước tiên bạn phải tiếp tục phát triển. SCRUM chỉ là một hộp công cụ.

Có vẻ như bạn cần phải đồng bộ hóa nhóm của bạn. Như thế

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Nếu tôi hiểu các anh chàng tự động hóa thử nghiệm phải bắt đầu sớm vài ngày.

Nhưng tôi cảm thấy một vấn đề trong nhóm của bạn: Tôi có một vấn đề với các nhà phát triển không kiểm tra mã của riêng họ. Nếu những người kiểm tra chuẩn bị kiểm tra mà không xem lại mã, có lẽ họ chỉ đang thực hiện các kiểm tra hộp đen không tính đến các điểm quyết định của chương trình đã phát triển. Bạn hài lòng với chất lượng phần mềm của bạn?