Phát triển S / W Thích ứng - Hướng dẫn Nhanh

Agile là gì?

Theo thuật ngữ văn học, từ “nhanh nhẹn” có nghĩa là người có thể di chuyển nhanh chóng và dễ dàng hoặc người có thể suy nghĩ và hành động nhanh chóng và rõ ràng. Trong kinh doanh, “nhanh nhẹn” được sử dụng để mô tả các cách lập kế hoạch và thực hiện công việc, theo đó người ta hiểu rằng thực hiện các thay đổi khi cần thiết là một phần quan trọng của công việc. Kinh doanh “nhanh nhạy” có nghĩa là một công ty luôn ở trong tư thế sẵn sàng tính đến những thay đổi của thị trường.

Trong phát triển phần mềm, thuật ngữ “nhanh nhẹn” được điều chỉnh để có nghĩa là “khả năng đáp ứng với những thay đổi - những thay đổi từ Yêu cầu, Công nghệ và Con người”.

Tuyên ngôn Agile

Tuyên ngôn Agile được xuất bản bởi một nhóm các nhà phát triển phần mềm vào năm 2001, nêu bật tầm quan trọng của nhóm phát triển, đáp ứng các yêu cầu thay đổi và sự tham gia của khách hàng.

Tuyên ngôn Agile là -

Chúng tôi đang khám phá ra những cách tốt hơn để phát triển phần mềm bằng cách thực hiện nó và giúp những người khác làm điều đó. Thông qua công việc này, chúng tôi đã hiểu ra giá trị -

• Các cá nhân và tương tác qua các quy trình và công cụ.
• Phần mềm làm việc trên tài liệu toàn diện.
• Hợp tác với khách hàng trong quá trình đàm phán hợp đồng.
• Đáp ứng sự thay đổi so với việc tuân theo một kế hoạch.

Có nghĩa là, trong khi có giá trị trong các mục ở bên phải, chúng ta đánh giá các mục ở bên trái nhiều hơn.

Đặc điểm của sự nhanh nhẹn

Sau đây là các đặc điểm của Nhanh nhẹn -

• Sự nhanh nhẹn trong Phát triển Phần mềm Agile tập trung vào văn hóa của cả nhóm với các nhóm đa chức năng, đa ngành được trao quyền và tự tổ chức.

• Nó thúc đẩy trách nhiệm chung và trách nhiệm giải trình.

• Tạo điều kiện giao tiếp hiệu quả và cộng tác liên tục.

• Phương pháp tiếp cận toàn đội tránh sự chậm trễ và thời gian chờ đợi.

• Việc giao hàng thường xuyên và liên tục đảm bảo phản hồi nhanh chóng, từ đó cho phép nhóm phù hợp với các yêu cầu.

• Hợp tác tạo điều kiện cho việc kết hợp các quan điểm khác nhau kịp thời trong quá trình thực hiện, sửa chữa các khiếm khuyết và điều chỉnh các thay đổi.

• Tiến bộ là liên tục, bền vững và có thể dự đoán trước nhấn mạnh tính minh bạch.

phương pháp Agile

Việc triển khai sớm các phương pháp Agile bao gồm Quy trình hợp nhất Rational, Scrum, Crystal Clear, Lập trình cực đoan, Phát triển phần mềm thích ứng, Phát triển theo hướng tính năng và Phương pháp phát triển hệ thống động (DSDM). Hiện nay chúng được gọi chung là các phương pháp Agile, sau khi tuyên ngôn Agile được xuất bản vào năm 2001.

Trong hướng dẫn này, chúng ta sẽ tìm hiểu Phương pháp Agile - Adaptive Software Development.

Phát triển phần mềm thích ứng là gì?

Phát triển phần mềm thích ứng là một động thái hướng tới các thực hành thích ứng, bỏ các thực hành xác định trong bối cảnh các hệ thống phức tạp và môi trường phức tạp. Phát triển Phần mềm Thích ứng tập trung vào sự hợp tác và học hỏi như một kỹ thuật để xây dựng các hệ thống phức tạp. Nó được phát triển từ các phương pháp hay nhất của Phát triển ứng dụng nhanh (RAD) và Vòng đời tiến hóa. Sau đó, Phát triển Phần mềm Thích ứng đã được mở rộng để bao gồm các phương pháp tiếp cận thích ứng cho việc quản lý, với việc suy đoán thay thế Lập kế hoạch.

Jim Highsmith đã xuất bản một cuốn sách về Phát triển phần mềm thích ứng vào năm 2000. Theo lời của Highsmith -

“Phát triển phần mềm thích ứng có tính chu kỳ giống như mô hình tiến hóa, với các tên giai đoạn Suy đoán, cộng tác, học hỏi phản ánh lĩnh vực không thể đoán trước của các hệ thống ngày càng phức tạp. Sự phát triển thích ứng đi xa hơn di sản tiến hóa của nó theo hai cách quan trọng. Đầu tiên, nó thay thế rõ ràng thuyết tất định bằng thuyết xuất hiện. Thứ hai, nó vượt ra khỏi sự thay đổi trong Vòng đời cho đến sự thay đổi sâu sắc hơn trong phong cách quản lý. ”

Mô hình Vòng đời Phát triển Phần mềm (SDLC) là một khuôn khổ mô tả các hoạt động được thực hiện ở mỗi giai đoạn của một dự án phát triển phần mềm.

Trong Vòng đời phát triển phần mềm, các hoạt động được thực hiện trong năm giai đoạn:

• Requirements Gathering- Các yêu cầu đối với một phần mềm được phát triển được thu thập. Các yêu cầu này sẽ được sử dụng bằng ngôn ngữ mà khách hàng / người dùng hiểu được. Thuật ngữ tên miền cụ thể được khuyến khích.

• Analysis - Các yêu cầu tập hợp được phân tích từ quan điểm thực hiện và các đặc tả phần mềm được viết để bao hàm cả hai yêu cầu chức năng và yêu cầu phi chức năng.

• Design - Giai đoạn này bao gồm việc đạt được kiến ​​trúc phần mềm và các chi tiết triển khai cụ thể dựa trên công nghệ được chọn để phát triển.

• Construction - Trong giai đoạn này, mã được phát triển, kiểm tra đơn vị, tích hợp, kiểm tra tích hợp và bản dựng được sản xuất.

• Testing- Kiểm thử chức năng của phần mềm đã xây dựng được thực hiện trong giai đoạn này. Điều này cũng bao gồm việc kiểm tra các yêu cầu phi chức năng.

Có hai cách tiếp cận để thực hiện các hoạt động này -

• Prescriptive - Các mô hình SDLC sẽ cung cấp cho bạn các cách thức thực hiện các hoạt động theo cách quy định như được xác định bởi khuôn khổ.

