Tôi làm việc tại một công ty đã liên tục cắt giảm quy mô của nhóm phát triển, đến mức các nhóm 10 người trước đây giờ chỉ còn một nhà phát triển cho mỗi sản phẩm (và một vài người thử nghiệm được chia sẻ giữa 5 sản phẩm). Chúng tôi đã từng khá nặng nề, đã bị tách khỏi một công ty lớn hơn và thừa hưởng quá trình thác nước nhiều giai đoạn của nó.

Điều này xuất phát từ nhóm điều hành rằng chúng tôi không phát hành phần mềm đủ nhanh và đây có thể là lỗi của quy trình (có thể là người đóng góp, mặc dù mất 90% nhân lực có thể không giúp ích gì). Đã có một sự thúc đẩy để chúng tôi chuyển sang một quy trình Agile để tránh mất thời gian viết tài liệu thiết kế, v.v.

Tôi đoán tôi chỉ tò mò về việc liệu chuyển sang Agile có giúp được cho các nhóm người độc thân hay không. Theo hiểu biết của tôi, rất nhiều lợi ích đến từ tầm nhìn cao hơn và giao tiếp nhiều hơn giữa các thành viên trong nhóm, nhưng tôi biết những gì tôi đang làm và người quản lý của tôi cũng vậy. Tôi đã làm TDD vì chúng tôi không có ai để kiểm tra sản phẩm.

Phiên bản TL; DR: Tôi đoán những gì tôi thực sự hỏi là, bạn có thể triển khai Agile với các nhóm 'một người' không, và bạn có thấy bất kỳ lợi ích nào từ nó không, hay nó thường là thứ gì đó hiệu quả hơn cho các nhóm lớn hơn?

Hãy xem https://groups.google.com/forum/#!forum/solo-scrum

và /programming/829497/agile-methods-specifically-taylored-to-usiness-solo

Cập nhật:
Liên kết đầu tiên là Nhóm Google Scrum Solo. Lợi ích rõ ràng nhất được nói đến ở đây là sử dụng nước rút hộp thời gian để quản lý phạm vi và xác định vận tốc dự án - cả hai điều rất tốt.

Liên kết thứ hai là một cuộc thảo luận trước đây về Stackoverflow, có thể chỉ ra đây là một câu hỏi trùng lặp, nhưng tôi nghĩ rằng nó sẽ hữu ích hơn khi liên kết với nó. Nó lần lượt liên kết đến http://c2.com/xp/ExtremeProgrammingForOne.html có rất nhiều liên kết và thông tin về việc thực hiện XP solo (lập trình cặp sans).

một

quy mô đội tối thiểu là một

Agile là một tập hợp các nguyên tắc và thực hành, mà bạn chọn để điều chỉnh luồng công việc. Nếu bạn là một người đàn ông, bạn chọn những gì phù hợp với bạn.

XP / TDD hoạt động rất tốt cho các đội một người. Và bạn có thể bỏ qua các thực tiễn có thể gây lãng phí thời gian của các cuộc họp độc lập hàng ngày và lập trình cặp.

Vấn đề chính của bạn không phải là "đi nhanh", mà là tài liệu. Bài viết này về tài liệu Agile / Lean của Scott Ambler có lẽ sẽ là một bài đọc thú vị cho bạn và đồng nghiệp của bạn.

Agile không phải là về tài liệu. Bạn vẫn tài liệu, chỉ là bạn chọn những gì và cách bạn sẽ viết tài liệu để tối đa hóa giá trị trong khi giảm thiểu thời gian dành cho việc tạo ra nó. Bạn vẫn nắm bắt được các yêu cầu, thực hiện thiết kế, ghi lại các quyết định thực hiện của mình và có đầy đủ khả năng truy nguyên trong suốt vòng đời khi cần, nhưng chỉ trong phạm vi mà dự án cần. Không nắm bắt thông tin và quyết định dự án quan trọng là một cách chắc chắn để có một dự án thất bại.

Để có một phần thưởng nhỏ thú vị, đây là cách tôi nhanh nhẹn cho các cá nhân:

Các phương pháp nhanh được thiết kế cho các nhóm. Scrum thường cần khoảng 3-9 nhà phát triển cùng với Chủ sở hữu sản phẩm và Scrum Master (và Chủ sở hữu sản phẩm và Scrum Master không nên là cùng một người). Lập trình cực đoan thường kêu gọi 4-7 người.

Lý do là một số thực tiễn thường được sử dụng trong các phương pháp nhanh chính thống không thu hẹp quy mô cho một nhà phát triển. Một ví dụ điển hình cho điều này là sự nhấn mạnh vào lập trình cặp và đánh giá mã trong XP - bạn thực sự không thể làm điều này với một nhà phát triển solo.

Một nhà phát triển có thể nhanh nhẹn, nhưng nó sẽ phải là một quy trình phù hợp. Hầu hết các phương thức nhanh đều yêu cầu một số kết hợp tích hợp liên tục, thử nghiệm đơn vị, phát triển dựa trên thử nghiệm, tái cấu trúc, các nguyên tắc KISS và YAGNI, v.v. Nhiều trong số này đã trở thành "thực tiễn tốt nhất", thậm chí trên các phương pháp dựa trên kế hoạch nhiều hơn. Không có lý do tại sao một nhà phát triển solo không thể tận dụng một số trong số họ, miễn là họ không can thiệp vào việc sản xuất và phân phối phần mềm.

Nếu bạn muốn giới hạn tài liệu, tôi sẽ tập trung vào đó nếu điều này cản trở bạn. Thông tin chỉ là một phần của sự nhanh nhẹn và có vẻ như không có ai ở công ty của bạn sẽ biết cách thực hiện nó. Điều này có thể trì hoãn việc phát hành mã của bạn trong thời gian ngắn vì đào tạo, mua, điều chỉnh, v.v.

