business analyst in Agile development

Business Analyst role in Agile development – BA work in Scrum team

Normally in Agile development, people don’t mention about Business Analyst role. So what will be the true story behind the scene?

Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to discover the user needs and the solution to address them, and specify requirements. But in Scrum, there is no business analyst role. (Roman Pichler)

What will BA do in a Scrum team?

Option 1: product owner

This is a natural move. The individual needs to own the product on behalf of the company instead of analyse and get features approval from specific clients. For that significant change, the individual might need to learn new skills to adapt new role.

Option 2: team member

The role of business analyst as a team member will mostly to address and help other members groom product backlog. Since this responsibility is for the whole team, business analyst inside a Scrum team usually covers additional tasks as well like writing technical documents, coordinate with testers.

The role of a Business Analyst in an Agile project is not well-defined just as there is no defined role for a Project Manager on an Agile project. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.

The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects

(chuckc3)

Option 3: proxy product owner

Dealing half-heartedly with the role of business analysts in Scrum is a common mistake: Business analysts neither play the product owner role nor are they team members. Instead, they end up as proxy product owners, a go-between the real decision maker and the development team, as shown blow.

Using a proxy product owner is best avoided—certainly as a permanent solution.

(Roman Pichler)

Why this model is not-recommended? Because it requires many communication to verify each single decision thus brings lots of miscommunication, misunderstanding as well as inconsistent product requirements. At the end, no one is really the Owner of Product.

The head of a business unit was asked to take on the product owner role for a new product. As he struggled to fill the role effectively, the business analyst stood in as a proxy. While the analyst did all the detailed grooming work, the business unit head decided about the product features and when which functionally was released. Unfortunately, this resulted in miscommunication, a long-winded decision-making process, and poor morale. (Roman Pichler)

Conclusion

There is no fixed direction, solution for a traditional business analyst to follow in Scrum world. But I think from the above suggestions, insights, we’re all more clear about the basic concepts.

Scrum is not a plug-and-play environment that will guarantee that product development will succeed. If improperly managed, the product development will not adequately scale to the customer’s requirements, which will increase costs, impact return on investment, and lead to instability. (Sriramasundararajan Rajagopalan)

Reference:

Kỹ năng viết User Story với nguyên lý INVEST

Mở  đầu

User Story là một khái niệm căn bản khi làm việc theo phương pháp Agile. Mỗi User Story là một yêu cầu bất kì đối với sản phẩm nhằm hướng tới mục tiêu mang lại giá trị tốt hơn cho khách hàng. Thông thường các user story được tách riêng lẻ trong bảng Backlog (bảng lưu trữ các yêu cầu sản phẩm) nên còn được gọi là Product Backlog Item (PBI)

user story

Trong bài viết này chúng ta sẽ đi sâu vào cách viết 1 PBI tốt bằng phương pháp INVEST

Independent

Trước hết, mỗi PBI cần là một yêu cầu độc lập, không phụ thuộc vào bất kì PBI khác trong tính năng.

Các PBI có thể liên kết với nhau theo hướng tham khảo hoặc dùng như là một điều kiện tiên quyết, tính năng bổ trợ nhưng bản thân yêu cầu của từng PBI là hoàn toàn riêng biệt.

Đây là yêu cầu đầu tiên vì nếu không có sự tách biệt thì sẽ dẫn tới sự chồng chéo, dư thừa. Tổn hao công sức của Product Owner.

First thing you need is to ensure the PBI is independent, not replicate others.

Negotiable

Một PBI cần có tính linh hoạt. Cho tới trước khi nó được giao vào một tiến trình phát triển sản phẩm thì một PBI có thể được chỉnh sửa, viết lại, bổ sung bất kì lúc nào.

Tại sao lại cần linh hoạt? Vì thực tế nhu cầu của thị trường, của khách hàng luôn luôn thay đổi. Phương pháp Agile nhấn mạnh tính quan trọng của việc luôn thích ứng với thực tế, không ngại thay đổi. Đó là lý do của nguyên tắc này.

Real business always changes, don’t freeze your requirements.

Valuable

Hãy chắc rằng một PBI mang lại giá trị nào đó cho sản phẩm, người dùng. Không cần phải giải thích thì ai cũng biết rằng khi chúng ta làm một điều gì đó thì tất nhiên phải hướng tới việc tạo ra giá trị. Trong phát triển sản phẩm cũng vậy, bạn cần nhìn lại xem điều mình dự định làm có mang lại giá trị gì trong ngắn hạn, trung hạn, dài hạn không?

Do things valuable and you will absoluately be happy with your work.

Estimable

Có thể định lượng được. Hãy chắc rằng bạn hiểu cơ bản cần bao lâu để làm xong một yêu cầu. Luôn có 3 yếu tố xác định thành công của một dự án – sản phẩm đó là THỜI GIAN – CHẤT LƯỢNG – GIÁ CẢ. Bạn cần cân nhắc kĩ yếu tố đầu tiên – Thời Gian trong mối tương gian với các yếu tố khác để quyết định thứ tự ưu tiên của các PBIs.

Time passes and cannot be back.

Small

Đủ nhỏ và đơn giản. Ngay từ đầu 1 PBI chỉ là một yêu cầu đơn lẻ nhằm giúp Product Owner có thể dễ dàng định lượng độ ưu tiên của các tính năng. Chính vì vậy hãy đảm bảo 1 PBI không quá lớn để có thể hiểu và nắm bắt nhanh.

Simplicity is simply perfect.

Testable

Có thể kiểm tra, đánh giá được thành quả. Một yêu cầu có tốt đến mấy trong ý tưởng nhưng không có cách đánh giá thì không có gì đảm bảo kết quả làm ra đúng với mong đợi. Vì vậy hãy đảm bảo mô tả của bạn có đầy đủ thông tin để đánh giá chính xác mong muốn của yêu cầu.

