NHỮNG VẤN ĐỀ KHI ÁP DỤNG SCRUM Ở VIỆT NAM

1 Hãy để water fall trong theo dòng thác.

Khi chuyển từ watter fall sang scrum là một vấn đề lớn vì hầu như những điều chúng ta biết trong watter fall được chúng ta chấp nhận như chuyện hiển nhiên. Scrum thoáng nghe qua có những thứ gần như trái ngược với những gì chúng ta từng biết. Chẳng hạn như:

Water fall	Scrum
Tài liệu thiết kế rõ ràng càng rõ càng tốt	Tài liệu cần thiết đủ để implement
Làm từng khâu (Phân tích, thiết kế, Implement … ) cần theo tuần tự rõ ràng. Mõi giai đoạn được cần có những tài liệu rõ ràng để lưu lại.	Chỉ lấy một chức năng (story card) một nhóm team cần làm. Sau đó cùng nhau chơi tất cả các giai đoạn này (Phân tích, thiết kế...)

Bạn đã thấy ví dụ trên. Nó đã thể hiện sự khác nhau rõ ràng. Những kiến thức về watter fall và quá hoàn hảo thế bây giờ chuyển đổi qua Scrum với quan điểm mới là chuyện hoàn toàn khó làm và khó triển khai.

1.1 Tài liệu phát triển như thế nào.

Để cần biết chúng ta nên viết tài liệu trong scrum được ghi đến mức nào chúng ta nên cần biết chúng ta viết tài liệu để làm gì?

Water Fall	Scrum
Dùng để report cho khách hàng	Dùng để report cho khách hàng
Dùng để đảm bảo các giai đoạn cần khóp để có thể gắn với nhau được	Dùng để note lại gợi nhớ sau này về chức năng.

Như vậy chúng ta đã thấy rằng Tài liệu dùng để trao đổi thông thông tin qua các giai đoạn Design → Implement …

Vì Water Fall, các giai đoạn tách rời nhau nên tài liệu cần rõ ràng để các giai đoạn đảm bảo khóp nhau.

Còn Scrum các giai đoạn cùng làm một lúc, thành viên trong team thường xuyên trao đổi nhau và đi đến hoàn thành task. Vậy tài liệu chỉ cần đủ ghi chú lại để gợi nhớ sau này. Không có giá trị trong giai đoạn làm ra sản phẩm nhiều.

1.2 Quan niệm từng giai đoạn và chờ đợi.

Như bạn biết đấy trong watter fall khâu này xong rồi đến khâu kia. Nếu đến khâu của mình, phát hiện vấn đề phải chuyển về khâu trước để thiết kế lại dẫn đến tốn thời gian và gặp nhiều phiền phức.

Scrum được cái là mọi người ngồi gần nhau có gì hỏi nhau liền. 2 yếu tố quan trọng cùng làm trong scrum là: Cùng làm chung một task và trao đổi nhau liên tục. Nhưng thực tế có bao nhiêu công ty làm được điều này? Vấn đề ở đâu?

Vấn đề là:

• Trong qui trình làm phần mềm phần lớn được chuyên môn hóa rất nhiều ví dụ: Graphic, Developer... Để một người có thể làm được tất cả là vấn đề lớn và độ chuyên sâu không có. Nên các công ty thường làm theo dạng cuốn chiếu (cho một sprint làm Graphic và một sprint Implement chức năng này – Cách này vô tình đã chuyển chúng ta qua watter fall – Chúng ta đã nghĩ nó nhanh nhưng thưc tế nó không nhanh như chúng ta tưởng).
• Có vài khâu bị chậm trể so với khâu khác vì task này cần nhiều hơn task kia. Ví dụ tôi đang làm game. Vẽ art và graphic cực kỳ lâu. Hơn so với implement. Vậy nếu làm chung thì developer phải ngồi chơi chờ art ah? Oh không.Chúng ta cần tăng resource art để tương xứng để đảm bảo đi chung luồng với developer.

2 Không tìm cách cải tiến estimate.

Tất cả các dự án nếu bạn làm đúng kết hoạch bạn đã thành công lớn rồi. Nhưng với Scrum lúc đầu nó không cần bạn phải đúng. Chính vì thế vô tình chúng ta thiết lập cho bản thân chúng ta một cơ hội không cần đảm bảo về thời gian như chúng ta nói.

Đây phần nhiều là vấn đề tâm lý. Tôi ví dụ: Trong water fall thời gian của bạn được PM set rồi hỏi bạn và ép bạn làm đúng hạn. Nhưng trong Scrum là bạn quyết định thời gian và chịu trách nhiệm với Product Owner.

- Khi bạn được hỏi “Em vẽ màn hình này chừng nào em xong?”. Bạn rất là đắng đo vài áp lực trách nhiệm được đổ dồn lên bạn đúng hong?

- Thông thường bạn trả lời “Em chưa biết nữa để em trong đó có gì rồi nói anh sau”. Để estimate Scrum Master nói “Em cứ cho anh thời gian đại đi, không cần phải chính xác 100% đâu”.

- Thế là bạn cho anh trả một estimate mà bạn không hề có trách nhiệm gì với nó cả

Đó là phần lớn những nguyên nhân dẫn đến estimate sai. Làm như thế bạn đã vô tình làm cho bạn nhiều lý do để fail hơn (Ngoại trừ task không rõ ràng hoặc gặp khó khăn về kỹ thuật).

3 Chưa xác định kết quả công việc

Khi bạn nhận một task bạn nên biết được bạn phải trả về cái gì cho người ta. Bạn với PO phải thỏa thuận và làm rõ kết quả đó. (Thông thường bạn phải chủ động cho PO thấy kết quả mà họ muốn vì phần lớn là các PO không được không minh và họ thường nói những thứ mà họ không biết họ muốn nói gì).
Bạn cần tìm đủ mọi cách để lấy requirement rõ ràng để bạn không bại reject sau này.

4 Không đủ kiến thức về Scrum

4.1 Chưa rõ tác dụng của các cuộc hợp

Scrum là một khung làm việc chứa các cuộc hợp. Nếu thành viên trong nhóm của bạn không hiểu rõ về những cuộc hợp này thì nó là vô ích. Những lý do là:

• Scrum master chưa truyền được tầm quan trọng các cuộc hợp. Nếu có thì tổ chức các cuộc hợp chưa được hiệu quả như lý thuyết → thành viên trong nhóm ngày càng nãn.
  
• Tư tưởng của team về Water fall vẫn còn ăn quá sâu.
  

4.2 Kỹ năng giao tiếp chưa tốt

Communication là một kỹ năng quan trọng trong Scrum. Nhưng phần lớn chúng ta không được tốt về skill này dẫn đến nó không được tốt. (vì thế chúng ta thích water fall hơn).

4.3 Giới hạn về kỹ thuật

Như chúng ta có những giới hạn về kỹ thuật mỗi người chỉ cần biết một lĩnh vực của mình thôi → Chúng ta phải làm cuốn chiếu như đã đề cập ở trên.