Làm cách nào để quản lý các nhà phát triển Agile làm việc với những người kinh doanh truyền thống (nối tiếp)? [đóng cửa]

Chào buổi trưa,

Môi trường làm việc của tôi có một số vấn đề. Nhóm CNTT của chúng tôi đang cố gắng trở nên nhanh nhẹn hơn, nhưng chúng tôi không thực sự nhận được sự mua lại từ doanh nghiệp. Họ tham dự các đánh giá độc lập và chạy nước rút hàng ngày của chúng tôi, và họ giúp lập kế hoạch chạy nước rút, nhưng sau đó họ quay lại và thực hiện 4 tháng yêu cầu thu thập cho một dự án trước khi chuyển tiếp với phong cách phát triển nối tiếp (chủ yếu). Các mục tiêu chạy nước rút là những thứ như "phát hành XX% gần hơn".

Đối với nhóm CNTT, họ đã biến Sprint thành một cuộc diễu hành tử thần. Chúng tôi kết thúc một Sprint một ngày và bắt đầu một Sprint mới vào ngày hôm sau. Không có sự phản ánh hoặc thay đổi được thực hiện giữa các lần chạy nước rút, chỉ trong thời gian.

Chưa bao giờ thực hiện bất kỳ phương pháp nhanh nào trước đây, tôi chưa có phần giới thiệu rất thú vị về chúng. Vì vậy, câu hỏi của tôi là:

1) Có nên có một khoảng thời gian (có lẽ là một tuần hoặc lâu hơn) giữa các lần chạy nước rút để thực hiện phản xạ / hướng nội / thay đổi / v.v.? Hoặc là chạy nước rút trở lại tiêu chuẩn?

2) Có bất kỳ cơ hội sống sót cho một nhóm nhanh nhẹn không có các bộ phận kinh doanh nhanh nhẹn không? Nếu không, có một số phương pháp chuyển tiếp hoặc thậm chí các mẹo để chuyển doanh nghiệp theo hướng lặp nếu không nhất thiết phải nhanh nhẹn?

3) Toàn bộ đội của bạn có nên chạy nước rút không? Chúng tôi có gần 20 lập trình viên trong một lần chạy nước rút nhưng làm việc trên các dự án hoàn toàn khác nhau (thường là các nhóm 3-5, đôi khi lớn hơn). Có bình thường khi có một lần chạy nước rút hay chúng ta nên cố gắng quản lý nhiều lần chạy nước rút độc lập? Chúng ta có nên cố gắng giữ nhiều lần chạy nước rút trong bước khóa đồng thời hay thời gian biểu của chúng có được phép chồng chéo và linh hoạt không?

Bất kỳ suy nghĩ hoặc lời khuyên được đánh giá cao. Đây là lần đầu tiên tôi đến từ SO cho một câu hỏi, vì vậy vui lòng cho tôi biết nếu có cách nào tốt hơn để diễn đạt các loại câu hỏi này (faq khá hữu ích, nhưng vẫn không chắc chắn tôi đang theo dõi nó hoàn hảo). Cảm ơn!

1) Thông thường bạn chỉ có thể xem lại lần chạy nước rút cuối cùng trong một cuộc họp, lên kế hoạch cho lần tiếp theo và bắt đầu nó. Đặc biệt xem xét cách ước tính nhiệm vụ chính xác và đưa điều này vào ước tính cho lần chạy nước rút tiếp theo. Bạn có thể trì hoãn lần chạy nước rút tiếp theo nếu bạn cần chờ phản hồi của khách hàng từ kết quả của lần trước và bạn nghĩ rằng phản hồi sẽ ảnh hưởng đến các nhiệm vụ cho lần chạy nước rút tiếp theo.

2) Nó sẽ không làm cho nó dễ dàng hơn, nhưng tất nhiên nhóm có thể thành công. Bình luận của bạn

Các mục tiêu chạy nước rút là những thứ như "phát hành XX% gần hơn"

là một chút đáng lo ngại vì lý tưởng bạn muốn bao gồm các tính năng / chức năng có thể chứng minh được như các mục tiêu trong một lần chạy nước rút.

3) Bạn nói có 3-5 dự án hoàn toàn khác nhau. Nếu chúng không liên quan, nghĩa là đối với các sản phẩm khác nhau, không cần phải đồng bộ hóa chúng, nhưng chúng nên được coi là chạy nước rút độc lập. Có vẻ như các đội của bạn cho mỗi lần chạy nước rút có lẽ là một kích thước tốt.

