thảo luận scrum - lợi hay hại

L.V.Gaal đã nói:

Có khi các thím hiểu nhầm ý mình. Agile in name là nói kháy các bên chỉ có mỗi cái mác Agile, còn lại làm waterfall, hoặc thậm chí éo có framework gì luôn.

Nhấp để mở rộng...

nói chung ng ta hay khoe những gì mình k có mà

Khang.Hy.Gia.222 đã nói:

có luôn à? cty mình là outsource, thấy cũng làm task như bình thường cơ

Nhấp để mở rộng...

ak đấy là tùy theo từng cty , nhưng cơ bản theo đúng qui trình thì khi đến tqay dev thì chỉ còn là công đoạn coding . Mọi công đoạn trước phải được appove và phải hạn chế tối đa chuyện xen ngang task khác vào .

jona_ma đã nói:

Mấy cái vụ lương lẹo này mình nghĩ cty phải có cách đánh giá và review performance thường xuyên để cải thiện chứ nhỉ

Nhấp để mở rộng...

thì có đánh giá , có review , chấm điểm 1/10 , gọi vào nói chuyện , nhưng có những nhân sự cứ ì ra đợi cty đuổi thì lên kiện đến đòi 2 tháng lương bác ạ . có cái bug , ET 2 ngày , sau 2 ngày báo ET sai , ET lại thêm 3 ngày . Trong khi ku junior vào fix hết 30p . Đó , team cạnh em gặp tình trạng đó , còn team em thì em dí luôn ET , sau đó buffer ra , scrum nửa mùa nhưng team chạy hết công suất đc , nhược điểm là nhiều anh em bất mãn vì phải làm nhiều , trong khi team bên cạnh thì thái cực quyền .

Vuanhhuy93 đã nói:

ak đấy là tùy theo từng cty , nhưng cơ bản theo đúng qui trình thì khi đến tqay dev thì chỉ còn là công đoạn coding . Mọi công đoạn trước phải được appove và phải hạn chế tối đa chuyện xen ngang task khác vào .

Nhấp để mở rộng...

mình nghĩ cái đó mới là đặc trưng waterfall cơ

Vuanhhuy93 đã nói:

thì có đánh giá , có review , chấm điểm 1/10 , gọi vào nói chuyện , nhưng có những nhân sự cứ ì ra đợi cty đuổi thì lên kiện đến đòi 2 tháng lương bác ạ . có cái bug , ET 2 ngày , sau 2 ngày báo ET sai , ET lại thêm 3 ngày . Trong khi ku junior vào fix hết 30p . Đó , team cạnh em gặp tình trạng đó , còn team em thì em dí luôn ET , sau đó buffer ra , scrum nửa mùa nhưng team chạy hết công suất đc , nhược điểm là nhiều anh em bất mãn vì phải làm nhiều , trong khi team bên cạnh thì thái cực quyền .

Nhấp để mở rộng...

Hix chã bù cty em là cty Nhật, toàn làm waterfall lính có được estimate đâu.
Dự án toàn estimate theo budget, rồi manager với lead đẻ dí task, mà đa số là bị ép chứ k phải estimate hợp lý, ví dụ task làm 8h xong thì toàn deadline phải xong trong 4h, làm ko kịp thì tự OT do năng lực kém nhé chứ k đc approve.

jona_ma đã nói:

Hix chã bù cty em là cty Nhật, toàn làm waterfall lính có được estimate đâu.
Dự án toàn estimate theo budget, rồi manager với lead đẻ dí task, mà đa số là bị ép chứ k phải estimate hợp lý, ví dụ task làm 8h xong thì toàn deadline phải xong trong 4h, làm ko kịp thì tự OT do năng lực kém nhé chứ k đc approve.

Nhấp để mở rộng...

chứ bộ scrum a được tự do chắc. a bảo 8h xong thì phải giải thích lý do, mà cả team nhiều người bảo 4h thì phải theo 4h nhé

Khang.Hy.Gia.222 đã nói:

chứ bộ scrum a được tự do chắc. a bảo 8h xong thì phải giải thích lý do, mà cả team nhiều người bảo 4h thì phải theo 4h nhé

Nhấp để mở rộng...

Cả team bảo 4h thì chịu rồi thím, còn case của em thì ở trên estimate ntn thì cấm có cãi.
Đúng là mỗi quy trình nó có cái hay dở riêng, như quy trình cty em thì bị ở trên lợi dụng bóc lột vkl ra.

k biết scrum chuẩn ntn, chứ thấy làm scrum mà có spec rõ ràng nó mơ hồ vl. quăng cho cái task, cái gì cũng contact PO để làm rõ, k biết lợi ntn chứ mệt vcl, thà thảy cái spec 10 trang cụ thể thích hơn

