Machine Translated by Google

Có sẵn trực tuyến tại www.sciencedirect.com

Khoa họcTrực tiếp

Thủ tục - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304

Đại hội thế giới IPMA lần thứ 27

Quản lý dự án linh hoạt trong các dự án phát triển sản phẩm

Aljaž Stare, CSPMa *

aĐại học Ljubljana, Khoa Kinh tế, Kardeljeva ploš7ad 17, Ljubljana 1000, Slovenia

trừu tượng

Bất chấp sự phổ biến ngày càng tăng của quản lý dự án linh hoạt trong lĩnh vực dự án CNTT, nó vẫn chưa được áp dụng trong các loại dự án

khác (kỹ thuật, nghiên cứu & phát triển, tổ chức sự kiện), có lẽ vì nhiều lý do: những thay đổi thường xuyên quá tốn kém. , các sản phẩm chuyển

giao một phần có thể không được tiếp thị hoặc sử dụng, các cá nhân tham gia vào một số dự án cùng lúc, v.v. Chúng ta có thể lập luận rằng phương

pháp này sẽ không bao giờ được sử dụng rộng rãi. Tuy nhiên, chúng tôi không thể nói rằng một số phương pháp linh hoạt nhất định không thể áp

dụng được cho các dự án vẫn được thực hiện theo cách truyền thống. Vì vậy, chúng tôi đã phân tích các dự án phát triển sản phẩm ở năm công ty

sản xuất. Trước tiên, chúng tôi muốn xác định xem họ đã sử dụng bất kỳ kỹ thuật linh hoạt nào chưa và hơn nữa - bằng cách sử dụng phân tích hồi

quy - chúng tôi đã xác định sự đóng góp thực tế của từng kỹ thuật linh hoạt vào sự thành công của dự án. Mục đích của bài viết này là chứng minh

khả năng ứng dụng của quản lý dự án linh hoạt trong bối cảnh phát triển sản phẩm. Chúng tôi cũng mong muốn khuyến khích các cuộc thảo luận và

nghiên cứu chuyên nghiệp về quản lý linh hoạt đối với các loại dự án khác và khuyến khích giới thiệu các kỹ thuật linh hoạt ở bất cứ nơi nào

được chứng minh là góp phần vào sự thành công của dự án.

© 2014 Các tác giả. Được xuất bản bởi Elsevier Ltd. ©
2014 The Authors. Được xuất bản bởi Elsevier Ltd. Truy cập mở theo giấy phép CC BY-NC-ND.
Lựa chọn và đánh giá ngang hàng thuộc trách nhiệm của IPMA.
Lựa chọn và đánh giá ngang hàng thuộc trách nhiệm của IPMA.

Từ khóa: dự án, quản lý, linh hoạt, phát triển sản phẩm

* Đồng tác giả. ĐT.: +386-1-5892-774; fax: +386-1-5892-698.

Địa chỉ email :aljaz.stare@ef.uni-lj.si

1877-0428 © 2014 Các tác giả. Được xuất bản bởi Elsevier Ltd. Truy cập mở theo giấy phép CC BY-NC-ND.
Lựa chọn và đánh giá ngang hàng thuộc trách nhiệm của IPMA.
doi: 10.1016/j.sbspro.2014.03.034
Machine Translated by Google

296 Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304

1. Giới thiệu

Các phương pháp tiếp cận linh hoạt để quản lý các dự án phát triển phần mềm (sau đây gọi là các dự án CNTT) đã phát triển đáng kể kể

từ khi tuyên ngôn Agile được xuất bản năm 2001. Theo nhiều người, đặc biệt là các tác giả của tuyên ngôn, do phản ứng được công nhận đối

với những thay đổi, tính linh hoạt sẽ càng trở nên quan trọng hơn, trong khi Bennekum và Van Hunt (trong Bowles Jackson, 2012) thậm chí

còn cho rằng tư duy linh hoạt là yếu tố quyết định thành công trong thế kỷ 21!

Trong một cuộc phỏng vấn với Bowles Jackson, các tác giả của bản tuyên ngôn cũng tuyên bố rằng cách tiếp cận linh hoạt rất hữu ích cho

tất cả các loại dự án và hơn thế nữa. Khi được hỏi trực tiếp liệu tính linh hoạt có thể được áp dụng bên ngoài các dự án CNTT hay không,

Hunt lập luận thêm rằng cách tiếp cận linh hoạt ít liên quan đến phần mềm; thay vào đó, tất cả chỉ là việc ghi nhận và áp dụng phản hồi.

Van Bennekum cho biết thêm rằng Agile có tính toàn diện và có thể áp dụng ở mọi nơi trong kinh doanh hoặc cuộc sống – ông sử dụng nó như

một khái niệm dù ở bất cứ đâu và cho bất cứ việc gì ông làm. Đồng tác giả thứ ba, Highsmith, tin rằng cần phải sử dụng các nguyên tắc và

phương pháp thực hành linh hoạt trong mọi dự án gặp phải tình trạng không chắc chắn.

Tuy nhiên, thực tế vẫn chưa khẳng định được tầm nhìn xa và nỗ lực của họ. Chúng tôi đã kiểm tra các nghiên cứu đã xem xét cách tiếp

cận linh hoạt trong thập kỷ qua và nhận thấy rằng cho đến năm 2009, hầu hết chúng chỉ tập trung vào các dự án CNTT; trong năm đó, một bài

báo đã khám phá cách tiếp cận linh hoạt trong các dự án phát triển sản phẩm (Berger & Beynon-Davies, 2009). Một năm sau, Doherty nghiên

cứu các dự án linh hoạt trong lĩnh vực học tập điện tử (Doherty, 2010), trong khi vào năm 2011 Gonzalez đã xem xét cách tiếp cận linh hoạt

liên quan đến việc thiết lập và quản lý sở hữu trí tuệ. Tóm lại, trong số 33 bài viết chỉ có 3 bài không thảo luận về các dự án CNTT.

Mặt khác, các nhà quản lý dự án có kinh nghiệm có thể khẳng định rằng nhiều phương pháp thực hành linh hoạt phổ biến đã tồn tại trong