• Adaptive- Các mô hình SDLC sẽ cung cấp cho bạn sự linh hoạt trong việc thực hiện các hoạt động, với các quy tắc nhất định cần được tuân thủ. Các phương pháp nhanh chủ yếu tuân theo cách tiếp cận này, với mỗi phương pháp có các quy tắc của nó. Tuy nhiên, theo cách tiếp cận thích ứng hoặc nhanh nhẹn không có nghĩa là phần mềm được phát triển mà không tuân theo bất kỳ kỷ luật nào. Điều này sẽ dẫn đến một sự hỗn loạn.

Bạn cần hiểu rằng chúng tôi không thể nói rằng một mô hình SDLC cụ thể là tốt hay xấu. Mỗi người trong số họ có điểm mạnh và điểm yếu riêng và do đó phù hợp trong bối cảnh nhất định.

Khi bạn chọn một mô hình SDLC cho dự án của mình, bạn cần hiểu -

• Bối cảnh tổ chức của bạn
• Bối cảnh công nghệ của bạn
• Thành phần nhóm của bạn
• Bối cảnh khách hàng của bạn

Ví dụ: nếu sự phát triển phần mềm có thể dự đoán được, bạn có thể sử dụng cách tiếp cận Theo quy định. Mặt khác, nếu việc phát triển phần mềm là không thể đoán trước, tức là các yêu cầu không được biết trước hoàn toàn, hoặc nhóm phát triển không tiếp xúc trước với miền hoặc công nghệ hiện tại, v.v. thì phương pháp tiếp cận thích ứng là lựa chọn tốt nhất.

Trong các phần sau, bạn sẽ hiểu các mô hình SDLC phổ biến nhất được phát triển trong quá trình thực hiện các dự án phát triển phần mềm trong toàn ngành. Bạn cũng sẽ biết được điểm mạnh và điểm yếu của từng người và họ phù hợp với bối cảnh nào.

Mô hình Waterfall là một mô hình SDLC cổ điển được nhiều người biết đến, hiểu và sử dụng phổ biến. Nó được Royce giới thiệu vào năm 1970 và vẫn đang được tuân theo như một cách tiếp cận chung để phát triển phần mềm trong các tổ chức khác nhau trong toàn ngành.

Trong mô hình Waterfall, mỗi giai đoạn vòng đời chỉ có thể bắt đầu sau khi giai đoạn vòng đời trước đó hoàn tất. Do đó, nó là một mô hình tuyến tính không có vòng phản hồi.

Mô hình thác nước - Điểm mạnh

Điểm mạnh của mô hình Waterfall là -

• Dễ hiểu, dễ sử dụng.
• Cung cấp cấu trúc cho nhóm phát triển thiếu kinh nghiệm.
• Các mốc quan trọng được hiểu rõ.
• Đặt yêu cầu ổn định.
• Lý tưởng cho việc kiểm soát quản lý (lập kế hoạch, giám sát, báo cáo).
• Hoạt động tốt khi chất lượng quan trọng hơn chi phí hoặc tiến độ.

Mô hình thác nước - Điểm yếu

Điểm yếu hoặc nhược điểm của mô hình Waterfall là -

• Lý tưởng hóa - Nó không phù hợp với thực tế.

• Không thực tế - không thể mong đợi các yêu cầu chính xác sớm trong dự án.

• Không phản ánh bản chất lặp đi lặp lại của sự phát triển khám phá phổ biến hơn.

• Khó khăn và tốn kém để thực hiện các thay đổi.

• Phần mềm chỉ được chuyển giao khi kết thúc dự án. Do điều này -

  • Chậm phát hiện ra các khiếm khuyết nghiêm trọng.

  • Khả năng cung cấp các yêu cầu lỗi thời.

• Chi phí quản lý đáng kể, có thể gây tốn kém cho các nhóm và dự án nhỏ.

• Yêu cầu nguồn lực có kinh nghiệm ở mọi giai đoạn - nhà phân tích, nhà thiết kế, nhà phát triển, người thử nghiệm.

• Thử nghiệm chỉ bắt đầu sau khi quá trình phát triển hoàn tất và người thử nghiệm không tham gia vào bất kỳ giai đoạn nào trước đó.

• Việc kiểm tra chuyên môn của các nhóm chức năng chéo không được chia sẻ vì mỗi giai đoạn được thực hiện trong các silo.

Khi nào thì sử dụng mô hình thác nước?

Bạn có thể sử dụng mô hình Waterfall nếu -

• Yêu cầu rất nổi tiếng.

• Định nghĩa sản phẩm là ổn định.

• Công nghệ được hiểu rõ.

• Phiên bản mới của một sản phẩm hiện có.

• Chuyển một sản phẩm hiện có sang một nền tảng mới.

• Tổ chức lớn với các nhóm chức năng chéo có cấu trúc.

• Các kênh liên lạc được thiết lập tốt trong tổ chức và với cả khách hàng.

Mô hình tạo mẫu tiến hóa

Trong quá trình phát triển phần mềm sử dụng mô hình Tạo mẫu Tiến hóa, các nhà phát triển xây dựng một nguyên mẫu trong giai đoạn yêu cầu. Người dùng cuối sau đó đánh giá nguyên mẫu và đưa ra phản hồi. Phản hồi có thể là các sửa đổi đối với nguyên mẫu hoặc chức năng bổ sung. Dựa trên phản hồi, các nhà phát triển sẽ tinh chỉnh thêm nguyên mẫu.

Do đó, sản phẩm phát triển thông qua Chu kỳ nguyên mẫu → Phản hồi → Chu kỳ nguyên mẫu tinh chỉnh và do đó có tên là Tạo mẫu tiến hóa. Khi người dùng hài lòng với chức năng và hoạt động của sản phẩm, mã nguyên mẫu được đưa đến các tiêu chuẩn bắt buộc để cung cấp sản phẩm cuối cùng.

Mô hình tạo mẫu tiến hóa - Điểm mạnh

Điểm mạnh hoặc lợi thế của mô hình Tạo mẫu tiến hóa là:

• Khách hàng / người dùng cuối có thể hình dung các yêu cầu hệ thống khi họ được thu thập khi xem xét nguyên mẫu.

• Các nhà phát triển học hỏi từ khách hàng và do đó không có sự mơ hồ nào về miền hoặc môi trường sản xuất.

• Cho phép thiết kế và phát triển linh hoạt.

• Tương tác với nguyên mẫu kích thích nhận thức về chức năng bổ sung cần thiết.

• Các yêu cầu bất ngờ và các thay đổi yêu cầu dễ dàng được đáp ứng

