Trong lĩnh vực phát triển công nghệ phần mềm, việc thay đổi, áp dụng và cải tiến quy trình là một điều thiết yếu. Chính vì vậy, những ai làm việc trong lĩnh vực này cũng cần trang bị cho mĩnh kĩ năng thích nghi môi trường mới. Người phân tích nghiệp vụ (Business Analyst – BA) chắc chắn không phải là ngoại lệ.
1. Khái niệm
- Mô hình Agile Software Development là một phương pháp phát triển phần mềm linh hoạt và thực hành dựa trên các giá trị và các nguyên lý được nêu ra trong tuyên ngôn Agile. Nó là quá trình làm việc tương tác và tích hợp, thúc đẩy sự lặp đi lặp lại trong suốt vòng đời phát triển phần mềm của dự án, nhằm đưa sản phẩm đến tay người dùng càng nhanh càng tốt.
- Mô hình Waterfall (Mô hình thác nước) là một mô hình cổ điển được sử dụng trong suốt vòng đời phát triển hệ thống (SDLC). Nó được gọi là thác nước vì mô hình này được áp dụng theo tính tuần tự từ giai đoạn này sang giai đoạn khác và không được quay lại giai đoạn trước để xử lí các thay đổi trong yêu cầu. Hay nói cách khác, mỗi giai đoạn cần phải được hoàn thiện đầy đủ trước khi bước sang các giai đoạn tiếp theo.
2. So sánh Agile và Waterfall
Giống nhau
Cả hai phương pháp này dùng cho quy trình phát triển phần mềm khác nhau. Mặc dù chúng khác nhau trong cách tiếp cận, nhưng cả hai phương pháp đều hữu ích, tùy thuộc vào yêu cầu và loại dự án.
Khác nhau
Waterfall | Agile |
|---|---|
|
|
|
|
|
|
Để chuyển đổi từ mô hình Waterfall sang mô hình Agile thì liên quan đến việc thay đổi tư duy để có thể thích nghi với môi trường làm việc mới này.
Đi sâu hơn về Agile, bạn cần nắm vững 4 giá trị cốt lõi sau của Agile:
Bốn giá trị cốt lõi của Agile
- Individuals and interactions over processes and tools. Tạm dịch là nỗ lực làm việc của các thành viên trong đội dự án và sự hỗ trợ lẫn nhau tốt hơn các quy trình và công cụ kiểm soát.
- Working software over comprehensive documentation. Phần mềm chạy tốt hơn là tài liệu đầy đủ, nhằm đảm bảo sau khi hoàn thành dự án thì phần mềm sẽ đáp ứng được nhu cầu của khách hàng.
- Customer collaboration over contract negotiation. Tạm dịch là việc khách hàng tương tác sẽ tốt hơn là việc đàm phán dựa trên nội dung hợp đồng. Vì vậy, cần phải nắm được các nhu cầu của khách hàng để tư vấn và điều chỉnh kế hoạch thay vì chỉ dựa vào các điều khoản có trên hợp đồng.
- Responding to change over following a plan. Tạm dịch là thích nghi trước sự thay đổi tốt hơn là thực hiện theo kế hoạch đã đề ra, khuyến khích thích nghi với các sự thay đổi như là thay đổi về công nghệ, nhân sự, deadline,….
3. Quy trình Agile
Có nhiều phương pháp Agile khác nhau, ở bài viết này là dựa trên “Scrum” – đây là một phương pháp được dùng rộng rãi nhất trong Agile. Mỗi lần lặp lại của Scrum còn được gọi là Sprint (vòng lặp).
Bài viết này chỉ ra sự khác nhau về những gì BA (chuyên viên phân tích) mong đợi trong môi trường agile-driven so với môi trường truyền thống, đặc biệt là những BA phải thay đổi một cách đột ngột hoặc cho những BA mới bước vào làm việc.
4. Các yếu tố BA cần có khi làm việc trong môi trường Agile
4.1. Sự tương tác trực tiếp với nhiều người dùng cuối và Product Owner
Với các phương pháp truyền thống, BA được mong đợi và khuyến khích tương tác với các bên liên quan từ nhiều lĩnh vực khác nhau. Như các Scrum xác định, không có vai trò của “Business Analyst” trong Scrum, chỉ có Product Owner (PO: chủ sở hữu sản phẩm), Scrum Master, và Development Team (đội ngũ phát triển).
Bạn cũng có thể đọc thêm về Scrum Guide tại đây
Vậy, tại sao BA có mặt và cần có trong Scrum Team?
- Thực tế, PO đôi khi không đủ “chuyên môn” của mỗi nhóm người dùng, đặc biệt là khi sản phẩm cuối cùng được mong đợi sẽ phục vụ cho lượng lớn và đa dạng cơ sở người dùng. Do đó, BA có thể cần có trong các nhóm scrum để liên lạc với các bên liên quan để làm rõ về các yêu cầu vượt quá chuyên môn hoặc năng lực của PO. Trường hợp PO không có để theo dõi chi tiết các nhu cầu này, BA có thể hỗ trợ quy trình này và tăng tốc độ phát triển của user stories, thay vì phải tìm một người khác vào vị trí PO.
- Tùy vào phạm vi phát triển của dự án, càng nhiều stakeholders (các bên liên quan) sẽ cần có nhiều BA hơn để tương tác với nhau. Ngoài ra cần phải khơi gợi các yêu cầu cũng như bản thiết kế mẫu (mockups) để làm rõ các user stories. Suy cho cùng, BA đóng một vai trò quan trọng trong Scrum Team để hỗ trợ cho PO, hơn thế nữa BA có thể đứng ra làm đại diện cho PO.
4.2. Từ Tài liệu đặc tả yêu cầu (RSDs) đến những việc cần làm (Product Backlog)
RSDs có công trong vòng đời phát triển phần mềm truyền thống, các tài liệu này thường dài và mô tả chi tiết. RSD thường chứa các danh sách câu lệnh “Hệ thống sẽ…” để đặc tả các yêu cầu cụ thể trước khi bàn giao cho Development team, nhằm đảm bảo công việc được thực hiện theo đúng tiến độ.
Các yêu cầu trong RSD có thể được viết dưới hình thức “user stories”, nhưng các user stories trong Product Backlog thì không cần thiết phải chi tiết như trong RSD, chỉ cần xây dựng các user stories mà nó cần cho các sprint tiếp theo.
4.3. Các cập nhật trạng thái đến các cuộc họp hàng ngày (Daily Stand-up)
Ở mô hình Waterfall, các công việc được cập nhật hàng tuần, hàng tháng cho các cấp quản lý trực tiếp (điều này thì tùy thuộc vào mô hình của các doanh nghiệp).
Trong khi đó, Scrum có thể thực hiện các cuộc họp hằng ngày. Mục tiêu của việc này cơ bản là như là: Hôm qua đã làm được những gì? Hôm nay phải hoàn thành những gì? Các trở ngại khi làm việc? …
4.4. Từ các Tasks (nhiệm vụ) thành Epics (Hạng mục công việc), Features (Tính năng), Stories và Sub-Tasks (Nhiệm vụ phụ)
- Với cách tiếp cận truyền thống (Waterfall), các công việc khơi gợi yêu cầu như là: phỏng vấn và các cuộc hội thảo để khảo sát lấy ý kiến sẽ được thể hiện như một chuỗi các nhiệm vụ hoặc các hoạt động mà BA phải thực hiện với mục đích xác định các yêu cầu, đây cũng như là một phần của kế hoạch dự án.
- Với Scrum, những công việc này không chỉ là quản lý những việc phải làm cho riêng BA, mà nó cần được liên kết với Epic để đạt được các mục tiêu chạy nước rút (sprint goal). Epic là những hạng mục công việc rất lớn để mang lại giá trị cho khách hàng, điều này cho thấy các epic sẽ ít có khả năng hoàn thành khi thực hiện sprint chỉ một lần.
5. Tổng kết
Tóm lại, không phải công ty chọn triển khai nhanh hay chậm thì xác định được sự thành công, mà đó còn là khả năng xác định cách làm việc giữa sự nhanh nhẹn và tính nghiêm khắc để đạt được lợi ích cho các bên liên quan. Về việc thay đổi tư duy, thì nó rất quan trọng đối với BA bởi vì nó liên quan đến các nguyên tắc chính trong Agile, nó là điểm khác biệt so với các nguyên tắc thông thường khác trong tổ chức truyền thống.
Đây là bài báo cáo tổng hợp dựa trên kết qủa cuộc khảo sát phân tích Phương pháp Agile từ các cá nhân và tổ chức đang làm việc trong môi trường Agile (năm 2019) của BA-Squard: Link tại đây. Bài báo cáo này sẽ cho bạn nhiều thông tin bổ ích liên quan đến tình hình áp dụng mô hình Agile trên thế giới hiện nay.
Hi vọng với bài viết ngắn được tổng hợp này từ BAC đã mang đến cho các bạn làm BA những thông tin bổ ích về môi trường làm việc Agile. Những yếu tố trên sẽ giúp bạn chuẩn bị tư thế và kiến thức trước khi bắt đầu vào một dự án phát triển phần mềm theo phương pháp Agile – Scrum.
Nguồn tham khảo:
https://www.projectmanager.com/waterfall-methodology
Nhu cầu đào tạo doanh nghiệp
BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.
CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN
Khoá học Online:
Khoá học Offline:
Tại Tp.HCM:
Tại Hà Nội:
Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.
Ban biên tập nội dung – BAC