Bên voz đang có topic tranh cãi về aige với scrum hay quá Cá nhân ngồi bem nhau lý thuyết với mấy expert scrum master thì thấy agile/scrum thích hợp cho mức quản trị hơn hoặc giai đoạn mới phát triển hơn là vận hành. (áp dụng cho cty outsource thì lại ngon nhất rồi). Tuy nhiên áp dụng cho inhouse product mà đã đến gian đoạn vừa build vừa ops thì ko phù hợp. Mình đã đổi methodology từ scrum => kanban + daily. Vẫn duy trì báo cáo monthly cho high level về status của từng epic. cty ae thế nào
Toàn mõm, làm năm rưỡi code 2 tháng, còn bị thằng đồng nghiệp xỉa a chưa làm chưa biết đâu (meanwhile mình làm remote thêm nhưng ko nói ra )
Phần đa những chỗ mình làm thì khá linh hoạt ở vị trí của mình, cũng tùy nơi mà dùng gì. Thường mình kiếm job remote/freelance thì ko hẳn là theo cái gì, chỉ là có features và tự xử. Mấy chỗ đó phần đa các sếp cũng làm team nhỏ, senior và ko thích họp hành nhiều, tuần call 1 buổi, còn lại ae chat riêng công việc.
Nói chung áp dụng scrum 1 cách cực đoạn quá là đã vi phạm nguyên tắc của agile rồi, với mình thì nên áp dụng 1 các vừa phải, với team toàn siêu sao thì bỏ mẹ srum luôn, còn với team toàn fresher thì phải áp dụng triệt để. Còn cá nhân đang remote, onsite thì đang quản lý theo feature, đúng deadline đưa feature là đc.
Scum nhưng có biến tấu, lai Kanban tí Đợt làm AÂ, do là cty dạy scrum nên bên đó cho team toàn dev, ngang role và k chia vị trí, dev tự làm ba-dev-test Kiểu áp dụng lí thuyết hơi strict nên hiệu quả ko cao Giờ làm bên cty khác thì Scrum chỉ để theo mấy event tính velocity thôi, nhưng cách làm việc 1 team vẫn chia rõ vị trí ra cho dễ làm, khá lai Kanban 1 xíu
Nếu thiên về ops thì Kanban ổn hơn ví như devops, support này nọ. Mix thì scrum cho chắc cốp, hoặc tách mẹ nó 2 board: development, support/ops. Theo cách hiểu cá nhân thì lợi ích của Agile là "reduce cost of changes" (chứ không phải là faster development time, có chăng là maximize value in shortest time bằng cách early/frequent/most viable release -> early feedback -> early change -> reduce cost of change). Vậy dự án nào mà scope nó ổn định, ít uncertainty thì lúc đó ko cần Agile vì cost of changes ko có bao nhiêu, mà có thể xài mấy framework khác để reduce waste giúp năng suất cao hơn
Scrum quan trọng nhất là member = nhau về trình độ thì không bao giờ được nhắc đến, cứ áp dụng vào tất cả các team trong khi điều kiện đầu tiên fail mẹ rồi
Nếu block theo kiểu A block B, làm A rồi mới làm B dc: cái này ít thì ko sao, bị thường xuyên là break tasks hoặc break story ko chuẩn, bản chất task của scrum phải là independent. Nếu block theo kiểu cần A + B để release, A xong, B vẫn chưa xong: nếu vậy thì vô phụ hoy hay gặp là backend xong, fe còn lọ mọ, be ko phải ai cũng đá qua fe dc, cái này gặp nhiều thì đi retro nói ra rồi team tìm cách giải quyết.
Thì đó chính là lí do nên ngang nhau để khỏi phải đi giải quyết. Không cần tất cả giỏi nhưng tất cả ngang nhau cũng đỡ vấn đề
Nếu vậy thì thằng development framework nào cũng có thể bị block. Kanban thì bản chất dành cho mấy task độc lập nên ít thấy block. Với đi ngang nhau nó khác với giỏi ngang nhau, có thể prj đó nặng về BE, FE hoặc Infras.. thì cần ưu tiên bên đó hơn. Cái này trước khi trách cái framework thì cần xem bên lead/manager lúc lập team có lập kế hoạch chuẩn chưa.
block là chuyện chắc chắn sẽ xảy ra ko chỉ với các dự án CNTT, mà với tất cả các loại dự án agile hay waterfall khi đó mới cần cái ông PM để làm việc chứ
PM ngay từ đầu đã phải xác định xem project đấy cần nhiều/ít dev FE/BE, rồi thì level các dev về từng skill ra sao thì pick team làm mới chuẩn được