• Các dấu hiệu tiến bộ ổn định và rõ ràng được tạo ra.

• Cung cấp sản phẩm cuối cùng chính xác và có thể bảo trì.

Mô hình tạo mẫu tiến hóa - Điểm yếu

Những điểm yếu hoặc bất lợi của mô hình Tạo mẫu Tiến hóa như sau:

• Xu hướng từ bỏ phát triển có cấu trúc trong phát triển mã và sửa chữa, mặc dù nó không phải là những gì được quy định bởi mô hình.

• Mô hình này đã nhận được tiếng xấu cho các phương pháp nhanh chóng và bẩn thỉu.

• Khả năng bảo trì tổng thể có thể bị bỏ qua.

• Khách hàng có thể yêu cầu cung cấp nguyên mẫu cuối cùng, không tạo cơ hội cho các nhà phát triển thực hiện bước cuối cùng, tức là tiêu chuẩn hóa sản phẩm cuối cùng.

• Dự án có thể tiếp tục mãi mãi (với phạm vi thay đổi liên tục) và ban quản lý có thể không đánh giá cao nó.

Khi nào sử dụng mô hình tạo mẫu tiến hóa?

Bạn có thể sử dụng mô hình Tạo mẫu Tiến hóa -

• Khi yêu cầu không ổn định hoặc phải làm rõ
• Là giai đoạn làm rõ các yêu cầu của mô hình thác nước
• Để phát triển giao diện người dùng
• Đối với các cuộc biểu tình ngắn hạn
• Để phát triển mới hoặc ban đầu
• Để triển khai một công nghệ mới

Trong mô hình gia tăng lặp lại, ban đầu, việc triển khai từng phần của một hệ thống tổng thể được xây dựng để nó ở trạng thái có thể phân phối. Tăng cường chức năng được thêm vào. Các khiếm khuyết, nếu có, từ lần giao hàng trước được sửa chữa và sản phẩm đang hoạt động được chuyển giao. Quá trình này được lặp lại cho đến khi hoàn thành việc phát triển toàn bộ sản phẩm. Sự lặp lại của các quá trình này được gọi là lặp lại. Vào cuối mỗi lần lặp lại, phần gia tăng sản phẩm sẽ được phân phối.

Mô hình gia tăng lặp lại - Điểm mạnh

Ưu điểm hoặc điểm mạnh của mô hình Tăng dần lặp lại là:

• Bạn có thể phát triển các yêu cầu ưu tiên trước.

• Việc giao sản phẩm ban đầu nhanh hơn.

• Khách hàng nhận được chức năng quan trọng sớm.

• Giảm chi phí giao hàng ban đầu.

• Mỗi bản phát hành là một sản phẩm gia tăng, do đó khách hàng sẽ luôn có trong tay một sản phẩm hoạt động.

• Khách hàng có thể cung cấp phản hồi cho từng sản phẩm gia tăng, do đó tránh được những bất ngờ khi kết thúc quá trình phát triển.

• Các yêu cầu thay đổi có thể được điều chỉnh dễ dàng.

Mô hình gia tăng lặp lại - Điểm yếu

Nhược điểm của mô hình Tăng dần lặp lại là:

• Yêu cầu lập kế hoạch lặp lại hiệu quả.

• Yêu cầu thiết kế hiệu quả để đảm bảo bao gồm các chức năng cần thiết và cung cấp cho các thay đổi sau này.

• Yêu cầu định nghĩa sớm về một hệ thống đầy đủ và đầy đủ chức năng để cho phép xác định các gia số.

• Cần có các giao diện mô-đun được xác định rõ ràng, vì một số được phát triển rất lâu trước khi các giao diện khác được phát triển.

• Tổng chi phí của hệ thống hoàn chỉnh không thấp hơn.

Khi nào sử dụng mô hình gia tăng lặp lại?

Mô hình tăng dần lặp lại có thể được sử dụng khi -

• Hầu hết các yêu cầu đều được biết trước nhưng dự kiến ​​sẽ phát triển theo thời gian.

• Các yêu cầu được ưu tiên.

• Cần phải có được các chức năng cơ bản được phân phối nhanh chóng.

• Một dự án có lịch trình phát triển dài.

• Một dự án có công nghệ mới.

• Miền mới đối với nhóm.

Mô hình Phát triển Ứng dụng Nhanh (RAD) có các giai đoạn sau:

• Requirements Planning phase - Trong giai đoạn lập kế hoạch yêu cầu, aworkshop cần được tiến hành để thảo luận về các vấn đề kinh doanh một cách có cấu trúc.

• User Description phase - Trong giai đoạn Mô tả người dùng, các công cụ tự động được sử dụng để nắm bắt thông tin từ người dùng.

• Construction phase - Trong giai đoạn Xây dựng, các công cụ năng suất, chẳng hạn như trình tạo mã, trình tạo màn hình, v.v. được sử dụng bên trong hộp thời gian, với cách tiếp cận “Làm cho đến khi Hoàn thành”.

• Cut Over phase - Trong giai đoạn Cut over, cài đặt hệ thống, kiểm tra chấp nhận người dùng và đào tạo người dùng được thực hiện.

Mô hình phát triển ứng dụng nhanh chóng - Điểm mạnh

Những ưu điểm hoặc điểm mạnh của mô hình Phát triển Ứng dụng Nhanh như sau:

• Giảm thời gian chu kỳ và cải thiện năng suất với ít thành viên trong nhóm hơn sẽ có nghĩa là chi phí thấp hơn.

• Sự tham gia của khách hàng trong suốt chu trình hoàn chỉnh giảm thiểu rủi ro không đạt được sự hài lòng của khách hàng và giá trị kinh doanh.

• Tiêu điểm di chuyển đến mã ở chế độ bạn thấy-là-gì-bạn-nhận được (WYSIWYG). Điều này mang lại sự rõ ràng về những gì đang được xây dựng là điều đúng đắn.

• Sử dụng các khái niệm mô hình hóa để nắm bắt thông tin về kinh doanh, dữ liệu và quy trình.

Mô hình phát triển ứng dụng nhanh chóng - Điểm yếu

Những nhược điểm hoặc điểm mạnh của mô hình Phát triển Ứng dụng Nhanh như sau:

• Quá trình phát triển tăng tốc phải đưa ra phản hồi nhanh chóng cho người dùng.

• Rủi ro không bao giờ đạt được đóng cửa.

• Khó sử dụng với các hệ thống cũ.

• Các nhà phát triển và khách hàng phải cam kết thực hiện các hoạt động nhanh chóng trong một khung thời gian ngắn.

Khi nào thì sử dụng mô hình phát triển ứng dụng nhanh?

