Là sự gia tăng lớn về vận tốc trong thực tế trong môi trường Scrum?

Người quản lý của tôi gần đây đã thực sự thúc đẩy sử dụng vận tốc như một mục tiêu và thước đo năng suất. Chúng tôi hiện đang làm việc với vận tốc trung bình là 50 điểm. Người quản lý của tôi muốn chúng tôi tăng 40% lên 70 điểm câu chuyện (không tăng thành viên trong nhóm). Nếu chúng tôi không đạt được mức tăng này, anh ấy muốn chúng tôi giải thích đầy đủ lý do tại sao.

Toàn bộ ý tưởng đo hiệu suất của đội bằng vận tốc và sử dụng nó làm mục tiêu có vẻ sai đối với tôi, nhưng tôi cảm thấy khó giải thích tại sao. Có ai giúp đỡ không? Tại sao đây không phải là cách đúng đắn để đo lường và khuyến khích năng suất?

Chà, thật đơn giản để tăng vận tốc lên 40% - chỉ cần thêm 40% điểm nữa cho tất cả các ước tính của bạn và thực hiện cùng một lượng công việc.

Cho rằng điều này là như vậy, rõ ràng tại sao sử dụng vận tốc làm mục tiêu là sai, nó chỉ khuyến khích các ước tính tăng cao.

Một câu trả lời ít ỏi hơn là ước tính của bạn đã cho rằng bạn sẽ đi nhanh nhất có thể trong khi làm mọi thứ chính xác. Cách duy nhất để thực sự tăng năng suất lên 40% là làm việc ngoài giờ hoặc không làm mọi thứ chính xác. Cả hai điều này đều tăng tốc trong thời gian ngắn, nhưng chậm lại trong thời gian dài. Và dài hạn trong trường hợp này không dài lắm, một tháng ở bên ngoài. Chiến lược dài hạn tối ưu là không bao giờ đi nhanh hơn tốc độ bền vững của bạn.

Peopleware nói hùng hồn về các vấn đề cố gắng buộc các lập trình viên đạt năng suất cao hơn, và là một tác phẩm kinh điển thường được trích dẫn. Nhưng nói chung, sẽ không dễ để thay đổi suy nghĩ của một người quản lý đang đi theo con đường của bạn. Dự án của bạn có thể gặp rắc rối - đây chắc chắn là một lá cờ đỏ.

Như các ý kiến ​​đã chỉ ra, yêu cầu rõ ràng là sai theo cách nó đã được đặt. Nhưng anh ấy không thực sự sai khi muốn liên tục cải thiện năng suất. Theo quy định, đó là những gì các nhà quản lý phấn đấu (và được đánh giá) cho.

Điều đó nói rằng, các nhà quản lý luôn tìm cách cải thiện hiệu suất và Scrum và Agile hoàn toàn có thể thích nghi được. Mặc dù vận tốc là thước đo tốc độ bền vững hiện tại của bạn, bạn không nên ngồi lại trên vòng nguyệt quế của mình. Scrum có một nơi để đánh giá và thay đổi những gì hoạt động và không có trong quy trình của bạn: quá trình hồi cứu. Nếu bạn tận dụng điều đó và điều chỉnh quy trình của mình, năng suất (và có thể là vận tốc) sẽ tăng lên.

Vì vậy, bạn đang tìm kiếm (trong quá trình hồi tưởng của bạn) để tìm cách trở nên hiệu quả hơn khi làm việc theo nhóm? Có bất cứ điều gì trong nước rút của bạn thường xuyên tiêu thụ một lượng nỗ lực không tương xứng? Nó có thể được giải quyết? Nó có thể sẽ không giúp bạn tăng 40%, nhưng 5-10% là một sự khởi đầu, phải không? Mỗi lần chạy nước rút bạn nên tìm kiếm các nút cổ chai và giải quyết chúng. Cuối cùng, bạn có thể tiến gần đến mục tiêu anh ấy đặt ra cho bạn.

