pipoi qwewe
Member
Em tưởng đầu tháng đi làm cuối tháng lãnh lương. Giờ lại phải fill timesheet là sao bác.
thảo luận scrum - lợi hay hại
- Người tạo chủ đề Khang.Hy.Gia.222
- Ngày bắt đầu
Khang.Hy.Gia.222
Member
thường là lm outsource cho thằng khác. nộp timesheet cho nó trả tiền hợp đồng cho cty.
thachit123
Member
Đợt tôi là cuối ngày sẽ log lại làm task gì, bao nhiêu tiếng. Tính tổng lại rồi công ty bên kia sẽ trả tiền cho bên này dựa trên số tiếng đã làm.
Làm kiểu này dù ít task vẫn áp lực lắm thím, làm sao log đủ một ngày 8 tiếng thì ok
snake_case
Senior Member
không biết lớn như google có theo scrum không mấy bác nhỉ?
lucius1605
Senior Member
Vào đây thấy nhiều thím không hiểu về agile/scrum quá 
Để giải thích chi tiết và dẫn chứng đầy đủ thì phải viết cả bài dài ngoằng, bác nào muốn tìm hiểu về mấy cái này thì lên medium rồi follow mấy topic liên qua mà đọc. Xem người ta chê gì, khen gì, quan điểm, rồi đọc comment sẽ học hỏi được khá nhiều về mindset. Kết hợp với quan sát thực tế khi làm việc thì mới ngộ ra được.
Còn về cơ bản thì đúng là agile nó không focus vào lợi ích cho dev rồi, nó focus vào working software. Nhưng đừng đánh đồng working software với product quality. Các bác để ý sẽ thấy agile không nhắc gì tới quality cả, nó chỉ focus vào working software thôi. Ngay cả các team theo đuổi agile cũng đều ưu tiên kiểm soát time-cost-scope, ưu tiên build the right thing hơn là build the thing right. Khá là hiển nhiên vì agile ra đời trong bối cảnh software product cứ làm ra là fail (không bug thì cũng không phù hợp thực tế nên không work).
Như vậy lợi ích của dev nhiều hay ít thì phụ thuộc vào công ty cân bằng lại lợi ích thế nào thôi. Vì cơ bản các môi trường theo agile sẽ đòi hỏi ownership cao hơn, nhưng điều đó không có nghĩa là waterfall không cần hay waterfall thì không vất vả. Vất vả hay không thì do leader hoặc manager. Như công ty tôi cũng scrum (không hoàn toàn do đặc thù ngữ cảnh) nhưng đợt nào làm căng chút thì sẽ tìm cách cho member relax bằng cách giao task dễ đi hoặc gần cuối ngày thì cho nghỉ sớm.
p/s: nếu các bác tìm hiểu về agile thì sẽ thấy hiện nay có rất nhiều nơi chỉ ra những yếu điểm của agile nhưng cũng có nhưng tổ chức nói rằng nhờ agile mà họ thành công. Nhưng có một đặc điểm chung là cùng agile, cùng scrum nhưng thầng nào apply cũng custom một tí hoặc nhiều tí
nên khi đọc thì nhớ là chỉ tham khảo thôi.
Để giải thích chi tiết và dẫn chứng đầy đủ thì phải viết cả bài dài ngoằng, bác nào muốn tìm hiểu về mấy cái này thì lên medium rồi follow mấy topic liên qua mà đọc. Xem người ta chê gì, khen gì, quan điểm, rồi đọc comment sẽ học hỏi được khá nhiều về mindset. Kết hợp với quan sát thực tế khi làm việc thì mới ngộ ra được.
Còn về cơ bản thì đúng là agile nó không focus vào lợi ích cho dev rồi, nó focus vào working software. Nhưng đừng đánh đồng working software với product quality. Các bác để ý sẽ thấy agile không nhắc gì tới quality cả, nó chỉ focus vào working software thôi. Ngay cả các team theo đuổi agile cũng đều ưu tiên kiểm soát time-cost-scope, ưu tiên build the right thing hơn là build the thing right. Khá là hiển nhiên vì agile ra đời trong bối cảnh software product cứ làm ra là fail (không bug thì cũng không phù hợp thực tế nên không work).
Như vậy lợi ích của dev nhiều hay ít thì phụ thuộc vào công ty cân bằng lại lợi ích thế nào thôi. Vì cơ bản các môi trường theo agile sẽ đòi hỏi ownership cao hơn, nhưng điều đó không có nghĩa là waterfall không cần hay waterfall thì không vất vả. Vất vả hay không thì do leader hoặc manager. Như công ty tôi cũng scrum (không hoàn toàn do đặc thù ngữ cảnh) nhưng đợt nào làm căng chút thì sẽ tìm cách cho member relax bằng cách giao task dễ đi hoặc gần cuối ngày thì cho nghỉ sớm.
p/s: nếu các bác tìm hiểu về agile thì sẽ thấy hiện nay có rất nhiều nơi chỉ ra những yếu điểm của agile nhưng cũng có nhưng tổ chức nói rằng nhờ agile mà họ thành công. Nhưng có một đặc điểm chung là cùng agile, cùng scrum nhưng thầng nào apply cũng custom một tí hoặc nhiều tí
nên khi đọc thì nhớ là chỉ tham khảo thôi.
Sửa lần cuối:
Still Waiting....
Đã tốn tiền
Cũng đang làm cty như vậy, d có task cũng phải giục pm, leader giao task cho mình k cuối ngày d có gì mà khai. Ngồi chơi cũng áp lực. Đang làm cty thoải mái giờ giấc sang cty quản lý chặt oải vãi. Cứ hết việc là bị điều qua support các con khác để có task log.
via theNEXTvoz for iPhone
thachit123
Member
Trước tui làm công ty vậy, task ít cực kỳ nhưng thấy áp lực lắm, thế là tui phắn
znvdicrd
Senior Member
Agile ngon hay không chưa biết nhưng sợ nhất là các ông mượn tên agile.
Số 1 là đội đi tư vấn, coaching, dạy chứng chỉ. Agile hay lắm, ngon lắm các công ty lớn đều làm nên công ty các chú làm đi. Các chú làm rồi mà chưa ngon thì phải tham gia khóa training A, B, C mà tình cờ công ty anh đang mở. Các chú học xong, chứng chỉ treo đầy trước ngực rồi mà công ty làm vẫn không ra gì thì phải mời các anh vào coaching Với các anh này thì dự án thành công là nhờ Agile và các anh, còn dự án lụt thì do các chú áp dụng agile chưa chuẩn ... Dự án cũ của tôi nghe đâu chủ dự án ở bển cúng cho các anh coacher/trainer gần nửa củ biden, may đến lúc ông chủ tịch thấy tình hình không ổn mới sút hết.
Số 2 là các anh sếp, PM, lead ... áp dụng agile kiểu tiêu chuẩn kép - nguyên tắc nào dễ cho anh thì anh làm, còn khó thì đẩy cho bọn ở dưới. VD như lúc deadline dí thì các anh không đi lo sửa scope mà lại làm theo kiểu waterfall, nghĩa là bọn ở dưới è cổ ra chạy cho đúng hạn. Đến lúc chúng nó nhỡ tay làm xong task sớm quá thì lúc này phải làm theo đúng agile là các anh bắt chúng nó nhặt task ở backlog lên y như ông OP ý kiến. Túm lại sustainable pace chỉ là cho vui
Gặp 2 mẫu đối tượng này thì các ông vắt giò lên mà chạy cho sớm.
Số 1 là đội đi tư vấn, coaching, dạy chứng chỉ. Agile hay lắm, ngon lắm các công ty lớn đều làm nên công ty các chú làm đi. Các chú làm rồi mà chưa ngon thì phải tham gia khóa training A, B, C mà tình cờ công ty anh đang mở. Các chú học xong, chứng chỉ treo đầy trước ngực rồi mà công ty làm vẫn không ra gì thì phải mời các anh vào coaching
Với các anh này thì dự án thành công là nhờ Agile và các anh, còn dự án lụt thì do các chú áp dụng agile chưa chuẩn ... Dự án cũ của tôi nghe đâu chủ dự án ở bển cúng cho các anh coacher/trainer gần nửa củ biden, may đến lúc ông chủ tịch thấy tình hình không ổn mới sút hết.Số 2 là các anh sếp, PM, lead ... áp dụng agile kiểu tiêu chuẩn kép - nguyên tắc nào dễ cho anh thì anh làm, còn khó thì đẩy cho bọn ở dưới. VD như lúc deadline dí thì các anh không đi lo sửa scope mà lại làm theo kiểu waterfall, nghĩa là bọn ở dưới è cổ ra chạy cho đúng hạn. Đến lúc chúng nó nhỡ tay làm xong task sớm quá thì lúc này phải làm theo đúng agile là các anh bắt chúng nó nhặt task ở backlog lên y như ông OP ý kiến. Túm lại sustainable pace chỉ là cho vui
Gặp 2 mẫu đối tượng này thì các ông vắt giò lên mà chạy cho sớm.
Love U So Much
Senior Member
trước tôi làm cty đang muốn apply agile scrum ra toàn công ty, bên cntt thì ko nói làm gì
nhưng sếp cntt qua các khối khác training, nói động chạm vào 1 chị, bị chị chửi cho
tất cả các sếp cứng đầu đều bài xích scrum. động vào họ, là họ chơi lại ngay
//tôi training dc do tôi thích uống rượu và thích làm việc với người thông minh hơn mình, người ta quý. nhưng thằng sếp tôi nó ko rượu lại tinh tướng, sếp to trong cty ko ai thích nó cả. mà tôi đi training thì lại vượt quyền thằng sếp, nên cũng ko làm dc
nhưng sếp cntt qua các khối khác training, nói động chạm vào 1 chị, bị chị chửi cho
tất cả các sếp cứng đầu đều bài xích scrum. động vào họ, là họ chơi lại ngay
//tôi training dc do tôi thích uống rượu và thích làm việc với người thông minh hơn mình, người ta quý. nhưng thằng sếp tôi nó ko rượu lại tinh tướng, sếp to trong cty ko ai thích nó cả. mà tôi đi training thì lại vượt quyền thằng sếp, nên cũng ko làm dc
thachit123
Member
Nó nói gì chị mà chị chửi thếtrước tôi làm cty đang muốn apply agile scrum ra toàn công ty, bên cntt thì ko nói làm gì
nhưng sếp cntt qua các khối khác training, nói động chạm vào 1 chị, bị chị chửi cho
tất cả các sếp cứng đầu đều bài xích scrum. động vào họ, là họ chơi lại ngay
//tôi training dc do tôi thích uống rượu và thích làm việc với người thông minh hơn mình, người ta quý. nhưng thằng sếp tôi nó ko rượu lại tinh tướng, sếp to trong cty ko ai thích nó cả. mà tôi đi training thì lại vượt quyền thằng sếp, nên cũng ko làm dc
Love U So Much
Senior Member
dẫn chị đi vòng tròn, chơi trò team work, chị đã rồ lên rồiNó nói gì chị mà chị chửi thế
sau đó nó giả thiết trong 1 tình huống là chị bị sai
, chị bực lên chị bảo cả đời tao chưa sai cái gì hết, ko giả thiết, cứ thực tế mà làm. chị còn dạy ngược, mà nói thấm lắm, bọn em chỉ biết cười trừcơ bản là kỹ năng mềm bên em quá kém so với chị, nên ko nói được
kỹ năng ngôn ngữ thì cứ rao dạy về PO
là 1 user xxy, tôi muốn cái này, cái kia... bên khác nó quan tâm éo gì. bọn em thấy ko có câu thần chú là user xxy thì ko nhận việc , sau đấy thì ko còn sau đấy nữa, sếp ngồi cố dc 2 năm nữa thì chán nên đi, bọn e cũng đi lâu rồi
Khang.Hy.Gia.222
Member
mà scrum vào phòng ban khác đéo hiểu để làm gì nhỉ? thấy k có tác dụng mấydẫn chị đi vòng tròn, chơi trò team work, chị đã rồ lên rồi
sau đó nó giả thiết trong 1 tình huống là chị bị sai
cơ bản là kỹ năng mềm bên em quá kém so với chị, nên ko nói được
kỹ năng ngôn ngữ thì cứ rao dạy về POlà 1 user xxy, tôi muốn cái này, cái kia...bên khác nó quan tâm éo gì. bọn em thấy ko có câu thần chú là user xxy thì ko nhận việc
Love U So Much
Senior Member
thì phét lên tận chủ tịch là em thay đổi cả cái tổ chức này
im mẹ nó mồm đi thì ko, cứ thích láo với người sắc xảo
nếu sếp tôi hồi đấy cứ điều PO đi làm, lúc nào thành công thì bảo đấy là agile scrum, thì may ra dc. đây lại phang scrum ngay từ đầu vào mặt các sếp khác. mà bắt các sếp kia thay đổi cả lời ăn tiếng nói nữa. toàn các sếp chơi solo, coi lính như chó, làm gì có team work với thảo luận mà agile
Khang.Hy.Gia.222
Member
có mỗi IT mới có team work, chứ mấy cái khác như sản xuất, kd, nhân sự toàn là mệnh lệnh thui
Vuanhhuy93
Senior Member
Lợi thì có lợi , nhưng còn xem team như thế nào , build được một team scrum chuẩn khó lắm , yc về trình độ , sự hiểu biết về dự án , tinh thần, thái độ , process làm việc . Như team mình , có nhưng member thái độ khá kém , áp scrum dân chủ thì chắc bạn ý ngồi chơi dài và lí do là đang tìm hiểu, ET việc đáng lẽ làm 1 ngày ra 1 tuần . Cuối cùng thì vẫn cần mình nhảy vào ép ET dí task thì công việc mới trôi được .
Khang.Hy.Gia.222
Member
à topic này k bàn vấn đề lớn lao đến thế ạ, e chỉ bàn lợi cho dev thui.
bác chia sẻ vài cái lợi xem được k ạ?
Vuanhhuy93
Senior Member
làm việc đúng qui trình , ET rõ ràng , hiểu rõ thì ET , ko hiểu thì yêu cầu support , tài liệu đầy đủ , nếu áp thêm qui trình chuẩn thì có thời gian tìm hiểu tài liệu , thời gian code , thời gian viết unitTest , unitTest . Dev có quyền từ chối job nếu tài liệu chưa đầy đủ , kiến trúc solution chưa được SA/PM/Techlead duyệt , tránh được việc làm xong rồi sếp bảo m code sai hết cmnr , nói chung lợi cũng có lợi cho dev , chỉ mệt ông quản lý thôi . nhưng đảm bảo , nếu làm chuẩn thì chất lượng sản phẩm rất tốt bạn ạ. Nhưng nhiều dev dựa vào scrum để lươn lẹo lắm , cty mình cũng có 1 case như thế rồi.
jona_ma
Senior Member
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ỉ
Khang.Hy.Gia.222
Member
có luôn à? cty mình là outsource, thấy cũng làm task như bình thường cơ
L.V.Gaal
Senior Member
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.e thấy nào mà càng đề cao như v thì càng tệ thui
Chủ đề tương tự
