thảo luận Hội anh em Project Manager - Scrum Master

Thai-Tu-Shang said:

Chào mọi người.

Mình giới thiệu qua một chút, mình hiện tại đang đảm nhiệm vai trò về Agile Project Manager và Scrum Master của công ty. Mình có theo dõi box thì thấy có rất nhiều topic về kỹ thuật nhưng chưa có Topic nào cho anh em đang làm quản lý dự án trao đổi kinh nghiệm và chia sẻ với nhau.

Với mình thì đặc thù mỗi công ty sẽ có những cách vận hành và áp dụng các process khác nhau. Mình có thể trao đổi kinh nghiệm với nhau về cách mà các tổ chức đang triển khai và biết đâu có thể tìm thấy những cái hay ho cho đội ngũ hoặc team của mình.

Hiện tại thì mình đang có 1 câu hỏi và đang đi tìm câu trả lời: Estimate point trong dự án Agile - đâu là khái niệm phù hợp nhất.

Bên mình hiện tại đang đánh giá point dựa trên 3 yếu tố: complexcity ( độ phức tạp ) - uncertainty/risk ( độ mơ hồ, rủi ro) và effort.

Tuy nhiên việc est như này có một vấn đề là làm sao để các ước lượng có thể sát với thực tế, hoặc làm sao để mọi người trong team có chung góc nhìn

Click to expand...

các ước lượng có thể sát với thực tế

Click to expand...

làm sao để mọi người trong team có chung góc nhìn

Click to expand...

nautilux said:

Cái này mình nghĩ trong các buổi planning / retro bạn cần chia sẻ các thông tin chi tiết hết mức c ó thể để mọi người cùng nắm được

Click to expand...

Lập Trình Viên Trẻ said:

Mấy ông PM nhàn vc mà lương cao, ở công ty mình chỉ ngồi họp với khách lúc bắt đầu dự án sau đó ngồi chơi, mà lương cao.

Click to expand...

Thai-Tu-Shang said:

À chắc mình chưa nói rõ ý. Nhưng mà team của mình thì đang gặp tình trạng như này:

Nếu theo Agile thì team có đủ cross functional, có nghĩa là bản thân những thành viên trong team đều có đủ kỹ năng để giải quyết vấn đề.

Nôm na nó giống như là trong 1 đơn vị quân đội có lục quân, thông tin, pháo binh, điệp viên, y tế...
Thì Scrum team là 1 team mà mỗi ông trong đó đều có đủ các kỹ năng cần thiết: vừa bắn nhau đc, vừa thu thập thông tin, vừa cứu thương, vừa lái xe...

Quay về team hiện tại, một số scrum team vẫn đang chia thành BE, FE, Tester, BA.. Và thế là khi est thì ông BE chỉ có góc nhìn của BE, FE chỉ có của FE.

Thành ra có ông vote 5 ông vote 8

Mà chắc chắn để có 1 ông full toàn bộ thì cty không thể đầu tư budget cho các bạn như vậy được. Mà để các bạn tự học thì cũng không có luôn

Click to expand...

Thai-Tu-Shang said:

Mình không biết ở cty khác như nào, nhưng vs mình sau 5 năm làm PM thì đúng là nhìn vào thì thấy PM chả làm gì cho dự án. Nhưng những công việc của PM thực sự làm thì nó lại thường không thể nhìn thấy hoặc là nó rất nhỏ nhặt nhưng lại quan trọng cho dự án.
Không dưng mà vị trí PM lại ngồi chơi mà lương cao đâu )

Click to expand...

Thai-Tu-Shang said:

Mình không biết ở cty khác như nào, nhưng vs mình sau 5 năm làm PM thì đúng là nhìn vào thì thấy PM chả làm gì cho dự án. Nhưng những công việc của PM thực sự làm thì nó lại thường không thể nhìn thấy hoặc là nó rất nhỏ nhặt nhưng lại quan trọng cho dự án.
Không dưng mà vị trí PM lại ngồi chơi mà lương cao đâu )

