SCRUM - Yahoo! JAPAN & Techbase Việt Nam - Vượt qua khoảng cách

February 24, 2020

Bài viết về câu chuyện áp dụng mô hình Scrum của TBV đã được đăng trên『Yahoo! JAPAN Tech Blog』của công ty Yahoo! JAPAN. Mọi người cùng đọc nhé!

■Yahoo! JAPAN Tech Blog

https://techblog.yahoo.co.jp/entry/20200212812580/

Chào các bạn, tôi là Định, hiện tôi đang phụ trách dự án Yahoo! Game tại Techbase Việt Nam. Techbase Việt Nam (TBV) là công ty con của Yahoo! JAPAN (YJ) tại thành phố Hồ Chí Minh, Việt Nam. TBV được thành lập năm 2015, hiện tại đang phát triển khoảng 20 services của công ty Yahoo! JAPAN.

TBV Homepage: https://www.techbasevn.com/

Lần này tôi xin được giới thiệu câu chuyện áp dụng Scrum của team dự án thuộc service Game.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Những vấn đề gặp phải

Từ tháng 8 năm 2018, với mục đích đổi mới hệ thống đã có của service Game, tôi đã phụ trách phát triển dự án đó tại TBV.

Yahoo! JAPAN thì theo mô hình Scrum nhưng tại TBV thì chúng tôi vẫn theo mô hình Waterfall.

Nhờ những tiến bộ về skill kỹ thuật cũng như nắm vững nghiệp vụ của team, nên chất lượng và tốc độ develop đã được cải thiện rất nhiều. Vì vậy phạm vi công việc mà TBV phụ trách cũng được mở rộng từ giai đoạn design tới IT test.

Tuy nhiên, những đóng góp của TBV vẫn còn giới hạn trong toàn bộ quá trình phát triển dự án.

Organization chart giữa Yahoo! JAPAN và TBV như dưới đây.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Ngoài ra, khi YJ làm việc với TBV thì phát sinh vấn đề là họ cần phải thực hiện "thêm" khá nhiều những task dưới đây.

  1. Confirm estimation và schedule, meeting thì chủ yếu confirm tiến độ và vấn đề
  2. Tạo tài liệu requirement chi tiết
  3. Review sản phẩm của từng giai đoạn (design, source code, test result)

Quyết định áp dụng Scrum

Để giải quyết vấn đề phạm vi công việc nhỏ, chi phí quản lý của YJ cao thì tôi nghĩ cần phải thực hiện 2 điều dưới đây.

  1. Mục đích của TBV không phải là tạo ra program, mà là mang service đến cho người dùng. Vì vậy, team phát triển TBV phải đóng vai trò chính (không phải là team chỉ thực hiện theo những chỉ thị). Tất cả các member dự án phải hiểu được WHY và thực hiện WHAT) (Lúc ấy team chỉ được chỉ thị về WHAT)
  2. Để hiểu rõ được WHY thì phải rút ngắn khoảng cách và communicate trực tiếp với người phụ trách dự án bên phía YJ (Planner/ Product Owner/ Develop team)

Để đạt được cả 2 điều này thì đã quyết định áp dụng Scrum vào dự án. Lấy mục tiêu là không đơn thuần chỉ là thực hiện việc phát triển mà còn phải hiểu được mục đích của việc phát triển, đóng góp nhiều hơn vào giá trị của service, kế hoạch công việc.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Training trước khi áp dụng Scrum vào dự án

Scrum không chỉ được áp dụng vào chỉ riêng dự án Game mà đã được áp dụng trong toàn bộ TBV. Trong các dự án mà TBV đang phụ trách thì có 3 dự án, bao gồm cả Game, được chọn làm pilot áp dụng Scrum.

Nếu chỉ áp dụng framework Scrum thì đơn giản, nhưng rất khó để team có thể nắm bắt được mục đích của những nội dung được định nghĩa trong Scrum, hiệu quả khi áp dụng mô hình này và có được năng lực cải thiện bản thân. Hơn nữa, khi áp dụng Scrum thì không chỉ TBV mà cả YJ cũng cần phải thay đổi cách làm việc vốn có. Chính vì vậy, cả TBV lẫn YJ đã được Agile Coach hướng dẫn, training trong khoảng nửa năm.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam Team khi đang training Scrum

