Báo cáo bài tập tình huống hệ thống thông tin quản trị agile development methods

Khái quát chung về mô hình Waterfall và phương pháp 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 tron

KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO BÀI TẬP TÌNH HUỐNG

HỆ THỐNG THÔNG TIN QUẢN TRỊ

ĐỀ TÀI:

CASE STUDY 13.1:

AGILE DEVELOPMENT METHODS

GVHD : Nguyễn Dương Thuấn Lớp : T01

Nhóm sinh viên :

1 Phạm Văn Trọng

2 Nguyễn Tiến Thăng

3 Bùi Thị Mỹ Hằng

4 Nguyễn Hằng Ngọc

5 Vũ Duy Hưng

6 Nguyễn Ngọc Tú

7 Trần Trọng Quyền

TP.HCM – 2010

DANH SÁCH PHÂN CÔNG NHÓM

STT Mã SV Họ và tên Nhiệm vụ Ký tên

1 030124081019 Phạm Văn Trọng dụng pp Agile, tổng Tìm tài liệu, ứng

hợp.

2 030124080800 Nguyễn Tiến Thăng Tìm tài liệu, ứng dụng pp Agile.

3 030124080236 Bùi Thị Mỹ Hằng

Tìm tài liệu, khái quát, đặc điểm, nguyên tắc, so sánh Waterfall và Agile.

4 030124081177 Nguyễn Hằng Ngọc

Tìm tài liệu, khái quát, đặc điểm, nguyên tắc, so sánh Waterfall và Agile.

5 030124080352 Vũ Duy Hưng Tìm tài liệu, ứng dụng pp Agile.

6 030124081039 Đỗ Hoàng Tú Tìm tài liệu, ứng

dụng pp Agile.

7 030124080739 Trần Trọng Quyền Tìm tài liệu, làm slide.

MỤC LỤC

1 Khái quát chung về mô hình Waterfall và phương pháp Agile 5

1.1 Mô hình thác nước Waterfall 5

1.2 Phương pháp Agile 6

2 Phương pháp phát triển linh hoạt (Agile Development method) 6

2.1 Đặc điểm 6

2.2 Nguyên tắc 7

3 So sánh Agile và Waterfall 7

4 Áp dụng phương pháp Agile 9

4.1 Điều kiện áp dụng phương pháp Agile 9

4.2 Cơ cấu làm việc trong Agile 9

4.3 Quy trình thực hiện 11

5 Kết luận 12

BÀI DỊCH CASE STUDY

AGILE DEVELOPMENT CÓ THỂ LÀM CÔNG VIỆC KINH DOANH

TRỞ 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 khỏi bị giam hãm vào 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 đầ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 riêng đ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 thử nghiệm 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 việc phát triển nhanh là việc tạo ra các mảnh nhỏ của một chương trình, một quá trình mà đô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 cần phải đượ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" thực sự là một ứng dụng thực tế của cuộc sống phát triển, các diễn giả nói 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 nó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 đủ để giữ cho 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 kế hoạch 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ó thể đã 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 với 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 kể 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 vào khoảng 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à phương pháp phát triển nhanh, đề xuất những ứng dụng tương ứng của họ để 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

Agile 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ông 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 và 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 được sẽ không được thực hiện hoặc là phải thay đổi, điều này có thể dẫn đến sản phẩm cuối cùng khác với kế hoạch ban đầu nhưng nó 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

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 thứ 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

Ngày nay, công nghệ thông tin (IT) có vai trò rất lớn trong 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ủ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ư trong các hoạt động của nền kinh tế nói chung và của 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 một 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 được đánh giá là chiếm lĩnh ưu thế trong những năm gần đây : phương pháp phát triển

linh hoạt (Agile Development Methods).

1 Khái quát chung về mô hình Waterfall và phương pháp 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 Waaterfall là một chuỗi quy trình phát triển như một luồng đều đặn từ trên xuống họat độ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á 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 sẽ trở thành đầu vào của giai đoạn sau Ư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 ở 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 của phần mềm

Để khắc phục đượ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 gian mà không cần phải làm lại từ đầu Phương pháp 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 hôm nay và sẵn sàng cho những thay đổi vào ngày mai

1.2 Phương pháp Agile

Là phương pháp phát triển phần mềm chú trọng vào sự tiến hóa, phát triển của nó theo thời gian (xây dựng bồi đắp thêm, mở rộng thêm) với sự kế thừa tối đa, hiệu chỉnh lại cho phù hợp và tránh phải bắt đầu làm một thành phần nào đó lại từ đầu

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ư Extreme Programming (XP) hay Scrum, gọi tắt là phương pháp Agile

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 ý tưởng mới, những yêu cầu mới hoặc thay đổi những yêu cầu của dự án Theo đó, nhóm lập trình viên có thể cập nhật và sửa đổi sản phẩm theo đúng yêu cầu của khách hàng thay vì chỉ căn cứ vào hợp đồng và làm việc Cần lưu ý là không giống với phương pháp Waterfall, 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àg 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à liên tục

 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 Agile và Waterfall