jona_ma đã nói:

Hix chã bù cty em là cty Nhật, toàn làm waterfall lính có được estimate đâu.
Dự án toàn estimate theo budget, rồi manager với lead đẻ dí task, mà đa số là bị ép chứ k phải estimate hợp lý, ví dụ task làm 8h xong thì toàn deadline phải xong trong 4h, làm ko kịp thì tự OT do năng lực kém nhé chứ k đc approve.

Nhấp để mở rộng...

Đứng lên chửi thề rồi đi về kiếm cty khác thôi chứ đâu ra 8h bắt estimate 4h rồi ot thêm 4h cho kịp.
Mạnh mẽ lên, ngoài kia vẫn còn nhiều cty tốt lắm.

Khang.Hy.Gia.222 đã nói:

chứ bộ scrum a được tự do chắc. a bảo 8h xong thì phải giải thích lý do, mà cả team nhiều người bảo 4h thì phải theo 4h nhé

Nhấp để mở rộng...

Cả team bảo 4h, mình nói 8h, thì giờ phải thuyết phục nhau là cái nào hợp lý chứ làm gì có chuyện là phải chọn 4h. Xong thường sẽ chọn con số khoảng 6h.

Thêm nữa nếu đúng là cái đó 4h thì mình vẫn có quyền nói do tao làm cái này không quen như mọi người nên tao cần thêm 4h tìm hiểu, nếu assign task này cho tao thì phải là 8h. Chứ đâu phải sẽ ép luôn là phải 4h (tất nhiên không thể task nào cũng tìm hiểu)

Gửi từ Samsung SM-N985F bằng vozFApp

Do tổ chức của bạn là chính chứ không phải do scrum đâu. Chắc chắn do có khâu nào làm không tốt rồi đổ lên đầu bạn. Chứ Scrum/Agile đâu phải là thích đổ việc lên đầu ai cũng được!?

Kurisu Makise đã nói:

Do tổ chức của bạn là chính chứ không phải do scrum đâu. Chắc chắn do có khâu nào làm không tốt rồi đổ lên đầu bạn. Chứ Scrum/Agile đâu phải là thích đổ việc lên đầu ai cũng được!?

Nhấp để mở rộng...

? đang bàn là nó có ích cho dev như quảng cáo k mà

dạo một vòng comment ở đây thấy nhiều ông gặp agile-but hoặc scrum-but nhưng lại quay sang chửi agile với scrum. Tôi cũng chẳng dám nhận là nhiều kinh nghiệm agile, nhưng tôi thấy có mấy điểm cần làm rõ như sau:

1. Agile không phải là một phương pháp hay một process. Agile là methodology/mindset, và scrum chỉ là một framework build dựa trên các manifesto của agile.

2. Agile nói chung và scrum nói riêng KHÔNG HỀ DỄ APPLY. Hay nói trắng ra là CỰC KỲ KHÓ, đòi hỏi member của team, từ SM, PO, Dev teams phải đủ mature để có thể apply chuẩn chỉ.

3. Agile không phải toàn năng. Không phải cứ project nào apply agile vào cũng là tốt nhất.

4. Nếu đã tự nhận là agile team thì PHẢI tôn trọng các core value + 12 principles của agile. Và SM phải là người dám đứng lên protect development team from outside influences + impediment và đủ mature để guide/train cho các stake holder khác về Agile.

5. Có một ông nào đó có comment là Agile chỉ quan tâm đến working software và ko quan tâm đến quality, tôi xin khẳng định đây là mindset Agile cực kỳ sai lệch. Agile cực kỳ quan tâm đến quality, nếu ô nào đã đi học về agile sẽ biết là agile rất khuyến khích việc giảm feedback loop, thông qua các practice như pair programming, TDD + Unit Test,...
Và Agile quan niệm rằng các technical debt phải được phát hiện và pay off càng sớm càng tốt.
Cũng chính ông comment bên trên nói rằng Agile quan trọng do right things hơn là do things right, đây là một sự đánh tráo khái niệm. Vì sao: xin mời xem principle số 9 và 10 của Agile:

9: Continuous attention to technical excellence and good design enhances agility.
-> và xin mời xem định nghĩa của từ Technical Excellence:

Technical Excellence is the ability to foresee and eliminate an issue before it has the potential to jeopardize safety, schedule, budget, quality, and most importantly, client satisfaction.

Nhấp để mở rộng...

10: Simplicity–the art of maximizing the amount of work not done–is essential.

Nhấp để mở rộng...

