Các yếu tố cần thiết đang được lập trình với các nhóm đồng nghiệp, chuyển tiếp nhanh chóng với những đơn vị nhỏ, liên hệ chặt chẽ với khách hàng, và sự tiếp xúc hằng ngày, nơi các nhà ph
Trang 1DANH SÁCH THÀNH VIÊN NHÓM
Ni
Dịch bài, tìm tài liệu, làm
powerpoint,trả lời câu hỏi.
2 030125090615 Đặng Thị Kim Phi Tìm tài liệu, tổng
hợp bài,chỉnh sữa word, thuyết trình.
3 030125090756 Lê Thị Thu Thủy Tìm tài liệu, làm
powerpoint, trả lời câu hỏi.
4 030125090883 Phạm Thị Tiện Tìm tài liệu, tổng
hợp, thuyết trình,viết lời mở.
Trang
Tìm tài liệu, trả lời câu hỏi,tóm tắt nội dung.
Trúc Tìm tài liệu, dịch bài, trả lời câu hỏi,
viết lời kết.
Trang 2MỤC LỤC
Mục lục 2
Bài dịch case study 3
Tóm tắt tình huống 5
Bài phân tích 6
1.Khái quát chung về mô hình Waterfall và mô hình Agile 6
1.1Mô hình thác nước Waterfall 6
1.2Phương pháp phát triển linh hoạt Agile 7
2.Phương pháp phát triển linh hoạt (Agile development method) 8
2.1Đặc điểm 8
2.2Nguyên tắc 9
3.So sánh mô hình Agile và mô hình thác nước 9
3.1.Mức độ rủi ro 9
3.2.Tính linh hoạt của mô hình 9
3.3.Thời gian và chi phí .10
3.4.Giao tiếp 10
3.5.Giai đoạn sau khi hoàn thành sản phẩm 11
4.Áp dụng phương pháp Agile 11
4.1.Điều kiện áp dụng 11
4.2.Cơ cấu làm việc trong Agile 12
4.3.Quy trình thực hiện .14
5.Thực trạng, giải pháp ứng dụng Agile ở Việt Nam 15
6.Kết luận 16
TÀI LIỆU THAM KHẢO 18
BÀI DỊCH CASE STUDY AGILE DEVELOPMENT CÓ THỂ LÀM CÔNG VIỆC KINH DOANH
Trang 3TRỞ NÊN NHANH CHÓNG VÀ NHẸ NHÀNG
Nhưng công nghệ thông tin phải truyền đạt lợi ích của nó nếu
các nhà quản lý chấp nhận nó
“Agile software development” có thể giúp ngăn ngừa các tổ chức bởi những ý tưởng
và chiến lược kinh doanh lỗi thời, nhưng nó có thể khiến một số nhà quản trị lo lắng, theo lời của các chuyên gia nói với thành viên Hiệp hội máy tính New Zealand tại một cuộc họp NZCS gần đây
Theo lời nhà phát triển Shane Hastie: “Agile software development” là một trong những cách mà các IT có thể bảo vệ khỏi việc trở thành một gánh nặng trì trệ làm thay đổi các doanh nghiệp Lối phân tích cứng rắn và kỹ thuật phát triển không linh hoạt có thể giam hãm các tổ chức vào những ý tưởng lỗi thời và cũng có thể kìm hãm sự phát triển thương mại Quản lí có thể đánh giá cao những lợi ích của kỹ thuật phát triển nhanh, nhưng với điều kiện những lợi ích này được truyền đạt đúng cách, ông nói Hastie, kỹ sư trưởng ở Hiệp hội phần mềm giáo dục, là một trong hai nhà phát triển đã diễn thuyết về giai đoạn “bird of the feather” trong phiên họp về phát triển nhanh, tổ chức tại Wellington vào đầu tháng này
Giải trình viên Stephen Hilson, hiện đang làm việc cho Telecom, cho biết các nhà quản lí nói chung và công nghệ thông tin nói chung đang lo lắng về tính chất thiếu tự nhiên của các phương pháp nhanh, đặc biệt là khi nói đến các ngành quan trọng, chẳng hạn như viễn thông
Theo lời Hilson: “ngành viễn thông phù hợp với công nghệ nhanh xung quanh một khung của sự phát triển theo mô hình thác nước nhiều hơn thông thường- bắt đầu với một đặc điểm kỹ thuật đầy đủ và làm việc thông qua thiết kế, lập trình và thử nghiệm giai đoạn tuyến tính”
Bản chất của Agile development là việc tạo ra các mảnh nhỏ của chương trình và đôi khi dẫn đến việc nhận ra rằng sự thiết kế ban đầu của chương trình hoặc là sẽ không làm việc hoặc là cần được sửa đổi Điều này dẫn đến thiết kế lại lặp đi lặp lại và tái
mã hóa, độc lập với các phần khác của sự phát triển
Bề ngoài, quá trình này có vẻ phi cấu trúc, nhưng yêu cầu “nổi sóng” có lẽ là thực sự thực tế với yêu cầu của cuộc sống phát triển Trong một môi trường linh hoạt, thực hiện công việc thường xuyên theo dõi có nghĩa là chỉ có một công việc nhỏ được bỏ
đi, Hastie nói
Ngược lại, một thiết kế không đáng tin dựa trên những đặc điểm kỹ thuật vững chắc,
có thể cho thấy việc vứt bỏ nhiều hơn với những tác động chính ảnh hưởng lớn đến tiến độ dự án Điều này rất quan trọng trong nguồn lực hạn chế ở New Zealand, ông
Trang 4nói Và nếu các mục tiêu hoàn thành là khó nhìn thấy ngay, thì các kỹ thuật nhanh nhẹn có thể ít nhất là cung cấp đủ để các doanh nghiệp tiến xa hơn
Các diễn giả thừa nhận rằng, với sự phát triển nhanh, các sản phẩm cuối cùng có thể khác với yêu cầu ban đầu Nhưng nó có xu hướng phù hợp hơn với nhu cầu của doanh nghiệp tại thời điểm hoàn thành- hơn là nhu cầu của mình khi bắt đầu, mà bây giờ có
lẽ đã lỗi thời
Nếu quản lý và người sử dụng có liên quan, họ sẽ hiểu được logic của cách mà nhóm ICT lựa chọn để phát triển
Hastie phát biểu: “Hai trong số những yếu tố quan trọng nhất là trình độ cao về sự tham gia của khách hàng và hỗ trợ giám đốc điều hành Nếu bạn có được chúng, bạn
sẽ thành công bất kể bạn đang sử dụng thứ công nghệ gì”
Bản chất của phát triển nhanh đã được biết đến từ 10 đến 15 năm, và được biết đến như một thử nghiệm tốt, theo lời Hastie Các yếu tố cần thiết đang được lập trình với các nhóm đồng nghiệp, chuyển tiếp nhanh chóng với những đơn vị nhỏ, liên hệ chặt chẽ với khách hàng, và sự tiếp xúc hằng ngày, nơi các nhà phát triển báo cáo về công việc mà họ đã đạt được từ cuộc họp cuối cùng, cũng như những gì họ dự định làm tiếp theo và bất kì trở ngại nào mà họ gặp phải
Phương pháp Agile đã được biết đến từ năm 2001- “Hãy kết hợp những thử nghiệm hay vào với nhau”
Câu hỏi:
Những khác biệt giữa mô hình thác nước truyền thống và mô hình phát triển nhanh, đề xuất những ứng dụng tương ứng giữa chúng để liên kết mục tiêu của doanh nghiệp và chiến lược IT?
TÓM TẮT TÌNH HUỐNG
Trang 5Agile development có thể làm công việc kinh doanh nhanh chóng và nhẹ nhàng hơn, giúp ngăn ngừa các tổ chức khỏi bị giam hãm vào những ý tưởng và chiến lược kinh doanh lỗi thời Nó khắc phục được lối phân tích cứng rắn và kỹ thuật phát triển không linh hoạt cũng như những thiết kế không đáng tin ảnh hưởng đến tiến độ dự án Tuy nhiên, vì tính chất thiếu tự nhiên của phương pháp nhanh mà có ý kiến cho rằng nó không phù hợp với ngành viễn thông
Bản chất của Agile development là việc tạo ra các mảnh nhỏ của chương trình và đôi khi những thiết kế ban đầu cần sẽ không được thực hiện hoặc sẽ được thay đổi, điều này có thể dẫn đến sản phẩm cuối cùng không giống với yêu cầu ban đầu nhưng nó phù hợp hơn với nhu cầu doanh nghiệp tại thời điểm hoàn thành
Hai trong số những yếu tố quan trọng nhất là trình độ cao về sự tham gia của khách hàng và sự hỗ trợ của giám đốc điều hành, nếu có được bạn sẽ thành công bất kể bạn đang sử dụng công nghệ gì
“Hãy kết hợp những thứ công nghệ này với nhau”
BÀI PHÂN TÍCH
Trang 6Ngày nay, công nghệ thông tin đóng một vai trò quan trọng trong các hoạt động kinh tế, sản xuất kinh doanh, bán hàng, xúc tiến thương mại, quản trị doanh nghiệp… Việc áp dụng các ứng dụng của công nghệ IT đã trở thành một phần không thể thiếu của đời sống cũng như các hoạt động của nền kinh tế nói chung
và các doanh nghiệp nói riêng Đặc biệt là việc phát triển hệ thống thông tin kinh doanh là yếu tố quan trọng góp phần vào sự thành công của doanh nghiệp Hiện nay, có rất nhiều phương pháp phát triển hệ thống và một trong những phương pháp chiếm lĩnh ưu thế nhất, đáp ứng kịp thời nhu cầu của khách hàng là phương pháp phát triển Agile Để hiểu rõ hơn về phương pháp này, sau đây là bài nghiên cứu mà nhóm chúng tôi đã thực hiện
1 Khái quát chung về mô hình Waterfall và mô hình Agile
1.1 Mô hình thác nước Waterfall
Mô hình thác nước (Waterfall) ra đời vào những năm 70, là một mô hình cổ điển và được áp dụng trong quy trình phát triển phần mềm tại phần lớn các công
ty Mô hình Waterfall là một chuỗi quy trình phát triển như một luồng đều đặn từ trên xuống giống như một thác nước, bao gồm các giai đoạn: phân tích yêu cầu khách hàng, thiết kế, cài đặt, kiểm tra, tích hợp và bảo trì
Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu chừng nào giai đoạn trước chưa hoàn thành Sản phẩm đầu ra của giai đoạn trước trở thành sản phẩm đầu vào của giai đoạn sau Trước hết, giai đoạn "xác định yêu cầu" phải được hoàn tất, kết quả nhận được sẽ là danh sách các yêu cầu đối với phần mềm Sau khi các yêu cầu đã hoàn toàn được xác định, sẽ chuyển sang giai đoạn thiết kế, ở giai đoạn này người ta sẽ tạo ra các tài liệu dành cho lập trình viên, trong đó mô tả chi tiết các phương pháp
và kế hoạch thực hiện các yêu cầu đã được làm rõ ở giai đoạn trước Sau khi giai đoạn thiết kế hoàn tất, lập trình viên sẽ triển khai thực hiện (mã hóa, viết mã) đồ án
họ nhận được Giai đoạn tiếp theo là liên kết các thành phần riêng lẻ đã được những đội lập trình viên khác nhau thực hiện thành một sản phẩm hoàn chỉnh Sau khi triển khai và liên kết hoàn tất, sẽ diễn ra việc kiểm thử và chỉnh sửa sản phẩm;
ở giai đoạn này những khiếm khuyết ở các giai đoạn trước đó sẽ bị loại bỏ Sau đó, sản phẩm phần mềm sẽ được đưa vào sử dụng; phần bảo trì phần mềm cũng sẽ được bảo đảm bằng cách bổ sung chức năng mới và loại trừ các lỗi Ưu điểm của Waterfall là dễ quản lý Tuy nhiên, nhược điểm của nó là quá cứng nhắc và thiếu thực tế bởi việc thay đổi của bất kỳ phần nào của quy trình cũng là không thể, vì việc làm lại các giai đoạn ban đầu để đáp ứng sự thay đổi thường mất rất nhiều công sức và phá vỡ cấu trúc phần mềm
Để khắc phục nhược điểm này của Waterfall, phương pháp Agile ra đời với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóa theo thời
Trang 7gian mà không cần phải làm lại từ đầu Phương thức này tập trung vào tính đơn giản: Tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng ngày hôm nay và sẵn sàng cho những thay đổi vào ngày mai
1.2 Mô hình phát triển linh hoạt Agile.
Agile là một triết lí cho việc phát triển phần mềm Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm, chẳng hạn như Exetreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile
Mỗi phương pháp Agile bao gồm tập hợp các quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc trình diễn sản phẩm hàng tuần cho khách hàng Có thể nói, phương pháp phát triển linh hoạt Agile là một nhóm các phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp và tiên tiến, theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường sử dụng cách lập kế hoạch thích ứng, việc phát triển và chuyển giao theo hướng tiến hóa,
sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển Nhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm
2 Phương pháp phát triển linh hoạt (Agile development method):
Để khắc phục những đặc điểm của phương pháp Waterfall, vào đầu những năm
90, một phương pháp phát triển phần mềm mới đã ra đời Phương pháp này cho phép các phần mềm có khả năng biến đổi, sửa chữa ngay cả khi dự án đã bắt đầu
Đó là phương pháp phát triển phần mềm linh hoạt
2.1 Đặc điểm:
Phương pháp phát triển linh hoạt cho phép các dự án được hoàn thành nhanh chóng mà vẫn đảm bảo được yêu cầu về chất lượng và dễ dàng trong việc sửa chữa, cập nhật khi những yêu cầu thay đổi vào bất cứ giai đoạn nào của dự án cho đến khi dự án kết thúc và sản phẩm được giao cho khách hàng Phương pháp phát triển linh hoạt có những đặc điểm sau:
Được phát triển dựa trên quy trình phát triển lặp (interative development) - mỗi
dự án sẽ được chia ra thành nhiều mảng nhỏ, dễ sử dụng và dễ sửa đổi khi yêu cầu của khách hàng thay đổi Dự án sẽ được thực hiện theo từng mảng nhỏ này, giống như những dự án nhỏ, hết dự án này quy trình
sẽ lại bắt đầu với dự án tiếp theo cho đến khi tất cả những yêu cầu của khách hàng được đáp ứng và dự án được bàn giao
Với phương pháp phát triển linh hoạt, cứ mỗi hai hay bốn tuần, nhóm lập trình viên sẽ giao cho khách hàng một phần của dự án, khách hàng sẽ kiểm tra và được khuyến khích đưa ra những ý kiến, nếu khách hàng muốn có sự thay đổi nào thì nhóm lập trình viên sẽ sửa đổi Cần lưu ý là không giống phương pháp
Trang 8Waterfall, việc sửa đổi này giúp cho ứng dụng tốt hơn, đẹp hơn và không phá hỏng nó, không buộc phải bắt đầu lại từ đầu
Với phương pháp phát triển linh hoạt, từng phần nhỏ của dự án phần mềm sẽ được test ngay trong quá trình làm dự án và việc này do chính các lập trình viên làm thay vì phải có các nhóm kiểm tra (tester) độc lập Bằng cách sử dụng công cụ “unit test” (kiểm tra từng phần) Từng phần của dự án sẽ được kiểm tra ngay trong quá trình phát triển trước khi tích hợp vào phần mềm
Phương pháp phát triển linh hoạt nhấn mạnh vào việc gặp mặt trao đổi hàng ngày giữa các thành viên trong nhóm dự án Khác với phương pháp phát triển truyền thống, các thành viên của nhóm dự án được chia ra phát triển từng mảng riêng biệt, với phương pháp Agile, tại mỗi thời điểm, cả nhóm cùng tập trung phát triển một mảng dự án Vì vậy, phương pháp Agile yêu cầu các thành viên có sự tập trung về địa lí, cùng bàn bạc thảo luận hàng ngày để hoàn thành dự án đúng hạn
Phương pháp phát triển Agile dựa vào việc phát triển trên từng nhóm nhỏ (10 thành viên trở xuống), các thành viên phải là những người có kĩ năng cao và hiểu biết về dự án, hơn nữa, các thành viên cần tin tưởng lẫn nhau, chia sẻ thông tin với nhau Với nhóm ít thành viên, các thành viên cũng cần có nhiều kĩ năng hơn so với việc lập trình và kiểm thử truyền thống
Với những đặc điểm như trên, hiện nay phương pháp phát triển linh hoạt đang ngày càng được ứng dụng rộng rãi với những phần mềm trị giá hàng chục triệu, thậm chí hàng trăm triệu đô la Mỹ
2.2 Nguyên tắc:
- Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và linh hoạt
- Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai đoạn cuối
- Bàn giao sản phẩm theo chu kỳ từ vài tuần đến vài tháng, chu kỳ ngắn tốt hơn chu kỳ dài
- Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau hằng ngày
- Tổ chức dự án xoay quanh những cá nhân tích cực, hỗ trợ và tin tưởng họ
- Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp
- Các chức năng đã hoạt động là thước đo chính cho tiến độ dự án
- Khuyến khích phát triển bền vững: lập trình viên, người dùng, nhà quản lý,…phải có khả năng tham gia dự án một cách liên tục
- Liên tục cải tiến chất lượng thiết kế và mã nguồn
- Tính đơn giản giữ vai trò cốt yếu, làm càng ít càng tốt
- Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ
Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc
3 So sánh mô hình Agile và mô hình thác nước
Trang 9Phương pháp phát triển linh hoạt đôi khi bị đánh giá là thiếu tính kỷ luật Nhưng hiểu vấn đề một cách đúng đắn thì phương pháp phát triển linh hoạt có khả năng thích ứng cao, nhanh chóng thích nghi với những thay đổi thực tế
3.1 Mức độ rủi ro:
Mô hình thác nước thực hiện bước kiểm tra dự án chỉ một lần cuối cùng sau khi tổng hợp kết quả làm việc của các nhóm Vì vậy nếu như có lỗi hay sai sót gì trong dự án thì rất khó để sửa được Vấn đề chỉ có thể giải quyết bằng cách sửa lại
và thiết kế một hệ thống hoàn toàn mới Và như thế thì sẽ nâng cao chi phí kiểm tra và sửa lỗi
Mô hình Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mền trong những khung thời gian ngắn Mỗi bước lặp giống như phát triển một phần mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, viết code, test, viết tài liệu Cho nên khi lỗi sẽ được phát hiện sau mỗi giai đoạn chứ không phải là khi hoàn thành sản phẩm nên sẽ ít tốn kém thời gian và chi phí hơn
3.2 Tính linh hoạt của mô hình
Mô hình Agile rất hoan nghênh những đóng góp của khách hàng để hoàn thiện sản phẩm hơn Có nghĩa là mặc dù đã tiến hành dự án nhưng phương pháp Agile vẫn có thể thay đổi hoặc thêm vào theo yêu cầu của khách hàng
Mô hình thác nước thì đòi hỏi tất cả các thông tin về sản phẩm và yêu cầu đặt
ra phải hoàn hảo ngay từ đầu và chỉ một thay đổi nhỏ hoặc sai sót sẽ ảnh hưởng đến toàn hệ thống Cho nên một khi dự án bắt đầu thì rất khó để thay đổi theo yêu cầu mới của khách hàng
3.3 Thời gian và chi phí
Mô hình thác nước ngay từ ban đầu đã hoạch định được rõ ràng thời gian hoàn thành và số vốn đầu tư cho dự án Thường mức độ sai lệch rất thấp Còn mô hình Agile có thể thay đổi theo yêu cầu của khách hàng nên khó để xác định được thời gian hoàn thành sản phẩm và số tiền cần thiết sử dụng khi bắt đầu dự án Theo phương pháp này thì chỉ có thể trả lời câu hỏi cho từng giai đoạn ngắn
3.4 Giao tiếp
Phương pháp Agile nhấn mạnh tầm quan trọng của giao tiếp thời gian thực, giao tiếp mặt đối mặt được đánh giá cao hơn là các tài liệu viết Hầu hết các đội phát triển theo kiểu Agile đều được tập trung trong một môi trường có điều kiện thuận lợi cho việc giao tiếp và các đội này phải bao gồm các lập trình viên và các khách hàng của họ
Mô hình thác nước thì ít có sự liên kết với nhau, sau khi được chia nhóm để thực hiện từng phần của dự án thì họ làm việc riêng lẻ và không có sự trao đổi với nhau, về phía khách hàng thì như đã nói phương pháp này ít có sự thay đổi nên vai trò của khách hàng không được phát huy trong quá trình thực hiện dự án Chỉ cho
Trang 10đến khi các giai đoạn hoàn thành và tạo ra sản phẩm cuối cùng thì họ mới gặp gỡ nhau để kiểm tra sản phẩm và tìm lỗi sai
3.5 Giai đoạn sau khi hoàn thành sản phẩm
Mô hình thác nước không thể tiêp tục phát triển được sản phẩm của mình nữa Nhưng mô hình Agile thì khác, trong khi thực hiện dự án họ có thể tạo ra những sản phẩm có những tính chất cơ bản mà khách hàng yêu cầu để đáp ứng một cách sớm nhất và dựa trên sản phẩm đó họ có thể nâng cấp sản phẩm để có thêm những tính năng mới mà khách hàng mong muốn
4 Áp dụng phương pháp Agile
4.1 Điều kiện áp dụng
Agile ra đời là sự cách tân, khắc phục những hạn chế mà các phương pháp truyền thống không thực hiện được Tuy nhiên, có phải lúc nào sử dụng phương pháp Agile cũng là tốt hay không? Ví dụ, nếu mục tiêu của bạn là nhằm tăng năng suất lao động, làm cho các lập trình viên làm việc nhanh hơn thì Agile không phù hợp vì nguyên tắc của nó không nhằm làm tăng năng suất Một phương pháp bất kì nào cũng đều có những ưu, nhược điểm riêng Do vậy, để có thể lựa chọn được phương pháp phù hợp với dự án của mình, trước hết bạn phải trả lời được những câu hỏi sau: Với dự án này, điều kiện công ty như thế này thì việc áp dụng phương pháp này hay phương pháp kia thì mang lại hiệu quả cho doanh nghiệp, cho công
ty của bạn nhiều hơn ?; lợi ích và những thiệt hại mà công ty có thể gặp phải khi
áp dụng mô hình đó? Theo như những đặc điểm đã phân tích ở trên thì doanh nghiệp có những đặc điểm sau sẽ phù hợp với việc áp dụng mô hình Agile:
Thứ nhất, mức độ rủi ro thấp Mức độ rủi ro của dự án có thể hiểu là khả
năng thực hiện và mức độ thành công của dự án Bất kì một dự án nào, nếu mức độ rủi ro cao và khả năng thành công của dự án thấp thì hiếm khi hoặc không được thực hiện
Thứ hai, kích thước nhóm nhỏ, các thành viên cùng làm việc tại một địa điểm Từ đặc điểm thường xuyên trao đổi thông tin giữa các thành viên trong
nhóm với nhau, phương pháp Agile rất thích hợp với những dự án có nhóm nhỏ từ hai đến tám người, vì nếu đông người quá thì việc trao đổi thông tin sẽ kém hiệu quả, các thành viên trong nhóm có thể sẽ đùn đẩy trách nhiệm cho nhau, môi trường làm việc sẽ không thân thiện Ngoài ra, trong phương pháp Agile, một thành viên trong nhóm có thể làm nhiều công việc, từ giao tiếp với khách hàng, thu nhận yêu cầu, thiết kế, bàn giao….nên không cần quá nhiều người trong cùng một nhóm Bên cạnh đó, các thành viên trong nhóm phải cùng làm việc tại một địa điểm thì việc trao đổi thông tin mới được thuận lợi
Thứ ba, thành viên trong nhóm có kinh nghiệm Vì Agile tập trung cho
các dự án nhỏ và có thời gian hoàn tất ngắn nên đòi hỏi có những cá nhân tài năng,