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

Sử dụng các câu chuyện của người dùng để xác định các yêu cầu dự án

Trong Phần 4 của loạt bài này, hãy tìm hiểu về cách xác định yêu cầu trong một môi trường nhanh. Trong tất cả các dự án phát triển phần mềm, mọi thứ đều dựa vào các yêu cầu. Vì sự phát triển nhanh nhấn mạnh việc nói chuyện trực tiếp hơn các tài liệu văn bản và đón nhận các thay đổi vào cuối thời kỳ phát triển, các phương thức truyền thống với các yêu cầu bằng văn bản có thể không thích hợp. Trong bài viết này, hãy tìm hiểu các yêu cầu về nhanh và những câu chuyện của người sử dụng giúp mô tả chúng.

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

Như vậy đến nay 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 trong tổ chức sử dụng chúng. Bạn cũng đã học được cách các kiểu tổ chức khác nhau thích ứng với sự phát triển nhanh 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. Vào lúc này, bạn có thể tự hỏi bạn sẽ mô tả các yêu cầu nhanh trong một môi trường luôn thay đổi như thế nào.

Khi xử lý các yêu cầu, bạn cần phải lập kế hoạch các tính năng nào mà phần mềm sẽ có trong bản phát hành tiếp theo và trong tương lai. Hãy xem xét ba trường hợp:

  • Nếu một công ty đang phát triển sản phẩm riêng của mình trong thời gian ngắn hạn, như là thêm tính năng và hiểu người sử dụng muốn chúng như thế nào, thì các yêu cầu có thể khá đơn giản và được thảo luận khi chúng được phát triển.
  • Nếu công ty cần để tạo ra các bản đồ phát triển của các tính năng trong tương lai, thì họ cần phải có các công cụ để thảo luận về các nỗ lực làm việc, chi phí và các vấn đề thiết kế. Trong trường hợp này, mức độ chi tiết sẽ cao hơn.
  • Một công ty quyết định thuê gia công phát triển dự án bên ngoài. Một nhóm ở ngoài công ty sẽ làm công việc phát triển thực sự và người mua muốn có mức giá cố định cho sự thỏa thuận này.

Như các bạn đã học được ở các mục trước, các thoả thuận giá cố định và phát triển nhanh không ăn khớp tốt. Một sự lựa chọn tốt hơn là mua nhóm phát triển trong một khoảng thời gian nhất định và dùng nhóm đó để phát triển càng nhiều càng tốt như họ có thể làm trong các lần chạy nước rút ngắn. Ví dụ, nhóm có thể có ba thành viên với một khung thời gian sáu tháng. Trong thời gian này, nhóm có thể có thể thực hiện 10 lần chạy nước rút với mỗi lần là hai tuần.

Có hai kiểu khung thời gian cho các yêu cầu: ngắn hạn và dài hạn. Phát triển nhanh là tuyệt vời cho các yêu cầu ngắn hạn, bởi vì các yêu cầu có thể được thảo luận kỹ lưỡng trước khi chúng được thực hiện. Phát triển nhanh nhấn mạnh đến nói chuyện trực tiếp hơn các tài liệu bằng văn bản và đón nhận sự thay đổi. Với các dự án ngắn hạn, điều này tốt vì bạn chỉ cần xử lý lượng nhỏ các yêu cầu. Các câu chuyện của người dùng là tuyệt vời để nắm bắt các nhu cầu người sử dụng theo định dạng dễ hiểu.

Trong các dự án dài hạn, bạn cần để ý đến khả năng xảy ra thay đổi và xử lý các yêu cầu chỉ ở mức tổng quát. Các câu chuyện của người dùng cũng sử dụng trong trường hợp này. Nhưng bạn phải nhớ phạm vi thời gian và để lại những yêu cầu sẽ được thực hiện trong lần chạy nước rút sau với một mức độ trừu tượng hơn.

Chúng tôi sẽ lại sử dụng Scrum như là phương pháp luận tham khảo của chúng tôi. Xem Tài nguyên để biết thêm về Scrum.


Các yêu cầu nhanh

