Nhái Cốm Blog

I love you just the way you are

0R8A4000_

5 phương pháp giúp lập trình viên ước lượng tốt hơn

Leave a comment

Author: jsonmez
Original Post in English: 5 Ways Software Developers Can Become Better at Estimation

(lược dịch)

Phương pháp 1: Chia nhỏ vấn đề

Tôi đã từng đề cập (chưa đọc nên chả rõ anh ý đề cập lúc nào và ở đâu😀) đến vấn đề tạo ra thời hạn quá xa làm việc ước lượng trở nên khó khăn và thiếu chính xác như thế nào; không may điều đó lại thường thấy trong bất kì dự án phát triển phần mềm nào.

Nếu bạn được yêu cầu ước lượng và bạn cho rằng công việc này sẽ tốn 5 phút để hoàn thành, kết quả ước lượng đó sẽ chính xác hơn nhiều so với việc ước lượng một công việc bạn cho rằng cần 5 tháng để hoàn thành.

Vậy thì làm thế nào để giải quyết vấn đề này?

Thật sự thì cách giải quyết tương đối đơn giản: Chia nhỏ công việc ra thành nhiều phần nhỏ và ước lượng cho những phần việc nhỏ đó.

Tôi biết điều này nghe có vẻ đơn giản và dễ thực hiện. Tôi cũng biết sẽ có những hoài nghi với cách tiếp cận này. Bạn sẽ có hàng tá lý do để bào chữa cho việc tại sao mình không chia nhỏ công việc ra. Nhưng sự thật là phần lớn công việc đều có thể chia nhỏ nếu bạn thực sự muốn làm.

Tuy nhiên, tôi đang bàn về việc tại sao việc chia nhỏ công việc ra lại tốt hơn và làm thế nào để chia nhỏ công việc tồn đọng từ trước tới giờ. Vì vậy, tôi sẽ không lan man thêm vào những chi tiết vụn vặt trong bài viết này.

Chìa khóa cho vấn đề ở đây là bạn không bao giờ đưa ra được một ước lượng chính xác với những công việc lớn. Tôi xin phép nhắc lại một lần nữa: Cách duy nhất bạn có thể ước lượng chính xác những công việc lớn là học cách chia nhỏ chúng thành những phần việc nhỏ hơn.

Nếu bạn thực sự cần ước lượng chính xác một việc nào đó, việc dành thời gian và công sức chia nhỏ việc đó thành những phần việc nhỏ sẽ thực sự đáng giá.

Ví dụ, giả sử tôi phải ước lượng khoảng thời gian cần thiết để hoàn thành một bài viết. Đó không phải là một công việc quá lớn, nhưng nó đủ lớn để gây ra sai lệch trong việc ước lượng.

Nếu tôi muốn kết quả chính xác hơn, tôi có thể chia nhỏ công việc của mình thành những việc nhỏ hơn.

Bạn có thể so sánh sự khác nhau giữa việc cố gắng phải ước lượng:

  • Viết và đăng lên một bài viết

So với việc ước lượng:

  • Nghiên cứu và đưa ra những vấn đề sẽ đề cập đến trong bài viết
  • Định hình bài viết
  • Viết một bản nháp
  • Thêm ảnh và liên kết
  • Lên kế hoạch đăng bài viết

Bằng cách phân chia ra, tôi có thể ước lượng chính xác hơn những công việc nhỏ này. Trên thực tế, khi vấn đề được chia nhỏ, tôi có thể giới hạn thời gian cho từng tiến trình một. Điều này đặc biệt hữu ích giúp kết quả ước lượng của tôi chính xác (để tránh đi quá xa, tôi sẽ đề cập đến vấn đề này sau).

Lần tới, khi được yêu cầu ước lượng một vài tính năng nào đó, thay về ước lượng xem bạn cần bao lâu để hoàn thành toàn bộ công việc, hãy cố gắng chia nhỏ tính năng và ước lượng xem bạn cần bao lâu để hoàn thành từng phần việc nhỏ một. Lúc nào bạn cũng có thể thêm vào những ước lượng, đánh giá mới để đưa ra kết quả chung chính xác hơn.

Đợi một chút! Tôi biết chính xác điểm sai bạn sẽ đề cập đến với kiểu ước lượng này. Hiển nhiên việc ước lượng các phần việc nhỏ sẽ chính xác hơn; nhưng khi bạn kết hợp chúng lại với nhau, tính chung lại bạn sẽ nhận được sai số tương đương với việc bạn ước lượng một công việc lớn.