Mô hình phát triển ứng dụng nhanh có thể được sử dụng khi -

• Người dùng có thể được tham gia trong suốt vòng đời.
• Dự án có thể được đóng hộp thời gian.
• Chức năng có thể được cung cấp theo từng bước.

Mặc dù các điểm mạnh của mô hình Phát triển ứng dụng nhanh được đánh giá cao, nhưng nó được sử dụng rất ít trong ngành.

Mô hình xoắn ốc bổ sung Phân tích rủi ro và tạo mẫu RAD vào mô hình Thác nước. Mỗi chu trình bao gồm trình tự các bước giống như mô hình Waterfall.

Mô hình xoắn ốc có bốn góc phần tư. Hãy để chúng tôi thảo luận chi tiết về chúng.

Góc phần tư 1 - Xác định mục tiêu, lựa chọn thay thế và ràng buộc

• Objectives - Chức năng, hiệu suất, giao diện phần cứng / phần mềm, các yếu tố thành công quan trọng, v.v.

• Alternatives - Xây dựng, tái sử dụng, mua, hợp đồng phụ, v.v.

• Constraints - Chi phí, lịch trình, giao diện, v.v.

Góc phần tư 2 - Đánh giá các giải pháp thay thế, xác định và giải quyết rủi ro

• Nghiên cứu các giải pháp thay thế liên quan đến các mục tiêu và ràng buộc đã được xác định.

• Xác định các rủi ro như thiếu kinh nghiệm, công nghệ mới, lịch trình chặt chẽ, v.v.

• Giải quyết các rủi ro đã xác định đánh giá tác động của chúng đối với dự án, xác định các kế hoạch giảm thiểu và dự phòng cần thiết và thực hiện chúng. Rủi ro luôn cần được theo dõi.

Góc phần tư 3 - Phát triển sản phẩm cấp độ tiếp theo

Các hoạt động tiêu biểu bao gồm -

• Tạo một thiết kế
• Xem lại thiết kế
• Phát triển mã
• Kiểm tra mã
• Sản phẩm thử nghiệm

Góc phần tư 4 - Lập kế hoạch cho giai đoạn tiếp theo

Các hoạt động tiêu biểu bao gồm -

• Xây dựng kế hoạch dự án
• Phát triển kế hoạch quản lý cấu hình
• Xây dựng kế hoạch kiểm tra
• Phát triển kế hoạch cài đặt

Mô hình xoắn ốc - Điểm mạnh

Ưu điểm hoặc điểm mạnh của phương pháp Xoắn ốc là:

• Cung cấp dấu hiệu sớm về các rủi ro mà không tốn nhiều chi phí.
• Người dùng có thể xem hệ thống sớm nhờ các công cụ tạo mẫu nhanh.
• Các chức năng rủi ro cao quan trọng được phát triển trước.
• Thiết kế không cần phải hoàn hảo.
• Người dùng có thể tham gia chặt chẽ vào tất cả các bước của vòng đời.
• Phản hồi sớm và thường xuyên từ người dùng.
• Chi phí tích lũy được đánh giá thường xuyên.

Mô hình xoắn ốc - Điểm yếu

Những nhược điểm hoặc điểm yếu của phương pháp Xoắn ốc là:

• Có thể khó xác định các mục tiêu, các cột mốc có thể kiểm chứng được cho thấy sự sẵn sàng để tiến hành trong lần lặp tiếp theo.

• Thời gian dành cho việc lập kế hoạch, thiết lập lại các mục tiêu, thực hiện phân tích rủi ro và tạo mẫu có thể là một chi phí lớn.

• Thời gian dành cho việc đánh giá rủi ro có thể quá lớn đối với các dự án nhỏ hoặc rủi ro thấp.

• Mô hình xoắn ốc rất phức tạp để hiểu đối với các thành viên mới trong nhóm.

• Cần phải có chuyên môn đánh giá rủi ro.

• Xoắn ốc có thể tiếp tục vô thời hạn.

• Các nhà phát triển phải được chỉ định lại trong các hoạt động của giai đoạn không phát triển.

Khi nào thì sử dụng mô hình xoắn ốc?

Mô hình xoắn ốc có thể được sử dụng khi -

• Việc tạo ra một nguyên mẫu là thích hợp.
• Đánh giá rủi ro là quan trọng.
• Một dự án có rủi ro trung bình đến cao.
• Người dùng không chắc chắn về nhu cầu của họ.
• Yêu cầu rất phức tạp.
• Dòng sản phẩm là mới.
• Dự kiến ​​sẽ có những thay đổi đáng kể trong quá trình thăm dò.
• Cam kết dự án dài hạn không khôn ngoan vì có thể có những thay đổi trong kinh doanh.

Các phương pháp Agile dựa trên tuyên ngôn Agile và có tính chất thích ứng. Các phương pháp Agile đảm bảo -

• Hợp tác nhóm.
• Sự hợp tác của khách hàng.
• Giao tiếp liên tục và liên tục.
• Phản ứng với những thay đổi.
• Sự sẵn sàng của một sản phẩm đang hoạt động.

Một số phương pháp Agile đã ra đời, thúc đẩy sự phát triển lặp đi lặp lại và gia tăng với các lần lặp theo hộp thời gian. Mặc dù các phương pháp Agile là thích ứng, nhưng các quy tắc của phương pháp cụ thể không thể được thông qua và do đó yêu cầu thực hiện có kỷ luật.

Phương pháp Agile - Điểm mạnh

Ưu điểm hoặc điểm mạnh của phương pháp Agile là:

• Bản phát hành sớm và thường xuyên.
• Chỗ ở của các yêu cầu thay đổi.
• Giao tiếp hàng ngày giữa khách hàng và nhà phát triển.
• Các dự án được xây dựng xung quanh những cá nhân có động lực.
• Các đội tự tổ chức.
• Sự đơn giản, tập trung vào những gì được yêu cầu ngay lập tức.
• Không xây dựng cho tương lai hoặc làm quá tải mã.
• Thường xuyên phản ánh để điều chỉnh hành vi nhằm nâng cao hiệu quả.

Phương pháp Agile - Điểm yếu

Nhược điểm hoặc điểm yếu của phương pháp Xoắn ốc là:

• Tính khả dụng của khách hàng có thể không thực hiện được.

• Các đội nên có kinh nghiệm để tuân theo các quy tắc của phương pháp.

• Cần phải có kế hoạch phù hợp để nhanh chóng quyết định chức năng cần được phân phối trong một lần lặp lại.

• Nhóm được yêu cầu có kỹ năng ước lượng và kỹ năng đàm phán.

• Nhóm cần có kỹ năng giao tiếp hiệu quả.

• Các đội mới có thể không tự tổ chức được.

