Bạn có nên nghỉ việc không?

Scrum - Những vấn đề trong các cuộc hợp

Scrum là khung làm việc chứa những cuộc hợp. Nếu chúng ta làm không đúng vô tình làm cho khung làm việc này nặng nề và lãng phí thời gian. Nhân viên của bạn cũng dần mất lòng tin và qui trình làm việc này.

Như các bạn đã biết. Hầu hết các cuộc hợp điều dưới sự dám sát của scrum master. Người chịu trách nhiệm đào tạo scrum cho các thành viên trong team. Nếu có vấn đề ở đây là do scrum master chưa tốt.

Sau đây là những vấn đề mà team tôi thường mắc lỗi khi triển khai.

1. Cuộc hợp làm mịn product backlog.

• Bỏ qua: Thường bị coi thường và bỏ qua. Đây là cuộc hợp tốn nhiều thời gian và có nhiều tranh cãi phần lớn rất ngại tham gia cuộc hợp này. Cuộc hợp này giúp làm rõ requirement hơn cho product owner.
• Phản bác chứ không phải góp ý: Team thường phản bác requirement thay vì góp ý cho requirement nó tốt hơn. Cần phát huy tin thần góp phần giúp đỡ người ra quyết định.

2. Cuộc hợp sprint planing.

• Nội dung story card không rõ ràng: đây là một nguyên nhân chính làm cho qui trình scrum thất bại. Tên của story card cần được đặc tên một cách rõ ràng để người dùng đọc và tiêu đề là dễ dàng hiểu mà không phải đọc vào nội dung bên trong của story card. Thêm phần vào đó là các thành viện không đi đến mức cuối cùng để làm rõ và đảm bảo những thành viên điều hiểu chung về nó. Nên cố gắn áp dụng một số kỹ thuật như lá bài (poker) khi tiến hành sprint planing.
• Estimate time: Các thành viên không dám đặt thách thức cho mình về thời gian hoàn thành công việc. Thông thường bạn sẽ bị ép phải trả lời những câu hỏi về thời gian hoàn thành. Tôi chưa có ý giải pháp nào tốt hơn ngoài việc khuyên các thành viện của mình tự thách thức mình về thời gian.
• Mọi người không hiểu chung về story card: Thật là khó để biết người nào có hiểu giống mình hong? Kỹ thuật poker có thể cho bạn biết người đó có chùng suy nghỉ với bạn hong. Tuy nhiên nó cũng có giới hạn khá lớn với những người không có cùng kiến thức kỹ thuật.

3. Cuộc hợp Daily Scrum.

• Thời gian của daily scrum: Phần lớn các cuộc hợp daily scrum điều chưa được đảm bảo đúng thời gian kết thúc. Phần lớn chúng ta không tôn trọng được 3 câu hỏi:
  • Hôm qua bạn làm gì?
  • Hôm nay bạn sẽ làm gì?
  • Bạn có gặp khó khăn gì hong?

(Scrum master sẽ giải quyết nó sau cuộc hợp daily scrum).

• Bàn luận theo cảm hứng: Phần lớn chúng ta bị thối quen nói ngay những gì chúng ta đang nghĩ. Chúng ta thường bị đan xen những cuộc bình luận không liên quan đến những thành viên khác trong nhóm. Tốn thời gian không cần thiết.
• Không chuẩn bị mình nói gì trong scrum: Cần ghi vào những tời note những gì mà chúng ta muốn nói để khi nói chuyện chúng ta dễ dàng nói chuyện một cách nhanh chóng.

4. Cuộc hợp Sprint Retrospective.

• Đi trễ: Vì cuộc hợp này phần lớn được tổ chức tại các quán cafe nên phần lớn chúng ta hay không tôn trọng thời gian. Thường đi trễ không tôn trọng các thành viên khác.
• Nêu quá nhiều vấn đề: Chúng ta chỉ nên nêu những vấn đề lớn mà chúng ta ấn tượng không nên nêu quá nhiều rồi sau đó quên hết không improve thì cũng không có tác dụng gì.
• Improve không được quản lý: Chúng ta thường nói sẽ improve nhưng chúng ta lại không quản lý nó. Dẫn đến nói mà không làm. Retrospective không phát qui tác dụng

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.