Velocity trong Agile là gì ?
Như đã được học trong nhà trường, để đo tốc độ của 1 chiếc xe, ta dùng velocity (vận tốc). Tuy nhiên hãy tưởng tượng bạn lái xe và đồng hồ đo tốc độ bị hỏng. Bạn lái xe trong 2 giờ, bạn đi được 160 km, vậy bạn biết được trung bình bạn đi được 80 km trong 1 giờ
Nếu mục đích của bạn đi được 200 km:
- Bạn sẽ đi tiếp trong 30 phút nữa, hoặc
- Bạn sẽ dừng lại ở đây sau khi đi được 160km hoặc
- Bạn không cần tiếp nhiên liệu và đi cho tới khi hết trong vòng 15 phút, tính thời điểm này bạn đi được 180km
Với project cũng tương tự như vậy: Vận tốc của team được đánh giá với số lượng stories từ product backlog. Nếu bạn biết về tốc độ của team bạn, bạn sẽ biết được:
- Khối lượng công việc có giá trị của team bạn đã hoàn thành và chuyển tới cho user sử dụng tính tới thời điểm hiện tại ( số lượng stories hoàn thành)
- Khi nào team bạn có thể hoàn thành tất cả các stories ở product backlog
- Bao nhiêu stories sẽ được chuyển cho user, product owner vào 1 ngày định trước.
Đo vận tốc của team như thế nào ?
Chúng ta đơn giản dùng các biểu thức toán học
Ta có kịch bản như sau: Team của bạn hoàn thành 3 user stories. Tổng điểm cho 3 stories này là 20. Như vậy vận tốc của team là 20. Nếu ở vòng lặp tiếp theo ( sprint trong scrum, team của bạn hoàn thành được 30 điểm, chúng ta có vận tốc trung bình là 25 hay (20 SP +30SP) chia cho 2 vòng lặp = 25 SP
Vận tốc của team chính là số tổng điểm của các stories được hoàn thành bởi team trong 1 vòng lặp phát triển sản phẩm ( iteration hay sprint)
Tại sao chúng ta phải làm như vậy :
Chúng ta cần biết vận tốc để làm :
- Đoán trước bao nhiêu công việc được hoàn thành và chuyển giao ở một thời điểm nhất định.
- Đoán trước ngày để hoàn thành và chuyển giao một khối lượng công việc bắt buộc phải hoàn thành
- Hiểu được giới hạn của team khi đề ra khối lượng công việc được hứa hoàn thành cho 1 vòng lặp ( sprint)
- Đoán trước bao nhiêu công việc được hoàn thành và chuyển giao ở một thời điểm nhất định.
- Đoán trước ngày để hoàn thành và chuyển giao một khối lượng công việc bắt buộc phải hoàn thành
- Hiểu được giới hạn của team khi đề ra khối lượng công việc được hứa hoàn thành cho 1 vòng lặp ( sprint)
Những yếu tố nào phụ thuộc tác động vào vận tốc:
Giống như bạn lái 1 chiếc xe :
- Chướng ngại vật -- Những khó khăn thực hiện Agile và phát triển sản phẩm ví dụ như vấn đề về technical, vấn đề về con người, cách thức làm việc
- Xăng xe -- Động lực trong phát triển sản phẩm
- Kinh nghiệm của người lái xe -- Sự hiểu biết, kinh nghiệm của các thành viên trong team ví dụ như developer
- Tình trạng của xe -- Môi trường làm việc của team
- Những thứ nhìn thấy -- Sự trong suốt trong phát triển sản phẩm ( ví dụ: thông báo update cả team cùng biết)
- Hướng đi -- Những function sản phẩm
- Giao thông/ luật -- Qui trình
- Đích tới -- Sản phẩm được bàn giao
- Chướng ngại vật -- Những khó khăn thực hiện Agile và phát triển sản phẩm ví dụ như vấn đề về technical, vấn đề về con người, cách thức làm việc
- Xăng xe -- Động lực trong phát triển sản phẩm
- Kinh nghiệm của người lái xe -- Sự hiểu biết, kinh nghiệm của các thành viên trong team ví dụ như developer
- Tình trạng của xe -- Môi trường làm việc của team
- Những thứ nhìn thấy -- Sự trong suốt trong phát triển sản phẩm ( ví dụ: thông báo update cả team cùng biết)
- Hướng đi -- Những function sản phẩm
- Giao thông/ luật -- Qui trình
- Đích tới -- Sản phẩm được bàn giao
Chính vì vậy, nếu những yếu tố trên không được định nghĩa đúng, đủ, và tuân thủ vận hành, vận tốc của team bạn sẽ giảm xuống. Điều này hoàn toàn đúng cho việc phát triển sản phẩm của team bạn
Chúng ta có nên đếm cả những stories chưa hoàn thành ?
Câu trả lời là không. Vận tốc là những stories đã được hoàn thành và bàn giao. Sau đây là một vài lý do bạn không nên đếm cả stories chưa hoàn thiện:
- Trong Agile sản phẩm luôn được thay đổi nếu bạn đếm số lượng chưa hoàn thành thì sẽ không có ý nghĩa, chúng ta chỉ nên tập trung vào những stories hoàn thành để biết được team đang tới đâu. - Tỉ số giữa hoàn thành và chưa hoàn thành là con số tương đối nên nếu nhìn vào đó sẽ đưa ra đánh giá và hướng đi không đúng.
- Chưa hoàn thành có nghĩa là storie chưa mang lại giá trị nào cho khách hàng
- Trong Agile sản phẩm luôn được thay đổi nếu bạn đếm số lượng chưa hoàn thành thì sẽ không có ý nghĩa, chúng ta chỉ nên tập trung vào những stories hoàn thành để biết được team đang tới đâu. - Tỉ số giữa hoàn thành và chưa hoàn thành là con số tương đối nên nếu nhìn vào đó sẽ đưa ra đánh giá và hướng đi không đúng.
- Chưa hoàn thành có nghĩa là storie chưa mang lại giá trị nào cho khách hàng
Vậy chúng ta nên làm gì với những stories :
Hãy chia nhỏ những stories ra có thể. Đây là cách thức dễ dàng và hiệu quả khi đưa chúng vào các sprint và quản lý. Giống như phép chia để trị và gói gọn theo dạng cuốn chiếu
QA- Teams và vận tốc
Lỗi và những vấn đề bảo trì có được đưa vào trong tính toán vận tốc ?
Có, nếu bạn estimate 1 số điểm cho 1 story. Sau khi đã sửa chữa các lỗi, nâng cấp bảo trì, sản phầm tiếp tục được bàn giao tới người dùng. Mặc dù có thể không có giá trị mới với người dùng, những bugs, bảo trì có liên hệ trực tiếp với giá trị, chất lượng sản phầm hiện có. Vậy để kiểm soát vấn đề về lỗi, chúng ta nên làm gì ? Có vài cách để kiểm soát chúng. "Không tạo ra lỗi". Sử dụng luật zero-bugs và ưu tiên 1-fix-bugs. Bất kể khi nào có lỗi, hãy hoàn thành nó ngay lập tức.
Có nên so sánh vận tốc giữa các team khác nhau ?
Không. Bởi vì chúng ta làm việc dựa trên điểm cho mỗi story. Điểm này tuỳ vào từng team định nghĩa, nó không fix cố định cho tất cả các team. Nếu so sánh chúng ta sẽ tạo ra sự bất công bằng cho các team. Điểm cho story có thể tham chiếu từ nhiều yếu tố. ví dụ: độ khó của 1 story. Một team có thể khẳng định rằng stories có điểm là 400 SP hoặc với team khác chỉ là 2 SP. Ước lượng điểm cho story chỉ mang tính chất tương đối.
Vây, làm thế nào để so sánh vận tốc làm việc giữa các team với nhau ?
Team A bàn giao được 800 SP, team B bàn giao được 30 SP. Điều đó có nghĩa là team A tốt hơn team B ?
Thực sự chúng ta không cần biết rõ và cũng không cần quan tâm tới điều đó. Mỗi team thì tự thân có cách so sánh bên trong ứng với các sprints. Vận tốc không dùng để đánh giá. Vận tốc chỉ giúp chúng ta cải thiện vấn đề thời gian -- giúp chúng ta trở nên tốt hơn, tốt hơn và tăng tốc, cũng như điều chỉnh cho phù hợp với nguồn lực vốn có từ đó thúc đẩy tinh thần team, nhìn nhận các vấn đề yếu kém gây vận tốc chậm
Nếu nhiều team làm việc trong cùng 1 project backlog thì sẽ ra sao ?
Đây là 1 trường hợp khác biệt với trường hợp trên. Sẽ là bất hợp lý nếu các teams này sử dụng những tham chiếu khác nhau để tính điểm cho story. Chúng ta sử dụng điểm (story point) để dự đoán bao nhiêu khối lượng công việc được bàn giao tại 1 ngày nhất định, hoặc để dự đoán khi nào chúng ta có thể bàn giao được toàn bộ yêu cầu khách hàng. Vậy nếu chúng ta có nhiều hơn 1 team đang làm việc trên cùng 1 backlog, và nếu mỗi team lại có số điểm khác nhau cho 1 story, thì chúng ta không thể nào dự đoán được khối lượng công việc hoàn thành.
Trong trường hợp này, team phải cùng nhau xác định mối liên hệ giữa các stories ( ví dụ như mức độ khó của các story), cùng định nghĩa số điểm cho story dựa trên cùng một tham số. Sau đó, mọi quá trình phát triển, thay đổi, team sẽ dùng đơn vị này để ước lượng thời gian, khối lượng, resource ( nhân sự- tài chính) để hoàn thành.
Lấy ví dụ như sau: Ta có 2 story là story A và story B. Story B có mức độ khó theo team phát triển và các chuyên gia gấp đôi story A, sử dụng thời gian nhiều hơn với story A. Story A sẽ làm trong 2 SP, như vậy story sẽ có số điểm là 4 SP
Sau cùng, với trường hợp sử dụng chung về kích thước số điểm của story, chúng ta có nên so sánh các team với nhau :
Không. Bởi vì có thể một team hoàn thành và bàn giao được ít số điểm story hơn bởi vì do story đó chưa được ước lượng đúng. Hoặc có thể team đó giúp team khác hoặc team đó dành nhiều thời gian cho việc kiểm thử, tối ưu code, tái cấu trúc code cho chuẩn tắc... Chúng ta chỉ nên so sánh nội bộ team, đào sâu tìm hiểu lý do tại sao team lại làm chậm. Làm như vậy bạn có thê tìm ra được vài vấn đề cản trở team làm, và có biện pháp kịp thời để khắc phục và loại bỏ, phục hồi team.
Mỗi chiếc xe đều có đặc tính của nó. Chúng ta cần khai thác những đặc tính tốt nhất, cộng với bảo trì, sửa chữa. Nếu chúng ta bắt chúng làm việc quá với công suất hiện có, có thể bạn sẽ làm hỏng động cơ của chiếc xe.
Hãy giúp team bạn giỏi hơn, tiến xa, đừng chỉ có nhìn vào những điểm yếu cá nhân.
Con người thì vẫn là con người, chúng ta mỗi người lại có sự khác biệt. Chúng ta luôn có hiệu suất công việc khác nhau giữa các thành viên. Chúng ta luôn luôn cần giữ một môi trường bền vững, nhiệt huyết và giúp cho các thành viên của team tiến xa, để chèo lái và phát triển công ty của bạn.
Theo Scrumalliance
Vây, làm thế nào để so sánh vận tốc làm việc giữa các team với nhau ?
Team A bàn giao được 800 SP, team B bàn giao được 30 SP. Điều đó có nghĩa là team A tốt hơn team B ?
Thực sự chúng ta không cần biết rõ và cũng không cần quan tâm tới điều đó. Mỗi team thì tự thân có cách so sánh bên trong ứng với các sprints. Vận tốc không dùng để đánh giá. Vận tốc chỉ giúp chúng ta cải thiện vấn đề thời gian -- giúp chúng ta trở nên tốt hơn, tốt hơn và tăng tốc, cũng như điều chỉnh cho phù hợp với nguồn lực vốn có từ đó thúc đẩy tinh thần team, nhìn nhận các vấn đề yếu kém gây vận tốc chậm
Nếu nhiều team làm việc trong cùng 1 project backlog thì sẽ ra sao ?
Đây là 1 trường hợp khác biệt với trường hợp trên. Sẽ là bất hợp lý nếu các teams này sử dụng những tham chiếu khác nhau để tính điểm cho story. Chúng ta sử dụng điểm (story point) để dự đoán bao nhiêu khối lượng công việc được bàn giao tại 1 ngày nhất định, hoặc để dự đoán khi nào chúng ta có thể bàn giao được toàn bộ yêu cầu khách hàng. Vậy nếu chúng ta có nhiều hơn 1 team đang làm việc trên cùng 1 backlog, và nếu mỗi team lại có số điểm khác nhau cho 1 story, thì chúng ta không thể nào dự đoán được khối lượng công việc hoàn thành.
Trong trường hợp này, team phải cùng nhau xác định mối liên hệ giữa các stories ( ví dụ như mức độ khó của các story), cùng định nghĩa số điểm cho story dựa trên cùng một tham số. Sau đó, mọi quá trình phát triển, thay đổi, team sẽ dùng đơn vị này để ước lượng thời gian, khối lượng, resource ( nhân sự- tài chính) để hoàn thành.
Lấy ví dụ như sau: Ta có 2 story là story A và story B. Story B có mức độ khó theo team phát triển và các chuyên gia gấp đôi story A, sử dụng thời gian nhiều hơn với story A. Story A sẽ làm trong 2 SP, như vậy story sẽ có số điểm là 4 SP
Sau cùng, với trường hợp sử dụng chung về kích thước số điểm của story, chúng ta có nên so sánh các team với nhau :
Không. Bởi vì có thể một team hoàn thành và bàn giao được ít số điểm story hơn bởi vì do story đó chưa được ước lượng đúng. Hoặc có thể team đó giúp team khác hoặc team đó dành nhiều thời gian cho việc kiểm thử, tối ưu code, tái cấu trúc code cho chuẩn tắc... Chúng ta chỉ nên so sánh nội bộ team, đào sâu tìm hiểu lý do tại sao team lại làm chậm. Làm như vậy bạn có thê tìm ra được vài vấn đề cản trở team làm, và có biện pháp kịp thời để khắc phục và loại bỏ, phục hồi team.
Mỗi chiếc xe đều có đặc tính của nó. Chúng ta cần khai thác những đặc tính tốt nhất, cộng với bảo trì, sửa chữa. Nếu chúng ta bắt chúng làm việc quá với công suất hiện có, có thể bạn sẽ làm hỏng động cơ của chiếc xe.
Hãy giúp team bạn giỏi hơn, tiến xa, đừng chỉ có nhìn vào những điểm yếu cá nhân.
Con người thì vẫn là con người, chúng ta mỗi người lại có sự khác biệt. Chúng ta luôn có hiệu suất công việc khác nhau giữa các thành viên. Chúng ta luôn luôn cần giữ một môi trường bền vững, nhiệt huyết và giúp cho các thành viên của team tiến xa, để chèo lái và phát triển công ty của bạn.
Theo Scrumalliance