1) Có nên có một khoảng thời gian (có lẽ là một tuần hoặc lâu hơn) giữa các lần chạy nước rút để thực hiện phản xạ / hướng nội / thay đổi / v.v.?

Số một tuần? Bạn chắc hẳn là điên rồi. 2 giờ là giới hạn.

Hoặc là chạy nước rút trở lại tiêu chuẩn?

Chắc chắn rồi. Nếu không, bạn đang quay bánh xe của bạn.

Có bất kỳ cơ hội sống sót cho một đội ngũ nhanh nhẹn không có bộ phận kinh doanh nhanh nhẹn không?

Kinh doanh không bao giờ là "Agile". Agile là một cái gì đó bạn làm. Không phải họ. Thật vậy, không bao giờ họ. Họ chỉ yêu cầu những thứ ngẫu nhiên. Bạn quản lý nó.

Nếu không, có một số phương pháp chuyển tiếp hoặc thậm chí các mẹo để chuyển doanh nghiệp theo hướng lặp nếu không nhất thiết phải nhanh nhẹn?

Không ai. Bạn phân tách các yêu cầu thành nước rút. Đó là kỷ luật của bạn. Không phải của họ.

Toàn bộ đội của bạn có nên chạy nước rút không?

Đúng.

Chúng tôi có gần 20 lập trình viên trong một lần chạy nước rút nhưng làm việc trên các dự án hoàn toàn khác nhau (thường là các nhóm 3-5, đôi khi lớn hơn).

Gì? Đó không phải là một đội. Đó là một nhóm các đội. 4 hoặc có thể 5 đội riêng biệt.

Có bình thường khi có một lần chạy nước rút hay chúng ta nên cố gắng quản lý nhiều lần chạy nước rút độc lập?

Không biết bạn đang nói về cái gì. Nhưng, vì dường như bạn có tất cả 4 hoặc 5 đội cùng nhau, nên rõ ràng là bạn sẽ có sự nhầm lẫn lớn.

Chúng ta có nên cố gắng giữ nhiều lần chạy nước rút trong bước khóa đồng thời hay thời gian biểu của chúng có được phép chồng chéo và linh hoạt không?

Mỗi đội - và chạy nước rút của đội - là vấn đề của đội. Không ai khác.

Một số người cho rằng các dự án lớn như thế này phải là "Scrum of Scrums". Các nhóm đặt mục tiêu của họ, xây dựng những thứ của họ. Đại diện của mỗi đội tập hợp lại theo định kỳ để phối hợp các đội để có được các bản phát hành cùng có lợi.

Tôi xin lỗi vì bạn đang ở trong một tổ chức rối loạn rõ ràng như vậy.

Nếu bạn muốn có bất kỳ khả năng nào để đo lường sự tiến bộ, điều bắt buộc là bạn phải lập kế hoạch theo các mốc hoàn thành 100%. Nếu có bất kỳ chỗ nào cho sự bất đồng trung thực về cột mốc cụ thể là gì, thì xu hướng tự nhiên là người thực hiện công việc sẽ có cách giải thích lạc quan nhất về mức độ họ đã làm và người nghe họ nói gì khi nghe điều đó theo những cách lạc quan nhất có thể. Điều này có nghĩa là tin tức ngày càng tốt hơn khi bạn đi lên chuỗi, dẫn đến sự mất kết nối hoàn toàn giữa thực tế và những gì hàng đầu nghe thấy. http://www.davar.net/HUMOR/JOKES/SHIT.HTM là một sự hài hước, và hoàn toàn thực tế về hiện tượng này.

Làm thế nào xấu là ngắt kết nối này? Xem xét điều này. Trong dự án trung bình, thời gian thực tế để hoàn thành (nếu bạn từng đến đó) trung bình gấp đôi so với ước tính ban đầu. Nhưng cho dù dự án bị trì hoãn bao nhiêu, thông thường, những người ở trên đỉnh không nhận được gợi ý đầu tiên rằng dự án bị chậm lại cho đến khoảng 2 tuần trước ngày đáo hạn, vì đó là điểm mà sự mất kết nối giữa các kỳ vọng và thực tế không còn có thể bị che giấu.

Do đó, mục tiêu gần hơn XX% không phải là yêu cầu thực tế. Theo nghĩa đen, nhóm của bạn nên từ chối chấp nhận những yêu cầu thực tế. Công việc của bạn là giáo dục họ rằng bạn cần những nhiệm vụ cụ thể, có thể hành động và trong kế hoạch, họ sẽ cần được chia thành các nhiệm vụ cụ thể có thể được ước tính là mất nhiều nhất vài giờ.