TL; DR

Vận tốc rất hữu ích để ước tính lịch trình hoặc tạo giá trị lập kế hoạch và cũng có thể là một điều khiển thám tử có ý nghĩa để đánh giá các tắc nghẽn trong quá trình hoặc thay đổi năng lực của nhóm. Tuy nhiên, đây không phải là thước đo hợp lệ của năng suất.

Khi Vận tốc bị nhầm lẫn với các mục tiêu quản lý

"Vận tốc" là một phạm vi thể hiện năng lực trung bình của một đội trong một số giai đoạn lịch sử. Đây là một phân tích thống kê về hiệu suất trong quá khứ, sau đó có thể được sử dụng để dự đoán các ước tính xác suất của khả năng khối lượng công việc trong tương lai hoặc thời gian chu kỳ. Điều này trái ngược hoàn toàn với "mục tiêu lập lịch", là mục tiêu quản lý đặt ra mốc thời gian hoặc mục tiêu cho các mục đích lập kế hoạch.

Các nhà quản lý dự án nhanh nhẹn có kinh nghiệm biết rằng việc sử dụng vận tốc hợp lý là để xác định xem một nhóm có khả năng bền vững để đáp ứng các mục tiêu lập lịch do quản lý xác định hay không. Đôi khi câu trả lời là có, và mọi người đều hạnh phúc. Đôi khi câu trả lời là không, tại thời điểm đó, tam giác sắt buộc các quyết định kinh doanh về phạm vi, chi phí, thời gian và chất lượng.

Đánh giá các lựa chọn chính trị của bạn

Chúng tôi có vận tốc trung bình là 50 điểm câu chuyện ... Tôi đã được yêu cầu tăng 40% lên 70 điểm câu chuyện (không tăng thành viên trong nhóm).

Giả sử rằng các thực tiễn ước tính của bạn là hợp lý và vận tốc của bạn ổn định một cách hợp lý, người quản lý của bạn sẽ không có niềm vui từ việc điều chỉnh thang đo ước tính hoặc đặt các mục tiêu quản lý không dựa trên hiệu suất lịch sử. Như bạn chỉ ra một cách chính xác, về cơ bản đây là một vấn đề năng lực .

Giới hạn năng lực có thể liên quan đến số lượng người trong nhóm của bạn hoặc có thể là giới hạn của quy trình tổ chức của bạn. Tất nhiên, việc thêm nhiều người không phải lúc nào cũng thêm năng lực dự án thực tế; xem Luật Brooks để biết thêm về quan niệm sai lầm phổ biến này.

Vấn đề bạn gặp phải là chính trị. Từ giai điệu của bài đăng của bạn, có vẻ như người quản lý của bạn muốn thấy sự tăng năng suất mà không thực hiện bất kỳ thay đổi thực tế nào đối với năng lực cơ bản của nhóm. Các giải pháp do đó cũng mang tính chính trị, và phần lớn mang tính giáo dục.

Nếu bạn là cửa hàng Scrum, hãy yêu cầu Scrum Master giải quyết vấn đề này thông qua các kênh khung phù hợp. Backlog Chải chuốt và Sprint Retrospectives thường là cơ hội kiểm tra và thích nghi lý tưởng cho vấn đề đặc biệt này.

Nếu bạn không phải là cửa hàng Scrum, bạn phải quyết định cách thức phù hợp để giải quyết mối quan tâm của bạn trong tổ chức của bạn. Nếu bạn có quan hệ tốt với người quản lý của mình, bạn thậm chí có thể cho anh ấy mượn một bản Dự toán và Lập kế hoạch Agile để hai bạn thảo luận trong bữa trưa.

Nếu vẫn thất bại, hãy chuẩn bị cho một cuộc diễu hành tử thần bằng cách xem sơ yếu lý lịch của bạn, và làm hết sức chuyên nghiệp cho đến khi dự án nổ ra. 68% dự án CNTT thất bại ; trừ khi các mục tiêu quản lý được củng cố vững chắc trong năng lực tổ chức, bạn có thể sẽ là một trong số họ.

