Phương pháp luận dự án phần mềm:

Truyền thống và Agile

Ngô Trung ViệtGiám đốc tri thức QNET

ntviet@gmail.com

Nội dung

● Mô hình vòng đời hệ thống● Phương pháp luận● Khuôn khổ qui trình phát triển phần mềm● Khuôn khổ: truyền thống và Agile● Agile● XP● Scrum

1. Mô hình vòng đời hệ thống

● Mô hình vòng đời hệ thống nhấn mạnh chủ yếu vào công việc phải làm khi phát triển một sản phẩm (khía cạnh kĩ thuật):

● Những pha bắt buộc phải trải qua, ● Sản phẩm và tài liệu cần được tạo ra.

Mô hình thác đổ

Waterfall

Quan niệm phần mềm

Yêu cầu

Phân tích

Thiết kế

Viết mã & gỡ lỗi

Kiểm thử hệ thống

Triển khai & bảo trì

•Quan niệm•Thăm dò quan niệm•Thăm dò hệ thống

•Phân tích yêu cầu

•Thiết kế kiến trúc

•Thiết kế chi tiết

•Thực hiện

•QA

•Sản xuất•Vận hành

Thác đổ

● “Cụ tổ” của các mô hình ● Trình tự tuyến tính của các pha

● Mô hình “thuần”: không chờm lấp pha ● Dẫn lái theo tài liệu ● Mọi việc lập kế hoạch đều phải được làm

từ phía trước

Điểm mạnh của thác đổ

● Có tác dụng tốt cho các dự án với: ● Định nghĩa sản phẩm ổn định ● Công nghệ được hiểu rõ ● Ràng buộc chất lượng mạnh hơn chi phí &

lịch biểu ● Hỗ trợ cho cán bộ yếu về kĩ thuật

● Cung cấp cấu trúc ● Tốt cho các dự án hải ngoại

Nhược điểm của thác đổ

● Không linh hoạt: ● Nước đi cứng nhắc từ bắt đầu -> kết thúc ● Tổ có thể theo đến cùng các kế hoạch lỗi thời

● Khó hoàn toàn xác định được các yêu cầu từ đầu. ● Có thể là quá tin tưởng vào qui trình. ● Có thể có các qui trình thực tế không được tuân theo. ● Có thể phí nhiều thời gian để tạo ra quá nhiều tài liệu. ● Ít dấu hiệu thấy được tiến độ cho tới cuối. ● Khách hàng/Người dùng chỉ thấy được sản phẩm ở

lúc cuối.

Mô hình thác đổ

Rât thường la khach hang không biêt đıch xac yêu câu cho dự an, va chắc chắn se thay đôi khi dự an tiên triên. Người phat triên co thê phai quay lai pha trước đê lam sang to. Rât tôn thời gian lam lai viêc.

Yêu cầu

Thiết kế

Viết mã

Kiểm thử

Tích hợp

Mô hình làm bản mẫu

● Mô hình làm bản mẫu có thể xây dựng phần mềm nhanh chóng và không tốn kém để đánh giá và trình diễn.

● Việc phát triển hệ thống không đầy đủ là để hiểu hệ thống và tính đổi qui mô của vấn đề.

● Chẳng hạn:● Bản mẫu – mô hình của sản phẩm, dịch vụ hay thệ

thống được đề nghị.● Bản mẫu chứng minh khái niệm – được dùng để

chứng tỏ tính khả thi kĩ thuật của hệ thống.● Bản mẫu bán – được dùng để thuyết phục mọi người

về giá trị của hệ thống được đề nghị

Mô hình bản mẫu

Lắng nghe & thu lấy yêu cầu từ

khách hàngDựng/Sửa

bản thử

Khách hàng chạy bản thử

Mô hình phát triển ứng dụng nhanh

Vài lần lặp được xây dựng để giúp đưa hệ thống vào vị trí.

Yêu cầu Thiết kế Viết mã Kiểm thử

Yêu cầu Thiết kế Viết mã Kiểm thử

Yêu cầu Thiết kế Viết mã Kiểm thử

Yêu cầu Thiết kế Viết mã Kiểm thử

Tích hợp

Mô hình gia tăng

● Vòng đời phát triển gia tăng là mô hình phân giai đoạn trong đó các phần khác nhau của hệ thống được phát triển ở những lúc khác nhau và được tích hợp khi chúng được hoàn thành.

