PHẠM VI PHÂN TÍCH NGHIỆP VỤ
Nhà tài trợ thay đổi
Điều quan trọng là nhà tài trợ cho một sáng kiến Agile phải quen thuộc với triết lý, tư duy và cách tiếp cận linh hoạt, đồng thời cởi mở với những phản hồi liên tục sẽ đòi hỏi sự đánh đổi từ các bên liên quan.
Một nhà tài trợ Agile hiểu và chấp nhận:
- Sử dụng kế hoạch thích ứng thay vì lập kế hoạch dự đoán
- Việc sử dụng và giá trị của một khoảng thời gian cố định cho một chu trình làm việc
- Sự cần thiết và giá trị của sự tham gia của nhà tài trợ.
Sự tham gia tích cực của nhà tài trợ (hoặc SME được trao quyền) với nhóm Agile là rất quan trọng để cung cấp cho nhà tài trợ khả năng xem trước và hiểu sản phẩm đang được phát triển, cũng như tạo cơ hội cho nhà tài trợ cung cấp phản hồi liên tục cho nhóm và điều chỉnh sản phẩm khi nhu cầu thay đổi.
Mục tiêu và tác nhân thay đổi
Các phương pháp tiếp cận Agile sẽ thành công nhất khi văn hóa tổ chức và môi trường làm việc cho phép hợp tác chuyên sâu, giao tiếp thường xuyên và có khuynh hướng mạnh mẽ hướng tới việc gia tăng giá trị giải pháp phù hợp.
Các nhóm Agile thường có quy mô nhỏ hoặc xung quanh các nhóm gồm các nhóm nhỏ. Cấu trúc đơn giản hơn và phẳng hơn không làm thay đổi thực tế là các sản phẩm bàn giao có thể ảnh hưởng đến một nhóm lớn các bên liên quan. Tác nhân thay đổi, cũng được coi là bên liên quan, không khác biệt vì dự án sử dụng Agile.
Các tác nhân chính cho sự thay đổi bằng cách sử dụng cách tiếp cận linh hoạt có thể bao gồm:
- Trưởng nhóm Agile: người điều phối công việc của nhóm. Một trưởng nhóm Agile thường có bộ kỹ năng mềm của người quản lý dự án nhưng ủy quyền hoàn toàn các nhiệm vụ lập kế hoạch, lên lịch trình và đánh độ ưu tiên cho nhóm. Thay vì quản lý bằng mệnh lệnh và kiểm soát truyền thống, phong cách lãnh đạo phục vụ được ưa chuộng hơn trong tất cả các phương pháp tiếp cận Agile. Tùy thuộc vào cách tiếp cận, vai trò này có thể được gọi là Scrum Master, Interation Manager, trưởng nhóm hoặc huấn luyện viên (coach).
- Đại diện khách hàng hoặc chủ sở hữu sản phẩm: thành viên tích cực của nhóm chịu trách nhiệm đảm bảo rằng thay đổi đang được phát triển giải quyết được các yêu cầu mà nó đã được ủy quyền. Trong Scrum vai trò này được gọi là chủ sở hữu sản phẩm (Product Owner). Phương pháp phát triển hệ thống động (DSDM) coi vai trò này là vai trò của người có tầm nhìn xa và lập trình cực hạn (XP) coi vai trò này là đại diện của khách hàng.
- Thành viên nhóm: các chuyên gia hoặc chuyên gia lĩnh vực bao gồm cả hai đại diện kỹ thuật và khách hàng. Tùy thuộc vào quy mô và bối cảnh cụ thể của sáng kiến, các cá nhân trong nhóm có những chuyên môn khác nhau. Các chuyên gia về tính khả dụng, kiến trúc sư kỹ thuật và quản trị viên cơ sở dữ liệu chỉ là một ví dụ về những vai trò chuyên biệt cung cấp hỗ trợ cho nhóm khi cần thiết.
- Các bên liên quan bên ngoài: tất cả các bên liên quan còn lại có thể không được coi là thành viên nhóm nhưng là một bên quan tâm đến kết quả của dự án hoặc đơn giản là cần thiết để hoàn thành dự án, đóng vai trò có thể được coi là vai trò hỗ trợ trong nhóm.
Vị trí của BA
Một nhóm Agile có thể có một hoặc nhiều thành viên trong nhóm có kỹ năng phân tích nghiệp vụ, những người này có thể có hoặc không có chức danh BA. Sự công nhận này dành cho các thành viên trong nhóm có kỹ năng đa dạng giúp mở rộng hoạt động phân tích nghiệp vụ vượt xa vai trò chuyên gia đơn lẻ.
Trong các nhóm Agile, hoạt động phân tích nghiệp vụ có thể được thực hiện bởi một hoặc kết hợp:
- BA làm việc trong nhóm,
- Đại diện khách hàng hoặc chủ sở hữu sản phẩm
- Phân phối các hoạt động này trong toàn nhóm.
Tham khảo Phần mở rộng Agile của BABOK® Guide để biết thêm chi tiết.
Kết quả phân tích nghiệp vụ
Trong môi trường Agile, phân tích nghiệp vụ gắn kết mọi người lại với nhau và đảm bảo rằng các bên liên quan phù hợp sẽ tham gia vào nhóm Agile vào đúng thời điểm.
Giao tiếp và cộng tác cởi mở là một trong những kết quả chính của việc phân tích nghiệp vụ thành công trong một dự án Agile.
BA đảm bảo rằng tầm nhìn và định hướng của dự án phù hợp về mặt chiến lược với mục tiêu của tổ chức và nhu cầu nghiệp vụ. BA chịu trách nhiệm chung trong việc xác định các tiêu chí chiến lược để hoàn thành dự án và trong quá trình dự án hỗ trợ xác định các tiêu chí chấp nhận. Chúng cũng tạo điều kiện thuận lợi cho việc trình bày rõ ràng tuyên bố về tầm nhìn sản phẩm. Tuyên bố tầm nhìn sản phẩm là một sản phẩm bàn giao ban đầu chung.
Sự chặt chẽ và phong cách của tài liệu phụ thuộc rất nhiều vào mục đích và bối cảnh mà nó được tạo ra. Các phương pháp tiếp cận Agile thiên về tài liệu vừa đủ và đúng lúc hơn là thiết lập các mô hình được xác định trước để gửi tài liệu. Cách tiếp cận tài liệu này cho phép các tài liệu kết hợp càng nhiều thay đổi được đưa ra càng tốt trong khi vẫn giữ chi phí thay đổi ở mức thấp. Tài liệu bắt buộc, chẳng hạn như tài liệu cần thiết cho việc kiểm tra hoặc báo cáo tuân thủ, vẫn được tạo ra như một phần của mỗi chu kỳ phân phối. Điều quan trọng là tài liệu phải giải quyết được nhu cầu đã được xác định và mang lại nhiều giá trị hơn chi phí phát sinh để tạo ra và duy trì chúng.
PHƯƠNG PHÁP TIẾP CẬN VÀ KỸ THUẬT
Phương pháp tiếp cận
Agile là một thuật ngữ chung cho nhiều cách tiếp cận khác nhau. Tất cả các phương pháp tiếp cận Agile đều thực hành phân tích nghiệp vụ nhưng chỉ một số ít xác định rõ ràng vai trò của phân tích nghiệp vụ. Đặc điểm chính của bất kỳ phương pháp tiếp cận Agile nào là sự liên kết của nó với các giá trị và nguyên tắc của Tuyên ngôn Agile. Một nhóm Agile có thể triển khai hoặc phát triển để sử dụng kết hợp các phương pháp tiếp cận cho phép họ mang lại giá trị hiệu quả hơn tùy theo loại dự án và môi trường làm việc của họ.
Bảng 11.1.1 Cách tiếp cận Agile
| Phương pháp tiếp cận | Mô tả ngắn |
|---|---|
| Mô hình pha lê trong suốt (Crystal Clear) | Một phần của nhóm phương pháp Crystal được xác định dựa trên độ cứng và màu sắc. Độ cứng đề cập đến mức độ quan trọng hoặc khả năng gây tổn hại cho nghiệp vụ, điều này đòi hỏi phải có kế hoạch chặt chẽ hơn và mang tính dự đoán khi mức độ quan trọng tăng lên. Màu sắc đề cập đến mức độ nặng nề của dự án trên một số khía cạnh bao gồm số lượng người cần thiết và các yếu tố rủi ro trong dự án. |
| Chuyển giao linh hoạt có kỷ luật (Disciplined Agile Delivery – DAD) | Một bộ khung quy trình ra quyết định kết hợp các ý tưởng từ nhiều phương pháp tiếp cận Agile khác. Nó nhằm mục đích hỗ trợ một dự án từ khi bắt đầu cho đến khi thực hiện. DAD không mang tính quy định và cho phép các nhóm tùy chỉnh vòng đời và cách tiếp cận của riêng họ. |
| Mô hình phát triển hệ thống năng động (Dynamic Systems Development Metod – DSDM) | Khung phân phối dự án tập trung vào việc ấn định chi phí, chất lượng và thời gian ngay từ đầu trong khi dự phòng được quản lý bằng cách thay đổi các tính năng sẽ được phân phối. MoSCoW kỹ thuật ưu tiên được sử dụng để quản lý phạm vi. Các khung thời gian hoặc khoảng thời gian tập trung ngắn với kết quả được xác định rõ ràng được sử dụng để quản lý công việc. |
| Quản lý dự án tiến hóa (Evolutionary Project Management – Evo) | Một phương pháp quản lý dự án để phát triển và cung cấp hệ thống theo từng bước. Nó tập trung mạnh vào việc định lượng giá trị cho nhiều bên liên quan và lập kế hoạch tăng dần dựa trên việc cung cấp giá trị đó (có thể đo lường được). Nó sử dụng các bảng ước tính tác động như một kỹ thuật chính thức để đánh giá các giải pháp về khả năng mang lại giá trị cho nhiều bên liên quan với một mức chi phí nhất định. |
| Lập trình cực hạn (Extreme Programming – XP) | Được đặt tên theo khái niệm tận dụng tối đa các kỹ thuật công nghệ phần mềm có lợi. Khái niệm này tập trung vào các quy trình phát triển kỹ thuật và có tính năng lập trình theo cặp, phát triển dựa trên thử nghiệm và các phương pháp tiếp cận thủ công khác đối với thực hành kỹ thuật. Thực hành kỹ thuật XP thường được sử dụng cùng với một trong các khung quản lý linh hoạt |
| Phát triển hướng tính năng (Feature Driven Development – FDD) | Tập trung vào triển vọng của chức năng được khách hàng coi trọng để phát triển phần mềm có thể hoạt động. Ví dụ, theo sau hoạt động xác định phạm vi cấp cao, một danh sách tính năng được xác định và tất cả các hoạt động lên kế hoạch, thiết kế, phát triển đều được thực hiện dựa trên các tập hợp tính năng. |
| Kanban | Không yêu cầu các vòng lặp cố định. Công việc tiến triển thông qua quá trình phát triển như là một luồng hoạt động liên tục. Tính năng quan trọng là nó giới hạn khối lượng công việc đang thực hiện tại mọi thời điểm bất kỳ (thường gọi là giới hạn công việc đang triển khai hoặc WIP). Nhóm chỉ làm việc trên một số hạng mục nhất định tại một thời điểm và chỉ có thể bắt đầu công việc của hạng mục mới khi có yêu cầu duy trì dòng chảy xuôi chiều (downstream) và sau khi hạng mục công việc trước đó đã hoàn thành. |
| Bộ khung linh hoạt điều chỉnh quy mô (Scaled Agile Framework – SAFe) | Một bộ khung để triển khai các thông lệ thực hành Agile ở quy mô doanh nghiệp. Nó làm nổi bật vai trò cá nhân, nhóm, hoạt động, các tạo tác cần thiết để mở rộng quy mô Agile từ cấp độ nhóm đến cấp chương trình đến cấp doanh nghiệp. |
| Một bộ khung quản lý quy trình gọn nhẹ dựa trên sự kiểm soát quy trình theo kinh nghiệm. Công việc được thực hiện trong một loạt các vòng lặp có độ dài cố định, dược gọi là phân đoạn (sprint), thường kéo dài một tháng hoặc ngắn hơn. Vào cuối mỗi phân đoạn, nhóm phải tạo ra được phần mềm hoạt động có chất lượng đủ cao để có thể “xuất xưởng” hoặc chuyển giao cho Khách hàng. |
Kỹ thuật
Bảng sau liệt kê các kỹ thuật thường được sử dụng trong các phương pháp tiếp cận Agile.
Tham khảo Phần mở rộng Agile của BABOK® Guide để biết mô tả chi tiết hơn về các kỹ thuật này.
| English | Tiếng Việt |
|---|---|
| Phát triển hướng hành vi (Behavior Driven Development – BDD) | Cách tiếp cận giúp tăng cường tương tác giữa các bên liên quan với các thành viên nhóm bằng cách thể hiện những nhu cầu sản phẩm qua ví dụ cụ thể. |
| Phân tích Kano (Kano Analysis) | Một kỹ thuật giúp hiểu rõ đâu là những tính năng sản phẩm sẽ giúp thúc đẩy độ hài lòng của khách hàng. |
| Hồ sơ kỹ thuật gọn nhẹ (Lightweight Documentation) | Một nguyên tắc chi phối tất cả các tài liệu được tạo ra trong một dự án Agile. Mục đích là để đảm bảo tất cả tài liệu đều nhằm để hoàn thành những nhu cầu sắp xảy ra, có giá trị rõ ràng với các bên liên quan, và không phát sinh chi phí không cần thiết. Ví dụ, một tài liệu tổng quan về hệ thống có thể được viết vào cuối dự án dựa trên nội dung ổn định và các đợt kiểm thử chấp nhận như một phần của hoạt động kiểm thử sản phẩm. |
| Sắp xếp độ ưu tiên MoSCoW | Một phương pháp sắp xếp thứ tự ưu tiên các user story (hoặc những yếu tố khác) trong cách tiếp cận vòng lặp và gia tăng. MoSCoW (Must have, Should have, Could have, Won’t have) cung cấp một cách thức để đạt được hiểu biết chung về tầm quan trọng tương đối của việc chuyển giao user story hoặc một phần giá trị khác trong sản phẩm. |
| Xây dựng chân dung (Personas) | Nhân vật hư cấu hoặc khuôn mẫu thể hiện các ví dụ về cách mà những người dùng điển hình tương tác với hệ thống. |
| Lập kế hoạch hội thảo | Một buổi hội thảo cộng tác được sử dụng để giúp nhóm dự án Agile xác định giá trị nào có thể được chuyển giao trong một khoảng thời gian, chẳng hạn như một bản phát hành. |
| Mô hình liên kết mục đích (Purpose Alignment Model) | Một mô hình được sử dụng để đánh giá các ý tưởng trong bối cảnh của khách hàng và giá trị. |
| Quyền chọn thực sự (Real Options) | Một cách tiếp cận nhằm giúp mọi người biết khi nào nên ra quyết định hơn là làm thế nào để ra quyết địnhk |
| Ước lượng tương đối (Relative Estimation) | Các kỹ thuật ước lượng theo nhóm sử dụng đơn vị tính độ khó (story points) để thể hiện mức độ phức tạp tương đối của một user story cần phát triển, hoặc sử dụng số ngày lí tưởng (ideal day) để thể hiện tổng số nỗ lực mà một user story sẽ cần để phát triển. |
| Họp cải tiến (Retrospectives) | Thuật ngữ tương tự với kỹ thuật Bài học kinh nghiệm. Họp cải tiến tập trung vào sự cải tiến liên tục trong quy trình làm việc nhóm và được thực hiện sau mỗi vòng lặp trong dự án Agile. |
| Phân rã yêu cầu sử dụng tính năng (Story Decomposition) | Đảm bảo rằng các yêu cầu cho sản phẩm được thể hiện ở mức độ chi tiết thích hợp và dẫn xuất từ mục tiêu nghiệp vụ có giá trị. |
| Lập bản đồ tính năng (Story Mapping) | Cung cấp một cái nhìn trực quan và vật lí về một chuỗi hoạt động tuần tự cần được hỗ trợ bởi giải pháp. |
| Phác họa kịch bản tương tác (Storyboarding) | Chi tiết một cách trực quan và bằng văn bản về chuỗi hoạt động tuần tự thể hiện các tương tác của người dùng với một hệ thống hoặc nghiệp vụ. |
| Ánh xạ chuỗi giá trị (Value Stream Mapping) | Cung cấp một phần trình bày đầy đủ, theo dòng thời gian, dựa trên thực tế về chuỗi hoạt động cần thiết để chuyển giao một sản phẩm hoặc dịch vụ cho khách hàng. |