các dự án truyền thống ngay cả trước khi có tuyên ngôn Agile. Khi đọc tài liệu của những người ủng hộ cách tiếp cận linh hoạt, tuyên ngôn

linh hoạt và các nguyên tắc phát triển phần mềm, chúng ta có thể hơi ngạc nhiên trước những lời chỉ trích về quản lý dự án truyền thống –

như thể các tác giả chưa bao giờ làm việc trong các nhóm thực sự, như thể các nhà quản lý chưa bao giờ lập kế hoạch dự án cùng với các

thành viên trong nhóm (và ngược lại - như thể các thành viên trong nhóm chưa bao giờ cộng tác với người quản lý trong việc lập kế hoạch

dự án), như thể người quản lý không phải là trưởng nhóm mà là những quản trị viên xa lạ và như thể các nhóm chưa bao giờ cộng tác

thường xuyên với khách hàng hoặc người dùng cuối (Stare , 2013).

Mặc dù nghi ngờ rằng cách tiếp cận linh hoạt sẽ được sử dụng rộng rãi trong tương lai, có lẽ là do các sản phẩm chuyển giao một phần

có thể không được tiếp thị hoặc sử dụng, những thay đổi muộn thường xuyên là quá tốn kém, môi trường nhiều dự án nơi các cá nhân tham

gia vào một số dự án cùng một lúc, v.v. ., chúng tôi tin rằng một số phương pháp linh hoạt nhất định có thể được sử dụng cho các dự án

vẫn được thực hiện theo cách truyền thống. Đó là lý do chúng tôi thực hiện nghiên cứu thí điểm về các dự án phát triển sản phẩm tại 5

doanh nghiệp Slovenia. Mục tiêu của chúng tôi là thực hiện một nghiên cứu chi tiết trên mẫu lớn hơn trong trường hợp có những phát hiện

đáng khích lệ trong nghiên cứu thí điểm.

Trong bài báo này chúng tôi trình bày kết quả nghiên cứu. Mục đích của chúng tôi là khuyến khích các cuộc thảo luận và nghiên cứu

chuyên nghiệp nhằm xác nhận (hoặc bác bỏ) các giả định được đưa ra và tất nhiên là triển khai phương pháp tiếp cận linh hoạt ở bất cứ

nơi nào nó thực sự đóng góp vào sự thành công của dự án.

2. Cách thức triển khai dự án linh hoạt

2.1. Sự nhanh nhẹn và cách tiếp cận nhanh nhẹn

Mặc dù đặt tiêu đề cho bài viết của chúng tôi là “Quản lý dự án Agile…” nhưng chúng tôi cho rằng việc sử dụng thuật ngữ đó không hoàn

toàn phù hợp. Khoa học định nghĩa quản lý là một quá trình lập kế hoạch, tổ chức, lãnh đạo và kiểm soát; tuy nhiên, khi nghiên cứu các đặc

điểm của phương pháp tiếp cận linh hoạt, sẽ khó tìm ra loại khác biệt nào có thể biện minh cho việc gọi quản lý là "linh hoạt". Chúng tôi

cũng đã kiểm tra các thuật ngữ được sử dụng trong tài liệu. Trong 35 bài viết được xuất bản trong 10 năm qua, số lượng tác giả nhiều

nhất (11) viết về các phương pháp Agile (về lập trình, quản lý dự án), trong khi chỉ có 5 bài sử dụng thuật ngữ quản lý dự án Agile. Mặt

khác, các tác giả thường thảo luận về phát triển phần mềm linh hoạt, cách tiếp cận linh hoạt, các dự án và nhóm linh hoạt và hiếm khi

thảo luận về các quy trình, yếu tố, tiêu chuẩn và công ty linh hoạt. Chúng tôi cũng tìm thấy năm cuốn sách thảo luận về các phương pháp

linh hoạt, mặc dù chỉ có Wysocki (2009) viết về quản lý dự án linh hoạt, trong khi những cuốn sách khác không đề cập đến thuật ngữ này:

• Rothman (2007) chủ yếu sử dụng vòng đời dự án linh hoạt và cũng đề cập đến dự án linh hoạt, cách tiếp cận,

phát triển, thực hành và kỹ thuật linh hoạt;

Machine Translated by Google

Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304 297

• Forsberg và cộng sự. (2005) chủ yếu nói về các phương pháp, quy trình và thực tiễn linh hoạt và phát triển linh hoạt;

• Brandon (2006) đề cập đến các phương pháp, quy trình và lập trình linh hoạt; trong khi đó • Thomsett

(2002), người có cuốn sách đề cập đến quản lý dự án cấp tiến/cực đoan, đề cập đến phát triển linh hoạt

và xử lý.

Sau khi xem xét nhiều nguồn khác nhau, chúng tôi thấy rằng: •

thuật ngữ và khái niệm bắt nguồn từ các phương pháp linh hoạt để phát triển hệ thống thông tin (đầu tiên đã có

xuất hiện vào những năm 1980) và chủ yếu được sử dụng cho các dự án CNTT;

• phương pháp nhấn mạnh việc thực hiện đồng thời các nhiệm vụ kế tiếp theo truyền thống của một dự án (một 'đài phun nước' thay vì

'thác nước') và sự phối hợp liên tục của những người tham gia. Theo nghĩa này, các phương pháp linh hoạt có thể so sánh với

kỹ thuật đồng thời, cũng xuất hiện vào những năm 1980;

• bản chất của phương pháp này liên quan đến việc cập nhật liên tục quá trình thực hiện và lập kế hoạch chi tiết cho các chu kỳ nhỏ hơn

(các lần lặp lại) để thực hiện dự án theo kết quả hiện tại, bài học kinh nghiệm, ý tưởng mới, v.v.; Và

• việc tập trung vào người dùng là rất quan trọng và do đó, nhóm dự án thường có đại diện của người dùng cuối, người này thường

xuyên kiểm tra từng phần kết quả của dự án (để đảm bảo sản phẩm cuối cùng phù hợp hơn với mong muốn và yêu cầu của người dùng) .

Do đó, bản chất của phương pháp này nằm ở chỗ các mục tiêu của dự án (phạm vi dự án, cấu hình và thời hạn) được xác định ít chi tiết hơn