● Phát triển lặp là chiến lược lập lịch làm lại theo đó xét lại và cải tiến các phần của hệ thống.

● Ý tưởng cơ bản là phát triển hệ thống phần mềm tăng dần.

Mô hình gia tăng

Yêu cầu

Yêu cầu

Yêu cầu

Th. Kế Mã Kiểm Tích hợp Bảo trì

Đưa ra 1

Th. Kế Mã Kiểm Tích hợp Bảo trì

Đưa ra 2

Th. Kế Mã Kiểm Tích hợp Bảo trì

Đưa ra 3

Yêu cầu liên tục được phân tích rồi cấp phát cho một loạt các đưa ra gia tăng.

Mô hình xoáy ốcXác định mục

tiêu, phương án và ràng buộc

Đánh giá phương án nhận diện và giảm nhẹ rủi ro

Lập kế hoạch Phát triển và trắc nghiệm

lần lặp sản phẩm tiếp

Phân tích rủi ro

Phân tích rủi ro

Phân tích rủi ro

Bản mẫu 1 2 3 Lập kế hoạch

yêu cầu

Lập kế hoạch phát triển

Thiết kế

Viết mã

Kiểm thử

Xoáy ốc

● Chuỗi các tiểu dự án, từng dự án nhỏ đề cập tới một tập các “rủi ro”. ● Bắt đầu nhỏ, thám hiểm rủi ro, làm bản mẫu,

kế hoạch, lặp lại ● Nhấn mạnh vào phân tích & quản lí rủi ro

trong từng pha. ● Lặp sớm là “rẻ nhất”. ● Số xoáy ốc (lặp) là biến thiên.

Điểm mạnh điểm yếu của xoáy ốc

● Ưu điểm ● Có thể được tổ hợp với các mô hình khác ● Khi chi phí tăng, rủi ro giảm ● Xu hướng rủi ro cung cấp cảnh báo sớm

● Nhược điểm ● Phức tạp ● Yêu cầu cấp quản lí có ý thức, thông thái

V- mô hình kĩ nghệ hệ thống cổ điển

Xây dựng

Kiểm thử đơn vị

Yêu cầuhệ thống

Kiểm thử hệ thống

Yêu cầu phần mềm

Kiểm thử chấp nhận

Thiết kế sơ bộ

Kiểm thử tích hợp

Thiết kế chi tiết

Kiểm thử cấu phần

Kiểm thử và tích hợp

Phân tích và thiết kế

2. Phương pháp luận

● Tuyển tập các chính sách và thủ tục được làm tài liệu bởi tổ phát triển hay tổ chức để thực hành kĩ nghệ phần mềm được gọi là phương pháp luận phát triển phần mềm - software development methodology (SDM))

Phương pháp luận (t.)

● Mọi SDLC đều có chung các qui trình, nhưng chúng có thể thực hiện theo cách khác nhau● Hiến chương dự án và hoàn cảnh doanh nghiệp● Yêu cầu sản phẩm● Kiến trúc mức đỉnh, cách tiếp cận kĩ thuật và thiết kế

hệ thống● Cấu phần và đặc tả đơn vị và thiết kế● Viết mã, lập kế hoạch kiểm thử đơn vị và kiểm thử

đơn vị● Kiểm thử đơn vị và tích hợp● Kiểm thử hệ thống ● Cài đặt, chuyển giao và chuyển dịch● Đào tạo và hỗ trợ người dùng● Nâng cấp hệ thống và bảo trình phần mềm thường lệ

Phương pháp luận (t.) ● Mọi SDLC đều dùng cùng các qui trình hỗ trợ

(kết cấu nền), nhưng chúng có thể thực hiện khác nhau● Kiểm soát mã nguồn● Quản lí cấu hình● Tích hợp liên tục● Kiểm soát thay đổi● Dõi vết lỗi● Thu thập và phân tích các độ đo● v.v.

● Tất cả những điều này đều cần thời gian và tài nguyên để thực hiện và quản trị

Hai kiểu phương pháp luận

Truyền thống

Agile

Phương pháp luận truyền thống

● Giả định yêu cầu được biết lúc bắt đầu dự án.● Chủ sản phẩm/người dùng tham gia cùng tổ

phát triển là tối thiểu sau khi yêu cầu được chấp thuận.

● Lịch biểu, ngân sách, kiến trúc và thiết kế cho cả dự án được tạo ra “từ đầu” theo yêu cầu đã cho.

● Thay đổi được quản lí một cách chính thức. Làm lại là tốn kém và không được hỗ trợ.