Click to expand...

namcungkiem said:

Tôi làm PM xưa giờ chả bao giờ được ngồi chơi. PM mà ngồi chơi hơi có vấn đề.
Khi không meeting tôi cũng vô ngồi review requirement, design, code, testcase đại loại thế.
Nắm càng rõ, càng dễ nói chuyện với ae, cũng như thấy được nhiều risk mà các ae ko thấy.
Thường Req chỉ nắm Req, Design-Code chỉ nắm phần mình, test chỉ nắm phần test.
Thì là người leader project, nắm hết sẽ thấy được bức tranh tổng quan hơn.
Còn về Agile thì chấm hóng các ae đồng đạo. Tôi làm trong Automotive nên Agile hơi xa xỉ. Cơ mà có vẻ Agile hợp với Web/App hơn Automotive.
Đang làm Agile nửa mùa. Hiện tôi chỉ cố gắng Agile hóa từng process trong automotive.
Tức là thay vì Requirement làm 1-2 tháng mới xong thì cứ 2 tuần release 1 lần để ae xem review cuốn chiếu.

Click to expand...

cái mũ bảo hiểm said:

PM nào ngồi chơi?

Click to expand...

namcungkiem said:

Tôi làm PM xưa giờ chả bao giờ được ngồi chơi. PM mà ngồi chơi hơi có vấn đề.
Khi không meeting tôi cũng vô ngồi review requirement, design, code, testcase đại loại thế.
Nắm càng rõ, càng dễ nói chuyện với ae, cũng như thấy được nhiều risk mà các ae ko thấy.
Thường Req chỉ nắm Req, Design-Code chỉ nắm phần mình, test chỉ nắm phần test.
Thì là người leader project, nắm hết sẽ thấy được bức tranh tổng quan hơn.
Còn về Agile thì chấm hóng các ae đồng đạo. Tôi làm trong Automotive nên Agile hơi xa xỉ. Cơ mà có vẻ Agile hợp với Web/App hơn Automotive.
Đang làm Agile nửa mùa. Hiện tôi chỉ cố gắng Agile hóa từng process trong automotive.
Tức là thay vì Requirement làm 1-2 tháng mới xong thì cứ 2 tuần release 1 lần để ae xem review cuốn chiếu.

Click to expand...

Thai-Tu-Shang said:

À chắc mình chưa nói rõ ý. Nhưng mà team của mình thì đang gặp tình trạng như này:

Nếu theo Agile thì team có đủ cross functional, có nghĩa là bản thân những thành viên trong team đều có đủ kỹ năng để giải quyết vấn đề.

Nôm na nó giống như là trong 1 đơn vị quân đội có lục quân, thông tin, pháo binh, điệp viên, y tế...
Thì Scrum team là 1 team mà mỗi ông trong đó đều có đủ các kỹ năng cần thiết: vừa bắn nhau đc, vừa thu thập thông tin, vừa cứu thương, vừa lái xe...

Quay về team hiện tại, một số scrum team vẫn đang chia thành BE, FE, Tester, BA.. Và thế là khi est thì ông BE chỉ có góc nhìn của BE, FE chỉ có của FE.

Thành ra có ông vote 5 ông vote 8

Mà chắc chắn để có 1 ông full toàn bộ thì cty không thể đầu tư budget cho các bạn như vậy được. Mà để các bạn tự học thì cũng không có luôn

Click to expand...

mraztrea said:

e làm tech lead, tự nhiên bị kéo lên làm PM , dân IT cổ hủ (đầu 8x) nên chả theo scrum hay agile, bác nào có tài liệu hướng dẫn agile cho em với, kiểu học cơ bản thôi ý. ko cần sâu như mấy ông PM lõi đời

Click to expand...

Hideto Takahashi said:

Scrum and XP from the Trenches - 2nd Edition

Một cuốn này là đủ nắm sơ bộ nha bác

Click to expand...