Phát triển phần mềm thích ứng - Thực tiễn

Thực tiễn Phát triển phần mềm thích ứng được thúc đẩy bởi niềm tin vào sự thích ứng liên tục, với vòng đời được trang bị để chấp nhận sự thay đổi liên tục như một tiêu chuẩn.

Vòng đời phát triển phần mềm thích ứng dành riêng cho -

Học liên tục
Thay đổi hướng
Re-evaluation
Nhìn vào một tương lai không chắc chắn
Cộng tác mạnh mẽ giữa các nhà phát triển, ban quản lý và khách hàng

SDLC thích ứng

Phát triển phần mềm thích ứng kết hợp RAD với các phương pháp hay nhất về kỹ thuật phần mềm, chẳng hạn như -

Dự án ban đầu.
Lập kế hoạch chu trình thích ứng.
Kỹ thuật thành phần đồng thời.
Kiểm tra chất lượng.
QA cuối cùng và phát hành.

Các phương pháp phát triển phần mềm thích ứng có thể được minh họa như sau:

Như được minh họa ở trên, các phương pháp phát triển phần mềm thích ứng được trải rộng qua ba giai đoạn như sau:

Suy đoán - Khởi đầu và lập kế hoạch
- Dự án ban đầu
- Thiết lập hộp thời gian cho toàn bộ dự án
- Quyết định số lần lặp và chỉ định hộp thời gian cho mỗi lần lặp lại
- Phát triển một chủ đề hoặc mục tiêu cho mỗi lần lặp lại
- Gán các tính năng cho mỗi lần lặp lại
Collaborate - Phát triển tính năng đồng thời
- Cộng tác cho các nhóm phân tán
- Cộng tác cho các dự án nhỏ hơn
- Cộng tác cho các dự án lớn hơn
Learn - Đánh giá chất lượng
- Chất lượng kết quả từ quan điểm của khách hàng
- Chất lượng kết quả từ góc độ kỹ thuật
- Hoạt động của nhóm phân phối và các thành viên nhóm thực hành đang sử dụng
- Tình trạng dự án

Suy đoán - Khởi đầu và Lập kế hoạch

Trong Phát triển phần mềm thích ứng, giai đoạn suy đoán có hai hoạt động:

Initiation
Planning

Speculate có năm thực hành có thể được thực hiện lặp đi lặp lại trong giai đoạn bắt đầu và lập kế hoạch. Họ là -

Dự án ban đầu
Thiết lập hộp thời gian cho toàn bộ dự án
Quyết định số lần lặp và chỉ định hộp thời gian cho mỗi lần lặp lại
Phát triển một chủ đề hoặc mục tiêu cho mỗi lần lặp lại
Gán các tính năng cho mỗi lần lặp lại

Dự án ban đầu

Khởi xướng dự án bao gồm -

Đặt sứ mệnh và mục tiêu của dự án
Hiểu các ràng buộc
Thành lập tổ chức dự án
Xác định và phác thảo các yêu cầu
Lập ước tính kích thước và phạm vi ban đầu
Xác định các rủi ro chính của dự án

Dữ liệu bắt đầu dự án nên được thu thập trong một phiên JAD sơ bộ, coi tốc độ là khía cạnh chính. Việc khởi xướng có thể được hoàn thành trong nỗ lực tập trung từ hai đến năm ngày đối với các dự án quy mô vừa và nhỏ, hoặc nỗ lực từ hai đến ba tuần đối với các dự án lớn hơn.

Trong các phiên JAD, các yêu cầu được thu thập đủ chi tiết để xác định các tính năng và thiết lập tổng quan về đối tượng, dữ liệu hoặc mô hình kiến trúc khác.

Thiết lập hộp thời gian cho toàn bộ dự án

Hộp thời gian cho toàn bộ dự án phải được thiết lập dựa trên phạm vi, các yêu cầu thiết lập tính năng, ước tính và sự sẵn có của nguồn lực do công việc khởi động dự án.

Như bạn đã biết, Suy đoán không từ bỏ ước tính, nhưng nó chỉ có nghĩa là chấp nhận rằng các ước tính có thể sai.

Lặp lại và Hộp thời gian