Tôi không hiểu người quản lý của bạn có vai trò gì trong nhóm Scrum? Anh ấy có phải là huấn luyện viên không? Có phải anh ấy là chủ sở hữu sản phẩm?

Nếu anh ấy ở trong đội như một huấn luyện viên hoặc như vậy (anh ấy làm việc trong một nhiệm vụ phát triển), bạn có thể hỏi anh ấy tại sao anh ấy đánh giá thấp năng suất của chính mình, bởi vì dường như đó không phải là trường hợp của các thành viên khác trong nhóm. Nếu anh ta tin rằng cá nhân anh ta có thể giả định 30 điểm câu chuyện nhiều hơn mỗi lần lặp, hãy để anh ta thể hiện điều đó.

Nhiều khả năng hơn: anh ta ở ngoài đội, có thể là chủ sở hữu sản phẩm? Nếu vậy anh nên hiểu thực hiện một yêu cầu ngu ngốc như vậy, anh chỉ dừng lại nhanh nhẹn.

Một quy tắc cơ bản là chủ sở hữu sản phẩm đặt mục tiêu trong khi nhóm đặt những gì có thể được thực hiện trong một lần lặp. Không làm như vậy dẫn đến vòng tròn sắt cổ điển và nổi tiếng: tài nguyên, vận tốc, tính năng. Chọn hai! Bạn không thể chọn ba trong số chúng cùng một lúc (và hãy nhớ: chất lượng không phải là biến điều chỉnh, cố gắng cắt các góc thông qua chất lượng thấp sẽ khiến mọi thứ trở nên tồi tệ hơn).

Nếu anh ta không muốn thay đổi mục tiêu hiện tại, có thể đạt được mức tăng năng suất 40% bằng cách tuyển thêm người cho đội? Có thể đầu tư vào một số đào tạo trước cho một số thành viên trong nhóm? Các đội cũng có thể đạt được vận tốc theo thời gian thông qua cải tiến liên tục, nhưng chắc chắn không phải do quyết định tùy ý.

Cố gắng thay đổi vận tốc của một đội cũng giống như cố gắng thay đổi kích thước của một căn phòng. Nó có thể được thực hiện, nhưng về cơ bản bạn cần phải thay đổi phòng.

Bạn không có Scrum Master hay một số người khác có hiểu biết cơ bản về Scrum, người có thể giải thích điều đó cho anh ta?

Trong trường hợp này, người quản lý đã rẽ sai hướng sau khi có được ước tính trung thực và trung thực từ nhóm. Người quản lý có nghĩa vụ phải chuyển sang các bên liên quan và cho họ biết rằng các yêu cầu của họ không thể được hoàn thành trong thời gian yêu cầu. Sau đó, người quản lý / nhà phân tích nên ưu tiên những tính năng nào PHẢI được đưa vào và những tính năng khác có thể chờ đợi (thậm chí chỉ một vài tuần). Nếu các bên liên quan là không hợp lý, thì nó có thể yêu cầu các nhà quản lý cao hơn tham gia, điều này thường có thể là thách thức và đòi hỏi một loạt các cuộc thảo luận khác.

Nếu tôi ở trong đôi giày của bạn, tôi sẽ đưa ra một trường hợp chi tiết về lý do tại sao dự án IS sẽ mất chừng nào được ước tính. Cũng cố gắng để xác định các mặt hàng trở lại thấp. Tìm các mục không thêm nhiều giá trị và đòi hỏi các nỗ lực lập trình đáng kể và tạo trường hợp để loại bỏ các mục khỏi chạy nước rút. Ngoài ra, hãy đưa ra một phương pháp lặp mang lại "X" vào ngày "Y" và đảm bảo rằng nó khả thi, sau đó đưa ra một bước lặp tiếp theo sẽ mang lại cho họ các mục còn lại.