• Yêu cầu kỷ luật để phát triển và cung cấp trong các lần lặp lại trong hộp thời gian.

• Thiết kế cần được giữ đơn giản và có thể bảo trì, do đó đòi hỏi kỹ năng thiết kế hiệu quả.

Khi nào sử dụng phương pháp Agile?

Các phương pháp Agile có thể được sử dụng khi -

• Ứng dụng rất quan trọng về thời gian.

• Phạm vi bị hạn chế và ít chính thức hơn (mở rộng các phương pháp nhanh đến các dự án lớn hơn đang được tiến hành, với một số phần mở rộng nhất định cho một số phương pháp nhanh).

• Tổ chức sử dụng các phương pháp kỷ luật.

Các mô hình SDLC trước đó hướng nhiều hơn đến các hoạt động ổn định, khả năng dự đoán và giảm lợi nhuận. Ngành công nghiệp, chẳng hạn như Nền tảng Internet đã và đang tăng cường các môi trường quay trở lại, các phương pháp tiếp cận không thể đoán trước, phi tuyến tính và nhanh chóng.

Phát triển phần mềm thích ứng (ASD) đã phát triển để giải quyết những vấn đề này. Nó tập trung vào sự nổi lên như là yếu tố quan trọng nhất từ ​​quan điểm của quản lý, để nâng cao khả năng quản lý phát triển sản phẩm.

Theo lời của Jim Highsmith, “Khung Phát triển Phần mềm Thích ứng dựa trên nhiều năm kinh nghiệm với các phương pháp Phát triển Phần mềm truyền thống, tư vấn, thực hành và viết về các kỹ thuật Phát triển Ứng dụng Nhanh (RAD) và làm việc với các công ty phần mềm công nghệ cao để quản lý phát triển sản phẩm của họ thực hành ”.

Mô hình thác nước được đặc trưng bởi tính tuyến tính và khả năng dự đoán, với phản hồi ít ỏi. Nó có thể được xem như một chuỗi cácPlan → Build → Implement.

Các mô hình Vòng đời tiến hóa như mô hình Xoắn ốc đã chuyển phương pháp Tiếp cận Xác định sang Phương pháp Thích nghi, với Plan → Build → Revise Cycles.

Tuy nhiên, tư duy của các học viên vẫn mang tính Xác định với khả năng dự đoán dài hạn chuyển sang khả năng dự đoán ngắn hạn. Thực hành của các mô hình Vòng đời tiến hóa như RAD được cho là ít mang tính xác định hơn.

Vòng đời thích ứng

Mô hình Thích ứng được xây dựng theo một quan điểm khác. Mặc dù theo chu kỳ giống như mô hình Tiến hóa, tên của giai đoạn phản ánh bản chất không thể đoán trước của các hệ thống ngày càng phức tạp.

Phát triển thích ứng đi xa hơn di sản tiến hóa của nó theo hai cách chính:

• Nó thay thế rõ ràng Chủ nghĩa Quyết định bằng Sự Xuất hiện.

• Nó vượt ra khỏi sự thay đổi trong vòng đời đến sự thay đổi sâu sắc hơn trong phong cách quản lý.

Ba giai đoạn trong Vòng đời phát triển phần mềm thích ứng là:

• Speculate - Suy đoán thay thế cho việc lập kế hoạch từ xác định, lập kế hoạch các đặc tính sản phẩm hoặc lập kế hoạch các nhiệm vụ quản lý dự án.

• Collaborate - Cộng tác thể hiện sự cân bằng giữa

  • Quản lý theo nghĩa quản lý dự án truyền thống, và

  • Tạo và duy trì môi trường hợp tác cần thiết cho sự xuất hiện.

Hoạt động Hợp tác xây dựng sản phẩm, theo kịp tốc độ thay đổi của môi trường.

• Learn - Tìm hiểu nhằm mục đích cả nhà phát triển và khách hàng, sử dụng kết quả của mỗi chu kỳ phát triển để tìm hiểu hướng đi tiếp theo.

Trong chương này, chúng ta sẽ hiểu các khái niệm khác nhau về Phát triển phần mềm thích ứng.

Lý thuyết hệ thống thích ứng phức tạp (CAS)

Brian Arthur và các đồng nghiệp của ông, tại viện Santa Fe, đã sử dụng lý thuyết Hệ thống thích ứng phức tạp (CAS) để cách mạng hóa sự hiểu biết về Vật lý, Sinh học, Tiến hóa và Kinh tế.

Brian Arthur đã lên đến đỉnh điểm trong hơn hai thập kỷ cố gắng thuyết phục các nhà kinh tế học chính thống rằng quan điểm của họ, bị chi phối bởi các giả định cơ bản về giảm lợi nhuận, cân bằng và động lực xác định, không còn đủ để hiểu thực tế. Thế giới mới là một trong những trở lại ngày càng tăng, sự bất ổn định và không thể xác định được nguyên nhân và kết quả.

Hai thế giới khác nhau về hành vi, phong cách và văn hóa. Họ kêu gọi -

• Các kỹ thuật quản lý khác nhau
• Các chiến lược khác nhau
• Hiểu biết khác nhau

Phát triển phần mềm phức hợp

Với phạm vi Ứng dụng phần mềm đang bùng nổ, ngay cả các tổ chức phát triển phần mềm cũng đang tích lũy những mâu thuẫn tương tự như đã đề cập ở trên.

• Một Thế giới được đại diện bởi sự phát triển Xác định, bắt nguồn từ các thực tiễn quản lý bắt nguồn từ những điều cơ bản về sự ổn định và khả năng dự đoán (theo thuật ngữ của Arthur có nghĩa là lợi nhuận giảm dần)

• Thế giới thứ hai được đại diện bởi các ngành công nghiệp chuyển từ môi trường giảm dần sang tăng trở lại, không thể đoán trước, phi tuyến tính và nhanh chóng.

Để giải quyết các vấn đề của thế giới thứ hai này, Jig Highsmith đã đưa ra một khuôn khổ, Phát triển phần mềm thích ứng, khác với Phát triển phần mềm xác định.

Phát triển phần mềm thích ứng tập trung vào việc giải quyết các hệ thống phức tạp -

• Phát triển phần mềm thích ứng cho vòng đời phát triển.

• Kỹ thuật Quản lý Thích ứng kêu gọi một tư duy khác với tư duy của các phương pháp quản lý dự án truyền thống.

Trong hướng dẫn này, bạn có thể hiểu cả hai cách triển khai này.

Phát triển phần mềm thích ứng (ASD) dựa trên hai quan điểm -

• Quan điểm khái niệm dựa trên lý thuyết Hệ thống thích ứng phức tạp (CAS), như được đưa ra trong phần đầu tiên của chương này.