Tất cả những gì tôi có thể trả lời với thắc mắc này là “hãy thử xem”. Ở một góc độ nào đó bạn có thể đúng. Nhiều sai số nhỏ gộp lại sẽ tạo thành một sai số lớn. Nhưng những sai số nhỏ này cũng có xu hướng bù trừ lẫn nhau. Một số công việc cần nhiều thời gian hơn những một số khác lại cần ít hơn. Điều này có nghĩa gộp chung lại, bạn sẽ có kết quả ước lượng chính xác hơn nhiều so với việc ước lượng một công việc lớn.

Phương pháp 2: Dành thời gian nghiên cứu

Tại sao bạn lại tệ trong việc ước lượng?

Lý do là bạn chưa hiểu đầy đủ về công việc bạn đang ước lượng.

Tôi từng đề cập đến việc không nắm được những điều mình không hiểu (đây là hiểm họa với rất nhiều dự án phát triển phần mềm) gây khó cho việc ước lượng như thế nào. Tuy nhiên, tôi chưa giải thích làm thế nào để giải quyết vấn đề chúng ta không nắm được những điều chúng ta không hiểu.

Thêm một lần nữa, câu trả lời cũng rất đơn giản: Nghiên cứu.

Cách tốt nhất để tránh việc không nắm được những điều mình không hiểu là biết rõ về nó.

Mỗi khi bạn được giao nhiệm vụ ước lượng, điều đầu tiên bạn nên nghĩ đến là nghiên cứu, cố gắng khám phá ra những gì mình chưa biết.

Thật không may là phần lớn lập trình viên không nghĩ đến việc nghiên cứu ngay khi họ ước lượng một công việc. Thay vì vậy, họ chủ yếu dựa vào kinh nghiệm trong quá khứ của mình. Nếu họ đã hoàn thành một việc tương tự trước đây, học sẽ tự tin ước lượng công việc mới mà bỏ qua tất cả những gì mình chưa nắm rõ. Nếu họ chưa bao giờ thực hiện một công việc tương tự, họ sẽ cho rằng có rất nhiều vấn đề cần phải làm và đưa ra kết quả ước lượng vống lên so với thực tế.

Cả hai cách làm trên không có cách nào tốt. Thay vì vậy, bạn nên tìm hiểu, đánh giá xem mình cần bao nhiêu thời gian để nghiên cứu về công việc trước ước lượng thời gian cần để thực hiện công việc đó. Bạn sẽ nhận ra rằng phần lớn lập trình viên ước lượng khá tốt thời gian họ cần để nghiên cứu; cho dù họ có thể rất tệ trong việc ước lượng thời gian cần để hoàn thành công việc đó.

Khi bạn đã hoàn thành việc nghiên cứu, bạn sẽ ít phải đối mặt với những vấn đề bạn không biết là mình không hiểu hơn. Tất nhiên, sẽ có những vấn đề bạn chưa hiểu nhưng ít nhất bạn cũng biết về điều đó.

Việc nghiên cứu trên thực tế là như thế nào?

Làm cách nào bạn nghiên cứu những công việc bạn sẽ phải ước lượng?

Đôi khi nó liên quan đến việc lên kế hoạch ra xa hơn một chút so với thời hạn. Tôi sẽ đưa ra một ví dụ về cách thực hiện trong một nhóm sử dụng Scrum hay Agile.

Giả sử bạn muốn cải thiện khả năng ước lượng của mình bằng việc thực hiện nghiên cứu trước khi tiến hành ước lượng công việc. Vấn đề ở đây là khi bạn làm việc trong một dự án sử dụng mô hình Agile, bạn luôn luôn phải ước lượng các công việc thực hiện trong một chu trình phát triển và không thật sự có thời gian để nghiên cứu từng công việc trước khi ước lượng công việc đó, đặc biệt là với những công việc lớn.

Tôi thấy rằng cách tốt nhất có thể làm trong hoàn cảnh này là chuyển công việc đó sang chu trình tiếp theo thay vì ước lượng nó ngay lập tức. Công việc bạn sẽ làm ở chu trình hiện tại là đánh giá xem mình cần bao nhiêu thời gian để nghiên cứu công việc đó.

Bạn có thể có rất nhiều việc nhỏ trong chu trình phát triển hiện tại với mục đích cung cấp đầy đủ thông tin giúp ước lượng chính xác hơn những công việc lớn ở chu trình phát triển tiếp theo. Trong quá trình thực hiện những công việc nhỏ này, bạn cũng có thể chia nhỏ những việc lớn thành những việc nhỏ hơn khi bạn hiểu rõ hơn.

Đợt chút! Tôi biết bạn đang nghĩ gì. Tôi không thể chỉ đơn giản là đẩy công việc sang chu trình phát triển tiếp theo. Sếp tôi và những người làm kinh doanh không thích điều đó. Họ muốn công việc được hoàn hiện ở chu trình phát triển hiện tại.

