Với những kết quả đạt được và chưa đạt được ở trên, đề tài đã phần nào đưa ra những mục tiêu và nhiệm vụ cao hơn cần đạt được trong các nghiên cứu tiếp theo, thể hiện được sự phù hợp trong việc nghiên cứu ứng dụng qui trình phát triển phần mềm linh hoạt (Agile) tại các doanh nghiệp trong ngành công nghệ thông tin và có thể mở rộng ra các ngành dịch vụ khác, đây cũng là một xu hướng đúng đắn và phổ biến hiện nay.
Ngoài ra, sự tổ chức tốt, chặt chẽ trong mô hình CMMI và sự linh hoạt của Agile đang hướng các nhà phát triển phần mềm đến những nghiên cứu mở rộng, kết hợp giữa CMMI và Agile trong một qui trình phát triển phần mềm, qua đó tận dụng được thế mạnh của cả hai.
PHỤ LỤC Phụ lục A Danh sách các nhà phát triển phần mềm đưa ra tuyên ngôn
Agile
Kent Beck Mike Beedle Arie van Bennekum
Alistair Cockburn Ward Cunningham
Martin Fowler
James Grenning Jim Highsmith
Andrew Hunt Ron Jeffries
Jon Kern Brian Marick
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
Phụ lục B Bảng câu hỏi phỏng vấn về thực trạng của bộ phận
Mục đích: Tìm hiểu thực trạng của các dự án phần mềm qua chất lượng
sản phẩm/dịch vụ của bộ phận và các số liệu thống kê trong thời gian 2009-2011
Đối tượng: Các trưởng nhóm và trưởng dự án Số lượng tham gia phỏng vấn: 3 người
Nội dung câu hỏi và tổng hợp các câu trả lời:
Câu 1: Số lượng dự án web mà bộ phận phần mềm của anh (chị) thực hiện từ
tháng 1/2009 đến tháng 12/2011 là bao nhiêu?
Trả lời: 20 dự án.
Câu 2: Anh (chị) có thể cho biết trong thời gian trên, số lượng các dự án
thành công về các tiêu chí sau đây là bao nhiêu:
- Đúng thời gian cam kết (deadline) - Đáp ứng chuyên môn kỹ thuật cao - Khách hàng hài lòng
- Đáp ứng đúng yêu cầu khách hàng
Trà lời:
- Đúng thời gian cam kết (deadline): 14 dự án.
- Đáp ứng chuyên môn kỹ thuật cao: 10 dự án.
- Khách hàng hài lòng: 15 dự án.
- Đáp ứng đúng yêu cầu khách hàng: 20 dự án.
Câu 3: Số lượng các dự án trễ deadline là bao nhiêu?
Trả lời: 6 dự án.
Câu 4: Số lượng các dự án không đáp ứng được kỹ thuật chuyên môn
yêu cầu là bao nhiêu?
Trả lời: 7 dự án.
Câu 5: Số lượng các dự án hoàn thành đúng tiến độ nhưng không làm
hài lòng khách hàng (WO Team & PG Team) là bao nhiêu?
Trả lời: 4 dự án.
Câu 6: Đứng ở vị trí là người quản lý dự án (Project management – PM),
anh (chị) có hài lòng với kết quả làm việc của nhóm qua các dự án đã và đang thực hiện không?
Trả lời: Không hài lòng lắm vì vẫn còn kết quả không làm hài lòng
khách hàng và khó quản lý (control) các dự án trong tiến trình thực hiện.
Câu 7: Theo anh (chị), các kỹ năng nào cần được cải thiện ở nhân viên của
mình?
Trả lời: Tính tự chủ trong công việc, tinh thần làm việc hăng say, sáng tạo
trong các phương pháp giải quyết vấn đề và giao tiếp tốt.
Câu 8: Theo anh (chị), trong các dự án thành công của bộ phận, có thể hiện
được đủ các tiêu chí thành công về dự án như sau (tham khảo ở phần Cơ sở lý thuyết):
- Thành công về cá nhân - Thành công về kỹ thuật - Thành công ở mức công ty
Trả lời: Không, hầu như chỉ đáp ứng một phần về thành công ở mức công ty
và kỹ thuật.
Câu 9: Vấn đề ngân sách có là mối quan tâm của anh (chị) trong các dự án?
Trả lời: Không quan tâm lắm, vì vấn đề này ở cấp quản lý khác tính toán.
Tuy nhiên, bộ phận vẫn quan tâm đến kết quả dự án nhiều hơn.
Câu 10: Anh (chị) cho biết qui mô trung bình của các dự án mà bộ phận đã
thực hiện được đến thời điểm hiện tại dựa trên các tiêu chí sau:
- Số thành viên trung bình trong dự án - Thời gian trung bình để hoàn thành dự án
Trả lời:
- Số thành viên trung bình trong dự án: 6 thành viên.
- Thời gian trung bình để hoàn thành dự án: 2 tháng.
Câu 11: Nhu cầu thay đổi yêu cầu (Change request - CR) từ phía khách hàng
nội bộ (WO Team và PG Team) trong và sau quá trình hiện thực hóa (develop) có nhiều không? Anh (chị) có thể cho biết con số trung bình CR trên mỗi sản phẩm trong một tháng? (ước lượng)
Trả lời: Tương đối nhiều, 5 đến 10 thay đổi yêu cầu.
Câu 12: Anh (chị) có nghĩ đến nguyên nhân dẫn đến những kết quả không
mong muốn từ các sản phẩm của bộ phận phần lớn xuất phát từ qui trình làm việc không? Chẳng hạn: lập trình viên (Developer - DEV) phải đợi yêu cầu từ phía khách hàng (Requirement - REQ) thực hiện xong mới tiến hành công việc của mình.
Trả lời: Có.
Câu 13: Anh (chị) có nghĩ các yêu cầu thay đổi thường xuyên của dự án,
hoặc các vấn đề về cá nhân của từng thành viên trong nhóm có ảnh hưởng đến thời gian hoàn thành và chất lượng của dự án? Nếu có, anh (chị) có thể cho một ví dụ?
Trả lời: Có. Ví dụ: một thành viên bận việc gia đình hoặc có biểu hiện
tâm lý tiêu cực làm cho chức năng mà thành viên đó đảm nhận không đạt tiến độ và chất lượng không đạt.
Câu 14: Theo cá nhân anh (chị), để nhóm làm việc hiệu quả, cần cải thiện
những điều nào sau đây (sắp xếp theo thứ tự ưu tiên):
a. Thay đổi qui trình làm việc phù hợp hơn b. Nâng cao kỹ năng giải quyết vấn đề từ các thành viên nhóm
c. Kết hợp với khách hàng chặt chẽ hơn trong hoạt động tiếp nhận và phân tích yêu cầu
d. Cần thêm ngân sách e. Thay đổi mục tiêu sao cho phù hợp trong quá trình phát triển
Trả lời: a, c, e, b và d.
Phụ lục C Bảng câu hỏi phỏng vấn về bài học kinh nghiệm
Mục đích: Tổng kết các bài học kinh nghiệm sau mỗi dự án về sự thành công
hay thất bại trong các dự án phần mềm của bộ phận trong thời gian 2009-2011
Đối tượng: Các thành viên trong nhóm dự án Số lượng tham gia phỏng vấn: 15 người Nội dung câu hỏi và tổng hợp các câu trả lời:
Câu 1: Anh (chị) đã tham gia vào bao nhiêu dự án tại bộ phận trong thời
gian từ tháng 01/2009 đến tháng 12/2011?
Trả lời: 18 dự án.
Câu 2: Sau mỗi dự án, anh (chị) có tham gia vào các buổi họp kết thúc dự án
(the project closure meeting)?
Trả lời: Có. Nhưng chỉ 80% số dự án là có tổ chức họp rút kinh nghiệm và
đóng dự án.
Câu 3: Theo anh (chị), nguyên nhân chủ yếu nhất làm cho các dự án trễ
deadline là gì?
Trả lời: Qui trình phát triển không linh động, cứng nhắc trong từng
công đoạn. Bên cạnh, tương tác khách hàng chiếm nhiều thời gian. Ngoài ra, năng lực thành viên dự án thấp cũng làm chậm tiến độ do tốn thời gian tìm hiểu và thực hành công nghệ.
Câu 4: Là một developer, anh (chị) có kinh nghiệm gì trong việc tích hợp
không thành công giữa các phần (module) trong cùng dự án?
Trả lời: Cấu trúc các phần của dự án quá cố định, không linh hoạt; các
thành viên làm các phần ít gắn kết với nhau qua trao đổi và thực hiện; các cấp quản lý thường chỉ yêu cầu tích hợp sau khi các phần hoàn chỉnh, gây khó khăn và chỉnh sửa nhiều nếu các phần tích hợp không khớp với nhau.
Câu 5: Anh (chị) có quan tâm đến những chi phí của dự án không? Nếu có,
anh (chị) có thể cho biết đó là những chi phí gì không?
Trả lời: Không và cũng không được cho biết.
Câu 6: Theo anh (chị), kinh nghiệm chuyên môn về bản thân có góp phần
lớn vào thành công của dự án?
Trả lời: Có, vì giúp tránh những vấn đề hay gặp, code tối ưu hơn.
Câu 7: Phương pháp quản lý dự án hiện tại ở bộ phận, theo anh (chị) có còn
phù hợp không? Nếu không, anh (chị) có thể cho biết những điểm nào không còn phù hợp không?
Trả lời: Không còn phù hợp. Phương pháp hiện tại rất cứng nhắc, khó
thay đổi trong các yêu cầu (Change request - CR), trong khi đó, số lượng thay đổi yêu cầu trong các dự án ngày càng nhiều.
Câu 8: Anh (chị) đánh giá thế nào về tốc độ di chuyển của thông tin
(các thay đổi yêu cầu, thông tin yêu cầu từ khách hàng, thông tin của dự án…) trong dự án?
Trả lời: Tốc độ di chuyển chậm, vì phải qua nhiều cấp quản lý và
cũng vì vậy làm giảm một phần chất lượng của thông tin.
Câu 9: Theo anh (chị), việc tương tác qua các điểm tiếp nhận thông tin
(Access point) là các thành viên trưởng dự án, trưởng nhóm để nhận/phát thông tin có làm cho quá trình trao đổi chậm lại?
Trả lời: Có. Vì những người này còn làm những công việc khác, không phải
chỉ tiếp nhận/phát thông tin giữa nhóm lập trình và khách hàng hoặc các bên liên quan.
Câu 10: Các thay đổi yêu cầu (Change request - CR) có thường xuyên xảy ra
trong các dự án mà anh (chị) đã thực hiện không? Việc đáp ứng các CR này có tốn nhiều công sức và thời gian của anh (chị) không? Nếu có, anh (chị) có thể cho biết nguyên nhân chính của những khó khăn này?
Trả lời: CR trong các dự án gần đây xảy ra thường xuyên. Việc thực hiện
các CR này phần lớn tốn khá nhiều thời gian do phải thay đổi lại cấu trúc chương trình. Nguyên nhân chính chủ yếu là do qui trình ứng dụng tại nhóm, theo đó, các tài liệu phải hoàn chỉnh và thiết kế hoàn chỉnh là đầu vào cho giai đoạn lập trình nên thời gian lập trình bị thu hẹp, không còn đủ linh hoạt để
phản ứng với những thay đổi, nguyên nhân thứ hai có thể là do thiết kế cứng nhắc, phụ thuộc vào một trạng thái của yêu cầu, nên khi yêu cầu thay đổi, chương trình sửa lại rất khó khăn.
Câu 11: Phản hồi (feedback) từ phía khách hàng là thông tin rất quan trọng
để đánh giá sự hài lòng của khách hàng về kết quả của dự án. Theo anh (chị), các dự án của nhóm có làm hài lòng khách hàng chưa? Nếu chưa, anh (chị) có thể cho biết các nguyên nhân chính của vấn đề này không?
Trả lời: Một số có và một số chưa. Nguyên nhân chủ yếu xuất phát từ những
yêu cầu nhỏ giúp cho sản phẩm tốt hơn không được chấp nhận do thay đổi kiến trúc chương trình.
Câu 12: Theo anh (chị), người lãnh đạo và phong cách lãnh đạo có tác động
lớn đến sự thành/bại của dự án không? Anh (chị) kỳ vọng gì ở người lãnh đạo?
Trả lời: Có. Mong muốn sếp có những chương trình hỗ trợ, động viên
tinh thần làm việc, sắp xếp công việc hợp lý và hiểu rõ những khó khăn mà nhân viên đang gặp phải.
Câu 13: Bằng kinh nghiệm của mình qua các dự án, anh (chị) có thể cho biết
yếu tố nào quan trọng nhất giúp dự án thành công?
Trả lời: Thực ra có nhiều yếu tố cần để dự án thành công, như: có các
thông tin rõ ràng, có người hỗ trợ kỹ thuật tốt, tinh thần làm việc của nhóm tốt…tuy nhiên, tất cả các yếu tố này có thể được qui định trong một qui trình phát triển phần mềm tốt hơn hiện tại.
Câu 14: Theo anh (chị), những việc nào cần tránh trong quá trình thực hiện ở
từng giai đoạn sau đây:
- Phân tích yêu cầu - Thiết kế sản phẩm - Lập trình
- Deploy - Release - Bảo trì
- Thay đổi yêu cầu
Trả lời:
- Phân tích yêu cầu: Tránh vội vàng, tiến hành phân tích ngay khi chưa hiểu rõ yêu cầu khách hàng.
- Thiết kế sản phẩm: Tránh đồng bộ với sản phẩm của công ty khác.
- Lập trình: Tránh làm việc thiếu nguyên tắc. Cần đưa ra những qui định rõ ràng, best practices và các coding convention.
- Deploy: Tránh vội vàng, thiếu cẩn thận. Cần backup file trước khi đưa file mới lên server.
- Release: Tránh làm nhanh và thiếu check list.
- Bảo trì: Không nên tiến hành đọc code ngay, cần tìm hiểu qua các tài liệu để xác định phạm vi bị lỗi.
- Thay đổi yêu cầu: Tránh vội vàng, cần xác định và phân tích mức độ ảnh hưởng.
Phụ lục D Bảng câu hỏi phỏng vấn về sự phù hợp ứng dụng Agile
Mục đích: Xác định các thông tin và thống kê nội bộ từ phía bộ phận
phát triển phần mềm web tại công ty VNG phục vụ cho việc đánh giá phù hợp ứng dụng Agile.
Đối tượng: Các trưởng nhóm và trưởng dự án Số lượng tham gia phỏng vấn: 3 người
Nội dung câu hỏi và tổng hợp các câu trả lời:
Câu 1: Agile là phương pháp phát triển phần mềm tiên tiến hiện nay, theo
anh (chị), tên gọi lập trình linh hoạt có phản ánh đủ hết ý nghĩa của phương pháp này?
Trả lời: Có.
Câu 2: Agile chỉ phù hợp cho các dự án nhỏ và ngắn, theo anh (chị), có
phù hợp không khi áp dụng Agile vào các dự án hiện tại của nhóm? Nếu có, anh (chị) có thể cho biết những điểm nào phù hợp?
Trả lời: Phù hợp, vì hầu hết các dự án của bộ phận tới thời điểm này là nhỏ,
chỉ trong 1-2 tháng.
Câu 3: Văn hóa nhóm cũng là một phần quyết định trong Agile, theo
anh (chị), với văn hóa mệnh lệnh như hiện tại của nhóm có thể dễ dàng chuyển sang văn hóa bình đẳng, mọi người có trách nhiệm chính trên chính phần việc của mình không?
Trả lời: Hơi khó, vì cần có thời gian và thực hành qua các dự án.
Câu 4: Theo anh (chị), yếu tố thành công của dự án có nằm ở qui trình
quản lý dự án? Nếu có, anh (chị) vui lòng cho một ví dụ.
Trả lời: Có. Ví dụ: Thời gian chờ giữa các khâu làm cho resource vừa thừa
vừa thiếu. Thừa là lúc các khâu trước đang thực hiện, thành viên của các khâu sau chưa làm được. Thiếu vì khi các khâu trước thực hiện xong, thời gian thực hiện cho các khâu sau bị thu hẹp.
Câu 5: Agile yêu cầu tính kỷ luật cao, anh (chị) có thể cho biết các
thành viên trong nhóm đã có đủ hoặc gần đủ phẩm chất này để có thể thích nghi với phương pháp làm việc mới – Agile?
Trả lời: Chắc gần đủ, vì cần thêm thời gian để rèn luyện.
Câu 6: Lập trình linh hoạt – Agile đòi hỏi tốc độ và sự thay đổi linh hoạt
trong quá trình thực hiện sản phẩm, theo anh (chị), việc trao đổi thông tin trực tiếp với khách hàng có gặp nhiều khó khăn? Phương tiện sử dụng chủ yếu trong trao đổi là gì? (điện thoại, phần mềm chat, gặp trực tiếp, email)
Trả lời: Hơi khó khăn, do mọi người ít check mail hoặc bận quá quên trả lời
email. Phương tiện trao đổi chủ yếu là email, thỉnh thoảng là điện thoại bàn.
Câu 7: Sự thành công của dự án phụ thuộc nhiều vào mối liên kết hai chiều
giữa khách hàng và các thành viên dự án, anh (chị) đánh giá thế nào về mối liên kết này trong các dự án hiện tại của bộ phận? Nếu anh (chị) đánh giá không tốt, có thể cho biết nguyên nhân?
Trả lời: Quan hệ với khách hàng của bộ phận khá tốt, phần lớn làm lâu và
hiểu tính nhau. Tuy nhiên, cũng có một số bất đồng trong giao tiếp nên gây ra các khó chịu. Nguyên nhân chủ yếu do các tài liệu trao đổi không được xác nhận hoặc không được lưu trữ cẩn thận từ phía khách hàng, ngoài ra, việc trao đổi nội bộ của nhóm khách hàng cũng chưa tốt, nên thông tin cần hỏi và lặp lại thường xuyên giữa 2 nhóm.
Câu 8: Để ứng dụng Agile vào các dự án của nhóm, theo anh (chị), các
hạng mục đào tạo nào sau đây cần được chú trọng nhất (đánh giá mức độ quan trọng, tính khả thi qua việc sắp xếp thứ tự):
a. Tính tự chủ trong công việc b. Khả năng phân tích yêu cầu, lên kế hoạch và triển khai c. Khả năng quản lý thời gian
d. Kỹ năng trao đổi, tương tác trực tiếp với khách hàng e. Kinh nghiệm lập trình
Trả lời: a, d, b, c và e.
Câu 9: Daily meeting trong Agile (gọi là họp đứng chính xác hơn) là các
cuộc họp ngắn với mục đích báo cáo kết quả và chia sẻ khó khăn, cập nhật tiến độ dự án. Anh (chị) cho biết hiện tại nhóm có hình thức họp này không?
Theo anh (chị), điểm yếu của việc họp này là gì?
Trả lời: Có, nhưng thường một tuần 3 lần. Yếu điểm của việc họp này là
chiếm thời gian nhiều.
Câu 10: Anh (chị) có thường xuyên nhận được các thay đổi yêu cầu (Change
request - CR) không? Những khó khăn khi đáp ứng yêu cầu đối với hệ thống đã được xây dựng là gì? Theo anh (chị), chi phí thay đổi thường chiếm bao nhiêu phần trăm chi phí toàn dự án?
Trả lời: Có. Khó khăn khi đáp ứng thay đổi yêu cầu sau khi hệ thống đã
được xây dựng là phải thiết kế lại chương trình. Hiện tại không quan tâm nhiều đến chi phí, tuy nhiên, nếu xét trên nhân lực cần thêm để thực hiện thay đổi yêu cầu thì chi phí chiếm khoảng 20% toàn bộ dự án.