Bạn là một thành viên hơi hơi cứng tuổi và mới join vào công ty. Một ngày đẹp trời, bạn được lãnh đạo gọi lên và giao cho một nhiệm vụ..."hỗ trợ một team phát triển trong công ty thực hiện phát triển phần mềm theo khung làm việc scrum" do đối tác yêu cầu cty phát triển phần mềm theo scrum framework và đối tác sẽ cử người sang làm PO (lãng xẹt đúng không !!? ).

Tương đương với việc tôi sẽ được đề cử làm Scrum-master cho scrum-team này. Tôi được chọn vì tôi đã từng tham gia nhiều scrum-team trong suốt quá trình đi làm "thuê" của mình. Tôi có một vài tuần chuẩn bị những gì cần thiết (trong đó có join một số khóa học - "tây" có, "ta" cũng có). Có vẻ như những thông tin đầu tiên này sẽ gây buồn cười với các anh/các bạn scrum-master chuyên nghiệp, nhưng đây lại là một cơ hội và career-path mới của tôi, tất nhiên là tôi nhận lời "sếp" làm và hiện tại thì tôi đã là SM "xịn sò" với một số chứng chỉ scrum.org dắt túi.

Những bài viết dưới đây của tôi sẽ chia sẻ với các bạn, hành trình ngắn ngắn mà tôi và scrum-team đầu tiên trong công ty đã chiến đấu cùng nhau để xây dụng một team vững mạnh, tiền đề cho các team khác trong công ty chuyển từ warter-fall sang scrum.

Lựa chọn tài liệu để tìm hiểu và đào tạo về scrum.

Để khởi động việc build một scrum team thì phải bắt đầu với việc đào tạo cho các bạn trong team biết về scrum, hiểu các nguyên lý cơ bản đang vận hành trong scrum framework. Sau một vài turn làm việc (sprint) thì tối ưu dần dần.

Tài liệu về Scrum/Agile thì khá nhiều, cả về video training và ebook, sách giấy nhưng với một team mới bắt đầu về scrum mà để các bạn đọc/xem tài liệu bằng tiếng Anh là một thử thách khá lớn.

May mắn cho tôi, thời điểm ấy, ở Việt Nam đang có 2 cuốn sách viết bằng tiếng Việt:

Cẩm nang SCRUM cho người mới bắt đầu - của các tác giả Học viện Agile

và cuốn Aglie Y - của tác giả Nguyễn Văn Hiển.

Tôi đọc đi đọc lại 2 cuốn sách trên trong vòng 3 ngày, take note kín mít một cuốn sổ dày về những gì dự định sẽ training/giải thích cho các bạn đồng nghiệp. Mỗi khái niệm sẽ cố gắng đưa ra một vài ví dụ. Lúc đầu, cách giải thích của tôi khá lộn xộn, dựa trên các đề mục của cuốn sách "Cẩm nang SCRUM"; về sau, tôi chỉnh lý lại và đưa ra các đề mục dựa trên thứ tự A-Z (Glossary).

Các bạn có thể tham khảo các glossary "chuẩn chỉnh" tại trang: https://www.scrum.org/resources/scrum-glossary.

Sau này, có khóa học online của nhóm thành viên Học viện Agile trên trang Kyna (hiện tại thấy unavaiable), khóa học này khá đầy đủ và dễ hiểu. Các bạn có quan tâm đến thì liên hệ trực tiếp với nhóm tác giả nhé.

Lựa chọn phương pháp trình bày công việc.

Sau một vài buổi "lý thuyết" với đồng nghiệp giới thiệu về SCRUM, chúng tôi bắt đầu setup công việc của team. Đầu tiên là phải chọn cách hiển thị sự "minh bạch" công việc giữa các thành viên trong team tại mỗi thời điểm. Ví dụ nhân sự A có thể biết B gần nhất làm gì (đã), hiện tại đang làm gì và sẽ làm gì tiếp theo.

Lúc đầu chúng tôi chọn dùng Trello, mỗi thẻ trello là một công việc, mỗi board là một backlog (Sprint Backlogs, Product Backlogs, ...). Sau một thời gian thì việc dùng Trello gặp một số hạn chế, chủ yếu liên quan đến việc mỗi thẻ trello không hiển thị được hết những nhu cầu mà PO mong muốn như hiển thị epic; nội dung công việc, các comment không hỗ trợ WYSIWYG; test-case phải quản lý bên ngoài; chức năng của thẻ mà "to quá" cần break ra thì không có cách để liên kết chúng với nhau,; sau mỗi sprint thì scrum-master phải tự cộng story-point, vẽ burn-down chart ra ngoài....

