Machine Translated by Google

Chương 4

Đội

Mục tiêu học tập

Sau khi nghiên cứu chương này, bạn sẽ có thể

• Giải thích tầm quan trọng của một nhóm được tổ

chức tốt. • Mô tả cách tổ chức các nhóm theo thứ bậc hiện

đại. • Phân tích điểm mạnh và điểm yếu của nhiều tổ chức nhóm khác
nhau.

• Đánh giá đúng các vấn đề nảy sinh khi lựa chọn tổ chức nhóm thích hợp.

Không có các kỹ sư phần mềm có năng lực, được đào tạo tốt, một dự án phần mềm chắc chắn sẽ
thất bại. Tuy nhiên, có đúng người là chưa đủ; các nhóm phải được tổ chức sao cho các thành
viên trong nhóm có thể làm việc hiệu quả khi hợp tác với nhau. Tổ chức đội là chủ đề của chương
này.

4.1 Tổ chức nhóm

Hầu hết các sản phẩm đều quá lớn để được hoàn thành bởi một chuyên gia phần mềm đơn lẻ trong
thời gian hạn chế nhất định. Do đó, sản phẩm phải được giao cho một nhóm các chuyên gia được
tổ chức thành một nhóm trong
. Ví dụ,
vònghãy
2 tháng,
xem xétcóquy
thểtrình
cần giao
phân nhiệm
tích. vụ
Để cho
xác ba
định
chuyên
sản phẩm
gia phân
mục tiêu
tích
được tổ chức thành một nhóm dưới sự chỉ đạo của trưởng phòng phân tích. Tương tự, nhiệm vụ
thiết kế có thể được chia sẻ giữa các thành viên của nhóm thiết kế.

Giả sử bây giờ một sản phẩm phải được viết mã trong vòng 3 tháng, mặc dù có liên quan đến
1 người-năm viết mã (một người-năm là khối lượng công việc mà một người có thể thực hiện trong
1 năm). Giải pháp có vẻ đơn giản: Nếu một lập trình viên có thể viết mã sản phẩm trong 1 năm,
bốn lập trình viên có thể làm việc đó trong 3 tháng.
Điều này, tất nhiên, không hoạt động. Trên thực tế, bốn lập trình viên có thể mất gần một
năm và chất lượng của sản phẩm tạo ra có thể thấp hơn so với nếu một lập trình viên

107 107
Machine Translated by Google

108 Phần A Khái niệm Công nghệ Phần mềm

đã mã hóa toàn bộ sản phẩm. Lý do là một số nhiệm vụ có thể được chia sẻ, nhưng những nhiệm
vụ khác phải được thực hiện riêng lẻ. Ví dụ, nếu một người nông dân có thể hái một ruộng dâu
tây trong 10 ngày, thì 10 người nông dân đó có thể hái được ruộng dâu đó trong 1 ngày. Mặt
khác, một con voi có thể đẻ một con trong 22 tháng, nhưng kỳ tích này không thể đạt được
trong 1 tháng bởi 22 con voi.
Nói cách khác, các nhiệm vụ như hái dâu hoàn toàn có thể được chia sẻ; những thứ khác,
chẳng hạn như sản xuất voi, hoàn toàn không thể chia sẻ. Không giống như sản xuất voi, có
thể chia sẻ các nhiệm vụ thực hiện giữa các thành viên trong nhóm bằng cách phân phối mã hóa
giữa các thành viên trong nhóm. Tuy nhiên, lập trình nhóm cũng không giống như hái dâu ở chỗ
các thành viên trong nhóm phải tương tác với nhau một cách có ý nghĩa và hiệu quả. Ví dụ:
giả sử Sheila và Harry phải viết mã hai mô-đun, m1 và m2. Một số điều có thể đi sai. Chẳng
hạn, cả Sheila và Harry đều có thể mã hóa m1 và bỏ qua m2. Hoặc Sheila có thể mã m1 và Harry
có thể mã m2. Nhưng khi m1 gọi m2, nó chuyển bốn đối số; Harry đã mã hóa m2 theo cách nó yêu
cầu năm đối số. Hoặc thứ tự của các đối số trong m1 và m2 có thể khác nhau. Hoặc thứ tự có
thể giống nhau nhưng kiểu dữ liệu có thể khác một chút. Những vấn đề như vậy thường được gây
ra bởi một quyết định được đưa ra trong khi luồng công việc thiết kế được thực hiện mà không
được phổ biến trong toàn bộ tổ chức phát triển.
Vấn đề không liên quan gì đến năng lực kỹ thuật của các lập trình viên.
Tổ chức nhóm là một vấn đề quản lý; quản lý phải tổ chức các nhóm lập trình sao cho mỗi nhóm
đều có năng suất cao.
Một loại khó khăn khác phát sinh từ việc phát triển phần mềm theo nhóm được thể hiện
trong Hình 4.1. Ba kênh giao tiếp tồn tại giữa ba chuyên gia phần mềm làm việc trong dự án.
Bây giờ, giả sử rằng công việc đang bị trượt, thời hạn đang đến rất nhanh và nhiệm vụ gần
như chưa hoàn thành. Điều hiển nhiên cần làm là thêm chuyên gia thứ tư vào đội. Nhưng điều
đầu tiên phải xảy ra khi chuyên gia thứ tư tham gia nhóm là ba người còn lại giải thích chi
tiết những gì đã hoàn thành cho đến nay và những gì vẫn chưa hoàn thành. Nói cách khác, việc
thêm nhân sự vào một dự án phần mềm muộn khiến nó thậm chí còn muộn hơn. Nguyên tắc này được
gọi là Định luật Brooks theo tên của Fred Brooks, người đã quan sát thấy nó trong khi quản
lý quá trình phát triển OS/360 [Brooks, 1975], một hệ điều hành dành cho máy tính lớn IBM
360.
Trong một tổ chức lớn, các nhóm được sử dụng trong mọi quy trình sản xuất phần mềm,
nhưng đặc biệt là khi quy trình triển khai được thực hiện; trong quy trình làm việc đó, các
lập trình viên làm việc độc lập trên các tạo phẩm mã riêng biệt. Theo đó, quy trình triển khai là

HÌNH 4.1

Giao tiếp

đường dẫn giữa

ba phần mềm

các chuyên
gia (đường liền
nét) và khi thứ tư

chuyên nghiệp
nối chúng
(đường đứt nét).
Machine Translated by Google

Chỉ trong trường hợp bạn muốn biết Hộp 4.1

Khoảng 40 năm trước, khi phần mềm vẫn được nhập trên thẻ đục lỗ, tất cả quá nhiều lập
trình viên đều coi “lỗi” trong phần mềm giống như côn trùng xâm nhập bộ bài của họ trừ
khi bị ngăn cản. Thái độ này đã được châm ngòi một cách thú vị bởi việc tiếp thị một
loại bình xịt aerosol có tên là Shoo-Bug. Các hướng dẫn trên nhãn giải thích một cách
trang trọng rằng việc rải Shoo-Bug lên bộ bài của một người sẽ đảm bảo rằng không có con
bọ nào có thể xâm nhập vào mã. Tất nhiên, bình xịt không chứa gì ngoài không khí.

một ứng cử viên chính cho việc chia sẻ nhiệm vụ giữa một số chuyên gia phần mềm. Trong một số tổ
chức nhỏ hơn, một cá nhân có thể chịu trách nhiệm về các yêu cầu, phân tích và thiết kế, sau đó
việc triển khai được thực hiện bởi một nhóm gồm hai hoặc ba người lập trình. Bởi vì các nhóm được
sử dụng nhiều nhất khi thực hiện quy trình công việc triển khai, các vấn đề về tổ chức nhóm được
cảm nhận sâu sắc nhất trong quá trình triển khai.
Do đó, trong phần còn lại của chương này, tổ chức nhóm được trình bày trong bối cảnh triển khai,
mặc dù các vấn đề và giải pháp của chúng đều có thể áp dụng như nhau cho tất cả các quy trình
công việc khác.
Có hai cách tiếp cận cực đoan để tổ chức nhóm lập trình, nhóm dân chủ và nhóm lập trình viên
trưởng. Cách tiếp cận được thực hiện ở đây là mô tả từng cách tiếp cận trong số hai cách tiếp
cận, làm nổi bật điểm mạnh và điểm yếu của nó, sau đó đề xuất các cách khác để tổ chức một nhóm
lập trình kết hợp các đặc điểm tốt nhất của hai thái cực.