Xin hãy chú ý phần in nghiêng trong câu trên. Dịch ra tiếng việt nó có nghĩa là: tối đa hoá lượng việc KHÔNG làm. Nghe hơi ngược đời phải ko, nhưng không hề đâu, và làm sáng tỏ được cái này thì sẽ sáng tỏ được cái gọi là "right things" và "things right"

principle số 10 có nghĩa là cả cái Agile team đó phải làm sao để LOẠI BỎ càng nhiều càng tốt những thứ DƯ THỪA, không mang lại value cho product, cho team, và phải dám nhìn nhận nó là một điều cần thiết, tức là bạn phải hiểu cái business, phải tự đặt mình vào vị trí người dùng để nhìn nhận xem, cái thứ mà stake holder/PO nó đang đòi hỏi này, có thực sự valid/cần thiết hay không ? Hay nó là một thứ fancy vẽ rắn thêm chân mà mấy thằng dở hơi đấy hứng lên nghĩ ra ? Và nếu bạn cho rằng nó ko cần thiết, bạn phải dám lên tiếng "bỏ nó đi" -> do right things

và khi mà đã xác định được cái gì là right things rồi thì các bạn mới có thể dành tâm huyết, dành công sức, thời gian "do things right" được chứ. Vì thế nên nó là quan hệ trước - sau chứ ko phải là cái nào quan trọng hơn cái nào đâu nhé.

Khang.Hy.Gia.222 đã nói:

? đang bàn là nó có ích cho dev như quảng cáo k mà

Nhấp để mở rộng...

Rất có ích, nhưng chỉ khi tổ chức của ông tôn trọng các core value + principle của agile.

Xin đừng đem mấy cái agile-but, scrum-but nửa mùa ra làm dẫn chứng nói agile nó lởm, nó tệ hại, nó làm dev phải OT này kia... Vì ngay trong principle của nó đã nói rõ rồi SUSTAINABLE PACE

scrum là thất bại của tạo hoá, ngay từ lý thuyết ban đầu của nó đã làm cho team có tận 2 weak points rồi. PO và SM, tôi nghĩ chất lượng nhân sự của 2 vị trí này chiếm tới 90% thành công của 1 dự án scrum.

thang1812 đã nói:

dạo một vòng comment ở đây thấy nhiều ông gặp agile-but hoặc scrum-but nhưng lại quay sang chửi agile với scrum. Tôi cũng chẳng dám nhận là nhiều kinh nghiệm agile, nhưng tôi thấy có mấy điểm cần làm rõ như sau:

1. Agile không phải là một phương pháp hay một process. Agile là methodology/mindset, và scrum chỉ là một framework build dựa trên các manifesto của agile.

2. Agile nói chung và scrum nói riêng KHÔNG HỀ DỄ APPLY. Hay nói trắng ra là CỰC KỲ KHÓ, đòi hỏi member của team, từ SM, PO, Dev teams phải đủ mature để có thể apply chuẩn chỉ.

3. Agile không phải toàn năng. Không phải cứ project nào apply agile vào cũng là tốt nhất.

4. Nếu đã tự nhận là agile team thì PHẢI tôn trọng các core value + 12 principles của agile. Và SM phải là người dám đứng lên protect development team from outside influences + impediment và đủ mature để guide/train cho các stake holder khác về Agile.

5. Có một ông nào đó có comment là Agile chỉ quan tâm đến working software và ko quan tâm đến quality, tôi xin khẳng định đây là mindset Agile cực kỳ sai lệch. Agile cực kỳ quan tâm đến quality, nếu ô nào đã đi học về agile sẽ biết là agile rất khuyến khích việc giảm feedback loop, thông qua các practice như pair programming, TDD + Unit Test,...
Và Agile quan niệm rằng các technical debt phải được phát hiện và pay off càng sớm càng tốt.
Cũng chính ông comment bên trên nói rằng Agile quan trọng do right things hơn là do things right, đây là một sự đánh tráo khái niệm. Vì sao: xin mời xem principle số 9 và 10 của Agile:





Xin hãy chú ý phần in nghiêng trong câu trên. Dịch ra tiếng việt nó có nghĩa là: tối đa hoá lượng việc KHÔNG làm. Nghe hơi ngược đời phải ko, nhưng không hề đâu, và làm sáng tỏ được cái này thì sẽ sáng tỏ được cái gọi là "right things" và "things right"