Sau thời gian tham khảo của các công ty khác, chúng tôi chuyển sang sử dụng Jira. Thật vui là các chức năng mà Jira cung cấp vượt mong đợi. Nhờ có Jira mà công việc SM của tôi trở lên nhẹ nhàng hơn rất nhiều (tất nhiên là giá của nó cũng kha khá "chát")

Các công cụ vật lý hỗ trợ cho công việc.

Để phục vụ cho các buổi meeting (đặc sản của scrum), chúng tôi cần chuẩn bị một bảng có thể viết và xóa. Vị trí đặt cái bảng này cũng phải đặc biệt, để các thành viên của team có thể ... đứng hoặc ngồi xung quanh. Có thể chọn loại bảng có ... chân để dễ dàng di chuyển khi cần "họp kín". Có bảng thì phải có bút viết bảng, càng nhiều màu càng tốt.

Thật nhiều giấy dán (giấy note) nhiều màu và sổ sách cho các thành viên ghi chép (nếu cần).

Một bộ bài poker-planning đặc biệt với các quân bài được đánh số từ 0, 1, 2, 3, 5, 8, 13, 20... (dãy số fibonaci) được sản xuất riêng cho cho scrum-team để thực hiện ước lượng công việc. Nếu không mua được bộ bài này, thì có thể tự in và dán số vào các bộ bài thông thường.

Một số "đồ chơi", sticker vui nhộn để chơi trò chơi, để ghi nhớ,....

Quán triệt tư tưởng chung.

Điều khó khăn nhất khi bắt đầu một team mới theo kiểu phát triển phần mềm nào cũng là "tư tưởng". Mỗi người trong team là một cá thể riêng...và "mỗi người một ý", làm thế nào để phần lớn mọi người sẽ có chung một góc nhìn với những sản phẩm, công việc sắp diễn ra. Trong Scrum, có 5 giá trị mà các thành viên trong team cần quán triệt với nhau để cùng phát triển.

Dũng cảm

Để một người dám nói ra vấn đề của mình và chấp nhận rất nhiều loại rủi ro khi thay đổi cam kết, họ cần là người dũng cảm.

Về cơ bản, những giá trị khác không thể có nếu bạn không có sự dũng cảm.

Tập trung

Mọi người cần tập trung vào công việc trong Sprint và Mục tiêu Sprint của nhóm.

Khi nhóm phát triển **đã cam kết **với những việc trong Sprint , họ cần phải tập trung để hoàn thành những gì mà mình đã cam kết.

Cam kết

Mỗi thành viên cam kết với các thanh viên khác về những điều mình làm và công việc đã được chọn ở buổi Lập kế Hoạch Sprint.

Ngoài ra chúng ta liên tục cải tiến tức là thay đổi để trở thành một các nhân tốt hơn, nhóm tốt hơn và tổ chức tốt hơn. Muốn cải tiến thì cần thay đổi mà thực hiện thay đổi bao giờ cũng rất khó khăn. Do đó chỉ với sự cam kết chung ta mới có thể làm được những việc tốt hơn.

Cởi mở

Mọi thứ cần phải rõ ràng, minh bạch để mọi người có thể làm việc hiệu quả.

Phát triển phần mềm rất phức tạp, một người không thể nhìn và hiểu được hết tất cả nhiều mọi vấn đề.

Do đó nếu mọi người không cởi mở với nhau, thông tin bị che giấu rất nhiều và hiệu quả công việc khó lòng nâng cao

Tôn trọng

Khi thiếu tôn trọng, mọi người khó thành thật trong chia sẻ.

Ví dụ một người không biết một điều gì đó, khi hỏi người khác. Người trả lời thay vì mong muốn giúp đỡ để người hỏi trở nên tốt hơn, độc lập hơn lại phàn nàn, đánh giá người hỏi (với người thứ 3 hoặc ngay trước mặt người hỏi) thì dù có được giúp đỡ thật nhưng lần sau người hỏi sẽ khó mà cởi mở và nói sự thật được. Không tôn trọng, khó có sự cởi mở

Nhận lời mời từ một người bạn "cùng phòng" về việc viết bài theo sự kiện MayFest. Cũng không biết viết gì nhiều nên tôi sẽ chia sẻ một số kinh nghiệm bản thân trong việc triển khai scrumt team. Hy vọng, các bạn mới tiếp xúc với scrum sẽ biết cần bắt đầu từ đâu.