4.2 Phương pháp tiếp cận nhóm dân chủ

Tổ chức đội dân chủ lần đầu tiên được Weinberg mô tả vào năm 1971 [Weinberg, 1971]. Khái niệm cơ

bản của nhóm dân chủ là lập trình vô ngã .

Weinberg chỉ ra rằng các lập trình viên có thể rất gắn bó với mã của họ. Đôi khi, họ thậm chí còn
đặt tên cho các mô-đun của mình theo tên của chính họ: Do đó, họ xem các mô-đun của mình như một
phần mở rộng của chính họ. Điều khó khăn với điều này là một lập trình viên coi một mô-đun như
một phần mở rộng của cái tôi của anh ấy hoặc cô ấy chắc chắn sẽ không cố gắng tìm ra tất cả các
lỗi trong mã của “anh ấy” hoặc mã “của cô ấy”. Và, nếu có lỗi,
mộtthì
số nó
cônđược
trùng
gọichui
là lỗi
vào ,mãgiống
mà không
như
cần hỏi và có thể đã bị ngăn chặn nếu mã được bảo vệ cẩn thận hơn để chống lại sự xâm nhập (xem
Hộp Đề phòng trường hợp bạn muốn biết 4.1).
Giải pháp của Weinberg cho vấn đề các lập trình viên quá gắn bó với mã của chính họ là lập
trình vô ngã. Môi trường xã hội phải được tái cấu trúc và các giá trị của lập trình viên cũng
vậy. Mọi lập trình viên phải khuyến khích các thành viên khác trong nhóm tìm lỗi trong mã của họ.
Sự hiện diện của một lỗi không được coi là một điều gì đó tồi tệ mà là một sự kiện bình thường và
được chấp nhận; thái độ của người đánh giá nên được đánh giá cao khi được hỏi lời khuyên, hơn là
chế nhạo lập trình viên vì đã mắc lỗi viết mã. Toàn bộ nhóm do đó phát triển một đặc tính, một
bản sắc nhóm; và các mô-đun thuộc về toàn bộ nhóm chứ không phải của bất kỳ cá nhân nào.

Một nhóm gồm tối đa 10 lập trình viên vô ngã tạo thành một nhóm dân chủ. Weinberg cảnh báo
rằng ban lãnh đạo có thể gặp khó khăn khi làm việc với một nhóm như vậy. Rốt cuộc, hãy xem xét
con đường sự nghiệp quản lý. Khi một lập trình viên được thăng chức lên vị trí quản lý, các lập
trình viên đồng nghiệp của anh ta hoặc cô ta không được thăng chức và phải cố gắng đạt được cấp
độ cao hơn ở vòng thăng tiến tiếp theo. Ngược lại, một nhóm dân chủ là một nhóm làm việc vì mục tiêu chung.
Machine Translated by Google

110 Phần A Khái niệm Công nghệ Phần mềm

không có người lãnh đạo duy nhất, không có lập trình viên nào cố gắng thăng tiến lên cấp độ tiếp theo.

Điều quan trọng là bản sắc nhóm và sự tôn trọng lẫn nhau.

Weinberg kể về một nhóm dân chủ đã phát triển một sản phẩm xuất sắc. Ban quản lý quyết định

thưởng tiền mặt cho người quản lý danh nghĩa của nhóm (theo định nghĩa, một nhóm dân chủ không có

người lãnh đạo). Anh ấy từ chối nhận nó một cách cá nhân, nói rằng nó phải được chia đều cho tất cả

các thành viên trong đội. Ban quản lý nghĩ rằng anh ta đang cố gắng kiếm thêm tiền và nhóm (và đặc

biệt là người quản lý danh nghĩa của nó) có một số ý tưởng khá không chính thống. Ban quản lý buộc

người quản lý danh nghĩa phải nhận số tiền, sau đó anh ta chia đều cho cả nhóm. Tiếp theo, toàn bộ

đội đã từ chức và gia nhập một công ty khác với tư cách là một đội.

Điểm mạnh và điểm yếu của các nhóm dân chủ hiện đã được trình bày.

4.2.1 Phân tích phương pháp tiếp cận nhóm dân chủ Điểm mạnh chính

của phương pháp tiếp cận nhóm dân chủ là thái độ tích cực đối với việc tìm ra lỗi. Càng
được tìm thấy, các thành viên của một nhóm dân chủ càng hạnh phúc. Thái độ tích cực này dẫn
đến việc phát hiện lỗi nhanh hơn và do đó dẫn đến mã chất lượng cao. Nhưng có một số vấn đề
lớn. Như đã chỉ ra trước đây, các nhà quản lý có thể gặp khó khăn trong việc chấp nhận lập
trình vô ngã. Ngoài ra, một lập trình viên với 15 năm kinh nghiệm có thể sẽ bực bội khi mã
của mình được đánh giá bởi các lập trình viên đồng nghiệp, đặc biệt là những người mới bắt đầu.
Weinberg cảm thấy rằng các đội vô ngã mọc lên một cách tự phát và không thể bị áp đặt từ bên

ngoài. Một nghiên cứu thử nghiệm nhỏ đã được thực hiện trên các nhóm lập trình dân chủ, nhưng kinh

nghiệm của Weinberg là các nhóm dân chủ có năng suất rất cao. Mantei [1981] đã phân tích tổ chức nhóm

dân chủ bằng cách sử dụng các lập luận dựa trên lý thuyết và thực nghiệm về tổ chức nhóm nói chung

thay vì cụ thể về nhóm lập trình. Cô ấy chỉ ra rằng các nhóm phi tập trung hoạt động tốt nhất khi vấn

đề trở nên khó khăn và gợi ý rằng các nhóm dân chủ nên hoạt động tốt trong môi trường nghiên cứu.

Theo kinh nghiệm của tôi, một nhóm dân chủ cũng hoạt động tốt trong môi trường công nghiệp khi phải

giải quyết một vấn đề khó khăn. Trong một số dịp, tôi đã là thành viên của các nhóm dân chủ nổi lên

một cách tự phát giữa các chuyên gia phần mềm có kinh nghiệm nghiên cứu. Tuy nhiên, một khi nhiệm vụ

đã được giảm xuống thành việc triển khai một giải pháp khó thắng, thì nhóm sau đó phải được tổ chức

lại theo kiểu phân cấp hơn, chẳng hạn như cách tiếp cận của nhóm lập trình viên trưởng được mô tả

trong Phần 4.3.

4.3 Phương pháp tiếp cận nhóm lập trình viên trưởng cổ điển

Hãy xem xét nhóm sáu người được minh họa trong Hình , với 15 chan giao tiếp hai người

4.2 nels. Trên thực tế, tổng số nhóm hai, ba, bốn, năm và sáu người là 57. Sự đa dạng của các kênh

liên lạc này là lý do chính khiến một nhóm sáu người được cấu trúc như trong Hình 4.2 khó có thể xảy

ra. thực hiện được 36 tháng công trong 6 tháng; nhiều giờ bị lãng phí trong các cuộc họp liên quan

đến hai hoặc nhiều thành viên trong nhóm cùng một lúc.

Bây giờ hãy xem xét nhóm sáu người được minh họa trong Hình 4.3. Một lần nữa, có sáu chương

trình, nhưng bây giờ chỉ có năm dòng giao tiếp. Đây là khái niệm cơ bản đằng sau cái mà ngày nay được

.Một
gọi là nhóm lập trình viên trưởng [1975], người đã rút ý tưởng
ra phép loạiliên
suy quan đã bác
về một đượcsĩđưa ra thuật
phẫu bởi Brooks

trưởng chỉ đạo một ca phẫu thuật. Bác sĩ phẫu thuật được hỗ trợ bởi các bác sĩ phẫu thuật khác, bác

sĩ gây mê và nhiều y tá. Ngoài ra, khi

Machine Translated by Google

Chương 4 Đội 111

HÌNH 4.2
Đường dẫn giao

tiếp giữa sáu

chuyên gia phần

mềm.

HÌNH 4.3 Lập

thư ký lập trình Lập
Cấu trúc của
trình viên trưởng trình viên sao lưu
một thủ lĩnh cổ điển

đội ngũ lập

trình viên.

