Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 5

Áp dụng các câu chuyện của người dùng trong công cụ lập kế hoạch tài chính trên nền Web

Trong phần 5 của loạt bài này, tìm hiểu xem các câu chuyện của người dùng và Scrum có thể giúp bạn nhanh chóng phát triển một ứng dụng Web như thế nào. Đi xuyên qua một trường hợp nghiên cứu thực và xem các câu chuyện của người dùng, cuộc thảo luận và sự ưu tiên có thể dẫn tới các phiên bản beta nhanh chóng như thế nào. Thấy cách những phản hồi từ người thử nghiệm và người dùng có thể được tích hợp lặp vào trong sản phẩm của bạn trong các lần chạy nước rút.

Mikko Kontio, Giám đốc, Softera

Mikko Kontio có một nền tảng về phát triển và tư vấn phần mềm. Ông hiện là Giám đốc tại Softera, một công ty phát triển phần mềm tập trung vào các cổng kinh doanh và giải pháp tính cước viễn thông.



30 10 2009

Giới thiệu

Trong loạt bài này bạn đã học về các quy trình nhanh, các lợi ích của việc sử dụng chúng và các yêu cầu đặt ra cho tổ chức có sử dụng chúng. Bạn cũng đã học các kiểu tổ chức khác nhau thích ứng với sự phát triển nhanh như thế nào và về các kiểu bên liên quan khác nhau và những điều mà các vai trò của chúng đòi hỏi. Phần đăng trước đã thảo luận việc áp dụng các câu chuyện người dùng để xác định các yêu cầu dự án trong một môi trường thay đổi liên tục.

Bài viết này giải thích cách áp dụng các câu chuyện của người dùng với một trường hợp ví dụ về việc phát triển một công cụ lập kế hoạch tài chính dựa trên Web. Ứng dụng này có cấu trúc đơn giản và các chức năng cơ bản dễ hiểu. Để cho ngắn gọn, ví dụ này được đơn giản hóa và các câu chuyện của người dùng không bao gồm tất cả các chức năng trong hệ thống.

Nhóm phát triển đã sử dụng Scrum như là quy trình phát triển của họ và được phát triển bằng Ruby on Rails. Ruby on Rails có thể chạy trên các nền tảng khác nhau, như Linux®, Windows™ và ngay cả trên các máy chủ ứng dụng Java™ nhờ JRuby. Ngày nay bạn có các lựa chọn thú vị cho các ứng dụng Web, thậm chí nếu công ty hoặc khách hàng của bạn phần lớn có các máy chủ ứng dụng Java.


Công việc tồn đọng của sản phẩm

Công việc tồn đọng của sản phẩm có chứa các khía cạnh năng suất và các chức năng mà người quản lý sản phẩm muốn đưa vào trong sản phẩm trong tương lai gần. Trong Scrum, người đại diện về quản lý sản phẩm được gọi là chủ sở hữu sản phẩm. Trong trường hợp của chúng ta, công việc tồn đọng là một danh sách các câu chuyện của người dùng.

Trong các dự án lớn hơn, việc tìm kiếm một hệ thống quản lý công việc tồn đọng của sản phẩm và công việc tồn đọng của lần chạy nước rút sẽ cần đến nhiều công sức. Trong trường hợp ví dụ, tuy nhiên, các công việc tồn đọng được quản lý trong một bảng tính trên nền Web.

Như được thảo luận trong Phần 4, cấu trúc sau là một khung tốt để viết các câu chuyện của người dùng:

Là một [kiểu hay vai trò của người sử dụng] (ai).

Tôi muốn [thực hiện một số nhiệm vụ] (cái gì).

Vì vậy tôi có thể [đạt được một số mục tiêu] (tại sao).

Bằng cách trả lời ba câu hỏi ai, cái gì và tại sao, câu chuyện của người dùng hoàn toàn dễ hiểu. Không có câu hỏi "tại sao", các nhà phát triển có thể có khả năng hiểu các chức năng một cách chính xác, nhưng biết lí do có thể làm cho mục tiêu của người dùng rõ ràng hơn và có thể giúp các nhà phát triển tìm ra nhiều cách để đạt được mục tiêu đó.