Kế hoạch áp dụng Scrum

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Sau buổi seminar giới thiệu về việc áp dụng Scrum, các team thảo luận với nhau và có những quyết định khi áp dụng mô hình Scrum thì sẽ có những thay đổi như sau.

  • Thay vì breakdown requirement từ YJ thành task thì chuyển sang quản lý bằng Product Backlog (PBL) → Acceptance Criteria (điều kiện chấp nhận) và quan điểm chất lượng được làm rõ
  • Trước thì Team leader sẽ estimate nhưng giờ Team member sẽ estimate số point theo phương pháp Planning pocker → sự cộng tác trong team được đẩy mạnh
  • Trước thì team leader sẽ tạo schedule, nhưng giờ thì trong buổi Scrum planning thì cả team sẽ cùng nhau chọn PBL sẽ làm trong sprint tiếp theo. → Hiểu rõ thứ tự ưu tiên
  • Thay vì YJ sẽ review Deliverable ở mỗi giai đoạn phát triển, giờ thì mỗi Sprint YJ đều review các chức năng thông qua working software được demo. → Việc review trở nên đơn giản hơn nhờ confirm software chạy được, có thể review được kỹ càng nên chi phí fix được giảm đi
  • Vào cuối mỗi sprint thì tổ chức KPT (retrospective), Team member có thể chia sẻ những điểm tốt, điểm cần cải thiện, chốt phương án hành động → Có thể trở thành một team mà sớm có những hành động để giải quyết vấn đề, có thể tự improve bản thân.
Planning poker là gì?
Planning poker là một practice được sử dụng khi thực hiện estimate trong phát triển Agile. Các member cầm tấm thẻ giống như trump cùng nhau đọc lên số point của item sẽ estimate. Nếu như ý kiến của các member không giống nhau, thì cả team lại cùng thảo luận và cùng nhau đọc lên số point lại một lần nữa. Nhờ thảo luận được lặp đi lặp lại này mà giữa các member có thể chia sẻ cho nhau sự hiểu biết, dần hiểu nhau hơn và năng lực của team sẽ được nâng cao.

Vấn đề phát sinh và action giải quyết

Được sự giúp đỡ của Agile Coach, team đã dần tiến hành chuyển đổi sang mô hình phát triển Scrum. Tuy nhiên trong quá trình chuyển đổi thì cũng có những vấn đề phát sinh. Bên dưới là những vấn đề ấy và cách giải quyết

Vấn đề về khoảng cách địa lý khi phát triển offshore và rào cản ngôn ngữ

Theo như Agile Manifesto (tuyên ngôn phát triển Agile) được định nghĩa vào năm 2001, thì đề cao việc cộng tác với khách hàng. Nhưng, khi tiến hành Scrum giữa Nhật Bản và Việt Nam thì đã có một khoảng cách về địa lý và rào cản ngôn ngữ.

Agile Manifesto
https://agilemanifesto.org/iso/en/manifesto.html

Giải quyết vấn đề về khoảng cách địa lý

Giữa Product Owner (PO) phía Nhật Bản và team phát triển TBV gặp khó khăn khi thảo luận trực tiếp, thảo luận sâu về những vấn đề liên quan tới requirement. Mặc dù là vẫn có hệ thống Teleconference hoặc tool communication, nhưng mà khi có chuyện gì xảy thì cũng khó mà communication nhanh được. Để cải thiện vấn đề này, thì chỉ định PO tại TBV, vai trò của Scrum team thì assign toàn bộ cho TBV. Vai trò PO sẽ được assign cho member biết tiếng Nhật, và member đó đã củng cố kiến thức nghiệp vụ để có thể định nghĩa PBL. PO tại TBV hiểu rõ được tình trạng của team phát triển, tạo PBL, thực hiện HO-REN-SHO (Báo cáo - Liên lạc - Thảo luận) với YJ.

Và dưới đây là những hiệu quả đã đạt được khi assign PO tại TBV.

  • Vì toàn bộ Scrum team ở cùng một nơi (Việt Nam) nên cũng dễ cộng tác, và có thể nhanh chóng giải quyết vấn đề
  • Có thể meeting hiệu quả mà không có sự tham gia của phía YJ, nên tiết kiệm được thời gian cho YJ member

Giải quyết vấn đề về ngôn ngữ

Như cũng đã đề cập ở phần trên, trong phát triển Scrum thì comminication sẽ rất quan trọng. Nhưng mà, tiếng Nhật và tiếng Việt không giống nhau nên team mình đã mất rất nhiều thời gian cho việc communication.