• Quan điểm thực tế dựa trên

  • Nhiều năm kinh nghiệm với các phương pháp luận phát triển phần mềm xác định.

  • Tư vấn, thực hành và viết về các kỹ thuật Phát triển Ứng dụng Nhanh (RAD); và làm việc với các công ty phần mềm công nghệ cao để quản lý việc phát triển sản phẩm của họ.

Trong chương này, bạn sẽ hiểu quan điểm khái niệm của Phát triển phần mềm thích ứng.

Các khái niệm về hệ thống thích ứng phức tạp (CAS)

Lý thuyết Hệ thống thích ứng phức tạp (CAS) có nhiều khái niệm. Phát triển phần mềm thích ứng dựa trên hai khái niệm sau:

• Emergence
• Complexity

Sự xuất hiện

Trong các dự án phát triển sản phẩm phần mềm phức tạp, kết quả là không thể đoán trước được. Tuy nhiên, các sản phẩm thành công luôn xuất hiện từ những môi trường như vậy.

Điều này có thể xảy ra bởi Sự xuất hiện, như được minh họa trong lý thuyết Hệ thống thích ứng phức tạp (CAS). Nó có thể được hiểu bằng một ví dụ đơn giản, hành vi bầy đàn của các loài chim.

Khi bạn quan sát một đàn chim, bạn nhận thấy rằng -

• Mỗi con chim cố gắng

  • Duy trì khoảng cách tối thiểu với các vật thể khác trong môi trường, kể cả các loài chim khác.

  • Khớp vận tốc với các loài chim trong khu vực lân cận.

  • Di chuyển về phía trung tâm có thể nhận thấy của khối lượng chim trong khu vực lân cận.

• Không có quy tắc hành vi nào cho nhóm. Các quy tắc duy nhất là về hành vi của từng loài chim.

• Tuy nhiên, tồn tại một tập tính nổi lên là bầy chim. Khi những con chim sai lầm lao tới đuổi kịp, đàn chia nhau xung quanh chướng ngại vật và cải tổ ở phía bên kia.

Điều này cho thấy yêu cầu của những thay đổi mô hình tinh thần khó khăn nhất trong Phát triển thích ứng - Từ cách quản lý và tổ chức sự tự do cá nhân đó cho đến quan niệm rằng một trật tự mới sáng tạo xuất hiện không thể đoán trước từ quá trình tự tổ chức tự phát.

Ngoài sự phát triển, sự nổi lên là khái niệm quan trọng nhất từ ​​góc độ quản lý cũng.

Phức tạp

Trong bối cảnh Phát triển Phần mềm, Độ phức tạp là về -

• Các cá nhân của một nhóm như nhà phát triển, khách hàng, nhà cung cấp, đối thủ cạnh tranh và người nắm giữ cổ phiếu, số lượng và tốc độ của họ.

• Kích thước và độ phức tạp công nghệ.

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

Phát triển phần mềm thích ứng cung cấp một quan điểm khác về thực tiễn quản lý phần mềm. Trong các phần bên dưới, bạn có thể hiểu hai thực hành quan trọng - Chất lượng và RAD, cả hai đều có các phân nhánh để thu thập các yêu cầu.

Bạn có thể tìm thấy chi tiết của tất cả các phương pháp trong chương, Các phương pháp phát triển phần mềm thích ứng trong hướng dẫn này.

Chất lượng

Trong một môi trường phức tạp, thực hành lâu đời "Làm đúng ngay lần đầu tiên" không hiệu quả vì bạn không thể đoán trước điều gì là đúng ngay từ đầu. Bạn cần phải có mục tiêu để tạo ra giá trị phù hợp. Tuy nhiên, trong môi trường phức tạp, sự kết hợp và hoán vị của các thành phần giá trị như phạm vi (tính năng, hiệu suất, mức độ lỗi), lịch trình và tài nguyên là rất lớn nên không bao giờ có thể có một giá trị tối ưu. Do đó, trọng tâm là chuyển đổi để mang lại giá trị tốt nhất trong thị trường cạnh tranh.

Thực hành RAD

Thực tiễn RAD thường bao gồm sự kết hợp của những điều sau:

• Vòng đời tiến hóa
• Nhóm tập trung vào khách hàng, Phiên JAD, Đánh giá kỹ thuật
• Quản lý dự án theo hộp thời gian
• Kỹ thuật phần mềm liên tục
• Đội chuyên dụng có phòng chiến

Các dự án RAD có một hương vị nổi bật, thích ứng vốn có. Nhiều tổ chức CNTT đang chống lại RAD. Tuy nhiên, Microsoft và những người khác đã sản xuất phần mềm cực kỳ lớn và phức tạp bằng cách sử dụng các kỹ thuật tương đương với RAD vì nó đặt ra câu hỏi về thế giới quan cơ bản của họ.

Thực hành RAD và quy trình của Microsoft đều là những ví dụ về Phát triển thích ứng trong thực tế. Việc gắn cho họ một nhãn hiệu (tức là Phát triển thích ứng) và nhận ra rằng ngày càng có nhiều kiến ​​thức khoa học (tức là lý thuyết CAS) giải thích tại sao chúng hoạt động. Điều này sẽ tạo cơ sở cho việc sử dụng rộng rãi hơn các thực hành này.

Phát triển phần mềm thích ứng đã phát triển từ thực tiễn RAD. Các khía cạnh của nhóm cũng được thêm vào các hoạt động này. Các công ty từ New Zealand đến Canada, đối với nhiều loại dự án và sản phẩm, đã sử dụng Phát triển phần mềm thích ứng.

Jim Highsmith xuất bản Phát triển phần mềm thích ứng vào năm 2000.

Thực tiễn Phát triển Phần mềm Thích ứng cung cấp khả năng thích ứng với sự thay đổi và có thể thích ứng trong môi trường hỗn loạn với các sản phẩm phát triển mà không cần lập kế hoạch và học hỏi.

Các giai đoạn của Vòng đời ASD

Phát triển phần mềm thích ứng có tính chu kỳ giống như mô hình Tiến hóa, với các tên giai đoạn phản ánh tính không thể đoán trước trong các hệ thống phức tạp. Các giai đoạn trong vòng đời Phát triển thích ứng là -

• Speculate
• Collaborate
• Learn

Ba giai đoạn này phản ánh bản chất năng động của Phát triển phần mềm thích ứng. Sự Phát triển Thích ứng thay thế rõ ràng Chủ nghĩa Quyết đoán bằng Sự nổi lên. Nó vượt ra khỏi sự thay đổi đơn thuần trong vòng đời mà còn là sự thay đổi sâu sắc hơn trong phong cách quản lý. Phát triển phần mềm thích ứng có Vòng đời suy đoán-cộng tác-học hỏi năng động.