lập trình viên lập trình viên lập trình viên

cần thiết, nhóm sử dụng các chuyên gia trong các lĩnh vực khác, chẳng hạn như bác sĩ tim mạch hoặc bác sĩ

thận. Sự tương tự này làm nổi bật hai khía cạnh chính của một nhóm lập trình viên trưởng. Thứ nhất là

chuyên môn hóa : Mỗi thành viên trong nhóm chỉ thực hiện những nhiệm vụ mà họ đã được đào tạo.

Khía cạnh thứ hai là hệ thống phân cấp : Bác sĩ phẫu thuật trưởng chỉ đạo hành động của tất cả các thành

viên khác trong nhóm và chịu trách nhiệm về mọi khía cạnh của ca phẫu thuật.

Khái niệm trưởng nhóm lập trình viên được chính thức hóa bởi Mills [Baker, 1972]. Một nhóm lập trình

viên trưởng cổ điển, như được mô tả bởi Baker khoảng 40 năm trước, được thể hiện trong Hình 4.3.

Nó bao gồm lập trình viên trưởng, người được hỗ trợ bởi lập trình viên dự phòng, thư ký lập trình và từ

một đến ba lập trình viên. Khi cần thiết, nhóm được hỗ trợ bởi các chuyên gia trong các lĩnh vực khác,

chẳng hạn như các vấn đề pháp lý hoặc tài chính, hoặc các câu lệnh ngôn ngữ kiểm soát công việc (JCL) được

sử dụng để đưa ra các lệnh của hệ điều hành cho các máy tính lớn của thời đại đó. Lập trình viên trưởng

vừa là một nhà quản lý thành công vừa là một lập trình viên có kỹ năng cao, người đã thiết kế kiến trúc

và bất kỳ phần quan trọng hoặc phức tạp nào của mã. Các thành viên khác trong nhóm làm việc trên thiết kế

chi tiết và mã hóa, dưới sự chỉ đạo của lập trình viên trưởng. Như thể hiện trong Hình 4.3, có sự tồn tại

, không
giữa các lập trình viên; tất cả các vấn đề về giao diện đều do lập trình viên trưởngđường dâyCuối
xử lý. liêncùng,
lạc lập

trình viên trưởng xem xét công việc của các thành viên khác trong nhóm, bởi vì lập trình viên trưởng chịu

trách nhiệm cá nhân cho mọi dòng mã.

Vị trí lập trình viên dự phòng chỉ cần thiết vì trưởng lập trình viên là con người và do đó có thể bị

ốm, ngã xe buýt hoặc thay đổi công việc. Vì thế,

Machine Translated by Google

112 Phần A Khái niệm Công nghệ Phần mềm

lập trình viên dự phòng phải có năng lực như lập trình viên trưởng về mọi mặt và phải biết nhiều về dự án

như lập trình viên trưởng. Ngoài ra, để lập trình viên trưởng rảnh tay tập trung vào thiết kế kiến trúc,

lập trình viên dự phòng đã lập kế hoạch kiểm thử hộp đen (Phần 15.11) và các nhiệm vụ khác độc lập với

thiết kế

quá trình.

Từ thư ký có một số ý nghĩa. Thư ký có thể là người hỗ trợ giám đốc điều hành bận rộn bằng cách trả lời

điện thoại, đánh máy thư từ, v.v. Nhưng khi chúng ta nói về Ngoại trưởng Mỹ hay Ngoại trưởng Anh, chúng ta

đề cập đến một trong những thành viên cao cấp nhất của Nội các. Thư ký lập trình không phải là một trợ lý

văn thư bán thời gian mà là một thành viên trung tâm có tay nghề cao, được trả lương cao của một nhóm lập

trình viên trưởng. Thư ký lập trình chịu trách nhiệm duy trì thư viện sản xuất dự án, tài liệu của dự án.

Điều này bao gồm danh sách mã nguồn, JCL và dữ liệu thử nghiệm. Các lập trình viên đã giao mã nguồn của họ

cho thư ký, người chịu trách nhiệm chuyển đổi sang dạng máy có thể đọc được, biên dịch, liên kết, tải, thực

thi và chạy các trường hợp thử nghiệm. Do đó, các lập trình viên không làm gì khác ngoài lập trình. Tất cả

các khía cạnh khác của công việc của họ đã được xử lý bởi thư ký lập trình. (Bởi vì thư ký chương trình duy

trì thư viện sản xuất dự án, một số tổ chức đã sử dụng chức danh thủ thư .)

Hãy nhớ lại rằng những gì được mô tả ở đây là những ý tưởng ban đầu của Mills và Baker, có từ năm 1971,

khi các phím bấm vẫn còn được sử dụng rộng rãi. Mã hóa không còn được thực hiện theo cách đó. Các nhà ngữ

pháp chuyên nghiệp hiện có thiết bị đầu cuối hoặc máy trạm riêng để họ nhập mã, chỉnh sửa mã, kiểm tra mã,

v.v. Phiên bản hiện đại của nhóm lập trình viên trưởng cổ điển được mô tả trong Phần 4.4.

4.3.1 Dự án The New York Times Khái niệm trưởng nhóm

lập trình viên lần đầu tiên được IBM sử dụng vào năm 1971 để tự động hóa tệp clip ping (“nhà xác”) của tờ

The New York Times. Tập tin trích đoạn chứa các phần tóm tắt và các bài báo đầy đủ từ The New York Times và

các ấn phẩm khác. Các phóng viên và các thành viên khác của ban biên tập sử dụng ngân hàng thông tin này
như một nguồn tài liệu tham khảo.

Sự thật của dự án là đáng kinh ngạc. Ví dụ: 83.000 dòng mã (LOC) đã được triển khai trong 22 tháng theo

lịch, một nỗ lực của 11 người-năm. Sau năm đầu tiên, chỉ có hệ thống bảo trì tệp bao gồm 12.000 LOC được

triển khai. Hầu hết mã được triển khai trong 6 tháng qua. Chỉ có 21 lỗi được phát hiện trong 5 tuần đầu

nghiệm thu; chỉ có 25 lỗi nữa được phát hiện trong năm đầu tiên hoạt động. Các lập trình viên chính tính

trung bình một lỗi được phát hiện và 10.000 LOC mỗi người-năm. Hệ thống cho thuê chính của tập tin, được

giao 1 tuần sau khi mã hóa hoàn tất, đã hoạt động 20 tháng trước khi một lỗi duy nhất được phát hiện. Gần

một nửa số chương trình con, thường là 200 đến 400 dòng PL/I, một ngôn ngữ do IBM phát triển, đã đúng trong

lần biên dịch đầu tiên [Baker, 1972].

Tuy nhiên, sau thành công tuyệt vời này, không có tuyên bố nào có thể so sánh được về khái niệm trưởng

nhóm lập trình viên đã được đưa ra. Vâng, nhiều dự án thành công đã được thực hiện bằng cách sử dụng các

nhóm lập trình viên chính, nhưng các số liệu được báo cáo, mặc dù khả quan, không ấn tượng bằng những số

liệu thu được cho dự án The New York Times . Tại sao dự án The New York Times lại thành công như vậy và tại

sao các dự án khác không đạt được kết quả tương tự?

Có thể giải thích rằng đây là một dự án uy tín của IBM. Đó là thử nghiệm thực sự đầu tiên cho PL/I. Là

một tổ chức nổi tiếng với các chuyên gia phần mềm xuất sắc, IBM đã thành lập một nhóm bao gồm những người

chỉ có thể được mô tả là crème de la crème từ một bộ phận. Thứ hai,

Machine Translated by Google

Chương 4 Đội 113

hỗ trợ kỹ thuật là cực kỳ mạnh mẽ. Những người viết trình biên dịch PL/I đã sẵn sàng hỗ trợ các lập

trình viên bằng mọi cách họ có thể, và các chuyên gia JCL đã hỗ trợ ngôn ngữ kiểm soát công việc. Khả

năng giải thích thứ ba là chuyên môn của lập trình viên trưởng, F. Terry Baker. Anh ấy là người mà

bây giờ được gọi là một siêu lập trình viên , một lập trình viên
vớicómột
kếtlập
quảtrình
gấp bốn
viênhoặc
giỏinăm
trung
lần bình.
so
Ngoài ra, Baker là một nhà quản lý và lãnh đạo xuất sắc, và kỹ năng, sự nhiệt tình và cá tính của anh

