wslwsl
Senior Member
Ủa vậy tưởng scrum chỉ dùng IT thôi chứ
thảo luận scrum - lợi hay hại
- Người tạo chủ đề Khang.Hy.Gia.222
- Ngày bắt đầu
Peedoo
Senior Member
Các mã nguồn ngày càng nát dần, lí do là phải chạy theo deadline, không tin thì hãy lấy thử vài cái phần mềm cho chính dev tự viết từ đầu đến cuối thì biết. Còn cái scrum thì tôi thấy bị chửi nhiều, và thực tế thì chả ai thấy được cái scrum nào gọi là thành công cả, ai biết chỉ coi. Nghe nó như cái chủ nghĩa Mac Lê trong công nghệ vậy, nghe thì hay nhưng ko ai áp dụng thành công.
Khang.Hy.Gia.222
Member
scrum mà? a lấp liếm với app rùi.
mà thành công theo a là gì?
thí dụ win 10 đi. nhiều ng dùng ok, nhưng bug cả mớ
Khang.Hy.Gia.222
Member
nhìu chỗ bày ra áp vào tất cả mọi phòng ban, và thường chả mang lại lợi ích gì.Ủa vậy tưởng scrum chỉ dùng IT thôi chứ
cty tui cũng v, riết rùi HR, ICT cũng áp scrum, chả hiểu để làm gì. mà những chỗ đó còn dễ,
chứ áp scrum vào KCN chắc bị mấy sếp chém thằng tuyên truyền mất
thang1812
Senior Member
chẳng phải lảng, nhưng các ông toàn hỏi lợi ích của scrum/agile là gì trong khi các ông còn chả hiểu Agile/Scrum nó là cái gì, toàn đem mấy cái bad practice của những team/project tự nhận là agile xong kêu nó lởm.
Còn đây là những thứ mà tôi coi là lợi ích:
1. Scrum fix timebox (sprint), mỗi sprint có timeline, scope và goal rõ ràng, dev team được quyền debate về khối lượng công việc của team trong sprint dựa trên velocity của team -> không có chuyện tự dưng bắt OT để chạy deadline vô lý, ép task giữa chừng
2. Dev collaborate với PO liên tục trong quá trình làm việc (thông qua các session như backlog refinement chứ ko phải đến lúc làm task mới hỏi PO nó là cái gì) nên dev sẽ hiểu về business/domain của dự án -> tạo thành tacit knowledge về nghiệp vụ.
3. Mỗi khi sprint kết thúc sẽ có session retro -> review và tổng hợp những thứ đã làm tốt hoặc có thể cải thiện được, dev được quyền nêu ý kiến về những điều cảm thấy chưa tốt, các issue cản trở họ làm việc và yêu cầu SM tạo thành task để giải quyết
4. daily meeting giúp cho team detect được xem có issue nào đang block hoặc cản trở các member hay không -> xử lý hoặc support, hoặc nếu critical thì raise để get expert vào help, nếu không resolve được thì thay đổi scope/sprint goal
satan456
Đã tốn tiền
Chỗ mình làm thì cũng theo agile, nôm na là chia 1 block lớn việc thành nhiều modules nhỏ để làm.
Modules nhỏ đó có 1 scrum team (cái này chắc tùy tính chất cviec thì sẽ có các role đặc thù khác nhau) các thứ ngồi với nhau làm liên tục các task được PO nêu sẵn ở backlog, cứ thế mà thêm. Daily meeting 15p cái nào khó thì nới thêm dl, involve expert support, khó quá thì bốc ra đưa vào mục riêng giải quyết, hết sprint thì review lại việc.
Mình không ở vị trí dev, nhưng được cái agile có 1 cái hay là giúp communicate liên tục nên đỡ đợi chờ nhau (làm trước, hoàn thiện giấy tờ sau). Chỉ có điều là cty thi thoảng vẫn hơi chuộng thủ tục nên communicate bị gián đoạn. Và cái nữa là có issue là ngồi với nhau giải quyết luôn, không bị delay pending.
Mình không học lý thuyết agile chắc lắm, vào làm thì thấy vậy thôi bác nào giỏi lí thuyết cmt xem để học bổ sung dần
Ăn nhau ở PM PO trình độ họ est được task cho mỗi sprint thì đỡ cực thôi
Modules nhỏ đó có 1 scrum team (cái này chắc tùy tính chất cviec thì sẽ có các role đặc thù khác nhau) các thứ ngồi với nhau làm liên tục các task được PO nêu sẵn ở backlog, cứ thế mà thêm. Daily meeting 15p cái nào khó thì nới thêm dl, involve expert support, khó quá thì bốc ra đưa vào mục riêng giải quyết, hết sprint thì review lại việc.
Mình không ở vị trí dev, nhưng được cái agile có 1 cái hay là giúp communicate liên tục nên đỡ đợi chờ nhau (làm trước, hoàn thiện giấy tờ sau
). Chỉ có điều là cty thi thoảng vẫn hơi chuộng thủ tục nên communicate bị gián đoạn. Và cái nữa là có issue là ngồi với nhau giải quyết luôn, không bị delay pending.Mình không học lý thuyết agile chắc lắm, vào làm thì thấy vậy thôi bác nào giỏi lí thuyết cmt xem để học bổ sung dần
Ăn nhau ở PM PO trình độ họ est được task cho mỗi sprint thì đỡ cực thôi
Yurisha
Senior Member
scrum nào PO lại est task thế fenChỗ mình làm thì cũng theo agile, nôm na là chia 1 block lớn việc thành nhiều modules nhỏ để làm.
Modules nhỏ đó có 1 scrum team (cái này chắc tùy tính chất cviec thì sẽ có các role đặc thù khác nhau) các thứ ngồi với nhau làm liên tục các task được PO nêu sẵn ở backlog, cứ thế mà thêm. Daily meeting 15p cái nào khó thì nới thêm dl, involve expert support, khó quá thì bốc ra đưa vào mục riêng giải quyết, hết sprint thì review lại việc.
Mình không ở vị trí dev, nhưng được cái agile có 1 cái hay là giúp communicate liên tục nên đỡ đợi chờ nhau (làm trước, hoàn thiện giấy tờ sau
Mình không học lý thuyết agile chắc lắm, vào làm thì thấy vậy thôi bác nào giỏi lí thuyết cmt xem để học bổ sung dần
Ăn nhau ở PM PO trình độ họ est được task cho mỗi sprint thì đỡ cực thôi
lucius1605
Senior Member
Anh đọc hiểu kém rồi lại nhép chữ vào mồm tôi rồi. Chỗ nào tôi nói Agile không quan tâm quality anh quote lại để tôi tự gạch nhé. Tôi cũng chưa hiểu anh định dạy gì tôi cái Build the right things/Build the things right? Cái comment của tôi nó thể hiện nguyên văn cái đoạn dài loằng ngoằng anh viết mà nhỉ ? Hay anh chỉ muốn thể hiện là anh biết và muốn dạy tôi những cái anh biết?
Cái tôi nói Agile không nhắc tới quality là cái này này anh ạ, tôi nói Agile chung chung quá làm mọi người hiểu sai, tôi nhận lỗi.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Nhưng cái tôi nói về việc người ta quan trọng working software hơn là quality thì tôi vẫn bảo lưu quan điểm. Anh muốn tranh luận thì tôi tiếp anh.
Còn cái này thì tôi thấy anh nói chuyện toán lý thuyết thôi, lý thuyết hay vision thì cái nào nghe cũng sẽ hay ho cả, nhưng quan trọng là có áp dụng được vào thực tế không. Lập luận cái kiểu không có chuyện, không thể, phải thế này, phải thế kia thì tôi thắc mắc anh đã bao giờ thực sự chạy dead line cho một cái product hay đã bao giờ operate một cái product chưa ?
Vào một dự án phức tạp thì xin thưa với anh là chả có cái scope, chả có cái timeline nào rõ ràng đâu anh ạ. Nếu tất cả đã rõ ràng như anh nói thì người ta làm mẹ nó waterfall rồi. không phải tự nhiên cần Responding to change over following a plan đâu anh ạ. Có rất nhiều dự án cho đến khi bắt đầu implement thì từ Product owner cho tới developer đều lờ mờ về thứ mình build, vì đơn giản có thể Product owner cũng mới chỉ tìm đến agile team với một idea và đang tìm cách validate idea đó. Thế cho nên cái số 1 của anh sẽ không đúng trong mọi trường hợp đâu thưa anh.
Đến cái số 2, ai làm software và làm product nói chung đều hiểu rõ là trên thực tế có rất nhiều trường hợp bị unplan vì vô vàn lý do, và càng làm thì người ta càng hiểu product hơn chứ chả mấy ai đã hiểu cái product mình làm ngay từ đầu cả. Rồi anh định timebox bao nhiều giờ cho cái Backlog refinement ? Như cái trên tôi đã nói, đã là agile thì bỏ cái mindset thích cái gì cũng clear đi. Dev đang implement rồi mà PO vẫn đang nghĩ là chuyện quá bình thường luôn. Tôi còn từng có case PO rõ về cả business lẫn hiểu technical, nhưng vì thay đổi nền tảng công nghệ nên cũng lúng túng về approach, dẫn tới team có blacklog riêng để research và dựng technical approach, vẫn phải tìm cách optimize thời gian vì PO không có nhiều thời gian để họp. Thực tế nó vô vàn bỏ mẹ, dăm ba cái lý thuyết của anh nếu ai từng tìm hiểu cả biết hết.
Cái số 4, anh nói rõ hơn về solution được không, chứ nói lý thuyết thì dễ quá, đâu phải tự dưng người ta mất dần niềm tin vào Agile đâu. cái thời gian mà nhà nhà hype về agile nó qua lâu rồi. Giờ thực tế đổi scope, đổi sprint/iteration goal rồi sao nữa ? nó impact thế nào tơi milistone và rồi làm sao để đạt milestome ? Cái MVP của tôi cần ready trong 2 tháng nữa để testing lấy số liệu đi gọi vốn. Anh định xử lý thế nào tiếp với cái scope anh thay đổi ???? Ví dụ stack mới nên team chưa quen, velocity không đủ thì đổi goal có giúp dự án thành công không thì anh không nói.
Tôi là thằng có đam mê về build up nên tôi hứng thứ đề tài này thôi chư tôi cũng chả anti Agile hay Scrum. Trong khi mọi người đang giữ thái độ chia sẻ thì anh lại mang cái thái độ lên mặt dạy người khác nên tôi bị khó chịu
chứ tranh luận về mấy cái này để biết cái ngu của bản thân thì tôi sẵn sàng
Peedoo
Senior Member
Thành công ở đây là nói đến hiệu quả trong quản lí dự án chứ ko phải là lời lỗ vì cái đó phụ thuộc nhiều yếu tố. Chưa kể nhiều cty quảng cáo là scrum để thu hút khách hàng nhưng ko thật sự chạy theo scrum. Search srcum suck sẽ ra nhiều người dù đã chạy scrum nhiều năm còn quay ra chửi kia.
Love U So Much
Senior Member
cứ lương tăng 40% thì tự nhiên tôi thông minh lạ thường, thậm chí còn cười nhẹ trong cuộc retro, pro active thì ko phải nhắc nhở
cái quan trọng nhất là chất lượng nhân sự, 1 team nó tầm 4 - 7 người thôi. mà người đã ngon, lương cao, đồng tâm hiệp lực thì làm cái gì chả dễ thành công
LoserThapNghiep
Member
Bên mình ko có srum / waterfal gì luôn. Trao đổi với BA rồi pick làm. Rồi có gì BA báo. Hoăck ko dev trao đổi trực tiếp bên bussiness luôn. Code xong tự build docker tự deloy lên server luôn, có khi server bị lỗi thì ssh vô sửa luôn. Lỡ PJ yêu cầu distribute thì dev tự xin thêm tài nguyên rồi build hệ thống luôn. Mỗi dev hâut như ai cũng lm 1 pj chứ ko có task tassk gì. Đó là mình nói ng ta.
PS : có yêu cầu thì dev tự vẽ UI/UX rồi code front end, mobile luôn, làm mạch code embeded, FPGA nêud cần., lỡ thiếu kế toán thì dev vô hoạch toán luôn. Nói chung ko có kanban ka biết scrum gì sất
PS : có yêu cầu thì dev tự vẽ UI/UX rồi code front end, mobile luôn, làm mạch code embeded, FPGA nêud cần., lỡ thiếu kế toán thì dev vô hoạch toán luôn. Nói chung ko có kanban ka biết scrum gì sất
Sửa lần cuối:
canh_1412
Senior Member
Agile nó chạy theo feature, Những người như senior thì phải bỏ thêm time ra để refactor liên tục, cải thiện dần dần để nó trở nên abstraction hơn, nhiều dự án thì có thể xin thời gian để refactor nhưng có dự án không có.
Có những pj thành công về biz nhưng đối với dev chưa chắc đã thành công, dev thì nói về tech, skill thôi nhé
Story thì phải nhỏ nhất có thể, nhưng thực tế nó là Big Story. đọc mù mắt luôn.
Có những pj thành công về biz nhưng đối với dev chưa chắc đã thành công, dev thì nói về tech, skill thôi nhé
Story thì phải nhỏ nhất có thể, nhưng thực tế nó là Big Story. đọc mù mắt luôn
.LoserThapNghiep
Member
À quên nữa. Có cần sửa xe hay sửa cam, lap thì dev lm luôn. Devs chạy ads luôn. Có quy trình gì sất đâu. Nhưng dev bên t thì nâng suất chấp 10 dev cômg ty k
satan456
Đã tốn tiền
Theo chuẩn lí thuyết thì ai est thím nhỉ
Em nghĩ sẽ customize cho phù hợp từng công ty
e cũng mới vào cty áp dụng agile nên cũng chưa nắm hếtLoserThapNghiep
Member
Máy a cứ tư tưởng task task thì cả đời cũng là công nhân code thôi. Lm có nhanh, có đúng cũng chỉ biết làm 1 thứ. Ko bao h lm đc 1 sản phẩm hoàn chỉnh. Mấy a có khác gì công nhân may đâu. Biết may mỗi bộ phận.
Love U So Much
Senior Member
Ok fen đúng, cầm về dc bao tiền. Tự tin 9h đến 4 rưỡi về ko
Khang.Hy.Gia.222
Member
kiểu này nói thẳng ra là bốc lột. thì cũng là thằng làm công thui. hơn j làm chuyên biệt rõ ràng
LoserThapNghiep
Member
Fen lại lầm rồi. Dev bên t chỉ khi nào thật cần. Bình thường mỗi ngày bắt buộc lên 2h thôi. Nếu nhà fen bận fen có thể xin ở nhà cả tháng.
LoserThapNghiep
Member
A lại lầm rồi. Dev bên t thật chí có thể làm part time. Số lượng vừa làm vừa học cao học đầy ra. Mỗi ngày chỉ lên công ty 2h. Nếu ko lên đc thì ơt nhà luôn ko sao. Tiến sĩ cũng ko ít.
Chủ đề tương tự