● Nhiều tài liệu

Điểm mạnh của truyền thống

● Có tác dụng tốt cho các dự án mà: ● Định nghĩa sản phẩm ổn định● Công nghệ được hiểu rõ● Ràng buộc chất lượng mạnh hơn chi phí & lịch biểu● Hỗ trợ cho cán bộ yếu về kĩ thuật

● Cung cấp cấu trúc● Tốt cho các dự án ra nước ngoài

● Mô hình xoáy ốc là chuỗi các tiểu dự án, nơi từng dự án đề cập tới một tập các rủi ro● Bắt đầu nhỏ, thăm dò rủi ro, làm bản mẫu, lập kế

hoạch, lặp lại ● Từng lần lặp đều “rẻ nhất”

Điểm yếu của truyền thống

● Không linh hoạt ● Tổ có thể kiên trì theo kế hoạch lỗi thời

● Yêu cầu khó xác định từ đầu● Người dùng có xu hướng xác định nhiều yêu

cầu như họ nghĩ tới● Tin cậy vào qui trình (điều có thể không có tác

dụng tốt hay không được tuân theo) ● Có thể tạo ra quá nhiều tài liệu● Ít dấu hiệu về tiến bộ mãi cho tới cuối

Phương pháp luận Agile

● Giả định rằng yêu cầu sẽ nổi lên khi người chủ sản phẩm/người dùng làm việc cùng tổ phát triển trên cơ sở hàng ngày.

● Lịch biểu, ngân sách, kiến trúc và thiết kế cho dự án tiến hoá khi yêu cầu nổi lên

● Thay đổi được quản lí không chính thức● Sản phẩm được xây dựng nên bạn bao giờ cũng

hệ thống làm việc và có thể “đưa ra” vào mọi lúc. ● Làm lại (cải biên lại) là tốt

Scrum

Agile

● Yêu cầu được làm tài liệu như “câu chuyện người dùng” (tồn dư tính năng sản phẩm)

● Thực hiện xuất hiện trong các đợt nước rút ‘sprints’ ngắn.

● Lập kế hoạch tiền và hậu sprint và các hoạt động chấp nhận.

● Tổ tự quản. ● Họp đứng ngắn (<30 phút) hàng ngày để

trao đổi về tình trạng & vấn đề

Điểm mạnh của Agile

● Đảm bảo đáp ứng nhu cầu của khách hàng (người chủ sản phẩm xác định câu chuyện người dùng để thực hiện trong từng sprint) ● Yêu cầu không quan trọng không được phát triển

● Tài liệu tối thiểu. Ví dụ: ● Yêu cầu được xác định như câu chuyện người

dùng● Tổ phát triển là được tin cậy● Từng sprint tạo ra sản phẩm giao được tiềm năng.

Nhược điểm của Agile

● Thiếu yêu cầu miền dài nghĩa là lập kế hoạch miền dài tối thiểu

● Việc nổi lên yêu cầu đòi hỏi quản lí yêu cầu phải uỷ quyền thẩm quyền ra quyết định cho tổ Scrum.

● Yêu cầu nhiều người phát triển cấp cao. ● Một số công nhân không thoải mái với

việc tạo khả năng chịu trách nhiệm Scrum

3. Khuôn khổ qui trình

● Các qui trình phần mềm của tổ chức bắt đầu đi liền với việc quản lí các tổ chức tri thức và việc nâng cao chất lượng quản lí toàn bộ tổ chức.

● Nói riêng Quản lí dự án theo khuôn khổ qui trình nhằm đạt mục tiêu của tổ chức chứ không chỉ mục tiêu sản phẩm.

Khuôn khổ qui trình phát triển phần mềm

● Khuôn khổ qui trình phát triển phần mềm là qui định chung trong toàn tổ chức mà● dựa trên các mô hình vòng đời phần mềm

tổng quát, ● Nêu rõ các vai trò, trách nhiệm, vật phẩm, thủ

tục, phương pháp, … phải được mọi người và dự án tuân thủ.

● Khuôn khổ qui trình phần mềm đề cập tới con người làm việc dựa trên kĩ thuật, nhấn mạnh vào qui trình phối hợp, khía cạnh chất lượng và tổ chức.

Tại sao cần qui trình phần mềm?

● Bằng việc hội tụ chỉ vào sản phẩm phần mềm, bạn không thể giải quyết được vấn đề kích cỡ và độ phức tạp (tính đổi qui mô) và không có tri thức về cách làm nó tốt hơn.