Phát triển nhanh nhấn mạnh đến nói chuyện trực tiếp hơn các tài liệu văn bản và đón nhận sự thay đổi ngay cả vào cuối giai đoạn phát triển. Trong thế giới không nhanh, các yêu cầu được thu thập, được ghi lại và được phân tích kỹ lưỡng trước khi bắt đầu phát triển. Các tài liệu này thường dài và các yêu cầu được mô tả chi tiết để đảm bảo rằng đã nắm bắt được các dữ liệu quan trọng. Trong một số trường hợp, người ghi chép lại của các yêu cầu không bao giờ gặp nhóm phát triển để thảo luận về các yêu cầu này và phần mềm. Đôi khi đây là tùy chọn duy nhất cho phép theo pháp luật, các hợp đồng, v.v.

Việc giới thiệu các thay đổi vào cuối giai đoạn phát triển trình bày những thách thức phát triển, chẳng hạn như việc quản lý thay đổi hoặc các vấn đề hợp đồng. Thay vì thực hiện một số thứ mà khách hàng thực sự mong muốn, trong kịch bản về trường hợp xấu nhất, khách hàng và nhà phát triển phải thương thảo lại hợp đồng. Việc thương thảo lại này dẫn đến tình huống mà, vào lúc bắt đầu phát triển, một số các yêu cầu là lỗi thời và các yêu cầu có mức ưu tiên cao và mức ưu tiên thấp được đối xử như nhau theo hợp đồng.

Trong sự phát triển nhanh, mục tiêu là để viết các yêu cầu theo cách như vậy mà các đại diện của cả khách hàng và các nhà phát triển có thể thảo luận về các yêu cầu hoặc chức năng. Việc thảo luận làm rõ các khả năng, những khó khăn và các chi phí cho khách hàng và nó chuyển tiếp tình huống nghiệp vụ cho các nhà phát triển. Thông qua thảo luận khách hàng có thể ưu tiên một số yêu cầu so với yêu cầu khác và nhóm phát triển có thể triển khai các mô tả chi tiết đối với yêu cầu quan trọng nhất trước khi chúng được thực hiện.

Điều gì sẽ xảy ra nếu các yêu cầu trong tương lai đòi hỏi một vài thứ không thể thực hiện được với kiến trúc hoặc sự lựa chọn công nghệ hiện có? Đó được coi là một sự thay đổi và phát triển nhanh đón nhận sự thay đổi. Nếu ba tháng trước đây người ta không biết đến các yêu cầu này hoặc trước đó mức ưu tiên của yêu cầu này đã không phải rất cao. Nếu sự thay đổi đòi hỏi các thay đổi rất nhiều trong phần mềm này, thì nó sẽ được thực hiện chỉ khi nó rất quan trọng đối với doanh nghiệp. Tri thức chuyên gia của nhóm phát triển đóng một vai trò quan trọng trong tình huống này. Kiến trúc phần mềm nên dễ sửa đổi và mở rộng trong tương lai. Một nhóm phát triển tốt bảo đảm rằng những thay đổi không lường trước sẽ yêu cầu thanh toán với khách hàng ít tới mức có thể.


Các câu chuyện của người dùng

Một câu chuyện của người dùng mô tả các chức năng mà người dùng muốn có trong phần mềm. Câu chuyện của người sử dụng bao gồm ba phần:

  • Một sự mô tả được viết ra.
  • Các cuộc đàm luận về câu chuyện với những người dùng.
  • Thử nghiệm có thể sử dụng để xác định rằng câu chuyện là hoàn thiện.

Các câu chuyện của người dùng thực hiện tốt nhất nếu người dùng viết ra chúng. Họ biết ngôn ngữ nghiệp vụ và họ có mối quan hệ mật thiết hơn với phần mềm này bởi vì họ sử dụng nó.

Khi kỹ thuật kể chuyện của người dùng đã được phát triển, mỗi câu chuyện đã được viết trên thẻ, nên chúng được gọi là các thẻ truyện. Các thẻ dễ dàng nhặt lên trong khi đang được thảo luận. Dễ dàng thêm vào các ý kiến và các thông tin chi tiết trên thẻ. Câu chuyện cũng được giới hạn về độ dài. Liệt kê 1 thể hiện một câu chuyện ví dụ của người dùng về một ứng dụng lập kế hoạch tài chính.

Liệt kê 1. Câu chuyện ví dụ của người dùng
A user adds a new budget to the system to start financial planning.

