ScrumDay Vietnam 2013: Phương pháp luận phần mềm - Truyền thống và Agile - Ngô Trung Việt
7 likes2,853 views
Tài liệu trình bày các phương pháp luận phát triển phần mềm truyền thống và agile, bao gồm mô hình vòng đời hệ thống như thác đổ, gia tăng và xoáy ốc, cùng với các ưu nhược điểm của từng phương pháp. Nó nhấn mạnh tầm quan trọng của quy trình phần mềm trong việc đảm bảo chất lượng và sự thành công của dự án, cũng như việc cải tiến quy trình thông qua các mô hình như CMMI và Six Sigma. Cuối cùng, tài liệu so sánh sự khác biệt giữa hai phương pháp phát triển phần mềm để xác định phương pháp nào phù hợp nhất với từng dự án cụ thể.
ScrumDay Vietnam 2013: Phương pháp luận phần mềm - Truyền thống và Agile - Ngô Trung Việt
- 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 [email protected]
- 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. 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. 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. 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. Đ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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Đ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. 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. 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. 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. 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. Hai kiểu phương pháp luận Truyền thống Agile
- 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. Đ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. Đ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. 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. Scrum
- 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. Đ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. 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. 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. 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. 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. 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. 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. TQM
- 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. CMMI
- 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. 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. Six Sigma
- 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. 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. 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. 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. 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. Đ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. Đ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. 5. Khuôn khổ dự án Agile
- 49. Qui trình Agile điển hình
- 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. 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. 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. Đà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. 6. Lập trình cực đoan XP
- 55. Lập trình cực đoan – qui trình
- 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. XP
- 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. 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. 7. Scrum
- 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 đề
- 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.
- 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. Trao đổi và thảo luận