Một câu chuyện tốt của người sử dụng nên có một số đặc điểm: Nó phải độc lập, thương thảo được, có thể định giá được, có thể đánh giá được, nhỏ và có thể thử nghiệm được. Ví dụ, một quy mô hợp lý đảm bảo rằng các chức năng tập trung vào một yêu cầu và có thể thử nghiệm để xác định rằng nó hoạt động như nó phải có.

Sau đây là những câu chuyện của người dùng ban đầu cho ứng dụng Web:

  • Là một người lãnh đạo nhóm tôi muốn:
    • Đăng ký trong hệ thống để bắt đầu lập kế hoạch tài chính cho công ty của tôi.
    • Quản lý con người, những người có thể chỉnh sửa kế hoạch tài chính của chúng tôi.
    • Nâng cấp đăng ký của ta để thêm nhiều tính năng.
  • Là một người sử dụng tôi muốn:
    • Duy trì các kế hoạch tài chính của mình.
    • Sửa đổi cấu trúc (các nhóm và các hàng) về kế hoạch tài chính của mình.
    • Nhập và sửa đổi các dữ liệu trong các kế hoạch tài chính của mình.
    • Chạy các báo cáo của các dữ liệu của mình để phân tích tài chính.
  • Là một quản trị viên của hệ thống tôi muốn:
    • Xem các thống kê của hệ thống.
    • Chạy báo cáo cho phòng kế toán của chúng ta.

Hầu hết các câu chuyện của người dùng trả lời các câu hỏi ai và cái gì, một số lỗi được đưa ra lý do tại sao. Chủ sở hữu sản phẩm đã dành ưu tiên liệt kê theo quan điểm của mình và sau đó đã xem xét người chủ Scrum (Scrum master).


Thảo luận về các câu chuyện của người dùng

