Phối hợp các nhóm - Organic Teams

Phối hợp các nhóm - Organic Teams
Một số trách nhiệm có liên quan trong quá khứ với các nhà quản lý dự án được đảm nhận
bởi các thành viên trong nhóm trong organic teams. Ví dụ trách nhiệm chính các quyết
định kỹ thuật nằm ở chính HLV kỹ thuật. Các nhà phát triển khác trong nhóm đảm nhận
trách nhiệm quan trọng là tốt. các trường hợp này xảy ra khi đội ngũ thực hành trong
framework 1 phần mềm kỹ năng khéo léo cho phép mỗi nhà phát triển ngày càng tăng
trách nhiệm tương xứng với chuyên môn phát triển phần mềm của mình. Cơ cấu đội
chính thức và đội thực hành giải quyết việc tổ chức các đội agile trong ranh giới của dự
án riêng của mình. Hiện tài liệu về phương pháp agile dừng lại ở đây mà không giải
quyết vấn đề lớn hơn là các đội tương tác như thế nào với các đơn vị khác trong tổ chức
của họ. Làm thế nào đội agile chuyển đổi từ trạng thái thí điểm để hội nhập với các dòng
chính? Những gì cần phải thay đổi trong cơ cấu tổ chức lớn hơn để làm cho toàn bộ tổ
chức nhanh nhẹn và thích nghi hơn. Khi các tổ chức bắt đầu triển khai các phương pháp
agile như là một giải pháp doanh nghiệp, quản lý cấp cao trong các tổ chức này cần phải
đặc biệt chú ý đến đội agile như thế nào được thành lập và tổ chức hoạt động trong các
doanh nghiệp lớn hơn và làm thế nào các doanh nghiệp lớn hơn chính nó phải thay đổi để
có được lợi ích đầy đủ từ alige và khả năng thích ứng. Hoạt động cho người quản lý
nhanh để cho phép thực hành nhóm và hội nhập doanh nghiệp được bảo hiểm tiếp theo.
Activities
Như đã thảo luận trong các chương trước đây, đây là những lãnh đạo của nhà quản lý
agile và trách nhiệm quản lý cần thiết để thành lập một đội của 1 dự án Agile
- Nhóm liên quan đến cấu trúc hoạt động được mô tả làm thế nào tổ chức tốt nhất
các đội cho các giá trị và linh hoạt
- Nhóm thực hành để xây dựng chuyên môn và cộng đồng.
- Các kỹ thuật tích hợp doanh nghiệp để giúp tích hợp các nhóm vào trong các tổ
chức lớn hơn.
Các hoạt động này được mô phỏng trong bảng 4.1
Phân loại Hoạt động
Cơ cấu đội chính thức Quản lý:
• Xác định dự án cộng đồng
• Thiết kế một cấu trúc ba chiều

chính thức.
• Các thành viên trong nhóm kỷ
luật tự giác.
Nhóm thực hành Lãnh đạo:
• Thúc đẩy chuyên gia phần mềm.
• Hợp tác nhóm
Hội nhập doanh nghiệp Lãnh đạo:
- Tạo thành một liên minh hướng dẫn
- Nuôi dưỡng các cộng đồng chính
thức của thực tiễn
Quản lý:
- Đề xuất 1 doanh nghiệp IT thích ứng
Cơ cấu nhóm nghiên cứu chính thức về giá trị và tính linh hoạt bằng cách áp dụng
các mô hình hữu cơ CAS được đề cập trong Chương 3, "Organic Teams -Phần 1 "; thực
hành nhóm và hội nhập doanh nghiệp được trình bày chi tiết tiếp theo.
Nhóm thực hành:
Một số thực hành cần phải được xử lý chủ yếu bởi nhóm riêng của mình với sự hỗ trợ
hạn chế từ các nhóm khác. trách nhiệm của bạn như là người quản lý agile về mặt này là
để thúc đẩy phần mềm thủ công và nuôi dưỡng đội ngũ cộng tác. Hai hoạt động này được
bao phủ tiếp theo.
Activity: Thúc đẩy (khuyến khích) chuyên gia phần mềm
Như Pete McBreen đã đề cập trong chương thúc đẩy các chuyên gia phần mềm, công
nghệ phần mềm được xây dựng để phục vụ cuộc sống, hiện thực, những hệ thống nhúng
và những hệ thống dự án kỹ thuật. Tuy nhiên, rất nhiều những nhà phát triển agile lại học
theo những chuyên gia phần mềm để tạo ra những ứng dụng thiết thực, chất lượng cao
với một chi phí hợp lý nhất trong một khoảng thời gian tương đối ngắn. Các chuyên gia
phần mềm sẽ thay thế những quan niệm truyền thống về phát triển phần mềm như một
hoạt động kỹ thuật ủng hộ cho những khái niệm cũ hơn của một phòng phát triển phần
mềm với một chuỗi những sự tiến bộ về kỹ năng từ người học việc cho đến thợ lành nghề
và cuối cùng là các chuyên gia.

