Tech.IT Forward #4: Tổng hợp Q&A

Còn cho đi là còn mãi, chúng mình xin gửi đến cộng dồng IT những câu hỏi đã có lời giải từ các diễn giả Tech.IT Forward Vietnam. Bài viết có sử dụng xen lẫn tiếng Việt và các từ tiếng Anh để tương thích với ngôn ngữ làm việc giao tiếp hàng ngày của cộng đồng.

Q1: 
Làm thế nào để dừng tình huống member cố tình delay 1 task qua nhiều sprint (1 tháng) trong khi 1 sprint chỉ có 2 tuần? Nếu team làm việc theo mô hình Scrum mà không có QC/QA thì làm thế nào để đảm bảo chất lượng chương trình?

A: Để tránh member delay 1 task qua nhiều sprint mình có thể apply một số practices như sau: task breakdown đủ nhỏ để có thể hoàn thành trong 1 sprint, áp dụng DoD để đảm bảo member clear được thế nào là done, keep up với member trong daily để support và resolve các khó khăn hoặc trở ngại nếu có.

Trong trường hợp team ko có QC/QA thì có thể áp dụng theo mô hình Shift Left testing để tăng ownership của developer trong việc đảm bảo release quality. Trong đó sẽ có nhiều practice giúp nâng cao chất lượng và giảm thiểu rủi ro ngay từ đầu.

Q2:
Thực tiễn chuyển đổi agile trong tổ chức tài chính tại VN

A: Các diễn giả không có trực tiếp làm trong các ngân hàng Việt Nam nên chưa đủ thông tin để trả lời câu hỏi của bạn. Tuy nhiên theo thông tin diễn giả James được những người khác chia sẻ cũng như trải nghiệm của anh khi làm việc cho một ngân hàng nước ngoài là quy trình phát triển và vận hành phần mềm ở các ngân hàng chịu ảnh hưởng rất lớn bởi quy trình tài chính của ngân hàng. Cách đây vài năm mình thấy là để deploy 1 version mới lên PROD phải trải qua quá trình kiểm duyệt, ký duyệt rất nặng nề. Các bên phải ký giấy, rồi scan, rồi gửi đi khá cồng kềnh. Nên ở thời điểm đó cho dù có các enhancement có thể deploy lên được nhưng gần như các team phải gom nhiều cái lại deploy chung một lần cho đỡ tốn công làm các process liên quan. Điều này gây nhiều cản trở ảnh hưởng đến tốc độ của team và làm chậm đi quá trình cung cấp giá trị cho người dùng. 
(nếu có bạn nào đang làm agile trong lĩnh vực ngân hàng thì có thể để lại comment chia sẻ thêm nhé)

Q3: 
Backlog là phía Product Owner (PO) sẽ đưa ra, Scrum Master sẽ trao đổi với team và PO à MFV?

A: Trong Scrum thì có 3 vai trò: 

1) PO - product owner. người chịu trách nhiệm chính về sản phẩm như product vision, product backlog

2) Scrum Master hỗ trợ Scrum team về Scrum framework, giúp team hiểu và áp dụng đúng, hiệu quả. Scrum master hỗ trợ team và không nhất thiết, không phải luôn luôn phải có mặt anh scrum master ở đó. tuỳ vào tình trạng của team mà ảnh linh động facilitate scrum event hay bất kì 1 bạn nào trong team cũng có thể facilitate. 

3) Development team phát triển sản phẩm, từ product backlog thành working product. 

Vậy nên PO sẽ trao đổi product backlog với development team, chứ không phải với Scrum Master rồi Scrum Master sẽ trao đổi với development team.

Q4:  

Trong buổi sprint review (demo) sẽ có những stakeholders nào?

A: Trong buổi sprint review sẽ có PdMs, POs, Development Team, Scrum Master và những stakeholders có liên quan và quan tâm đến những chức năng được demo trong event này. Để có 1 buổi sprint review hiệu quả chúng ta cần phải mời đúng stakeholders có liên quan đến Sprint goals. Vì vậy khi tổ chức Sprint Planning cũng nên có stakeholders tham gia cùng team để có thể hiểu được chúng ta sẽ làm gì và deliver chức năng nào khi sprint kết thúc.

Q5: 

Scrum Master cần có thêm kinh nghiệm delivery management như vậy trong 1 project, công việc của 2 role Scrum Master và Delivery Manager có overlap nhau ko hay tách bạch hoàn toàn? 

A: Sẽ không bị overlap mà là bổ xung cho nhau. 