ấy có thể là những lý do dẫn đến sự thành công của dự án.

Nếu lập trình viên trưởng có năng lực, thì tổ chức nhóm lập trình viên trưởng hoạt động tốt. Mặc

dù thành công đáng chú ý của dự án The New York Times không được lặp lại, nhiều dự án thành công đã

sử dụng các biến thể của cách tiếp cận lập trình viên trưởng. Lý do cho các biến thể cụm từ của cách

tiếp cận là nhóm lập trình viên chính cổ điển như được mô tả trong [Baker, 1972] là không thực tế

theo nhiều cách.

4.3.2 Tính không thực tế của phương pháp tiếp cận nhóm lập trình
viên trưởng cổ điển
Hãy xem xét lập trình viên trưởng, sự kết hợp giữa một lập trình viên có tay nghề cao và người quản

lý thành công. Những cá nhân như vậy rất khó tìm do thiếu các lập trình viên có kỹ năng cao cũng như

thiếu các nhà quản lý thành công; và mô tả công việc của một lập trình viên trưởng yêu cầu cả hai khả

năng. Ngoài ra, những phẩm chất cần thiết để trở thành một lập trình viên có tay nghề cao dường như

khác với những phẩm chất cần thiết để trở thành một nhà quản lý thành công; do đó, cơ hội tìm được

một lập trình viên trưởng là rất nhỏ.

Nếu lập trình viên trưởng khó kiếm thì lập trình viên dự phòng hiếm như răng gà.

Xét cho cùng, lập trình viên dự phòng được kỳ vọng sẽ giỏi như lập trình viên trưởng nhưng phải ngồi

ở ghế sau và nhận mức lương thấp hơn trong khi chờ đợi điều gì đó xảy ra với lập trình viên trưởng.

Rất ít lập trình viên hàng đầu hoặc nhà quản lý hàng đầu sẽ chấp nhận vai trò như vậy.

Một thư ký lập trình cũng khó tìm. Các chuyên gia phần mềm nổi tiếng là ác cảm với công việc giấy

tờ, và thư ký lập trình được cho là sẽ không làm gì ngoài công việc giấy tờ cả ngày.

Do đó, các nhóm lập trình viên trưởng, ít nhất là như đề xuất của Baker, là không thực tế để thực

hiện. Các nhóm dân chủ cũng được chứng minh là không thực tế nhưng vì những lý do khác nhau.

Hơn nữa, dường như không có kỹ thuật nào có thể xử lý các sản phẩm yêu cầu 20, chưa nói đến 120, lập

trình viên cho quy trình triển khai. Điều cần thiết là một cách tổ chức các nhóm lập trình sử dụng sức

mạnh của các nhóm dân chủ và các nhóm lập trình viên chính và có thể được mở rộng để triển khai các

sản phẩm lớn hơn.

4.4 Ngoài lập trình viên trưởng và các nhóm dân chủ
Các nhóm dân chủ có một điểm mạnh chính: thái độ tích cực trong việc tìm ra lỗi. Một số tổ chức sử

dụng các nhóm lập trình viên chính kết hợp với đánh giá mã (Phần 6.2), tạo ra một cạm bẫy tiềm ẩn.

Lập trình viên trưởng chịu trách nhiệm cá nhân cho mọi dòng mã và do đó, phải có mặt trong tất cả các

lần xem xét mã. Tuy nhiên, lập trình viên trưởng cũng là người quản lý và, như đã giải thích trong

Chương 6, đối với bất kỳ hình thức đánh giá hiệu suất nào. Vì vậy, bởi,vì
đánh
lậpgiá không
trình nêntrưởng
viên được sử dụng
cũng

là người quản lý chịu trách nhiệm đánh giá chính các thành viên trong nhóm, nên việc cá nhân đó có

mặt tại buổi đánh giá mã là điều không nên.

Machine Translated by Google

114 Phần A Khái niệm Công nghệ Phần mềm

HÌNH 4.4 Cấu

Đội trưởng
trúc của một nhóm
giám đốc
nhóm lập

trình hiện
đại.

lập trình viên lập trình viên lập trình viên

quản lý kỹ thuật
quản lý phi kỹ thuật

Cách thoát khỏi mâu thuẫn này là loại bỏ phần lớn vai trò quản lý khỏi lập trình viên
trưởng. Rốt cuộc, khó khăn trong việc tìm kiếm một cá nhân vừa là một lập trình viên có tay
nghề cao vừa là một nhà quản lý thành công đã được chỉ ra. Thay vào đó, lập trình viên trưởng
nên được thay thế bởi hai cá nhân: một trưởng nhóm phụ trách các khía cạnh kỹ thuật của các
hoạt động của nhóm và một người quản lý nhóm chịu trách nhiệm về tất cả các quyết định quản lý
phi kỹ thuật. Cấu trúc của nhóm kết quả được thể hiện trong Hình 4.4 . Điều quan trọng là
phải nhận ra rằng cơ cấu tổ chức này không vi phạm nguyên tắc quản lý cơ bản là không nhân
viên nào được báo cáo cho nhiều hơn một người quản lý. Các lĩnh vực trách nhiệm được phân định
rõ ràng. Tổ trưởng chỉ chịu trách nhiệm quản lý kỹ thuật. Do đó, các vấn đề về ngân sách và
pháp lý không được xử lý bởi trưởng nhóm cũng như việc đánh giá hiệu suất. Mặt khác, trưởng
nhóm chịu trách nhiệm duy nhất về các vấn đề kỹ thuật.
Do đó, người quản lý nhóm không có quyền hứa hẹn, chẳng hạn như sản phẩm sẽ được giao trong
vòng 4 tuần; những lời hứa kiểu đó phải được thực hiện bởi trưởng nhóm. Trưởng nhóm đương nhiên
tham gia vào tất cả các đánh giá mã; xét cho cùng, anh ấy hoặc cô ấy chịu trách nhiệm cá nhân
về mọi khía cạnh của mã. Đồng thời, người quản lý nhóm không được phép đánh giá, bởi vì đánh
giá hiệu suất của lập trình viên là một chức năng của người quản lý nhóm. Thay vào đó, người
quản lý nhóm thu thập kiến thức về các kỹ năng kỹ thuật của từng lập trình viên trong nhóm
trong các cuộc họp nhóm được lên lịch thường xuyên.
Trước khi bắt đầu triển khai, điều quan trọng là phải phân định rõ ràng những lĩnh vực có
vẻ là trách nhiệm của cả người quản lý nhóm và trưởng nhóm. Ví dụ, xem xét vấn đề nghỉ phép
hàng năm. Tình huống có thể phát sinh là người quản lý nhóm chấp thuận đơn xin nghỉ phép vì
nghỉ phép là một vấn đề phi kỹ thuật, chỉ để thấy đơn bị trưởng nhóm phủ quyết vì thời hạn sắp
đến. Giải pháp cho vấn đề này và các vấn đề liên quan là quản lý cấp cao hơn phải xây dựng
chính sách liên quan đến các lĩnh vực mà cả người quản lý nhóm và trưởng nhóm đều coi là trách
nhiệm của họ.
Còn những dự án lớn hơn thì sao? Cách tiếp cận này có thể được nhân rộng như trong Hình 4.5 ,
trong đó thể hiện cơ cấu tổ chức quản lý kỹ thuật; phía phi kỹ thuật cũng được tổ chức tương
tự. Việc triển khai toàn bộ sản phẩm dưới sự chỉ đạo của trưởng dự án. Các lập trình viên báo
cáo với trưởng nhóm của họ và trưởng nhóm báo cáo với trưởng dự án. Đối với các sản phẩm thậm
chí còn lớn hơn, các cấp độ bổ sung có thể được thêm vào hệ thống phân cấp.
Một cách khác để tận dụng những đặc điểm tốt nhất của cả nhóm dân chủ và trưởng nhóm lập
trình viên là phi tập trung hóa quy trình ra quyết định khi thích hợp. Kết quả là các kênh
giao tiếp được thể hiện trong Hình 4.6 . Đề án này là hữu ích cho các loại
Machine Translated by Google

HÌNH 4.5 Cơ cấu tổ chức quản lý kỹ thuật cho các dự án lớn hơn.

Lãnh
đạo dự án

