Có một bạn Software Engineer (SE) hỏi tôi rằng “Agile/Scrum giúp được gì cho công việc của chúng tôi? Agile/Scrum có gì nổi trội hơn các phương pháp phát triển phần mềm khác và giúp chúng tôi làm việc hiệu quả hơn không? Agile/Scrum có giảm khối lượng công việc re-work do bug hoặc thay đổi yêu cầu?”. Đây là những câu hỏi thú vị. Tôi không vội trả lời thay vào đó tôi hỏi để làm rõ câu hỏi cuối:
(Hình ảnh từ khoá đào tạo Agile Project Management ở Apex Global)
- Theo bạn nguyên nhân re-work ở dự án bạn tham gia đến từ đâu?
- SE: Người cung cấp yêu cầu thường không hiểu yêu cầu nghiệp vụ và khi họ nhìn thấy phần mềm thì cứ yêu cầu thay đổi.
- Người cung cấp yêu câu cho đội của bạn là ai?
- SE: Là Business Analyst
- Đội của bạn có hỏi rõ yêu cầu đó mang lại giá trị gì cho khách hàng?
- SE: Đó không phải là việc của đội kỹ thuật
- Bạn và đội của bạn thật nhẫn tâm. Đội của bạn là người trực tiếp sản xuất phần mềm, là người trực tiếp tạo ra giá trị cho khách hàng. Đội của bạn không hiểu rõ giá trị mà bạn cung cấp cho khách hàng thì liệu những gì bạn cung cấp làm thoả mãn khách hàng?
- …SE có một chút bối rối trước câu hỏi của tôi.
- SE: Anh nói đúng, em cũng thấy nhẫn tâm thật. Mà nhiều khi tụi em cũng không quan tâm đến khách hàng trải nghiệm như thế nào trên sản phẩm của tụi em làm ra.
- Đó là vấn đề, sự re-work có thể đến từ yêu cầu thật sự của khách hàng (thường là thay đổi yêu cầu rất giá trị), re-work đến từ khả năng yếu kém của Business Analyst, và re-work đến từ chính đội kỹ thuật đã nhắm mắt để chấp nhận phát triển sản phẩm trên các yêu cầu không rõ ràng, các yêu cầu không mang lại giá trị cho khách hàng. Điều gì xảy ra khi 4 năm làm việc của em ở cty này mà em không hiểu rõ kiến thức domain em đang làm?
- SE: Chắc em chỉ là thằng code dạo.
- Uh, ý tưởng rất hay và anh đã nghe nhiều bạn cũng nói như vậy.
Bài viết liên quan: “Vai trò đội phát triển (Development team) trong dự án Agile”
Đây là một đoạn hội thoại ở một quán café với một bạn Software Engineer nhờ tôi giới thiệu khái quát về Agile/Scrum. Sau một hồi khơi gợi thì cũng giúp cậu ấy hiểu ra được nội tại của vấn đề và lý do tại sao đội của anh ta cần một phương pháp phát triển phần mềm hiệu quả hơn.
Phương pháp phát triển sản phẩm nhanh (Agile) và đặc biệt Scrum Framework đưa ra cách hướng dẫn thực hành rất hiệu quả. Nhưng để thực hành thành công với Agile/Scrum là một thách thức lớn. Bởi lẽ, Scrum đưa ra hướng dẫn cô đọng các công cụ, sự kiện, và vai trò, nhưng đằng sau sự cô đọng ấy là những nguyên lý làm việc nhóm theo trường phái Leadership. Scrum tập trung vào kết quả nhiều hơn quá trình như phương pháp phát triển phần mềm truyền thống. Scrum rất chặt chẽ đến nổi khắc nghiệt, chỉ cần bạn bỏ qua một vài bước thì mội thứ rối cả lên, hoặc chỉ cần hiện ra 1 bug ở thời điểm review thì xem như sprint đã thất bại. Và bạn sở hữu ngay một SCRUM-BUT.
Bài viết liên quan: “Viết User Story cho Lỗi (Bug) trong dự án Agile”
Nếu đội dự án của bạn áp dụng đúng hướng dẫn của Scrum thì bản thân mỗi thành viên của đội kỹ thuật sẽ nhận được những giá trị cho bản thân như:
- Bạn có cơ hội tương tác trực tiếp với khách hàng, lắng nghe trăn trở của họ trong công việc và kỳ vọng đạt được thông qua hệ thống. Bạn có cơ hội nâng cao kỹ năng giao tiếp với các đối tượng khách hàng, người trả tiền cho ý tưởng và sản phẩm của bạn.
- Bạn có cơ hội sáng tạo bằng cách tư vấn hướng giải quyết cho từng yêu cầu, thay vì làm việc như một cái máy để rồi sau vài năm không tích luỹ được nhiều kinh nghiệm.
- Bạn có cơ hội được học từ những người expert trong team. Mỗi sprint có sprint goals, chính là mục tiêu chung của cả team, điều này thúc ép các expert chia sẻ và hướng dẫn thành viên khác để cả team cùng hướng đến sprint goals.
- Bạn có cơ hội được tương tác face-to-face với các thành viên khác để gia tăng sự tin tưởng lẫn nhau, phối hợp cùng nhau như là một đội cùng một vai trò Development team, thay vì chăm chăm vào các tài liệu vô cảm.
- Bạn có cơ hội loại bỏ code dư thừa bởi lẽ team sẽ không cho phép bạn có cơ hội làm điều đó. Nhưng điều kiện, team của bạn thực hành được tự quản (self-organizing).
- Bạn có cơ hội chọn lựa task (thay vì bị ông sếp gán task). Người làm kỹ thuật ghét nhất ái đó ép nhận việc.
- Được sống trong một môi trường vui vẻ, tập trung vào công việc chính, được tôn trọng, và quan trọng hơn là được các thành viên khác trong team thúc đẩy sự can đảm để trải nghiệm những task khó.
- Khi bạn gặp trở ngại thì cả đội sẽ nhảy vào hỗ trợ bạn. Bạn được sống trong môi trường làm việc công bằng, cả team cùng làm với nhau, thay vì người làm, người ngồi chơi như thường có.
- Được thừa nhận kết quả ngay ở cuối sprint nếu team hoàn thành sprint goals. Có những quy tắc để ép Product Owner thừa nhận kết quả của team. Và Scrum Master sẽ thực thi quyền đó.
- Bạn có cơ hội nói lên chính kiến của mình ở sự kiện Restrospective. Bạn có cơ hội đưa ra những ý tưởng cải tiến để việc tương tác được hiệu quả hơn.
Bài viết liên quan: “Nguyên lý của Agile và sự thành công của phát triển phần mềm”
(Hình ảnh từ khoá đào tạo Agile Project Management ở Apex Global)
Là một người làm kỹ thuật, bạn có thể thấy có nhiều giá trị mà bạn có thể nhận được thông qua dự án triển khai theo Agile/Scrum. Nhưng những giá trị ấy chỉ tạo ra khi bạn áp dụng Scrum đúng cách, và được hướng dẫn thực hành làm việc nhóm hiệu quả. Bạn thử dùng những giá trị này để soi lại cách áp dụng Agile/Scrum trong dự án của mình, nếu dự án của bạn chỉ đạt được khoảng 50% các giá trị đó thì tôi xin chúc mừng bạn. Dự án của bạn có thể đang áp dụng SCRUM-BUT hoặc đó chỉ là cách quản lý linh hoạt.
***
Đây là series bài viết về chủ đề về “Ứng dụng Agile trong doanh nghiệp” bạn có thể đọc các phần của bài viết:
- Phần 1: “Thực trạng ứng dụng Agile trong doanh nghiệp”
- Phần 2: “Khách hàng kỳ vọng điều gì từ dự án Agile?”
- Và đón phần 4 với chủ đề “Tại sao lãnh đạo đặt mục tiêu đưa Agile vào doanh nghiệp?”
***
By Cao Trần,
Bài viết chia sẻ trên tường facebook của tác giả ở link