Agile hoạt động dựa trên nguyên tắc lặp, tức là, mỗi dự án được chia thành nhiều module nhỏ, mỗi module đều thực hiện những chức năng giống nhau được lặp đi lặp lại: tập hợp yêu cầu, lập kế hoạch, phân tích, code, test… cũng với một trình tự như vậy nhưng Waterfall lại hướng đến cách tiếp cận cấu trúc có định trước, nó không có sự linh hoạt trong việc phân chia các giai đoạn của dự án, mỗi khâu phải đảm bảo hoàn thành chính xác 100% trước khi chuyển sang khâu tiếp theo Đây có thể coi là sự khác nhau cơ bản dẫn đến những khác nhau tiếp theo của hai phương pháp

Thứ nhất, về rủi ro của hai phương pháp, theo phương thức hoạt động của Waterfall,

kiểm tra là bước thực hiện một lần và duy nhất và cuối mỗi dự án, như vậy, nếu dự án có lỗi sai thì lỗi sai đó chỉ được phát hiện khi dự án đã sắp hoàn thành, rủi ro gặp phải là rất lớn, hơn nữa, chi phí tìm kiếm và sửa chữa là rất tốn kém bởi các khâu trong cả quá trình cảu dự

án có mắt xích với nhau Tuy nhiên, Agile đã khắc phục điều này Với các module nhỏ hoạt động như nhau, Agile cho phép dự án được kiểm tra một cách thường xuyên bởi cứ cuối mỗi giai đoạn thử nghiệm đều có thể đưa ra kết quả Như thế đảm bảo phát hiện và loại bỏ

các lỗi sai trong vùng phát triển, kết quả sẽ được kiểm tra lại hai lần sau đợt sàng lọc lỗi đầu tiên, từ đó, giảm thiểu tối đa rủi ro cho mình cũng như khách hàng, tiết kiệm được thời gian cũng như chi phí dành cho dự án Thực tế cho thấy, những dự án làm theo phương pháp water mất từ 6 tháng đến 1 năm, trong khi đó, Agile chỉ mất khoảng 1-2 tháng để hoàn thành dự án

Thứ hai, tính linh hoạt và sự phù hợp với thực tế của Waterfall gần như bị triệt tiêu đến

thời điểm bàn giao dự án cho khách hàng, đặc biệt đối với những ngành nghề mang tính chất nhạy cảm cao với thông tin thị trường, thường xuyên thay đổi như tài chính ngân hàng nhưng Agile lại hoàn toàn ngược lại Với Waterfall, khách hàng phải gần như phải đưa ra tất cả yêu cầu, thông tin ngay từ khi ký kết hợp đồng, một sự thay đổi cũng rất khó bởi nó ảnh hưởng đến cả một hệ thống Từ đây, chúng ta thấy, có thể 6 tháng trước, với những thông tin đó sẽ đưa ra những phân tích chính xác về thị trường, nhưng 6 tháng sau, có nhiều yếu tố thay đổi không thể lường trước, những thông tin đưa vào lúc đầu không còn phù hợp nữa Nếu muốn, chúng ta chỉ có thể quay lại lập trình lại hệ thống từ đầu, như vậy

sẽ rất mất thời gian và tốn kém Trong khi đó, khách hàng của Agile lại có thể thay đổi yêu cầu của mình trước những biến động bất thường của thị trường, vì cứ cuối mỗi giai đoạn của Agile sẽ có một chương trình hợp lý được lập trình nhằm giải quyết và sửa chữa những ý tưởng mới

Thứ ba, do yêu cầu và mục tiêu của phương pháp mà yêu cầu về nguồn nhân lực của

hai phương pháp này cũng khác nhau Phương pháp Agile chú trọng đến việc giao tiếp khách hàng thường xuyên trong thời gian thực hiện hợp đồng nhằm đưa đến một sản phẩm tốt nhất, phù hợp nhất Mỗi cá nhân hoạt động theo phương pháp Agile không chỉ là những người lập trình viên viết code hay những tester đơn thuần, họ phải biết tất cả các khâu để hoàn thành dự án đó: từ việc marketing, thỏa thuận với khách hàng, đến việc thiết kế, phân tích, bàn giao và đưa sản phẩm ra thị trường Agile khuyến khích làm việc nhóm, hoạt động trong môi trường mở, giảm thiểu tối đa những truyền đạt mang tính chất giấy tờ Đây có thể coi là một phong cách làm việc mới trong giai đoạn hiện nay Agile đối lập hoàn toàn với Waterfall ở điểm này, khi mà các cá nhân của Waterfall chỉ quan tâm đến một khâu mà họ đảm nhiệm

Thứ tư, Agile phù hợp với những dự án nhỏ, có tính chất thay đổi thường xuyên, yêu

cầu thời gian hoàn thành nhanh chóng và rủi ro thấp như thiết kế Web Waterfall lại phù hợp hơn với những dự án lớn, không có yêu cầu thay đổi nhiều