Về cơ bản, ai đó cần nói với các bên liên quan những gì họ có thể mong đợi nhận được trước hạn chót và nó bao gồm phần lớn các yêu cầu của họ. và bằng cách phát hành sau họ sẽ có các mục còn lại. Nếu khách hàng không hợp lý thì cần phải tham gia quản lý cấp trên, người quản lý có thể thực hiện điều này.

Tuy nhiên, nếu khách hàng đã hết lời hứa và không ai lên tiếng cho đến bây giờ thì đó sẽ là một trận chiến khó khăn. Đây không phải là một tình huống hiếm gặp.

Có vẻ như bạn phải đối mặt với hai vấn đề.

Phần về đo vận tốc làm phiền bạn có lẽ là phép đo là chi phí . Những gì bạn thực sự muốn cải thiện là giá trị . Thật không may, đo lường giá trị của phần mềm nổi tiếng là khó khăn và chủ quan. Tuy nhiên, ngay cả một số liệu không hoàn hảo và chủ quan có thể hữu ích. Có thể vấn đề thực sự không phải là nhóm của bạn cần viết thêm mã, mà là những câu chuyện cần có giá trị hơn.

Vấn đề khác là dựa trên tài khoản của bạn, người quản lý của bạn dự kiến ​​tăng 40% năng suất. Nó không được nêu trong câu hỏi của bạn bối cảnh của yêu cầu này. Nó có thể là một người tốt bụng nếu mong muốn mong muốn cho nhóm của bạn để cải thiện. Hoặc nó có thể là một dấu hiệu không tinh tế đến mức người quản lý của bạn tin rằng nhóm của bạn đang hoạt động kém.

chỉnh sửa: Dựa trên nhận xét của bạn, tình hình có vẻ tồi tệ. Có vẻ như công ty của bạn đang đặt nền tảng để sa thải bạn và nhóm của bạn (có thể cả người quản lý của bạn nữa). Tôi đề nghị bạn nên tìm một công việc khác.

Sa thải anh ta. Đó là để nói, đi qua đầu của anh ấy và giải thích rằng anh ấy đã mất tất cả niềm tin của đội ngũ của mình, và giải thích anh ấy không có giá trị với doanh nghiệp. Giải thích rằng các nhà quản lý có mức độ bất tài này dễ thay thế hơn nhiều so với nhóm dưới đây.

Không có lý do chính đáng để đưa ra một người quản lý như vậy, nhưng điều đó không tự động có nghĩa là các nhà phát triển nên từ chức. Không nhất thiết phải có điều gì đó sai với doanh nghiệp, chỉ với một cá nhân này. Khắc phục sự cố đó.

Và để tránh sự che giấu từ quản lý cấp trên, hãy nói rõ rằng đây không phải là một sai lầm có thể tha thứ. Nó báo hiệu rằng người quản lý có trách nhiệm không có hiểu biết về đội ngũ mà anh ta đang quản lý. Điều đó không cho vay để sửa chữa, cũng không cần phải có trong thị trường lao động hiện tại. Các nhà quản lý thường có thể thay thế giống như các huấn luyện viên thể thao. Chủ sở hữu không đội lửa.

Bây giờ, điều này có thể trông giống như một chiến lược có thể gây phản tác dụng. Nhưng hãy xem xét: nếu quản lý cấp trên với người quản lý của bạn bất kể, bạn đã ở trong tình trạng thua lỗ. Vì vậy, nếu bạn chỉ xem xét các tình huống mà bạn chưa ở vị trí thua cuộc đó, kết quả có thể sẽ tích cực hơn nhiều. Rủi ro thực sự là quản lý cấp trên chỉ sa thải cả nhóm, bao gồm cả người quản lý. Chỉ có bạn có thể ước tính rủi ro đó. Rõ ràng đầu ra của bạn là muốn, nếu không họ sẽ không yêu cầu nhiều hơn, nhưng với giá nào?