Những nhà phát triển được mong chờ sẽ đảm nhiệm nhiều vai trò và chịu trách nhiệm
cho toàn bộ khối lượng công việc từ khi bắt đầu đến khi kết thúc. Không có một sự
chuyên môn hóa nào bị hạn chế - tất cả các nhà phát triển đều được hy vọng sẽ trở thành
những chuyên gia thành thạo từ những kỹ năng cơ bản nhất của lập trình: lập trình, kiểm
tra, tìm và khắc phục lỗi, và bảo trì. Không có một sự phân biệt nào giữa ‘người nghĩ’ và
‘người làm’ – tất cả các nhà phát triển đều được yêu cầu làm cả 2 nhiệm vụ trên.
Các chuyên gia phần mềm đều rất tự chủ và luôn chú trọng vào từng cá thể, thúc đẩy họ
từng bước để có thể làm chủ những phát triển phần mềm. Các nhà phát triển tiến bộ từng
bước từ người học việc sơ cấp đến thợ lành nghề bằng cách trở thành các chuyên gia có
kỹ năng, có thể thực hiện các dự án phát triển ứng dụng khác nhau mà không cần trợ
giúp.
Các chuyên gia phần mềm là những thợ lành nghề mà sự tiến bộ của họ được phát triển
thông qua việc học hỏi và kinh nghiệm trên nhiều dự án, đồng thời khuyến khích những
nhà phát triển khác trên con đường phát triển của riêng họ. Giống như các nghành nghề
thủ công khác, bài học này được đưa ra dựa trên việc học hỏi những sự tiến bộ thông qua
sự tương tác xã hội lẫn nhau và sự giám sát. Phần mềm được phát triển trong các phòng
phát triển phần mềm hoặc các khu vực mà sự tương tác giữa các nhà phát triển trở nên dễ
dàng hơn. Những người học việc được làm việc trên những nhiệm vụ dễ hơn và phát triển
những kiến thức cho riêng mình thông qua sự quan sát và thực hành dưới sự giám sát.
Phải thừa nhận rằng sự thành thạo mất rất nhiều thời gian và các nhà phát triển được coi
như những người làm việc có kiến thức đã mang lại sự cống hiến, kỷ luật và một niềm
mong ước được học tập và phát triển không ngừng. Mỗi một người học việc sẽ đào tạo ra
một người kế vị trước khi chuyển sang một nhiệm vụ mới thử thách hơn. Điều này cho
phép các chuyên gia phần mềm chỉ cần truyền đạt những kỹ năng tiên tiến nhất và tập
trung vào hiệu quả công việc.
Để thúc đẩy chuyên gia phần mềm, người quản lý agile cần phải thiết lập và duy trì một
studio với 1 lượng nhỏ lập trình viên có tay nghề. Dưới đây là một số hướng dẫn về việc
này:
- Thuê 1 người thầy chuyên gia dựa trên cơ sở đề nghị cá nhân, uy tín và danh mục
đầu tư.