khi bắt đầu dự án và lịch trình thực hiện dự án cũng được chuẩn bị đại khái – dự án được chia thành các phần bằng nhau. lặp lại với các phần

được chỉ định của phạm vi dự án sẽ được tạo. Ban đầu, một nhóm đảm nhận những chức năng quan trọng nhất và để lại những chức năng ít quan trọng

nhất cho đến cuối. Những yêu cầu ít quan trọng hơn sau đó có thể được bỏ qua trên cơ sở kết quả của những lần lặp lại đã hoàn thành, mong muốn/

yêu cầu đã thay đổi của khách hàng, đề xuất của người thực hiện hoặc những thay đổi trong môi trường. Một đặc tả chi tiết về các sản phẩm của

các lần lặp và lập kế hoạch chính xác cho các lần lặp (cách thực hiện, nhiệm vụ, giờ làm việc, người thực hiện, v.v.) được tạo vào đầu mỗi lần

lặp, có tính đến các kết quả hiện tại, những hiểu biết mới, mong muốn mới của khách hàng hoặc ý tưởng của nhà phát triển cũng như những thay

đổi đối với các giả định và yêu cầu ban đầu. Kế hoạch thực hiện vòng lặp được lập bởi nhóm dự án (chứ không phải người quản lý dự án).

Gibbs (2006) đề cập rằng những người tiên phong trong cách tiếp cận linh hoạt và phát triển phần mềm lặp lại đã noi gương sản xuất tinh gọn

của Toyota và mục đích của họ là loại bỏ phần lớn chi phí chung và "nghi lễ" phổ biến đối với vòng đời dựa trên thác nước. Các lần lặp lại quá

trình phát triển sau đó kéo dài từ hai đến bốn tuần và ngày nay thời lượng của chúng không thay đổi – Rothman (2007) cho biết chúng kéo dài từ

một đến bốn tuần. Việc kiểm tra các kết quả trung gian diễn ra rất nhanh chóng (chứ không phải ở giai đoạn cuối như cách phát triển phần mềm

truyền thống) và sau mỗi lần lặp lại, nhóm cũng nhận được phản hồi về sự hài lòng của khách hàng. Wysocki (2009) cho biết thêm rằng việc lặp

lại có thể được lặp lại nếu khách hàng không hài lòng với kết quả.

Điều quan trọng là phải nhận ra rằng cách tiếp cận linh hoạt trước hết tập trung vào giai đoạn thực hiện của dự án và không xác định toàn

bộ vòng đời dự án, về nguyên tắc vẫn giữ nguyên (bắt đầu, lập kế hoạch, thực hiện và kết thúc), ngoại trừ giai đoạn cuối cùng. một phần của việc

bắt đầu (xác định các thông số kỹ thuật) và một phần của việc lập kế hoạch được chuyển sang giai đoạn thực hiện. Cách tiếp cận này chủ yếu ảnh

hưởng đến tính chính xác của việc lập kế hoạch – chắc chắn cần phải xác định lịch trình sơ bộ cho toàn bộ dự án khi bắt đầu dự án, trong khi

các bước lặp riêng lẻ được lên kế hoạch chi tiết hơn trong giai đoạn thực hiện (ví dụ: chiến thuật, nhiệm vụ, giờ làm việc, người biểu diễn,

v.v.).

Quản lý dự án cực đoan là bản nâng cấp của quản lý linh hoạt (cung cấp mức độ linh hoạt cao hơn). Theo Thomsett (2002), cái sau linh hoạt

hơn và dựa trên các yêu cầu năng động, chu kỳ phát triển ngắn hơn, các nhóm ảo, công nghệ thay đổi và sự tham gia chung của tất cả các bên liên

quan của dự án. Ông nhấn mạnh rằng mối quan hệ giữa khách hàng (người dùng) và nhà thầu (nhóm dự án) dựa trên sự hợp tác! Wysocki (2009) chỉ ra

rằng sự khác biệt trong các cách tiếp cận là do mức độ quen thuộc với giải pháp khi bắt đầu dự án. Sự khác biệt chính là mức độ chi tiết của

việc lập kế hoạch, vai trò lớn hơn của quản lý rủi ro và sự cộng tác nhiều hơn với khách hàng. Tác giả xác định việc sử dụng các phương pháp

tiếp cận riêng lẻ như sau:

• truyền thống – giải pháp và yêu cầu được xác định rõ ràng, không mong đợi những thay đổi lớn về phạm vi,

các dự án mang tính thường xuyên và có thể lặp lại, sử dụng một khuôn mẫu đã được chứng minh;
Machine Translated by Google

298 Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304

• linh hoạt – giải pháp và yêu cầu đã được biết một phần, có khả năng có các tính năng bổ sung mà nhóm chưa biết, dự kiến sẽ có nhiều

thay đổi trong phạm vi dự án (thường là các dự án phát triển hoặc tổ chức); và • cực đoan – mục tiêu và yêu cầu

không rõ ràng (thường là các dự án nghiên cứu và phát

triển).

2.2. Các phương pháp và kỹ thuật linh hoạt cũng như những điểm mới mà sự linh hoạt mang lại cho quản lý dự án

Nghiên cứu bổ sung về tài liệu và Nguyên tắc phát triển phần mềm linh hoạt (www.agilemanfesto.org) cho thấy những khác biệt chính của cách

tiếp cận truyền thống và linh hoạt có thể được phân thành bốn nhóm: yêu cầu và thông số kỹ thuật (mức độ chi tiết khi bắt đầu dự án), lập kế

hoạch dự án (lặp lại và lập lịch trình sơ bộ ở giai đoạn lập kế hoạch), làm việc nhóm (nhóm tự tổ chức, họp hàng ngày) và sự cộng tác của khách

hàng (đại diện của khách hàng là thành viên thường xuyên của nhóm). Dưới đây chúng tôi trình bày các nhóm yếu tố chi tiết hơn.

Yêu cầu/thông số kỹ thuật • được

khách hàng và nhóm dự án cùng chuẩn bị (www.agilemanifesto.org), • được xác định đại khái khi bắt

đầu dự án, trong khi chỉ chi tiết hơn khi bắt đầu các lần lặp lại

(Brandon, 2006),

• bao gồm đánh giá về tầm quan trọng của các chức năng (Gibbs, 2006), • có thể thay đổi và