Kinh nghiệm của tôi là rất khó để tăng vận tốc thực tế của một đội, do cả nhóm, miền vấn đề hoặc ngăn xếp công nghệ không thay đổi.

Nơi tôi đã có thể đạt được mức tăng, đó là vấn đề:

• làm sạch nợ kỹ thuật; đảm bảo rằng mọi thứ đang chạy đúng phiên bản (không nhất thiết phải là mới nhất!), rằng mã được cung cấp đầy đủ và không có sự dư thừa trong hệ thống (mã trùng lặp, mã không sử dụng, v.v.)

• cải thiện thực hành; ghép nối khi có thể (vâng, tôi đã thấy tăng vận tốc), dành thời gian để tái cấu trúc mạnh mẽ (ditto!), và tàn nhẫn về phạm vi và trọng tâm

• tìm kiếm và / hoặc mua các công cụ tốt nhất cho công việc (ví dụ ReSharper cho .NET có giá trị bằng vàng, Airbrake và Splunk để phát triển Ruby, v.v.)

Tôi đồng ý với những người khác ở đây nói rằng người quản lý của bạn yêu cầu tăng vận tốc tùy ý là một lá cờ đỏ. Tôi sẽ tìm kiếm một công việc khác là một ưu tiên cao.

Người quản lý của bạn đang yêu cầu (hoặc nói) nhóm của bạn làm thêm giờ. Mặc dù loại bỏ các nút thắt cổ chai và đạt được hiệu quả có thể cải thiện phần nào vận tốc của bạn, cách duy nhất để có được sự gia tăng đó (40%) là làm việc nhiều giờ hơn, vì bạn cần phải nhồi nhét nhiều đơn vị công việc hơn trong khoảng thời gian đó.

Hãy lấy một kịch bản.

Trong một khoảng thời gian hai tuần, hãy nói 10 ngày. Utopia sẽ là 8 giờ một ngày, với một điểm câu chuyện được trừu tượng hóa thành một ngày làm việc. Vì vậy, từ đầu, vận tốc của bạn sẽ là 8. Nhưng, mọi người có thể nhận được 6 giờ tốt mỗi ngày với email, các cuộc họp, giờ nghỉ trong phòng tắm, v.v. Vì vậy, đường cơ sở của bạn là 6. Giả sử bạn muốn mọi người làm việc ngoài giờ, bây giờ là 10 giờ một ngày. Vì vậy, đó sẽ là 10 điểm vận tốc cho mỗi nhà phát triển.

Vận tốc của bạn sẽ luôn dao động, có thể là thấp vì bạn đã phải đối phó với rất nhiều lỗi trong quá trình lặp lại đó, có thể yêu cầu bị thiếu, có thể ai đó bị bệnh trong vài ngày. Có thể đó là cao vì công việc được đánh giá quá cao hoặc nhóm của bạn làm thêm giờ.

Nhưng nếu bạn ở mức 50 ổn định, thực sự để đến 70 sẽ cần thêm giờ.

Vấn đề với vận tốc là nó là một biến phụ thuộc, là đầu ra đo lường của quá trình phát triển của bạn. Yêu cầu tăng vận tốc 40% giống như cố gắng đi làm sớm hơn bằng cách hét vào những chiếc xe để đi nhanh hơn. Vận tốc tăng bằng cách nạp thêm nhiên liệu và không khí vào động cơ hoặc nhận xe nhanh hơn, cộng với việc tìm tuyến đường có ít lưu lượng.

Làm việc nhiều giờ hơn sẽ không tăng vận tốc nếu bạn đo lường chính xác, nói theo điểm tính năng trên mỗi giờ của nhà phát triển. Nó chỉ hoạt động nếu bạn đo điểm mỗi ngày và sau đó xác định lại "ngày" là gì trong phép đo giữa. Điều này chỉ cung cấp ảo ảnh về tốc độ.