Tất nhiên là bạn đúng. Vậy làm thế nào bạn giải quyết vấn đề này?

Điều này cũng rất đơn giản. Bạn chỉ cần lên kế hoạch những công việc lớn cần hoàn thiện vào thời gian nào. Nếu bạn làm việc trong nhóm sử dụng mô hình Agile, bạn nên nhắm đến việc nghiên cứu những công việc lớn, những công việc sẽ phải thực hiện ở các chu trình phát triển sau.

Bằng cách luôn tìm tòi, nghiên cứu trước khi ước lượng bất kì việc gì, bạn sẽ tạo tạo dựng cho mình thói quen đưa ra những ước lượng chính xác hơn nhiều.

Cách làm này cũng có thể áp dụng với các công việc nhỏ, bằng cách dành ra khoảng 5 đến 10 phút để tìm hiểu về công việc đó trước khi đưa ra ước lượng.

Lần kế, khi bạn ước lượng một công việc, hãy dành ra một chút thời gian để nghiên cứu. Bạn sẽ ngạc nhiên khi nhận ra rằng kết quả ước lượng của mình trở nên chính xác hơn nhiều như thế nào.

Phương pháp 3: Theo dõi thời gian

Một trong những vấn đề lớn chúng ta gặp phải trong việc ước lượng là cảm giác chính xác thời gian. Việc nhớ lại thời gian thực hiện các dự án trong quá khứ của tôi thường bị sai lệch ít nhiều tùy theo mức độ yêu thích của tôi với dự án cũng như việc tôi đã đói đến như thế nào.

Sự sai lệch thời gian này có thể dẫn đến kết quả ước lượng cực kỳ sai lầm.

Vì lý do này, việc theo dõi thời gian bạn thực sự dùng cho công việc là rất quan trọng.

Tạo cho mình thói quen theo dõi thời gian của bất kì công việc nào bạn làm là một ý tưởng tuyệt vời. Hiện tại, trong khi đang viết bài này, đồng hồ của tôi vẫn đang chạy để theo dõi thời gian tôi bỏ ra. Vì thế, tôi có thể biết được việc viết các bài viết cần bao nhiêu thời gian. Tôi cũng có thể biết được liệu tôi có tiêu tốn quá nhiều thời gian vào một giai đoạn nào đó hay không.

Khi bạn tạo được cho mình thói quen theo dõi thời gian, bạn sẽ mường tượng tốt hơn khoảng thời gian cũng như địa điểm sử dụng cho một công việc nào đó.

Sẽ là điên rồi nếu cho rằng bạn có thể ước lượng tốt những công việc chưa làm trong khi bạn thậm chí không thể nói chính xác thời gian bạn đã làm một việc trước đây.

Bạn nên nghiêm túc suy nghĩ về vấn đề này trong một phút. Đừng cười, tôi nói thật đấy! Theo tôi bạn nên nghĩ về việc sẽ vô lý đến như thế nào nếu tin rằng mình có thể ước lượng tốt bất kỳ công việc gì trong khi bạn không thể nhớ lại được mình đã làm một công việc nào đó trước đây trong bao lâu.

Nhiều người phàn nàn rằng việc phát triển phần mềm không giống như những công việc khác, và rằng công việc này không thể ước lượng chính xác. Tôi đồng ý rằng việc phát triển phần mềm khó ước lượng hơn việc trải thảm hay lợp lại mái nhà. Nhưng tôi nghĩ rằng nhiều lập trình viên không làm tốt trong việc ước lượng là do họ không có ý tưởng gì về khoảng thời gian dành cho những công việc đó.

Hãy tự giúp bản thân mình và bắt đầu theo dõi thời gian. Có rất nhiều công cụ tốt giúp bạn thực hiện việc này:

Nhân tiện, làm theo cách này đã giúp tôi tốt hơn rất nhiều trong việc ước lượng. Tôi luôn có thể ước lượng chính xác toàn bộ công việc trong tuần trong 1 đến 2 giờ. Và tất nhiên, tôi biết được thời gian mình cần để ước lượng bởi vì tôi đã theo dõi thời gian cho việc đó.

Phương pháp 4: Giới hạn thời gian cho công việc

Tôi đã nói rằng tôi sẽ quay lại vấn đề này. Và đây chính là thời điểm đề cập đến.

Một bí mật lớn để trở thành một lập trình viên, người có thể ước lượng tốt công việc, là giới hạn thời gian cho từng công việc một. Điều này gần giống như là gian lận.

