Love U So Much
Senior Member
Thế thì hoàn con mẹ nó hảo rồi.
thảo luận scrum - lợi hay hại
- Người tạo chủ đề Khang.Hy.Gia.222
- Ngày bắt đầu
naiveryan
Đã tốn tiền
Những thứ mà bạn kể trên bất kỳ cty nào có Engineering Culture tốt đều có cả, thậm chí cái số 2,4 là những thứ rất bình thường ở mọi doanh nghiệp đều như vậy.
Còn 1,3: OT hay ko, có Improve được gì hay ko lại càng ko liên quan tới Agile/Scrum mà nó liên quan tới Planning, Expertise, Collaborative trong team.
Yurisha
Senior Member
Chuẩn lý thuyết là scrum team est độ phức tạp của từng US, PO ngồi nhìn không có được lớ xớ gì vào quá trình đấy cảTheo chuẩn lí thuyết thì ai est thím nhỉ
Em nghĩ sẽ customize cho phù hợp từng công tye cũng mới vào cty áp dụng agile nên cũng chưa nắm hết
thang1812
Senior Member
Tôi chẳng muốn lên mặt dạy đời ai hay tự cho là mình giỏi, mình hay lắm này kia. Nhưng tôi ghét cái kiểu chống chế, cứ gặp khó là bắt đầu thoái thác rồi tìm cách đổ lỗi, câu hay gặp nhất khi nghe các ông pm apply agile xong fail quay về máng lợn waterfall nửa mùa là “dự án em đặc thù”
Đổi scope, đổi sprint goal làm gì có dự án nào không gặp phải vài ba lần ?
Nhưng để cái câu chuyện đó lặp đi lặp lại thì chính nội tại cái team đó phải đặt ra câu hỏi là tại sao lại như thế ? Tại sao không rút ra được bài học nào sau những lần đầu tiên ?
Rồi chuyện đang làm thì thay đổi nền tảng, idea của PO ko rõ ràng, thế cái sprint 0 thằng PO + SA với tech lead làm gì ? Lúc build skeleton SA không nghĩ đến extension trong tương lai à ? Lúc cần làm epic, làm User story cho backlog thằng PO làm cái gì ?
Rồi anh nói đến lúc dev implement rồi mà PO vẫn đang ngồi viết Backlog thì thôi anh nên vứt mẹ cái dự án ấy đi. Bắt thằng dev build 1 cái thứ mà cái thằng chủ nhân ý tưởng còn chưa rõ hình thù nó như thế nào xong lại kêu tại agile tôi thấy nó khắm thối lắm.
Và cái MVP deadline, các milestone của anh bị impact bởi việc thay đổi scope nó là chuyện bình thường, anh sẽ phải tìm cách motivate team để cố gắng cover (in short term) cái khoảng thời gian anh bị mất để bù lại, agile không cấm việc đó, nhưng để nó xảy ra triền miên thì anh phải tự xem lại project của mình.
Bản thân project tôi đang làm cũng lắm vấn đề bỏ mịa, tech debt và stake holder cần handle cũng không ít, nhưng bọn tôi xác định đó là do mình trong quá khứ chọn cách dễ, chọn tránh thay vì đối đầu nên giờ phải payoff là điều bình thường. Nhưng cái quan trọng là cái agile team của anh có sẵn sàng adaptive, sẵn sàng improve lên hay ko, hay là thôi cứ cách dễ ta làm, nhận lương rồi đến lúc cty giải thể là phắn.
Đôi lời vậy thôi, tôi sẽ ko tham gia vào thread này nữa, vì tôi chẳng phải expert agile mà vào đây dạy được ai, tôi cũng chẳng có nhiều kinh nghiệm quản lý dự án, tôi thấy ngứa mồm nói thì các anh lại bảo dạy đời =.=
-----
Edit:
thêm cái này lúc nãy viết thiếu: Agile chỉ là mindset, Scrum chỉ là một cái framework trên tinh thần agile, và Scrum KHÔNG phải toàn năng, có những dự án dùng waterfall sẽ hiệu quả hơn Scrum, xin đừng apply nó lung tung bừa bãi.
Đổi scope, đổi sprint goal làm gì có dự án nào không gặp phải vài ba lần ?
Nhưng để cái câu chuyện đó lặp đi lặp lại thì chính nội tại cái team đó phải đặt ra câu hỏi là tại sao lại như thế ? Tại sao không rút ra được bài học nào sau những lần đầu tiên ?
Rồi chuyện đang làm thì thay đổi nền tảng, idea của PO ko rõ ràng, thế cái sprint 0 thằng PO + SA với tech lead làm gì ? Lúc build skeleton SA không nghĩ đến extension trong tương lai à ? Lúc cần làm epic, làm User story cho backlog thằng PO làm cái gì ?
Rồi anh nói đến lúc dev implement rồi mà PO vẫn đang ngồi viết Backlog thì thôi anh nên vứt mẹ cái dự án ấy đi. Bắt thằng dev build 1 cái thứ mà cái thằng chủ nhân ý tưởng còn chưa rõ hình thù nó như thế nào xong lại kêu tại agile tôi thấy nó khắm thối lắm.
Và cái MVP deadline, các milestone của anh bị impact bởi việc thay đổi scope nó là chuyện bình thường, anh sẽ phải tìm cách motivate team để cố gắng cover (in short term) cái khoảng thời gian anh bị mất để bù lại, agile không cấm việc đó, nhưng để nó xảy ra triền miên thì anh phải tự xem lại project của mình.
Bản thân project tôi đang làm cũng lắm vấn đề bỏ mịa, tech debt và stake holder cần handle cũng không ít, nhưng bọn tôi xác định đó là do mình trong quá khứ chọn cách dễ, chọn tránh thay vì đối đầu nên giờ phải payoff là điều bình thường. Nhưng cái quan trọng là cái agile team của anh có sẵn sàng adaptive, sẵn sàng improve lên hay ko, hay là thôi cứ cách dễ ta làm, nhận lương rồi đến lúc cty giải thể là phắn.
Đôi lời vậy thôi, tôi sẽ ko tham gia vào thread này nữa, vì tôi chẳng phải expert agile mà vào đây dạy được ai, tôi cũng chẳng có nhiều kinh nghiệm quản lý dự án, tôi thấy ngứa mồm nói thì các anh lại bảo dạy đời =.=
-----
Edit:
thêm cái này lúc nãy viết thiếu: Agile chỉ là mindset, Scrum chỉ là một cái framework trên tinh thần agile, và Scrum KHÔNG phải toàn năng, có những dự án dùng waterfall sẽ hiệu quả hơn Scrum, xin đừng apply nó lung tung bừa bãi.
Sửa lần cuối:
pipoi qwewe
Member
Bác cứ nóng. Thằng kia nó trình còi biết gì đâu mà. Bác cứ lên đây tâm sự với anh em cho vui. Kệ mẹ nó đi ạ.
satan456
Đã tốn tiền
bác đọc thấy kiến thức thâm sâu, lên chia sẻ vài dòng cho ae sau vào đọc chứ bác
Nhiều cái google không có search vOz có là do có những member lão làng truyền lại exp đấy ;D
Trước e đi pvan cũng lội thớt đọc exp các thớt còm men như này để chém gió lúc pvan
thang1812
Senior Member
thực ra là mình thấy mệt nhiều hơn, vì mọi người hiểu sai về agile + scrum xong nghĩ nó là toàn năng, apply vào không được lại kêu nó lởm, hype
Agile nói chung và scrum nói riêng không phải là toàn năng, không phải dự án nào cũng apply được Scrum, còn Agile nó là mindset thì anh có thể inspire cho nhân viên được bao nhiêu là do năng lực của anh, mindset nhân viên tốt lên thì performance tăng, môi trường làm việc thuận lợi, thu hút thêm nhân tài.
Còn Agile nó có rất nhiều framework/practice, ai thấy cái nào phù hợp với tổ chức, với dự án của mình thì apply cái đó, nếu dự án của bạn là kiểu sản xuất or cung cấp service, ticket base, như kiểu IT support trong một công ty thì có thể thử apply kanban, sau đó đo lead time và cycle time của ticket/order để tối ưu quy trình, bỏ bớt những thứ tốn thời gian vô ích đi. Agile lúc này nó chỉ đơn giản là tìm cách cải tiến công việc hiệu quả hơn, thế thôi, đao to búa lớn Scrum chi cho mệt
Hoặc dự án của anh đang chạy waterfall, mọi thứ vẫn ổn, plan vẫn đúng, khách hàng vẫn happy, vậy thì ngu gì chuyển sang scrum cho nó thêm rủi ro. Nếu thích cải tiến quality thì apply thử pair programming xem có hiệu quả không, thử apply TDD xem có giảm defect rate không, ai nói là chỉ có làm Scrum/XP thì mới được làm những thứ đó.
snapdragon0221
Đã tốn tiền
1. Water fall cũng có mà, PjM + Tech lead + Senior cũng phải est effort cho mỗi kì release.
2. Hình như ko có
3. Hình như ko có
4. Daily meeting là thứ nhảm shit nhất trên đời trong mỗi kì sprint. Tôi luôn luôn yêu cầu là bi-daily meeting (15~30'). 1 Weekly meeting (1h).
Dự án cty có cả 2 loại và có ku 95 làm scrum master
znvdicrd
Senior Member
Mượn đoạn bôi đen này tham khảo luôn các anh em đã làm cả Agile và Waterfall: làm agile hay waterfall thì mấy ông SA/tech lead hiểu rõ về các vần đề kỹ thuật dùng trong dự án hơn?
Kinh nghiệm của tôi qua cả mớ dự án đủ thể loại thì làm Waterfall chính ra các ông SA/Techlead nắm rõ hơn. Các dự án Agile tôi join lớn có, nhỏ có thì cái nào cũng trong tình trạng làm cả 4, 5 sprint mới lòi ra những cái phát sinh về kỹ thuật. Lý do là có mỗi cái sprint 0 dò đường như thím này nói nên nhiều cái chưa thể tìm ngay ra - kể cả khách quan như là thằng dự án dependency nó sai, hoặc chủ quan như là dự án nó đòi hỏi những cái edge case của tech mà các ông ấy chưa gặp.
Trong khi hồi làm Waterfall thời gian làm planning với analysis đều dài vãi đạn, dự án 1 năm thì đoạn này làm cũng mất 3 tháng nên những dự án tôi làm Waterfall vấn đề chủ yếu đến từ business hơn là về kỹ thuật. Các vấn đề kỹ thuật phát sinh cũng có nhưng rất nhỏ nên sửa tí là vểnh râu tán phét được rồi.
Cũng có thể những dự án waterfall tôi làm toàn ngắn (max 2 năm) nên nó có khác nhỉ? Có thím nào từng làm dự án dài hơi vào chia sẻ cho anh em phát?
lucius1605
Senior Member
Mấy cái ví dụ kia tôi kể đều là các project thực tế của tôk và apply agile nhé. Các ví dụ tôi kể cũng là các case tôi gặp. Và các dự án đó team tôi đều deliver ngon nghẻ luôn. Ai hay join mấy dự án start up sẽ không thấy lạ lẫm gì mấy cái tôi nêu cả. Nên bớt quy chụp giúp tôi, dự án của tôi có fail đâu 
không giải được câu hỏi của tôi anh lại bảo dẹp. Cơ hội kiếm tiền ai chả cần mà lại kêu dẹp. Dẹp hết thế thì agile làm gì???? Những ví dụ tôi đưa toàn là những case để team mạnh agile thể hiện đấy.
Nó đòi hỏi năng lực collaborate với PO để set expectation. Đỏi hỏi khả năng planning và adapt của team để sẵn sàng nhận thay đổi từ PO. Cũng đòi hỏi expertise của team đủ tốt để sẵn sàng thay đổi theo ý PO. On the same side với bên business để để giải quyết khó khăn của business. Gấp quá thì thử xem có đổi qua no code solution được không. Scope to quá không deliver được thì cái nào priority thấp để cắt đi deliver sau, etc.
Còn tại sao đổi nền tảng? Vì nền tảng cũ có vấn đề của nó. Cần testing với nền tảng mới. Dự án đó xài Google cloud và PO còn thuê cả người của Google để get advice, google nó sắp ra cái gì, thay đổi cái gì team tôi biết trước cả nửa năm trước khi goolge nó public. Và bản thân Google nó cũng thay đổi liên tục thôi anh ạ, vì google cũng không biết chính xác họ cần gì. Thế mới cần adapt to change. Vẫn câu hỏi cũ, nếu muốn tất cả phải clear từ đầu, khi deliver không thay đổi rồi mới làm thì agile để làm gì?
Làm product chả mấy ai biết rõ mình cần gì đâu thưa anh. PO mà biết hết thì cần gì PA. Mà đám PA nó cũng phân tích thấy mẹ, nghiên cứu và chạy campaign các kiểu nhưng idea vẫn fail và chuyện đó là bình thường đó thôi. Những câu hỏi của tôi không nói đến chuyện team mạnh hay yếu, nhưng anh lúc nào cũng assume team yêu nên mới xảy ra vấn đề là sao. Ví dụ của tôi đâu đả động mấy vấn đề về việc lesson learned, review retro các kiểu đâu? =]]
Còn quan điểm ở cái còm bên dưới của anh về agile thì tôi hoàn toàn đồng ý. Cái đội agile theo phong trào và agile chứng chỉ quá nhiều, cũng quá nhiều nơi gắn mác agile để makeup.
P/s: đồng ý là change nhiều quá và mất kiểm soát thì phải coi lại working way và khả năng lern&unlearn của team thật, cái đó tôi đồng ý luôn. Nhưng những case tôi hỏi anh là những case về business problems. Những case đó đòi hỏi team mạnh để giải quyết đấy
không giải được câu hỏi của tôi anh lại bảo dẹp. Cơ hội kiếm tiền ai chả cần mà lại kêu dẹp. Dẹp hết thế thì agile làm gì???? Những ví dụ tôi đưa toàn là những case để team mạnh agile thể hiện đấy.Nó đòi hỏi năng lực collaborate với PO để set expectation. Đỏi hỏi khả năng planning và adapt của team để sẵn sàng nhận thay đổi từ PO. Cũng đòi hỏi expertise của team đủ tốt để sẵn sàng thay đổi theo ý PO. On the same side với bên business để để giải quyết khó khăn của business. Gấp quá thì thử xem có đổi qua no code solution được không. Scope to quá không deliver được thì cái nào priority thấp để cắt đi deliver sau, etc.
Còn tại sao đổi nền tảng? Vì nền tảng cũ có vấn đề của nó. Cần testing với nền tảng mới. Dự án đó xài Google cloud và PO còn thuê cả người của Google để get advice, google nó sắp ra cái gì, thay đổi cái gì team tôi biết trước cả nửa năm trước khi goolge nó public. Và bản thân Google nó cũng thay đổi liên tục thôi anh ạ, vì google cũng không biết chính xác họ cần gì. Thế mới cần adapt to change. Vẫn câu hỏi cũ, nếu muốn tất cả phải clear từ đầu, khi deliver không thay đổi rồi mới làm thì agile để làm gì?
Làm product chả mấy ai biết rõ mình cần gì đâu thưa anh. PO mà biết hết thì cần gì PA. Mà đám PA nó cũng phân tích thấy mẹ, nghiên cứu và chạy campaign các kiểu nhưng idea vẫn fail và chuyện đó là bình thường đó thôi. Những câu hỏi của tôi không nói đến chuyện team mạnh hay yếu, nhưng anh lúc nào cũng assume team yêu nên mới xảy ra vấn đề là sao. Ví dụ của tôi đâu đả động mấy vấn đề về việc lesson learned, review retro các kiểu đâu? =]]
Anh nói ra câu này thì đi tìm hiểu MVP nó là cái gì đi đã. đấy là anh chưa thấy case một ông PO chạy tới tìm team build product rồi mới bắt đầu lên ý tượng và lập feature set thôi
Còn quan điểm ở cái còm bên dưới của anh về agile thì tôi hoàn toàn đồng ý. Cái đội agile theo phong trào và agile chứng chỉ quá nhiều, cũng quá nhiều nơi gắn mác agile để makeup.
P/s: đồng ý là change nhiều quá và mất kiểm soát thì phải coi lại working way và khả năng lern&unlearn của team thật, cái đó tôi đồng ý luôn. Nhưng những case tôi hỏi anh là những case về business problems. Những case đó đòi hỏi team mạnh để giải quyết đấy
Sửa lần cuối:
Khang.Hy.Gia.222
Member
anh nói y chang trong sách. trình bày thì wall of text. còn chưa mẹ j đã chửi ng khác. ignore list tôi 1000 thằng r. chứ k thì
còn anh? anh hóng mà a nói ng ta là thằng này thằng nọ à?
Khang.Hy.Gia.222
Member
mình thì tham gia ít project. nhưng cũng cảm thấy thế
Niels Henrik Abel
Member
naiveryan
Đã tốn tiền
good thinking
zAries
Senior Member
tôi thì tôi thích nhịp độ dồn dập , hard 8 tiếng xong out , thời gian trôi nhanh lắm , cứ loáng cái hết ngày
xong hết tháng từ bao giờLoserThapNghiep
Member
Nó hoàn hảo chứ gì nữa. Có điều nó ko dành cho t. PV 4 lần vẫn fail, chỉ được làm học việc. T đang định đi công ty k đây. Nói công ty chớ t thấy giống lab hơn. PV có 4 vòng. Vòng 1 với 2 thạc sĩ, vòng 2 với 2 thạc 1 tiến. Rồi sau đó làm project, tiền bạc nhiêu thì bên họ hỗ trợ. Rồi lên bảo vệ project đó . Nếu ổn thì vô thử việc qua 5 tháng ổn thì chính thức
Ayemdi
Member
Lợi hay hại là do dân tộc tính nữa bạn ạ.
Tại sao người ta nói chuyện 3 người Nhật làm chung thì khác với 3 người Việt làm chung.
Xuất phát từ xã hội và nền giáo dục, đã làm cho người VN mắc phải 2 thứ trong công việc:
1. Ngại trách nhiệm.
2. Sợ tranh công. Cứ thấy mình làm nhiều hưởng ít, thằng khác làm ít mà nó hưởng nhiều.
Vậy nhé, Agile, ISO, Kanban, 5S...đều tốt và có lợi. Chúng xuất phát từ những nơi có tinh thần làm việc nhóm tốt, làm việc theo qui trình.
Tất cả những bài viết nói những thứ này không hiệu quả, mà do người VN viết, không cần đọc.
Tại sao người ta nói chuyện 3 người Nhật làm chung thì khác với 3 người Việt làm chung.
Xuất phát từ xã hội và nền giáo dục, đã làm cho người VN mắc phải 2 thứ trong công việc:
1. Ngại trách nhiệm.
2. Sợ tranh công. Cứ thấy mình làm nhiều hưởng ít, thằng khác làm ít mà nó hưởng nhiều.
Vậy nhé, Agile, ISO, Kanban, 5S...đều tốt và có lợi. Chúng xuất phát từ những nơi có tinh thần làm việc nhóm tốt, làm việc theo qui trình.
Tất cả những bài viết nói những thứ này không hiệu quả, mà do người VN viết, không cần đọc.
namcungkiem
Member
Có ae nào làm Automotive bị bắt đú trend làm Agile chưa.
Post cái comment của 1 Giáo Sư Nancy Leveson luôn mà các thánh vẫn kêu làm đi
"You have to be insane to use Agile on safety-critical systems." Professor Nancy Leveson (2020).
Post cái comment của 1 Giáo Sư Nancy Leveson luôn mà các thánh vẫn kêu làm đi
"You have to be insane to use Agile on safety-critical systems." Professor Nancy Leveson (2020).
grand_magus
Junior Member
Theo mình thì scrum hay waterfall hay V-Model ,.... đều tùy thuộc vào tính chất của mỗi dự án, khách hàng, sản phẩm nữa... chỉ là chọn mô hình nào phù hợp nhất hoặc kết hợp các mô hình theo từng giai đoạn cho phù hợp mà thôi
Chủ đề tương tự