bổ sung trong toàn bộ dự án, theo đề xuất của khách hàng hoặc các thành viên trong nhóm (Meade & Sarkis, 1999),

• các tính năng ít quan trọng nhất đã bị loại bỏ ở giai đoạn lập kế hoạch dự án hoặc sau đó ở giai đoạn lập kế hoạch lặp lại

(Gibbs, 2006).

Tiến độ dự án • dự

án được chia thành các giai đoạn lặp lại ngắn, thường kéo dài không quá tám tuần (Beck và Fowler trong

Thomsett, 2002; Rothman, 2007), • dự án

được lên kế hoạch sơ bộ ngay từ đầu, trong khi lịch trình chi tiết của quá trình lặp lại được chuẩn bị bởi

nhóm khi bắt đầu lặp lại (Boehm & Turner, 2005),

• nhóm tự tổ chức xác định chiến thuật thực hiện, nhiệm vụ và người thực hiện (Meade & Sarkis, 1999;

Lindstrom & Jeffries, 2004; Boehm & Turner, 2005),

• các quy trình thử nghiệm được phát triển trước khi phát triển các giải pháp (Brandon, 2006).

Vai trò của nhóm và làm việc nhóm

• nhóm chịu trách nhiệm về sự thành công của sản phẩm trên thị trường chứ không chỉ về việc triển khai hiệu quả

của dự án (Forsberg và cộng sự, 2005),

• đối đầu mang tính xây dựng là một cách thường xuyên để tìm kiếm ý tưởng mới và giải quyết vấn đề (Forsberg et

cộng sự, 2005),

• các thành viên trong nhóm làm việc theo cặp (Lindstrom & Jeffries, 2004; Brandon, 2006; Rothman, 2007), • nhóm

gặp nhau hàng ngày để thảo luận về kết quả công việc, ý tưởng, vấn đề và xác định nhiệm vụ hàng ngày (Rothman,

2007),

• các thành viên trong nhóm thường xuyên thảo luận về những sai lầm của mình và học hỏi từ

chúng, • sau mỗi lần lặp lại, nhóm thảo luận về tính đầy đủ của các đánh giá được yêu cầu, các phương pháp và kỹ thuật,

những sai sót trong công việc và những cải tiến có thể có trong tương lai (Boehm & Turner, 2005).

Cộng tác với khách hàng - đại diện của khách hàng: • sẵn

sàng 24/7 để biết thêm thông tin (Meade & Sarkis, 1999), một người là thành viên thường xuyên của nhóm và tham gia tích cực

mỗi ngày (Brandon, 2006),

• tham gia phát triển các quy trình kiểm tra (Lindstrom & Jeffries, 2004; Gibbs, 2006), • thường xuyên kiểm tra các kết

quả trung gian và báo cáo cho nhóm về những bất cập và sai sót (Brandon, 2006),
Machine Translated by Google

Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304 299

• đề xuất những thay đổi và tham gia đánh giá của họ (công việc và chi phí bổ sung, giá trị gia tăng).

Ngoài các kỹ thuật/thực hành linh hoạt được liệt kê, chúng tôi đã nghiên cứu các tài liệu nghiên cứu mới nhất để tìm hiểu xem các kỹ

thuật/thực hành riêng lẻ cải thiện hiệu suất và thành công của dự án đến mức nào. Tuy nhiên, các bài viết được nghiên cứu chủ yếu trình

bày các khía cạnh chung của cách tiếp cận linh hoạt, cách các nhóm, người quản lý và khách hàng cộng tác, lập kế hoạch và thực hiện dự án.

Chúng tôi đã tìm thấy một số bài viết có ý kiến chủ quan của các bên liên quan đến dự án thường cho thấy ảnh hưởng tích cực của cách tiếp

cận linh hoạt đến sự thành công của dự án (Conforto & Amaral, 2008; N<n<u, 2008; Batra, 2009; McAvoy & Butler, 2009; Subramanian và cộng

sự, 2009); tuy nhiên, chỉ có một số ít nghiên cứu và trình bày tác động thống kê của các kỹ thuật linh hoạt đến hiệu suất và thành công của

dự án (sử dụng phân tích hồi quy; Lee & Xia, 2010).

Ceschi và cộng sự. (2005) cho thấy kinh nghiệm tốt của các nhà quản lý dự án về lập kế hoạch linh hoạt (các nhà quản lý linh hoạt hài

lòng với kế hoạch dự án hơn các nhà quản lý truyền thống “dựa trên kế hoạch”), trong khi các công ty linh hoạt cũng hài lòng hơn với mối

quan hệ khách hàng của họ so với các công ty hoạt động dựa trên kế hoạch. Thật thú vị khi phát hiện ra rằng linh hoạt mà không có cấu trúc

có thể gây ra sự hỗn loạn, đặc biệt là trong các dự án phân tán phức tạp lớn, nơi việc lập kế hoạch, kiểm soát và điều phối là rất quan

trọng (Batra và cộng sự, 2010). Cấu trúc không có tính linh hoạt có thể dẫn đến sự cứng nhắc, đặc biệt khi một dự án liên quan đến nhiều

hoạt động học hỏi, khám phá và thay đổi.

Lee & Xia (2010) đã kiểm tra bằng thực nghiệm phạm vi khá hẹp của cách tiếp cận linh hoạt - mối quan hệ giữa mức độ mở rộng phản hồi

của nhóm phần mềm và hiệu quả phản hồi của nhóm, quyền tự chủ của nhóm và tính đa dạng của nhóm cũng như hiệu suất phát triển phần mềm

(hoàn thành đúng thời hạn, đúng hạn). hoàn thành ngân sách và chức năng phần mềm). Cuộc khảo sát cho thấy mức độ phản hồi và hiệu quả phản

hồi tác động khác nhau đến hiệu suất phát triển phần mềm (hiệu quả phản hồi ảnh hưởng tích cực đến tất cả việc hoàn thành đúng thời hạn,

hoàn thành đúng ngân sách và chức năng phần mềm, trong khi mức độ phản hồi tích cực chỉ ảnh hưởng tích cực đến chức năng phần mềm). Quyền

