Hoàn thiện và đo vận tốc nhóm Agile Scrum của bạn

653

Vận tốc là một phương pháp cực kỳ đơn giản, mạnh mẽ để đo chính xác tốc độ mà tại đó các đội phát triển Scrum luôn phân phối giá trị kinh doanh. Để tính toán vận tốc và cho bạn Agile Scrum tutorial, chỉ cần xác định dựa trên các feature estimation, user stories, requirement hoặc backlog items, những thứ sẽ được dự định bàn giao trong một vòng lặp.

Có một số hướng dẫn đơn giản để ước tính vận tốc ban đầu cho nhóm Scrum của bạn trước khi hoàn thành lần lặp đầu tiên, nhưng sau thời điểm đó, bạn nên sử dụng các biện pháp đã được chứng minh hoặc được rút ra từ kinh nghiệm trong quá khứ để lập kế hoạch cho các Feature mới. Trong một thời gian ngắn, vận tốc thường ổn định và cung cấp một cơ sở to lớn để cải thiện độ chính xác và độ tin cậy của cả kế hoạch ngắn hạn và dài hạn của các dự án Agile của bạn. Agile delivery cycles là rất nhỏ nên vận tốc nhanh chóng xuất hiện và có thể được xác nhận rất sớm trong một dự án và sau đó dựa vào đó để cải thiện khả năng dự đoán của dự án.

Có thể bạn quan tâm: 

  Sơ lược về phương pháp Agile
  Nuxt.js là gì? Một vài lưu ý khi sử dụng Nuxt.js

Vận tốc có thực sự đơn giản?

Đừng cố gắng làm nó phức tạp- nó thực sự là một khái niệm được hiểu đúng nghĩa và rất nhiều giá trị của nó nằm trong sự đơn giản vốn có của nó. Nhiều nhà quản lý và đội dự án mới tiếp cận Agile thường có khuynh hướng phân tích quá mức khái niệm vận tốc và làm phức tạp các vấn đề xung quanh nó. Sau một vài tháng thực hiện, hầu hết mọi người sẽ nhận ra và vứt bỏ những thứ phức tạp mà chú trọng vào sự đơn giản nội tại của nó.

Biểu đồ vận tốc

Cùng với các biểu đồ release và sprint burndown, đo vận tốc của các nhóm Agile đã được chứng minh là cung cấp cái nhìn trực quan về tiến độ và trạng thái của dự án. Biểu đồ tốc độ hiển thị tổng số ước tính của công việc được phân phối trên tất cả các vòng lặp (sprint). Thông thường vận tốc sẽ ổn định trong suốt vòng đời của dự án trừ khi nhóm dự án có sự thay đổi. Như vậy, vận tốc có thể được sử dụng cho các mục đích lập kế hoạch trong tương lai. Biểu đồ vận tốc điển hình cho một nhóm dự án nhanh có thể trông giống như hình ảnh ở đây.

Ban đầu, các nhóm mới phát triển Agile chỉ nên đi sâu và velocity dựa vào hướng dẫn và thông tin có sẵn. Rất nhanh (có thể là ở lần lặp tiếp theo), vận tốc có thể được đo và điều chỉnh. Vận tốc, cùng với các tính năng chi tiết (user stories, backlog, requirements, vv) và estimation (về points, ideal days, or even hours), đơn giản hóa và tăng tốc toàn bộ kế hoạch dự án , ước tính, theo dõi trạng thái và quy trình báo cáo.

Câu hỏi thường gặp của Agile Scrum

Vận tốc của một nhóm Agile được tính như thế nào?

Vận tốc là tổng các ước tính của các tính năng được phân phối (tức là, được chấp nhận) cho mỗi lần lặp lại.

Đơn vị nào được sử dụng để đo vận tốc?

Vận tốc được đo trong cùng đơn vị như là feature estimates, cho dù đây là story points, days, ideal days, hoặc số giờ mà nhóm Scrum thực hiện cho đến khi phân phối – tất cả đều được chấp nhận.

Tốc độ của vòng lặp đầu tiên được ước tính như thế nào?

Đối với lần lặp đầu tiên của nhóm Agile, hướng dẫn chung là lập kế hoạch tính vận tốc ban đầu ở một phần ba thời gian có sẵn. Nếu bạn đang ước tính thời gian lý tưởng thì khoảng thời gian này sẽ dành cho họp, email, thiết kế, tài liệu, làm lại, cộng tác, nghiên cứu, v.v. Ví dụ, 6 developer làm trong sprint 2 tuần –> thời gian tổng cộng 60 ngày (6 developer x10 ngày). Trong tình huống này, một khởi đầu tốt sẽ là lập kế hoạch 20 ngày để thực hiện task và khoảng thời gian sau dành cho cho dự kiến các vấn đề phát sinh hoặc là dự trù cho việc ước tính không chính xác. Ngoài ra, hãy nhớ rằng vận tốc sẽ nhanh chóng xuất hiện trong lần lặp đầu tiên. Nếu đánh giá thấp, vận tốc trong lần lặp đầu tiên sẽ tăng lên khi các tính năng mới được đưa vào; và nếu được đánh giá quá cao, vận tốc sẽ giảm khi các tính năng được loại bỏ. Đối với lần lặp thứ hai, nhóm Scrum nên sử dụng lần lặp đầu tiên làm hướng dẫn.

