Phương pháp luận
dự án phần mềm:
Truyền thống và Agile
Ngô Trung Việt
Giá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ốn...
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 p...
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ả...
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ể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 b...
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ạc...
Mô hình thác đổ
Rấ t thường là khá ch hà ng không biết đı́ch xá c yêu cầ u
cho dự á n, và chắc chắn sẽ thay đổi...
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....
Mô hình bản mẫu
Lắng nghe & thu
lấy yêu cầu từ
khách hàng
Dự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...
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...
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...
Mô hình xoáy ốc
Xá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á...
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...
Đ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ư...
V- mô hình kĩ nghệ hệ thống cổ điển
Xây
dựng
Kiểm thử
đơn vị
Yêu cầu
hệ thống
Kiểm thử
hệ thống
Yêu cầu
phần mềm
Kiểm thử
...
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ĩ ...
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ươn...
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
...
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ổ
p...
Đ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à...
Đ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...
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...
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 ...
Đ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...
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...
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 ...
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à
...
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ỡ...
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 p...
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...
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ả...
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 t...
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 ...
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...
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ổ A...
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 ...
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 đ...
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...
Đ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ậ...
Đ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ề n...
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 để...
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à...
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...
Đà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...
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...
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ỏ.
● Tra...
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 ...
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 ...
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ủ...
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 ...
Trao đổi và thảo luận
Upcoming SlideShare
Loading in...5
×

ScrumDay Vietnam 2013: Phương pháp luận phần mềm - Truyền thống và Agile - Ngô Trung Việt

1,089

Published on

Giới thiệu

ScrumDay là một chuỗi hội thảo phi lợi nhuận chuyên sâu về phương pháp phát triển phần mềm Agile\Scrum, sự kiện này được diễn ra tại nhiều thành phố trên thế giới. Năm 2012, lần đầu tiên Cộng đồng Scrum tại Hà Nội đã tổ chức ScrumDay và đạt được nhiều thành công tốt đẹp. Đến 2013, ScrumDay với chủ đề “Transition” mong muốn tiếp tục là Ngày hội của cộng đồng Scrum Hà Nội với các mục đích:

Giới thiệu và thúc đẩy sự phát triển Agile\Scrum
Phát triển một cộng đồng Agile\Scrum lớn mạnh ở Việt Nam từ đó góp phần đổi mới và phát triển ngành phát triển phần mềm Việt Nam
Chia sẻ kinh nghiệm triển khai từ những người thực hành và chuyên gia
Hỗ trợ các Công ty\Tổ chức trong việc áp dụng và thực hành phương pháp Agile\Scrum

Khác với ScrumDay 2012 nội dung đề cập tới hầu hết các khía cạnh căn bản trong Agile\Scrum, đối tượng trải rộng từ sinh viên\developer tới những nhà quản lý, hội nghị năm nay với chủ đề là “Transition” và hướng tới các đối tượng như sau:

Giám đốc\Quản lý doanh nghiệp trong lĩnh vực phần mềm: những người mong muốn thấu hiểu khách hàng hơn, đáp ứng tốt hơn nguyện vọng của họ để phát triển kinh doanh.
Các CTO: những người đang đau đầu với sự thay đổi quá nhanh của Công nghệ, muốn có một công cụ mạnh hơn cho chiến lược công nghệ tại công ty
Team Leader: Những người mong muốn xây dựng một team mạnh Các Tech Startup founders: Những người luôn muốn tạo ra sản phẩm đột phá "disrupt the market"
Salesperson\Marketer: Những người muốn áp dụng Agile\Scrum vào công việc của mình
Những Nhà thực hành và nghiên cứu Agile\Scrum: những người đam mê và thực hành triết lý Agile, những người có đam mê chia sẻ hiểu biết để cùng nhau xây dựng một cộng đồng Agile mạnh tại Việt Nam, góp phần thúc đẩy sự phát triển của ngành.

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,089
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
108
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

ScrumDay Vietnam 2013: Phương pháp luận phần mềm - Truyền thống và Agile - Ngô Trung Việt

  1. 1. Phương pháp luận dự án phần mềm: Truyền thống và Agile Ngô Trung Việt Giám đốc tri thức QNET ntviet@gmail.com
  2. 2. 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
  3. 3. 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.
  4. 4. 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
  5. 5. 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
  6. 6. Đ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
  7. 7. 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.
  8. 8. Mô hình thác đổ Rấ t thường là khá ch hà ng không biết đı́ch xá c yêu cầ u cho dự á n, và chắc chắn sẽ thay đổi khi dự á n tiến triển. Người phá t triển có thể phải quay lại pha trước để là m sá ng tỏ. Rấ t tốn thời gian là m lại việc. Yêu cầu Thiết kế Viết mã Kiểm thử Tích hợp
  9. 9. 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ị
  10. 10. Mô hình bản mẫu Lắng nghe & thu lấy yêu cầu từ khách hàng Dựng/Sửa bản thử Khách hàng chạy bản thử
  11. 11. 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
  12. 12. 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.
  13. 13. 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.
  14. 14. Mô hình xoáy ốc Xá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ử
  15. 15. 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.
  16. 16. Đ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
  17. 17. V- mô hình kĩ nghệ hệ thống cổ điển Xây dựng Kiểm thử đơn vị Yêu cầu hệ 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ế
  18. 18. 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))
  19. 19. 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ệ
  20. 20. 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ị
  21. 21. Hai kiểu phương pháp luận Truyền thống Agile
  22. 22. 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
  23. 23. Đ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”
  24. 24. Đ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
  25. 25. 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
  26. 26. Scrum
  27. 27. 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 đề
  28. 28. Đ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.
  29. 29. 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
  30. 30. 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.
  31. 31. 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.
  32. 32. 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.
  33. 33. 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
  34. 34. 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
  35. 35. TQM
  36. 36. 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.
  37. 37. CMMI
  38. 38. 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.
  39. 39. 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đượcdùngđểthẩmtrakếtquảcảitiến
  40. 40. Six Sigma
  41. 41. 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
  42. 42. 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
  43. 43. 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ệ.
  44. 44. 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.
  45. 45. 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.
  46. 46. Đ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
  47. 47. Đ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
  48. 48. 5. Khuôn khổ dự án Agile
  49. 49. Qui trình Agile điển hình
  50. 50. 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
  51. 51. 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
  52. 52. 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.
  53. 53. Đà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.
  54. 54. 6. Lập trình cực đoan XP
  55. 55. Lập trình cực đoan – qui trình
  56. 56. 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.
  57. 57. XP
  58. 58. Đ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
  59. 59. 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)
  60. 60. 7. Scrum
  61. 61. 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 đề
  62. 62. Sprint trong Scrum
  63. 63. Đ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.
  64. 64. Qui trình dự án Scrum
  65. 65. 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.
  66. 66. Trao đổi và thảo luận
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×