Vòng đời phát triển phần mềm thích ứng tập trung vào kết quả, không phải nhiệm vụ và kết quả được xác định là các tính năng ứng dụng.

Suy đoán

Kế hoạch kỳ hạn quá xác định và cho thấy mức độ chắc chắn khá cao về kết quả mong muốn. Mục tiêu ngầm định và rõ ràng về việc tuân thủ kế hoạch, hạn chế khả năng của người quản lý trong việc điều hành dự án theo các hướng đổi mới.

Trong Phát triển phần mềm thích ứng, kế hoạch thuật ngữ được thay thế bằng thuật ngữ suy đoán. Trong khi suy đoán, nhóm nghiên cứu không từ bỏ kế hoạch, nhưng họ thừa nhận thực tế không chắc chắn trong các vấn đề phức tạp. Suy đoán khuyến khích khám phá và thử nghiệm. Khuyến khích lặp lại với chu kỳ ngắn.

Hợp tác

Các ứng dụng phức tạp không được xây dựng, chúng phát triển. Các ứng dụng phức tạp đòi hỏi một khối lượng lớn thông tin được thu thập, phân tích và áp dụng cho vấn đề. Môi trường hỗn loạn có tốc độ dòng thông tin cao. Do đó, các ứng dụng phức tạp đòi hỏi một khối lượng lớn thông tin được thu thập, phân tích và áp dụng cho vấn đề. Điều này dẫn đến các yêu cầu về Kiến thức đa dạng mà chỉ có thể được giải quyết bằng cách hợp tác nhóm.

Cộng tác sẽ yêu cầu khả năng làm việc chung để tạo ra kết quả, chia sẻ kiến ​​thức hoặc đưa ra quyết định.

Trong bối cảnh quản lý dự án, Sự hợp tác thể hiện sự cân bằng giữa việc quản lý bằng các kỹ thuật quản lý truyền thống và việc tạo ra và duy trì môi trường hợp tác cần thiết cho sự xuất hiện.

Học hỏi

Phần Tìm hiểu của Vòng đời rất quan trọng cho sự thành công của dự án. Nhóm phải liên tục nâng cao kiến ​​thức của họ, sử dụng các phương pháp như -

• Đánh giá kỹ thuật
• Những điều tra về dự án
• Nhóm khách hàng tập trung

Đánh giá nên được thực hiện sau mỗi lần lặp lại. Cả nhà phát triển và khách hàng đều kiểm tra các giả định của họ và sử dụng kết quả của mỗi chu kỳ phát triển để tìm hiểu hướng đi tiếp theo. Nhóm tìm hiểu -

• Về thay đổi sản phẩm

• Những thay đổi cơ bản hơn trong các giả định cơ bản về cách sản phẩm đang được phát triển

Các lần lặp lại cần phải ngắn để nhóm có thể học hỏi từ những sai lầm nhỏ thay vì lớn.

Suy đoán - Cộng tác - Tìm hiểu toàn bộ chu trình

Khi bạn quan sát từ chu trình Suy đoán-Cộng tác-Tìm hiểu, được đưa ra ở trên, rõ ràng là ba giai đoạn là phi tuyến và chồng chéo.

Chúng tôi quan sát những điều sau đây từ một khung Thích ứng.

• Rất khó để Hợp tác mà không Học hỏi hoặc Học mà không Cộng tác.

• Rất khó để suy đoán mà không học hoặc để tìm hiểu mà không suy đoán.

• Rất khó để suy đoán mà không cộng tác hoặc cộng tác mà không suy đoán.

Vòng đời phát triển phần mềm thích ứng có sáu đặc điểm cơ bản:

• Nhiệm vụ tập trung
• Dựa trên tính năng
• Iterative
• Time-boxed
• Định hướng rủi ro
• Thay đổi sự khoan dung

Trong chương này, bạn sẽ hiểu sáu đặc điểm này của Phát triển phần mềm thích ứng.

Tập trung vào sứ mệnh

Đối với nhiều dự án, nhiệm vụ tổng thể hướng dẫn nhóm đã được trình bày rõ ràng, mặc dù các yêu cầu có thể không chắc chắn khi bắt đầu dự án. Tuyên bố sứ mệnh đóng vai trò như những hướng dẫn khuyến khích sự khám phá ngay từ đầu nhưng có trọng tâm hẹp trong suốt quá trình của một dự án. Một nhiệm vụ cung cấp ranh giới hơn là một điểm đến cố định. Các tuyên bố sứ mệnh và các cuộc thảo luận dẫn đến các tuyên bố đó cung cấp định hướng và tiêu chí để đưa ra các quyết định đánh đổi dự án quan trọng.

Nếu không có nhiệm vụ rõ ràng và thực hành tinh chỉnh nhiệm vụ liên tục, các vòng đời lặp đi lặp lại trở thành các vòng đời dao động, lắc lư qua lại mà không có sự tiến bộ nào trong quá trình phát triển.

Dựa trên tính năng

Vòng đời phát triển phần mềm thích ứng dựa trên các tính năng của ứng dụng chứ không dựa trên nhiệm vụ. Tính năng là chức năng được phát triển trong một lần lặp lại dựa trên các ưu tiên của khách hàng.

Các tính năng có thể phát triển qua nhiều lần lặp lại khi khách hàng cung cấp phản hồi.

Các tính năng ứng dụng cung cấp kết quả trực tiếp cho khách hàng sau khi thực hiện là chính. Một tài liệu hướng tới khách hàng như sách hướng dẫn sử dụng cũng được coi là một tính năng. Các tài liệu khác, chẳng hạn như mô hình dữ liệu, ngay cả khi được định nghĩa là tài liệu phân phối luôn chỉ là thứ yếu.

Lặp đi lặp lại

Vòng đời phát triển phần mềm thích ứng là lặp đi lặp lại và tập trung vào các bản phát hành thường xuyên để thu thập phản hồi, đồng hóa kết quả học tập và thiết lập hướng đi đúng để phát triển hơn nữa.

Hộp thời gian

Trong Vòng đời phát triển phần mềm thích ứng, các lần lặp lại được đóng hộp theo thời gian. Tuy nhiên, người ta nên nhớ rằng tính thời gian trong Phát triển phần mềm thích ứng không phải về thời hạn. Nó không nên được sử dụng để làm cho nhóm làm việc trong nhiều giờ thách thức một môi trường cộng tác hoặc làm ảnh hưởng đến chất lượng của các sản phẩm được giao.