- Hãy để người thầy chuyên gia có ảnh hưởng phủ quyết hơn là lựa chọn của nhóm
phát triển.
- Đối phó với những sai lầm trong việc lựa chọn càng sớm càng tốt.
- Thúc đẩy mối quan hệ mạnh mẽ giữa các nhà phát triển và người sử dụng.
- Quan trọng nhất, nhường trách nhiệm về mặt quản lý kỹ thuật(đánh giá thiết kế,
giám định mã, ) cho người thầy chuyên gia của bạn. Người thầy chuyên gia hoặc
team leader cũng phù hợp cho vai trò huấn luyện kỹ thuật. Họ là người có thể có
hiệu quả nhất trong việc đảm bảo về việc phát triển thực hành của XP, phát triển
thử nghiệm điều khiển, lập trình cặp, tái cấu trúc, và thiết kế đơn giản và họ cũng
là người thực hiện và duy trì. Điều đó không có nghĩa là bạn từ bỏ trách nhiệm của
bạn cho team như là người quản lý dự án, mà chỉ đơn giản rằng bạn tập trung vào
quản lý bối cảnh dự án (các bên liên quan, người sử dụng thông tin, thông tin liên
lạc, ) và để nội dung dự án nằm trong tay của 1 ai đó mà bạn lựa chọn cho mục
đích đó.
Đây là hướng dẫn cơ bản cho bạn để thúc đẩy chuyên gia phần mềm. Chi tiết có trong
cuốn McBeen.
Activity: Foster Team Collaboration – Bồi dưỡng cộng tác nhóm.
Mô hình cơ chế xử lý phát triển phần mềm như là một hoạt động sản xuất dây chuyền lắp
ráp các nhóm phát triển phân chia lao động giữa các nhóm chuyên biệt.
Điều này không chỉ tạo ra các vấn đề thông tin liên lạc và phối hợp mà làm cho nó khó để
gán quyền sở hữu cho tổng số sự phân phối của các kết quả hoạt động. Mỗi nhóm chịu
trách nhiệm cho một phần của quá trình nhưng không phải toàn bộ Gánh nặng phối hợp
rơi vào tay người quản lý dự án, các nhóm khác bao gồm cả khách hàng và người dùng,
rơi vào lập trường phản tác dụng giữa chúng tôi và họ.
Tổ chức tập thể hữu cơ 3 chiều sẽ loại bỏ sự tách biệt giữa các nhóm chuyên biệt và
khiến cho các nhóm phải chịu trách nhiệm cho toàn bộ quá trình từ khi bắt đầu cho đến
lúc kết thúc có thể giảm sự rủi ro của tổ chức xuống mức thấp nhất. Tuy nhiên team agile
đòi hỏi một mức độ cao sự hợp tác, cộng tác, và sự tin tưởng mà vượt ra ngoài sự thù
địch liên quan đến công việc. Có thể làm gì để tạo ra các điều kiện tối ưu cho sự hợp tác
trên các team agile? Một đầu mối chính nằm trong mối quan hệ giữa lợi ích cá nhân và

tập thể. Trong hầu hết các tổ chức 2 lợi ích này đều là 1 phần quan trọng trong công ty
nhưng dường như không bao giờ có thể dung hòa được. Ngày nay có vẻ như sự thành
công đến từ sự liều lĩnh và lợi ích riêng của cá nhân. Tuy nhiên khoa học đã chứng minh
rằng lợi ích sự cộng tác vượt xa giá trị của chính nó. Làm thế nào để bài học này có thể
áp dụng tính cộng tác vào agile team? Các nhà quản lý agile có thể cung cấp cho các nhà
lãnh đạo bằng cách thúc đẩy tính hợp tác tập thể cho dù cân bằng quyền lực , hợp tác
khách hàng và tham gia quyết định.
Cán cân lực lượng (Balance of Power )
Phương pháp nhanh được thông báo bởi lý lý thuyết trò chơi trong tăng cường hợp tác.
Ví dụ, hãy lập kế hoạch trò chơi XP. Đó là cấu trúc xung quanh hai quy tắc đơn giản
được thiết kế để cân bằng quyền lực và tối đa hoá lợi ích bắt nguồn bởi các bên lien quan,
nhiệm vụ của các nhà phát triển là dự đoán và sáng tạo công việc của khách hàng . Điều
này tạo ra tình huống nâng cao lợi ích cá nhân của mỗi bên để tối đa hoá lợi ích của tập
thể. Các nhà phát triển và khách hàng cùng nhau bàn bạc để giảm thiểu các tính năng có
lỗi. Các bên cùng tôn trọng những quy tắc cơ bản để đàm phán thay vì có tư tưởng chống
đối nhau. Nếu các quy tắc đã được trao đổi và thống nhất nhà phát triển sẽ lập kế hoạch
hoàn thành công việc trong thời gian thiết lập với khách hàng.
Thúc đẩy dự án, người quản lý nên khắc phục các tình huống anhr hưởng đến dự án để dự
án được hoàn thành tong thời gian nhanh nhất có thể. Ví dụ, một trong những dự án XP
ban đầu, người phát triển là một lập trình viên Java giỏi và cam kết gắn bó với dự án XP.
Trong thực tế, ông ta lại thường làm mất đoàn kết nội bộ, làm những lập trình viên khác
cảm thấy không yên tâm khi gắn bó với dự án. Để khắc phục điều này, người quản lý cần
tìm hiểu nguyên nhân và loại bỏ người đấy để thay thế anh ta bằng một người khác cùng
tay nghề mà được mọi người đồng tình.
Đặc điểm của các nhóm dự án nhanh
Làm thế nào để xác định nhóm dự án nhanh?
Một số đặc điểm phân biệt: Định hướng của khách hàng, năng lực cá nhân, tính ổn định
và kỷ luật tự giác, sự hợp tác mạnh mẽ, giảm chi phí chuyển giao thông tin, nhanh chóng
tiếp nhận thông tin phản hồi, liên tục học hỏi và thích ứng. Những đặc điểm này được áp
dụng trong nhóm dự án XP như sau:

Định hướng của khách hàng: Nhóm xem lời khuyên của khách hàng là một phần không
thể thiếu của mỗi dự án. Ví dụ, trong dự án XP có cơ chế để khách hàng tham gia cùng
nhóm dự án thông qua những lần thực hiện trên trang web của khách hàng, để khách
hàng xác định các tính năng mong muốn nhằm đảm bảo kết quả cuối cùng phù hợp với
yêu cầu của khách hàng ( tất cả các thành viên trong nhóm dự án, các khách hàng, người
quản lý được coi là quan trọng đối với dự án ).
Thẩm quyền cá nhân, nhu cầu mạnh mẽ về năng lực cá nhân và sự khác biệt về các nhóm
dự án tập trung vào các quá trình, các đánh giá sai lầm về kỹ năng và năng lực cá nhân.
Ví dụ, ba trong số bốn vấn đề phát triển cốt lõi của XP là thiết kế đơn giản, phát triển
điều khiển thử nghiệm và sắp xếp thẩm quyền giữa các người phát triển. Tương tự như
vậy, thử nghiệm, quản lý và các chuyên gia trong các lĩnh vực sẽ đóng vai trò quan trọng
giúp dự án được hoàn thành đúng thời hạn.
Các nhóm nhỏ thường được xây dựng đơn giản, thành lập nhanh và các thành viên trong
nhóm thường có ý thức cao để hoàn thành công việc. Scum đề nghị kích thước một nhóm
khoảng bảy người.
Tính tự giác và kỷ luật. Cùng với các thẩm quyền cá nhân, các thành viên trong nhóm
phải duy trì kỷ luật tự giác. Chẳng hạn như XP, nó kêu gọi tích hợp toàn bộ các mã
nguồn và mỗi mã mới được kiểm tra với bất kỳ thành viên nào của nhóm. Kịch bản tự
động thường được sử dụng để kiểm tra tất cả các mã, xây dựng nó, tự động chạy các đơn
vị và nghiệm thu. Mặc dù điều này nghe có vẽ khó khăn, nhưng nó là cần thiết cho mỗi
người trong nhóm phát triển cần phải có kỷ luật và tính tự giác.
Hợp tác chặt chẽ, Giữa người lập kế hoạch trò chơi, người phát triển và khách hàng, hợp
tác trong tất cả các kế hoạch, tất cả thời gian. Người phát triển cung cấp các ước tính để
thực hiện các tính năng, và khách hàng quyết định các tính năng ưu tiên để đội ngũ về
phát triển ước tính. Nhà phát triển và khách hàng giao tiếp với nhau bằng văn bản, phản
ánh quá trình thực hiện dự án theo định kỳ với tất cả các thành viên trong nhóm để rút ra
các bài học và các kinh nghiệm cần thiết.
Giảm chi phí chuyển giao thông tin. Các bên tạo điều kiện thuận lợi trong giao tiếp, sử
dụng văn bản, mặt đối mặt để truền tải các thông điệp là phương thức tốt để giản chi phí
chuyển giao thông tin.

