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.