hoctrokha
Member
Estimate task có lẽ là một phong tục trong ngành phần mềm, nó phổ biến đến mức người ta hỏi về estimate cứ như nó là một thứ hiển nhiên phải có vậy.
Thậm chí người ta còn đặt ra những quả deadline dài cả năm cho estimate từ developer, cái mà chúng ta gọi là milestone.
Vào năm 2012, khi Woody Zuill đưa ra khái niệm #NoEstimate, nó đã kéo theo một ... có thể nói là cuộc cách mạng trong cách nhìn về quy trình phát triển phần mềm.
Đại khái ý tưởng là: Thay vì đưa ra estimate theo kiểu fibonacci: 1, 2, 3, 5, 8 ..., ta chỉ cần đếm số ticket là đủ.
Và khá ngạc nhiên rằng việc đếm số ticket có độ chính xác bằng hoặc thậm chí là hơn cả estimate theo fibonacci.
Tuy nhiên, khi đem ý tưởng này áp dụng vào các dự án khác hoặc chỉ đem ra bàn luận thôi thì có rất rất nhiều ý kiến trái chiều.
Trong bài này mình sẽ không nói nhiều về #NoEstimate, các bạn tự lên youtube, google để tìm hiểu thêm để biết #NoEstimate là gì. (Research là bản năng cần có của dân kỹ thuật rồi, mình ko đưa link, các bạn tự kiếm nhé)
Vậy thay vì giải thích #NoEstimate, mình sẽ nói về thực tế của việc áp dụng #NoEstimate trong các dự án mình đã làm, qua đó cho các bạn một cái nhìn thực tế và cũng trả lời câu hỏi rằng #NE có thực tế không (tất nhiên là theo kinh nghiệm của mình).
Một chút về kinh nghiêm bản thân mình với agile (muốn ghi tí điểm vs các bạn, ko lại bảo ông này kinh nghiệm k có chém vớ vẩn)
Trước khi tốt nghiệp đại học (khoảng 8 năm trước thì phải - tầm 2015 gì đó), mình thấy tò mò về quy trình phát triển phần mềm nên thử tìm hiểu và biết được một thứ tên là scrum. Lúc đó mình chỉ biết mỗi waterfall thôi nên mình thấy đọc được scrum giống như lụm được bí kíp võ công.
Cảm giác như scrum giải quyết được mọi thứ, nó perfect, cảm thấy như được khai sáng vậy.
Nhưng sau vài năm làm (mình bắt đầu làm scrum master cho team mình vào đầu 2018 - đây là công ty thứ 5 mình từng làm) thì càng ngày mình càng thấy có gì đó sai sai với scrum, nhưng lúc đó mình chỉ biết là nó có gì đó sai sai thôi, chứ không biết nó sai chỗ nào, không thể nói rõ ra được. Thành thử mình cũng ậm ờ: "Thì chắc tại mình chưa custom scrum cho phù hợp với team mình, dần dần sẽ improve thêm".
Cuối cùng đến đầu 2021 mình rời công ty, kiếm cơ hội khác. Lúc đó phỏng vấn ở 2 vị trí khác nhau:
- Công ty 1: Scrum Master => khi phỏng vấn mình nói rõ là mình không có certificate, mình chỉ có kinh nghiệm thực tế thôi => Nhận được offer như mong muốn
- Công ty 2: Technical Architect => Phỏng vấn thiên về kỹ thuật hơn => Nhận được offer như mong muốn
Mình chọn công ty 2, tại mình thấy chuyển qua quản lý thuần thì phí khả năng kỹ thuật của mình quá. Với lại mình nghĩ làm tech thì vẫn có cơ hội làm quản lý thuần mà.
Khi vào công ty thứ 2 thì sếp muốn có scrum certificate, thế là bắt mình học.
Sắp xếp vào 1 lớp học với anh em khác trong công ty, học mất đâu đó hơn 1 tháng thì phải.
Trong khoá học mình hỏi khá nhiều câu hỏi trước đây mình cố tìm cách nhưng không trả lời được:
- Làm sao estimate mà không để storypoint liên quan đến thời gian?
- Làm sao estimate bằng TShirt size mà vẫn track được tiến độ?
- Làm sao estimate khi mình còn chưa biết gì về công nghệ đó, hoặc làm một thứ chưa ai từng làm?
- vân vân và mây mây
Học xong mình rút ra một kết luận: "Mình không có lỗi, scrum đúng là có gì đó sai thật". Vấn đề estimate là thứ không ai trong lớp học trả lời cho mình một cách thoả đáng cả. Thế là mình trả lời thẳng với sếp rằng mình k muốn lấy scrum certificate tại vì nó là bull shit.
Ngay sau đó mình tìm hiểu thêm thì biết đến khái niệm #NoEstimate, lúc đó giống kiểu như tìm được bí kíp võ công lần 2, và để học thứ võ công này thì phải phế hết scrum đi. (rất khuyến nghị các bạn tìm hiểu #NoEstimate là gì ngay và luôn).
Giác ngộ: "Scrum không phải là giải pháp, scrum chính là vấn đề".
Khi tỉnh ngộ thì mình mới nhìn thấy được một thế giới mới tươi đẹp và khác hoàn toàn thế giới mình đang sống, thế giới không có estimate còn sếp thì là servant leader ... nói chung là quá đẹp, quá đẹp để thành sự thật.
Mình làm ở Công ty 2 được 6 tháng thì qua Mỹ onsite, hiện mình đang làm lead cho 2 dự án. Trong đó 1 dự án mình chịu trách nhiệm deliver.
#NoEstimate: tranh luận trà đá thôi cũng đã nảy lửa rồi
Thật vậy, khi nói về #NoEstimate với các scrum master khác thì câu truyện thường là:
Mr. Scrum Master 1:
- Ông dở ah, ko estimate thì sao mà họ chi tiền làm?
Me:
- Sao phải biết chi phí làm gì khi mình nhảy vào làm những story có value cao nhất?
Mr. Scrum Master 2:
- Nhưng phải có plan release chứ, làm mà không biết khi nào xong ah?
Me:
- Cần gì phải có plan release khi mình có thể release mỗi 2 tuần và sau đó biết ngay được nó có đem lại giá trị hay không?
Mr. Scrum Master 1:
- Không estimate thì sao biết dev họ lười làm hay không, lỡ task làm nhanh mà họ chây ra thì sao
Me:
- Đó là tổ chức đó đang có vấn đề về sự tin tưởng nội bộ, cái đó tổ chức cần phải cải thiện. Làm pair programming là khỏi lo.
Mr. Scrum Master 2:
- pair programming chỉ làm được trong môi trường lý tưởng, khi 2 dev có cùng trình độ thôi.
Me:
- Đâu ra vậy, tôi pair với junior suốt
Mr. Scrum 1+2: méo tin
Me: cạn lời
Câu truyện thường sẽ kéo dài và các tia lửa bắt đầu nổ lách tách giữa các bên, đến một thời điểm hai bên quyết định dừng lại để uống trà đá tiếp.
Cơ bản rất, rất, rất khó để thể thuyết phục được người khác suy nghĩ theo cách mình suy nghĩ, nhất là khi họ nghĩ "chân lý" của họ được bảo hộ bởi cụm từ "industry standard", "certified" .... vâng, quá khó.
Đem vào thực tế còn khó hơn trăm lần
Khách hàng: Mình cần làm cụm tính năng này, bạn estimate giúp mình xem hết bao nhiêu man month nhé.
Me: Bạn có thể cân nhắc việc không estimate được không, tại vì khả năng estimate bị sai số là rất cao. Lý do bởi đây là giai đoạn chúng ta biết ít nhất về yêu cầu và requirement thậm chí có thể thay đổi bất cứ lúc nào.
Khách hàng: Ừ mình hiểu, nhưng cơ bản là mình mà không đưa ra được estimate thì các sếp trên không cho fund mà làm.
Me: Nhưng cụm tính năng này làm phải mất cả 6 tháng đến 1 năm, estimate vào lúc này cho cả đống thì có khác nào chúng ta đánh bạc với nhau đâu, sai số sẽ rất lớn.
Khách hàng: Mình hiểu, nhưng không sao đâu, mình chỉ cần ước tính sơ sơ đại khái để nói chuyện với cấp trên thôi.
Mình: Haizz, thôi estimate nào. (dành cả mấy tiếng tiếp theo để estimate khoảng chục epic, mỗi epic mình estimate trong đầu xong nhân đôi lên cho an toàn, an toàn cho cả mình lẫn an toàn cho bạn khách hàng, bên cạnh đó mỗi ngày phải estimate cho các ticket trong sprint nữa).
Kết quả là mình deliver được sớm hơn estimate 3 tháng và được khách hàng khen tấm tắc, nhưng mình thấy ... đúng là vớ vẩn thực sự.
Một câu truyện thực tế khác
Khách hàng: Bạn estimate giúp mình xem mình tự build giải pháp multi factor authentication/authorization này thì hết bao nhiêu tháng nhỉ?
Me: Làm sao mình biết được, tại team mình chưa có kinh nghiệm làm nó. Sao cần authen thì ta không mua giải pháp bên thứ 3 giống như auth0 hay okta gì đó cho nhanh mà phải tự build chi vậy bạn?
Khách hàng: Thì đó, mình cũng đã nói chuyện với bên auth0/okta rồi, có báo giá luôn rồi, nên mình cần bạn estimate để so sánh giá sau đó biết là tự build sẽ rẻ hơn hay mua của bên thứ 3 sẽ rẻ hơn. Như vậy mới xin được tiền của sếp chứ.
Me: Nhưng team mình chưa làm bao giờ, làm sao mình cho bạn estimate được, phải nhảy vào research thì mới develop được.
Khách hàng: Thì bạn cứ nói theo kinh nghiệm của bạn thôi ...
Me: (đậu xanh, kinh nghiệm cái ... có đ** đâu mà estimate), thôi hay ta làm quả spike sprint đi được ko bạn?
Khách hàng: ừ thôi cũng được, cứ thử spike trước xem sao
Kết quả: team mình spike từ sprint này qua sprint khác, làm spike mà không có một cái gì là rõ ràng về tương lai cả, không có hứa hẹn, không gì cả. Tụi mình chỉ biết là mình chưa hiểu rõ về cái này, thôi làm luôn về nó cho hiểu. Cần cái gì thì làm thử cái đó, kiểu như vậy.
Sau khi "Spike" nửa cmn năm thì cũng là lúc hoàn thành đc hệ thống authen mới. hoàn toàn k hề có estimate hay j cả. Chỉ biết đến một thời điểm thấy cả hệ thống hoạt động với nhau trơn tru thì mới biết là đã xong rồi.
Sản phẩm có test rất xịn, chất lượng code cao, release không có downtime và "không có lấy 1 bug!". Đến giờ này mình ngồi đây vẫn chưa có 1 bug nào cả.
Lại được khách hàng khen nữa, thâm chí ngay sau lần đó director khách hàng thậm chí muốn tuyển thẳng mình luôn tại cơ bản thấy mình là key member rồi, nhưng sau đó là đợt layoff nên chính director của khách hàng cũng toạch luôn, mình thì vẫn làm ở công ty hiện tại. Buồn.
Nghe hài hước vcl, và mình cũng không tự hào gì cả, cơ bản tại vì lúc đó thực sự mình cũng muốn estimate lắm, nhưng k estimate nổi. Tại có biết vẹo j đâu mà đòi estimate.
Hôm nay viết tới đây thôi, đây là trải nghiệm thực tế của mình. Trong phần tiếp theo mình sẽ nói ra cách làm sao để thực sự áp dụng #NoEstimate vào thực tế và nếu mình gặp lại các case vừa rồi thì mình sẽ làm gì.
Hy vọng sẽ giải quyết được hết các lăn tăn của các scrum master lẫn khách hàng.
Thậm chí người ta còn đặt ra những quả deadline dài cả năm cho estimate từ developer, cái mà chúng ta gọi là milestone.
Vào năm 2012, khi Woody Zuill đưa ra khái niệm #NoEstimate, nó đã kéo theo một ... có thể nói là cuộc cách mạng trong cách nhìn về quy trình phát triển phần mềm.
Đại khái ý tưởng là: Thay vì đưa ra estimate theo kiểu fibonacci: 1, 2, 3, 5, 8 ..., ta chỉ cần đếm số ticket là đủ.
Và khá ngạc nhiên rằng việc đếm số ticket có độ chính xác bằng hoặc thậm chí là hơn cả estimate theo fibonacci.
Tuy nhiên, khi đem ý tưởng này áp dụng vào các dự án khác hoặc chỉ đem ra bàn luận thôi thì có rất rất nhiều ý kiến trái chiều.
Trong bài này mình sẽ không nói nhiều về #NoEstimate, các bạn tự lên youtube, google để tìm hiểu thêm để biết #NoEstimate là gì. (Research là bản năng cần có của dân kỹ thuật rồi, mình ko đưa link, các bạn tự kiếm nhé)
Vậy thay vì giải thích #NoEstimate, mình sẽ nói về thực tế của việc áp dụng #NoEstimate trong các dự án mình đã làm, qua đó cho các bạn một cái nhìn thực tế và cũng trả lời câu hỏi rằng #NE có thực tế không (tất nhiên là theo kinh nghiệm của mình).
Một chút về kinh nghiêm bản thân mình với agile (muốn ghi tí điểm vs các bạn, ko lại bảo ông này kinh nghiệm k có chém vớ vẩn)
Trước khi tốt nghiệp đại học (khoảng 8 năm trước thì phải - tầm 2015 gì đó), mình thấy tò mò về quy trình phát triển phần mềm nên thử tìm hiểu và biết được một thứ tên là scrum. Lúc đó mình chỉ biết mỗi waterfall thôi nên mình thấy đọc được scrum giống như lụm được bí kíp võ công.
Cảm giác như scrum giải quyết được mọi thứ, nó perfect, cảm thấy như được khai sáng vậy.
Nhưng sau vài năm làm (mình bắt đầu làm scrum master cho team mình vào đầu 2018 - đây là công ty thứ 5 mình từng làm) thì càng ngày mình càng thấy có gì đó sai sai với scrum, nhưng lúc đó mình chỉ biết là nó có gì đó sai sai thôi, chứ không biết nó sai chỗ nào, không thể nói rõ ra được. Thành thử mình cũng ậm ờ: "Thì chắc tại mình chưa custom scrum cho phù hợp với team mình, dần dần sẽ improve thêm".
Cuối cùng đến đầu 2021 mình rời công ty, kiếm cơ hội khác. Lúc đó phỏng vấn ở 2 vị trí khác nhau:
- Công ty 1: Scrum Master => khi phỏng vấn mình nói rõ là mình không có certificate, mình chỉ có kinh nghiệm thực tế thôi => Nhận được offer như mong muốn
- Công ty 2: Technical Architect => Phỏng vấn thiên về kỹ thuật hơn => Nhận được offer như mong muốn
Mình chọn công ty 2, tại mình thấy chuyển qua quản lý thuần thì phí khả năng kỹ thuật của mình quá. Với lại mình nghĩ làm tech thì vẫn có cơ hội làm quản lý thuần mà.
Khi vào công ty thứ 2 thì sếp muốn có scrum certificate, thế là bắt mình học.
Sắp xếp vào 1 lớp học với anh em khác trong công ty, học mất đâu đó hơn 1 tháng thì phải.
Trong khoá học mình hỏi khá nhiều câu hỏi trước đây mình cố tìm cách nhưng không trả lời được:
- Làm sao estimate mà không để storypoint liên quan đến thời gian?
- Làm sao estimate bằng TShirt size mà vẫn track được tiến độ?
- Làm sao estimate khi mình còn chưa biết gì về công nghệ đó, hoặc làm một thứ chưa ai từng làm?
- vân vân và mây mây
Học xong mình rút ra một kết luận: "Mình không có lỗi, scrum đúng là có gì đó sai thật". Vấn đề estimate là thứ không ai trong lớp học trả lời cho mình một cách thoả đáng cả. Thế là mình trả lời thẳng với sếp rằng mình k muốn lấy scrum certificate tại vì nó là bull shit.
Ngay sau đó mình tìm hiểu thêm thì biết đến khái niệm #NoEstimate, lúc đó giống kiểu như tìm được bí kíp võ công lần 2, và để học thứ võ công này thì phải phế hết scrum đi. (rất khuyến nghị các bạn tìm hiểu #NoEstimate là gì ngay và luôn).
Giác ngộ: "Scrum không phải là giải pháp, scrum chính là vấn đề".
Khi tỉnh ngộ thì mình mới nhìn thấy được một thế giới mới tươi đẹp và khác hoàn toàn thế giới mình đang sống, thế giới không có estimate còn sếp thì là servant leader ... nói chung là quá đẹp, quá đẹp để thành sự thật.
Mình làm ở Công ty 2 được 6 tháng thì qua Mỹ onsite, hiện mình đang làm lead cho 2 dự án. Trong đó 1 dự án mình chịu trách nhiệm deliver.
#NoEstimate: tranh luận trà đá thôi cũng đã nảy lửa rồi
Thật vậy, khi nói về #NoEstimate với các scrum master khác thì câu truyện thường là:
Mr. Scrum Master 1:
- Ông dở ah, ko estimate thì sao mà họ chi tiền làm?
Me:
- Sao phải biết chi phí làm gì khi mình nhảy vào làm những story có value cao nhất?
Mr. Scrum Master 2:
- Nhưng phải có plan release chứ, làm mà không biết khi nào xong ah?
Me:
- Cần gì phải có plan release khi mình có thể release mỗi 2 tuần và sau đó biết ngay được nó có đem lại giá trị hay không?
Mr. Scrum Master 1:
- Không estimate thì sao biết dev họ lười làm hay không, lỡ task làm nhanh mà họ chây ra thì sao
Me:
- Đó là tổ chức đó đang có vấn đề về sự tin tưởng nội bộ, cái đó tổ chức cần phải cải thiện. Làm pair programming là khỏi lo.
Mr. Scrum Master 2:
- pair programming chỉ làm được trong môi trường lý tưởng, khi 2 dev có cùng trình độ thôi.
Me:
- Đâu ra vậy, tôi pair với junior suốt
Mr. Scrum 1+2: méo tin
Me: cạn lời
Câu truyện thường sẽ kéo dài và các tia lửa bắt đầu nổ lách tách giữa các bên, đến một thời điểm hai bên quyết định dừng lại để uống trà đá tiếp.
Cơ bản rất, rất, rất khó để thể thuyết phục được người khác suy nghĩ theo cách mình suy nghĩ, nhất là khi họ nghĩ "chân lý" của họ được bảo hộ bởi cụm từ "industry standard", "certified" .... vâng, quá khó.
Đem vào thực tế còn khó hơn trăm lần
Khách hàng: Mình cần làm cụm tính năng này, bạn estimate giúp mình xem hết bao nhiêu man month nhé.
Me: Bạn có thể cân nhắc việc không estimate được không, tại vì khả năng estimate bị sai số là rất cao. Lý do bởi đây là giai đoạn chúng ta biết ít nhất về yêu cầu và requirement thậm chí có thể thay đổi bất cứ lúc nào.
Khách hàng: Ừ mình hiểu, nhưng cơ bản là mình mà không đưa ra được estimate thì các sếp trên không cho fund mà làm.
Me: Nhưng cụm tính năng này làm phải mất cả 6 tháng đến 1 năm, estimate vào lúc này cho cả đống thì có khác nào chúng ta đánh bạc với nhau đâu, sai số sẽ rất lớn.
Khách hàng: Mình hiểu, nhưng không sao đâu, mình chỉ cần ước tính sơ sơ đại khái để nói chuyện với cấp trên thôi.
Mình: Haizz, thôi estimate nào. (dành cả mấy tiếng tiếp theo để estimate khoảng chục epic, mỗi epic mình estimate trong đầu xong nhân đôi lên cho an toàn, an toàn cho cả mình lẫn an toàn cho bạn khách hàng, bên cạnh đó mỗi ngày phải estimate cho các ticket trong sprint nữa).
Kết quả là mình deliver được sớm hơn estimate 3 tháng và được khách hàng khen tấm tắc, nhưng mình thấy ... đúng là vớ vẩn thực sự.
Một câu truyện thực tế khác
Khách hàng: Bạn estimate giúp mình xem mình tự build giải pháp multi factor authentication/authorization này thì hết bao nhiêu tháng nhỉ?
Me: Làm sao mình biết được, tại team mình chưa có kinh nghiệm làm nó. Sao cần authen thì ta không mua giải pháp bên thứ 3 giống như auth0 hay okta gì đó cho nhanh mà phải tự build chi vậy bạn?
Khách hàng: Thì đó, mình cũng đã nói chuyện với bên auth0/okta rồi, có báo giá luôn rồi, nên mình cần bạn estimate để so sánh giá sau đó biết là tự build sẽ rẻ hơn hay mua của bên thứ 3 sẽ rẻ hơn. Như vậy mới xin được tiền của sếp chứ.
Me: Nhưng team mình chưa làm bao giờ, làm sao mình cho bạn estimate được, phải nhảy vào research thì mới develop được.
Khách hàng: Thì bạn cứ nói theo kinh nghiệm của bạn thôi ...
Me: (đậu xanh, kinh nghiệm cái ... có đ** đâu mà estimate), thôi hay ta làm quả spike sprint đi được ko bạn?
Khách hàng: ừ thôi cũng được, cứ thử spike trước xem sao
Kết quả: team mình spike từ sprint này qua sprint khác, làm spike mà không có một cái gì là rõ ràng về tương lai cả, không có hứa hẹn, không gì cả. Tụi mình chỉ biết là mình chưa hiểu rõ về cái này, thôi làm luôn về nó cho hiểu. Cần cái gì thì làm thử cái đó, kiểu như vậy.
Sau khi "Spike" nửa cmn năm thì cũng là lúc hoàn thành đc hệ thống authen mới. hoàn toàn k hề có estimate hay j cả. Chỉ biết đến một thời điểm thấy cả hệ thống hoạt động với nhau trơn tru thì mới biết là đã xong rồi.
Sản phẩm có test rất xịn, chất lượng code cao, release không có downtime và "không có lấy 1 bug!". Đến giờ này mình ngồi đây vẫn chưa có 1 bug nào cả.
Lại được khách hàng khen nữa, thâm chí ngay sau lần đó director khách hàng thậm chí muốn tuyển thẳng mình luôn tại cơ bản thấy mình là key member rồi, nhưng sau đó là đợt layoff nên chính director của khách hàng cũng toạch luôn, mình thì vẫn làm ở công ty hiện tại. Buồn.
Nghe hài hước vcl, và mình cũng không tự hào gì cả, cơ bản tại vì lúc đó thực sự mình cũng muốn estimate lắm, nhưng k estimate nổi. Tại có biết vẹo j đâu mà đòi estimate.
Hôm nay viết tới đây thôi, đây là trải nghiệm thực tế của mình. Trong phần tiếp theo mình sẽ nói ra cách làm sao để thực sự áp dụng #NoEstimate vào thực tế và nếu mình gặp lại các case vừa rồi thì mình sẽ làm gì.
Hy vọng sẽ giải quyết được hết các lăn tăn của các scrum master lẫn khách hàng.
Last edited:
sẵn cuối tuần phần kế luôn nha bác
.