Trong Phát triển phần mềm thích ứng, tính thời gian được coi là một hướng để tập trung và buộc phải đưa ra các quyết định cân bằng khó khăn khi cần thiết. Trong một môi trường không chắc chắn, trong đó tỷ lệ thay đổi cao, cần phải có một chức năng bắt buộc định kỳ như hộp thời gian để hoàn thành công việc.

Định hướng rủi ro

Trong Phát triển phần mềm thích ứng, các lần lặp lại được thúc đẩy bằng cách xác định và đánh giá các rủi ro quan trọng.

Chịu được thay đổi

Phát triển phần mềm thích ứng có khả năng chịu thay đổi, coi thay đổi là khả năng kết hợp lợi thế cạnh tranh, nhưng không phải là vấn đề đối với sự phát triể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 thực hành Phát triển Phần mềm Thích ứng được trải rộng trong 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

  • 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
• 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 nên đượ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 là kết quả của công việc bắt đầu 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 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. Sau 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. Không nên 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 chúng 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 rằng kiểu lập kế hoạch này cung cấp sự hiểu biết về dự án tốt hơn kiểu lập kế hoạch dựa trên 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 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à phải đượ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 lỗi
• 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 danh 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 đánh giá đị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 của 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ác 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?"

Sơ đồ về quản lý phần mềm truyền thống được hiển thị bên dưới.

Quản lý phần mềm truyền thống đã được đặc trưng bởi thuật ngữ điều khiển lệnh.

Nhiều tổ chức có truyền thống tối ưu hóa, hiệu quả, khả năng dự đoán, kiểm soát, tính chặt chẽ và cải tiến quy trình. Tuy nhiên, nền kinh tế thời đại thông tin mới nổi đòi hỏi khả năng thích ứng, tốc độ, hợp tác, ứng biến, linh hoạt, đổi mới và dẻo dai.

Sách về quản lý và đánh giá kinh doanh của Harvard đã đưa ra các thuật ngữ như trao quyền, quản lý có sự tham gia, tổ chức học tập, quản lý lấy con người làm trung tâm, v.v., nhưng không có sách nào trong số này được đưa vào quản lý các tổ chức hiện đại.

Trong bối cảnh của Phát triển phần mềm thích ứng, khoảng cách có vẻ rộng hơn nhiều và cần phải xem xét các kỹ thuật quản lý thích ứng đã được chứng minh là thành công trong các lĩnh vực khác.

Quản lý thích ứng

Quản lý thích ứng đã được chứng minh là thành công trong môi trường mà các nhà quản lý tài nguyên làm việc cùng với các bên liên quan và các nhà khoa học như một nhóm, với các mục tiêu sau:

• Để tìm hiểu cách các hệ thống được quản lý phản ứng với các can thiệp của con người.

• Để cải thiện các chính sách và thông lệ tài nguyên trong tương lai.

Nguyên tắc đằng sau quản lý thích ứng là nhiều hoạt động quản lý tài nguyên là thử nghiệm vì kết quả của chúng không thể dự đoán trước một cách đáng tin cậy. Sau đó, những thí nghiệm này được sử dụng làm cơ hội học hỏi để cải tiến trong tương lai.

Quản lý thích ứng nhằm tăng khả năng phản ứng kịp thời khi đối mặt với thông tin mới và trong bối cảnh các mục tiêu và sở thích của các bên liên quan khác nhau. Nó khuyến khích các bên liên quan đưa ra các tranh chấp ràng buộc và thảo luận về chúng một cách có trật tự trong khi những bất ổn về môi trường đang được điều tra và hiểu rõ hơn.

Quản lý thích ứng giúp các bên liên quan, người quản lý và những người ra quyết định khác nhận ra các giới hạn của kiến ​​thức và sự cần thiết phải hành động đối với thông tin không hoàn hảo.

Quản lý thích ứng giúp thay đổi các quyết định đã đưa ra bằng cách làm rõ rằng -

• Các quyết định là tạm thời.
• Quyết định của ban quản lý không phải lúc nào cũng đúng.
• Các sửa đổi được mong đợi.

Có hai loại phương pháp tiếp cận quản lý thích ứng -

• Quản lý thích ứng thụ động.
• Quản lý thích ứng tích cực.

Quản lý thích ứng thụ động

Quản lý thích ứng nhằm mục đích nâng cao kiến ​​thức khoa học và do đó làm giảm sự không chắc chắn.

Trong quản lý Thích ứng thụ động, một hướng hành động ưu tiên duy nhất, dựa trên thông tin và hiểu biết hiện có, được chọn. Kết quả của các hoạt động quản lý được giám sát và các quyết định tiếp theo được điều chỉnh dựa trên kết quả.

Cách tiếp cận này góp phần vào việc học tập và quản lý hiệu quả. Tuy nhiên, nó bị hạn chế về khả năng nâng cao năng lực khoa học và quản lý đối với các điều kiện vượt quá quy trình hành động đã chọn.

Quản lý thích ứng tích cực

Phương pháp quản lý thích ứng tích cực xem xét thông tin trước khi thực hiện các hành động quản lý.

Sau đó, một loạt các mô hình hệ thống cạnh tranh, thay thế của hệ sinh thái và các phản ứng liên quan (ví dụ: thay đổi nhân khẩu học; sử dụng giải trí), thay vì một mô hình duy nhất, sau đó được phát triển. Các phương án quản lý được lựa chọn dựa trên đánh giá của các mô hình thay thế này.

Lãnh đạo-Quản lý cộng tác

Quản lý thích ứng là những gì phù hợp nhất cho Phát triển phần mềm thích ứng. Cách tiếp cận này yêu cầu các nhà quản lý nguồn lực, tức là các nhà quản lý có thể làm việc với mọi người, cho phép sự can thiệp của con người và tạo ra một môi trường thân thiện.

Trong phát triển phần mềm, những người lãnh đạo thường đảm nhận những trách nhiệm này. Chúng ta cần những người lãnh đạo hơn những người chỉ huy. Các nhà lãnh đạo là những người cộng tác và làm việc cùng với nhóm. Lãnh đạo Hợp tác là phương pháp được săn lùng nhiều nhất trong Phát triển thích ứng.

Các nhà lãnh đạo có những phẩm chất sau:

• Nắm bắt và thiết lập hướng.

• Ảnh hưởng đến những người liên quan và cung cấp hướng dẫn.

• Cộng tác, tạo điều kiện và quản lý vĩ mô nhóm.

• Cung cấp chỉ dẫn.

• Tạo môi trường nơi những người tài năng có thể đổi mới, sáng tạo và đưa ra các quyết định hiệu quả.

• Hiểu rằng đôi khi họ cần ra lệnh, nhưng đó không phải là phong cách chủ đạo của họ.