Thêm vào đó, đặc tính tự điều chỉnh của phương pháp Agile chính là tận dụng tốt hơn những lập trình và chương trình hướng đến đối tượng phù hợp, nghĩa là phương pháp này sở hữu mô hình hoạt động đưa ra những kết quả kịp thời ngay cả khi phương pháp này không phù hợp hoàn toàn với những chỉ định của khách hàng Trong khi đó, phương pháp Waterfall chỉ đưa ra được một kết quả duy nhất và bất kì rắc rối hay trì hoãn nào đều khiến khách hàng thất vọng Cùng với đó là việc phương pháp Agile thậm chí còn cải thiện chất lượng phần mềm do chúng chú trọng vào việc thử nghiệm Phương pháp Agile khuyến khích các lập trình viên tự mình thử nghiệm, thường xuyên yêu cầu họ đưa ra các thử nghiệm trước khi đưa ra bất kì mã nào và phát triển những thói quen kiểm tra tự động cho các chương trình họ đưa ra

Cuối cùng, cần phải có rất nhiều hệ thống khác để tương tác với phương pháp Waterfall Đối với phương pháp Agile, điều này không cần thiết

Tuy nhiên, cả hai phương pháp đều cho phép thực hiện phân khu, cụ thể trong phương pháp Waterfall việc phân khu được thực hiện vào mỗi giai đoạn Đối với phương pháp Agile, mỗi module đã được mã hóa đều có thể được phân bổ cho những nhóm lập trình khác

nhau Điều này cho phép nhiều phần trong dự án được hoàn thành cùng lúc thế nên việc phân khu được sử dụng hiệu quả hơn trong phương pháp Agile

4 Áp dụng phương pháp Agile

4.1 Điều kiện áp dụng phương pháp Agile

Agile là một phương pháp tốt, tuy nhiên không phải trường hợp nào cũng áp dụng được phương pháp này Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu hỏi: đối với dự án này, điều kiện của công ty như thế này thì liệu phương pháp Agile có giúp bạn thành công hơn khi áp dụng các phương pháp khác hay không? Các dự án

có đặc điểm sau đây có thể phù hợp với Agile:

4.1.1 Mức độ rủi ro thấp

Mức độ rủi ro của dự án có thể được hiểu là khả năng thực hiện và mức độ thành công của dự án Dự án nào có tính khả thi thấp, tức là mức độ rủi ro cao thì không nên áp dụng

mô hình này

4.1.2 Thành viên 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, do đó phương pháp này đòi hỏi có những cá nhân tài năng, những người sẵn lòng làm mọi chuyện và có năng lực tổng quát hóa, có thể làm qua nhiều công đoạn trong vòng đời truyền thống của sản phẩm Phương pháp Agile cần có các cá nhân đa năng, có động lực, biết nghiên cứu, biết phân tích, biết sáng tạo, và có các kỹ năng giao tiếp cần thiết để hiểu thấu các vấn đề của khách hàng Họ cũng phải là những người làm việc nhóm có tính kỹ luật, và là những kỹ sư phần mềm tài ba có thể cho ra đời sản phẩm đúng hạn thời gian cho phép

4.1.3 Nhu cầu thay đổi thường xuyên

Khi thực hiện phương pháp này, các thành viên trong nhóm sẽ tiếp xúc thường xuyên với khách hàng, trao đổi thường xuyên để cùng hoàn thiện dự án Do vậy, đối với các dự án

có tính ổn định cao, ít thay đổi thì áp dụng phương pháp này là không cần thiết

4.1.4 Kích thước nhóm nhỏ, các thành viên làm việc cùng một địa điểm

Xuất phát từ yêu cầu trao đổi thông tin thường xuyên giữa các thành viên trong nhóm, nên phương pháp Agile đòi hỏi nhóm không cần quá nhiều thành viên, nếu quá nhiều thành viên sẽ làm cho sự quản lý nhóm, trao đổi giữa các thành viên trong nhóm trở nên không hiệu quả Mặt khác, yêu cầu quan trọng nữa là các thành viên phải cùng làm việc tại cùng một địa điểm, khi đó sự trao đổi thông tin mới có hiệu quả hơn

4.1.5 Văn hóa công ty ưa thích sự “không trật tự”

Bởi vì có như thế các thành viên mới mạnh dạn đưa ra những chính kiến của mình trong quá trình làm việc nhóm Nhằm phát huy tính sáng tạo cao nhất của các thành viên

Trái lại, những điều kiện sau đây là vật cản cho việc áp dụng Agile:

 Kích thước nhóm lớn

 Các thành viên phân tán về mặt địa lí (ví dụ các dự án outsource)

 Văn hóa làm việc theo mệnh lệnh

4.2 Cơ cấu làm việc trong Agile

Phương pháp Agile thích hợp nhất cho những dự án có các yêu cầu sản phẩm hay thay đổi nhanh chóng như các dự án Web hay các sản phẩm cần được hoàn tất trong một khoảng thời gian ngắn Với phương pháp Agile, một dự án có thể được chia ra thành nhiều phần

nhỏ; mỗi phần có thể được hoàn tất trong một tuần hay một tháng, được gọi là sprint Nhóm