Chủ sở hữu sản phẩm và chủ Scrum đã duyệt qua công việc tồn đọng của sản phẩm và đã chọn bốn câu chuyện của người dùng sẽ được thảo luận và có thể được thực hiện tại lần chạy nước rút số 1. Mục đích chính của các câu chuyện của người sử dụng là dành cho khách hàng (trong trường hợp của chúng ta, chủ sở hữu sản phẩm) và nhóm phát triển để thảo luận về câu chuyện đó và thương thảo cách thực hiện của nó. Các cuộc thảo luận là quan trọng hơn bất kỳ tài liệu văn tự, bởi vì không có văn bản nào có thể thay thế cho nói chuyện trực tiếp. Sau đây các cuộc thảo luận được mô tả ngắn gọn.

  • Là một lãnh đạo nhóm, tôi muốn đăng ký để bắt đầu lập kế hoạch tài chính cho công ty của mình.

    Để lưu trữ dữ liệu của người dùng và sau đó quay trở lại tới nó, hệ thống cần nhận dạng người sử dụng. Chủ sở hữu sản phẩm muốn chạy ứng dụng với một phiên bản miễn phí (có các chức năng hạn chế) và bán các thuê bao cho các phiên bản khác. Các phiên bản này được gọi là các kế hoạch. Người dùng sẽ có thể bắt đầu sử dụng hệ thống mà không có một giao dịch bán hàng thủ công, vì thế việc đăng ký vào hệ thống, hoặc ký hợp đồng, là cần thiết.

    Người sử dụng có thể thêm nhiều người dùng để truy cập dữ liệu của công ty trong hệ thống đó (một yêu cầu về sau), do đó cá nhân đăng ký có thể được coi như là một người quản lý hoặc người lãnh đạo nhóm. Trong khi đăng ký, người dùng chỉ cần nhập thông tin cần thiết, chẳng hạn như tên, email, mật khẩu và có thể tên quốc gia. Mọi thông tin khác của người dùng cần phải được quản lý bằng cách sử dụng sở thích người dùng sau này trong ứng dụng.

  • Là một người sử dụng, tôi muốn duy trì các kế hoạch tài chính của mình.

    Có thể có nhiều hơn một phiên bản về ngân sách của tôi, hoặc ngân sách có thể gồm một số ngân sách khác (ví dụ, một ngân sách cho từng dòng sản phẩm). Khi những người dùng tạo ra một ngân sách mới, họ sẽ có thể sao chép một ngân sách hiện có để sử dụng làm ngân sách cơ sở cho ngân sách mới. Tạo ra các phiên bản của một ngân sách là dễ dàng. Ngân sách tự nó không cần bất kỳ thông tin tổng quát nào hơn là tên của nó.

  • Là một người sử dụng, tôi muốn thay đổi cấu trúc (các nhóm và các hàng) của kế hoạch tài chính của mình.

    Ngân sách cần phải có một cấu trúc có thể do người sử dụng sửa đổi, gồm các nhóm và các hàng. Các hàng thuộc về một nhóm. Ví dụ, các chi phí (một nhóm) chứa phòng nhân sự, văn phòng các nhà thầu phụ (các hàng). Những người dùng có thể sửa đổi và loại bỏ các tiêu đề của nhóm và hàng. Một hàng chứa dữ liệu có liên quan đến ngày tháng, do đó khung nhìn ngân sách nên có một ma trận các nhóm và các hàng ở bên trái với các tháng trên đầu trang. Dữ liệu là lượng tiền. Trong tương lai, dữ liệu cũng có thể là một công thức của các hàng khác, nhưng điều đó sẽ được thiết kế và lập kế hoạch sau này nếu cần thiết.

    Vào lúc này, chủ sở hữu sản phẩm đã đưa ra một số sơ đồ thiết kế màn hình ví dụ để chỉ ra hình dạng của dự thảo ngân sách điển hình dựa trên tháng. Người dùng sẽ có thể cuộn các tháng ở đầu trang để cho phép di chuyển dự thảo ngân sách.

  • Là một người sử dụng, tôi muốn nhập vào và sửa đổi các dữ liệu trong các kế hoạch tài chính của mình.

    Chủ sở hữu sản phẩm tiếp tục đưa ra các màn hình mẫu và cho thấy cách các dữ liệu (một số tiền) sẽ được đặt trên màn hình. Trong ứng dụng này, có các hộp văn bản, như một bảng tính, cho phép người dùng xem và chỉnh sửa các dữ liệu. Nhóm phát triển đã đề xuất các khả năng về cách thực hiện theo quan điểm tiện dụng. Họ đồng ý rằng trong lần chạy nước rút đầu tiên họ sẽ thử một trong những đề xuất và xem nó có làm việc không.

Bạn chắc chắn nhận ra một sự phụ thuộc giữa hai câu chuyện cuối cùng của người dùng. Một câu chuyện không thể được thực hiện trước khi một câu chuyện thứ ba hoàn thành. Kiểu phụ thuộc này chấp nhận được, bởi vì rất khó để tránh được các phụ thuộc như vậy khi bạn đang xây dựng đầy đủ một ứng dụng mới hoặc các khía cạnh mới mà chúng yêu cầu một điều gì khác cái đầu tiên.

Câu cuối cùng của câu chuyện thứ ba của người dùng (về hiện ngân sách) đã được loại bỏ để trở thành một câu chuyện mới của người sử dụng cho các lần chạy nước rút sau này. Vào lúc này, khung nhìn ngân sách sẽ chỉ hiển thị 12 tháng, bắt đầu từ tháng hiện tại.


Công việc tồn đọng của lần chạy nước rút số 1

Vào lúc bắt đầu lần chạy nước rút đầu tiên, nhóm phát triển đã thảo luận các mục công việc cần làm đã lựa chọn và đồng ý cam kết phân phối các chức năng đó trong lần chạy nước rút số 1. Nhóm phát triển sau đó thảo luận chi tiết bốn câu chuyện của người dùng và đã liệt kê tất cả các nhiệm vụ cần phải thực hiện.