principle số 10 có nghĩa là cả cái Agile team đó phải làm sao để LOẠI BỎ càng nhiều càng tốt những thứ DƯ THỪA, không mang lại value cho product, cho team, và phải dám nhìn nhận nó là một điều cần thiết, tức là bạn phải hiểu cái business, phải tự đặt mình vào vị trí người dùng để nhìn nhận xem, cái thứ mà stake holder/PO nó đang đòi hỏi này, có thực sự valid/cần thiết hay không ? Hay nó là một thứ fancy vẽ rắn thêm chân mà mấy thằng dở hơi đấy hứng lên nghĩ ra ? Và nếu bạn cho rằng nó ko cần thiết, bạn phải dám lên tiếng "bỏ nó đi" -> do right things

và khi mà đã xác định được cái gì là right things rồi thì các bạn mới có thể dành tâm huyết, dành công sức, thời gian "do things right" được chứ. Vì thế nên nó là quan hệ trước - sau chứ ko phải là cái nào quan trọng hơn cái nào đâu nhé.

Nhấp để mở rộng...

no no, đừng wall of text đây. xin bám vào câu hỏi làm ơn.
bàn scrum thì là phải gắn vào thực tiễn. lấy lý thuyết ra chứng minh được j. nếu ông thấy nó có lợi cho dev. ok trình bày. nếu nó k có lợi. ok chửi. chứ a nói tràn giang đại hải chứng tỏ cái gì? lý thuyết cần thì trên mạng nói cả đống r

Yurisha đã nói:

scrum là thất bại của tạo hoá, ngay từ lý thuyết ban đầu của nó đã làm cho team có tận 2 weak points rồi. PO và SM, tôi nghĩ chất lượng nhân sự của 2 vị trí này chiếm tới 90% thành công của 1 dự án scrum.

Nhấp để mở rộng...

chứ gì nữa. thấy SM y như 1 team leader mặc dù éo dc công nhận

Khang.Hy.Gia.222 đã nói:

no no, đừng wall of text đây. xin bám vào câu hỏi làm ơn.
bàn scrum thì là phải gắn vào thực tiễn. lấy lý thuyết ra chứng minh được j. nếu ông thấy nó có lợi cho dev. ok trình bày. nếu nó k có lợi. ok chửi. chứ a nói tràn giang đại hải chứng tỏ cái gì? lý thuyết cần thì trên mạng nói cả đống r

Nhấp để mở rộng...

cho những dev như ông, thích ngắn, đọc doc rồi implement không cần phải communicate nhiều thì agile CÓ HẠI.

vì Agile nó đòi hỏi phải có service mindset/product mindset, còn tôi thấy ông thích hợp outsource hơn.

thang1812 đã nói:

cho những dev như ông, thích ngắn, đọc doc rồi implement không cần phải communicate nhiều thì agile CÓ HẠI.

vì Agile nó đòi hỏi phải có service mindset/product mindset, còn tôi thấy ông thích hợp outsource hơn.

Nhấp để mở rộng...

theo a comunicate nhiều và k doc với việc có doc cái nào lợi?

mà chưa thấy dc anh nói có lợi ở chỗ nào? ở chỗ dc comunicate là có lợi hay gì?

thang1812 đã nói:

cho những dev như ông, thích ngắn, đọc doc rồi implement không cần phải communicate nhiều thì agile CÓ HẠI.

vì Agile nó đòi hỏi phải có service mindset/product mindset, còn tôi thấy ông thích hợp outsource hơn.

Nhấp để mở rộng...

Tôi cũng hóng xem đại hiệp trả lời Agile/Scrum cho dev lợi ích gì mà mãi chưa thấy?

Đúng là Agile/Scrum toàn sách vở lý thuyết với cả khoá học. Chứ wall of text xong ngta hỏi lợi ích gì thì lảng.

Khang.Hy.Gia.222 đã nói:

theo a comunicate nhiều và k doc với việc có doc cái nào lợi?

mà chưa thấy dc anh nói có lợi ở chỗ nào? ở chỗ dc comunicate là có lợi hay gì?

Nhấp để mở rộng...

lợi là a có kn làm việc ở scrum team, và để đi pv những chỗ nó đang làm scrum, lương tăng 40%

lợi 2, là a làm việc theo 1 team, mọi vấn đề là vấn đề của team, ko phải của riêng cá nhân. nó dẹp cái tôi của thằng team lead, và giúp đỡ thằng newbie

nhiều dự án chỉ có communicate bằng mồm, hoặc vài cái test case, ko cần spec, nhìn là hiểu ngay. và nó có hàng trăm issue, thay đổi liên tọi. agile scrum chỉ phù hợp với dự án kiểu này

đa phần các dự án cntt là phải có spec và communicate bằng văn bản giữa các bên liên quan. scrum ko làm dc kiểu dự án này.