tự chủ của nhóm có tác động tích cực đến hiệu quả ứng phó và tác động tiêu cực đến khả năng mở rộng phản ứng, và sự đa dạng của nhóm có tác

động tích cực đến khả năng mở rộng phản ứng. Các tác giả cũng phát hiện ra rằng các quy trình, phương pháp và công cụ được tiêu chuẩn hóa

giúp quản lý các thay đổi, thời gian và chi phí. Stare (2010) cũng phát hiện ra tác động mạnh mẽ của quy trình quản lý thay đổi được tiêu

chuẩn hóa về thời gian và chi phí kết hợp với quản lý rủi ro.

Nghiên cứu duy nhất được biết đến về phát triển sản phẩm linh hoạt được thực hiện bởi Berger & Beynon-Davies (2009). Họ đã chứng minh

một số vấn đề với việc áp dụng các nguyên tắc phát triển lặp đi lặp lại, đặc biệt là

xung quanh việc tiến hành sự tham gia của các bên liên quan trong thiết kế chung. Nhìn chung, các bên liên quan ban đầu tỏ ra thụ động

trong việc tham gia và mặc dù được trao quyền chính thức nhưng tỏ ra miễn cưỡng đưa ra các quyết định ngoài vị trí dự kiến của họ. Giao

tiếp trong các phiên thiết kế cũng bị hạn chế thay vì cởi mở. Những khó khăn như vậy đã ảnh hưởng đến quỹ đạo của dự án, gây ra sự chậm

trễ trong việc đáp ứng thời hạn quan trọng của dự án.

3. Nghiên cứu thực nghiệm

3.1. Phương pháp nghiên cứu

Vì những phát hiện của nghiên cứu tài liệu không góp phần xác thực các giả định của chúng tôi, nên chúng tôi đã phát triển một mô hình

(Hình 1) và thử nghiệm nó dựa trên một nghiên cứu định lượng thực nghiệm thí điểm liên quan đến 21 dự án phát triển sản phẩm tại 5 doanh

nghiệp Slovenia. Tuy nhiên, mẫu người trả lời không lớn, mục đích chính của nghiên cứu này là kiểm tra xem liệu có tồn tại phôi thai phát

triển sản phẩm linh hoạt trong các doanh nghiệp Slovenia hay không. Trong trường hợp có những phát hiện đáng khích lệ, một nghiên cứu định

lượng thực nghiệm rộng hơn sẽ được thực hiện.

Các kết quả được thu thập trong bảng câu hỏi trên Web và hai loại phân tích đã được thực hiện. Đầu tiên, chúng tôi

đã xem xét những thực hành linh hoạt nào đã được thực thi trong các doanh nghiệp và ở mức độ nào. Và thứ hai, bằng phân tích đa biến bằng

phần mềm SPSS, chúng tôi đã kiểm tra tác động của các phương pháp thực hành khác nhau đối với việc triển khai dự án hiệu quả và thành công

của dự án. Chúng tôi đã phân tích dữ liệu thu được bằng phân tích đa biến - với phân tích tương quan, chúng tôi đã xác minh xem liệu sự

tồn tại của các biến cụ thể có làm giảm (hoặc tăng) việc thực hiện dự án hiệu quả (hiệu suất dự án) và sự thành công của dự án hay không.

Bằng cách tính toán hồi quy tuyến tính của từng cá nhân
Machine Translated by Google

300 Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304

các biến số mà chúng tôi muốn tìm ra mức độ tác động của chúng, tuy nhiên, phân tích tương quan cho thấy có rất ít mối
tương quan giữa các biến số nên phân tích hồi quy sẽ vô giá trị.

Thông số kỹ thuật
CÓ HIỆU QUẢ

DỰ ÁN

tiến độ dự án

Làm việc nhóm

DỰ ÁN THÀNH CÔNG

Cộng tác khách hàng

Hình 1. Mô hình nghiên cứu

Để xác định tác động của các phương pháp linh hoạt đến hiệu suất dự án, chúng tôi đã xác định bốn chỉ số hiệu quả: độ
trễ của dự án, thặng dư chi phí, giờ làm việc và chức năng của sản phẩm. Chúng tôi đã sử dụng tỷ lệ (%) giữa đường cơ sở
và các chỉ số thực tế (được chỉ ra ở cuối dự án) và chúng trở thành nhóm biến phụ thuộc đầu tiên trong phân tích tiếp theo.
Những người được hỏi phải ước tính độ lệch trung bình cuối cùng của các dự án (kết quả được trình bày trong bảng 1).

Chuyển hướng. 1: Chỉ số thực hiện dự án của các dự án được khảo sát

Thời gian Trị giá Công việc Chức năng

Số dự án dư thừa 11 (50%) 8 (36%) 13 (59%) 4 (18%)

Độ lệch trung bình 29% 14% 30% 15%

Số dự án có thặng dư trên 50% 2 (9%) 0 2 (9%) 2 (9%)

Một trong những đặc điểm của các dự án phát triển là chúng có thể được thực hiện không hiệu quả (bị chậm trễ và vượt
quá ngân sách), tuy nhiên, sản phẩm đã phát triển vẫn có thể thành công trên thị trường. Đó là lý do tại sao chúng tôi cũng
muốn xác định tác động của các phương pháp linh hoạt đến sự thành công của dự án. Chúng tôi đã đo lường tác động này bằng
ba chỉ số: 1) sự hài lòng của khách hàng, 2) sự thành công của sản phẩm trên thị trường và 3) thành công tài chính tổng
thể. Chúng tôi đã sử dụng thang đo Likert bốn cấp độ - người trả lời phải ước tính mức độ của các chỉ số thành công từ kém
thỏa đáng (1) đến mẫu mực (4). Tỷ lệ dự án có mức độ thành công duy nhất được thể hiện trên Hình 2.

Thành công tài chính Ít thỏa đáng hơn

đạt yêu cầu

Sự thành công của sản phẩm trên thị trường Khá thỏa đáng

gương mẫu
Sự hài lòng của khách hàng

0% 20% 40% 60% 80% 100%

Hình 2. Các chỉ số thành công của dự án

Machine Translated by Google

Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304 301

3.2. kết quả và thảo luận