trưởng trưởng trưởng

nhóm nhóm nhóm

lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên

quản lý kỹ thuật

115
Machine Translated by Google

116

HÌNH 4.6 Phiên bản ra quyết định phi tập trung của tổ chức nhóm Hình 4.5 thể hiện các kênh liên lạc để quản lý kỹ thuật.

Lãnh
đạo dự án

trưởng trưởng trưởng

nhóm nhóm nhóm

lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên lập trình viên

quản lý kỹ thuật
Machine Translated by Google

Chương 4 Đội 117

những vấn đề mà cách tiếp cận dân chủ là tốt, nghĩa là trong môi trường nghiên cứu hoặc bất cứ khi
nào một vấn đề khó đòi hỏi tác động hiệp lực của sự tương tác nhóm để giải quyết nó. Dù đã phân cấp
nhưng mũi tên từ cấp này đến cấp kia vẫn chỉ xuống phường; cho phép các lập trình viên ra lệnh cho
trưởng dự án chỉ có thể dẫn đến sự hỗn loạn.

4.5 Đồng bộ hóa và ổn định nhóm

Một cách tiếp cận khác để tổ chức nhóm là nhóm đồng bộ hóa và ổn định được sử dụng bởi Microsoft
[Cusumano và Selby, 1997]. Microsoft xây dựng các sản phẩm lớn; ví dụ, Windows 2000 bao gồm hơn 30
triệu dòng mã, được xây dựng bởi hơn 3000 người lập trình và người thử nghiệm, sử dụng lại phần lớn
Windows NT 4.0 [Business Week Online, 1999]. Tổ chức nhóm là một khía cạnh quan trọng của việc xây
dựng thành công một sản phẩm có kích thước này.
Mô hình vòng đời đồng bộ hóa và ổn định được mô tả trong Phần 2.9.6. Thành công của mô hình này
phần lớn là kết quả của cách tổ chức các nhóm. Mỗi trong số ba hoặc bốn bản dựng tuần tự của mô
hình đồng bộ hóa và ổn định được xây dựng bởi một số nhóm nhỏ song song do người quản lý lãnh đạo
và bao gồm từ ba đến tám nhà phát triển cùng với ba đến tám người thử nghiệm làm việc trực tiếp với
nhau với các nhà phát triển.
Nhóm được cung cấp các đặc điểm kỹ thuật của nhiệm vụ tổng thể của nó; các thành viên trong nhóm cá

nhân sau đó được tự do thiết kế và thực hiện các phần của nhiệm vụ đó theo ý muốn. Lý do khiến điều
này không nhanh chóng biến thành hỗn loạn do tin tặc gây ra là bước đồng bộ hóa được thực hiện hàng
ngày: Các thành phần hoàn thành một phần được kiểm tra và sửa lỗi hàng ngày. Theo đó, mặc dù sự
sáng tạo và tự chủ của cá nhân được nuôi dưỡng, nhưng các thành phần riêng lẻ luôn làm việc cùng
nhau.
Điểm mạnh của cách tiếp cận này là, một mặt, các lập trình viên cá nhân được khuyến khích sáng
tạo và đổi mới, một đặc điểm của một nhóm dân chủ. Mặt khác, bước đồng bộ hóa hàng ngày đảm bảo
rằng hàng trăm nhà phát triển cùng làm việc hướng tới một mục tiêu chung mà không yêu cầu đặc tính
liên lạc và phối hợp của một nhóm lập trình viên trưởng ( Hình 4.3 ).

Các nhà phát triển của Microsoft phải tuân theo rất ít quy tắc, nhưng một trong số đó là họ phải
tuân thủ nghiêm ngặt thời gian quy định để nhập mã của họ vào cơ sở dữ liệu sản phẩm để đồng bộ hóa
vào ngày hôm đó. Cusumano và Selby [1997] so sánh điều này với việc nói với trẻ em rằng chúng có
thể làm những gì chúng thích cả ngày nhưng phải đi ngủ trước 9 giờ tối Một quy tắc khác là, nếu mã
của nhà phát triển ngăn không cho sản phẩm được biên dịch cho quá trình đồng bộ hóa của ngày hôm
đó, sự cố phải được khắc phục ngay lập tức để những người còn lại trong nhóm có thể kiểm tra và gỡ
lỗi công việc của ngày hôm đó.
Việc sử dụng mô hình đồng bộ hóa và ổn định và tổ chức nhóm có liên quan có đảm bảo rằng mọi tổ
chức phần mềm khác sẽ thành công như Microsoft không? Điều này là cực kỳ khó xảy ra. Microsoft,
Inc., không chỉ là mô hình đồng bộ hóa và ổn định.
Đây là một tổ chức bao gồm một tập hợp các nhà quản lý và nhà phát triển phần mềm tài năng cao với
đặc tính nhóm đã phát triển. Chỉ sử dụng mô hình đồng bộ hóa và ổn định không biến một tổ chức
thành một Microsoft khác một cách kỳ diệu. Đồng thời, việc sử dụng nhiều tính năng của mô hình
trong các tổ chức khác có thể dẫn đến cải tiến quy trình. Mặt khác, có ý kiến cho rằng mô hình đồng
bộ hóa và ổn định chỉ đơn giản là một cách cho phép một nhóm tin tặc phát triển các sản phẩm lớn và
thành công của Microsoft là do hoạt động tiếp thị tuyệt vời hơn là do chất lượng phần mềm.
Machine Translated by Google

118 Phần A Khái niệm Công nghệ Phần mềm

4.6 Nhóm cho các quy trình linh hoạt

Phần 2.9.5 đưa ra tổng quan về các quy trình nhanh nhẹn [Beck và cộng sự, 2001]. Trong phần này, chúng tôi

mô tả cách các nhóm được tổ chức khi sử dụng các quy trình linh hoạt.

Một tính năng hơi khác thường của các quy trình nhanh là tất cả mã được triển khai bởi một nhóm gồm hai

lập trình viên dùng chung một máy tính; điều này được gọi là lập trình theo cặp [Williams, Kessler,

Cunningham, và Jeffries, 2000]. Những lý do cho phương pháp này bao gồm:

• Như đã giải thích trong Phần 2.9.5, các lập trình viên cặp đôi trước tiên sẽ soạn thảo các ca kiểm thử và

sau đó triển khai đoạn mã đó ( nhiệm vụ ). Như đã giải thích trong Phần 6.6, lập trình viên rất không nên

kiểm tra mã của chính mình. Các quy trình linh hoạt khắc phục vấn đề này bằng cách để một lập trình viên

theo cặp trong nhóm soạn thảo các trường hợp thử nghiệm cho một nhiệm vụ và lập trình viên theo cặp khác

cùng triển khai mã bằng cách sử dụng các trường hợp thử nghiệm đó.

• Trong một mô hình vòng đời thông thường hơn, khi một nhà phát triển rời khỏi dự án, tất cả kiến thức mà

nhà phát triển đó tích lũy được cũng rời đi. Cụ thể, phần mềm mà nhà phát triển đó đang làm việc có thể

chưa được ghi lại và có thể phải được phát triển lại từ đầu. Ngược lại, nếu một thành viên của nhóm lập

trình cặp rời đi, người kia có đủ kiến thức để tiếp tục làm việc trên cùng một phần của phần mềm với một

lập trình viên cặp mới. Hơn nữa, sự hiện diện của các trường hợp thử nghiệm hỗ trợ trong việc làm nổi bật

một lỗi, nếu nhóm mới vô tình làm hỏng phần mềm bằng cách thực hiện một sửa đổi sai lầm.

• Làm việc chặt chẽ theo cặp cho phép một chuyên gia phần mềm ít kinh nghiệm hơn có được

kỹ năng của thành viên có kinh nghiệm hơn trong nhóm.

• Như đã đề cập trong Phần 2.9.5, tất cả các máy tính được sử dụng bởi các nhóm khác nhau được đặt cùng nhau

ở giữa một căn phòng lớn. Điều này thúc đẩy quyền sở hữu mã của nhóm, một tính năng tích cực của các nhóm

vô ngã (Phần 4.2).

Vì vậy, mặc dù ý tưởng về hai lập trình viên làm việc cùng nhau trên cùng một máy tính

có vẻ hơi bất thường, thực hành có thể có lợi thế khác biệt.