Quyết định số lần lặp và độ dài lần lặp riêng dựa trên phạm vi dự án tổng thể và mức độ không chắc chắn.

Đối với ứng dụng có kích thước vừa và nhỏ -

Các lần lặp lại thường thay đổi từ bốn đến tám tuần.
Một số dự án hoạt động tốt nhất với hai tuần lặp lại.
Một số dự án có thể yêu cầu hơn tám tuần.

Chọn thời gian, dựa trên những gì phù hợp với bạn. Khi bạn quyết định số lần lặp và độ dài của mỗi lần lặp, hãy chỉ định lịch trình cho mỗi lần lặp.

Phát triển một Chủ đề hoặc Mục tiêu

Các thành viên trong nhóm nên phát triển một chủ đề hoặc mục tiêu cho mỗi lần lặp lại. Đây là một cái gì đó tương tự như Mục tiêu Sprint trong Scrum. Mỗi lần lặp lại phải cung cấp một tập hợp các tính năng có thể thể hiện chức năng của sản phẩm, làm cho sản phẩm hiển thị với khách hàng để cho phép đánh giá và phản hồi.

Trong các lần lặp lại, các bản dựng phải cung cấp các tính năng hoạt động tốt nhất là hàng ngày cho phép quá trình tích hợp và làm cho sản phẩm hiển thị với nhóm phát triển. Thử nghiệm phải là một phần liên tục, không thể thiếu của quá trình phát triển tính năng. Nó không nên được trì hoãn cho đến khi kết thúc dự án.

Chỉ định các tính năng

Các nhà phát triển và khách hàng nên cùng nhau gán các tính năng cho mỗi lần lặp lại. Tiêu chí quan trọng nhất để gán tính năng này là mỗi lần lặp lại phải cung cấp một tập hợp các tính năng có thể nhìn thấy với chức năng đáng kể cho khách hàng.

Trong quá trình gán các tính năng cho các lần lặp lại -

Nhóm phát triển nên đưa ra các ước tính về tính năng, rủi ro và sự phụ thuộc và cung cấp cho khách hàng.
Khách hàng nên quyết định ưu tiên tính năng, sử dụng thông tin do nhóm phát triển cung cấp.

Do đó, lập kế hoạch lặp lại dựa trên tính năng và được thực hiện như một nhóm với các nhà phát triển và khách hàng. Kinh nghiệm cho thấy kiểu lập kế hoạch này mang lại hiểu biết tốt hơn về dự án so với kiểu lập kế hoạch theo nhiệm vụ của người quản lý dự án. Hơn nữa, quy hoạch dựa trên tính năng phản ánh tính độc đáo của mỗi dự án.

Cộng tác ─ Phát triển tính năng đồng thời

Trong giai đoạn Cộng tác, trọng tâm là sự phát triển. Giai đoạn Cộng tác có hai hoạt động -

Nhóm Phát triển cộng tác và cung cấp phần mềm hoạt động.
Các nhà quản lý dự án tạo điều kiện cho các hoạt động hợp tác và phát triển đồng thời.

Cộng tác là một hành động tạo ra sự chia sẻ bao gồm nhóm phát triển, khách hàng và người quản lý. Sự sáng tạo được chia sẻ được nuôi dưỡng bởi sự tin tưởng và tôn trọng.

Các nhóm nên cộng tác trên -

Sự cố kỹ thuật
Yêu cầu kinh doanh
Ra quyết định nhanh chóng

Sau đây là các thực hành liên quan đến giai đoạn Hợp tác trong Phát triển Phần mềm Thích ứng -

Cộng tác cho các nhóm phân tán
Cộng tác cho các dự án nhỏ hơn
Cộng tác cho các dự án lớn hơn

Cộng tác cho các nhóm được phân phối

Trong các dự án liên quan đến các nhóm phân tán, cần xem xét những điều sau:

Thay đổi đối tác liên minh
Kiến thức rộng
Cách mọi người tương tác
Cách họ quản lý sự phụ thuộc lẫn nhau

Cộng tác cho các dự án nhỏ hơn