Scrum Master sẽ tập trung vào việc hỗ trợ và tối ưu quy trình phát triển. Trong khi Delivery Manager tập trung đảm bảo Ontime delivery và quallity standard.

MFV nghĩ Scrum Master tương lai nên phát triển thành Engineering Manager (EM) với các mô hình công ty vừa và nhỏ. Như vậy ngoài kinh nghiệm Scrum Master thì EM cần đảm nhiệm cả công việc liên quan Delivery Management.

Q6:

I understand that SCRUM always accepts changes in requirements, roadmap, or goals from stakeholders or PO. But in rare cases, if the project is frequent, it will affect the backlog. If this happens, what actions will the Scrum master take to limit these changes continuously and frequently 

A: MFV hiểu câu hỏi là, mô hình Scrum là luôn chấp nhận những thay đổi liên quan đến requirement, roadmap, goal để đáp ứng nhanh hơn với thị trường, với kỳ vọng của người dùng. Nhưng vài trường hợp thiểu số, việc thay đổi quá thường xuyên sẽ ảnh hưởng tới Scrum team. 

Trong trường hợp này Scrum Master nên trao đổi với PO để hiểu rõ nguyên nhân đằng sau sự thay đổi thường xuyên đó là gì. Đó là bản chất, nature của product, domain, user hay đó là việc PO chưa thật sự hiệu quả, chưa manage backlog vững, chưa có vision rõ ràng. 

Nếu PO chưa đủ kỹ năng, kinh nghiệm dẫn đến backlog thay đổi quá thường xuyên thì Scrum master có thể hướng dẫn PO plan tốt hơn. Ngược lại nếu đó là bản chất của product, domain, user thì Scrum team cần adapt cho phù hợp với hoàn cảnh. Ví dụ plan 80% effort của dev team thôi, và 20% còn lại để đáp ứng thay đổi trong sprint. Số 20% này có thể tăng hay giảm tuỳ ngữ cảnh. Nhưng nếu quá nhiều sẽ ảnh hưởng đến plan và delivery của team. Và nếu sự thay đổi nó quá thường xuyên, quá lớn, đôi khi Scrum không phải là framework phù hợp.

Q7: Nếu quá nhiều matrix và measure thì tốn nhiều thời gian của PO/BA/QC vậy thì có tailoring theo từng module hoặc từng giai đoạn không?

A: Tuỳ và từng dự án, từng giai đoạn mà chúng ta sẽ xác định những metrics nào được sử dụng. Hiện tại ở MFV chúng tôi đang sử dụng Jira Report. 

Jira sẽ collect data hoàn toàn tự động. Công việc của team chỉ đơn giản là đọc và phân tích data từ report của Jira. Nên không mất quát nhiều thời gian của team. Project Team đọc và phân tích data cùng nhau trong buổi sprint retrospective.

Q8: Là 1 non IT project manager, làm sao để dev team tôn trọng các quyết định của mình ạ? Vì khi discuss các vấn đề, các dev luôn xem thường PM ko có base tech nên vô tình dẫn đến những mâu thuẫn không đáng và không cho ra 1 outcome nào.

A: Lý tưởng nhất là mình có PM có base tech sẽ dễ trao đổi và thuyết phục mọi người. Nếu không có:

• PM có thể kết hợp với các thành viên chuyên môn cao về tech để cùng discuss và đưa ra quyết định. 

• PM có thể learning, nâng cao skill tech. Học từ member cũng là một cách để lắng nghe và tăng sự tin tưởng (trust) giữa 2 bên.

• PM có thể tận dụng skill của mình ở những mảng khác (dev process, schedule management)

Q9: Nếu chia boundary theo tech stack thì làm sao có thể bring value (US) cho user nếu 1 user story yêu cầu thực hiện cả công việc của BackEnd và FrontEnd để có thể được user đó

Giả định mình có thể làm được thì việc dependencies giữa BE và FE rất lớn, mà communicate giữa các scrum team thường không nhiều, nên mình thấy khả năng sẽ không hiệu quả"

A: Một scrum team sẽ cần đủ để deliver value cho user nên thực tế việc chia theo tech stack khá khó để đảm bảo việc đó nếu yêu cầu cần cả FE/BE tham gia. Trong câu hỏi của bạn cũng đã đề cập tới các khó khăn nếu triển khai như vậy. Tuy nhiên chia theo tech stack theo mình sẽ phù hợp cho mô hình phát triển theo functional team để improve nhiều hơn các mảng technical.

Cảm ơn các bạn đã đọc đến đây. Cùng chia sẻ bài viết này để lan toả giá trị “Forward” nhé