Một thí nghiệm thú vị về lập trình theo cặp được mô tả trong [Arisholm, Gallis, Dybå, and Sjøberg, 2007].

Tổng cộng có 295 lập trình viên chuyên nghiệp (99 cá nhân và 98 cặp) đã được thuê để tham gia vào cuộc thử

nghiệm kéo dài một ngày được tiến hành cẩn thận về lập trình cặp.

Các đối tượng được yêu cầu thực hiện một số tác vụ bảo trì trên hai sản phẩm phần mềm Java, một đơn giản và

một phức tạp. Cặp lập trình viên cần nỗ lực hơn 84% để thực hiện các nhiệm vụ một cách chính xác. Dựa trên

kết quả này, một số kỹ sư phần mềm có thể xem xét lại việc sử dụng lập trình cặp và do đó, các quy trình

nhanh nhẹn.

Hơn nữa, như đã nêu trong Phần 2.9.5, một phân tích của 15 nghiên cứu đã công bố đã so sánh hiệu quả của

lập trình cá nhân và lập trình theo cặp [Dybå et al., 2007] và đi đến kết luận rằng nó phụ thuộc vào cả

chuyên môn của lập trình viên và độ phức tạp của hệ thống và các nhiệm vụ cụ thể cần giải quyết. Rõ ràng,

cần tiến hành nhiều nghiên cứu hơn, tốt nhất là thực hiện trên các mẫu lớn gồm các lập trình viên chuyên

nghiệp trong lĩnh vực này.

4.7 Nhóm lập trình mã nguồn mở

Điều đáng ngạc nhiên là bất kỳ dự án nguồn mở nào cũng thành công, chưa nói đến việc một số sản phẩm phần

mềm thành công nhất từng được phát triển đã sử dụng mô hình vòng đời nguồn mở.

Xét cho cùng, các dự án nguồn mở thường được điều hành bởi các nhóm tình nguyện viên không được trả lương. Họ
Machine Translated by Google

Chương 4 Đội 119

giao tiếp không đồng bộ (nghĩa là qua e-mail), không có cuộc họp nhóm và không có người quản lý— tính

không chính thức ngự trị ở mọi khía cạnh. Hơn nữa, không có thông số kỹ thuật hoặc thiết kế nào tồn tại;

trên thực tế, tài liệu dưới bất kỳ hình thức nào là cực kỳ hiếm, ngay cả trong các dự án trưởng thành.

Nhưng bất chấp những trở ngại gần như không thể vượt qua này, một số nhỏ các dự án mã nguồn mở như Linux

và Apache đã đạt được mức độ thành công cao nhất.

Các cá nhân tình nguyện tham gia vào một dự án nguồn mở vì hai lý do chính: vì

niềm vui tuyệt đối khi hoàn thành một nhiệm vụ đáng giá, hoặc cho trải nghiệm học tập.

• Để thu hút các tình nguyện viên vào một dự án nguồn mở và giữ cho họ quan tâm, điều cần thiết là họ

luôn xem dự án là “đáng giá”. Các cá nhân không có khả năng dành một phần đáng kể thời gian rảnh rỗi

của họ cho một dự án trừ khi họ thực sự tin rằng dự án sẽ thành công và sản phẩm sẽ được sử dụng

rộng rãi. Những người tham gia sẽ bắt đầu trôi đi nếu họ bắt đầu coi dự án là vô ích.

• Liên quan đến lý do thứ hai, nhiều chuyên gia phần mềm tham gia dự án nguồn mở để đạt được kỹ năng về

công nghệ mới đối với họ, chẳng hạn như ngôn ngữ lập trình hiện đại hoặc hệ điều hành mà họ không

quen thuộc. Sau đó, họ có thể tận dụng kiến thức thu được để được thăng chức trong chính tổ chức của

mình hoặc có được vị trí tốt hơn trong tổ chức khác. Xét cho cùng, các nhà tuyển dụng thường coi

kinh nghiệm thu được khi làm việc trong một dự án mã nguồn mở lớn, thành công là đáng mong đợi hơn

là đạt được các bằng cấp học thuật bổ sung. Ngược lại, chẳng ích gì khi dành nhiều tháng làm việc

chăm chỉ cho một dự án mà cuối cùng lại thất bại.

Nói cách khác, trừ khi một dự án luôn được coi là người chiến thắng, nó sẽ không thu hút và giữ chân

các tình nguyện viên làm việc trong dự án đó. Hơn nữa, các thành viên của nhóm nguồn mở phải luôn cảm

thấy rằng họ đang đóng góp. Vì tất cả những lý do này, điều cốt yếu là cá nhân chủ chốt đằng sau một dự

án nguồn mở phải là một người thúc đẩy tuyệt vời.

Trừ khi đây là trường hợp, dự án chắc chắn sẽ thất bại.

Một điều kiện tiên quyết khác để phát triển nguồn mở thành công là kỹ năng của các thành viên trong

nhóm. Như đã giải thích chi tiết trong Phần 9.2, người ta đã quan sát thấy sự khác biệt lớn về trình độ

kỹ năng giữa các lập trình viên. Ghi nhớ những trở ngại đối với việc sản xuất phần mềm nguồn mở thành

công được liệt kê trong đoạn đầu tiên của phần này, hầu như không có cách nào mà một dự án nguồn mở có

thể thành công trừ khi các thành viên của nhóm cốt lõi (Phần 2.9.4) là những cá nhân tầm cỡ hàng đầu với

những kỹ năng được mài giũa kỹ lưỡng ở cấp độ cao nhất. Những cá nhân đẳng cấp hàng đầu như vậy sẽ phát

triển mạnh trong hầu hết mọi môi trường, kể cả môi trường phi cấu trúc như nhóm nguồn mở.

Nói cách khác, một dự án mã nguồn mở thành công do bản chất của sản phẩm mục tiêu, tính cách của kẻ

chủ mưu và tài năng của các thành viên trong nhóm nòng cốt. Cách mà một nhóm nguồn mở thành công được

tổ chức về cơ bản là không liên quan.

4.8 Mô hình trưởng thành năng lực con người

Mô hình trưởng thành năng lực con người (P–CMM) mô tả các phương pháp hay nhất để quản lý và phát triển

lực lượng lao động của một tổ chức [Curtis, Hefl ey, và Miller, 2002]. Như với mô hình trưởng thành về

năng lực phần mềm, SW–CMM (Phần 3.13), một tổ chức tiến triển qua năm cấp độ trưởng thành với mục đích

liên tục cải thiện các kỹ năng cá nhân và tạo ra các nhóm hiệu quả.

Mỗi cấp độ trưởng thành đều có các khu vực quy trình chính (KPA) riêng , mỗi trong số đó cần được

giải quyết thỏa đáng trước khi một tổ chức có thể được coi là đã đạt được sự trưởng thành đó
Machine Translated by Google

120 Phần A Khái niệm Công nghệ Phần mềm

mức độ. Ví dụ: đối với cấp độ 2, cấp độ được quản lý, KPAs là nhân sự, giao tiếp và
phối hợp, môi trường làm việc, quản lý hiệu suất, đào tạo và phát triển, và lương
thưởng. Ngược lại, KPA cho cấp độ 5, cấp độ tối ưu hóa, là cải tiến năng lực liên tục,
liên kết hiệu quả hoạt động của tổ chức và đổi mới lực lượng lao động liên tục.
SW–CMM là một khuôn khổ để cải thiện quy trình phần mềm của tổ chức—không khuyến
nghị quy trình hoặc phương pháp cụ thể nào. Theo cách tương tự, P–CMM là một công việc
khung để cải thiện quy trình quản lý và phát triển lực lượng lao động của tổ chức và
không đưa ra cách tiếp cận cụ thể nào đối với tổ chức nhóm.

4.9 Chọn một tổ chức nhóm phù hợp

Hình 4.7 cũng cho thấy phần so sánh về các loại hình tổ chức nhóm khác nhau , cái mà
trong đó mỗi tổ chức nhóm được mô tả. Thật không may, không có giải pháp nào giải
quyết được vấn đề tổ chức nhóm lập trình hay nói rộng ra là vấn đề

HÌNH 4.7
tổ chức đội điểm mạnh Những điểm yếu
So sánh các
phương pháp Các nhóm dân chủ (Mục Mã chất lượng cao là Nhân viên có kinh nghiệm bực
vào đội 4.2) kết quả của thái độ tích bội mã của họ được đánh giá bởi