Trong các dự án nhỏ hơn, khi các thành viên trong nhóm đang làm việc gần nhau, nên khuyến khích cộng tác với các cuộc trò chuyện không chính thức ở hành lang và viết nguệch ngoạc trên bảng trắng, vì điều này được cho là có hiệu quả.

Cộng tác cho các dự án lớn hơn

Các dự án lớn hơn yêu cầu thực hành bổ sung, công cụ cộng tác và tương tác với người quản lý dự án và cần được sắp xếp trên cơ sở ngữ cảnh.

Tìm hiểu - Đánh giá Chất lượng

Phát triển phần mềm thích ứng khuyến khích khái niệm 'Thử nghiệm và Học hỏi'.

Rút kinh nghiệm từ những sai lầm và thử nghiệm yêu cầu các thành viên trong nhóm chia sẻ sớm mã và phần mềm đã hoàn thành một phần, để -

Tìm sai lầm
Học hỏi từ họ
Giảm công việc làm lại bằng cách tìm ra những vấn đề nhỏ trước khi chúng trở thành những vấn đề lớn

Vào cuối mỗi lần lặp lại phát triển, có bốn hạng mục chung cần học:

Chất lượng kết quả từ quan điểm của khách hàng
Chất lượng kết quả từ góc độ kỹ thuật
Hoạt động của nhóm phân phối và nhóm thực hành
Tình trạng dự án

Chất lượng kết quả từ quan điểm của khách hàng

Trong các dự án Phát triển Phần mềm Thích ứng, việc lấy ý kiến phản hồi từ khách hàng là ưu tiên hàng đầu. Thực hành được khuyến nghị cho điều này là một nhóm tập trung vào khách hàng. Các phiên này được thiết kế để khám phá mô hình hoạt động của ứng dụng và ghi lại các yêu cầu thay đổi của khách hàng.

Các phiên nhóm tập trung vào khách hàng là các phiên được tạo điều kiện, tương tự như phiên jad, nhưng thay vì tạo ra các yêu cầu hoặc xác định kế hoạch dự án, chúng được thiết kế để xem xét chính ứng dụng. Khách hàng cung cấp phản hồi về phần mềm đang hoạt động do lặp lại.

Chất lượng kết quả từ góc độ kỹ thuật

Trong các dự án Phát triển phần mềm thích ứng, việc xem xét định kỳ các hiện vật kỹ thuật nên được coi trọng. Việc đánh giá mã phải được thực hiện liên tục. Việc đánh giá các hiện vật kỹ thuật khác, chẳng hạn như kiến trúc kỹ thuật có thể được tiến hành hàng tuần hoặc vào cuối một lần lặp lại.

Trong các dự án Phát triển phần mềm thích ứng, nhóm nên theo dõi hiệu suất của chính mình theo định kỳ. Hồi tưởng khuyến khích các nhóm tìm hiểu về bản thân và công việc của họ, cùng nhau như một nhóm.

Các hồi cứu kết thúc lặp lại tạo điều kiện thuận lợi cho việc tự đánh giá hiệu suất nhóm định kỳ, chẳng hạn như -

Xác định những gì không hoạt động.
Những gì Đội cần làm thêm.
Những gì Đội cần làm ít hơn.

Tình trạng dự án

Việc xem xét tình trạng Dự án giúp lập kế hoạch cho công việc tiếp theo. Trong các dự án phát triển phần mềm thích ứng, việc xác định trạng thái dự án là cách tiếp cận dựa trên tính năng, phần cuối của mỗi lần lặp được đánh dấu bằng các tính năng đã hoàn thành dẫn đến phần mềm hoạt động.

Đánh giá Tình trạng Dự án nên bao gồm:

Dự án ở đâu?
Dự án ở đâu so với kế hoạch?
Dự án nên ở đâu?

Vì các kế hoạch trong các dự án Phát triển phần mềm thích ứng mang tính suy đoán, hơn câu hỏi 2 ở trên, câu hỏi 3 quan trọng. Có nghĩa là, nhóm dự án và khách hàng cần liên tục tự hỏi bản thân, "Chúng tôi đã học được gì cho đến nay, và nó có thay đổi quan điểm của chúng tôi về nơi chúng tôi cần đến không?"