Thứ hai, như những người khác đã nói, bạn hoàn toàn cần chia nhóm của mình thành các đơn vị nhỏ hơn, có lẽ sẽ cần phải có trong các lịch trình khác nhau. Nghiên cứu chỉ ra rằng một nhóm phần mềm duy nhất gồm 20 người làm việc trên một thứ có thể hoàn thành nhiều như một nhóm 5-8 người. (Tôi đã xem qua sự thật đáng ngạc nhiên này trong Dự toán phần mềm xuất sắc của Steve McConnell .)

Thứ ba, nó là một lá cờ đỏ thực sự lớn mà nó cảm thấy giống như một cuộc diễu hành tử thần. Nếu nó cảm thấy như một cuộc diễu hành tử thần, nó có thể là một cuộc diễu hành tử thần. Các nhà phát triển phần mềm có xu hướng đạt hiệu suất cao nhất khi họ làm việc 35-40 giờ một tuần. (Tôi đã nhận được con số đó từ Phát triển nhanh chóng của Steve McConnell .) Làm việc nhiều giờ hơn có thể tăng hiệu suất tạm thời, với chi phí giảm hiệu suất dài hạn. Một dự án lớn là một cuộc đua marathon, bạn cần phải tăng tốc bản thân.

Thứ tư thực sự cần phải có một nhịp điệu để chạy nước rút. Khi tôi làm việc trong một nhóm làm scrum, chúng tôi thấy rất hữu ích khi chia mỗi lần chạy nước rút thành hai phần mà chúng tôi gọi là "tập trung dài" và "tập trung ngắn". Trong thời gian "tập trung dài", chúng tôi đã bắt đầu phát triển phần mềm về các nhiệm vụ đã được thống nhất cho lần chạy nước rút đó. Trong thời gian "tập trung ngắn", chúng tôi đã làm tất cả những thứ cần thiết mà chúng tôi cần để liên quan đến nhiều gián đoạn và chuyển đổi nhiệm vụ. Vì vậy, đó là khi chúng tôi thực hiện QA, sửa lỗi, các cuộc họp khác nhau, ước tính các nhiệm vụ cho lần chạy nước rút tiếp theo và cuối cùng đã đồng ý về những gì sẽ và sẽ không có trong lần chạy nước rút tiếp theo. Điều này làm việc rất tốt cho chúng tôi vì rất nhiều sự phát triển phần mềm chỉ có thể được thực hiện khi bạn ở trong "khu vực", điều này thường không '

Nếu bạn theo một nhịp điệu như vậy thì bạn sẽ có được một chiến thắng khác khi có lịch trình khác nhau giữa các đội: người QA của bạn luôn có thể làm việc với bất kỳ đội nào hiện đang ở QA, điều này giúp họ duy trì công việc ở mức độ ổn định.

Chúc may mắn, và lưu ý rằng nếu không có sự hỗ trợ từ phía trên, bạn có thể không thể khắc phục các rối loạn chức năng. Nếu đó là trường hợp thì lựa chọn thực tế tốt nhất của bạn có thể là tìm một tổ chức lành mạnh hơn để trở thành một phần thay vì cố gắng biến tổ chức của bạn thành một thứ mà nó sẽ không trở thành.

1. Kinh nghiệm của tôi là chạy nước rút thường quay trở lại với một số mất thời gian để thực hiện hồi cứu, thể hiện chức năng và lập kế hoạch cho lần chạy nước rút tiếp theo. Ví dụ, ngày cuối cùng của một lần chạy nước rút thường sẽ được coi là xóa sổ vì sẽ có 3 cuộc họp kéo dài trong ngày đó, do đó, một lần chạy nước rút 2 tuần bằng 9 ngày làm việc. Việc hồi cứu ở cuối giai đoạn nước rút có thể mang lại những thay đổi sẽ được thử trong lần chạy nước rút tiếp theo bắt đầu gần như ngay lập tức theo một nghĩa nào đó.

2. Cơ hội có nhưng khá nhỏ nếu bạn sử dụng Scrum nên có chủ sở hữu sản phẩm được ban quản lý chấp thuận để ưu tiên trực tiếp mức độ khẩn cấp của một số câu chuyện so với những câu chuyện khác. Phải có một số hiểu biết về trách nhiệm của họ mặc dù một phần khác là "XX% gần hơn để phát hành" là một số liệu khá kém đối với tôi vì điều này có xu hướng không bao gồm các lỗi và các vấn đề khác vào phút cuối gần như không thể đúng ước tính trong kinh nghiệm hạn chế của tôi. Ngoài ra còn có một điều cần nói để hiểu khi thay đổi các ưu tiên có thể được nhóm biết và sử dụng trong việc lập kế hoạch chạy nước rút. Quản lý mua là rất quan trọng vì nếu họ không hiểu những gì bạn đang làm, có thể giống như cố gắng giao hàng trong khi đi bộ trên một máy chạy bộ đứng yên. Trong khi chân bạn đang di chuyển, bạn không