Đến từ một đội một người (mặc dù hy vọng không lâu).

Tôi cố gắng đạt được Agile cho bản thân theo nghĩa là tôi dự định họ sẽ trở thành nhà phát triển hơn là bản thân mình cho các dự án trong tương lai. Tôi viết lên một WBS cấp cao, tôi tạo các câu chuyện của người dùng, các tác vụ theo các câu chuyện của người dùng, các trường hợp thử nghiệm và theo dõi tốt các dự án theo cách mà người quản lý của tôi có thể nhìn và hiểu. Nó có thể hơi cồng kềnh vì tôi "chỉ biết" trong đầu mình đang ở đâu nhưng tôi vẫn dành thời gian để làm điều đó hoàn toàn để siêng năng cho đội tương lai huyền thoại đã được hứa với tôi nhưng chưa xảy ra. Tôi muốn nghĩ rằng tôi đang theo dõi các quy trình tốt cho những người sẽ đến sau tôi.

Tài liệu tôi làm với số lượng nhỏ và đó chủ yếu là sơ đồ dòng chảy và sơ đồ ca sử dụng nhưng nhìn chung không có gì ở mức độ thấp trừ khi có điều gì đó thực sự phức tạp hoặc quan trọng về nó mà tôi không muốn quên. Tôi cũng làm các sơ đồ triển khai vì lợi ích của những người trong tương lai khi họ phải tạo ra một môi trường mới để "đào tạo" hoặc tương tự.

Tôi đang tự dạy TDD một cách chậm chạp nhưng tôi vẫn chưa hoàn thiện nó, thật khó để thực hiện theo nghĩa thuần túy cho các ứng dụng cũ mà không cần cấu trúc lại các chức năng lớn và rủi ro. Chức năng mới phức tạp Tôi vẫn phải vật lộn với nhưng tôi vẫn nhắm đến phạm vi bảo hiểm 100%, đây là trò chơi cuối cùng của TDD. Tôi có thể không đi con đường tốt nhất để đến đó mặc dù.

Nó chắc chắn có thể được thực hiện, nhưng chủ yếu là cần thiết.

Tại sao Agile là một nhóm một người khi bạn có thể tạo thành một nhóm gồm năm nhà phát triển với một sản phẩm tồn đọng duy nhất cho năm sản phẩm của bạn. Hãy thử lặp lại một hoặc hai tuần và tập trung vào một sản phẩm tại một thời điểm và xem năng suất của bạn cải thiện như thế nào với năm kỹ sư làm việc cùng nhau như một nhóm tự tổ chức gắn kết. Tùy thuộc vào tần suất bạn dự định phát hành, bạn có thể cần điều chỉnh độ dài của lần chạy nước rút. Tôi đoán doanh nghiệp có thể không muốn đợi 10 tuần giữa các lần cập nhật cho sản phẩm, trong trường hợp đó, thời gian chạy nước rút 1 tuần có thể hoạt động tốt hơn. Bạn có thể làm việc trên hai sản phẩm trong một lần chạy nước rút nhưng tôi sẽ cố gắng hết sức để tránh điều này để bạn có thể tập trung vào một mục tiêu sản phẩm duy nhất và thực hiện điều đó một cách hiệu quả và chất lượng.

IMO có một người duy nhất dành riêng cho một sản phẩm có thể là một cách tiếp cận không khôn ngoan khi có năm nhà phát triển và tổng cộng năm dự án, bất kể phương pháp bạn đã chọn.

Ví dụ, rất nhiều thực hành nhanh nhẹn trả cho các nhóm> 0. Kiểm soát nguồn và phát triển không ma sát, và như vậy sẽ luôn được đền đáp cho dù nhóm nhỏ như thế nào.

Điều này thực sự phụ thuộc vào việc có mua từ phía doanh nghiệp hay chỉ là một điều mới để ban lãnh đạo đổ lỗi cho sự phát triển (loại âm thanh nào giống như tình huống, dựa trên việc giảm 90% quy mô nhóm). Điều higher visibility and more communication between team membersnày không chỉ có nghĩa giữa các nhà phát triển. Điều quan trọng đối với phía doanh nghiệp là xem thời gian của bạn đi đâu và đặt ra các ưu tiên chính xác.

Chúng tôi đã chứng kiến ​​sự gia tăng lớn về niềm tin giữa các bên kinh doanh và CNTT của công ty chúng tôi, bởi vì mỗi nhóm hiện có Chủ sở hữu sản phẩm tham gia vào các hoạt động độc lập hàng ngày và họ thấy thời gian của chúng tôi đi đâu và họ là những người đưa ra quyết định về những gì chúng ta làm việc tiếp theo. Thay vì các nhà quản lý liên tục bị bắn phá bởi các yêu cầu, và sau đó phát triển bị đổ lỗi khi mọi thứ trôi qua vết nứt hoặc không có đủ thời gian trong ngày để hoàn thành mọi việc, giờ đây, Chủ sở hữu sản phẩm chịu trách nhiệm thiết lập các ưu tiên và thực hiện quyết định về những gì được bao gồm trong một chạy nước rút.

Vì vậy, nếu có cam kết từ Chủ sở hữu sản phẩm sẽ tham gia vào quy trình, thì có, quy trình Agile có thể rất hiệu quả ngay cả đối với một nhóm. Nhưng nếu đây chỉ là một cách khác để biến các nhà phát triển thành vật tế thần, thì Agile sẽ thất bại cho mọi người.