1. 6 Điều kiện để áp dụng
2.2. Tổ chức phát triển phần mềm thuê ngoài với XP
2.2.1. Tổ chức khách hàng
Với việc áp dụng phƣơng thức phát triển phần mềm thuê ngoài, tổ chức doanh nghiệp cần phải xác định ra các nghiệp vụ kinh doanh chính của doanh nghiệp mình và những nghiệp vụ hỗ trợ. Đối với các nghiệp vụ hỗ trợ kinh doanh, doanh nghiệp có thể thực hiện thuê ngoài để tập trung vào các nghiệp vụ kinh doanh chính của mình.
Hình 2-1 Tổ chức khách hàng áp dụng thuê ngoài
Tùy theo đặc thù phát triển của từng doanh nghiệp mà có thể xác định các hoạt động nghiệp vụ phụ trợ khác nhau. Nhƣng thƣờng là các hoạt động nhƣ
quản trị doanh nghiệp, xử lý dữ liệu, hỗ trợ kết nối … là các hoạt động có thể thuê ngoài mang lại các lợi ích lớn lao cho doanh nghiệp.
2.2.2. Tổ chức đội phát triển thuê ngoài
Sau khi khảo sát một vài mô hình thực tế trong các doanh nghiệp cung cấp dịch vụ phát triển phần mềm thuê ngoài nhƣ CMC Soft, FPT Software, Tinh Vân tôi thấy có hai mô hình chính thƣờng đƣợc áp dụng là: Mô hình từ xa và mô hình tại chỗ. Sau đây tôi sẽ đi sâu hơn về hai mô hình này.
Mô hình từ xa (offsite/offshore models)
Hình 2-2 Mô hình từ xa
Lớp thứ nhất (offsite) thƣờng bao gồm một Trung tâm dịch vụ dự án (project services center), là điểm giao tiếp với khách hàng. Nhóm dịch vụ dự án đảm nhiệm:
- Phân tích (analysis) - Lập kế hoạch (planning)
- Cấu trúc kỹ thuật (technical architechture) - Thiết kế bậc cao (high-level design)
- Chuyển giao (delivery)
- Điều phối (coordination) mọi giao tiếp giữa khách hàng và Trung tâm thực hiện dự án (project execution center).
Lớp thứ hai (offshore) là Trung tâm thực hiện dự án thƣờng ở một khu vực hay nƣớc khác. Trung tâm từ xa này bao gồm một nhóm phát triển điều hành bởi giám đốc dự án. Nhóm thực hiện dự án đảm bảo các khâu:
- Thiết kế chi tiết (detailed design) - Xây dựng (construction)
- Kiểm tra (testing)
- Làm tài liệu (documentation)
Nhóm offsite thực hiện hầu hết quy trình thiết kế và khai thác trong khi nhóm offshore tập trung vào phát triển và kiểm tra.
Mô hình tại chỗ (onsite/offshore models)
Hình 2-3 Mô hình tại chỗ
Ở nơi mà bản chất dự án đòi hỏi sự kết hợp hay giao tiếp cao độ, mang tính liên tục hoặc khi có yêu cầu đặc biệt của khách hàng, mô hình tại chỗ đƣợc sử dụng. Giám đốc dự án làm việc tại chỗ với khách hàng, điều phối các hạng mục liên quan tới dự án giữa trung tâm phát triển từ xa và khách hàng. Sự có mặt tại chỗ này có thể chỉ đòi hỏi một nguồn lực đơn lẻ hoặc toàn bộ nhóm dịch vụ dự án, tùy theo bản chất, quy mô và độ phức tạp của công việc phát triển ban đầu. Đặc trƣng quan trọng của mô hình này là:
- Thành phần tại chỗ (onsite) có thể bao gồm một hay nhiều nguồn lực tùy vào quy mô và tính phức tạp của dự án. Phần lớn công việc có thể chuyển cho đơn vị thực hiện từ xa. Điều này có thể tiết kiệm chi phí cho khách hàng.
Cần chú ý rằng chẳng có hình thức tài liệu nào, dù dễ hiểu đến đâu, có thể trao ngay cho nhà cung cấp dịch vụ mà công ty có thể hoàn toàn an tâm mình sẽ nhận đƣợc những gì mình muốn. Các tài liệu tin cậy chỉ có thể là kết quả của quá trình kiểm tra và phân tích, thƣờng đƣợc đánh dấu bằng chuỗi tài liệu:
Yêu cầu đề xuất RFP: tài liệu này tìm hiểu khả năng của nhà cung cấp dịch vụ, mô tả các yêu cầu trên góc độ kinh doanh và góc độ sản phẩm, thiết lập một trục thời gian cho dự án và đƣa ra giá ƣớc tính.
Đề xuất các bƣớc công việc SOW: bắt đầu với các mô tả cao cấp về nhu cầu kinh doanh và giải pháp của nhà cung cấp dịch vụ, tính đến cả tình huống hệ thống sụp đổ. Tài liệu này cũng cần mô tả cơ chế chuyển giao, tiêu chí và thủ tục chấp nhận, kế hoạch thời gian và giá cung cấp giải pháp. SOW cũng bao gồm các vấn đề pháp lý và hợp đồng nhƣ quyền sở hữu tài sản, điều khoản và điều kiện thanh toán, giới hạn tin cậy...
Chi tiết yêu cầu kinh doanh và chi tiết chức năng: sau khi đƣợc chọn, nhà cung cấp thƣờng phải thực hiện phân tích các yêu cầu, tiếp xúc với những ngƣời điều hành và ngƣời sử dụng cuối cùng. Các đánh giá độc lập của họ sẽ giúp đảm bảo đáp ứng đúng nhu cầu kinh doanh. Thông qua phân tích, nhà cung cấp sẽ rà soát lại SWO bao gồm giá cho các bƣớc thiết kế, phát triển và khai thác rồi đƣa ra các chi tiết yêu cầu kinh doanh và chức năng. Yêu cầu kinh doanh cho biết sản phẩm là gì còn chi tiết chức năng trình bày cách làm ra sản phẩm đó.
Khách hàng và nhà cung cấp đều cần tôn trọng quy trình này. Ngoài chi tiết về sản phẩm, để dự án thành công, chi tiết về phƣơng thức phối hợp giữa hai bên đối tác cũng là yếu tố quyết định sự thành công. Cần chú ý rằng, sẽ là một thảm họa nếu khách hàng mô tả cái áo nhƣng chúng ta lại may cái quần cho khách hàng. Do đó, ngoài việc thu nhận thông tin khách hàng mô tả yêu cầu, đội dự án cũng cần thể hiện cho khách hàng của mình biết rằng mình đang làm cái gì và kết quả của công việc mình làm sẽ ra cái gì, có đúng ý khách hàng không.
2.2.3. Phân tách các nhóm trong dự án
Nhiều suy nghĩ truyền thống rằng việc phân tách các nhóm (đặc biệt là nhóm mới và nhóm cũ) là dựa trên các hoạt động mà các nhóm đó thực hiện. Vì vậy,
việc phân tích và thiết kế đƣợc thực hiện trên các đội gần với khách hàng hơn, còn việc phát triển, kiểm thử thƣờng đƣợc các nhóm mới, ít kinh nghiệm về hệ thống thực hiện. Điều này rõ ràng rất phù hợp với mô hình phát triển định hƣớng kế hoạch nhƣ mô hình thác nƣớc.
Trái lại, trong quá trình phát triển phần mềm theo XP, chúng ta có thể cải thiện vấn đề khi cho nhóm mới xử lý các hoạt động nhiều nhất có thể. Vì vậy họ làm đƣợc nhiều công việc phân tích và thiết kế nhất có thể, nhƣng chịu sự hạn chế bởi các yêu cầu đƣợc các nhóm cũ hoặc khách hàng đƣa ra. Khi chia nhỏ sự nỗ lực giữa các nhóm phát triển với nhau, theo XP thì cần phải làm điều này theo chức năng chứ không phải là căn cứ hoạt động. Chúng ta cần chia hệ thống thành các khối mã nguồn mở rộng và cho phép các thành viên mới giải quyết một số trong những khối mã nguồn này. Tuy nhiên không giống nhƣ hầu hết các nhóm đã làm việc này, XP không thực hiện một nỗ lực lớn nào để thiết kế và cố định các giao diện giữa các phân hệ: tích hợp liên tục và quyền sở hữu mã nguồn yếu cho phép các giao diện của khối mã nguồn đƣợc phát triển liên tục giống nhƣ mã nguồn.
Hình 2-4 Phân tách nhóm trong XP
Một phần quan trọng của việc này là để các nhóm cùng phân tích các tính năng. Việc càng nhiều ngƣời ở trong các nhóm hiểu đƣợc nghiệp vụ và các yêu cầu cần phát triển, thì càng có nhiều nhóm có thể phát triển hiệu quả. Thay vì phải chờ đợi khách hàng hay nhóm phân tích, thiết kế để trả lời một câu hỏi, nhóm phát triển có thể nhận đƣợc câu trả lời ngay lập tức và loại bỏ đƣợc các khúc mắc để cùng phát triển. Điều này cần có thời gian, nhƣng những kiến thức
chuyên môn là một phần quan trọng để hiểu và áp dụng các kiến thức nghiệp vụ vào công việc.
2.2.4. XP tổ chức nhóm phát triển thuê ngoài
Nhƣ đã nêu ở phần trên, XP phân chia các nhóm theo chức năng, trong nhóm sẽ tự tổ chức, do đó, cấu trúc nhóm trong XP rất linh hoạt, tuy theo yêu cầu của khách hàng mà nhóm sẽ cần các vai trò với các kỹ năng khác nhau để thực hiện dự án. Trong một nhóm phát triển XP có thể bao gồm đủ các thành viên với các vai trò nhà phân tích, thiết kế, phát triển hay kiểm thử hoặc có thể thêm các thành viên khác nếu cần.
Với việc phát triển thuê ngoài, XP khuyến khích các thành viên trong nhóm có thể đảm nhận nhiều vai trò khác nhau trong nhóm phát triển. Đồng thời XP khuyến khích các thành viên có kinh nghiệm thay vì tăng số lƣợng ngƣời trong một nhóm và giới hạn số thành viên tối đa trong một nhóm là 20 ngƣời để đảm bảo việc giao tiếp giữa các thành viên trong nhóm và với các nhóm khác đƣợc thuận lợi. Đặc biệt, với vai trò ngƣời đại diện khách hàng và đại diện nhóm giao thiệp với các nhóm khác, XP khuyến khích đƣa ngƣời mới đi kèm với những ngƣời có kinh nghiệm để việc truyền thông đƣợc thông suốt và giúp ngƣời mới hiểu đƣợc mong muốn của khách hàng.
2. 3. Truyền thông trong dự án thuê ngoài
Nhƣ đã nêu ở phần trên, phƣơng pháp lập trình cực hạn đòi hỏi việc truyền thông phải thông suốt từ khách hàng tới các lập trình viên. Theo XP, quá trình truyền thông phải thật thuận tiện và dễ dàng, cho phép mọi ngƣời trong đội dự án (kể cả khách hàng) có thể trao đổi bất cứ lúc nào nếu cần. Tuy nhiên, việc truyền thông trong XP đƣợc chia ra ở nhiều mức (theo thời gian) từ mức diễn ra vài tháng một lần trong kế hoạch bàn giao hay mức vài tuần một lần trong kế hoạch lặp hàng tuần của đội dự án đến mức vài giờ trong đàm phán giữa cặp lập trình viên về cách thức phát triển một chức năng hoặc mức từng giây một trong quá trình trao đổi của cặp lập trình viên khi phát triển. Ở mọi mức XP khuyến nghị việc truyền thông phải trực tiếp, mặt đối mặt để đảm bảo hiệu quả cao nhất trong thời gian ngắn nhất.
Hình 2-5 Truyền thông trong XP
Trong việc phát triển phần mềm thuê ngoài, việc trao đổi trực tiếp giữa đội dự án và khách hàng diễn ra khó khăn hơn, đặc biệt là với các dự án lớn, nhiều nhóm cùng tham gia, việc truyền thông giữa các nhóm cũng là một vấn đề cần quan tâm và phải đƣợc xem xét ở nhiều khía cạnh. Đầu tiên, việc lấy ý kiến và nhận phản hồi từ khách hàng dựa trên việc tích hợp liên tục đối với các dự án thuê ngoài và có nhiều nhóm cùng tham gia cũng có những khó khăn mà tôi sẽ đề cập trongphần “2.3.1 Nhận phản hồi từ khách hàng”. Tiếp đến, tôi muốn đề cập đến việc giao tiếp giữa các nhóm trong đội dự án, đặc biệt là vấn đề các nhóm không ở cùng một địa điểm hoặc các nhóm không thuộc một công ty hay một đơn vị quản lý trong phần “2.3. 2 Truyền thông giữa các nhóm”. Sau đó tôi sẽ đề cập đến việc truyền thông trong nhóm với việc áp dụng các cuộc họp ngắn mà XP hay gọi là “Họp đứng” trong phần “2.3.3 Truyền thông trong nhóm”. Cuối cùng tôi sẽ nói đến việc sử dụng các phƣơng tiện truyền thông khác nhau trong phần “2.3.4 Công cụ truyền thông”.
2.3.1. Truyền thống với khách hàng
Khi mọi ngƣời xem xét các yêu cầu đƣợc thu thập bằng các phƣơng pháp lập trình cực hạn XP, họ thƣờng không thấy đƣợc tầm quan trọng của chu trình phản hồi. Thƣờng thì quá trình yêu cầu đƣợc thấy khi các nhà phân tích cung cấp các yêu cầu, và các nhà phát triển nhận yêu cầu và thực hiện các chức năng. Cuối cùng, một ngƣời kiểm tra để xem các nhà phát triển đã thực hiện đƣợc những gì họ đƣợc yêu cầu chƣa. Trên một dự án áp dụng XP, sự gần gũi chặt chẽ giữa khách hàng và phát triển cho phép các khách hàng theo dõi tiến độ thƣờng
xuyên hơn, cho phép họ phát hiện những hiểu lầm sớm hơn và nhanh hơn. Ngoài ra một hệ thống phát triển một phần cũng có thể giúp khách hàng hiểu có sự khác biệt giữa những gì của yêu cầu và những gì cần thiết - và thƣờng là không đƣợc thể hiện rõ ràng ra cho đến khi có một vài phần mềm làm việc.
Việc xây dựng tích hợp thông xuyên cho phép một khách hàng có thể lấy về và sử dụng thử. Mặc dù điều này không hoàn toàn nhƣ là ngay lập tức nhƣ việc cùng làm ở một địa điểm, nhƣng nó vẫn cho phép các khách hàng để sửa bất kỳ sự hiểu lầm nào một cách nhanh chóng, và cũng giúp họ hiểu biết sâu sắc hơn về các yêu cầu của mình.
Để làm công việc này, điều quan trọng là cần phân loại các vấn đề môi trƣờng để các đội và khách hàng có cùng bản môi trƣờng. Không có gì tệ hơn việc khách hàng hay đội khác lấy chƣơng trình xuống từ kho chứa mã nguồn và xây dựng trên hệ thống của họ, họ phát hiện vấn đề, và các đội còn lại lại không có khả năng lặp lại các vấn đề mà khách hàng hay đội khách gặp phải do các vấn đề môi trƣờng cấu hình. Cần đảm bảo chắc chắn rằng vấn đề môi trƣờng đƣợc loại ra sớm nhất có thể, và đảm bảo một ngƣời nào đó xung quanh để sửa chữa bất kỳ vấn đề môi trƣờng nếu chúng xuất hiện. Vấn đề môi trƣờng đặc biệt nghiêm trọng khi mà yêu cầu phát triển phần mềm cần phải đáp ứng đƣợc trên nhiều hệ thống khác nhau ví dụ nhƣ trên các hệ điều hành khác nhau, trên các trình duyệt (browser) khác nhau...
Cần đảm bảo rằng mọi ngƣời có thể nhìn thấy đƣợc những gì đƣợc thƣờng xuyên xây dựng, thậm chí nếu nó chỉ là một phần chức năng. Càng sớm thấy đƣợc các phần của công việc, chúng ta càng sớm phát hiện ra bất kỳ thiếu sót nào trong quá trình trao đổi. Thƣờng mọi ngƣời thích chờ đợi cho đến khi một cái gì đó là hoàn thành trƣớc khi thể hiện nó cho ngƣời khác xem. Tuy nhiên, trong tình huống này, nó không đáng để chờ đợi, chúng ta nên tìm cách thể hiện cái mà chúng ta định làm và kết quả chúng ta làm đƣợc để khách hàng, các đội khác cũng nhƣ mọi ngƣời trong đội có thể nắm bắt đƣợc càng tốt.
Phƣơng pháp lập trình cực hạn luôn khuyến khích nhóm phát triển có một bản thử nghiệm cho khách hàng vào cuối mỗi lần lặp. Chúng tôi đã sử dụng cách thức này khá rộng rãi và hiện nay, chúng tôi gọi nó là một bản giới thiệu. Với đội ở xa chúng tôi muốn làm một trình diễn từ xa, nơi mà các nhà phát triển ở đó cho thấy các tính năng mới trong phần mềm với sự trợ giúp của phần mềm máy tính từ xa. Để nhóm nghiên cứu ở xa làm điều này là một ví dụ khác của việc
mọi cơ hội để xây dựng mối liên kết giữa các đội ở cùng địa điểm và ở xa, giữa các nhà phát triển và khách hàng.
2.3.2. Truyền thông giữa các nhóm Gửi ngƣời đại diện đến các đội khác Gửi ngƣời đại diện đến các đội khác
Nhƣ tôi đã nói ở trên, phƣơng pháp lập trình cực hạn nhấn mạnh tầm quan trọng của tƣơng tác mặt đối mặt. Ngay cả nếu mọi ngƣời không thể đồng thời ở một địa điểm thì việc di chuyển một số ngƣời sẽ giúp làm sáng tỏ rất nhiều vấn đề. Ngay từ đầu chúng ta cần đảm bảo rằng ở bất kỳ thời điểm nào cũng có ai đó đại diện đội chính ở các đội khác để tạo thuận lợi cho giao tiếp. Nhƣ một đại sứ đã biết mọi ngƣời và bổ sung thêm địa chỉ liên hệ cá nhân của mình để giúp giao tiếp với mọi ngƣời [13].
Chúng tôi bây giờ mở rộng cách thức này ở nhiều cấp độ. Chúng tôi tìm thấy nó hữu ích để gửi một nhà phát triển và một nhà phân tích sang đội còn lại để giao tiếp trên cả hai phƣơng diện yêu cầu nghiệp vụ và kỹ thuật. Nó cũng có giá trị để nhận một ngƣời từ đội còn lại sang đội mình.
Một trong những lợi ích của một đại sứ thiên về nghiệp vụ về đội thuê ngoài