Measuring is always a hard thing to do.

 

công việc tìm hiểu nghiệp vụ

Happy investigating!

  •  https://en.wikipedia.org/wiki/INVEST_(mnemonic)
  •  https://www.agilealliance.org/glossary/invest
  •  http://agileforall.com/new-to-agile-invest-in-good-user-stories

Thiết lập và sử dụng hệ thống phiên bản – API system

Hệ  thống API là gì?

API là viết tắt của chữ Application Programming Interface, dịch thuần Việt là “Giao diện lập trình ứng dụng”. Hiểu một cách sâu sắc hơn thì đó là những chuẩn kết nối, giao tiếp nhằm lấy thông tin hay dịch vụ do một bên cung cấp cho một hoặc một số bên khác sử dụng, có thể trừu tượng hoá bằng hình sau:

API schema

Tác dụng của API?

  • Ứng dụng khả năng hiện thực cấu trúc micro-service trong phát triển phần mềm (chia nhỏ các chức năng thành các module nhỏ)
  • Cung cấp back-end side cho webapp, mobile apps
  • Sử dụng các tiện ích dịch vụ từ bên thứ 3 (3rd party service) như xác thực và lấy thông tin người dùng thông qua Facebook, Google, Stripe, etc. Đây là tác dụng phổ biến và dễ thấy nhất. Ngoài các dịch vụ về xác thực, mạng xã hội, API còn mang tới sự cung cấp dịch vụ thanh toán online, chỉnh sửa hình ảnh, gửi tin nhắn sms, chữ kí điện tử, upload/download files, etc.
  • Cung cấp dịch vụ ra bên ngoài (đứng vai trò là 3rd party service)

Mô thức hoạt động của API

Với bản chất là một giao diện, các thông tin về cách sử dụng API cần được công khai với người dùng, ít nhất là với các nhà lập trình của bên đối tác. Tất cả phương thức tiếp nhận, máy chủ và dữ liệu trả về đều do một tổ chức cụ thể nào đó cung cấp (API provider).

API provider sẽ chịu trách nhiệm vận hành máy chủ của họ và mở các cổng giao tiếp phù hợp cho người dùng sử dụng. Mọi vấn đề về dữ liệu lỗi, quá tải, sai ý nghĩa của cổng giao tiếp so với dữ liệu trả về đều do bên API provider chịu trách nhiệm.

Chính vì thế, khi sử dụng API, chúng ta gần như phải phó mặc chất lượng cho nhà cung cấp vì bản thân chúng ta không quyết định được gì cả. Chúng ta chỉ thấy và chỉ có khả năng làm những gì mà họ cho phép và cung cấp (dù cái họ cung cấp là dữ liệu sai, chậm, không rõ ràng :D)

scsb-toolkit-whatistoolkit

Tiếp theo chúng ta sẽ đi tới các kinh nghiệm quan trọng về API của bản thân người viết và từ góp nhặt thông tin.

Các lưu ý trong việc sử dụng API

  • Đôi khi những gì API provider cung cấp là không khả thi cho yêu cầu của khách hàng/quản lý dự án, người phát triển phần mềm cần dùng các thông tin và ví dụ cụ thể để chứng minh điều đó và đề xuất các giải pháp tốt nhất có thể. Đừng đâm đầu quá sâu vào vấn đề nằm ngoài phạm vi giải quyết của mình.
  • Một số nhà cung cấp lớn vẫn có hệ thống documentation vô cùng tệ hại làm cho việc hiện thực API integration của nhà phát triển là một cuộc thử sai dài, bạn cần chấp nhận vấn đề này ^_^. Tuy nhiên, nên tận dụng tối đa tiện ích hỗ trợ của họ (nếu có) bằng cách hỏi thẳng những thắc mắc.
  • Nếu nhà phát triển sản phẩm dùng một thư viện mã nguồn mở để đẩy nhanh tốc độ tích hợp API, việc có lỗi hay các warning khó chịu là bình thường vì không ai có trách nhiệm đảm bảo điều đó không xảy ra với bạn. Vì thế, “có qua có lại”, nếu bạn có thể giải quyết một vấn đề nào đó, hãy đóng góp mã nguồn của bạn để khắc phục cho cả những người khác (chẳng phải bạn cũng đang dùng lòng tốt của người khác hay sao?!).

Các lưu ý trong việc phát triển API

  • API versioning là việc chia phiên bản cho hệ thống API mà bạn cung cấp. Tại sao phải chia phiên bản API? Vì bạn muốn giữ nguyên mọi thứ liên quan đến hệ thống API cũ và cung cấp một hệ thống API hoàn toàn mới, không ảnh hưởng tới những tích hợp API cũ. Ví dụ: google/v1/user/lehoang1417 sẽ trả về handsome nhưng google/v2/user/lehoang1417 sẽ trả về awesome 😀
  • Tuỳ sự độc lập trong thiết kế hệ thống mà nguy cơ thay đổi mới sẽ ảnh hưởng tới các phiên bản cũ nhiều hay ít. Nhưng trong trường hợp nào thì bạn cũng cần ý thức và đề phòng vấn đề này.
  • Đối với mobile apps, khi đã release thì ta không thể thay đổi API version mà nó gọi tới nếu như chúng ta chỉ quyết định phiên bản API trả về theo cái mà nó request lên. Vì thế cần thật cẩn thận trong các lần release.
  • Tuy nhiên, có một cách có thể thay đổi mobile apps’ requests API version một cách chủ động bằng cách trong request của app phải có cả app_type và app_version. Chúng ta sẽ dựa vào đó quyết định version trả về mong muốn.

Chúc các bạn sử dụng và nghiên cứu API thành công 🙂

have_fun