Giảm thời gian phản hồi quyết định. Một nguyên lý cơ bản của cách tiếp cận nhanh là
phát triển phần mềm từng bước và lặp đi lặp lại. Mục đích chính của điều này là để giảm
thời gian khi một quyết định được thực hiện và khi hiệu ứng được nhìn thấy. Có sẵn một
đại diện của khách hàng xác nhận và thông qua, phải đảm bảo luôn thực hiện kiểm thử
hồi quy để giám sát các thay đổi và làm cho các phiên bản nhỏ đi để đảm bảo tính khả thi
của giải pháp.
Liên tục học hỏi và thích ứng. Bởi vì các nhóm dự án nhanh thường thay đổi nên phải
học hỏi và thích ứng liên tục. Các cuộc họp, các cuộc thảo luận là cơ hội để theo dõi, tìm
hiểu và thích ứng. Dự án được trao đổi thường xuyên để tìm ra các vấn đề cũng như để
điều chỉnh quá trình thực hiện.
Hợp tác khách hàng
Theo truyền thống, khách hàng và người sử dụng luôn được đặt “bên ngoài” đội ngũ quản
lý. XP giới thiệu khái niệm về một đội ngũ với mối quan hệ chặt chẽ giữa khách hàng,
nhóm phát triển và nhóm quản lý để thúc đẩy sự sáng tạo của mạng lưới và duy trì mối
quan hệ hợp tác thường xuyên giữa các bên.
Sự tham gia của các bên và ra quyết định( Participatory DecisionMaking )
Ra quyết định có sự tham gia của các bên là một quá trình mà tất cả các nhóm đều có ảnh
hưởng và đưa ra sáng kiến để thực hiện dự án tốt hơn. Mặc dù bạn là người quản lý giỏi
và là người chịu trách nhiệm cuối cùng của dự án nhưng bạn cũng phải cho phép các
thành viên trong nhóm tham gia và đóng góp ý kiến các vấn đề liên quan đến công việc
của dự án. Khi cho họ các quyền này, các nhóm sẽ tham gia nhiệt tình và có trách nhiệm
vì họ cảm thấy các ý kiến của họ được tôn trọng. Như vậy, thay vì sự lãnh đạo độc tài bạn
cần hợp tác và lắng nghe. Tuy nhiên, các ý kiến này không phải lúc nào cũng được chấp
thuận mà phải được xem xét kỷ lưỡng và bạn vẫn là người chịu trách nhiệm cuối cùng về
thành công hay thất bại của dự án.
Bây giờ ta có thể hểu hơn về cấu trúc nhóm, các hoạt động để giúp tích hợp các nhóm
thành các nhóm lớn hơn để thực hiện các dự án lớn hơn.
Enterprise Integration
Developing agility( Phát triển linh hoạt) là lỗ lực lớn bạn cần thực hiện trong cơ cấu tổ
chức chứ không phải là cơ cấu lại các đội dự án và sửa đổi các kỹ thuật của họ. Với kinh

nghiệm nhiều năm quản lí và tư vấn cho các agile project đã dạy tôi rằng sự thành công
của các đội dự án này phụ thuộc phần lớn vào việc họ tích hợp vào các doanh nghiệp lớn
hơn. Agile teams không thể cung cấp đầy đủ tiềm năng của họ mà không đi kèm với sự
thay đổi tổ chức. Các tổ chức thì luôn có nhu cầu nhận ra lợi ích đầu tư đầy đủ của họ
trong agile project teams do đó cần phải cam kết chuyển đổi cơ cấu tổ chức của họ nếu
không APM chỉ sẽ vẫn là một
mốt hiện đại nhất thời và sẽ sớm được thay thế bởi kỹ thuật thịnh hành thuật tiếp theo.
Một trong những điều mà một người quản lý agile có thể làm tại doanh nghiệp là gì ?
Người quản lý agile có thể đóng một vai trò trong việc giúp phát triển doanh nghiệp lớn
hơn, một mô hình IT với khả năng thích ứng tốt hơn phù hợp với kinh doanh và đáp ứng
nhiều hơn để thay đổi. Các hoạt động để giúp hoàn thành mục tiêu này bao gồm hình
thành một liên minh hướng dẫn, xây dựng cộng đồng thực hành và đề nghị một tổ chức
CNTT thích nghi.
Activity: Form a Guiding Coalition (Hoạt động: Thành lập một Liên minh Hướng dẫn)
Sau khi bạn xác định các dự án cộng đồng của bạn bằng cách nhóm các bên liên quan
và tạo ra một bản đồ của các bên liên quan, bước tiếp theo là tạo thành một liên minh
hướng dẫn. John Kotter đề nghị tạo ra một liên minh hướng dẫn mạnh mẽ cho việc
chuyển đổi tổ chức thành công. Liên minh cần phải có một cốt lõi là quản lý cấp cao, đó
những người có quyền lực, độ tin cậy và kinh nghiệm để dẫn dắt dự án của bạn. Nó cũng
nên bao gồm các bên liên quan ở tất cả các cấp của tổ chức cam kết cho sự thành công
của dự án. Thành viên của nhóm nên chia sẻ một cái nhìn chính xác của dự án và ý nghĩa
của nó, tin tưởng lẫn nhau, và có kỹ năng giao tiếp tốt. Họ sẽ là những đại sứ và các nhà
truyền bá của sáng kiến agile. Họ sẽ cần phải chính thức hoặc không chính thức đăng ký
để loại bỏ những trở ngại, thúc đẩy các dự án và hành động như một tác nhân thay đổi.
Bạn sẽ cần sự giúp đỡ của họ để đảm bảo dự án đạt được kết quả và các thực hiện thay
đổi được được duy trì. Một trong những mục tiêu của bạn nên mở rộng nhóm này có
chiến lược để bao gồm nhiều người và nhiều người hơn nữa trong quá trình của dự án để
mở rộng khả năng thay đổi và đảm bảo sự đa dạng các quan điểm.
Activity: Cultivate Informal Communities of Practice (Hoạt động: Bồi dưỡng cộng
đồng thức thực hành)

