Vòng đời phát triển phần mềm linh hoạt là gì?
Vòng đời phát triển phần mềm linh hoạt (Agile Software Development Lifecycle) là phương pháp luận được sử dụng để phát triển phần mềm chất lượng cao và phù hợp với thị trường. Tuy nhiên, không giống như các phương pháp luận phát triển phần mềm khác, Agile thu thập các phương pháp đơn giản nhưng hiệu quả để các nhà phát triển tạo và liên tục cải tiến hệ thống của họ.
Phương pháp linh hoạt dựa trên việc ra quyết định tham vấn giữa các yêu cầu hệ thống và nhà phát triển. Việc phát triển hệ thống được thực hiện thường xuyên, theo chu kỳ nhỏ gọi là Sprint, kéo dài từ hai đến bốn tuần.
Không giống như các vòng đời phát triển phần mềm khác, phương pháp linh hoạt đánh giá cao sự phát triển ổn định và lặp lại, trong đó các hệ thống được định hình thông qua sự hợp tác hiệu quả của nhiều nhóm. Quá trình này khuyến khích các nhà phát triển phần mềm thúc đẩy sự thích ứng liên tục với các phản hồi. Việc phát triển phần mềm linh hoạt được triển khai đúng cách sẽ nhanh chóng và uyển chuyển.
Dựa trên một cuộc khảo sát 8 công ty và liên quan đến 35 dự án, việc phát triển phần mềm linh hoạt có thể dẫn đến tăng thời thời gian và chi phí hiệu suất nhưng chất lượng được cải thiện. Phương pháp này cũng cung cấp một cách để các công ty công nghệ quản lý các nhóm phát triển hệ thống tốt hơn. Dưới đây là tóm lược về các nguyên tắc, giai đoạn và lợi ích khác nhau của Vòng đời Phát triển Hệ thống Linh Hoạt.
Các giai đoạn chính của Vòng đời phát triển phần mềm linh hoạt
Như đã đề cập ở trên, mô hình phát triển phần mềm nhanh nhẹn là gia tăng (incremental) . Điều này có nghĩa là sự phát triển phần mềm tuân theo một loạt các chu kỳ ngày càng tăng và nhanh chóng. Trình tự được chia thành các bản phát hành nhỏ, với mỗi bản phát hành nâng cao chức năng của giai đoạn trước. Các nhà phát triển phần mềm cần kiểm tra kỹ lưỡng mọi bản phát hành để đảm bảo chất lượng cho sản phẩm cuối cùng. Dưới đây là các giai đoạn của ASDL:
Khởi động dự án / Yêu cầu
Giai đoạn khởi động và lấy yêu cầu (Project Initiation/Requirements) là bước đầu tiên trong vòng đời phát triển phần mềm linh hoạt. Được gọi phổ biến là giai đoạn hình dung (envision), giai đoạn này liên quan đến việc phác thảo tầm nhìn của người dùng và đánh giá ROI. Trước khi dự án triển khai, chủ sở hữu nên phác thảo các yêu cầu ban đầu. Trong số đó có các mục tiêu cần đạt được, các tính năng mà hệ thống sẽ hỗ trợ và những tính năng mà phần mềm không thể hỗ trợ.
Ví dụ: nếu khách hàng ký hợp đồng với một công ty công nghệ để phát triển một trình soạn thảo văn bản, thì đây sẽ là mục tiêu cuối cùng. Đối với các tính năng mà nó có thể hỗ trợ, khách hàng có thể hình dung rằng nó cần một trình chỉnh sửa cho phép các kích thước phông chữ, bảng màu khác nhau và các tính năng khác. Mặc khác, phần mềm có thể không hỗ trợ nhúng video hoặc thêm hình ảnh động vào văn bản.
Theo nguyên tắc chung, chủ dự án thường được khuyên nên hạ thấp các yêu cầu ban đầu và chỉ xác định các tính năng quan trọng của hệ thống. Các nhà phát triển phần mềm sau đó có thể cập nhật hệ thống với các tính năng không quan trọng khác sau này, khi hệ thống đã được triển khai với các tính năng cốt lõi hoạt động hiệu quả.
Bỏ qua giai đoạn này có thể là một thảm họa, vì các nhà phát triển có thể phải phát triển các tính năng không cần thiết ngay từ đầu. Do đó, khách hàng và nhà phát triển phần mềm nên xem xét các yêu cầu này để làm cho chúng phù hợp.
Giai đoạn thiết kế
Thiết kế (design) là giai đoạn đầu cơ của phát triển phần mềm trong quy trình linh hoạt. Nhóm Agile có thể sử dụng hai cách tiếp cận trong giai đoạn này, bao gồm:
Thiết kế phần mềm
Trong vòng lặp hay phân đoạn (iteration) này, chủ sở hữu phần mềm hoặc khách hàng gặp gỡ nhóm phát triển phần mềm và đưa ra các yêu cầu cụ thể được nêu trong giai đoạn đầu tiên. Sau đó, nhóm cần thảo luận về cách họ có thể giải quyết các tính năng được chỉ định và đề xuất các công cụ thiết yếu sẽ giúp họ đạt được kết quả tốt nhất.
Ví dụ: các nhà phát triển nên xác định một ngôn ngữ lập trình phù hợp, các thư viện cú pháp và các frameworks chính. Nhóm cũng có thể thảo luận về việc triển khai tính năng cụ thể của ứng dụng.
Thiết kế giao diện người dùng
Trong giai đoạn này, các nhóm phát triển phần mềm có thể tạo ra một bản phác thảo sơ bộ về giao diện người dùng (User Interface) dự kiến. Điều này là cần thiết đối với các sản phẩm cấp độ người tiêu dùng, nơi mà cả giao diện người dùng và trải nghiệm đều rất quan trọng. Trong trường hợp này, cần thận trọng xem xét những gì đối thủ cạnh tranh của bạn có, đặc biệt nhấn mạnh vào những gì bạn có thể làm khác đi.
Phát triển và lập trình
Với các yêu cầu được đặt ra và thảo luận rõ ràng giữa khách hàng và nhóm phát triển phần mềm, bây giờ là lúc quá trình phát triển hệ thống thực sự bắt đầu. Như đã đề cập, tùy chọn linh hoạt nhằm mục đích cung cấp các hệ thống chất lượng cao thông qua các giai đoạn gia tăng được gọi là các sprints.
Các nhà phát triển phần mềm bắt đầu phân đoạn đầu tiên với mục tiêu phát triển một sản phẩm có thể sử dụng được vào cuối sprint. Kết quả phải có chức năng tối thiểu và nó khác xa với phiên bản cuối cùng của phần mềm.
Phát triển và lập trình (Development and Coding) là giai đoạn dài nhất, vì nó liên quan đến việc viết code và chuyển đổi các yêu cầu thành một hệ thống hiện có. Các nhóm phát triển phần mềm có thể đạt được thành công của những bước sprint này bằng cách:
- Phối hợp làm việc với các nhóm khác và các bên liên quan của hệ thống;
- Tuân thủ nghiêm ngặt các quy ước về coding để duy trì chất lượng;
- Tuân thủ các ưu tiên do khách hàng đưa ra về lịch trình, ngân sách và phạm vi của ứng dụng.
Tích hợp và kiểm thử
Các developer luôn hiểu được tầm quan trọng của việc thường xuyên kiểm thử các prototypes (nguyên mẫu). Giai đoạn này cho phép các nhà phát triển phần mềm đảm bảo rằng hệ thống không có lỗi và tương thích với các cú pháp khác được viết trước đó.
Sau khi các nhà phát triển hoàn tất việc tích hợp, bộ phận đảm bảo chất lượng (quality assurance) sẽ thực hiện một số thử nghiệm bằng cách sử dụng các công cụ kiểm tra phần mềm để kiểm tra hệ thống để tìm lỗi và sự tương thích với các mục tiêu kinh doanh. May mắn thay, 17% công cụ kiểm tra phần mềm hỗ trợ nền tảng dựa trên web.
Trong số này, 10% và 7% hỗ trợ nền tảng máy tính để bàn và di động tương ứng. Thử nghiệm vượt ra ngoài khía cạnh chức năng của hệ thống để có thể tích hợp hệ thống, chấp nhận của người dùng (user acceptance) và hơn thế nữa.
Thực hiện và Triển khai
Như tên cho thấy, nhóm triển khai phần mềm tới các máy chủ hoặc khách để đưa vào sử dụng thực tế hoặc dùng thử. Các nhà phát triển phần mềm nên giám sát chặt chẽ hiệu suất để lưu ý bất kỳ lỗi nào bị bỏ sót hoặc lỗi không được xác định trong giai đoạn thử nghiệm. Nhóm cũng nên giám sát việc bàn giao, bao gồm đào tạo cho các nhóm hỗ trợ.
Lưu ý rằng quá trình bàn giao thay đổi tùy thuộc vào loại phần mềm được phát triển. Khi điều này được thực hiện, giai đoạn sản xuất của phần mềm thường kết thúc.
Đánh giá / Kết thúc dự án
Khi giai đoạn phát triển hoàn tất, khách hàng hoặc chủ sở hữu phần mềm gặp lại nhóm phát triển phần mềm để đánh giá phần mềm dựa trên các yêu cầu đã đặt ra ban đầu. Nhóm cũng có thể đề xuất các vấn đề đã gặp phải trong giai đoạn trước cho chủ sở hữu. Vào cuối giai đoạn này, vòng đời phát triển hệ thống linh hoạt có thể bắt đầu lại với một lần lặp mới hoặc chuyển sang giai đoạn tiếp theo.
Các phương pháp linh hoạt
Các phương pháp linh hoạt (Agile) chỉ đơn giản là một tập hợp các quy ước được phác thảo mà các nhóm phát triển hệ thống tuân theo. Các nhóm phát triển phần mềm có thể sử dụng các phương pháp luận linh hoạt khác nhau khi thiết kế một hệ thống. Bất kể lựa chọn của nhóm bạn là gì, các phương pháp phải tuân theo các nguyên tắc chính của phát triển hệ thống linh hoạt. Các phương pháp luận phổ biến bao gồm:
Scrum
Scrum là một phương pháp linh hoạt phổ biến tập trung vào việc khuyến khích các nhóm phát triển phần mềm cộng tác. Tùy chọn tập trung vào việc điều chỉnh các yếu tố dao động khác nhau bằng cách giả định rằng nhóm phát triển có thể không biết mọi thứ khi bắt đầu nhiệm vụ. Như tên cho thấy, phương pháp này dựa trên các chiến lược được sử dụng bởi các đội bóng bầu dục.
Phương pháp này nhằm mục đích tăng cường sự hợp tác trong nhóm bằng cách chia nhiệm vụ thành các vai trò nhỏ. Điều này mô phỏng một đội bóng bầu dục nơi các cầu thủ toàn đội được giao trách nhiệm cụ thể. Scrum hoạt động theo ba yếu tố chính, bao gồm:
Product backlog
Product backlog mô tả các nhiệm vụ chính mà nhóm phải thực hiện. Chủ sở hữu phần mềm hoặc người quản lý sản phẩm có trách nhiệm phân công và giám sát việc này. Các nhiệm vụ dựa trên các yêu cầu và tính năng được nêu trong giai đoạn đầu tiên của quá trình phát triển linh hoạt.
Sprint backlog
Tiểu mục này phác thảo các bản sửa lỗi và các hạng mục khác mà nhóm phát triển phần mềm xác định sẽ được thực hiện trong một giai đoạn cụ thể. Không giống như product backlog, cho phép thay đổi, sprint backlog là không đổi được.
Gia tăng
Gia tăng (Incremental) còn được gọi là mục tiêu sprint (sprint goal), phần gia tăng là sản phẩm cuối cùng hoặc kết quả của sprint. Đây là kết quả cuối cùng được nhóm phát triển hệ thống hiện thực hóa. Các nhóm có thể đạt được mục tiêu này bằng cách hoàn thành toàn bộ quá trình phát triển. Ví dụ: nếu nhóm tải ứng dụng lên Play Store, họ sẽ đạt được một mức tăng sau khi ứng dụng được xuất bản.
Kanban
Không giống như Scrum, Kanban hướng đến việc phát triển các hệ thống theo chu kỳ một thời gian dài. Trong phương pháp này, các đội sử dụng các thẻ (card) xoay vòng trong toàn bộ quá trình. Điều này làm cho Kanban trở thành một quá trình gia tăng nhưng không lặp lại. Vì không có sự lặp lại, Kanban không có điểm bắt đầu và điểm kết thúc cụ thể. Các dự án Kanban luôn có thẻ “công việc đang tiến hành”, ngay cả khi nhóm tập trung vào từng phân đoạn nhỏ tại một thời điểm.
Dynamic Software Development Method (Phát triển phần mềm động)
Cách tiếp cận phát triển phần mềm linh hoạt này dựa trên việc người dùng tham gia tích cực và đưa ra quyết định trong các giai đoạn phát triển phần mềm. Do đó, triển khai không liên tục và thường xuyên của hệ thống trở thành trọng tâm tích cực của phương pháp luận này.
Crystal (Pha lê)
Phương pháp Crystal (pha lê) là một phương pháp phát triển hệ thống linh hoạt khác với ba khái niệm cơ bản:
- Chartering – giống như giai đoạn yêu cầu trong đó các hoạt động liên quan được phác thảo. Điều này liên quan đến các nghiên cứu khả thi, phát triển kế hoạch và cụ thể hóa phương pháp luận.
- Cyclic delivery (Phát hành theo chu kỳ) – giai đoạn này chứa hai hoặc nhiều chu kỳ phát hành. Tại đây, nhóm sẽ tinh chỉnh các kế hoạch, thực hiện các yêu cầu của tập hợp con, xem xét kế hoạch dự án và áp dụng phương pháp luận.
- Wrap-up – giai đoạn cuối cùng thường liên quan đến việc triển khai hệ thống tới máy chủ và người dùng. Một phân tích sau khi triển khai cũng được thực hiện.
Feature Driven Development (Phát triển theo hướng tính năng)
Phương pháp luận này tập trung vào việc xây dựng và thiết kế các tính năng của hệ thống. Với FDD, các nhóm phát triển hệ thống làm việc trong các giai đoạn ngắn để phát triển các chức năng của hệ thống. Nói một cách đơn giản, FDD tập trung vào việc phát triển các hệ thống theo tính năng cụ thể.
eXtreme Programming
eXtreme Programming là một phương pháp khác hữu ích với các hệ thống có yêu cầu thay đổi liên tục. Khách hàng hoặc chủ sở hữu đôi khi có thể đề xuất các điều khoản thay đổi, đặc biệt khi không chắc chắn về các yêu cầu cụ thể sẽ nâng cao chức năng hệ thống của họ.
Phương pháp luận này ủng hộ việc phát hành chương trình thường xuyên và chu kỳ phát triển ngắn. Thông qua đó, phương pháp cải thiện năng suất và giới thiệu các điểm kiểm tra theo từng giai đoạn, nơi có thể thực hiện các yêu cầu thay đổi của khách hàng.
Giá trị và nguyên tắc của thát triển phần mềm linh hoạt
Mục tiêu chính của phát triển phần mềm linh hoạt là cung cấp cho người dùng cuối sự hài lòng tối đa. Do đó, bất kỳ nhiệm vụ nào khác không hướng tới việc đạt được điều này đều được coi là thứ yếu. Tuyên ngôn Agile có bốn giá trị và nguyên tắc cốt lõi cho các nhà phát triển hệ thống. Mỗi phương pháp nêu trên áp dụng các giá trị và nguyên tắc này một cách khác nhau nhưng dựa vào chúng để phát triển phần mềm chất lượng cao và hiệu quả.
Giá trị cốt lõi
Cá nhân và Tương tác hơn là Quy trình và công cụ – People and Interactions over Tools and Processes
Phát triển phần mềm Agile tập trung vào các cá nhân thay vì các quy trình và công cụ. Các nhà phát triển Agile nên đánh giá cao con người hơn các quy trình, vì các cá nhân đáp ứng nhu cầu kinh doanh và là nguyên nhân cho quá trình phát triển. Các nhà phát triển linh hoạt sẽ ít có khả năng đáp ứng các nhu cầu của khách hàng nếu các công cụ và quy trình thúc đẩy sự phát triển hệ thống.
Một trường hợp cụ thể là giao tiếp phải trôi chảy và diễn ra bất cứ lúc nào đối với các nhà phát triển linh hoạt, những người coi trọng yếu tố con người. Tuy nhiên, đối với những người ưu tiên các công cụ và quy trình, việc trao đổi thông tin cần được lên lịch và có nội dung chỉ định trước.
Phần mềm chạy tốt hơn là tài liệu toàn diện – Functional Software over Comprehensive Documentation
Ban đầu, các nhà phát triển phần mềm đã lãng phí rất nhiều thời gian để ghi lại toàn bộ quá trình phát triển hệ thống. Điều này bao gồm các thông số kỹ thuật, triển vọng kỹ thuật, thiết kế giao diện người dùng, kế hoạch kiểm thử, v.v. Điều này làm cho quá trình phát triển phần mềm tốn nhiều công sức và do đó, dẫn đến sự chậm trễ.
Các quy trình Agile hiểu tầm quan trọng của các tài liệu như vậy và không loại bỏ sự chậm trễ, nhưng hợp lý hóa quy trình tài liệu để cung cấp cho các nhà phát triển những gì họ cần mà không lãng phí thời gian. Phương pháp Agile chắc chắn đánh giá cao tài liệu nhưng coi trọng phần mềm hoạt động được.
Cộng tác với khách hàng hơn là đàm phán hợp đồng – Customer Collaboration over Contract Negotiation
Hầu hết các nhà phát triển phần mềm bắt đầu hợp đồng của họ bằng cách thương lượng các chi tiết giao hàng và các chi tiết phát triển cụ thể khác. Tuy nhiên, điều này khác với sự hợp tác. Không giống như Waterfall, nơi khách hàng thương lượng các yêu cầu sản phẩm trước khi bắt đầu, Agile hướng đến việc ràng buộc khách hàng trong suốt quá trình phát triển.
Điều này làm cho các nhà phát triển phần mềm đáp ứng nhu cầu của khách hàng một cách khả thi. Các quy trình Agile cho khách hàng xem các bản demo định kỳ, điều này vốn khó có được khi ứn dụng các quy trình phát triển khác.
Đánh giá cao những thay đổi hơn là các kế hoạch đã tuân theo – Appreciating Changes over Following Laid Plans
Các quy trình phát triển hệ thống truyền thống coi sự thay đổi là một khoản chi phí có thể tránh được. Do đó, nó dựa trên các kế hoạch bài bản với các tính năng được xác định. Tuy nhiên, với Agile, sự hiện diện của các phân đoạn (iteration) có nghĩa là các nhà phát triển có thể thay đổi mức độ ưu tiên từ vòng lặp này sang vòng lặp khác.
Những chức năng mới, vốn không có trong vòng lặp trước, có thể bao gồm trong vòng lặp tiếp theo. Mục tiêu cuối cùng là cải thiện dự án và thay đổi có thể mang lại giá trị không thể đo lường được. Vì vậy, để nói rằng, bạn có thể đạt được 3/4 những gì bạn có thể làm với Waterfall chỉ với 1/3 khi ứng dụng hệ thống linh hoạt.
Nguyên tắc phát triển Agile
Tuyên ngôn Agile nêu ra 12 nguyên tắc linh hoạt hướng dẫn phát triển phần mềm. Các nguyên tắc bao gồm:
Chuyển giao phần mềm có giá trị sớm và liên tục
Phát triển hệ thống Agile tập trung vào việc đảm bảo rằng người dùng phần mềm hài lòng thông qua việc cung cấp phần mềm có giá trị một cách thường xuyên. Điều này giúp loại bỏ sự chờ đợi kéo dài giữa các bản cập nhật và bản phát hành mới.
Sẵn sàng cho sự thay đổi
Như đã đề cập trong số các giá trị cốt lõi, các nhà phát triển nhanh phải luôn chào đón sự thay đổi vì lợi thế cạnh tranh của khách hàng. Với thế giới công nghệ hiện tại là tĩnh, không ai có thể đoán trước được phần mềm tiếp theo sẽ có những gì. Thay đổi này cũng cho phép khách hàng tránh lãng phí tiền vào việc phát triển một sản phẩm không phù hợp.
Cung cấp phần mềm hoạt động trong thời gian ngắn
Phát triển hệ thống Agile cũng ủng hộ việc cung cấp thường xuyên phần mềm đầy đủ chức năng. Các nhà phát triển nên phát hành sản phẩm sau vài tuần hoặc vài tháng, ưu tiên hơn cho các khoảng thời gian ngắn. Đừng nhầm lẫn với nguyên tắc đầu tiên, nguyên tắc này khuyên bạn nên cung cấp phần mềm hoạt động liên tục.
Các nhà phát triển phần mềm nên phát hành các phiên bản mới trong một khoảng thời gian ngắn, với các bản phát hành nhỏ và ít nguy cơ lỗi hơn. Mặt khác, nguyên tắc đầu tiên nói rằng phần mềm nên được chuyển giao sớm.
Sự hợp tác giữa các nhà phát triển và các bên liên quan
Việc nhận ra các sản phẩm tốt hơn và các quyết định tốt hơn có thể được đưa ra nếu đội ngũ kỹ thuật làm việc cùng với các doanh nghiệp và các bên liên quan. Không giống như các phương pháp khác mà các nhà phát triển bỏ qua các doanh nghiệp, nguyên tắc này khuyến khích loại bỏ các rào cản để cho phép các doanh nghiệp tương tác với các nhà phát triển. Điều này thúc đẩy sự tôn trọng và hiểu biết lẫn nhau.
Xây dựng dự án xung quanh các cá nhân có động lực
Một nhóm có động lực sẽ hoạt động tốt hơn. Do đó, các tổ chức nên cung cấp môi trường và sự hỗ trợ cần thiết.
Tạo điều kiện cho tương tác mặt đối mặt
Mặc dù nhiều công nghệ giao tiếp từ xa đã ra đời, việc phát triển hệ thống thích hợp có thể đạt được bằng cách trò chuyện trực tiếp. Mặc dù 56,7% công ty thích các kênh truyền thông hiện đại, nhưng truyền miệng thường được coi là đáng tin cậy, rõ ràng và thấu đáo. Thay đổi chiến lược giao tiếp với sự ra đời của Slack, Hangouts và Skype sẽ không bao giờ đạt được những gì mà các tương tác trong đời thực có được.
Phần mềm hoạt động được là thước đo tiến độ
Nguyên tắc này khẳng định rằng cách duy nhất để đánh giá tiến độ là tạo ra phần mềm hoạt động được. Phần mềm có thể là một mô hình đã hoàn thành hoặc một mô hình giả lập.
Nhịp độ phát triển nhất quán
Các nhóm phát triển phần mềm nên tạo ra một tốc độ tuần tự và đáng tin cậy để họ có thể cung cấp phần mềm hoạt động được. Họ nên lặp lại điều này với mỗi bản phát hành.
Kỹ thuật tối ưu
Bất chấp những hạn chế về thời gian, các nhà phát triển phần mềm nên liên tục chú ý đến sự tối ưu về kỹ thuật.
Sự đơn giản
Mặc dù cần bảo các thiết kế có chất lượng hoàn hảo, các nhóm kỹ thuật nên phát triển phần mềm vừa đủ để hoàn thành công việc.
Tự tổ chức
Các nhà phát triển hệ thống trong nhóm phải có kỹ năng và động lực cao để có một quy trình liền mạch. Họ phải có kỹ năng ra quyết định đúng đắn, giao tiếp với các thành viên và chia sẻ ý tưởng để có sản phẩm chất lượng.
Phản ánh thường xuyên
Như tên cho thấy, nhóm nên phản ánh sự tiến bộ của họ và thường xuyên đưa ra các cách làm thế nào để trở nên hiệu quả hơn.
Và cuối cùng
Dựa trên một nghiên cứu, 50% dự án được thực hiện với sự tham gia tích cực của khách hàng, đây là điều mà Agile luôn ủng hộ. 66,7% người tham gia nghiên cứu đồng ý rằng năng suất đã được cải thiện. Scrum, một phương pháp quản lý dự án Agile rất phổ biến, có tính năng chia các dự án thành các phần với các mục tiêu cụ thể, mỗi phần theo sau là một bài đánh giá để đánh giá tiến độ.
Agile, như đã đề cập, tập trung vào phân đoạn các dự án và thúc đẩy các nhóm phát triển. Những người ủng hộ quá trình này tin rằng sự phát triển gia tăng có thể thỏa mãn nhu cầu của khách hàng tốt hơn và dẫn đến việc tạo ra các sản phẩm chất lượng hơn.
Bài được dịch từ bài gốc The Agile System Development Lifecycle Explained của Angela Martin, người hiện tại đang làm việc trong lĩnh vực phát triển phần mềm, đăng trên jelvix.com. Bài dịch được sự đồng ý của công ty Jelvix.
Nguồn: itguru
