Phân rã công việc
(jacobian.org)- Việc ước tính hay giao việc cho một dự án bắt đầu từ việc biến những yêu cầu lớn như “xây cái này” thành danh sách công việc rõ ràng, và mỗi mục cần thể hiện thay đổi mong muốn cũng như trạng thái hoàn thành
- Quá trình phân rã là viết ra các bước cần thiết từ ý tưởng, bản phác thảo, hoặc danh sách ban đầu, rồi chia nhỏ đệ quy cho đến khi từng mục được định nghĩa đủ rõ
- Ví dụ về streak tracker cho hoạt động ngoài trời dần được tách thành mô hình dữ liệu, chế độ xem lịch, ghi lại hoạt động, tính streak, và streak freeze, đồng thời cũng làm lộ ra các điểm còn chưa chắc chắn
- “Công việc được định nghĩa đủ rõ” là trạng thái có thể trả lời có cho tất cả các câu hỏi về thay đổi mong muốn, hình hài khi hoàn thành, mọi bước cần để hoàn thành, và mọi thông tin cần thiết để bắt đầu ngay
- Vì phân rã công việc là một kỹ năng cần đối sánh mẫu dựa trên kinh nghiệm, các nhóm mới cần cơ hội luyện tập an toàn để thử lập kế hoạch và nhận phản hồi
Biến dự án lớn thành danh sách công việc
- Các thảo luận trước đây về ước tính dự án giả định rằng đã có một danh sách công việc rõ ràng, nhưng trong thực tế, trước đó thường cần đến bước phân rã công việc
- Phân rã công việc là quá trình chia một dự án lớn thành các phần cấu thành; để ước tính hay giao việc, cần những đơn vị chi tiết hơn là một nhiệm vụ đơn lẻ như “làm ra màn hình này”
- Với dự án cá nhân do một người tự làm, chỉ cần bản phác thảo có thể đã đủ, nhưng nếu muốn giao cho người khác hoặc ước tính thời gian thì cần nâng mức chi tiết lên cao hơn
Ví dụ: streak tracker cá nhân
- Một streak tracker cá nhân để theo dõi những ngày có hoạt động ngoài trời được dùng làm ví dụ
- Muốn có dạng tương tự ứng dụng Streaks
- Muốn thêm các lựa chọn hoạt động ngoài trời như chạy bộ, đạp xe, trượt tuyết
- Cũng muốn bao gồm tính năng streak freeze của Duolingo
-
Lần 1: bắt đầu từ bản phác thảo
- Mockup trực quan là điểm khởi đầu tốt vì nó cho thấy rõ những gì sẽ được xây dựng
- Nếu là dự án tự làm một mình thì chỉ với mức phác thảo này cũng có thể bắt tay viết code ngay
- Nếu mục tiêu là ước tính hay giao việc thì cần một danh sách công việc được chia nhỏ hơn là chỉ “làm ra màn hình này”
-
Lần 2: chia theo các khối tính năng lớn
- Ở lần phân rã đầu tiên, dự án được chia thành các thành phần tổng quát
- Mô hình hóa dữ liệu
- Chế độ xem lịch hiển thị các ngày của tuần hiện tại
- Lịch tương tác cho phép bấm biểu tượng để ghi lại hoạt động và đánh dấu ngày đó là hoàn thành trong phần theo dõi streak
- Tính toán và hiển thị độ dài streak hiện tại
- Triển khai streak freeze
- Để đơn giản hóa ví dụ, các công việc vận hành như triển khai hay thiết lập cơ sở dữ liệu được bỏ qua
- Trong dự án thực tế, đặc biệt là dự án có nhiều người tham gia, thường hợp lý hơn nếu tách riêng các đầu việc triển khai, frontend và backend
- Chỉ đến bước này cũng đã có thể ước tính phần nào, nhưng vẫn còn các điểm bất định như cách tích lũy và theo dõi freeze, bản ghi quá khứ, hay thêm và xóa loại hoạt động
-
Lần 3: chia tiếp để tiêu chí hoàn thành trở nên rõ ràng
- Mô hình dữ liệu được chia thành loại hoạt động, hoạt động đã ghi, freeze và streak
- Với loại hoạt động, chỉ cần một danh sách hard-code như run/bike/ski/climb là đủ
- Hoạt động đã ghi có ngày và loại
- Freeze có ngày nhận được và ngày sử dụng
- Streak có ngày bắt đầu, ngày kết thúc và thông tin tổng hợp theo từng loại hoạt động
- Chế độ xem lịch tĩnh được chia thành chế độ xem tuần, màn hình chính, chế độ xem tháng, điều hướng và nhập để di chuyển ngày
- Với việc di chuyển ngày, có thể dùng widget ngày HTML5 thay vì phải hỗ trợ nhập fuzzy date phức tạp
- Lịch tuần động không đưa phần nhập động vào chế độ xem tháng, mà ghi nhận hoàn thành bằng cách bấm loại hoạt động cho một ngày cụ thể
- Phần tính và hiển thị streak sẽ quét qua bản ghi hoạt động để tính streak, hiển thị streak hiện tại trên UI, rồi tính lại streak khi người dùng ghi hoạt động từ UI
- Streak freeze bao gồm tích lũy, ngăn tích lũy trùng lặp, cũng như hiển thị việc sử dụng và số lượng còn lại trên UI
- Tiêu chí X ngày để nhận freeze trước mắt có thể hard-code
- Freeze có thể được chuyển sang streak tiếp theo
- Khi sửa hoạt động quá khứ và tính lại streak, cần ngăn việc tích lũy trùng lặp khiến cùng một freeze được nhận lại
Quy trình phân rã lặp đi lặp lại
- Phân rã công việc không phải là thiết kế xong trong một lần mà là một quá trình lặp
- Bắt đầu từ danh sách công việc hoặc một dự án lớn
- Nghĩ và viết ra các bước cần thiết để hoàn thành công việc đó
- Kiểm tra xem từng bước đã được định nghĩa đủ rõ chưa
- Nếu chưa đủ thì phân rã tiếp mục đó
- Mỗi vòng lặp không cần phải hoàn chỉnh hay chính xác tuyệt đối; chỉ cần mở rộng thêm đôi chút so với danh sách trước là đủ
- Lặp lại cùng một quy trình cho đến khi mọi công việc đều được định nghĩa đủ rõ
Tiêu chí của “công việc” và “được định nghĩa đủ rõ”
- Trong phát triển phần mềm và ước tính dự án, công việc là một đơn vị việc làm được định nghĩa đủ rõ, trọn vẹn, và truyền tải được thay đổi
- “làm linh tinh gì đó” không phải là công việc vì không có đường nét yêu cầu rõ ràng
- “đốn cái cây” không phải là một công việc trọn vẹn nếu bạn chỉ mang theo cưa máy
- Trong bối cảnh công việc, một tác vụ chỉ có ý nghĩa khi sau khi làm xong thì có điều gì đó thay đổi
- Một công việc có được định nghĩa đủ rõ hay không được đánh giá bằng việc người thực hiện có thể trả lời “có” cho toàn bộ các câu hỏi sau hay không
- Có hiểu thay đổi mong muốn là gì không
- Có hiểu “hoàn thành” sẽ trông như thế nào không
- Có thể xác định mọi bước cần thiết để đi tới hoàn thành không
- Nếu không có yếu tố chặn hay phụ thuộc, đã có đủ mọi thông tin cần để bắt đầu ngay bây giờ chưa
- Tùy theo bối cảnh tổ chức, những người quan sát như quản lý dự án, bên liên quan chính, hoặc kiểm toán viên cũng có thể cần trả lời “có” cho các câu hỏi này
- Cũng có những công việc như sửa lỗi mà tồn tại ẩn số khó có thể chia nhỏ thêm
- Trong những trường hợp như vậy, có thể dùng các kỹ thuật như timeboxing
Cảm giác phân rã được tích lũy từ kinh nghiệm
- Phân rã công việc là một kỹ năng cần luyện tập, và việc ban đầu thấy nó không dễ là hoàn toàn bình thường
- Lý do đặt mô hình dữ liệu lên trước trong ví dụ không phải vì có thuật toán rõ ràng, mà vì trực giác từ kinh nghiệm
- Khi xây các công cụ tương tự, kinh nghiệm cho thấy chốt mô hình dữ liệu trước thì mọi thứ tiến triển thuận hơn
- Django cung cấp các affordance phù hợp hơn với luồng ưu tiên dữ liệu mô hình
- Nếu chưa có nhiều kinh nghiệm quan sát hoặc thực hiện nhiều dự án, có thể sẽ khó xác định điểm bắt đầu
- Để cả nhóm phát triển được năng lực này, cần một môi trường an toàn để lập kế hoạch dự án, thử phân rã, và nhận phản hồi
- Nếu không trừng phạt những bản kế hoạch ban đầu sai lệch nhiều, thì chính các sai sót đó sẽ trở thành dữ liệu kinh nghiệm cho lần đối sánh mẫu sau
Kết quả ước tính cho dự án ví dụ
- Trong phần ước tính bổ sung, sau khi chia nhỏ công việc thì mỗi mục được gắn độ phức tạp, mức bất định, số ngày dự kiến, và số ngày trong trường hợp xấu nhất
- Tổng ước tính được tính là 15,5 ngày, còn trường hợp xấu nhất là 23,5 ngày
- Trong các hạng mục chính, phần tính streak và tích lũy freeze đều có độ phức tạp medium và mức bất định moderate, với ước tính 3 ngày và xấu nhất là 4,5 ngày cho mỗi mục
- Việc ngăn freeze tích lũy trùng lặp có độ phức tạp small nhưng mức bất định extreme, nên được tính là 1 ngày và xấu nhất là 5 ngày
- Trên thực tế, mọi thứ đã được hoàn thành trong khoảng mười hai buổi tối và một chuyến bay dài, nhưng phần thiết kế đã được lược bỏ khá nhiều, và thuật toán freeze có thể vẫn còn lỗi sẽ lộ ra về sau
1 bình luận
Ý kiến trên Hacker News
Thứ nhất, tôi hầu như chưa bao giờ thực hiện hết các bước thực tế đúng như đã lên kế hoạch. Chỉ sau vài bước là lại có nhận ra mới, phát hiện thứ bị bỏ sót, hoặc thấy một cách dễ hơn, nên kế hoạch sẽ không còn được bám theo
Thứ hai, tôi không thích làm việc theo cách này vì có cảm giác toàn bộ nỗ lực sáng tạo để nghĩ ra cách làm đều bị dồn hết vào phần đầu. Trong khi phần còn lại vẫn chiếm phần lớn công việc, thì chỉ còn lại đoạn chán nhất; trộn đều sáng tạo và nhàm chán hơn thì vui hơn, vì thế nhanh hơn và kết quả cũng tốt hơn
Hai điều này có lẽ có liên quan với nhau, và cũng không loại trừ khả năng tôi bị ADHD
Nếu bạn đang khám phá hoặc xây dựng một dự án cá nhân và không có cơ chế trách nhiệm nào đáng kể, thì trừ khi bạn thích lập kế hoạch, còn không cũng chẳng cần lên kế hoạch đến mức đó
Nhưng ngay khoảnh khắc sếp hỏi “mất bao lâu? ai làm gì? bắt đầu từ đâu?” thì bạn sẽ cần một khuôn khổ nào đó
Tôi cũng ghét việc phải ép mình vào những hệ thống tùy tiện hoặc quá cứng nhắc, nhưng hệ thống nên đơn giản và linh hoạt, và hệ thống năng suất là để hỗ trợ con người
Có lẽ tác giả không định biến nó thành một công thức nấu ăn chi tiết, mà chỉ muốn cho thấy cách tiếp cận của mình để người khác tự rút ra ý tưởng riêng
Có khi còn tệ hơn cả chuyện “kế hoạch không bao giờ được làm đúng y nguyên”. Nếu bạn cứ tiếp tục thêm việc trong lúc thực hiện, thì đến cuối cùng chỉ còn lại một danh sách lộn xộn các việc chưa xong, trộn lẫn giữa các việc tạo ra lúc lập kế hoạch và các việc phát sinh sau đó mà thậm chí không còn cần nữa
Những việc đó được tạo ra khi chưa có toàn bộ ngữ cảnh chỉ xuất hiện trong quá trình thực thi
Cái hay của lập trình nằm ở chỗ nó là một hoạt động sáng tạo linh hoạt, trôi chảy. Bạn vừa đi vừa tạo ra và trải nghiệm nó một cách hữu cơ
Trong môi trường công việc, vì cần giám sát và quy trách nhiệm, tính hữu cơ đó chủ yếu bị loại bỏ
Lần sau khi lên kế hoạch cho việc giống hoặc tương tự, kế hoạch tương lai sẽ tốt hơn
Các quản lý dự án cũng có khẩu hiệu “không lập kế hoạch tức là lên kế hoạch cho thất bại”
Vì tôi thường nhận ra mình bỏ sót nhiều thứ giữa vô số điều cần nhớ
Kế hoạch chỉ là cách để bản thân trong quá khứ nhắc bản thân trong tương lai về kết quả lý tưởng mà mình từng nghĩ tới. Thay vì cứ mãi sửa kế hoạch và chạy theo những đốm sáng chập chờn
“Chia nhỏ công việc” là một chủ đề lớn đến mức hoàn toàn có thể trở thành cả một thể loại sách hay podcast. Khi đọc các sách về phát triển bản thân hoặc tổ chức công việc, tôi thường thấy họ giả định việc chia nhỏ công việc là một năng lực con người nguyên thủy mà độc giả vốn đã có
Nhưng theo trải nghiệm của tôi và những gì nghe được trong các buổi thảo luận nhóm, chia nhỏ công việc là việc rất khó và có thể gây cảm giác né tránh hoặc tuyệt vọng
Lời khuyên có vẻ áp dụng rộng nhất mà tôi từng thấy là: hãy tiếp tục chia nhỏ cho đến khi mức tự tin rằng mình có thể hoàn thành tác vụ đó thành công đạt 90%. Mức độ tự tin này thay đổi theo mức tự tin vào bản thân và xu hướng chấp nhận rủi ro; với một số người, có thể chỉ cần chia đến mức xác suất thành công khoảng 70%
Một ngày làm việc thực sự có thể dùng được khoảng 6 tiếng, nhưng khi ai đó tự tin nói là “nửa ngày” thì nếu bạn chỉ ra rằng như vậy là khoảng 3 tiếng, họ bỗng kém chắc chắn hẳn hoặc thấy khó chịu. Rồi 3 ngày sau họ vẫn còn đang làm nó
Cách này cho kết quả ước lượng thời gian chính xác đến ngạc nhiên, nhưng nếu nhìn theo tổng thể thì đúng, còn từng ước lượng riêng lẻ thì sai rất xa
Xét cho cùng nó là ước lượng xác suất. Qua nhiều sự kiện, nó sẽ hội tụ về trung bình
Điều mà đa số không hiểu là phát triển phần mềm trước hết gần với một hoạt động sáng tạo. Tất nhiên nó có khía cạnh kỹ thuật nghiêm túc, nhưng vì bản thân vấn đề mang tính ảo và không bị trói buộc bởi các ràng buộc của thế giới thực như kỹ thuật xây dựng, nên không có một lời giải tối ưu duy nhất
Nếu cố định nghĩa lời giải trước khi xem xét đúng mức vấn đề, thì thứ duy nhất bạn làm là giới hạn kết quả cuối cùng. Phần lớn việc khám phá thực ra chỉ diễn ra sau khi đã bắt đầu viết code
Trong phần mềm, chuyện sản phẩm cuối cùng và thời gian không được định nghĩa rõ ràng cũng không quá quan trọng, vì không có chi phí trên mỗi đơn vị. Các quản lý không có nền tảng kỹ nghệ phần mềm thường không hiểu điều này
Một sản phẩm có tính tổng quát có thể bán cho nhiều khách hàng mà không phát sinh thêm chi phí phát triển
Nhưng vì đa số công ty vận hành như nhà máy, nên mọi quy trình cuối cùng đều tạo ra những sản phẩm rất hạn chế nhắm vào một khách hàng cụ thể. Đó chính là điều các công ty công nghệ lớn đã tránh được
Có vẻ như cả ngành đã chấp nhận mô hình này
Nhưng thành thật mà nói, tôi nghĩ thứ ngăn cản đa số chúng ta lại là thiếu khả năng không làm điều đó. Nếu bạn có thứ muốn xây, đừng lên kế hoạch cho mọi mảnh ghép; cứ làm luôn thứ nhỏ nhất có thể có giá trị
Ví dụ, hãy bắt đầu bằng màn hình “hôm nay” và 4 nút. Hôm nay bạn có thể làm thứ hiển thị 4 nút bài tập để nhấn mỗi ngày. Không cần streak, freeze hay chế độ xem lịch
Tất cả những ý tưởng đó đều hay và rồi cũng sẽ được làm, nhưng trước tiên bạn cần đà tiến. Vài ngày sau bạn thậm chí có thể quyết định rằng mình không thích chế độ xem lịch đó
Với nhiều dự án hơn, cần có kiểu thúc đẩy “cứ làm đi, dù chỉ là một phần nhỏ”. Hoàn thành trong hôm nay, rồi từ điểm đó xem việc tiếp theo là gì. Rất có thể nó sẽ khác với điều đã nghĩ ở giai đoạn lập kế hoạch
Tất nhiên, điều này cũng không dễ. Để tìm ra thứ nhỏ nhất và quyết tâm phát hành mà không bị xao nhãng thì cần suy nghĩ và kỷ luật. Dù vậy, vẫn đáng để rèn luyện
Đây là nguyên tắc rằng khi đối mặt với sự bất định, ta nên tập trung vào “điều đúng đắn cần làm tiếp theo” [0]
Tôi không có ý xem nhẹ việc này. Tìm ra điều đúng đắn cần làm tiếp theo là rất khó, và theo góc nhìn của tôi, đó là phần có giá trị nhất của việc lập kế hoạch
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Ví dụ, một người làm phương pháp so sánh để kiểm thử, một người thử một cách tiếp cận, người khác thử một cách tiếp cận khác, và người thứ ba thử thêm một cách khác nữa, rồi sau một khoảng thời gian định trước thì cùng đánh giá tất cả
Tất nhiên, điều này chỉ có ý nghĩa khi chưa có cách tiếp cận nào được ưu tiên sẵn hoặc chưa có cách nào rõ ràng là vượt trội
Trong quá trình phát triển thực tế, mô-đun hóa có thể là một cách để song song hóa. Chẳng hạn mỗi người hoặc mỗi đội phụ trách một thành phần
Trong công việc của tôi, đặc biệt là khi vẫn đang tìm ra phương hướng, tôi thích luân phiên giữa phần người dùng nhìn thấy và phần kỹ thuật bên trong. Nếu chỉ phát triển kỹ thuật mà chưa biết nó sẽ được dùng thế nào thì cách có thể sử dụng sẽ bị ép theo một hướng nhất định, còn nếu chỉ thiết kế giao diện mà không hiểu công nghệ thì cũng có những cạm bẫy
Nhưng với những việc như nghiên cứu, nơi cần các thử nghiệm sáng tạo và bằng chứng khái niệm để kiểm chứng những điều không thể biết trước, thì chính việc phân rã công việc sẽ sụp đổ
Vì thế tôi hình thành thói quen giữ phần lớn công việc bằng chứng khái niệm ở chế độ không công khai và không nói với ai cả
Nếu thành công thì có thể công bố, còn nếu không thì có thể bỏ đi và bước tiếp mà không phải mất mặt hoặc bị nghe những câu kiểu phải cố làm cho nó chạy bằng được ngay cả sau khi đã xác nhận rằng không nên tiếp tục
Chỉ cần nói “hãy dành 3 giờ để điều tra X, 3 giờ cho Y, 3 giờ cho Z, rồi sau đó họp kế hoạch để quyết định tiếp theo làm gì”
Có bốn kết quả. Hoặc cái đầu tiên giải được, hoặc cái thứ hai giải được, hoặc cái thứ ba giải được, hoặc chẳng cái nào giải được cả
Nếu đó là một vấn đề có thể giải bằng một chút nỗ lực, thì khả năng giải được trong lần thử thứ hai, tức trong 6 giờ, là 50%
Và đến một lúc nào đó thì cứ phải làm thôi
Phân rã công việc và ước lượng gần như là cùng một việc. Khi đã phân rã xong, người có vài năm kinh nghiệm sẽ có các mức ước lượng tiêu chuẩn cho những việc nhỏ, nên chỉ mất vài phút để gắn ước lượng cho từng mảnh
Với tôi, tôi chia công việc thành những khối mà mình có thể ước lượng, còn những phần không thể ước lượng thì tôi hỏi ý kiến người khác
Tuy vậy, tôi không nghĩ con đường thật sự của sự thành thạo là phân rã công việc. Ai cũng có thể tạo ra một bản phân rã tệ
Thành thạo thực sự là nhận ra khi nào bằng chứng cho thấy bản phân rã đó sai đến mức gây vấn đề, và biết cách truyền đạt điều đó hoặc ước lượng lại [0]
Và cũng quan trọng là thoải mái chấp nhận rằng điều đó sẽ xảy ra, để không bị căng thẳng khi ngay từ đầu phải đưa ra một lịch trình có khả năng cao sẽ thay đổi
Các quản lý thường muốn một lộ trình chính xác ngay từ đầu, nhưng đó là đòi hỏi điều không thể. Tôi cho rằng quản lý tốt nằm ở sự linh hoạt, và ở việc hiểu rằng theo thời gian, khi lập trình viên học thêm, bản chất của công việc được dự liệu sẽ thay đổi
Ví dụ nhỏ ở cuối bài cũng đáng suy ngẫm. Dù có ai đó đưa ra một ước lượng chính xác, kiểu như “chỉ cần vài bữa tối trên chuyến bay là xong”, thì có lẽ anh ta vẫn sẽ từ chối vì thấy quá rủi ro
Điều đó cho thấy ước lượng không chỉ là vấn đề về độ chính xác. Ở đây còn có rất nhiều yếu tố khó diễn đạt trọn vẹn bằng những từ như quản lý rủi ro, quản lý kỳ vọng, hay mức độ quen thuộc với công việc
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - cũng có một bài viết về chủ đề này
Họ là những nhân sự phần mềm mới rất tốt, nhưng vì lĩnh vực còn mới nên đôi khi thực sự không biết cách dựng nên các chức năng cơ bản. Theo kinh nghiệm của tôi, họ muốn những công việc mà họ có thể học và làm tốt, và điều đó dẫn tới sự trưởng thành
Điều nhất định phải nhớ là chi phí của quy trình là một phổ liên tục cần được điều chỉnh cho phù hợp với đội ngũ. Các cầu thủ NBA không học cách ném bóng qua chướng ngại trong lúc thi đấu, nhưng học sinh lớp 3 thì có
Cả hai kiểu lập kế hoạch và huấn luyện đều phù hợp khi chúng hợp với từng đội
Có thể đó là sự thật cốt lõi của kỹ nghệ phần mềm. Có lẽ đã tồn tại một phiên bản mã nguồn mở của ứng dụng Streak mà tác giả đang định làm, và đây chỉ là phát minh lại bánh xe
Có vẻ như bộ não không thích danh sách công việc. Lập danh sách có thể đem lại cảm giác vui, nhưng phần lớn khởi nghiệp hay lập trình là khám phá
Và danh sách công việc cản trở sự khám phá
Nếu không, thì điều gì khác biệt ở phát triển phần mềm khiến “tôi không biết” lại là một câu trả lời hợp lý trong nghề của chúng ta?
Có lúc điều đó đúng, nhưng cũng có lúc không. “Bản đồ không phải là lãnh thổ”
Muốn chia công việc thành những phần nhỏ hơn thì phải làm công việc trùng lặp, và mẹo là giảm thiểu điều đó
Nếu cố không làm bất kỳ việc thừa nào, cuối cùng bạn sẽ phải làm mọi thứ cùng một lúc
Ví dụ, giả sử bạn đang tái cấu trúc một chương trình có mô-đun A và B, trong đó B phụ thuộc vào A. Cách ít lãng phí nhất là tái cấu trúc cả hai mô-đun cùng lúc. Nhưng đó cũng là cách rủi ro nhất và khó ước lượng nhất
Cách chia nhỏ là refactor A, rồi điều chỉnh để B hoạt động với A đã được refactor. Sau đó nếu lại refactor A lần nữa thì sẽ có nguy cơ phần điều chỉnh trước đó nhanh chóng bị bỏ đi
Nếu muốn đưa lượng việc bị bỏ đi về 0 thì nhiều khi gần như không thể chia nhỏ công việc. Dù đã có 20 năm kinh nghiệm, tôi vẫn thường ngần ngại khi phải làm những phần việc tạm thời có thể sẽ bị vứt đi để chia nhỏ công việc
Thay vào đó, tôi hay làm những đầu việc kéo dài vài tuần và cạo sạch tất cả “lông yak” còn sót lại
Việc suy nghĩ về vấn đề cần giải quyết trước khi bắt đầu là hợp lý, và các cột mốc đại khái cũng quan trọng. Nhưng phần lớn trường hợp có quá nhiều ẩn số chưa biết nên việc chia nhỏ hoàn toàn либо là vô dụng, либо là bất khả thi
Nếu thời gian dùng để chia tách dự án được dành thẳng cho việc tìm hoặc xây giải pháp thì có lẽ đã xong nhanh hơn nhiều. Ít nhất thì tôi cảm thấy như vậy
Tôi thường tiếp cận khác. Mục đích là ước lượng công sức bỏ vào để quyết định ngay từ đầu xem có nên làm hay không. Nói cách khác, lý do đầu tiên là để hỗ trợ đánh giá chi phí - lợi ích
Điều này cũng có thể rất hữu ích cho cả nhóm. Đặc biệt khi làm việc với những người ít kinh nghiệm hơn, có thể chia nhỏ công việc nhiều hơn và triển khai song song
Có lẽ Jacob cũng không chia nhỏ đến mức đó khi tự triển khai ứng dụng Streak của mình, nên mới đưa ví dụ theo cách đệ quy để giải thích
Khi đó, chia thành các đầu việc nhỏ hơn và hoàn thành từng cái một rất hữu ích. Nhờ vậy, ngay cả khi bị mắc kẹt hoặc không muốn làm, vẫn có tiến triển, và tiến triển đó tạo ra đà để tiếp tục
Việc quản lý có thể ước lượng tốc độ rõ ràng là cũng có giá trị. Chỉ là một khi đã quen với điều đó thì họ sẽ thực sự không còn hiểu được câu “không chắc chắn” nữa, đó mới là vấn đề
Tôi cũng là tư vấn viên, nên dù chúng tôi làm việc “agile” thì việc nói rằng “chúng tôi sẽ bàn giao thứ này trong khoảng thời gian này” vẫn là cực kỳ quan trọng