SCRUM đơn giản cho công việc phức tạp (phần 1)

Hiện tại các công ty công nghệ thường áp dụng mô hình SCRUM cho quản lý dự án của họ. Nhiều team mới thành lập áp dụng mô hình này rồi gặp khó khăn trong thực hành đến mức phải rã team mà dự án vẫn không xong. Những việc trông thấy mà đau đớn lòng nên hôm nay mình một bài đơn giản để hỗ trợ áp dụng mô hình SCRUM một cách giản dị cho mọi team nhất là các team mới thành lập để có thể ra được sản phẩm chất lượng xác suất hoàn thành dự án cao mà mọi người vẫn vui vẻ không quạo.

Nếu làm việc lâu trong các công ty công nghệ thì các bạn sẽ thấy một mô hình như sau: Project Manager là người lo lên kế hoạch dự án, dự trù milestone và deadline. Người Project Manager này sẽ hỏi thăm các thành viên trong dự án về estimate thời gian họ có thể thực hiện các công việc trong dự án như thế nào để lên một lịch trình cụ thể rồi mọi người theo đó mà làm. Thật là đơn giản dễ hiểu biết bao.

Tuy nhiên, đời không như là mơ. Khi deliver cho khách hàng hay đưa sản phẩm ra thị trường, kết quả lại không như mong đợi hay khách hàng có những đòi hỏi trời đất chỉ có nước đập đi làm làm mới có thể chiều khách hàng. Lúc đó thì cả team khóc ròng rồi đập đi làm lại chứ biết sao bây giờ.

Nên mấy ông chuyên phát triển phần mềm thấy không ổn mới họp nhau lại để kiếm đường nào làm phần mềm khoẻ hơn mà dễ chiều khách hàng và thị trường hơn. Họp năm bảy lần gì đó thì mới ra Tuyên Ngôn Agile. Tuyên ngôn đó là gì mấy bạn search Google đọc đi chứ viết ra đây cũng lùng bùng lỗ tai mấy bạn cũng không nhớ nổi đâu. Sau đó thì mô hình SCRUM được phát triển như một cách triển khai của tuyên ngôn Agile. Chi tiết SCRUM thế nào thì mình không đi lý thuyết mấy bạn lên wikipedia mà đọc.

Thay vào đó ta sẽ đi vào những khó khăn thực tế hàng ngày trong công việc rồi từng bước hoá giải nó bằng các chiêu thức SCRUM.

Biết là các bạn Bussiness Analyst (chuyên thu thập nhu cầu khách hàng) cũng ăn dằm nằm dề ở công ty khách hàng để thu thập không xót nhu cầu nào. Nhưng mà dù cẩn thận kiểu nào thì cuối cùng cái bạn thường nghe ở khách hàng là

“Tao tưởng mày làm khác chứ, cái này đâu phải cái tao muốn…”

Thế là tức nổi điên muốn lật cái bàn. Nhưng mà bạn cũng phải hiểu cho khách hàng, họ chỉ biết những gì họ muốn cho đến khi họ thấy cái đó thôi. Thế thì phải làm sao? Cách đơn giản nhất là bàn giao cho khách hàng sớm sớm. Có gì bàn giao đó để khách hàng check coi có phải thứ họ muốn không. Đưa sớm, feedback sớm đỡ phải đập đi làm làm. Để làm được như vậy bạn phải có một chu kỳ làm việc thật ngắn, đưa ra được phần bàn giao thật nhỏ để nhận feedback của user thật sớm. Thì để giải quyết vấn đề đó. Trong khung mô hình SCRUM dùng khái niệm Sprint để mô tả chu kỳ làm việc đó.

Một cách thực dụng là một chu kỳ làm việc từ 2 tuần đến 1 tháng (dài hơn thì nó lại quay lại cách làm truyền thống có project manager rồi). Nên các bạn phải cắt giảm công việc sao đó để nó có thể hoàn thành trong 2 tuần đến 1 tháng thôi đừng dài quá. Best practice là 2 tuần.

Kết quả của 1 Sprint là 1 phần bàn giao được cho khách hàng. Khách hàng sẽ xem rồi feedback cho nhóm phát triển. Nhóm phát triển lúc đó dù có đập đi làm lại thì cũng chỉ là phần việc của 2 tuần, đỡ đau khổ hơn là làm 6 tháng xong mới có feedback rồi đập đi làm lại.

Problem solved!!! YEAHHHHHH

Gói chuyển giao nhỏ làm trong 2 tuần

Team bạn sau khi đã có lịch trình công việc cho 2 tuần rồi. đến ngày thứ 6 của tuần thứ 2 mới hỏi dev là build xong chưa, tại sao chưa build. Dev nói em có bug mà chưa nghĩ ra, giờ mọi người chờ em fix xong đi rồi mới build được. Đến lúc đó ông project manager mới nổi xung lên. “Anh hẹn với khách hàng rồi mà em lại trễ như vậy là chết anh”. Thế là cả team lục đục. Khổ không cơ chứ. Giá như…

Giá như anh dev đó gặp bí mà la lên liền thì hay biết mấy, có mấy anh senior dev lead ra tay cứu giúp ngay rồi. Chắc là cần một cuộc họp ngắn hàng ngày để mọi người nói ra khúc mắc để mà còn giải quyết chứ để lâu quá mới nói thì chết. Thế là mọi người đi đến thống nhất, mỗi ngày dành 15p để cập nhật tình hình của mọi người trong team. Thế là ai có khó khăn gì thì nói ra. Không phải là để tìm giải pháp trong lúc đó mà là để mọi người biết anh bị khó khăn để sau đó còn hỗ trợ. Không cần dài, dài lại không hay dễ gây mệt mỏi. Chỉ 15p mỗi ngày. Team tự họp nhẹ rồi chọn 1 khung giờ cố định để mọi người thuận tiện tham gia. Sáng sớm hay chiều tà không quan trọng. Chỉ cần 15p mỗi ngày là mọi nổi niềm được bày tỏ. Trong SCRUM thì người ta gọi là Daily Stand Up Meeting hay Daily SCRUM.

Đâu anh bị gí cái gì nói tui nghe

3 câu hỏi cần được trả lời trong Sprint:

1. Hôm qua anh làm được gì rồi?

2. Hôm nay anh định làm gì?

3. Anh có bị stuck chỗ nào không?

Trả lời nhanh gọn lẹ chứ họp có 15p rề rà quá là không nên. Thế là khỏi có việc bí mà không dám nói.

Problem solved!!! YEAHHHHHH

Sprint: một chu kì làm việc 2 tuần có phần bàn giao cho khách hàng ở cuối chu kì để giúp việc phản hồi từ khách hàng nhanh hơn.

Daily SCRUM: Trong Sprint, mỗi ngày dành 15p để nguyên team họp thông báo tiến độ.

Còn tiếp phần 2… Clap để được đọc sớm hơn.