Công việc tồn đọng của lần chạy nước rút số 1 có các nhiệm vụ sau:

  • Tạo khung ứng dụng.
  • Tạo một CSS (bảng định kiểu xếp tầng) đơn giản để người phát triển sử dụng trong quá trình phát triển.
  • Thiết kế cơ sở dữ liệu cho người sử dụng, các ngân sách và dữ liệu ngân sách.
  • Tạo bảng cơ sở dữ liệu cho người sử dụng, các ngân sách, các nhóm ngân sách, các hàng ngân sách và dữ liệu ngân sách.
  • Xác nhận tính hợp lệ logic để đăng ký người sử dụng (cho một thành phần sẵn sàng).
  • Xác nhận tính hợp lệ logic cho người dùng ký hợp đồng (cho thành phần sẵn sàng đó).
  • Xác nhận tính hợp lệ logic để gửi một mật khẩu bị quên (cho thành phần sẵn sàng đó).

Chúng cũng cần tạo ra các chức năng để thêm, xoá và sửa đổi dữ liệu ngân sách cơ bản, như thêm các nhóm và các hàng cho các cấu trúc ngân sách.

Sau lần chạy nước rút số 1 chủ sở hữu sản phẩm có một đoạn phần mềm làm việc để thử nghiệm.


Công việc tồn đọng của lần chạy nước rút số 2

Chủ sở hữu sản phẩm và Scrum master đã dành ưu tiên cho công việc tồn đọng còn lại của sản phẩm. Họ ngập ngừng lựa chọn các câu chuyện của người dùng sau đây cho lần chạy nước rút tiếp theo.

  • Là một lãnh đạo nhóm phát triển, tôi muốn quản lý những người có thể chỉnh sửa các kế hoạch tài chính của chúng ta.
  • Là một lãnh đạo nhóm phát triển, tôi muốn nâng cấp đăng ký của chúng ta để có thêm nhiều tính năng.

Chủ sở hữu sản phẩm đã quyết tâm có được các chức năng nhất định cho một nhóm lựa chọn của những người thử nghiệm beta và những người dùng thí điểm để thử sau lần chạy nước rút số 2. Chủ sở hữu sản phẩm muốn nhận được sự phản hồi từ những người dùng về khả năng sử dụng và cần ngay các chức năng này.

Trong lần chạy nước rút số 3, chủ sở hữu sản phẩm đã có thể thực hiện các thay đổi đối với các việc cần làm về sản phẩm. Lần chạy nước rút thứ tư là một lần chạy nước rút ngắn để tạo ra các thay đổi trong giao diện người dùng và các chức năng


Các lần chạy nước rút tương lai

Các lần chạy nước rút đầu tiên không trình bày tất cả các câu chuyện của người dùng ban đầu. Một số đã được để lại cho các lần chạy nước rút tương lai, cùng với các mong muốn và các bình luận của người sử dụng. Là sản phẩm phát triển, chủ sở hữu sản phẩm sẽ có thể thêm nhiều câu chuyện của người dùng hơn trong công việc tồn đọng của sản phẩm. Như là các lần chạy nước rút đang được lên kế hoạch, các câu chuyện của người dùng vẫn được ưu tiên để các khía cạnh quan trọng sẽ được phát triển đầu tiên. Ví dụ:

  • Trong khung nhìn ngân sách, người dùng sẽ có thể cuộn các tháng ở đầu trang để tiện hiện dự thảo ngân sách.
  • Là một người sử dụng, tôi muốn chạy các báo cáo của các dữ liệu của mình để phân tích tài chính.
  • Là một quản trị viên, tôi muốn xem các thống kê của hệ thống.
  • Là một quản trị viên, tôi muốn chạy báo cáo cho phòng kế toán của chúng ta.

Ứng dụng

Sau hai lần chạy nước rút, những người thử nghiệm beta có một đoạn phần mềm làm việc để thử nghiệm. Chủ sở hữu sản phẩm này đã hoàn toàn hài lòng với điều đó. Phần mềm vẫn chưa sẵn sàng để khởi chạy, nhưng nó đã có một tình trạng tốt hơn nhiều so với việc chờ đợi một dự án 6 tháng hay 12 tháng nữa mới sẵn sàng làm việc.