Khi bạn giới hạn thời gian cho công việc, bạn đảm bảo nó tiêu tốn đúng khoảng thời gian mà bạn đã lên kế hoạch.

Có lẽ bạn đang nghĩ rằng phần lớn công việc phát triển phần mềm không thể giới hạn thời gian; bạn đã sai. Tôi sử dụng công cụ này thường xuyên và tôi phát hiện ra rằng nhiều công việc chúng ta làm có xu hướng không cố định thời gian phải dành cho chúng.

Tôi cũng phát hiện ra rằng nếu bạn sử dụng một khoảng thời gian cố định (và chỉ dùng đúng khoảng thời gian đó) cho một việc, bạn có thể làm việc theo hướng đảm bảo công việc được hoàn thanh đúng hạn.

Hay xem một ví dụ về việc viết mã kiểm thử đơn vị (Unit test):

Với phần lớn lập trình viên, viết mã kiểm thử đơn vị (Unit test) là một công việc có tính chủ quan. Trừ khi bạn hướng tới mục đích kiểm tra toàn bộ mã, bạn luôn chỉ viết mã kiểm thử đơn vị (Unit test) khi bạn cảm thấy bạn phải kiểm tra đầy đủ đoạn mã. (Nếu bạn đang phát triển phần mềm theo hướng kiểm thử, Test Driven Development – TDD, điều này có lẽ không còn chính xác).

Nếu bạn giới hạn một khoảng thời gian dành cho việc viết mã kiểm thử đơn vị (Unit test), bạn có thể ép mình làm việc với những khối mã quan trọng trước và thực hiện theo nguyên tắc 80/20 để đảm bảo rằng bạn sẽ thu lợi lớn nhất trong giới hạn cho phép.

Đối với nhiều công việc, bạn có thể kết thúc với việc tiêu tốn thêm nhiều giờ cho những chi tiết vụn vặt mà chẳng tạo nên nhiều khác biệt. Giới hạn thời gian ép buộc bạn làm việc với những việc quan trọng trước, tránh thực hiện những công việc như tối ưu hóa ngay trong giai đoạn đầu hay bị ám ảnh về việc đặt tên làm sao cho đúng.

Hiển nhiên rằng sẽ có lúc bạn sử dụng vượt quá thời gian mình thiết lập ra. Nhưng trong nhiều lần khác, bạn sẽ thấy rằng mình thực sự có thể hoàn thành công việc cần thiết; sau đó, bạn luôn có thể quay lại sửa cho nó tốt hơn khi có thời gian.

Tôi xin nhắc lại một lần nữa: bạn hãy yêu thích việc theo dõi thời gian; nó là một thói quen bạn phải gây dựng. Đến khi bạn đã quen với nó, bạn sẽ có khả năng sử dụng nó như một mánh lới giúp các ước lượng của mình trở nên chính xác hơn bất kì thứ gì bạn có thể tưởng tượng.

Phương pháp 5: Kiểm tra lại ước lượng của bạn

Đây là một bí mật nhỏ: Bạn không phải ước lượng chính xác ngay lần đầu tiên. Thay vì thế, bạn có thể xem lại ước lượng của mình như một tiến trình trong công việc.

Tôi biết sếp bạn muốn bạn đưa ra một ước lượng chính xác ngay từ đầu chứ không phải lúc bạn gần hoàn thành công việc đó. Nhưng bạn luôn được phép đưa ra ước lượng chính xác nhất có thể và xem lại ước lượng của mình như một tiến trình trong công việc.

Tôi không thể nghĩ ra bất kỳ tình huống nào trong đó việc cập nhập thêm thông tin lại không được hoan nghênh.

Hãy sử dụng bốn phương pháp trên để đảm bảo rằng ước lượng ban đầu của bạn sẽ chính xác hết mức có thể. Nhưng bạn nên định kỳ dành ra một chút thời gian để đánh giá lại tình trạng thực tế của ước lượng đó.

Hãy nghĩ theo hướng nay: Bạn biết thời điểm bạn tải về một tệp tin và máy tính thông báo với bạn cần bao lâu để hoàn tất công việc đó. Liệu bạn có nghĩ rằng nó tính toán quãng thời gian này ngay từ đầu và không bao giờ cập nhập lại? Tất nhiên là không. Thay vì vậy, phần lớn các chương trình quản lý đều định kỳ cập nhập khoảng thời gian ước tính còn lại.

Nói chung, tiến hành phương pháp này có thể giúp bạn ước lượng tốt hơn. Khi bạn định kỳ xem lại và cập nhập ước lượng của mình, bạn sẽ nhận ra lý do tại sao ước lượng ban đầu của mình lại chưa chính xác.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s