Yêu cầu ở đây là một người sử dụng phải có khả năng thêm một ngân sách mới cho hệ thống. Câu chuyện này đưa ra một số câu hỏi, chẳng hạn như:

  • Người sử dụng có cần đăng nhập không?
  • Các giá trị nào được lưu trữ về ngân sách? Tiêu đề? Thời gian khung? Tên của cá nhân?
  • Ai chịu trách nhiệm về ngân sách?

Rất nhiều lần, thông tin bổ sung thêm có thể được diễn tả như là các câu chuyện mới. Bạn cũng có thể thêm thông tin vào thẻ, chẳng hạn như “ Người dùng A thêm một ngân sách mới và cung cấp cho nó một tiêu đề”.

Câu chuyện người sử dụng không phải là một hợp đồng, tuy nhiên, vì thế bạn không nên lo lắng về việc đưa tất cả các chi tiết vào câu chuyện. Thay vào đó, bạn nên thảo luận về các chi tiết này với khách hàng và viết lại chúng trong các lần thử nghiệm. Nếu bạn đang sử dụng các thẻ, lật chúng lên và ghi ở mặt sau. Liệt kê 2 cho thấy một số lần thử nghiệm với câu chuyện của người dùng trong Liệt kê 1.

Liệt kê 2. Các thử nghiệm với câu chuyện ví dụ của người dùng
Add a new budget with title "Budget for 2008"?
Add a new budget with responsible person "Dave"?
Add a new budget with empty title?
Add a new budget with really long title?

Khi bạn xem các yêu cầu với khách hàng (hoặc một ủy quyền của khách hàng), bạn bắt đầu tạo một danh sách các yêu cầu. Trong Scrum, danh sách này có thể được coi như là công việc tồn đọng của sản phẩm, nó phải được ưu tiên và sau đó chia thành các lần chạy nước rút.

Cấu trúc sau đây là một khung công tác tốt để viết các câu chuyện của người dùng.

As a [Vai trò - type or role of user]
  
I want to [Nhiệm vụ - perform some task] 

So that I can [Mục tiêu - reach some goal]

Trong Liệt kê 1 bạn thấy rằng câu chuyện người dùng có vai trò của họ, nhiệm vụ và mục tiêu. Việc mô hình hóa vai trò người sử dụng là một phần quan trọng của việc thu thập các câu chuyện của người dùng. Bạn phải mô hình hóa các vai trò để tìm ra những giới hạn khác nào mà nhiệm vụ đó có thể có. Ví dụ, một câu chuyện của người dùng mô tả "việc liệt kê tất cả các ngân sách trong hệ thống" sẽ thực hiện hết sức khác nhau nếu người dùng đã là một quản trị viên công ty (người có thể xem tất cả các ngân sách của công ty), một người dùng cơ bản (người có thể chỉ xem chỉ ngân sách của riêng người dùng), hoặc người quản trị ứng dụng (những người có thể xem tất cả các ngân sách).

Các mục tiêu cũng rất quan trọng để hiểu biết miền của câu chuyện —tại sao người dùng muốn thực hiện nhiệm vụ đó. Trong câu chuyện ví dụ, mục tiêu là bắt đầu lập kế hoạch tài chính. Nó cung cấp cho các nhà phát triển nguyên nhân tại sao chức năng này quan trọng với người sử dụng.


Các đặc điểm của câu chuyện tốt của người dùng

Một câu chuyện tốt của người dùng được xác định bởi một vài đặc điểm:

Sự độc lập
Các câu chuyện nên có một vài sự phụ thuộc có thể được, bởi vì các sự phụ thuộc có thể gây ra các vấn đề theo ưu tiên. Ví dụ, nếu một có một mức ưu tiên cao và được kết nối đến một câu chuyện khác có một mức ưu tiên thấp, việc chọn các câu chuyện cho một lần chạy nước rút có thể khó khăn.

Một vấn đề khác phát sinh theo ước tính các nỗ lực làm việc. Nếu hai câu chuyện có các sự phụ thuộc trong việc thực hiện chúng, thì việc thực hiện câu chuyện đầu tiên có thể mất năm ngày và câu chuyện thứ hai có thể được thực hiện trong một ngày. Thật khó để đánh giá điều này bằng cách chỉ xem xét các câu chuyện.