Đầu tiên chúng tôi xem xét phương pháp chuẩn bị các yêu cầu/thông số kỹ thuật và mức độ chi tiết khi bắt đầu dự án. 81% thông số kỹ thuật của

dự án do khách hàng và nhóm dự án cùng chuẩn bị (Hình 3), 86% bao gồm đánh giá về tầm quan trọng của các chức năng, trong khi 62% nhóm dự án cân

nhắc loại bỏ các chức năng ít quan trọng nhất.

Thông số kỹ thuật đã được khách hàng cùng chuẩn bị

và nhóm dự án

Thông số kỹ thuật bao gồm việc đánh giá ĐÚNG

tầm quan trọng của chức năng của sản phẩm

KHÔNG

Nhóm, cùng với khách hàng đã quyết định về

loại bỏ các chức năng ít quan trọng nhất

0% 20% 40% 60% 80% 100%

Hình 3. Chuẩn bị/xác định các thông số kỹ thuật

Ngoài ra, chúng tôi yêu cầu những người trả lời nêu rõ các thông số kỹ thuật của sản phẩm đã được xác định ở mức độ nào khi bắt đầu dự án:

29% dự án đã xác định chính xác toàn bộ chức năng của sản phẩm ngay từ đầu, 33% trong số đó đã xác định đại khái chức năng của sản phẩm tại thời

điểm bắt đầu. ngay từ đầu, trong khi chỉ những chức năng quan trọng nhất được xác định chi tiết, tuy nhiên 38% dự án chỉ xác định những chức năng

quan trọng nhất, trong khi phần còn lại được trình bày chi tiết sau đó.

Sau đó, chúng tôi đã phân tích tác động của việc xác định thông số kỹ thuật bằng phân tích tương quan - chúng tôi đã xác minh xem liệu sự tồn

tại của các biến cụ thể có làm giảm (hoặc tăng) việc triển khai dự án hiệu quả và thành công của dự án hay không.

Mối tương quan cho thấy rằng việc xác định tầm quan trọng của các chức năng dẫn đến giảm độ trễ của dự án (Tương quan Pearson C 0,727, Sig.

0,000) và chi phí (C 0,510, Sig. 0,031), trong khi việc loại bỏ các chức năng ít quan trọng nhất sẽ làm tăng tổng thể thành công tài chính của dự

án (C 0,602, Sig. 0,005). Các yếu tố khác không chứng minh được ảnh hưởng.

Dự án được chia thành các đoạn ngắn (cùng độ dài)

chu kỳ/lặp đi lặp lại trong đó nhóm đã

tập trung vào các chức năng riêng lẻ (hoặc tập hợp các

chức năng) của sản phẩm

Tim đã tự tổ chức và quyết tâm làm việc ĐÚNG

(chiến thuật, công nghệ, v.v.)

KHÔNG

Các thành viên trong nhóm đã phát triển các quy trình thử nghiệm

trước khi họ phát triển các giải pháp

0% 20% 40% 60% 80% 100%

Hình 4. Lập kế hoạch dự án

Machine Translated by Google

302 Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304

Như đã đề cập ở đầu chương, mẫu khảo sát có quy mô nhỏ, điều này chắc chắn ảnh hưởng đến chất lượng phân tích hồi
quy. Tuy nhiên, nghiên cứu đã chỉ ra rõ ràng rằng trong phần lớn các dự án phát triển được nghiên cứu, các thông số kỹ
thuật được xác định theo cách linh hoạt, nhưng để chứng minh rằng nó thực sự mang lại lợi ích, chúng ta sẽ phải xem xét
một mẫu dự án lớn hơn.
Lĩnh vực được kiểm tra tiếp theo là lập kế hoạch dự án. 70% dự án được chia thành các giai đoạn/giai đoạn lặp lại ngắn
(có cùng độ dài), trong đó các nhóm tập trung vào các chức năng riêng lẻ hoặc một tập hợp chức năng của sản phẩm (Hình 4).
Ba phần tư (76%) các nhóm tự xác định cách thức thực hiện dự án (chiến thuật, công nghệ, nhiệm vụ, v.v.), trong khi gần
một nửa trong số họ (47%) đã phát triển các quy trình thử nghiệm trước khi phát triển các giải pháp (chức năng của sản
phẩm) . Tuy nhiên, chỉ có 19% dự án không được lên lịch khi bắt đầu dự án – chúng chỉ được chia thành các giai đoạn lặp
lại/giai đoạn, trong khi những dự án đó chỉ được lên lịch chi tiết hơn khi bắt đầu thực hiện. Phần lớn, 71% dự án được
lập kế hoạch ngay từ đầu dự án và được cập nhật thường xuyên trong quá trình thực hiện, trên cơ sở kết quả và những thay
đổi, trong khi 19% dự án được lập kế hoạch đầy đủ, chính xác ngay từ đầu và không thay đổi nhiều trong quá trình thực
hiện. giai đoạn thực hiện.
Phân tích tương quan chỉ cho thấy một yếu tố nổi bật của việc thực hiện hiệu quả – khi các nhóm tự tổ chức xác định
cách thực hiện dự án, chức năng của sản phẩm cuối cùng ít sai lệch hơn so với yêu cầu (C 0,451, Sig. 0,046), trong khi
chúng tôi không tìm thấy ảnh hưởng nào của việc kiểm tra. yếu tố quyết định sự thành công của dự án.

KHÔNG
Đối đầu mang tính xây dựng là một cách thường xuyên để tìm kiếm ý tưởng

và giải quyết vấn đề

Một vài lần

Các thành viên trong nhóm làm việc theo cặp (mỗi hoạt động được thực hiện

do hai người biểu diễn cùng thực hiện)

Vài lần
Các thành viên trong nhóm thường xuyên thảo luận về những sai lầm của mình
và học hỏi từ họ

Sau mỗi lần lặp lại (chức năng đã phát triển) các thành viên trong nhóm
CÓ (thường xuyên/có hệ thống),
thảo luận về tính đầy đủ của việc đánh giá công việc, các phương pháp được sử dụng
đây là cách thông thường của chúng tôi
và kỹ thuật, sai sót trong công việc và tìm kiếm những cải tiến…
đang làm việc
0% 20% 40% 60% 80% 100%

Hình 5. Vai trò của nhóm và làm việc nhóm

