Trong khi cách tiếp cận "thác nước" truyền thống có một đóng góp chuyên môn cho dự án, sau đó "vứt nó qua tường" cho người đóng góp tiếp theo, thì Agile kêu gọi các nhóm hợp tác liên chức năng. Giao tiếp cởi mở, hợp tác, thích ứng và tin tưởng giữa các thành viên trong nhóm là trọng tâm của Agile. Mặc dù trưởng dự án hoặc chủ sở hữu sản phẩm thường ưu tiên công việc sẽ được giao, nhưng nhóm sẽ dẫn đầu trong việc quyết định cách thức hoàn thành công việc, tự tổ chức xung quanh các nhiệm vụ và nhiệm vụ chi tiết
Agile không được xác định bởi một tập hợp các nghi thức hoặc kỹ thuật phát triển cụ thể. Thay vào đó, Agile là một nhóm các phương pháp thể hiện cam kết tuân thủ các chu kỳ phản hồi chặt chẽ và cải tiến liên tục.
Các nhóm chọn phương pháp linh hoạt để họ có thể phản ứng với những thay đổi trên thị trường hoặc phản hồi từ khách hàng một cách nhanh chóng mà không làm hỏng kế hoạch của một năm. Lập kế hoạch và vận chuyển "vừa đủ" với số lượng nhỏ, thường xuyên cho phép nhóm của bạn thu thập phản hồi về từng thay đổi và tích hợp nó vào các kế hoạch trong tương lai với chi phí tối thiểu
Nhưng nó không chỉ là một trò chơi số—trước hết, nó là về con người. Như được mô tả trong Tuyên ngôn Agile, các tương tác đích thực của con người quan trọng hơn các quy trình cứng nhắc. Hợp tác với khách hàng và đồng đội quan trọng hơn sự sắp xếp được xác định trước. Và cung cấp giải pháp hiệu quả cho vấn đề của khách hàng quan trọng hơn tài liệu siêu chi tiết
Một nhóm nhanh nhẹn đoàn kết dưới một tầm nhìn chung, sau đó đưa nó vào cuộc sống theo cách mà họ biết là tốt nhất. Mỗi nhóm đặt ra các tiêu chuẩn riêng về chất lượng, khả năng sử dụng và tính đầy đủ. Sau đó, "định nghĩa về việc hoàn thành" của họ cho biết họ sẽ hoàn thành công việc nhanh như thế nào. Mặc dù ban đầu có thể đáng sợ, nhưng các nhà lãnh đạo công ty nhận thấy rằng khi họ đặt niềm tin vào một nhóm nhanh nhẹn, nhóm đó sẽ cảm thấy có quyền sở hữu hơn và tăng lên để đáp ứng [hoặc vượt quá] mong đợi của ban quản lý
Agile là một thuật ngữ chung cho một số phương pháp và thực hành. Hãy xem xét một số phương pháp phổ biến
- Scrum
- Lập trình cực đoan [XP]
- Phát triển phần mềm thích ứng [ASD]
- Phương pháp phát triển phần mềm động [DSDM]
- Phát triển hướng tính năng [FDD]
- Kanban
- Phát triển Định hướng Hành vi [BDD]
Phương pháp Scrum
Phương pháp Scrum là một khuôn khổ đơn giản để làm việc với các dự án phức tạp và nó được tạo ra bởi Ken Schwaber và Jeff Sutherland
Các phương pháp phát triển phần mềm Agile có tính chất lặp đi lặp lại, nghĩa là công việc được chia thành các lần lặp lại, được gọi là Sprint trong trường hợp của Scrum. Scrum được thực hiện bởi các nhóm nhỏ từ 7-9 người, bao gồm Scrum Master và Product Owner
Trong Scrum, các dự án được chia thành các chu kỳ [thường là chu kỳ 2 hoặc 3 tuần] được gọi là Sprint. Sprint đại diện cho một khung thời gian trong đó một tập hợp các tính năng phải được phát triển. Nhiều lần chạy nước rút có thể được kết hợp để tạo thành một Bản phát hành – nơi phân phối sản phẩm/phần mềm chính thức được thực hiện cho khách hàng/thị trường
Chức năng tổng thể của sản phẩm được Chủ sở hữu sản phẩm chia nhỏ thành các tính năng nhỏ hơn [thường được mô tả là Sử thi và Câu chuyện của người dùng – hoặc chỉ là Câu chuyện]. Những Câu chuyện này được ưu tiên và sử dụng trong mỗi Sprint hoặc Lặp lại. Mục đích của phương pháp này là để nhóm có thể demo vào cuối mỗi phần hoạt động của sản phẩm Sprint cho Chủ sở hữu sản phẩm, để đảm bảo rằng sản phẩm đang hoạt động như dự kiến
Nhìn chung, phương pháp Scrum chia quá trình phân phối thác nước dài thành các chu kỳ nhỏ hơn, cho phép các nhóm sản phẩm và khách hàng cuối thường xuyên xem xét phần mềm đang hoạt động và đảm bảo rằng nó đáp ứng các yêu cầu kinh doanh của họ. Điều này đảm bảo rằng sản phẩm cuối cùng cũng đáp ứng các yêu cầu cuối cùng của khách hàng
Phương pháp Scrum được đặc trưng bởi các nghi lễ cụ thể như cuộc họp Dự phòng Hàng ngày, Cuộc họp Đánh giá Sprint, Demo cho Chủ sở hữu Sản phẩm và cuộc họp Cải tiến Sprint. Tất cả các cuộc họp này đều mang lại cơ hội hợp tác và đánh giá cho nhóm để đảm bảo rằng quá trình phát triển đang diễn ra như dự kiến và mọi vấn đề đều được giải quyết nhanh chóng
Lập trình cực đoan [XP]
Extreme Programming [XP] – hay Paired Programming là một phương pháp được phát triển bởi Kent Beck vào đầu những năm 90. Phương pháp nhanh nhẹn này tập trung vào việc tăng cường mối quan hệ giữa các cá nhân như là chìa khóa thành công trong phát triển phần mềm. XP cũng tập trung vào việc thúc đẩy tinh thần đồng đội, quan tâm đến việc học tập của các nhà phát triển và thúc đẩy môi trường làm việc tốt. Nó được đặc trưng bởi các nhà phát triển làm việc theo cặp trong đó một nhà phát triển lập trình trong khi nhà phát triển kia quan sát; . Bằng cách này, chúng cho phép đánh giá và phản hồi mã liên tục giúp nâng cao chất lượng mã và khả năng của nhà phát triển
Extreme Programming [XP] thúc đẩy phản hồi liên tục giữa khách hàng và nhóm phát triển, giao tiếp trôi chảy giữa tất cả những người tham gia, tính đơn giản trong các giải pháp được triển khai và sẵn sàng đối mặt với những thay đổi. XP đặc biệt phù hợp với các dự án có yêu cầu không rõ ràng, thay đổi nhiều và có rủi ro kỹ thuật cao
Phát triển phần mềm thích ứng [ASD]
Adaptive Software Development [ASD] được phát triển bởi Jim Highsmith và Sam Bayer vào đầu những năm 1990. Nó kết hợp các nguyên tắc thích ứng liên tục, tôi. e. , thích ứng với sự thay đổi và không chống lại nó. Phát triển phần mềm thích ứng sử dụng chu kỳ phát triển động được gọi là Suy đoán, Cộng tác và Học hỏi. Chu kỳ này dành riêng cho việc học hỏi không ngừng và cộng tác chặt chẽ giữa các nhà phát triển và khách hàng do sự thay đổi liên tục trong môi trường kinh doanh
Không giống như hầu hết các phương pháp phát triển Phần mềm sử dụng vòng đời tĩnh, tôi. e. , Lập kế hoạch-Thiết kế-Xây dựng, ASD cung cấp vòng đời lặp lại phi tuyến tính, trong đó mỗi chu kỳ có thể lặp lại và được sửa đổi trong khi một chu kỳ khác đang được thực thi. Nó hướng tới Phát triển ứng dụng nhanh [RAD], trong đó nhấn mạnh tốc độ phát triển để tạo ra một sản phẩm chất lượng cao, bảo trì thấp liên quan đến người dùng càng nhiều càng tốt. Các đặc điểm chính của ASD là
- Suy đoán. Đây là giai đoạn khởi đầu của dự án, nơi cần thiết lập các mục tiêu và mục tiêu chính của dự án bằng cách hiểu các hạn chế [lĩnh vực rủi ro] mà dự án vận hành
- Hợp tác. Đây là giai đoạn mà phần lớn sự phát triển được tập trung, duy trì sự phối hợp giữa các nhóm để đảm bảo những gì nhóm này học được sẽ được truyền đạt cho các nhóm còn lại và các nhóm khác không phải học lại từ đầu
- Học hỏi. Giai đoạn cuối cùng kết thúc với một loạt các chu kỳ hợp tác – công việc là nắm bắt những gì đã học được, cả tích cực và tiêu cực. Giai đoạn này rất quan trọng đối với hiệu quả của dự án
Phương pháp phát triển phần mềm động [DSDM]
Phương pháp phát triển phần mềm động [DSDM] được phát triển vào năm 1994 bởi một nhóm các nhà cung cấp và chuyên gia trong lĩnh vực phát triển phần mềm. DSDM tập trung vào các dự án Phần mềm được đặc trưng bởi ngân sách và lịch trình eo hẹp. Nó tập trung vào việc phân phối thường xuyên các chu kỳ sản phẩm và sự phát triển là lặp đi lặp lại và gia tăng
Với Phương pháp phát triển phần mềm động [DSDM], người ta có thể thiết kế lộ trình phân phối sớm và liên tục cho dự án, triển khai giải pháp gia tăng, điều chỉnh từ phản hồi thu được trong suốt quá trình và kiểm tra xem các lợi ích mong đợi có được đáp ứng hay không
DSDM là một mô hình linh hoạt chắc chắn có thể giúp các tổ chức đã quen làm việc với các dự án thay đổi tâm lý và cách làm việc để cải thiện khả năng mang lại giá trị và giảm thời gian đưa ra thị trường
Phát triển hướng tính năng [FDD]
Phương pháp phát triển theo hướng tính năng [FDD] chủ yếu được định hướng cho các nhóm lớn hơn với nhiều người hơn là những người thường áp dụng các phương pháp nhanh nhẹn khác như Scrum. FDD được phát triển bởi Jeff De Luca và Peter Coad vào năm 1997. Phương pháp này tập trung vào các lần lặp lại ngắn, cho phép phân phối sản phẩm hữu hình trong một khoảng thời gian ngắn [2 tuần]
Các dự án có nhiều nhóm và số lượng lớn người đại diện cho thách thức mà không phải tất cả đều tài năng và kỷ luật như nhau. FDD bao gồm các hoạt động cụ thể giúp giải quyết các thách thức về giao tiếp và điều phối các dự án đó
FDD là một quy trình gồm 5 giai đoạn, 3 giai đoạn đầu tiên là tuần tự và hai giai đoạn cuối cùng là lặp đi lặp lại [như thể hiện trong sơ đồ trên]. Tất cả các phương pháp nhanh đều tuân theo một loạt nguyên tắc khiến chúng giống nhau. Tuy nhiên, FDD cung cấp các giải pháp về cách tổ chức nhóm và cách lập trình mã, điều này đặc biệt khả thi đối với các nhóm phát triển lớn xây dựng phần mềm phức tạp
Một trong những cuốn sách phổ biến nhất về phương pháp FDD đã được xuất bản bởi Stephen Palmer vào năm 2002, có tiêu đề “Hướng dẫn thực hành về phát triển theo hướng tính năng“
Phương pháp Kanban
Phương pháp Kanban được David Anderson định nghĩa vào đầu những năm 2000 đến giữa những năm 2000, để đối phó với một số thách thức của các phương pháp Agile khác nhau, đặc biệt là Scrum. Những phương pháp này, trong khi cố gắng giải quyết các thách thức của các phương pháp truyền thống/thác nước, lại trở thành nạn nhân của một số thách thức tương tự
Chu kỳ chạy nước rút 2-3 tuần trở nên quá dài để chờ đợi trong nhiều bối cảnh kinh doanh, những thay đổi cần thiết trong cơ cấu tổ chức [vai trò và trách nhiệm mới] và quy trình lập kế hoạch/quản lý dự án gây quá nhiều căng thẳng cho các tổ chức và nhiều nhóm thấy mình không đáp ứng được . Đối với hầu hết các tổ chức, việc thực hiện các phương pháp này trở nên rất khó khăn
Phương pháp Kanban được định nghĩa là ngược lại với điều đó - một phương pháp tiến hóa không đột phá để cải tiến, cuối cùng cho phép các nhóm phân phối liên tục thay vì trong khoảng thời gian 2-3 tuần, nhận phản hồi nhanh hơn và giảm thời gian thực hiện để cung cấp giá trị
Kanban là một hệ thống trực quan để quản lý công việc khi nó di chuyển qua một quy trình. Kanban trực quan hóa cả quy trình [quy trình làm việc] và công việc thực tế đi qua quy trình đó. Mục tiêu của Kanban là xác định các tắc nghẽn tiềm ẩn trong quy trình của bạn và khắc phục chúng, để công việc có thể trôi qua một cách hiệu quả về mặt chi phí với tốc độ hoặc thông lượng tối ưu
Kanban được định nghĩa là một hệ thống sản xuất có hiệu lực và hiệu suất cao. Nguồn gốc của phương pháp Kanban nằm ở quy trình sản xuất “đúng lúc” [JIT] do Toyota nghĩ ra, trong đó các thẻ được sử dụng để xác định nhu cầu nguyên vật liệu trong chuỗi sản xuất. Bạn có thể tìm hiểu thêm về kanban tại đây. https. //www. chữ số. com/kanban/kanban là gì/
Phát triển Định hướng Hành vi [BDD]
Phát triển theo định hướng hành vi [BDD] là một phương pháp phát triển linh hoạt theo định hướng hành vi. Nó được Dan North tạo ra vào năm 2003 như một sự phát triển của phương pháp TDD. Dan North nhằm mục đích tập hợp những người không có kỹ thuật lại với nhau trong quá trình tạo chức năng kỹ thuật của hệ thống. Điều xảy ra là khi chúng tôi phát triển phần mềm, chúng tôi vô tình không đưa các khái niệm kinh doanh có trong chức năng, dẫn đến khả năng xảy ra các lỗi lặp lại và thậm chí nghiêm trọng
Nguồn. John Ferguson thông minh. com
BDD sử dụng các khái niệm ngôn ngữ chung khuyến khích sự hợp tác giữa những người có hoặc không có kiến thức kỹ thuật trong một dự án phần mềm. Quá trình phát triển BDD dựa trên việc viết các tính năng và kịch bản thử nghiệm. Chúng chứa các yêu cầu và tiêu chí chấp nhận cho hành vi của hệ thống. Nó cho bạn biết chức năng nào cần để bắt đầu, nó sẽ làm gì tiếp theo và kết quả sẽ ra sao sau khi nó được thực thi
BDD giúp các nhóm truyền đạt yêu cầu chính xác hơn, sớm phát hiện ra lỗi và xây dựng phần mềm bền vững theo thời gian