Việc tăng vận tốc đòi hỏi phải cải thiện các biến độc lập trong quá trình dev; máy tính và trình biên dịch nhanh hơn, hệ thống xây dựng hiệu quả hơn, quy trình thiết kế tốt hơn, nhà phát triển có khả năng hơn, không gian làm việc tốt hơn, động lực siêu lừa đảo. Một cải tiến 40% sẽ đòi hỏi những thay đổi rất đáng kể.

Hỏi xem người quản lý của bạn có cân nhắc việc đặt nhóm của bạn trong các văn phòng kín xung quanh một phòng làm việc chung, mua phần cứng dành cho nhà phát triển hoàn toàn mới hay thuê một vài nhà phát triển thực sự cao cấp để cố vấn cho nhóm nếu điều đó giúp anh ta đạt 40%. Nếu không có tài nguyên có sẵn để cải thiện các yếu tố đầu vào cho quy trình phát triển của bạn, thì có khá nhiều quy tắc dành cho sự quan tâm chân thành trong việc cải thiện. Điều này khiến kỹ thuật đảo ngược của bạn quản lý để tìm ra điều gì thực sự thúc đẩy anh ta, đó sẽ là chủ đề của toàn bộ chủ đề.

Chà, tôi hơi ngạc nhiên khi các câu trả lời khác thực hiện nghiêm túc yêu cầu của sếp. Một số người đòi hỏi tăng 40% năng suất không biết điều đầu tiên về phát triển phần mềm.

Tôi vẫn thích đọc Phil Factor về chủ đề này:

Có hai con đường cơ bản để quản lý CNTT. Bạn có thể học giao dịch của mình thông qua máu, mồ hôi và nước mắt và dần dần tiến lên, dựa trên uy tín bạn có được từ bí quyết kỹ thuật khó kiếm được và các dự án thành công. Ngoài ra, bạn có thể tặng một bộ đồ sắc sảo và cà vạt, học cách chơi lô tô và nói chuyện suôn sẻ theo cách của bạn lên hàng đầu.

Cả hai tuyến dường như hiệu quả như nhau. Đối phó với giống chó sau này chắc chắn có thể gây ra một số khoảnh khắc mất tinh thần và hoài nghi về sự tuyệt vọng, thậm chí là một số điều được ghi lại trong những câu chuyện này.

Tuy nhiên, thật dễ dàng để trở nên buồn bã và chán nản khi một người gặp phải sự bất tài về kỹ thuật ở các vị trí quyền lực, và làm cho tất cả các nhà quản lý có cùng một bàn chải. Phil khuyên chống lại nó. Hầu hết các nhà quản lý làm việc chăm chỉ và đóng góp tốt cho công ty, và thậm chí các nhà quản lý kém có thể được đào tạo theo tiêu chuẩn bắt buộc, nếu bạn chỉ cần làm theo một vài hướng dẫn đơn giản. Đó là một phần trách nhiệm trong nhóm của bạn để giúp người quản lý của bạn hoạt động theo cách có lợi cho tất cả.

Cuối cùng, nếu bạn không thể đào tạo họ, khuyến khích họ hoặc tránh họ, có lẽ bạn có thể học cách yêu họ chỉ vì những đóng góp ngoài ý muốn của họ cho bộ phim hài phong phú tại nơi làm việc.

Lời khuyên không nên trở nên "buồn và chán nản" là điều tốt nhất bạn có thể nhận được. Đừng đấu tranh với một ông chủ bất tài về mặt kỹ thuật trong các vấn đề kỹ thuật. Anh ta sẽ chỉ coi đó là một cuộc tấn công cá nhân.

Người quản lý của bạn đã hiểu nhầm việc sử dụng vận tốc. Nó không phải là một số liệu và nó không phải là một mục tiêu. Mục đích của nó là hiệu chuẩn khối lượng công việc của nhóm trên mỗi lần chạy nước rút.
Nếu bạn nghĩ về nó, vận tốc của bạn nổi lên từ một dự đoán tốt nhất, điều mà bạn cảm thấy hài lòng sau mỗi lần chạy nước rút. Thông thường khi thời gian tiến triển, nó sẽ trở nên ổn định. Nhưng điều đó không thay đổi thực tế rằng đó là sản phẩm phụ của những gì nhóm của bạn thực sự đang làm: tạo ra giá trị cho khách hàng của bạn.