Nhóm thực hành linh hoạt được kiểm tra thứ ba là vai trò nhóm và làm việc nhóm (Hình 5). Chúng tôi nhận thấy rằng gần
hai phần ba (62%) nhóm không chỉ chịu trách nhiệm thực hiện dự án hiệu quả mà còn chịu trách nhiệm về sự thành công của
sản phẩm trên thị trường. Tuy nhiên, trong một nửa số dự án, các nhóm thường phải làm việc linh hoạt, chỉ có chưa đến
1/4 các nhóm thường xuyên đối đầu mang tính xây dựng, tìm kiếm ý tưởng mới và giải quyết vấn đề (24%), thường xuyên
thảo luận về những sai lầm của mình và học hỏi từ chúng (20%), và sau mỗi lần lặp lại thảo luận về tính đầy đủ của các
đánh giá được yêu cầu, các phương pháp và kỹ thuật, những sai sót trong công việc và những cải tiến có thể có trong
tương lai (14%). Chỉ trong 5% dự án, các thành viên trong nhóm thường xuyên làm việc theo cặp (trong khi 29% làm việc
thường xuyên). Chúng tôi cũng yêu cầu người trả lời nêu tần suất các cuộc họp nhóm; tuy nhiên, chỉ có một nhóm dự án gặp
nhau vài lần trong ngày, không có ai gặp nhau hàng ngày, nhưng 16 (76%) gặp nhau hàng tuần. Có lẽ do cách tiếp cận ít hệ
thống hơn nên chúng tôi không tìm thấy tác động của vai trò nhóm/các yếu tố công việc đến việc thực hiện hiệu quả và thành công của dự án
Nhóm được kiểm tra cuối cùng là nhóm cộng tác với khách hàng (Hình 6). Cuộc kiểm tra của nó cho thấy mức độ thấp nhất
của cách tiếp cận linh hoạt trong các dự án. Đại diện của người dùng/khách hàng chỉ là thành viên nhóm thường xuyên trong
hai dự án, trong khi chỉ tham gia hàng ngày trong một dự án (nhưng chỉ một lần một ngày). Trên một nửa số dự án họ tham
gia hàng tuần, 15% dự án hàng tháng, trong khi 30% thậm chí còn hiếm hơn. Trên 2/3 (67%) dự án, đại diện người dùng/khách
hàng đề xuất và đánh giá các thay đổi (chi phí, giá trị gia tăng) cùng với nhóm, nhưng điều này cũng thường xảy ra ở các
dự án truyền thống. 24% đại diện khách hàng tham gia xây dựng quy trình kiểm tra, trong khi 38% thường xuyên kiểm tra các
kết quả trung gian và báo cáo cho nhóm về những bất cập, sai sót.
Machine Translated by Google

Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304 303

Đại diện của người dùng/khách hàng…

tích cực làm việc theo nhóm hàng ngày (anh ấy/cô ấy là một

thành viên chính thức của nhóm)

những thay đổi được đề xuất và đánh giá (chi phí, giá trị gia tăng)

cùng với đội

ĐÚNG

thường xuyên kiểm tra kết quả trung gian và thông báo
KHÔNG
đội ngũ (trong) phù hợp

tham gia xây dựng quy trình kiểm thử

0% 20% 40% 60% 80% 100%

Hình 6. Sự hợp tác của khách hàng

Một lần nữa, chúng tôi chưa tìm thấy tác động của các yếu tố cộng tác của khách hàng đến việc thực hiện hiệu quả; tuy nhiên,

việc khách hàng thường xuyên kiểm tra các kết quả trung gian đã chứng tỏ làm tăng thành công tài chính chung của dự án (C 0,589,

Sig. 0,006). Các yếu tố khác không chứng minh được ảnh hưởng.

4. Kết luận

Các phương pháp tiếp cận linh hoạt để quản lý các dự án phát triển phần mềm đã phát triển đáng kể kể từ khi tuyên ngôn Agile

được xuất bản năm 2001. Các tác giả của tuyên ngôn tuyên bố rằng phương pháp tiếp cận linh hoạt mang lại nhiều lợi ích cho cả

khách hàng và nhóm dự án, và phương pháp này sẽ hữu ích cho Tuy nhiên, đối với tất cả các loại dự án, thực tiễn vẫn chưa khẳng

định được tầm nhìn xa và nỗ lực của họ. Bất chấp những nghi ngờ của chúng tôi rằng cách tiếp cận linh hoạt sẽ được sử dụng rộng

rãi trong tương lai, chúng tôi tin rằng một số phương pháp linh hoạt nhất định có thể được sử dụng cho các dự án phát triển sản

phẩm về cơ bản vẫn được thực hiện theo cách truyền thống.

Sự khác biệt chính của cách tiếp cận truyền thống và linh hoạt có thể được phân thành bốn nhóm: yêu cầu & thông số kỹ thuật

(mức độ chi tiết khi bắt đầu dự án), lập kế hoạch dự án (lặp lại và lập lịch trình sơ bộ ở giai đoạn lập kế hoạch), làm việc nhóm

(tự -tổ chức nhóm, họp hàng ngày) và cộng tác với khách hàng (đại diện của khách hàng là thành viên thường xuyên của nhóm).

Các nghiên cứu trước đây chủ yếu trình bày các khía cạnh chung của phương pháp tiếp cận linh hoạt, cách các nhóm, người quản

lý và khách hàng cộng tác, lập kế hoạch và thực hiện dự án, trong khi chỉ có một số nghiên cứu xem xét ảnh hưởng của các phương

pháp thực hành linh hoạt riêng lẻ đến hiệu suất và thành công của dự án. Vì những phát hiện đó không góp phần xác thực các giả

định của chúng tôi nên chúng tôi đã thực hiện một nghiên cứu thí điểm về các dự án phát triển sản phẩm ở năm doanh nghiệp Slovenia.

Nghiên cứu định lượng thực nghiệm liên quan đến 21 dự án phát triển sản phẩm. Mẫu người trả lời không lớn, tuy nhiên mục đích

chính của nghiên cứu là kiểm tra xem liệu có tồn tại phôi thai phát triển sản phẩm linh hoạt trong các doanh nghiệp Slovenia hay

