Bằng việc sử dụng các công cụ hỗ trợ, hoạt động CM trong XP cần đƣợc thực hiện một cách tự động để kiểm thử lại toàn bộ các trƣờng hợp và phát hành một phiên bản mới cho ngƣời dùng. Cùng với điều này, chúng ta cũng cần thiết lập một cơ chế để cho phép tất cả các ngƣời liên quan thấy đƣợc những gì đang diễn ra trong đội phát triển kể cả khách hàng của chúng ta. Đầu tiên vào buổi sáng chúng ta có thể kiểm tra xem những gì thay đổi đã đƣợc thực hiện bởi các đội dự án khác. Bằng cách này, ta có thể biết đƣợc những gì đang xảy ra ở các đội dự án khác. Điều này đòi hỏi phải xây dựng kỷ luật tốt, các nhà phát triển cố gắng rất nhiều để không phá vỡ xây dựng và sửa chữa nó ngay lập tức nếu nó bị phá vỡ. Một thực tế thƣờng đƣợc chấp nhận rằng nếu bạn thay đổi đƣờng chính, bạn không nên về nhà cho đến khi bạn nhận đƣợc các tin nhắn email từ các đội khác đảm bảo rằng kết quả của những thay đổi của bạn đã thành công.
2. 5. Các vấn đề khác
2.5.1. Biến đổi văn hóa doanh nghiệp
Một trong những phần khó nhất của việc đƣa các phƣơng pháp phƣơng pháp lập trình cực hạn vào một tổ chức là sự thay đổi văn hóa mà nó gây ra. Thực ra chúng ta đã nhận thấy rằng đây là lý do chính tại sao các tổ chức có vấn đề với việc áp dụng phƣơng pháp phƣơng pháp phát triển phần mềm linh hoạt. Nhiều công ty hoạt động với mô hình kiểm soát và ra lệnh (Giả định rằng cấp trên đƣa ra quyết định và cấp dƣới thực hiện theo yêu cầu của cấp trên). Để thực hiện phƣơng pháp lập trình cực hạn trong công việc, bạn cần tự chủ hơn và tự quyết định nhiều hơn các công việc thuộc về bạn.
Chúng tôi thấy đây là một vấn đề lớn trong các công ty ở châu Á do nền văn hóa châu Á luôn giữ sự tôn trong và nghe lời cấp trên. Trong môi trƣờng này chúng ta cần khuyến khích việc đặt câu hỏi, nói chuyện về những vấn đề đang và sẽ xẩy ra, cảnh báo về thời hạn thực hiện, hoặc đề xuất các giải pháp thay thế để nhận đƣợc các chỉ dẫn từ cấp trên.
Cần phải rất cảnh giác với xu hƣớng này vì trong dự án có nhiều đội tham gia, có thể đội tích hợp chính có thể cảm nhận thấy các đội còn lại là thụ động đồng ý. Chú ý rằng việc chấp nhận theo phép lịch sự thƣờng là một dấu hiệu của một vấn đề quan trọng khi không nhận đƣợc sự thảo luận từ các đội cùng phát triển. Việc các đội đƣợc chủ động nhiều hơn là một cuộc chiến gian nan, và một trong đó chắc chắn phải mất rất nhiều thời gian. Bạn không bao giờ có thể giả định rằng vấn đề sẽ đƣợc nêu ra, ngay cả khi chúng đƣợc phát hiện. Nhƣ vậy
chúng ta sẽ cần nhiều thời gian hơn để sử dụng phƣơng pháp lập trình cực hạn theo phong cách quản lý phân tán. Nhƣng một khi ngƣời nhận ra họ có quyền tự do, và trách nhiệm, trong việc ra quyết định – họ dƣờng nhƣ thực sự hạnh phúc vì điều đó. Một số đội áp dụng XP nói rằng trong các công ty khác không thể tin đƣợc rằng họ đang đƣợc quyền tự chủ. Tự chủ là một động lực lớn cho phép chúng ta nâng năng suất và hiệu quả lao động đồng thời có thể phát triển thành một trách nhiệm lớn hơn. Hơn nữa, các thành viên trong nhóm đạt đƣợc sự tin tƣởng vào sự hiểu biết để đƣa ra quyết định thay vì chờ đợi từ đội khác hoặc từ đội tích hợp mà làm chậm trễ công việc. Việc đi thăm đội khác đóng một vai trò rất quan trọng ở đây. Thông thƣờng mọi ngƣời sẽ nên lên các vấn đề nếu họ có một mối quan hệ cá nhân tốt.
2.5.2. Bổ xung thêm nhóm mới
Hai trong số các dự án của chúng tôi liên quan đến việc mang một cơ sở mã nguồn lớn (hàng trăm nghìn dòng mã nguồn) và chuyển cơ sở mã nguồn này đến phát triển trong các phòng thí nghiệm. Trong cả hai của các dự án này, các đội đã bắt đầu với một vài lần lặp sửa lỗi trƣớc khi họ bắt đầu bổ sung thêm chức năng mới vào hệ thống. Việc bắt đầu với sửa lỗi cho phép các đội mới trở thành quen thuộc với các cơ sở mã nguồn mới, trƣớc khi chúng ta làm việc trên nó, do việc sửa lỗi liên quan đến việc đọc mã nguồn nhiều hơn là sửa đổi. Mặc dù điều này làm việc tốt, nhƣng có một số lo ngại rằng nhiều ngƣời có kinh nghiệm có thể coi nó là một sự thiếu tin tƣởng nên chỉ giao cho công việc sửa lỗi. Trong khi một số ngƣời cảm nhận điều này nhƣ là một vấn đề, chúng tôi luôn tin rằng việc sửa lỗi hoặc địa phƣơng hóa các tính năng là một trong những cách tốt nhất để làm quen với một cơ sở mã nguồn lớn.
Việc truyền đạt các lỗi cần sửa thƣờng dễ dàng hơn cho một đội mới làm việc với các đội cũ. Các đội cũ có thể bỏ ra nhiều ngày của họ để chỉ ra các chi tiết của lỗi, cái có thể đƣợc truyền đạt cho các đội mới và giúp đội mới hiểu ra các vấn đề cần chỉnh sửa. Nhóm cũ cũng cần xem lại các bản sửa lỗi sau đó. Chúng tôi thấy rằng đây không phải là một cách hiệu quả hơn nhƣng nó có thể là một cách ít phức tạp và mau chóng để một đội mới hiểu và nắm bắt đƣợc hệ thống mà mình dự định sẽ phát triển trên nó.
2.5.3. Viết tài liệu dự án
Phƣơng pháp lập trình cực hạn làm giảm bớt các yêu cầu về tài liệu từ sự quan sát cho rằng một phần lớn các nỗ lực rất lãng phí. Tuy nhiên, tài liệu sẽ trở
nên quan trọng hơn với sự phát triển thuê ngoài khi mà giao tiếp mặt đối mặt giảm. Việc làm tài liệu sẽ là một sự lãng phí nếu toàn đội làm việc trong cùng một địa điểm. Nhƣng với mô hình thuê ngoài, bạn cần phải làm chúng - vì chúng là một phần công việc của đội thuê ngoài. Đó là một giá bỏ ra cho công sức của những ngƣời viết ra chúng, thời gian thêm vào vì nó khó hơn cho mọi ngƣời hiểu nhiều điều từ một tài liệu, và cũng là một giá trong thất vọng khi ngƣời mọi ngƣời sử dụng chúng.
Cũng nhƣ việc viết tài liệu, bạn cũng có nhu cầu sử dụng các công cụ cộng tác tích cực hơn: wiki, các công cụ theo dõi vấn đề và các công cụ tƣơng tự nhƣ thế. Hơn hết, việc viết tài liệu thƣờng phù hợp với các công cụ áp dụng ít cấu trúc hơn, nhƣ vậy các nhóm có thể phù hợp với họ tốt hơn vào cách họ muốn làm việc hơn (một trong những lý do mà wiki có thể làm việc rất tốt.)
Chúng tôi luôn luôn tƣ vấn cho các nhóm kiểm tra tài liệu của họ trong một hệ thống kiểm soát phiên bản để mọi ngƣời có thể dễ dàng nhận đƣợc tài liệu mới nhất. Điều này đặc biệt quan trọng khi bạn đang làm công việc ở xa.
Cho dù đó là tài liệu hoặc bất cứ điều gì khác, hãy nhớ rằng những mẫu tài liệu của ngƣời khác sẽ không làm việc cho bạn, và bạn sẽ không phải đƣa ra một lƣợc đồ chuẩn ngay từ ban đầu. Hãy chắc chắn rằng có rất nhiều thông tin về hình thức của các tài liệu và nhƣ thế nào họ đang làm việc. Hy vọng sẽ phát triển cấu trúc của tài liệu nhƣ bạn đã học những gì làm việc tốt nhất cho nhóm của bạn.
Có hai chìa khóa để việc tạo tài liệu thành công trong các dự án áp dụng phƣơng pháp lập trình cực hạn. Chìa đầu tiên là tìm điểm vừa đủ "tài liệu". Đây là khó khăn để xác định và sẽ thay đổi tùy theo dự án. May mắn thay, tính chất lặp đi lặp lại của phƣơng pháp lập trình cực hạn cho phép bạn thử nghiệm cho đến khi bạn nhận đƣợc nó. Chìa khóa thứ hai là không đƣợc đính kèm với nó hoặc có hy vọng không thực tế của việc giữ nó đƣợc cập nhật. Tài liệu phải đƣợc tạo ra để phục vụ một mục đích cụ thể, và sau khi nó đã phục vụ mục đích đó bạn sẽ có thể có tất cả những điều quan trọng hơn để làm hơn là tiếp tục cập nhật các tài liệu. Nó có thể có vẻ phản trực giác, nhƣng nó thƣờng tốt hơn để tạo ra tài liệu mới trong thời gian tới với những yêu cầu rõ ràng. Một mặt lợi ích của việc bắt đầu lại mỗi khi bạn cần tài liệu hóa một phần trong dự án của bạn, đó là sự khích lệ lớn để giữ tài liệu của bạn hiệu quả!
Chƣơng 3 ỨNG DỤNG XP TRONG DỰ ÁN THUÊ NGOÀI
Để có thể đánh giá đƣợc mô hình đƣợc đề xuất trong chƣơng 2, trong chƣơng này, tôi sẽ giới thiệu một số dự án cả những dự án áp dụng theo mô hình cũ và các dự án đã áp dụng mô hình mới và các đánh giá kết quả thu đƣợc trong quá trình áp dụng. Các kết quả thu đƣợc phần nào thể hiện đƣợc các ƣu thế cũng nhƣ những vấn đề của mô hình này.
3. 1. Môi trƣờng áp dụng
Các thử nghiệm đƣợc tiến hành trên một số dự án thuộc Trung Tâm Công Nghệ Ngân Hàng VIB. Đây là trung tâm cung cấp các dịch vụ công nghệ cho toàn bộ ngân hàng, bao gồm các dịch vụ ngân hàng lõi (core banking), dịch vụ ATM, dịch vụ hỗ trợ chi nhánh (Branch Teller), dịch vụ ngân hàng trực tuyến eBanking, dịch vụ bảo dƣỡng sửa chữa máy tính (PC Care) ... Trung Tâm Công Nghệ là một đơn vị kinh doanh độc lập, có con dấu riêng, nguồn thu dựa trên việc cung cấp các hoạt động dịch vụ về công nghệ thông tin cho toàn bộ hệ thống ngân hàng VIB với chiến lƣợc tin học hóa, tự động hóa các công đoạn xử lý trên toàn bộ hoạt động của ngân hàng.
3. 2. Mô hình tổ chức
Ở giai đoạn ban đầu, VIB đã áp dụng phƣơng thức tổ chức theo hƣớng chuyên trác quản trị dự án nhằm phát triển các dự án lớn xây dựng nên nền tảng công nghệ thông tin ban đầu để hỗ trợ toàn ngân hàng.
Sau đó, do nhu cầu duy trì và hỗ trợ các dự án, VIB lại tái cơ cấu tổ chức và chuyển sang áp dụng mô hình quản trị theo chức năng. Nhân sự của các dự án đƣợc phân về các phòng khác nhau nhằm chịu trách nhiệm chuyên trách về các vấn đề giúp trung tâm tập trung vào các mảng hỗ trợ việc sử dụng kết quả mà các dự án lớn đã thực hiện mang lại và giúp nhân sự các phòng tập trung vào việc chuyên môn hóa công việc của mình.
Hình 3-2 Mô hình tổ chức theo chức năng
Cuối cùng, do yêu cầu cần chỉnh sửa và phát triển các sản phẩm mới dựa trên các dự án nền tảng đã đƣợc phát triển và nhu cầu phát triển thêm các hệ thống mới nhằm hỗ trợ việc quản trị trong Trung tâm và trong cả Ngân Hàng đòi hỏi Trung Tâm phải có sự cải cách về cơ cấu nên Trung Tâm đã áp dụng phƣơng thức tổ chức quản trị theo dạng ma trận. Tổ chức quản trị theo dạng ma trận là hình thức kết hợp giữa mô hình tổ chức quản lý dự án theo chức năng và mô hình tổ chức quản lý chuyên trách dự án. Đây là hình thức quản trị mà các dự án đƣợc tổ chức dƣới sự điều phối của từng nhà quản trị dự án độc lập với từng dự án cũng nhƣ chịu sự điều phối của phụ trách các bộ phận chức năng trong tổ chức này.
Việc tổ chức quản trị dự án theo ma trận mang lại rất nhiều lợi ích cho Trung Tâm Công Nghệ VIB. Đầu tiên là đảm bảo nhân lực vừa có kinh nghiệm phát triển và giữ đƣợc các nhân lực này sau khi dự án kết thúc cũng nhƣ có nhân lực hỗ trợ dự án ngay lập tức khi cần sửa chữa hay phát triển mở rộng thêm dự án. Thứ hai là giúp cho các thành viên trong đội dự án tập trung hoàn toàn vào dự án, có thể kết hợp với các thành viên khác mà không bị ràng buộc trong phạm vi chuyên môn của mình cũng nhƣ trong phòng ban của mình. Thứ ba là tạo điều
kiện cho doanh nghiệp biến đổi, thích ứng với sự thay đổi của nhu cầu khách hàng, của thị trƣờng. Cuối cùng và quan trọng nhất là, mô hình tổ chức theo dạng ma trận giúp doanh nghiệp có thể kết hợp với các đội dự án thuê ngoài để vừa có nhân lực tổ chức phát triển dự án, vừa dễ dàng trao đổi với các đội dự án và dễ dàng tiếp nhận kết quả khi hoàn thành dự án.
Hình 3-3 Mô hình tổ chức theo dạng ma trận 3. 3. Các dự án thực nghiệm
3.5.1. Dự án tƣơng tác liên chi nhánh InterBranch
Mô tả dự án
Dự án tƣơng tác liên chi nhánh InterBranch xuất phát từ các khó khăn của khách hàng khi đăng ký ở chi nhánh này nhƣng lại sang chi nhánh khác làm việc. Khi đó, chi nhánh phải trực tiếp làm việc trên CoreBank để thực hiện hỗ trợ các khách hàng của chi nhánh khác. Điều này đã mang đến hai vấn đề lớn cho hệ thống là hiệu năng của hệ thống và rủi ro hệ thống.
Về mặt hiệu năng, khi khách hàng của VIB ngày càng tăng lên, các giao tác liên chi nhánh ngày càng nhiều nên việc tƣơng tác trực tiếp lên CoreBank làm hệ thống CoreBank dễ bị quá tải và bị “treo” gây ảnh hƣởng lớn đến toàn hệ thống của ngân hàng.
Về mặt rủi ro, cần phân quyền cho nhiều nhân viên ở các chi nhánh khác nhau đƣợc trực tiếp thâm nhập vào hệ thống CoreBank. Mặc dù có cơ chế kiểm soát các hoạt động của từng nhân viên trên hệ thống tuy nhiên việc có nhiều
nhân viên đƣợc vào tƣơng tác trực tiếp với hệ thống CoreBank làm cho việc kiểm soát trở nên khó khăn hơn và đôi khi phải mất một khoảng thời gian dài mới phát hiện ra lỗi.
Vì những lý do trên, cần phải xây dựng một cơ chế cho phép chia sẻ thông tin giữa các khác hàng liên chi nhánh giúp giảm tải cho hệ thống CoreBank cũng nhƣ tăng cƣờng đƣợc khả năng phục vụ khách hàng của các chi nhánh.
Các chức năng chính
Cho phép khách hàng đăng ký, mở tài khoản liên chi nhánh
Cho phép khách hàng đóng, mở sổ tiết kiệm, rút tiền, chuyển khoản liên chi nhánh
Cho phép khách hàng ghi nhận giấy tờ, in, sao kê báo cáo, hóa đơn thu phí liên chi nhánh
Hệ thống là “trong suốt” đối với ngƣời sử dụng ở các chi nhánh, các chức năng vẫn đƣợc sử dụng bình thƣờng.
Tổ chức đội dự án
Dự án áp dụng phƣơng thức phát triển phần mềm thống nhất RUP, trong đó, VIB thuê trọn gói đối tác Sungard thực hiện toàn bộ dự án InterBranch. Đây là một dự án quan trọng, ảnh hƣởng đến rất nhiều chức năng của hệ thống đang hoạt động.
Trong dự án này, bên VIB có hai bộ phận tham gia vào dự án là phòng Nghiệp Vụ thực hiện kiểm thử chấp nhận việc thực hiện của các chức năng và phòng Hệ Thống nhằm triển khai hệ thống đƣa vào hoạt động. Bên Sungard gồm 14 thành viên tham gia vào dự án và hoạt động độc lập với VIB. Trƣớc đó, việc phát triển dự án kết nối chi nhánh VIB_Branch đã đƣợc chính Sungard phát triển nên Sungard hiểu rất rõ các hệ thống hiện tại của VIB.
Lựa chọn kỹ thuật
Đây là dự án mở rộng tính năng của hệ thống đang tồn tại, do đó, về mặt kỹ thuật, hệ thống mới sẽ vẫn sử dụng công nghệ của hệ thống đang hoạt động là cơ sở dữ liệu Oracle kết hợp với Oracle Form/Report. Việc tƣơng tác liên chi nhánh sẽ sử dụng cơ chế truyền thông báo thông qua MiddleWare Tuxedo theo chuẩn
giao dịch ISO 8583 [21]. Để đảm bảo việc giảm tải giữa các chi nhánh, đội dự