tổ chức và cực tìm lỗi người mới bắt đầu

bộ phận Đặc biệt tốt với các vấn Không thể áp đặt bên
đề khó khăn ngoài
trong chương
Trưởng nhóm lập
này, trong đó mỗi Thành công lớn của The New không thực tế

mô tả. trình viên cổ điển Dự án thời báo York

(Phần 4.3)

Các nhóm lập Nhiều thành công Không thành công nào sánh được với The
trình viên trưởng đã Dự án Thời báo New York
được sửa đổi (Phần 4.3.1)

phân cấp hiện đại Cơ cấu quản lý nhóm/trưởng nhóm Vấn đề có thể phát sinh trừ khi

nhóm lập trình (Phần loại bỏ nhu cầu về lập trình các lĩnh vực trách nhiệm
4.4) viên trưởng của người quản lý nhóm và
tăng quy mô trưởng nhóm được phân định rõ
Hỗ trợ phân quyền khi cần ràng
thiết

Đồng bộ hóa và ổn khuyến khích sự sáng tạo Không có bằng chứng nào cho thấy

định nhóm (Phần Đảm bảo rằng một số lượng lớn các phương pháp này có thể được sử

4.5) nhà phát triển có thể làm việc dụng bên ngoài Microsoft

hướng tới một mục tiêu chung

Nhóm quy trình linh Các lập trình viên không kiểm Vẫn còn quá ít bằng chứng về hiệu quả
hoạt (Phần 4.6) tra mã của riêng họ

Kiến thức không bị mất nếu một

lập trình viên rời đi
Các lập trình viên ít kinh nghiệm có thể
học hỏi từ những người khác

Nhóm sở hữu mã

Nhóm nguồn mở (Phần Một vài dự án cực kỳ thành công Áp dụng hẹp
4.7) Phải được dẫn dắt bởi một động
lực tuyệt vời

Yêu cầu những người tham gia tầm cỡ hàng đầu

Machine Translated by Google

Chương 4 Đội 121

vấn đề tổ chức các nhóm cho tất cả các luồng công việc khác. Cách tối ưu để tổ chức
một nhóm phụ thuộc vào sản phẩm được xây dựng, kinh nghiệm trước đây với các cấu trúc
nhóm khác nhau và quan trọng nhất là văn hóa của tổ chức. Ví dụ, nếu quản lý cấp cao
không thoải mái với việc ra quyết định phi tập trung, thì nó sẽ không được thực hiện.

Trên thực tế, hầu hết các đội hiện được tổ chức như mô tả trong Phần 4.4. Đó là,
một số biến thể của nhóm lập trình viên trưởng là thông lệ.
Không có nhiều nghiên cứu được thực hiện về tổ chức nhóm phát triển phần mềm và
nhiều nguyên tắc được chấp nhận rộng rãi dựa trên nghiên cứu về động lực nhóm nói
chung chứ không phải nhóm phát triển phần mềm. Ngay cả khi các nghiên cứu về các nhóm
phần mềm đã được tiến hành, cỡ mẫu nhìn chung vẫn còn nhỏ, vì vậy kết quả không thuyết
phục.
Cho đến khi thu được kết quả thử nghiệm về tổ chức nhóm trong ngành công nghiệp
phần mềm, sẽ không dễ để xác định cách tổ chức nhóm tối ưu cho một sản phẩm cụ thể.

chương Vấn đề tổ chức nhóm (Phần 4.1) được tiếp cận bằng cách xem xét đầu tiên các nhóm dân chủ (Phần 4.2)
Ôn tập và các nhóm lập trình viên trưởng (Phần 4.3). Sự thành công của dự án The New York Times (Phần 4.3.1)
tương phản với tính phi thực tế của các nhóm lập trình viên trưởng cổ điển (Phần 4.3.2). Một tổ chức
nhóm sử dụng điểm mạnh của cả hai cách tiếp cận được đề xuất trong Phần 4.4. Các nhóm đồng bộ hóa và
ổn định (do Microsoft sử dụng) được mô tả trong Phần 4.5.
Các nhóm cho các quy trình linh hoạt được thảo luận trong Phần 4.6 và cho phần mềm nguồn mở trong Phần
4.7. Mô hình trưởng thành năng lực con người (P–CMM) được mô tả trong Phần 4.8. Cuối cùng, Phần 4.9 mô
tả các yếu tố liên quan đến việc lựa chọn tổ chức nhóm tối ưu cho một dự án nhất định.

Vì Các tác phẩm kinh điển về tổ chức nhóm là [Weinberg, 1971], [Baker, 1972] và [Brooks, 1975].
Hơn nữa Những cuốn sách mới hơn về chủ đề này bao gồm [DeMarco và Lister, 1987] và [Cusumano và Selby, 1995].
[Mackey, 1999] đã tìm thấy một mô tả thú vị về cách thức tương tác nhóm phát triển. Chương 11 của
Đọc
[Royce, 1998] chứa thông tin hữu ích về vai trò của các thành viên trong nhóm. Một cách tiếp cận đầy
hứa hẹn là sử dụng phân tích loại tính cách trong việc lựa chọn các thành viên trong nhóm; xem, ví dụ,
[Gorla và Lam, 2004].
Các nhóm đồng bộ hóa và ổn định được phác thảo trong [Cusumano và Selby, 1997] và được mô tả chi
tiết trong [Cusumano và Selby, 1995]. Các nhóm lập trình cực đoan được mô tả trong [Beck, 2000].
Số tháng 5–tháng 6 năm 2003 của IEEE Software bao gồm một số bài viết về lập trình cực đoan, đặc biệt
là [Reifer, 2003] và [Murru, Deias, và Mugheddue, 2003].
Quan điểm về quy trình linh hoạt được thể hiện trong [Boehm, 2002] và [DeMarco và Boehm, 2002], và
trong số tháng 5–tháng 6 năm 2005 của IEEE Software . Williams, Kessler, Cunningham và Jeffries [2000]
mô tả một thử nghiệm về lập trình theo cặp, một thành phần của lập trình cực đoan. Kỹ năng ngữ pháp
theo cặp được đánh giá trong [Drobka, Noftz, và Raghu, 2004], [Flor, 2006], và [Lui, Chan, và Nosek,
2008]. Các kết quả của [Arisholm, Gallis, Dybå, và Sjøberg, 2007] liên quan đến những lợi ích có thể
có của lập trình cặp nên được nghiên cứu chi tiết.
P–CMM được mô tả trong [Curtis, Hefl ey, và Miller, 2002]. Cặp phân phối toàn cầu (từ xa)
lập trình được đưa ra trong [Flor, 2006].
Machine Translated by Google

122 Phần A Khái niệm Công nghệ Phần mềm

Điều khoản quan trọng lập trình dự phòng 111 hệ thống phân chuyên ngành 111 siêu
Luật Brooks 108 lập cấp 111 khu vực quy trình chính lập trình viên 113 nhiệm

trình viên trưởng 111 (KPA) 119 thủ thư 112 lập trình vụ 118

trưởng nhóm lập trình viên 110 cặp 118 lập trình viên 112 thư đội 107

nhóm dân chủ 109 lập trình vô ký lập trình 112 đội trưởng 114 đội

ngã 109 trưởng 114

Các vấn đề 4.1 Bạn sẽ tổ chức một nhóm như thế nào để phát triển một dự án trả lương? Gia i thich câu tra lơi cu a ba n.

4.2 Bạn sẽ tổ chức một nhóm phát triển phần mềm liên lạc quân sự tối tân như thế nào? Gia i thich câu tra lơi

cu a ba n.

4.3 Định luật Brooks của Bang. Giải thích tại sao nó giữ.

4.4 Bạn vừa thành lập một công ty phần mềm mới. Tất cả nhân viên của bạn đều là sinh viên mới tốt nghiệp đại học;

đây là công việc lập trình đầu tiên của họ. Có thể triển khai các nhóm dân chủ trong tổ chức của bạn không, và

nếu có thì bằng cách nào?

4.5 Nhóm lập trình sinh viên được tổ chức như một nhóm dân chủ. Điều gì có thể được suy luận về
học sinh trong đội?

4.6 Nhóm lập trình sinh viên được tổ chức như một nhóm lập trình trưởng. Điều gì có thể được suy ra
về các học sinh trong đội?

