Làm cách nào để quản lý phát triển nhanh khi nhóm không ổn định?

Question

Tôi đã sử dụng các cách tiếp cận nhanh (XP và Scrum) cho các dự án của mình trong nhiều năm với kết quả tuyệt vời. Nhưng trong mọi trường hợp, tất cả các thành viên của nhóm dev đã cam kết 100% cho dự án.

Bây giờ tôi phải đối mặt với việc này khi nhóm không ổn định. Ví dụ, một lần lặp lại có thể có bốn người làm việc, tiếp theo có lẽ chỉ có hai hoặc ba.

Tôi nhận thấy điều này khiến cho việc ước tính sử dụng phương pháp vận tốc bình thường trở nên khó khăn vì nó sẽ biến động nhiều và không ổn định. Điều sau là người ta không thể mong đợi để có thể phát hành vào cuối mỗi lần lặp lại.

Có thể cần có cách tiếp cận khác tại đây. Chỉ cần lấy thứ từ backlog và chỉ muddle thông qua và phát hành bất cứ khi nào nó có thể. Tôi thực sự là không thích điều đó ...

Mọi suy nghĩ?

Answer 1

Từ câu hỏi tôi giả sử bạn có một số nhà phát triển (có thể, 2) 100% cam kết với dự án và một số (2-3 người khác) chỉ tham gia vào một thời điểm.

Một điều bạn có thể làm là đặt quy trình khác nhau cho các nhà phát triển cốt lõi là 100% được cam kết và mọi người khác. Sử dụng quy trình nhanh nhẹn thông thường cho những người cốt lõi và phát hành công việc của họ ở chu kỳ lặp lại bình thường. Đối với những người không phải là người cốt lõi, hãy lập kế hoạch ít và giả định ước tính của họ (và của bạn) sẽ là một thời điểm. Lý tưởng nhất là các thay đổi của chúng nên được phân lập và sáp nhập thành nhánh mã ổn định bởi các thành viên cốt lõi, nhưng không phải mọi kiến ​​trúc và vai trò nhóm của dự án đều cho phép điều này.

Vấn đề là tách biệt và cô lập nguồn gốc của sự hỗn loạn và rời khỏi trái tim của một dự án và nhóm không bị ảnh hưởng.

Answer 2

Cho phép nhà phát triển cá nhân sẽ làm việc dựa trên câu chuyện ước tính nỗ lực cần thiết để hoàn thành câu chuyện. Bạn có thể xem xét các biến thiên lịch sử trong các ước tính của nhà phát triển đó, nhưng ý tưởng là bạn có thể ước tính của họ và tìm ra số lượng câu chuyện bạn có thể hoàn thành trong lần chạy nước rút đó.

Answer 3

Có thể thay vì tiếp cận nhanh, bạn có thể làm chậm mọi thứ xuống với iterative and incremental approaches khác. Thay vì lặp lại được đo trong tuần, có lặp lại dài hơn (có thể đo bằng tháng) sẽ tốt hơn nếu bạn tiếp tục thêm và bỏ mọi người khỏi nhóm.

Điều này không có nghĩa là bạn vẫn không thể sử dụng một số kỹ thuật Agile. Tôi vẫn sẽ duy trì Backlog của bạn và ghi lại các biểu đồ, với việc nhận ra rằng thay vì có một bản phát hành mỗi 2 tuần, bạn sẽ phát hành mỗi 6 tuần (~ 2 tháng). Nếu bạn có nhà phát triển mới tham gia nhiều nhà phát triển có kinh nghiệm hơn, hãy sử dụng lập trình ghép nối, chỉ định nhà phát triển mới sửa lỗi hoặc chỉ định nhà phát triển mới duy trì kiểm tra đơn vị để giúp họ tìm hiểu cơ sở mã.

Answer 4

Vận tốc chỉ là ước tính.

ngây thơ, nếu bạn có một vận tốc cho v với một đội ngũ của 4 nhà phát triển, sau đó sắp xếp lặp của bạn với một vận tốc của (v/4)*number_of_developers

Bạn có thể tin giờ chót giá trị này nếu các thành viên bạn đang mất đi đặc biệt mạnh hơn hoặc yếu hơn Trung bình.

Điều này về cơ bản là những gì PivotalTracker thực hiện với chỉ số sức mạnh nhóm của nó.

Answer 5

Đừng quên rằng vận tốc trung bình chủ yếu được sử dụng để lập kế hoạch phát hành lookahead; đội chịu trách nhiệm chọn trong mỗi lần lặp số lượng các mục tồn đọng để tiếp tục (mặc dù biết vận tốc lịch sử có thể hỗ trợ chúng).

