Đăng ký Đăng nhập
Trang chủ Phối hợp các nhóm - organic teams...

Tài liệu Phối hợp các nhóm - organic teams

.DOC
15
162
63

Mô tả:

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 Cơ cấu đội chính thức Nhóm thực hành Hoạt động 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. Lãnh đạo:  Thúc đẩy chuyên gia phần mềm. Hội nhập doanh nghiệp  Hợp tác nhóm 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.
- Xem thêm -

Tài liệu liên quan

Tài liệu vừa đăng