Lừa đảo là gì?

Tôi đã nghe tràn ngập đề cập trong bối cảnh Agile hoặc Extreme Programming. Nó dường như là một bổ sung để ghép nối.

Chính xác thì nó là gì? Khi nào nên áp dụng? Làm thế nào để bạn làm điều đó tốt?

Ý tưởng là mọi người trong nhóm của bạn làm việc trên cùng một câu chuyện cùng một lúc. Thay vì mọi người tập trung vào các nhiệm vụ khác nhau, mọi người tập trung vào một nhiệm vụ tại một thời điểm cho đến khi hoàn thành. Sau đó, họ chuyển sang điều tiếp theo, nơi tất cả họ cùng làm việc với nó.

Điều này giúp các đội đấu tranh hoàn thành câu chuyện trước khi kết thúc nước rút. Thường thì các đội hoàn thành 80% tất cả các câu chuyện, nhưng không có câu chuyện nào hoàn thành. Điều này ít hữu ích hơn hoàn thành 80% câu chuyện, vì những câu chuyện còn dang dở (thực sự) không có giá trị đối với người dùng cuối. Dễ dàng hoàn thành câu chuyện hơn khi mọi người trong nhóm tập trung vào một câu chuyện cùng một lúc. Đây là động lực đằng sau tràn ngập.

Có một số khó khăn ở đây. Chẳng hạn, QA không thể luôn kiểm tra mọi thứ trước khi chúng được xây dựng (hoặc thậm chí được thiết kế). Trong trường hợp này, bạn nên sớm thiết lập một thiết kế cùng nhau và sau đó QA có thể viết các thử nghiệm (ban đầu không thành công) đối với thiết kế và không phải là triển khai thực tế.

Swarming chỉ đề cập đến thực tế là nhiều người làm việc cùng nhau để hoàn thành một nhiệm vụ hoặc câu chuyện. Theo kinh nghiệm của tôi, đây không phải là điều bạn thường làm.

Thông thường, mỗi thành viên trong nhóm của tôi làm việc trên một nhiệm vụ khác nhau và / hoặc câu chuyện khác nhau. Nếu ai đó bị tụt lại phía sau, hoặc nếu muốn hoàn thành sớm một nhiệm vụ hoặc câu chuyện, những người khác sẽ ngừng làm việc khác và "vung" để hoàn thành nhiệm vụ, điều đó có nghĩa là tất cả họ cùng làm một nhiệm vụ hoặc một câu chuyện cho đến khi hoàn thành đã hoàn thành.

Gần đây chúng tôi đã có một số lượng nhỏ các câu chuyện là một công việc khá nhàm chán, không thú vị. Tôi đã cho nhóm một sự khích lệ nhỏ (pizza) và thời hạn (cuối ngày) để hoàn thành công việc, vì vậy họ tràn vào câu chuyện và hạ gục ít nhất vài ngày làm việc trong một buổi chiều. Họ đã hoàn thành công việc và ra khỏi đường sớm, sau đó mỗi thành viên trong nhóm quay lại với bất cứ điều gì họ đang làm. Họ được ăn trưa miễn phí, tôi đã hoàn thành công việc sớm mà có thể kéo dài do bản chất buồn tẻ của nó, và đội đã vượt lên trước cuộc đua nước rút của họ. Thắng thắng thắng.

"Swarming" không gì khác hơn là một thuật ngữ ưa thích cho "hey, hãy để chúng tôi giúp bạn điều đó".

Swarming thực sự là một khái niệm trung tâm cho sự nhanh nhẹn. Nó không phải là một cái gì đó được thực hiện "khi có vấn đề". Swarming, ở dạng đơn giản nhất, có nghĩa là các nhóm làm việc cộng tác trên các vật phẩm (câu chuyện) và hoàn thành chúng. Khái niệm cốt lõi là "bỏ việc bắt đầu và bắt đầu hoàn thiện". Nói cách khác, thay vì mọi nhà phát triển làm việc độc lập với một câu chuyện, nhóm sẽ tập trung vào một tập hợp các câu chuyện / nhiệm vụ hạn chế hơn cùng nhau và hoàn thành từng mục sớm hơn. Hãy nghĩ về nó như sự khác biệt giữa một hệ thống đơn luồng và đa luồng. Nếu Câu chuyện của người dùng có 10 nhiệm vụ phải hoàn thành và mỗi nhiệm vụ là 8 giờ, giả sử rằng không có sự phức tạp nào, một nhà phát triển có thể thực hiện từng nhiệm vụ một cách tuần tự và hoàn thành câu chuyện trong 80 giờ hoặc khoảng hai tuần (trong 10 ngày nước rút 8 giờ mỗi ngày). Điều gì xảy ra nếu hai nhà phát triển phân chia các nhiệm vụ và làm việc cùng một lúc? 80 giờ làm việc tương tự có thể được hoàn thành theo cách này trong một tuần. Thêm một phần ba, và bạn có thể thấy bây giờ nó có thể được thực hiện trong 3 đến 4 ngày.

Swarming có thể được thực hiện theo nhiều cách:

1. Lập trình cặp (hai nhà phát triển ngồi cạnh nhau để làm việc với mã, một là "trình điều khiển" viết mã, hai là người điều hướng, giữ định hướng dài hạn hơn và giúp xem lại mã đồng thời.
   2. Làm việc theo cặp: Một nhà phát triển và người kiểm thử làm việc đồng thời trên cùng một công việc, một mã hóa và thử nghiệm khác, tự động viết, v.v.
   3. Swarming như tôi đã đề cập ở trên, đó là rất phổ biến. Thông thường, các thành viên trong nhóm tràn ngập một Câu chuyện, nhưng mỗi người sở hữu các nhiệm vụ riêng trong phương pháp này.
   4. Lập trình Mob: toàn bộ nhóm tập trung vào một câu chuyện (hoặc thậm chí là nhiệm vụ) tại một thời điểm.

Các nhóm đưa ra một câu chuyện cho mọi nhà phát triển có xu hướng có quá nhiều "công việc đang tiến triển" hoặc WIP, và thường nhiều câu chuyện bắt đầu nhưng không được thực hiện. Đây là một BỆNH NHÂN, và KHÔNG phải là thực hành tốt nhất.

Các nhóm có xu hướng có ít WIP hơn và hoàn thành nhiều câu chuyện hơn - và bằng cách thực hiện, ý tôi là Phát triển, Thử nghiệm, Phê duyệt, sẵn sàng triển khai. Vì vậy, đây là một thực hành là cốt lõi của sự nhanh nhẹn.

Bài viết sau đây về InfoQ mô tả một cách tiếp cận với bầy đàn:

• Nhóm sử dụng lập trình mob cho hầu hết các nhiệm vụ mã hóa của nó
• Một phần của nhóm hoặc các thành viên nhóm riêng lẻ thường chia tách và tham gia nhóm trong khoảng thời gian ngắn
• Mọi người đều làm mọi thứ (không có vai trò)
• Nhóm không sử dụng ước tính, WIP luôn là một, không cần phải đứng lên hoặc các nghi lễ tương tự

Đọc bài viết để được giải thích chi tiết.