Ví dụ, trong buổi Sprint Review thì team sẽ demo những kết quả đã làm cho YJ, nhưng sau khi team phát triển giải thích bằng tiếng Việt thì communicator của TBV (phiên dịch viên) sẽ dịch lại bằng tiếng Nhật, nên sẽ mất gấp đôi thời gian, có trường hợp lượng thông tin nhiều quá hoặc phiên dịch không đủ ý. Và team mình đã cải thiện bằng cách là communicator giỏi tiếng Nhật sẽ thực hiện demo thay cho developer. Để communicator có thể demo được tốt thì trước buổi Sprint Review thì team phát triển support communicator như là giải thích nghiệp vụ, giải thích trình tự demo, và cùng nhau luyện tập trước. Kết quả đạt được:

  • Không mất thời gian cho việc phiên dịch nên thời gian demo cũng ngắn lại, Sprint Review cũng được tiến hành suôn sẻ hơn, và cả 2 bên hiểu nhau hơn.
  • (Thành quả ngoài mong đợi) Communicator biết nhiều hơn về nghiệp vụ, từ vựng kỹ thuật.
  • (Thành quả ngoài mong đợi) Communicator càng muốn cống hiến nhiều hơn nữa cho cho team phát triển.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Sự conflict về vai trò quản lý và Scrum team

Cơ cấu tổ chức thường thấy ở TBV như dưới đây. Đó là cơ cấu command/control, cấp trên đưa ra chỉ thị.

Project manager (PM) → Team leader → Member

Trong khi đó, team phát triển theo mô hình Scrum, với mục tiêu là trở thành một team tự quản, tự chủ, trưởng thành, nên sẽ không phù hợp với cấp trên theo kiểu command/control. Khi áp dụng Scrum thì thay đổi vai trò của nhóm quản lý như thế nào? Đó cũng là vấn đề.

Nhân tiện thì ở Việt Nam mình thấy là có nhiều management theo kiểu command/control hơn ở Nhật.

Vì vậy, sau khi Nhóm quản lý và team phát triển đã thảo luận với nhau, xem xét tới những vai trò trong Scrum, thì đã quyết định thay đổi cơ cấu tổ chức thành như sơ đồ dưới đây.

  • Team Leader sẽ đóng vai trò là Scrum Master, sẽ quan sát và support team
  • PM sẽ support Scrum Master/Product Owner vận hành thành công mô hình Scrum. Ngoài ra, PM sẽ kết hợp với Agile Coach xây dựng trạng thái mà ở đó team đang tập trung hướng tới một hình ảnh tốt đẹp hơn.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Theo như sơ đồ ở trên, thay vì management theo kiểu command/control thì PM, leader đã thay đổi cách làm việc để team có thể tự quản và hoàn thành được công việc. Chỉ có điều, cũng có những lo lắng khi có sự thay đổi này. Từ trước tới giờ team leader có liên quan trực tiếp với member để quản lý chất lượng và tiến độ. Nhưng mà nếu team leader đóng vai trò là Scrum Master sẽ quan sát/support team thì trách nhiệm/quyền hạn sẽ ít đi, động lực làm việc cũng giảm đi. Ngược lại, team phát triển cũng cảm thấy trách nhiệm của mình nhiều hơn và sẽ thấy áp lực hơn.

Với những lo lắng này thì tôi vừa giải thích cặn kẽ vai trò và trách nhiệm trong mô hình Scrum cho tất cả member, và lắng nghe ý kiến của cả team. Nhờ vậy mà cả team đã thấu hiểu được.

SCRUM - Yahoo! JAPAN - Techbase Việt Nam

Những vấn đề khi áp dụng practice của scrum

