Trong giai đoạn 1, chủ sở hữu sản phẩm xác định tầm nhìn sản phẩm. Tầm nhìn sản phẩm là một định nghĩa sản phẩm là gì, sản phẩm này hỗ trợ thế nào cho chiến lƣợc của t chức, và những ngƣời sẽ sử dụng sản phẩm. Với những dự án dài, tầm nhìn sản phẩm sẽ đƣợc xem xét và điều chỉnh lại ít nhất mỗi năm một lần.
Trong giai đoạn 2, các chủ sở hữu sản phẩm tạo ra một lịch trình phát triển các các sản phẩm. Lộ trình này bao gồm định nghĩa yêu cầu sản phẩm ở mức cao, xác định độ ƣu tiên cho việc phát triển các sản phẩm dựa trên ƣớc tính thô, định nghĩa ra khung thời gian tƣơng đối để phát triển các sản phẩm đó. Với các dự án lớn và dài hạn, lịch trình phát triển sản phẩm sẽ đƣợc điều ít nhất hai lần một năm.
Trong giai đoạn 3, các chủ sở hữu sản phẩm tạo ra một kế hoạch cụ thể hơn để phát triển các sản phẩm. Những sản phẩm có độ ƣu tiên cao hơn sẽ đƣợc thực hiện trƣớc. Một dự án theo phƣơng pháp linh hoạt sẽ có nhiều phiên bản, các tính năng ƣu tiên cao nhất sẽ đƣợc thực hiện ở những phiên bản đầu tiên. Một phiên bản sản phẩm thƣờng sẽ đƣợc thực hiện trong khoảng từ 3-5 Sprint. Kế hoạch phát hành sản phẩm sẽ đƣợc tạo ra ở thời điểm bắt đầu thực hiện bản phát hành đó.
Giai đoạn 4, chủ sản phẩm, chuyên gia về quy trình linh hoạt thƣờng gọi là Scrum Master , và đội phát triển lên kế hoạch phát triển những chức năng gì cho các Sprint, mỗi Sprint sẽ đƣợc thực hiện trong 1 khung thời gian thƣờng là 2-4 tuần để phát triển một số chức năng. u i lập kế hoạch để chọn chức năng gì sẽ đƣợc phát triển sẽ đƣợc thực hiện vào đầu mỗi Sprint. Việc làm kế hoạch này sẽ lặp lại cho mỗi Sprint.
Trong giai đoạn 5, trong mỗi Sprint, nhóm phát triển có cuộc họp hàng ngày khoảng 15 phút và thảo luận về những gì từng thành viên đã hoàn thành, sẽ hoàn thành từng ngày và chia s các khó khăn gặp phải để đƣợc giải quyết.
Giai đoạn 6, thực hiện khi kết thúc 1 sprint, đội phát triển trình bày những chức năng đã hoàn thành cho chủ sản phẩm và những ngƣời khác có liên quan tùy vào nhu cầu của t chức
Giai đoạn 7, thực hiện khi kết thúc Sprint, nhóm phát triển t chức một cuộc họp giúp kinh nghiệm để chỉ ra những gì đội đã làm tốt, chƣa tốt và những cải tiến cần làm cho các Sprint tiếp theo.
Các hoạt động cụ thể của các giai đoạn phát triển phần mềm theo Agile Scrum có thể đƣợc chia thành 5 nhóm và 18 quy trình dƣới đây
Gi i đoạn Quy trình nhỏ
Khởi tạo 1. Tạo tầm nhìn sản phẩm
2. Xác định Scrum Master và Các bên liên quan 3. Lập đội dự án
36
5. Tạo ra 1 danh sách công việc và sắp xếp độ ƣu tiên 6. Lập kế hoạch bàn giao
Kế hoạch và ƣớc lƣợng
7. Tạo User Story
8. Ƣớc lƣợng, phê duyệt và cam kết các User Stories đƣợc thực hiện
9. Tạo công việc nhỏ để thực hiện User Story 10. Ƣớc lƣợng công việc nhỏ
11. Tạo danh sách việc cho 1 Sprint Sprint backlog
Thực hiện 12. Tạo ra các sản phẩm bàn giao
13. T chức họp hàng ngày
14. Xem xét và cập nhật chi tiết hơn danh sách công việc cho Sprint tiếp theo
Đánh giá và xem xét cách làm để cải tiến
15. Thực hiện họp giữa các thành viên đại diện của các nhóm (Scrum of Scrum)
16. Trình di n sản phẩm và thẩm định 17. Họp rút kinh nghiệm
Bàn giao 18. àn giao các sản phẩm đầu ra
19. Rút kinh nghiệm cả dự án
Bảng 2-12: Các quy trình trong phƣơng pháp quản lý linh hoạt Agile Scrum
2.2.3Cá v i trò trong quản ý dự án theo Agile Scrum
Nhóm dự án Scrum đƣợc tạo thành từ nhiều ngƣời và bao gồm năm vai trò sau đây: Đội ng phát triển: Các nhóm ngƣời thực hiện công việc tạo ra một sản phẩm.
Lập trình, kiểm thử, các nhà thiết kế, ngƣời viết tài liệu.., và bất cứ ai có một vai trò thực tế trong phát triển sản phẩm là một thành viên của nhóm phát triển. Ch sản phẩm: Là ngƣời chịu trách nhiệm về sự thành công của dự án, ngƣời
định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm. Chủ sản phẩm là ggƣời là cấu nối giữa khách hàng, các bên liên quan, và đội ngũ phát triển. Chủ sản phẩm là một chuyên gia về các sản phẩm và hiểu về các nhu cầu của khách hàng và độ ƣu tiên của các các yêu cầu. Chủ sản phẩm làm việc với nhóm phát triển hàng ngày để giúp đội làm rõ các yêu cầu. Chủ sản phẩm đôi khi đƣợc gọi là một đại diện của khách hàng.
Chuyên gia Scrum: Ngƣời chịu trách nhiệm hỗ trợ nhóm phát triển, giải quyết các vấn đề khó khăn, và giữ cho quy trình đƣợc thực hiện một cách nhất quán.
Các bên liên quan: bao gồm những ngƣời có liên quan đến dự án. Các bên liên quan không phải là ngƣời chịu trách nhiệm cho các sản phẩm đƣợc phát triển, nhƣng họ cung cấp đầu vào và bị ảnh hƣởng bởi kết quả của dự án
2.2.4Công ụ s dụng trong quản ý dự án theo Agile Scrum
Agile Srcum thƣờng sử dụng các công cụ sau để phát triển sản phẩm và quản lý tiến độ
Tuyên bố tầm nhìn về sản phẩm: một bản tóm tắt trình bày rõ mục tiêu của sản phẩm, và thể hiện đƣợc sản phẩm của bạn hỗ trợ các chiến lƣợc của công ty hoặc t chức nhƣ thế nào.
D nh sá h á hứ n ng ần phát triển (Product backlog : danh sách đầy đủ những chức năng thuộc phạm vi của dự án và đƣợc sắp xếp theo ƣu tiên. Chủ sản phẩm chịu trách nhiệm duy trì và sắp xếp độ ƣu tiên cho từng hạng mục dựa trên các giá trị của từng hạng mục.
Lộ trình phát triển sản phẩm Product Roadmap : Một lộ trình cung cấp cái nhìn t ng quan về các yêu cầu cần thực hiện và một khung thời gian dự kiến để thực hiện từng sản phẩm.
K hoạ h bàn gi o: Một bảng thời gian chi tiết hơn cho việc bàn giao các sản phẩm đang thực hiện.
D nh sá h á hứ n ng s đƣợ phát triển 1 Sprint: Mục tiêu của Sprint, Các chức năng yêu cầu bởi ngƣời dùng User Story , các nhiệm vụ đƣợc phân nhỏ để thực hiện các chức năng.
Sản phẩm đƣợ bàn gi o s u mỗi Sprint: Các chức năng đƣợc hoàn thành sau mỗi Sprint phát triển
Bảng theo dõi ông việ
Biều đồ th o dõi ti n độ 1 Sprint
38
2.3 CMMI và các mụ tiêu đánh giá cho nhóm quy trình Quản ý dự án
2.3.1Giới thiệu về CMMI
Mô hình trƣởng thành năng lực tích hợp Capability Muturity Intergration Model, viết tắt là CMMI) đƣợc phát triển bởi Viện Kỹ Nghệ SEI tại trƣờng Đại học Carnegie Mellon Mỹ, là chuẩn đánh giá về quy trình sản xuất phần mềm bao gồm quy trình quản lý dự án đang đƣợc áp dụng rộng rãi trên thế giới [12].
CMMI là sự kế thừa của Mô hình trƣởng thành năng lực Capacity Maturity Model, viết tắt là CMM . CMM là mô hình đánh giá sự trƣởng thành năng lực sản xuất phần mềm, mô hình quản lý chất lƣợng cho các t chức sản xuất phần mềm. CMM là một bộ các hƣớng dẫn và kinh nghiệm thực ti n đƣợc chọn lọc của các chuyên gia và t chức hàng đầu trong lĩnh vực phát triển, cải tiến hoặc đánh giá quy trình sản xuất phần mềm. CMM không đƣa ra các quy trình cụ thể, mà chỉ đƣa ra các hƣớng dẫn để các công ty/ t chức phát triển phần mềm có thể tự xây dựng và cải tiến hiệu quả các quy trình của mình.
CMMI bao gồm ba phần chính:
CMMI-Dev cho sự phát triển CMMI for evelopment : cải thiện sự phát triển , giải pháp sản phẩm và dịch vụ phức tạp
CMMI-QCA cho sự tiếp nhận , thu mua CMMI for Acquisition : cải thiện việc thu mua các sản phẩm, dịch vụ và/hoặc hàng hóa
CMMI-SCV cho dịch vụ CMMI for Service : cải thiện phân phối dịch vụ và sự tạo ra hệ thống dịch vụ
Đánh giá CMMI cho một tổ hứ
Phƣơng pháp đánh giá CMMI tiêu chuẩn cho việc cải tiến quy trình The Standard CMMI Appraisal Method for Process Improvement – SCAMPI là phƣơng pháp mà Đánh giá trƣởng đƣợc Viện CMMI ủy quyền sẽ thực hiện giúp doanh nghiệp đạt đƣợc “CMMI ở một mức độ mong muốn”. Có ba loại đánh giá khác nhau, đƣợc phân theo “cấp”, đó là SCAMPI A, SCAMPI và SCAMPI C. SCAMPI A là phƣơng pháp đánh giá duy nhất giúp chấm điểm để doanh nghiệp đạt đƣợc chứng chỉ mức độ trƣởng thành hoặc mức độ năng lực. SCAMPI C thƣờng đƣợc xem nhƣ là hạng mục “Phân tích thực trạng”, hoặc là một công cụ để thu thập thông tin, còn SCAMPI thì đƣợc thực hiện nhƣ hạng mục Xem xét mức độ chấp hành của doanh nghiệp hoặc đánh giá thử. Kết quả đánh giá SCAMPI A sẽ đƣợc đăng lên trang web Viện CMMI “PARS” và bất cứ ai cũng có thể truy cập và kiểm tra [6].
ISO 9001 là một tiêu chuẩn quốc tế về quản lý, các điều khoản gọi là “yêu cầu” quy định những điểm cần phải làm , không chỉ ra việc đó nên làm nhƣ thế nào.
CMMI là một mô hình, cung cấp các hƣớng dẫn và kinh nghiệm thực tế dùng để phát triển, cải tiến và đánh giá năng lực của quy trình. CMMI không phải là một tiêu chuẩn, tùy vào từng t chức, cách thực hiện khác nhau.
Về nguyên tắc, ISO bao gồm hầu hết các quy trình chủ chốt của CMMI, tuy nhiên ISO đƣợc dùng cho hầu hết mọi ngành nghề, do vậy không cụ thể, gần gũi với công việc đặc thù có liên quan đến phần mềm nhƣ CMM/CMMI. ISO không cung cấp các ví dụ và kinh nghiêm cụ thể nhƣ CMM/CMMI.
2.3.2Cấu trú CMMI CMMI đƣợ ấu trú nhƣ s u:
Cá mứ t ng trƣởng: Mỗi mức tăng trƣởng thể hiện mức độ thực hiện quy trình của một t chức. Mức tăng trƣởng bao gồm các quy cách chung và quy cách riêng tƣơng ứng với nhóm các lĩnh vực quy trình cải thiện hoạt động của t chức. Việc cải thiện quy trình của t chức đƣợc thực hiện bằng việc cải tiến nhóm các qui trình tƣơng ứng với các cấp độ của CMMI.
Cá ĩnh vự quy trình: Một lĩnh vực quy trình bao gồm nhiều quy cách làm việc hoặc nhiều hoạt động cần đƣợc thực hiện cùng nhau để đạt đƣợc mục đích của lĩnh vực quy trình đó
Mụ tiêu: gồm mục tiêu chung và mục tiêu riêng, để đáp ứng mục tiêu của quy trình và mục tiêu chung đáp ứng nhu cầu của t chức
Các đặ điểm chung : các điểm đặc trƣng chỉ đơn giản là nhóm các quy cách làm việc chung trong một lĩnh vực quy trình lại với nhau, tùy theo chức năng của quy cách làm việc
Quy cách làm việ ( á thự hành) : quy cách làm việc bao gồm các ví dụ, các mô tả, các hƣớng dẫn và đặt biệt là các hoạt động cần thực hiện để đạt đƣợc mục tiêu của lĩnh vực quy trình. Quy cách làm việc cho mục tiêu riêng đáp ứng mục tiêu riêng, và quy cách làm việc mục tiêu chung để đáp ứng mục tiêu chung
40
Hình 2-4 : Cấu trúc một lĩnh vực quy trình của CMMI [13]
Mối iên hệ giữ mụ tiêu và á thự hành
Mỗi quy trình đều có vài mục tiêu cần phải đạt đƣợc. Mục tiêu đƣợc chia thành mục tiêu riêng và mục tiêu chung. Mục tiêu chung đáp ứng mục tiêu của t chức gắn với các thực hành chung đi kèm, mục tiêu riêng đáp ứng mục tiêu thực hiên quy trình có các quy cách riêng gắn liền với nó.
2.3.3Cá mụ tiêu và thự hành ho á quy trình Quản ý dự án trong CMMI
CMMI bao gồm 5 mức trƣởng thành và 22 quy trình quan trọng viết tắt là KPA trong đó bao gồm 7 quy trình về Quản lý dự án
Các quy trình sắp xếp theo mô hình phân tầng của phiên bản hiện tại CMMI-Dev 1.3 phát hành thán 11 năm 2010 nhƣ sau
Mứ Mụ tiêu Quy trình chính Mứ 5
Tối Ƣu
Cải tiến quy trình liên tục
Phân tích nguyên nhân và ra quyết định Triển khai và đ i mới t chức
Mứ 4
Quản ý đƣợ
Quản lý định lƣợng
Quản lý dự án định lƣợng Hiệu suất quy trình t chức
Level 3 Xá p
Chuẩn hóa quy trình
Phân tích quyết định và giải pháp Quản lý dự án tích hợp
Định nghĩa quy trình t chức Tập trung quy trình t chức Đào tạo trong t chức Tích hợp sản phẩm
Phát triển yêu cầu Quản lý rủi ro Giải pháp kỹ thuật Thẩm định Phê duyệt Mứ 2 Mứ ặp Quản lý dự án cơ bản Quản lý cấu hình Phân tích và đo lƣờng
Giám sát và kiểm soát dự án Lập kế hoạch dự án
ảo đảm chất lƣợng quy trình và sản phẩm
Quản lý yêu cầu
Quản lý hợp đồng nhà thầu phụ
Mứ 1 Khởi đầu
Không xác định
Bảng 2-13: 5 mức trƣởng thành của CMMI-Dev 1.3 [13]
Các lĩnh vực quy trình đƣợc sắp xếp trong mô hình liên tục 4 nhóm quy trình
Hình 2-5: Phân nhóm các quy trình trong CMMI
Quản lý quy trình của t chức • Định nghĩa quy trình t chức • Tập trung quy trình t chức • Đào tạo trong
t chức
• Hiệu suất quy trình của t chức • Triển khai và đ i mới t chức Quản lý dự án • Quản lý yêu cầu • Lập kế hoạch dự án • Giám sát và kiểm soát dự án • Quản lý hợp đồng nhà thầu phụ • Quản lý dự án tích hợp • Quản lý rủi ro • Quản lý dự án định lƣợng Công việc phát triển • Phát triển yêu cầu • Giải pháp kỹ thuật • Tích hợp sản phẩm • Thẩm định • Phê duyệt Hỗ trợ • Phân tích và đo lƣờng • Đảm bảo chất lƣợng quy trình và sản phẩm • Quản lý cấu hình • Phân tích quyết định và giải pháp • Phân tích nguyên nhân và ra quyết định
42
Các mụ tiêu ho á quy trình Quản ý dự án Mụ tiêu quy trình Quản ý yêu ầu (REQM)
SG 1 Quản lý yêu cầu SP 1.1
SP 1.2 SP 1.3 SP 1.4 SP 1.5
Hiểu các yêu cầu dự án
Đạt đƣợc sự cam kết với các yêu cầu Quản lý các thay đ i của yêu cầu
Duy trì các truy xuất nguồn gốc hai chiều giữa các yêu cầu và công việc các sản phẩm.
Đảm bảo công việc dự án phù hợp với yêu cầu
Bảng 2-14: Mục tiêu của quy trình Quản lý yêu cầu
Cá mụ tiêu quy trình L p k hoạ h dự án (PP)
SG 1 Thiết lập các bản ƣớc lƣợng SP 1.1 SP 1.2 SP 1.3 SP 1.4 Ƣớc lƣợng phạm vi của dự án
Thiết lập các bản ƣớc lƣợng cho các nhiệm vụ Xác định vòng đời của dự án
Uớc tính nguồn lực ngày công và chi phí SG 2 Phát triển một bản kế hoạch dự án SP 2.1 SP 2.2 SP 2.3 SP 2.4 SP 2.5 SP 2.6 SP 2.7
Thiết lập ngân sách và thời gian của dự án Xác định các rủi ro của dự án
Lập kế hoạch quản lý dữ liệu Lập kế hoạch nguồn lực của dự án
Lập kế hoạch về kỹ năng và kiến thức cần thiết Lập kế hoạch sự tham gia của những ngƣời liên quan Lập kế hoạch t ng thể của dự án
SG 3 Thống nhất kế hoạch thực hiện SP 3.1
SP 3.2 SP 3.3
Xem xét các kế hoạch ảnh hƣởng tới dự án Cân đối nguồn lực và công việc
Thống nhất kế hoạch triển khai