Nếu kích thước nhóm (và do đó vận tốc) dao động từ lần lặp đến lần lặp, bạn vẫn có thể lập kế hoạch phát hành hữu ích bằng cách sử dụng vận tốc trung bình trong các lần chạy nước rút trước đây. vận tốc sẽ thực sự ổn định.

Answer 6

Vấn đề chính của bạn ở đây là nhóm sẽ gặp khó khăn trong việc đưa ra các ước tính và phân phối có thể dự đoán được vì nhóm đang thay đổi từ chạy nước rút sang chạy nước rút. Điều này cũng có thể làm tổn thương cam kết của nhóm và cải tiến liên tục.

Trường hợp này thực sự có thể phù hợp với phương pháp Kanban. Hãy xem phần giới thiệu của Henrik Knibergs về Kanban để biết tổng quan nhanh.

Chúc may mắn!

Answer 7

Vì vậy, bạn có một dự án với quy mô nhóm liên tục thay đổi và sếp của bạn muốn bạn cho anh ta ước tính chính xác thời gian cần thiết? Bạn có thể làm điều này, miễn là bạn ghi nhớ sự khác biệt giữa chính xác và chính xác. Độ chính xác của bạn sẽ phụ thuộc phần lớn vào số lượng mục và mức độ chi tiết của từng mục; càng có nhiều mục bạn càng có nhiều Luật về số lượng lớn hoạt động cho bạn, tính trung bình và đánh giá thấp.

Độ chính xác của bạn là chức năng của sự tự tin. Lưu ý rằng các ước tính không phải là các giá trị một điểm, chúng là một phạm vi với các con số có phần trăm tin cậy. Ví dụ, một ước tính thích hợp sẽ không phải là "2 tuần" nó sẽ là "50% sự tự tin của 2 tuần, 80% sự tự tin của 4 tuần."

Nếu tôi là người được giao nhiệm vụ không thể hoàn thành cho dự án được quản lý tùy ý trong bài đăng gốc, tôi sẽ cố gắng tìm ra một phạm vi dựa trên số lượng người được chỉ định tối thiểu (ví dụ, "48 đến 66 tuần cho 2 nhà phát triển [50% đến 80% tự tin]") và phạm vi kết hợp với số lượng trung bình của những người được chỉ định (ví dụ: "25 đến 45 tuần với 5 nhà phát triển [50% đến 80% tự tin] ") và sử dụng con số thấp từ con số trung bình cùng với con số cao từ số lượng tối thiểu (ví dụ:" 25 đến 66 tuần cho từ 2 đến 5 nhà phát triển [50% đến 80% tự tin] ") và thậm chí sau đó tôi sẽ đặt một tuyên bố từ chối trách nhiệm về nó ("cộng thêm 10% cho thời gian bị mất do chuyển ngữ cảnh").

Tốt hơn, tôi giải thích chính xác lý do tại sao sự sắp xếp này là lịch sự, tối ưu và lý do đa nhiệm là một biển hiệu chính trên đường đến dự án Địa ngục.

Như một người khác đã đề xuất, việc thay đổi quy trình làm việc từ dựa trên lặp thành dựa trên luồng (Kanban) cũng có thể là một chiến lược tốt. Với Kanban bạn xử lý các thay đổi ưu tiên của dự án bằng cách thay đổi mức độ ưu tiên của các mục trong phần tồn đọng; một khi một mục đã được nhóm nắm lấy, nó thường được hoàn thành (lưu thông tất cả các cách thông qua quy trình làm việc, các bên liên quan không được phép phá vỡ nhóm bằng cách vặn vẹo xung quanh với công việc đang tiến hành). Tôi đã sử dụng Kanban cho các dự án kỹ thuật bền vững và nó hoạt động rất tốt. Làm thế nào nó sẽ giúp với ước tính, chìa khóa để dòng chảy liên tục là cố gắng để có mỗi mục công việc có kích thước gần như giống nhau (1x, 2x, 3x, không 10x, 20x, 100x). Bạn nên theo dõi chuyển động của các mục thông qua quy trình làm việc bằng cách theo dõi ngày thay đổi trạng thái quy trình, ví dụ: Hàng đợi 1/15, Thiết kế 1/22, Dev 1/24, Kiểm tra 2/4, Tích hợp 2/7, v.v ... và sau đó tạo một biểu đồ dòng tích lũy thường xuyên để đánh giá thời gian theo trạng thái theo thời gian. Làm việc ra bao lâu dự án nên đưa ra rằng bạn biết kích thước của mỗi mục và thời gian thông qua các công việc cho các hạng mục là một bài tập tính toán tầm thường để lại cho người đọc.(Câu hỏi thú vị hơn là làm thế nào để phát hiện ràng buộc ... và sau đó làm thế nào để loại bỏ chúng. Gợi ý: hãy tìm thời gian dài ở các tiểu bang, bởi vì công việc chồng chất lên trước các ràng buộc.)