Có thể đàm phán
Các câu chuyện không phải là các hợp đồng. Chúng được mô tả ngắn gọn về các chức năng và cần có cách nhắc nhở để thảo luận. Các chi tiết của các câu chuyện được thảo luận giữa khách hàng và nhóm phát triển.
Có thể định giá được
Các câu chuyện nên định giá được với một ai đó trong tổ chức của khách hàng (những người sử dụng, nhóm mua hàng, nhóm hỗ trợ, và v.v).
Có thể đánh giá được
Các nỗ lực làm việc rất quan trọng đối với việc lập kế hoạch nước rút, vì thế các nhà phát triển có khả năng đánh giá hoặc ít nhất phải đoán, những nỗ lực làm việc. Thường có ba lý do tại sao câu chuyện này không thể đánh giá được:
  • Các nhà phát triển không biết đầy đủ về miền lĩnh vực .
  • Các nhà phát triển không biết đầy đủ về công nghệ.
  • Câu chuyện đó quá lớn.
Tất cả những trở ngại này có thể được khắc phục để tránh những sai lầm lớn.
Bản tóm tắt
Các câu chuyện không nên quá dài. Nếu câu chuyện là quá ngắn, bạn không thể sử dụng nó trong việc lập kế hoạch. Độ dài của câu chuyện phần lớn phụ thuộc vào các kỹ năng và kinh nghiệm của nhóm phát triển, của các khách hàng và kinh nghiệm làm việc cùng nhau của họ.
Có thể thử nghiệm được
Tất cả các câu chuyện nên có thể thử nghiệm được để đảm bảo rằng chúng có thể được thực hiện. Như trong việc phát triển không nhanh, các vấn đề thử nghiệm xảy ra chủ yếu với các yêu cầu không theo chức năng hoặc các tiêu chí chất lượng (quality). Thực ra dễ dàng viết các yêu cầu không theo chức năng vì nó không đo đếm nên vì thế không thể thử nghiệm được. Nhà phát triển nên luôn luôn ghi nhớ điều này.

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 và các chức năng mà chủ sở hữu sản phẩm muốn có trong sản phẩm đó trong tương lai. Đối với mỗi lần chạy nước rút, một nhóm các chức năng được chọn từ công việc tồn đọng của sản phẩm và đặt nó trong công việc cần làm của lần chạy nước rút. Công việc cần làm của lần chạy nước rút sẽ được thực hiện trong lần chạy nước rút đó.

Để trợ giúp ước tính một câu chuyện của người dùng sẽ đòi hỏi có bao nhiêu việc, bạn có thể sử dụng các điểm câu chuyện hoặc các ngày làm việc. Mục tiêu là có một số phân loại ước tính có bao nhiêu công việc mà câu chuyện đòi hỏi có thể thực hiện một công việc tồn đọng của lần chạy nước rút hợp lý. Tất nhiên, các câu chuyện được bàn luận với nhóm phát triển trước khi họ đồng ý về nội dung của lần chạy nước rút đó. Nhóm phát triển này sau đó sắp xếp lại công việc tồn đọng của lần chạy nước rút bằng cách duyệt tất cả những câu chuyện của người sử dụng đã được lựa chọn và xác định các nhiệm vụ phát triển cần thiết để thực hiện chúng.


Kết luận

Trong bài viết này, bạn đã học được các yêu cầu nhanh khác với các yêu cầu truyền thống, được viết kỹ lưỡng trên văn bản như thế nào. Trong phát triển nhanh, các yêu cầu được thu thập theo một định dạng cho phép trợ giúp thay đổi và nói chuyện trực tiếp.

Các câu chuyện của người dùng đã trở thành một phương thức phổ biến để mô tả các yêu cầu trong các dự án nhanh. Các câu chuyện của người dùng là các câu chuyện ngắn, trả lời các câu hỏi cơ bản về ai, cái gì và tại sao. Các câu chuyện tốt của người dùng là độc lập, có thể đàm phán, có thể định giá và có thể thử được. Nếu nhóm phát triển đang sử dụng Scrum, thì công việc tồn đọng của sản phẩm trong Scrum chứa các chức năng trong tương lai (cơ bản là một danh sách các câu chuyện của người dùng).

Phần đăng tiếp theo trong loạt bài này, sẽ trình bày một câu chuyện ví dụ của người sử dụng và quy trình yêu cầu.

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 cho 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, 94.2008)
    • Phần 3, Vai trò của các bên liên quan về nhanh (developerWorks, 05.2008)
  • Đọc cuộ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.
  • 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=441876
ArticleTitle=Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 4
publish-date=10302009