Organic Teams yêu cầu thiết kế một cấu trúc ba chiều chính thức (holographic
structure) để tái tạo sự ổn định và quản lý công việc trong khi tránh các rối loạn chức
năng đã đề ra.Tuy nhiên, agile teams cũng cần một sự cân bằng giữa thiết kế cơ cấu tổ
chức với sự nổi bật thể hiện sự sáng tạo cần thiết, khả năng thích ứng và sức sống của các
tổ chức. Chìa khóa để đạt được sự cân bằng này nằm trong sự hiểu biết cách cấu trúc và
phương tiện mà mọi người sử dụng để tiếp cận với những người khác và hợp tác trên cơ
sở không chính thức.
Trong mọi tổ chức, mọi người ngồi lại với nhau để thảo luận, phân tích và cộng tác
chính thức xung quanh nền tảng của việc chia sẻ lợi ích. Tổ chức nhà lý luận Etienne
Wenger đặt ra các cộng đồng thực hành cho các nhóm người có chung một mối
quan tâm, một tập hợp của các vấn đề, hoặc một niềm đam mê về một chủ đề và
những người đào sâu kiến thức và chuyên môn của họ trong lĩnh vực này bằng cách
tương tác một cách thường xuyên.
Cộng đồng thực hành starkly làm nổi bật bản chất kép của các tổ chức, họ đồng thời là
tổ chức xã hội được thiết kế cho các mục đích cụ thể và cộng đồng của những người xây
dựng mối quan hệ và tương tác ở một mức độ rất cá nhân. Quản lý Agile cần phải giữ
tính 2 mặt này trong tâm trí khi tạo một nhóm để đạt được các nguyên tắc agile cơ bản.
Những nguyên tắc agile cơ bản là rất cá nhân và đạt được bởi các thành viên vì vậy
những thành viên cần phải có kiến thức, kinh nghiệm và học hỏi và giao tiếp tốt.
Quản lý Agile cần nhận ra và nuôi dưỡng các cộng đồng thực hành, bởi vì tri thức không
phải là một thứ hàng hóa mà đó là riêng biệt của từng người.
Cộng đồng thực hành được đặc trưng bởi ba tính năng: tham gia lẫn nhau của các
thành viên, một doanh nghiệp liên doanh, sự chia sẻ các thói quen, quy tắc ứng xử, kiến
thức. Các tính năng liên quan thể hiện trong Bảng 4-2.
Mặc dù cộng đồng thực hành phần lớn là những cấu trúc chính thức, nuôi trồng thông
qua hỗ trợ chính thức là cách tốt nhất để duy trì sự tồn tại của họ và đảm bảo giá trị của
họ. Một số hướng dẫn để nuôi dưỡng các cộng đồng thực hành từ cuốn sách của Etienne
Wenger là nuôi dưỡng các cộng đồng thực hành thiết kế tiến hóa, nhiều quan điểm, mức
độ tham gia khác nhau, không gian công cộng và tư nhân, tập trung vào sự quen thuộc,
giá trị và sự phấn khích và cộng đồng rhythm.4. Quản lý Agile cần phải áp dụngnhững