Cuộc họp, cuộc gọi điện thoại, email có được đưa vào vận tốc không?

Điều này phụ thuộc vào việc các mục này có được ước tính và đưa vào kế hoạch sprint hay không. Chúng thường không được bao gồm – mục tiêu của tínhvận tốc là tính nhất quán tương đối và khả năng dự đoán qua các sprint về khả năng phân phối của nhóm Agile.

Video: Đằng sau kiến trúc và công nghệ của Facebook Search

Vận tốc có nên được tích lũy trên tất cả các nhóm hoặc dự án phát triển nhanh không?

Vận tốc là một biện pháp địa phương hóa rất nhiều. Ngoài các thành viên nhóm khác nhau với các tính cách khác nhau của nhóm, các dự án thường có những đặc điểm độc đáo về kỹ thuật ước tính, quy trình chi tiết, công nghệ, sự tham gia của khách hàng, vv… Kết quả là điều này có thể phân tích trên toàn tổ chức rất không chính xác.

Vận tốc có nên được tích lũy trên tất cả các nhóm hoặc dự án phát triển nhanh không?

Vận tốc là một phương pháp không áp dụng chung cho các cá nhân và các nhóm khác nhau. Các thành viên, nhóm khác nhau với các tính chất khác nhau, các dự án thường có những đặc điểm riêng về kỹ thuật, quy trình, công nghệ, sự tham gia của khách hàng, vv. Kết quả là điều này có thể phân tích trên toàn tổ chức rất không chính xác.

Điều gì xảy ra nếu vận tốc dao động?

Vận tốc thường dao động trong phạm vi hợp lý, điều này hoàn toàn tốt. Nếu vận tốc dao động với biên độ rộng cho nhiều hơn một hoặc hai lần lặp(sprint), nhóm Scrum có thể cần phải ước tính lại và / hoặc thương lượng lại kế hoạch phát hành.

Mất bao lâu để vận tốc ổn định?

Đối với hầu hết các nhóm scrum, vận tốc thông thường sẽ ổn định giữa 3 và 6 sprint.

Làm cách nào để ước tính các lần lặp lại trong tương lai?

Các lần lặp lại trong tương lai sử dụng lịch sử đã được chứng minh của nhóm để xác định nhóm có thể làm được bao nhiêu. Do đó, vận tốc là biện pháp phù hợp để sử dụng cho việc lên kế hoạch cho các lần lặp lại trong tương lai.

Làm cách nào để ước tính vận tốc nếu các nhóm dự án thay đổi kích thước?

Vận tốc dựa trên sự nhất quán của đội để có giá trị nhất. Nếu nhóm scrum của bạn thay đổi, hãy sử dụng ý thức chung trong việc lên kế hoạch cho các lần lặp lại trong tương lai. Nếu 20% nhóm của bạn không có mặt trong một vài sprint tới, thì có thể giảm vận tốc dự kiến xuống 20% hoặc hơn. Nếu điều này bao gồm một vài thành viên chủ chốt, thì có thể giảm ước tính nhiều hơn một chút. Nó sẽ chỉ mất vài sprint tiếp theo để hiểu rõ hơn những gì mà đội của bạn có thể phân phối và do đó vận tốc mới của họ.

Vận tốc tối đa có nghĩa là năng suất tối đa không?

Tuyệt đối không. Trong một nỗ lực để tối đa hóa vận tốc, thực tế team có thể đạt được điều ngược lại. Nếu được yêu cầu tối đa hóa vận tốc, một nhóm có thể giảm unit test, acceptance test, giảm comunicate với khách hàng, bỏ qua fix bug, giảm refactor code, hoặc nhiều lợi ích quan trọng khác của một nhóm thực hành Agile. Trong khi cải thiện ngắn hạn mà có thể để lại tác động tiêu cực lâu dài. Mục tiêu không phải là vận tốc tối đa, mà là vận tốc tối ưu theo thời gian, có tính đến nhiều yếu tố bao gồm chất lượng của sản phẩm cuối cùng.

Làm thế nào để chúng ta đo vận tốc nếu độ dài lặp của chúng ta thay đổi?

Rất khó để đo lường trong trường hợp này. Giá trị của Velocity xuất phát từ sự nhất quán vốn có của nó. Độ dài các vòng lặp (sprint) cố định giúp điều chỉnh nhịp điệu của dự án một cách đáng tin cậy. Không có nhịp điệu này, bạn thường xuyên phải sửa đổi, ước tính lại, và khả năng dự đoán trong tương lai sẽ bị giảm do các kết quả không phù hợp. Mặt khác, nếu hầu như cả team sẽ phải dành một ngày hoặc một tuần cho các ngày lễ hoặc các cuộc họp công ty, thì tất cả các phương thức đo đạt chỉ đơn giản là sử dụng ý thức chung và thích ứng với từng sprint để đánh giá velocity phù hợp.

Người viết: Thanh

TopDev via Viblo