4.7 Để so sánh hai tổ chức nhóm khác nhau, TO 2 và

, ĐẾN 1 trong một công ty phần mềm lớn, thí

nghiệm sau đây được đề xuất. Cùng một sản phẩm phần mềm sẽ được xây dựng bởi hai nhóm khác nhau, một nhóm được

tổ chức theo TO và nhóm kia theo TO 2 . Công 1typhẩm.

ước tính rằng
Đưa ra ba mỗi nhóm
lý do tạisẽsao
mấtthử
khoảng 18 mang
nghiệm
không tháng
này là để
lại xây quả
không
kết dựngcó
thực sản
tếývà

nghĩa.

4.8 Công ty bạn sở hữu vừa tiếp quản một đối thủ cạnh tranh nhỏ hơn, và bạn phát hiện ra rằng một trong những lập

trình viên của họ là một siêu lập trình viên. Làm thế nào để bạn đảm bảo rằng cô ấy không rời đi và nhận một

công việc ở một công ty khác?

4.9 Tại sao các nhóm quy trình nhanh phải dùng chung máy tính?

4.10 Sự khác biệt giữa nhóm dân chủ và nhóm nguồn mở là gì?

4.11 Bạn sẽ tổ chức một nhóm mã nguồn mở như thế nào?

4.12 Bạn có muốn làm việc trong một tổ chức sử dụng các nhóm đồng bộ hóa và ổn định không? Giải thích

câu trả lời của bạn.

4.13 Tổ chức nhóm nào phù hợp với P–CMM?

4.14 Bạn là phó chủ tịch phát triển phần mềm của một công ty lớn. Bạn sẽ thực hiện như thế nào

đề cập đến P–CMM trong công ty của bạn?

4.15 (Dự án học kỳ) Kiểu tổ chức nhóm nào sẽ phù hợp để phát triển Choco

holics Sản phẩm ẩn danh được mô tả trong Phụ lục A?

4.16 (Bài đọc về Kỹ thuật phần mềm) Người hướng dẫn của bạn sẽ phân phát các bản sao của [Arisholm, Gallis, Dybå, và

Sjøberg, 2007]. Ý nghĩa của bài báo này đối với các quy trình nhanh là gì?

Người giới thiệu [Arisholm, Gallis, Dybå, và Sjøberg, 2007] E. ARISHOLM, H. GALLIS, T. DYBÅ, VÀ DIK SJØBERG, “Đánh giá lập trình cặp

dựa trên độ phức tạp của hệ thống và chuyên môn của lập trình viên,”

IEEE Transactions on Software Engineering 33 (Tháng 2 năm 2007), trang 65–86.

[Baker, 1972] FT BAKER, “Trưởng nhóm Lập trình viên Quản lý Lập trình Sản xuất,”

Tạp chí Hệ thống IBM 11 (Số 1, 1972), trang 56–73.

[Beck, 2000] K. BECK, Giải thích về lập trình cực đoan: Chấp nhận thay đổi, Addison-Wesley Long

man, Reading, MA, 2000.

Machine Translated by Google

Chương 4 Đội 123

[Beck và cộng sự, 2001] K. BECK, M. BEEDLE, A. COCKBURN, W. CUNNINGHAM, M. FOWLER, J. GRENNING, J.
HIGHSMITH, A. HUNT, R. JEFFRIES, J. KERN, B. MARICK, RC MARTIN, S. MELLOR, K. SCHWABER,
J. SUTHERLAND, D. THOMAS, VÀ A. VAN BENNEKUM, “Tuyên ngôn về phát triển phần mềm linh
hoạt ,” Agilemanifesto.org, 2001.
[Boehm, 2002] BW BOEHM, “Hãy sẵn sàng cho các phương pháp linh hoạt, cẩn thận,” IEEE Computer 35 (tháng 1

2002), trang 64–69.

[Brooks, 1975] FP BROOKS, JR., The Mythical Man-Month: Essays in Software Engineering, Addison Wesley,
Reading, MA, 1975; Ấn bản kỷ niệm lần thứ 20, Addison-Wesley, Reading, MA, 1995. www.businessweek.com/

[Tuần kinh doanh trực tuyến, 1999] Tuần kinh doanh trực tuyến , 1999/99_08/
b3617025.htm , ngày 2 tháng 2 năm 1999.

[Curtis, Hefl ey, và Miller, 2002] B. CURTIS, WE HEFLEY, AND SA MILLER, Mô hình trưởng thành về khả năng của

con người: Hướng dẫn cải thiện lực lượng lao động , Addison-Wesley, Reading, MA, 2002.

[Cusumano và Selby, 1995] MA CUSUMano VÀ RW SELBY, Bí mật của Microsoft: Công ty phần mềm hùng mạnh nhất thế

giới đã tạo ra công nghệ, định hình thị trường và quản lý con người như thế nào , The Free Press/Simon và
Schuster, New York, 1995.

[Cusumano và Selby, 1997] MA CUSUMANO VÀ RW SELBY, “Microsoft xây dựng phần mềm như thế nào,”

Truyền thông của ACM 40 (tháng 6 năm 1997), trang 53–61.

[DeMarco và Boehm, 2002] T. DEMARCO AND B. BOEHM, “The Agile Methods Fray,” IEEE Com

puter 35 (tháng 6 năm 2002), trang 90–92.

[DeMarco và Lister, 1987] T. DEMARCO AND T. LISTER, Peopleware: Productive Projects and Teams,
Nhà Dorset, New York, 1987.

[Drobka, Noftz, và Raghu, 2004] J. DROBKA, D. NOFTZ, VÀ R. RAGHU, “Thí điểm XP trên 4 Dự án Nhiệm vụ Quan

trọng,” IEEE Software 21 (Tháng 11–Tháng 12 năm 2004), trang 70–75.

[Dybå et al., 2007] T. DYBÅ, E. ARISHOLM, DIK SJØBERG, JE HANNAY, VÀ F. SHULL, “Hai cái đầu có tốt hơn một

cái đầu không? Về Hiệu quả của Lập trình Cặp,” IEEE Software 24 (Tháng 11–Tháng 12 năm 2007), trang 12–15.

[Flor, 2006] NV FLOR. “Phát triển phần mềm phân tán toàn cầu và lập trình cặp,” Com

đạn dược của ACM 49 (tháng 10 năm 2006), trang 57–58.

[Gorla và Lam, 2004] N. GORLA VÀ YW LAM, “Ai nên làm việc với ai?” Thông tin liên lạc của ACM 47 (tháng 6

năm 2004), trang 79–82.

[Lui, Chan, và Nosek, 2008] KM LUI, KCC CHAN, AND JT NOSEK, “The Effect of Pairs in Program Design Tasks,”

IEEE Transactions on Software Engineering 34 (Tháng 3–Tháng 4 năm 2008), trang 197–211.

[Mackey, 1999] K. MACKEY, “Các giai đoạn phát triển nhóm,” IEEE Software 16 (tháng 7–tháng 8 năm 1999),

trang 90–91.

[Mantei, 1981] M. MANTEI, “Tác động của cấu trúc nhóm lập trình đối với nhiệm vụ lập trình,”

Truyền thông của ACM 24 (tháng 3 năm 1981), trang 106–13.

[Murru, Deias, và Mugheddue, 2003] O. MURRU, R. DIAS, VÀ G. MUGHEDDUE, “Đánh giá XP tại

một Công ty Internet Châu Âu,” IEEE Software 20 (tháng 5–tháng 6 năm 2003), trang 37–43.

[Reifer, 2003] D. REIFER, “XP và CMM,” IEEE Software 20 (tháng 5–tháng 6 năm 2003), trang 14–15.

[Royce, 1998] W. ROYCE, Software Project Management: A Unifi ed Framework , Addison-Wesley,

Reading, Th.S, 1998.

[Weinberg, 1971] GM WEINBERG, Tâm lý học lập trình máy tính , Van Nostrand
Reinhold, New York, 1971.

[Williams, Kessler, Cunningham, và Jeffries, 2000] L. WILLIAMS, R. R. KESSLER, W. CUNNINGHAM, VÀ R. JEFFRIES,

“Tăng cường khả năng lập trình theo cặp,” IEEE Software 17 (tháng 7–tháng 8 năm 2000), trang 19 –25.