● Bằng việc hội tụ vào qui trình phần mềm và hiểu mọi bước trên con đường phát triển, bạn có thể dự đoán chất lượng của sản phẩm, xu hướng dự án, và có khả năng lặp lại điều bạn đã làm trong công việc tương lai.

Yếu tố qui trình

● Qui trình được xác định của tổ chức bao gồm vài “Yếu tố qui trình” cho các hoạt động như:● Ước lượng phần mềm, lập kế hoạch phần mềm● Kiến trúc, thiết kế, làm mô hình, luồng phần mềm● Viết mã, kiểm thử và kiểm soát thay đổi● Kiểm điểm, giám định● Đào tạo và làm tài liệu

● Các yếu tố qui trình được mô tả dưới dạng chuẩn, thủ tục, hướng dẫn, khuôn mẫu, trừu tượng. v.v

● “Qui trình được xác định” của tổ chức hỗ trợ cho các mô hình vòng đời như Thác đổ, Xoáy ốc, Dựng gia tăng, Bản mẫu v.v

Các góc nhìn cải tiến qui trình

● Việc cải tiến qui trình truyền thống được nhìn theo các góc độ khác nhau: chất lượng sản phẩm, qui trình, cách tổ chức● Các mô hình vòng đời thác đổ, ● TQM: cải tiến chất lượng toàn bộ, ● CMMI: mô hình trưởng thành năng lực● ISO 9000: tổ chức quản lí ● Six Sigma: quản lí chất lượng

TQM

Cải tiến chất lượng toàn bộ TQM

● Mọi người phát triển đều là người chịu trách nhiệm cho chất lượng việc mình làm

● Đảm bảo chất lượng ở mọi khâu● Đảm bảo tuân thủ qui trình qua việc tiến

hành hoạt động QA, QC● Người chịu trách nhiệm QA phải là những

người quản lí giầu kinh nghiệm.

CMMI

Mô hình tăng trưởng năng lực tích hợp (CMMI)

● Mô hình khái niệm để giúp tổ chức: ● Đặc trưng hoá sự trưởng thành về qui trình của họ (nó

vậy) ● Thiết lập mục đích cho cải tiến qui trình (sẽ vậy) ● Đặt ưu tiên cho hành động ngay (chuyển tiếp) ● Quản lí và duy trì thay đổi trong tổ chức (ổn định hoá) ● Đưa vào thay đổi dần để tránh ngắt quãng qui trình hiện

thời. ● Mức độ trưởng thành là tập các “chuẩn văn hoá kĩ nghệ

phần mềm” được thiết lập vững chắc – dựa trên các thực hành tốt nhất trong công nghiệp.

● Từng mức trưởng thành bao gồm vài Khu vực qui trình (PA) để hướng dẫn tổ chức hướng tới “các chuẩn văn hoá kĩ nghệ phần mềm” này.

CMMI và mục đích doanh nghiệp

Kế hoạch cải tiến qui trình phần mềm

Mục đích kinh doanh của tổ chức

CMMI Trưởng thành năng lực hiện thời

Nhiệm vụ

Đào tạo

Kiểm điểm

Thực hiện

Thực hiệnNhiệm vụ cải tiến

CMMI chỉ là hướng dẫn

Mục đích doanh nghiệp là dẫn lái chính

Kế hoạch dựa trên kết quả đánh giá

Dữ

liệu được dùng để thẩm

tra kết quả cải tiến

Six Sigma

Six Sigma

● Là phương pháp luận quản lí● Khách hàng được hội tụ● Quyết định đưa ra theo dữ liệu● Thu được hiệu năng đột phá● Kết quả tuyến đáy được kiểm nghiệm

Khuôn khổ nặng cân và nhẹ cân

● Khuôn khổ truyền thống: chia pha và làm tài liệu nhiều được coi là nặng cân.

● Khuôn khổ Agile: tập trung vào lập trình, bớt yêu cầu tài liệu nhưng tăng tương tác với khách hàng, được coi là nhẹ cân.

● Ví dụ về phương pháp Agile● RAD● XP● Scrum

4. Khuôn khổ truyền thống và Agile

● Phương pháp luận theo kế hoạch khẳng định nhu cầu cần kỉ luật qui trình mạnh và thực hành nghiêm túc. ● Sản phẩm chất lượng tới từ qui trình chất