Lý do tại sao nó sai khi sử dụng nó làm mục tiêu và / hoặc số liệu là bởi vì điều đó sẽ làm cho nó trở thành một số liệu phù phiếm. Nó sẽ có vẻ tốt trên giấy, nhưng nó hoàn toàn không có gì để phản ánh thời tiết hay không sản phẩm của bạn đáp ứng đầy đủ nhu cầu của khách hàng. Và đó là điều quan trọng nhất (tôi hy vọng).

Về kinh nghiệm của tôi và đi thẳng vào vấn đề.

Đầu tiên, bạn có thể làm tăng dự toán nhưng điều đó không có nghĩa là bạn đang làm nhiều hơn.

Thứ hai (tiền đề: không thổi phồng, chỉ tập trung vào vận tốc đội),

Cố gắng tìm các kỹ năng trong nhóm của bạn. Họ đang làm việc trên những gì họ tốt nhất? Bạn có cần một kiến ​​trúc sư hệ thống để đưa ra các quyết định khó khăn liên quan đến việc xây dựng ứng dụng và những thứ phức tạp không? Làm thế nào nhóm đang dành những nỗ lực của họ? Họ đang dành thời gian nghiên cứu các giải pháp cho các vấn đề của họ, tái cấu trúc, đưa ra quyết định kinh doanh hay gì?

Họ có thoải mái, tập trung và ước tính? Điều gì tiếp theo cho họ?

Đây không phải là "tôi bị đẩy vào giới hạn" ... nó giống như một câu hỏi cho toàn đội "Chúng ta có đang ở giới hạn không?" và "Làm thế nào chúng ta có thể đẩy các giới hạn?" ...

Tôi có các nhóm hiệu suất cao hàng đầu (cho lần đầu tiên xây dựng và / hoặc di chuyển) ... động lực của nhóm là chìa khóa thành công ... và lập kế hoạch làm thế nào cơ sở của ứng dụng sẽ là điều cần thiết. Đôi khi, tôi hoặc một đồng đội có được vai trò của Kiến trúc sư hệ thống và quyết định cách thức và "nơi" nên đi.

Đôi khi tôi thấy rằng các đồng đội của mình đang mất hiệu quả, tôi cố gắng phá vỡ và mời họ ra ngoài để uống bia, hoặc thứ gì đó họ thích. Điều này giải quyết mọi xung đột và vào ngày hôm sau họ lại tập trung.

BÁN ...

Nếu giải thích lý do bạn không thể tăng vận tốc là khó, hãy sử dụng ROI.

Scrum tập trung vào những gì quan trọng nhất cho khách hàng. Về mặt lý thuyết các nhiệm vụ có lợi nhất.

Nếu vấn đề của bạn liên quan đến việc bán nỗ lực phát triển, bạn nghĩ bán ROI của nỗ lực phát triển là gì thay vì trực tiếp chuyển đổi điểm câu chuyện thành "giá". Nếu bạn có thể chứng minh rằng nhóm của bạn làm việc với ROI cao, ai sẽ hỏi bạn? Ngoài ra, mọi đội đều có giới hạn của mình nếu đội đã tìm thấy "kích cỡ confort" của mình, hãy thử tăng từng tháng một chút, nếu họ không thể hoàn thành tất cả các nhiệm vụ thì đây có thể là giới hạn.

Hiển thị lịch sử của các nhiệm vụ, doanh thu lợi nhuận (nếu có), điểm câu chuyện bạn đã sử dụng và cho thấy NĂNG SUẤT LÀ ĐỘI NHÓM là một phép tính được xác định bởi nhóm để đánh giá mức độ phức tạp và có lẽ là thời gian để có được thứ gì đó làm xong