nguyên tắc như sau:
• Tiến hóa thiết kế: Bắt đầu với các yếu tố cần thiết, điều phối viên và một nhóm cốt
lõi họp thường xuyên. Cho phép các nhóm phát triển thiết kế theo thời gian để đáp
ứng với thay đổi lợi ích.
• Nhiều quan điểm: Đảm bảo rằng nhiều quan điểm tồn tại trong trang điểm của cộng
đồng. Mở một hộp thoại giữa các quan điểm trong và ngoài để làm điều này. Quan
điểm bên trong rất quan trọng để hiểu các vấn đề và kết hợp thay đổi hiệu quả. Quan
điểm bên ngoài là rất quan trọng cho việc mở ra những khả năng và nhận được nhóm
để xem xét các tùy chọn.
• Các mức độ tham gia khác nhau: Mời nhiều cấp độ tham gia. Kế hoạch cho một
nhóm cốt lõi đó là rất năng động. Một nhóm hoạt động có thể không đảm nhận vai trò
lãnh đạo nhóm nòng cốt nhưng sẽ tham gia thường xuyên . Cuối cùng, nhiều thành
viên sẽ là ngoại biên xem sự tương tác của lõi và các nhóm hoạt động và đôi khi bước
vào tham gia cùng họ.
• Không gian công cộng và tư nhân: Tương tác tư nhân giữa các thành viên cũng quan
trọng như công cộng. Bên cạnh các bài thuyết trình công cộng, các cuộc họp, hội thảo
cần khuyến khích các thành viên để tương tác với nhau và làm việc cùng nhau về các
vấn đề của nhau.
• Tập trung vào giá trị: Cộng đồng thực hành không thể phát triển mà không có việc
cung cấp các giá trị đo lường. Họ sẽ mất sự tín nhiệm và hỗ trợ không chỉ từ các tổ
chức mà còn từ chính các thành viên. Khuyến khích các thành viên tập trung vào
cung cấp giá trị thường xuyên.
• Có hiểu biết và hứng thú: Để thành công, cộng đồng cần để duy trì các hoạt động
quen thuộc tạo ra một mức độ thoải mái. Họ cũng cần phải kết hợp các hoạt động
quen thuộc với các hoạt động mới để tạo ra sự phấn khích mà giữ các thành viên hoạt
độngvà tham gia.
• Cộng đồng nhịp điệu (Community rhythm): Cộng đồng cần thiết lập arhythm mà
không phải là quá nhanh mà nó lấn át mọi người và cũng không quá chậm mà họ trở
nên chậm chạp. Tất cả các cuộc họp thường xuyên, trao đổi email và các hoạt động
chính thức khác góp phần vào nhịp điệu của một cộng đồng.

Activity: Propose an Adaptive IT Enterprise
Hoạt động: đề nghị một khả năng thích nghi tổ chức kinh doanh CNTT
Chúng ta nhận thấy rằng vấn đề này không nằm trong phạm vị hoạt động ảnh hưởng hầu
hết các nhà quản lý dự án hoặc cơ quan có thẩm quyền quyết định về tổ chức doanh
nghiệp của họ. Tuy nhiên, như các nhóm thực hiện các phương pháp agile chuyển từ sáng
kiến thí điểm đến tích hợp đầy đủ, các thành công nhóm của sáng kiến agile phụ thuộc
phần lớn vào sự biến đổi văn hóa/ văn minh/ tu dưỡng/ mở mang của tổ chức đó, tạo điều
kiện cho một quá trình phát triển doanh nghiệp CNTT của mình một mô hình thích ứng
tập trung hơn giá trị kinh doanh trong kiểm soát và chi phí. Để thực hiện điều này thành
thực tế, các nhà quản lý agile sẽ cần phải đề xuất sự cần thiết cho một mô hình doanh
nghiệp CNTT có khả năng thích ứng để quản lý điều hành trong các tổ chức của họ. thích
ứng doanh nghiệp CNTT là một giống lai/ hỗn hợp phát triển từ truyền thống dành riêng
cho doanh nghiệp CNTT và ngày nay là một ma trận đầy đủ cho doanh nghiệp CNTT.
Truyền thống dành riêng cho các doanh nghiệp CNTT đã tập trung mạnh vào giá trị
doanh nghiệp cho phép các lợi thế của các đường dây liên lạc chặt chẽ, như minh họa
trong Hình 4-1
Hình 4-1. Dedicated IT enterprises
CM = configuration manager, DBA = database administrator
Thông thường, chuyên dụng cho các doanh nghiệp CNTT:
- Đơn vị kinh doanh bắt đầu dự án trên cơ sở chiến lược của công ty.
- Tất cả các thành viên trong nhóm dự án có trách nhiệm trực tiếp cho giá trị đóng
góp cho chiến lược của công ty.
- Người quản lý dự án có một vai trò quản lý mạnh mẽ.
- Có ít hoặc không có sự phối hợp hợp của các tiêu chuẩn chung giữa các dự án.
Mặc dù doanh nghiệp này vay chính nó để tạo ra giá trị, nó cũng tạo ra lãng phí do thiếu
sự phối hợp tổng thể và hiệu quả trên toàn dự án. Kết quả là, hầu hết các doanh nghiệp
CNTT được tổ chức theo kiểu dự án matrixed mạnh mẽ.
Các doanh nghiệp CNTT matrixed cố gắng để nâng cao hiệu quả và giảm thiểu lãng phí
do trùng lặp các tài nguyên, thiếu sự phối hợp và các tiêu chuẩn. Tuy nhiên, vì nó đạt
được điều này với một mô hình cơ học cơ bản các mà gọi là chuyên môn hẹp trong tổ