không.

Nghiên cứu cho thấy có nhiều phương pháp thực hành linh hoạt tồn tại trong các dự án được kiểm tra; tuy nhiên, chúng ta không

thể nói về cách tiếp cận linh hoạt có hệ thống để phát triển sản phẩm mới mà là về những cách tiếp cận từng phần đã được các nhóm/

người quản lý riêng lẻ thiết lập trên cơ sở các phương pháp hay nhất từ các dự án trước đây. Thật không may, phân tích đa biến

về ảnh hưởng của các phương pháp thực hành linh hoạt đến hiệu suất và thành công của dự án không mang lại nhiều thông tin hữu

ích, có lẽ là do mẫu nhỏ. Tuy nhiên, chúng tôi đã gặp phải một số phát hiện đáng khích lệ thuyết phục chúng tôi rằng việc thực

hiện một nghiên cứu chi tiết trên một mẫu lớn hơn là hợp lý.

5. Tài liệu tham khảo

Batra, D. (2009). Thực hành linh hoạt được sửa đổi cho các dự án phần mềm thuê ngoài. Truyền thông của ACM. 52 (9), 143-148.
Machine Translated by Google

304 Aljaž Stare / Procedia - Khoa học xã hội và hành vi 119 ( 2014 ) 295 – 304

Batra, D., Xia, W., Vander-Meer, D., Dutta, K. (2010). Cân bằng các phương pháp tiếp cận phát triển linh hoạt và có cấu trúc để quản lý thành công các dự án phần

mềm phân tán lớn: Một nghiên cứu điển hình từ ngành công nghiệp tàu du lịch. Truyền thông của AIS. 27 (21), 379-394.

Berger, H., Beynon-Davies, P. (2009). Tiện ích của việc phát triển ứng dụng nhanh chóng trong các dự án phức tạp, quy mô lớn. Hê thông thông tin

Tạp chí. 19 (6), 549–570.

Boehm, B., Turner, R. (2005). Những thách thức quản lý trong việc triển khai các quy trình linh hoạt trong các tổ chức phát triển truyền thống. IEEE

Phần mềm. 22(5), 30-39.

Bowles Jackson, M. (2012). Agile: một thập kỷ trong Mạng PM. 26 (4), 58-62.

Brandon, D. (2006). Quản lý dự án cho các hệ thống thông tin hiện đại. Hershey: Nhà xuất bản IRM.

Ceschi, M., Sillitti, A., Succi, G., De Panfilis, S. (2005). Quản lý dự án trong các công ty có kế hoạch và linh hoạt. Phần mềm IEEE. 22 (3), 21-
27.

Conforto, EC, Amaral, DC (2008). Đánh giá một phương pháp linh hoạt để lập kế hoạch và kiểm soát các dự án đổi mới. Quản lý dự án

Tạp chí. 41 (2), 73-80.

Doherty, I. (2010). Quản lý dự án linh hoạt để phát triển giáo dục điện tử. Tạp chí Giáo dục Từ xa. 24 (1), 91-106.

Doherty, MJ (2011). Sử dụng các lý thuyết tổ chức, điều phối và dự phòng để kiểm tra hiểu biết sâu sắc của người quản lý dự án về các yếu tố thành công truyền

thống và linh hoạt cho các dự án công nghệ thông tin. luận án tiến sĩ. Đại học Walden

Forsberg, K., Mooz, H., Cotterman, H. (2005). Trực quan hóa quản lý dự án. Hoboken: John Wiley & Sons.

Gibbs, RD (2006). Gia công phần mềm và quy trình thống nhất hợp lý của IBM. Thượng Yên Sông: Nhà xuất bản IBM.

Gonzalez, W. (2011). Quản lý dự án linh hoạt và tạo ra sở hữu trí tuệ. luận án tiến sĩ. Đại học Maryland

Đại học Cao đẳng.

Lee, G., Xia, W. (2010). Hướng tới sự linh hoạt: một phân tích tổng hợp dữ liệu lĩnh vực định lượng và định tính về tính linh hoạt trong phát triển phần mềm. MIS

Hàng quý. 34 (1), 87-114.

Lindstrom, L., Jeffries, R. (2004). Phương pháp lập trình cực đoan và phát triển phần mềm linh hoạt. Quản lý hệ thống thông tin. 21

(3), 41-52.

Tuyên ngôn về phát triển phần mềm linh hoạt (2001). www.agilemanfesto.org.

McAvoy, J., Butler, T. (2009). Vai trò của quản lý dự án trong việc đưa ra quyết định không hiệu quả trong các dự án phát triển phần mềm Agile.

Tạp chí Hệ thống Thông tin Châu Âu. 18 (4), 372–383.

Meade, LM, Sarkis J. (1999) Phân tích các phương án thay thế dự án tổ chức cho các quy trình sản xuất linh hoạt: cách tiếp cận mạng phân tích.

Tạp chí quốc tế về nghiên cứu sản xuất. 37(2), 241-261.

N<n<u, CS (2008). Vấn đề chất lượng trong các dự án CNTT. Bản tin của Đại học Transilvania ở Brasov. 1 (50), 531-540.

Từ điển Oxford. www.oxforddictionaries.com

Rothman, J. (2007). Quản lý nó. Dallas: Kệ sách thực dụng.

Nhìn chằm chằm, A. (2010). Quản lý toàn diện các thay đổi của dự án. Tạp chí kinh tế và kinh doanh. 12(3), 195-210.

Nhìn chằm chằm, A. (2013). Quản lý dự án linh hoạt – một cách tiếp cận tương lai để quản lý dự án? Tạp chí quản lý mối quan hệ năng động. 2

(1).

Subramanian, GH, Klein, G., Jiang, JJ, Chan, CL (2009). Cân bằng bốn yếu tố trong các dự án phát triển hệ thống. Truyền thông của

ACM. 52 (10), 118-121.

Thomsett, R. (2002). Quản lý dự án cấp tiến. Thượng Saddle River (NJ): Prentice Hall PTR.

Wysocki, RK (2009). Quản lý dự án hiệu quả: truyền thống, nhanh nhẹn, cực đoan. ( Tái bản lần thứ 5) Indianapolis: Nhà xuất bản Wiley.