Hẳn các bạn giờ cũng không xa lạ gì với Agile, Scrum hay phương pháp phát triển phần mềm linh hoạt. Tuyên ngôn của Agile như sau:
Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện.
Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:Cá nhân và sự tương tác hơn là quy trình và công cụ;
Phần mềm chạy tốt hơn là tài liệu đầy đủ;
Cộng tác với khách hàng hơn là đàm phán hợp đồng;
Phản hồi với các thay đổi hơn là bám sát kế hoạch.Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái.
Thực tế đi làm ở các công ty phần mềm hiện nay, cá nhân mình thấy việc học, áp dụng, hiểu và thực tế diễn ra thì khác nhau kha khá, thậm chí còn đi ngược lại với tuyên ngôn của Agile ngay trong những công ty áp dụng nó.
- Cá nhân và sự tương tác hơn là quy trình và công cụ
Thực tế môi trường với toàn người trẻ thì sự tương tác 1 cách chủ động là cần thiết và cũng không quá gặp khó khăn. Nhưng hầu hết các công ty khi đã lớn 1 chút (quy mô tầm >100 người) sẽ thường có nhiều các quy trình quản lý gắt gao, sát sao; các công cụ đánh giá, theo dõi nhân viên 1 cách máy móc nhiều hơn. Lý do thì nhiều, nhưng theo ý kiến chủ quan của mình thì do nhân sự thiếu sự chủ động và tự giác 1 cách cần thiết, và đôi khi sự tương tác cũng chỉ diễn ra khi dự án, team đang chạy tốt. Cứ có vấn đề chút là lại đòi theo quy trình, xem log, check tool.
Đi làm thì bạn chẳng xa lạ với việc đổ lỗi cho Bug này của ai, ai code lỗi, hay tester test không ra bug. Khi bug vẫn còn trong chăn thì sự tương tác giữa các dev, hay giữa dev và tester thường nhẹ nhàng là anh fix đi em test lại cho. Chứ khi bug đã rơi vào tay khách hàng hay PO, PM, quản lý, … thì đó lại là chuyện khác. Rồi tại sao không làm theo quy trình, sao lại lọt bug, sao lại không làm cái này làm cái kia nó luôn được đặt ra, giải quyết thì lại based trên quy trình. Rốt cuộc thì đầu tư vào quy trình, tool thì vẫn dễ làm việc, rõ ràng hơn so với cái gọi là cá nhân và sự tương tác.
Tất nhiên tùy tính chất của dự án, của khách hàng, của công ty (product hay outsourcing) mà cũng khác nhau tương đối. Cũng có nhiều khách hàng chấp nhận những sai sót kiểu như vậy, đúng với mô hình lí tưởng của Agile; nhưng đó không phải là số đông và cũng không lặp lại nhiều lần. Bạn cứ thử re-open cái bug khoảng 3 lần xem có ai chấp nhận được không? Lúc đó thằng trong team nó cũng nhìn bạn với đôi mắt khinh thường chứ ngồi đó mà tương tác nhé.
- Phần mềm chạy tốt hơn là tài liệu đầy đủ
Cái này thì tất nhiên, nó khá là đúng ở bất kỳ hoàn cảnh nào. Nhưng tài liệu đầy đủ là 1 khái niệm tương đối bị xem là tiêu cực. Đầy đủ không phải là dư thừa, ý ở đây nếu dùng từ tài liệu vừa đủ thì chắc là mang tính tích cực hơn. Tài liệu luôn luôn quan trọng, nhất là giờ anh em nhân sự nhảy việc như thay người yêu, có mấy ai chung tình đâu. Rồi mấy anh em mới vào ngơ ngác nhìn 1 cái hệ thống đang chạy mà không hề có 1 dòng giải thích nào ngoài code. Đọc code thì cũng được đấy, test khám phá thì cũng ổn đấy, nhưng thời gian không cho phép các bạn ngồi đấy mà thẩm thấu dần.
Phần mềm chạy tốt thì đương nhiên, nhưng không có nghĩa là nó không có lỗi, không tiềm ẩn những vấn đề có thể gặp phải trong tương lai. Đội ngũ phát triển đi trước để lại cho chúng ta 1 số lượng bug tiềm ẩn mà nếu bạn phải đi tìm hiểu từ đầu thì quá cực, thế nên đừng trách có 1 số tài liệu dư thừa đối với nhiều người nhưng quan trọng với những cái đầu có sạn.
Ví dụ mình từng gặp phải: Hồi đó team mình gặp phải 1 lỗi trên 1 thiết bị Android của khách hàng. Khó ở chỗ là chỉ nhận được log về, chứ máy thì mình không có (có thông tin thiết bị nhưng tái hiện trên đúng con đó không được nhé). Và rồi 1 ngày đẹp trời thì lục trong đống issues closed trên redmine (hồi đó chưa có dùng jira hay tool agile nào đâu) thì có 1 issue bug với log lỗi tương tự, được đóng vì thiết bị dùng room cook (nói nôm na là đã can thiệp vào room của thiết bị Android). Đấy thế là vấn đề dần dần được giải quyết, nhưng tại sao không có 1 dòng note, ghi chú, hay ngon lành hơn là tài liệu nào mô tả lại cái lỗi trên. Chẳng phải là phần mềm vẫn chạy tốt mà khách thì vẫn khó chịu đấy thôi.
- Cộng tác với khách hàng và phản hồi với các thay đổi hơn là đàm phán hợp đồng và bám sát kế hoạch
2 điều này mình gộp chung luôn vì nó thể hiện sự hợp tác với khách hàng. Thực tế các công ty outsourcing thì việc được nói chuyện với khách hàng cũng là cả 1 vấn đề. Bất đồng ngôn ngữ, thời gian cũng chả có, cứ based trên requirements rồi anh em tự làm là chính thôi. Việc chiều khách như chiều vong cũng là 1 cách để Công ty, các sếp sinh tồn; cộng tác với khách nhưng vẫn là khách thôi; mấy khi khách nghe anh em Dev, Tester nói đâu.
Tâm lí chung của anh em Dev, Tester cũng dần dần làm theo hướng đối phó, làm cho xong; xem đấy cũng chả phải sản phẩm của mình; vài tháng chán mình lại nhảy việc mà. Thành ra bảo cộng tác rồi phản hồi thay đổi như 1 cực hình, OT triền miên để đối ứng với thay đổi, khách có tiền nói gì mà chả được; anh em chỉ biết câm nín ngồi làm và chửi khách, chửi brSE, chửi sếp cho sướng mồm thôi.
- Kết
Agile tất nhiên hiệu quả hơn so với phương pháp truyền thống, cái này mình không bàn cãi. Nhưng thực tế ở rất nhiều Công ty mình trải qua cho thấy việc làm Agile mà chỉ là theo Agile chứ chưa hiểu Agile khiến anh em Dev, Tester rất mệt mỏi. Anh em cũng cần có sự thay đổi thích ứng với các quy trình mà từng Công ty đặt ra, mỗi nơi 1 văn hóa làm việc khác nhau, xét cho cùng vẫn đang cần sự thay đổi từ trên bộ máy làm việc trực tiếp với khách hàng nữa.
Cảm ơn mọi người đã đọc
From Anyway with Love!
Bình luận