chức có những cản trở tiêu cực giữa các bộ phận trong công ty, các tổ chức CNTT
matrixed trở thành nạn nhân đối mặt với sự thay đổi và cái kết tạo ra lãng phí cho chính
nó trong cách thức phối hợp quá nhiều, kích cỡ nhóm lớn và sự chậm trễ thông tin phản
hồi.
Bởi vì các chuyên ngành hẹp, trách nhiệm cho việc cung cấp giá trị kinh doanh được lan
rộng trên toàn tổ chức silo để thấy rằng không ai xác định rõ ràng cho các giá trị cung cấp
kinh doanh. Đáng chú ý, như minh họa trong Hình 4-2, quản lý dự án đóng vai trò như
một lịch trình và quản lý điều phối có ảnh hưởng rất ít. Thành viên trong nhóm dự án
thường không thực sự dành riêng cho dự án, nhưng thay vì matrixed vào nó từ các silos
bên ngoài. Tổ chức này đã giới thiệu rất nhiều kiểm soát và tiêu chuẩn hóa, nhưng đi kèm
các chi phí dự án đã được thông và phân phối giá trị cho khách hàng có hiệu quả.
Figure 4-2. Matrixed IT Enterprise
PMO = project management office, QA = quality assurance (đảm bảo chất lượng)
Thông thường, trong ma trận các doanh nghiệp CNTT:
- Đơn vị kinh doanh bắt đầu dự án trên cơ sở chiến lược của công ty.
- Tất cả các thành viên trong nhóm dự án chịu trách nhiệm về giá trị đóng góp cho
silo nhóm, chứ không phải là chiến lược của công ty.
- Người quản lý dự án có một lịch trình yếu và vai trò điều phối.
- Nhóm Chuyên gia, chẳng hạn như cơ quan quản lý chương trình (PMO) và các
nhóm khác, có ảnh hưởng mạnh mẽ về tổ chức. Có độ ưu tiên ở cấp độ nhóm, bởi vì
ưu tiên nhóm thường ghi đè lên dự án hoặc kinh doanh ưu tiên trên vị trí cơ sở.
Sự thích nghi của doanh nghiệp CNTT cung cấp số lượng dự án cao và giá trị kinh doanh
nhất quán và hiệu quả hơn. Nó là sự kết hợp giữa các đội dự án chuyên dụng và tổ chức
ma trận đầy đủ, như minh họa trong Hình 4-3.
Figure 4-3. Adaptive IT Enterprise
Thông thường, trong thích ứng doanh nghiệp CNTT
- Đơn vị kinh doanh bắt đầu dự án trên cơ sở chiến lược của công ty.
- Tất cả các thành viên trong nhóm dự án chịu trách nhiệm cho việc cung cấp giá trị
kinh doanh đối với chiến lược của công ty đóng góp.
- Người quản lý lanh lợi có một sự hợp tác mạnh mẽ, trao quyền và vai trò tạo điều

kiện thuận lợi, cũng như vai trò lãnh đạo.
- Các nhóm giúp đỡ lẫn nhau duy trì thông lệ và tiêu chuẩn chuyên ngành nhưng
không bẻ gay tổ chức vào silo của các chuyên gia.
Sự thích ứng doanh nghiệp CNTT hỗ trợ cho việc giao dự án chiến lược kinh doanh,
đồng thời cho phép phù hợp tiêu chuẩn kỹ thuật và hoạt động trên các đội dự án. Người
quản lý nhanh nhẹn và tất cả các thành viên trong nhóm trở thành "chuyên gia tổng hợp",
nơi họ có một khu vực chuyên môn chính của nhưng được trao quyền để góp phần cho tất
cả các khía cạnh của giao dự án. Một người quản lý sản phẩm phục vụ như là đối tác của
người quản lý để cung cấp các dự án. Đáng kể nhất, trong suốt thời gian của dự án, báo
cáo toàn bộ dự án cho một giám đốc điều hành kinh doanh.
Bạn sẽ cần phải đề xuất các doanh nghiệp CNTT thích ứng như mô hình tổ chức ưu tiên
cho việc tích hợp nhóm agile của bạn vào các tổ chức lớn hơn.