Hình 1 cho thấy một phiên bản mới nhất của ứng dụng. Các chức năng và các khái niệm cơ bản đã phát triển trong hai lần chạy nước rút đầu tiên, chẳng hạn như cấu trúc bảng tính, được bao gồm. Ngoài ra còn có một số chức năng mới đã được phát triển sau này, chẳng hạn như phân tích dòng tiền mặt, xuất khẩu và báo cáo nổi trội.

Hình 1. Ứng dụng Web
Hình 1. Ứng dụng Web

Kết luận

Các câu chuyện của người dùng cùng với Scrum là các công cụ tốt để phát triển các ứng dụng Web. Bạn duyệt qua trường hợp phát triển ứng dụng thực tế và thấy các câu chuyện của người dùng và Scrum đã được sử dụng trong việc xây dựng các ứng dụng như thế nào.

Các cuộc thảo luận giữa ban quản lý sản phẩm và nhóm phát triển là một phần quyết định để tìm ra cách tốt nhất để thực hiện các yêu cầu. Các câu chuyện của người dùng sau đó đã được nhóm phát triển chia thành các nhiệm vụ. Một nhiệm vụ thường mất ít hơn một ngày để thực hiện. Một lần chạy nước rút về cơ bản là một khoảng thời gian đã thỏa thuận để thực hiện các nhiệm vụ đó.

Các bản phát hành thường xuyên đã làm cho nó có thể phân phối phiên bản đầu tiên sớm hơn cho ban quản lý sản phẩm và sau đó cho một nhóm các nhà thử nghiệm beta được chọn để lấy kinh nghiệm và bình luận của họ. Các ý kiến sau đó đã được coi là các câu chuyện của người dùng — hay là các thay đổi cho các lần chạy nước rút tiếp theo. Lợi ích chính là đạt được nhanh chóng và và thay đổi cần thiết theo các bình luận. Ban quản lý sản phẩm và những người dùng cũng nhanh chóng đạt được các mong ước của mình.

Tài nguyên

Học tập

  • Xem các phần khác của loạt bài này về việc chấp nhận phát triển nhanh:
    • Phần 1, "Phát triển nhanh có đúng với tổ chức của bạn không?" (developerWorks, 03.2008)
    • Phần 2, "Hiểu biết về các khía cạnh khác nhau" (developerWorks, 04.2008)
    • Phần 3, "Vai trò của các bên liên quan đến nhanh" (developerWorks, 05.2008)
    • Phần 4, "Sử dụng các câu chuyện của người sử dụng để xác định các yêu cầu dự án" (developerWorks, 06.2008)
  • Đọc các thảo luận của Wikipedia về các câu chuyện của người dùng.
  • Đọc nhiều hơn về ScrumQuản lý dự án thích nghi bằng cách sử dụng Scrum.
  • User Stories Applied: For Agile Software Development của Mike Cohn giải thích cách phát triển các yêu cầu linh hoạt, thực tế được thực hiện; tiết kiệm thời gian và phát triển phần mềm tốt hơn để đáp ứng các nhu cầu của người sử dụng; thu thập những câu chuyện của người sử dụng — ngay cả khi bạn không thể nói chuyện với người sử dụng; sử dụng các câu chuyện của người sử dụng như là một phần của việc lập kế hoạch, sắp xếp chương trình, đánh giá và thử nghiệm.
  • Bắt đầu một nguồn cung cấp RSS cho mục bài Bản tuyên ngôn kiến trúc của Mikko Kontio.
  • Duyệt qua cửa hàng sách công nghệ với các sách về các chủ đề kỹ thuật này và khác.
  • Trong khu vực Kiến trúc trên developerWorks, hãy nhận tài nguyên mà bạn cần để đặt các kỹ năng của bạn trong vùng kiến trúc.

Lấy sản phẩm và công nghệ

  • Tải về phiên bản đánh giá sản phẩm IBM và nhận được các bài thực hành của bạn trên các công cụ phát triển ứng dụng và các sản phẩm phần mềm trung gian từ IBM® DB2®, Lotus®, Rational®, Tivoli® và WebSphere®.

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=441879
ArticleTitle=Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 5
publish-date=10302009