lượng. ● Giả định các yêu cầu được biết vào lúc bắt

đầu. ● “Đây là lịch biểu & ngân sách được cho theo

các yêu cầu này.” ● Thay đổi được quản lí chính thức. ● Làm lại việc là tồi tệ.

Phương pháp luận theo kế hoạch so với Agile

● Phương pháp luận Agile dùng cho các mô thức nhẹ, dễ thích nghi. ● Sản phẩm được dựng để bao giờ cũng có hệ thống

làm việc và có thể "đưa ra" vào bất kì lúc nào. ● Chỉnh sửa là tốt.

● Cương lĩnh Agile nói rằng chúng ta đi tới đánh giá: ● Cá nhân & tương tác qua qui trình & công cụ. ● Phần mềm làm việc qua tài liệu thấu đáo. ● Cộng tác của khách hàng qua thương lượng hợp

đồng. ● Đáp ứng với thay đổi qua việc tuân theo kế hoạch.

Phương pháp luận theo kế hoạch so với Agile (t.)

● Cách nào tốt nhất? Còn tuỳ theo thuộc tính và môi trường của dự án. ● Yêu cầu nổi lên hay đã biết? ● Văn hoá của dự án và tổ chức. ● Tri thức chuyên gia của tổ. ● Tính sẵn có của khách hàng. ● Bản chất của mối quan hệ với khách hàng. ● Độ phức tạp của khách hàng.

Đo truyền thống so với Agile

● Chúng ta có xây dựng sản phẩm đúng không? ● Truyền thống: Quản lí yêu cầu● Agile: Chấp nhận của khách hàng sau từng sprint

● Dự án mất bao lâu? ● Truyền thống: Kế hoạch lớn từ đầu & giá trị thu được● Agile: Gia tốc & Sơ đồ Burn Down

● Dự án tốn bao nhiêu tiền? ● Truyền thống: Kế hoạch lớn từ đầu & giá trị thu được ● Agile: Người phát triển được phân 100% cho dự án,

cho nên chi phí dự án là # số người phát triển * # số sprints

Đo truyền thống so với Agile

● Thay đổi sản phẩm ● Truyền thống: Cần được quản lí● Agile: Phần tự nhiên của cuộc họp về nhu cầu khách

hàng. Chỉ cần đo số câu chuyện● Làm lại và cải biên

● Truyền thống: Làm lại là dở, phải dẹp● Agile: Cải biên là phần tự nhiên của đáp ứng nhu cầu

khách hàng. Không cần đo● Chất lượng

● Truyền thống: chất lượng qui trình & sản phẩm ● Agile: Nhấn mạnh vào chất lượng sản phẩm

5. Khuôn khổ dự án Agile

Qui trình Agile điển hình

Yếu tố Agile thành công

● Người lãnh đạo là người quản lí dự án giỏi: “Là người quản lí dự án, bạn có sẵn lòng thay đổi để trở thành người lãnh đạo giỏi hơn không?”

● Tổ có kinh nghiệm và có kỉ luật: “Là thành viên tổ, bạn có đủ kinh nghiệm và kỉ luật để áp dụng phương pháp agile vào công việc của bạn không?”

● Liên hệ chặt chẽ với khách hàng

Yêu cầu của Agile

● Tổ phát triển phải toàn những cá nhân tài năng, người sẵn lòng và có khả năng thuộc vào loại những nhà tổng quát, có thể làm việc xuyên qua miền rộng các bước của vòng đời truyền thống.

● Agile yêu cầu các cá nhân đa kĩ năng, người có động cơ cá nhân, biết nghiên cứu, có tính phân tích, sáng tạo, và có các kĩ năng liên con người rất cao để hiểu vấn đề của khách hàng.

● Tổ Agile có kết hợp chặt chẽ với khách hàng

Nhược điểm của Agile

● Được thiết kế để làm việc trong môi trường rất nhỏ, không then chốt (trang Web, trạm web) nơi mọi sự phải xảy ra rất nhanh chóng và nếu mọi thứ không làm việc thì bắt đầu lại toàn bộ.

● Đòi hỏi sự hợp tác chặt chẽ của khách hàng ngay bên cạnh trong quá trình làm sản phẩm.

● Cần rất thận trọng về dùng Agile trong các dự án lớn nơi kỉ luật là quan trọng và tài liệu là then chốt. Nói riêng, nó không nên được dùng trong các dự án lớn và trong môi trường nghiệp vụ điển hình.