3. Không nhất thiết nhưng đôi khi đó có thể là trường hợp. Điều quan trọng là phải biết mỗi nhà phát triển được phân bổ bao nhiêu cho dự án và giữ sự nhất quán này để khi có vận tốc từ một vài lần chạy nước rút đầu tiên, điều này hữu ích trong việc dự đoán vận tốc trong tương lai thay vì vô dụng như số giờ của con người các dự án bị trả lại quá nhiều để dễ dàng ước tính có bao nhiêu điểm có thể được thực hiện trong một lần chạy nước rút. Mỗi dự án nên có một bộ nước rút riêng nếu dự án đủ lớn để kéo dài trong nhiều tuần làm việc.

Chúc may mắn trong việc giáo dục quản lý về những gì họ phải làm và cách thức hoạt động vì đây có thể là trở ngại lớn của bạn để vượt qua ở đây.

Nếu dự án của bạn đang sử dụng Scrum, thì bạn nên có một Scrummaster có nhiệm vụ là giáo dục tất cả các bên về cách chính xác quy trình được cho là hoạt động. Nếu bạn đang làm Scrum, có vẻ như nhân viên kiểm tra không làm việc của anh ấy / cô ấy, vì không có sự mua lại từ phía doanh nghiệp của dự án là một rào cản HUGE (và không phổ biến).

Nói với mọi người chương trình để vặn nó nếu họ nói hãy đến gần XX% để hoàn thành. NÓI cho bạn, bạn sẽ hoàn thành yêu cầu X, Y và Z trước ngày đó. Nếu họ muốn ký hợp đồng lịch trình, hãy hỏi họ những gì họ muốn loại bỏ, nếu họ chùn bước nói với họ rằng họ sẽ loại bỏ các mảnh hoặc thêm thời gian. Nói rằng làm cho nó được thực hiện nếu không sẽ không làm một chút tốt. Nếu họ đẩy gán mã quản lý dự án của bạn để hoàn thành chạy nước rút đó. Hãy nhớ rằng Agile là một nỗ lực của nhóm. Nếu những người quản lý dự án không làm việc 12 giờ một ngày thì tốt hơn là họ sẽ lấy pizza và soda cho những người đang làm và bất kỳ phần thưởng nào để hoàn thành công việc hoặc trước thời hạn sẽ tốt hơn cho những người đã làm việc đó. Nói với mgmt trên nếu bạn cũng vậy, có lẽ họ là những người đã đẩy Agile vào bạn trong khi không đào tạo người quản lý dự án.

Theo dõi tiến trình của bạn, thực hiện điều chỉnh sau đó chọn các yêu cầu tiếp theo để đáp ứng. Nếu dự án sẽ không được phân phối cho đến khi hoàn thành toàn bộ, đừng lo lắng về mức độ ưu tiên của các tính năng, hãy lo lắng về những tính năng quan trọng đối với bạn mà chúng được thực hiện cho các phần trong tương lai. Bạn phải có quyền sở hữu này. Nó cũng không phải là một cuộc diễu hành cái chết. Các dự án Scrum nên được đo lượng công việc bạn có thể hoàn thành trong thời gian chạy nước rút BÌNH THƯỜNG. Đó là 10 (hoặc 9 như đã lưu ý ở trên) 8 ngày làm việc bình thường.

Một điều tôi đã nghe tại hội nghị Agile vài năm trước là nhóm của bạn giống như một nhà máy và nó có thể sản xuất X số lượng xe (hoặc trong trường hợp tính năng của bạn) mỗi lần chạy nước rút.

Ngoài ra các đội chạy nước rút của bạn nên có 3 đến 5 người chứ không phải 20. Đó có thể là một phần của vấn đề. Mỗi nhóm nên chọn câu chuyện của họ (yêu cầu chi tiết đơn hàng nếu bạn muốn) và làm việc với những câu chuyện đó. Họ nên scrum riêng, nhưng gặp một nhóm lớn trên cơ sở để chia sẻ ý tưởng.

Khi quản lý các loại nhóm này, có thể tốt hơn cho các nhà quản lý để tách riêng để xác định những nhiệm vụ nhóm chéo nào là cần thiết và đặt đúng người liên lạc. Standup 20 người là đơn điệu và nhàm chán cho những người liên quan.