Ở giai đoạn Scrum Framework, có vài vấn đề phát sinh, nhưng team đã giải quyết từng cái từng cái một.

  • Để tăng cường sự cộng tác trong team thì team đã áp dụng mob programing. Nhưng ngay sau khi áp dụng thì tạm thời productivity cũng có giảm đi. → Team đã giải thích với bên YJ về hiệu quả của việc áp dụng mob programming như là skill, và sự cộng tác của team sẽ được nâng cao, thì đã được YJ đồng ý. Ngoài ra, không phải là áp dụng với tất cả mà để quyết định task trong Sprint Planning một cách hiệu quả. Mặc dù ngay sau khi áp dụng mob programing thì productivity có giảm nhưng skill và sự hiểu biết của team được nâng cao, và cuối cùng thì productivity cũng được tăng lên.

    SCRUM - Yahoo! JAPAN - Techbase Việt Nam

  • Cũng có trường hợp là vì thời gian của Sprint là 1 tuần nên có những PBL không thể hoàn thành được trong sprint đó, chất lượng thì giảm. → Team đã cố gắng brainstorming để có thể định nghĩa được PBL nhỏ hơn, hoặc áp dụng mob programing để giảm thời gian review, hoặc tìm cách để cho cả team có thể tự test được (công việc mà trước giờ một mình leader làm).
  • Trong buổi KPT thì ít ý kiến được đưa ra, bầu không khí trở nên trầm xuống. → Team đã đưa ra metric chung, khi KPT thì đánh giá lại metric đó, Scrum Master thúc đẩy memnber đưa ra ý kiến. Nhờ vậy mà bầu không khí team cũng được cải thiện. Ví dụ, Fun/Done/Learn đã có hiệu quả.

Cuối cùng

Khi áp dụng Scrum, team không chỉ làm việc được chỉ thị mà tự chúng ta thiết lập mục tiêu (Vision), cam kết với mục tiêu đó, và quyết tâm để hoàn thành được mục tiêu đã đặt ra.

◇Vision

  • Cả YJ và TBV đều có vision giống nhau
  • Để phát huy hơn nữa phong độ đẳng cấp cao thì YJ và TBV trở thành one team (đồng lòng)
  • Sự thỏa mãn của khách hàng (CSS) đạt trên 85%
  • Không còn bug phát sinh sau khi giao sản phẩm cho YJ
  • Trở thành team Cross-functional
  • Tăng productivity, product sau khi delivery thì phải thỏa mãn được tất cả AC (Acceptance Criteria)
  • Trở thành một team có thể tìm ra vấn đề và chia sẻ những vấn đề đó

Vẫn còn nhiều những vấn đề cần cải thiện nhưng team đã áp dụng thành công mô hình Scrum vào phát triển service Game.

Sau khi áp dụng scrum, team đã nhận được những comment từ phía YJ.

  • TBV đã đảm nhận kế hoạch của Sprint Review nên TBV đã trở nên tự chủ hơn, giảm được việc rework
  • Review bằng demo đã giúp việc review delivariable (design, source code, kết quả test) của mỗi công đoạn được giảm đi
  • Giảm effort tạo tài liệu khi assign công việc
  • TBV đảm nhận việc quản lý JIRA sau khi assign công việc, nhờ vậy mà phạm vi đối ứng bussiness được mở rộng từ giai đoạn design tới làm task. Nên số đề xuất từ TBV đã tăng.
  • Sau khi áp dụng Scrum thì rework đã giảm đi. Cảm nhận là chất lượng đã tăng lên khoảng 5%

Mặc khác, TBV cũng có những cảm nghĩ qua Scrum như dưới đây.

  • Mỗi tuần, với việc demo được working software cho YJ và nhận được feedback ngay , nên team có nhiều cơ hội cảm nhận được cảm giác đạt được mục tiêu.
  • Có cảm giác là cả team đang cùng làm chứ không phải là từng cá nhân riêng lẽ làm task riêng. Có vấn đề gì thì có thể thảo luận với team, có lúc lại làm brainstorming. Ngoài ra, thực hiện mob programming khi phát triển thực tế đã làm cho ý thức cộng tác trong team được nâng cao và động lực của team cũng được tăng lên.
  • Nâng cao được tinh thần trách nhiệm, bản thân phải đảm bảo được chất lượng sản phẩm mình làm ra, không phải nhờ vào leader hay đàn anh review.
  • Tinh thần hướng tới mục tiêu được đẩy mạnh, nên mọi thành viên đều hướng tới mục tiêu chung và làm việc cùng nhau
  • Không quan trọng là kinh nghiệm ít hay nhiều, tất cả đều được thử thách với những task có kỹ thuật mới hay những task khó nên team đã trưởng thành nhanh chóng

"Mọi người cùng tôn trọng nhau, và không chỉ là kết quả mà quan trọng là phải dám thay đổi hành động để đạt được kết quả ."

Với tinh thần đó, chúng tôi hướng đến xây dựng team có thể tự lập, tự phát triển sau này.

Trần Thanh Định
Techbase Việt Nam Company Limited - Project Manager
Phụ trách các dự án Yahoo! Game, Yahoo! Premium, Yahoo! BB