Đào tạo về dùng Agile

● Phần lớn đào tạo về quản lí dự án hội tụ vào dự án lớn tập trung theo cách tiếp cận "vòng đời thác đổ."

● Khi công ti dùng phương pháp agile, người quản lí dự án phải được đào tạo lại● giữ các nhiệm vụ dự án nhỏ (8 tới 20 giờ),. ● Mọi nhiệm vụ đều có định nghĩa về "làm xong." ● Phương pháp Agile hội tụ nhiều vào công việc tổ,

hội tụ nhiều vào chức năng hơn vào kiến trúc ● Cả tổ tham gia lập lịch và ước lượng, cần người

quản lí cấu hình và phiên bản● Vai trò người quản lí là lãnh đạo và thầy kèm chứ

không giám sát và kiểm soát.

6. Lập trình cực đoan XP

Lập trình cực đoan – qui trình

XP

● Dựa trên bốn giá trị: ● Trao đổi: Tiến hành trao đổi tích cực. ● Tính đơn giản: Thủ tục đơn giản nhất đáp ứng nhu

cầu khách hàng. ● Phản hồi: Thu và đánh giá phản hồi từ khách hàng, hệ

thống. ● Dũng cảm: Được chuẩn bị để ra quyết định cứng rắn.

● Tổ nhỏ. ● Khách hàng liên tục hiện diện tại chỗ. ● Lặp ngắn (không quá 3 tuần). ● Cách tiếp cận kiểm thử trước. ● Dựng và tích hợp liên tục.

XP

Điểm mạnh của XP

● Phương pháp Agile được thừa nhận rộng rãi nhất.

● Giữ kỉ lục thành công lớn với các ứng dụng nhỏ.

● Trao đổi và tham gia rất mạnh cùng khách hàng làm giảm nhẹ rủi ro của việc nổi lên yêu cầu.

● Thực hành XP lập trình cặp đôi tại http://www.agileventures.org/projects

Nhược điểm của XP

● Đổi qui mô là vấn đề ● Ít kinh nghiệm với tổ lớn hơn ● Có xu hướng cần phương pháp quản lí có kỉ

luật hơn để tổ lớn hơn làm việc ● Một số rào chắn sử dụng:

● Tổ không được xếp cùng chỗ ● Chu kì phản hồi dài (khách hàng không sẵn

có vào đúng lúc)

7. Scrum

Scrum (t.)

● Dựa trên quan niệm là phát triển phần mềm không phải là quá trình được xác định, mà thay vì thế là quá trình kinh nghiệm mà có thể hay không thể lặp lại được dựa trên hoàn cảnh.

● Tổ tự tổ chức. ● Có nhấn mạnh vào quản lí dự án xác định.

● Được quản lí bởi Người chủ Scrum ● Dựa trên tồn việc về nâng cao sản phẩm ● 'nước rút' 30-ngày ● Các hoạt động tiền và hậu nước rút ● Các cuộc họp Scrum hàng ngày ngắn (<30 phút) để

giám sát tình trạnh & trao đổi vấn đề

Sprint trong Scrum

Điểm mạnh của Scrum

● Một trong số ít các phương pháp mau lẹ đã cố đổi qui mô cho các dự án lớn hơn bằng việc có scrums của các thầy scrum. ● Không có thực hành kĩ nghệ đặc biệt nào được qui

định, nhưng nhiều tổ Scrum đang chấp nhận XP. ● Scrum cung cấp các phương tiện được kiểm

soát để đưa các phương pháp Agile vào môi thường theo kế hoạch truyền thống.

● Không thay đổi nào được phép có trong một đợt nước rút!

● Từng đợt nước rút đều tạo ra việc tăng sản phẩm chuyển đi được về tiềm năng.

Qui trình dự án

Scrum

Nhược điểm của Scrum

● Yêu cầu quản lí liền tay, nhưng không vi quản lí. ● Cấp quản lí phải sẵn lòng làm thay đổi để giúp cho tổ

Scrum thành công. ● Scrum yêu cầu giám sát thường xuyên cả về số

lượng và chất lượng. ● Yêu cầu cấp quản lí uỷ quyền ra quyết định cho

tổ Scrum. ● Người quản lí phải để tổ Scrum ra quyết định

riêng của họ, thậm chí cho phép họ thất bại nếu cần.

● Một số công nhân không thoải mái với tính trách nhiệm mà Scrum tạo ra khả năng.

Trao đổi và thảo luận