Nghiên cứu phương pháp lập trình cực hạn áp dụng cho các dự án thuê ngoài

Trong xu thế phát triển phần mềm thuê ngoài ngày càng nhiều, việc áp dụng các phương pháp phát triển hạng nặng đang trở nên khó khăn khi phát triển phần mềm thuê ngoài hướng tới hình thứ

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LỜI CẢM ƠN

Tôi xin được gửi lời cảm ơn sâu sắc tới Trung tâm Đào tạo Sau đại học và các thầy cô giáo trong Khoa Công Nghệ Thông Tin, Trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy và truyền đạt những kiến thức, những kinh nghiệm quý báu trong suốt 2 năm học Cao học

Tôi xin bày tỏ lòng cảm ơn chân thành tới tất cả các bạn bè, các thầy cô giáo, các đồng nghiệp Khoa Công Nghệ Thông Tin, Trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội đã động viên, tạo điều kiện cho tôi trong suốt thời gian thực hiện luận văn này

Đặc biệt, tôi xin gửi lời cảm ơn sâu sắc nhất tới PGS.TS Đỗ Trung Tuấn, Khoa Toán Cơ Tin học, Trường Đại học Khoa học Tự nhiên, Đại học Quốc Gia

Hà Nội, người thầy đã định hướng đề tài và tận tình hướng dẫn chỉ bảo tôi trong suốt quá trình thực hiện luận văn cao học này

Cuối cùng tôi xin dành một tình cảm biết ơn tới Bố, Mẹ và gia đình, những người đã luôn luôn ở bên cạnh tôi, động viên, chia sẻ cùng tôi trong suốt thời gian học cao học cũng như quá trình thực hiện luận văn cao học

Hà Nội, ngày 10 tháng 05 năm 2011

Nguyễn Oen

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi Các kết quả nêu trong bản luận văn này là trung thực và chƣa từng đƣợc ai công bố trong bất cứ công trình nào khác

Hà Nội, ngày 10 tháng 05 năm 2011

Nguyễn Oen

MỤC LỤC

LỜI CẢM ƠN i

LỜI CAM ĐOAN ii

MỤC LỤC iii

DANH MỤC KÝ HIỆU, TỪ VIẾT TẮT vi

DANH MỤC HÌNH VẼ vii

PHẦN MỞ ĐẦU 1

0 1 Tính cấp thiết của đề tài 1

0 2 Mục đích nghiên cứu 2

0 3 Đối tượng và phạm vi nghiên cứu 3

0 4 Phương pháp nghiên cứu 4

0 5 Cơ sở lý luận và thực tiễn 4

0 6 Đóng góp của đề tài 4

0 7 Kết cấu đề tài 5

Chương 1 TỔNG QUAN PHƯƠNG PHÁP LẬP TRÌNH CỰC HẠN 6

1 1 Khái niệm phương pháp lập trình cực hạn 6

1 2 Các nguyên tắc của XP: 7

1.2.1 Nguyên tắc trao đổi 7

1.2.2 Nguyên tắc phản hồi 8

1.2.3 Nguyên tắc đơn giản 8

1.2.4 Nguyên tắc tôn trọng 8

1.2.5 Nguyên tắc dũng cảm 8

1 3 Các phương pháp thực hành 9

1.3.1 Khách hàng cùng tham gia 9

1.3.2 Lập kế hoạch liên tục 10

1.3.3 Phát hành từng phần 10

1.3.4 Lập trình theo cặp 11

1.3.5 Phát triển định hướng kiểm thử 12

1.3.6 Tích hợp liên tục 13

1.3.7 Tái cấu trúc hệ thống 14

1.3.8 Sở hữu tập thể 15

1.3.9 Thiết kế đơn giản 16

1.3.10 Hệ thống ký pháp 17

1.3.11 Làm việc lâu bền 17

1.3.12 Chuẩn hóa mã nguồn 18

1 4 Vòng đời phương pháp phát triển XP 19

1.4.1 Khám phá yêu cầu 19

1.4.2 Pha lập kế hoạch 21

1.4.3 Pha lặp để phát hành 24

1.4.4 Pha xuất xưởng 24

1.4.5 Pha bảo trì 25

1.4.6 Pha kết thúc 25

1 5 Đội dự án XP 25

1.5.1 Đại diện khách hàng 25

1.5.2 Người quản lý sản phẩm 26

1.5.3 Các chuyên gia nghiệp vụ 27

1.5.4 Người thiết kế giao diện 27

1.5.5 Lập trình viên 27

1.5.6 Người kiểm thử 28

1.5.7 Quản lý dự án/Hướng dẫn viên 28

1.5.8 Các thành viên khác 28

1 6 Điều kiện để áp dụng 29

Chương 2 PHẦN MỀM THUÊ NGOÀI VÀ XP 31

2 1 Dịch vụ thuê ngoài 31

2.1.1 Khái niệm dịch vụ thuê ngoài 31

2.1.2 Lợi thế của dịch vụ thuê ngoài 31

2.1.3 Phát triển phần mềm thuê ngoài 33

2.1.4 Phát triển phần mềm thuê ngoài với XP 36

2 2 Tổ chức phát triển phần mềm thuê ngoài với XP 37

2.2.1 Tổ chức khách hàng 37

2.2.2 Tổ chức đội phát triển thuê ngoài 38

2.2.3 Phân tách các nhóm trong dự án 40

2.2.4 XP tổ chức nhóm phát triển thuê ngoài 42

2 3 Truyền thông trong dự án thuê ngoài 42

2.3.1 Truyền thống với khách hàng 43

2.3.2 Truyền thông giữa các nhóm 45

2.3.3 Truyền thông trong nhóm 48

2.3.4 Công cụ truyền thông 49

2 4 Quản lý cấu hình cho XP 51

2.4.1 Tiến trình thường nhật 52

2.4.2 Tiến trình tìm giải pháp 52

2.4.3 Tiến trình tái cấu trúc 52

2.4.4 Tiến trình phát hành 53

2 5 Các vấn đề khác 54

2.5.1 Biến đổi văn hóa doanh nghiệp 54

2.5.2 Bổ xung thêm nhóm mới 55

2.5.3 Viết tài liệu dự án 55

Chương 3 ỨNG DỤNG XP TRONG DỰ ÁN THUÊ NGOÀI 57

3 1 Môi trường áp dụng 57

3 2 Mô hình tổ chức 57

3 3 Các dự án thực nghiệm 59

3.5.1 Dự án tương tác liên chi nhánh InterBranch 59

3.5.1 Dự án bảng khai báo công việc TimeSheet 64

3.5.2 Dự án lập kế hoạch toàn hàng VIB_Planing 69

3.5.3 Dự án ngân hàng điện tử VIB4U 73

3 4 Đánh giá chung 78

KẾT LUẬN 81

TÀI LIỆU THAM KHẢO 82

Tiếng việt 82

Tiếng anh 82

DANH MỤC KÝ HIỆU, TỪ VIẾT TẮT

BPO Business process

RFP Request For Proposal Yêu cầu đề xuất

SOW Statement Of Work Đề xuất các bước công việc

XP eXtreme Programming Lập trình cực hạn hay lập trình cường độ cao

VIB Việt Nam International

Bank

Ngân Hàng Quốc Tế VIB

OTP One Time Password Mã số được dùng 1 lần duy nhất

RUP Rational Unified

Process

Quy trình phát triển phần mềm thống nhất

DANH MỤC HÌNH VẼ

Hình 0-1 Tiêu chí thành công của dự án phần mềm 3

Hình 1-1 Các phương pháp thực hành trong XP 19

Hình 1-2: Vòng đời dự án theo XP 19

Hình 1-4 Pha khám phá yêu cầu 20

Hình 1-5 Pha lập kế hoạch 22

Hình 1-6 Lên kế hoạch phát hành 23

Hình 1-7 Lên kế hoạch bước lặp 24

Hình 2-1 Tổ chức khách hàng áp dụng thuê ngoài 37

Hình 2-2 Mô hình từ xa 38

Hình 2-3 Mô hình tại chỗ 39

Hình 2-4 Phân tách nhóm trong XP 41

Hình 2-5 Truyền thông trong XP 43

Hình 2-6: Vấn đề tích hợp 53

Hình 3-1 Mô hình tổ chức chuyên trách dự án 57

Hình 3-2 Mô hình tổ chức theo chức năng 58

Hình 3-3 Mô hình tổ chức theo dạng ma trận 59

Hình 3-4 Biểu đồ đánh giá kết quả dự án 79

PHẦN MỞ ĐẦU

0 1 Tính cấp thiết của đề tài

Trong những năm gần đây, khi công nghệ thông tin càng ngày càng phát triển, phần mềm thực sự trở thành một phần không thể thiếu trong các doanh nghiệp Mỗi bộ phận trong mỗi doanh nghiệp đều phụ thuộc vào phần mềm để

hỗ trợ việc phát triển, sản xuất, quảng cáo và tiếp thị các sản phẩm và dịch vụ của họ Với tốc độ phát triển đến chóng mặt của lĩnh vực công nghệ thông tin và truyền thông trên cả các hệ thống phần cứng và phần mềm nhằm đáp ứng nhu cầu ngày càng phức tạp của công việc cũng như cuộc sống đòi hỏi phải có những phương pháp phát triển tốt hơn nhằm đảm bảo cho sự thành công của các

dự án công nghệ thông tin

Theo thống kê của Standish Group, Mỹ (2000) [6]: Trên 350 công ty với hơn

8000 dự án phần mềm có: 31% dự án phần mềm bị huỷ bỏ trước khi được hoàn thành Với các công ty lớn, chỉ có khoảng 9% tổng số các dự án hoàn thành đúng tiến độ và trong ngân sách dự án (với các công ty nhỏ, tỷ lệ này vào khoảng 16%)

Báo cáo của Ngân hàng thế giới cho biết, 85% các dự án tin học hoá quản lý hành chính ở các nước đang phát triển đã thất bại hoặc một phần hoặc hoàn toàn Ở Việt Nam, điển hình là đề án 112 – đề án tin học hóa công tác quản lý nhà nước đã gặp thất bại hoàn toàn Và còn rất nhiều các dự án tin học khác cũng gặp thất bại, chậm triển khai, không đạt được mục tiêu đề ra[4]

Việc phát triển phần mềm thỏa mãn chất lượng, tiến độ, và kinh phí là rất khó, đòi hỏi rất nhiều yếu tố trong đó việc áp dụng một phương pháp phát triển thích hợp là một trong những nhân tố mang tính quyết định đến thành công của

dự án Hiện nay có rất nhiều các phương pháp phát triển dự án đang được áp dụng trong các doanh nghiệp phát triển phần mềm ở Việt Nam từ phương pháp phát triển hạng nặng được thiết lập trên các tiêu chuẩn ISO9001, mô hình trưởng thành về năng lực - CMMI, quy trình phát triển phần mềm thống nhất (Rational Unified Process) đến các phương pháp phát triển hạng nhẹ như phương pháp lập trình cực hạn – XP, phát triển phần mềm có khả năng thích nghi, Trong xu thế phát triển phần mềm thuê ngoài ngày càng nhiều, việc áp dụng các phương pháp phát triển hạng nặng đang trở nên khó khăn khi phát triển phần mềm thuê ngoài hướng tới hình thức dịch vụ - các yêu cầu được thay đổi liên tục theo nhu cầu của khách hàng – làm cho vấn đề giá thành cho sự thay đổi bị đội lên rất cao

Trước vấn đề đó, việc áp dụng các phương pháp phát triển hạng nhẹ cho các dịch vụ phát triển phần mềm thuê ngoài nhằm giải quyết vấn đề thay đổi liên tục của yêu cầu người dùng đang nhận được sự quan tâm của đông đảo các nhà phát triển, các doanh nghiệp phần mềm trong nước Đặc biệt là phương pháp lập trình cực hạn đã nhận được sự quan tâm nhiều nhất vì nó đã đề ra hai mục tiêu rất rõ ràng và cần thiết cho việc phát triển công nghệ phần mềm:

 Một là phát triển sản phẩm một cách nhanh chóng: Với sự phát triển

hiện nay của nền kinh tế dựa trên tri thức, doanh nghiệp nào đưa sản phẩm ra thị trường nhanh nhất sẽ chiếm được thị phần có lợi nhất Phương pháp lập trình cực hạn sẽ giúp cho các nhà phát triển phần mềm rút ngắn thời gian phát triển sản phẩm

 Hai là phát triển sản phẩm đúng theo yêu cầu của khách hàng: Thực

tế cho thấy rằng nhiều sản phẩm phần mềm tuy được phát triển một cách công phu nhưng lại không đáp ứng được nhu cầu của người sử dụng Phương pháp lập trình cực hạn đã đưa ra các cơ chế cho phép sản phẩm phát triển luôn phù hợp với yêu cầu của người sử dụng

Tuy nhiên việc áp dụng phương pháp lập trình cực hạn vào việc phát triển phần mềm thuê ngoài vẫn có những trở ngại làm cho các nhà phát triển, doanh nghiệp phần mềm nghi ngại Nắm bắt tính cấp bách của việc áp dụng phương pháp lập trình cực hạn trong việc phát triển phần mềm thuê ngoài đã thôi thúc

em chọn đề tài: “Nghiên cứu phương pháp lập trình cực hạn áp dụng cho các dự

án thuê ngoài” nhằm nghiên cứu sâu hơn về phương pháp lập trình cực hạn và tìm cách áp dụng vào việc phát triển phần mềm thuê ngoài

0 2 Mục đích nghiên cứu

Đề tài được đưa ra nhằm mục đích chính là làm sao có thể áp dụng phương pháp lập trình cực hạn vào các dự án thuê ngoài thành công Theo quan niệm truyền thống, một dự án phần mềm được coi là thành công khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng Trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng Do đó, ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi là thành công khi thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty

Hình 0-1 Tiêu chí thành công của dự án phần mềm

 Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm làm việc say mê, phát triển khả năng cá nhân, mong muốn đóng góp công sức

và trí tuệ cho nhóm và tổ chức

 Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của sản phẩm Thành công về kỹ thuật cũng làm tăng chất lượng sản phẩm, tăng hiệu quả phát triển sản phẩm

 Thành công ở mức công ty được bảo đảm nhờ các thành công mà các nhóm mang lại cho công ty Ở mức này, thành công của công ty là sự đóng góp của tất cả các thành viên vào sự phát triển của công ty

Do đó, đề tài sẽ tập trung trả lời các câu hỏi:

 Đặc trưng của phương pháp lập trình cực hạn là gì?

 Tại sao áp dụng phương pháp lập trình cực hạn cho các dự án thuê ngoài?

 Làm sao để phát triển thành công các dự án dự án thuê ngoài theo phương pháp lập trình cực hạn?

0 3 Đối tượng và phạm vi nghiên cứu

Nhằm áp dụng thành công phương pháp lập trình cực hạn vào các dự án thuê ngoài, đề tài xác định đối tượng chính cần nghiên cứu là phương pháp phát triển phần mềm cực hạn trong phạm vi các dự án thuê ngoài Bằng cách đặt vào môi trường phát triển một dự án phần mềm cụ thể giúp cho phạm vi nghiên cứu được

cụ thể hơn, rõ ràng hơn nhưng chúng ta hoàn toàn có thể áp dụng cho các dự án phần mềm phát triển phần mềm thuê ngoài khác bằng cách tổng quát hóa và lược bỏ đi các chi tiết riêng biệt mang tính môi trường doanh nghiệp

0 4 Phương pháp nghiên cứu

Dựa trên việc ứng dụng các lý luận phát triển phần mềm vào thực tiễn và đúc rút ra các cách thức và kinh nghiệm nhằm chia sẻ cho cộng đồng cách thức phát triển phần mềm thích hợp trong các dự án cụ thể nhằm giúp các nhà phát triển, các doanh nghiệp phần mềm có những cách thức giải quyết những vướng mắc trong quá trình áp dụng phương thức phát triển phần mềm cực hạn cho các dự án thuê ngoài

0 5 Cơ sở lý luận và thực tiễn

Về cơ sở lý thuyết, phương pháp lập trình cực hạn dựa trên triết lý phát triển phần mềm linh hoạt và hệ thống công cụ hỗ trợ ngày càng phát triển, phương pháp lập trình cực hạn đã phát triển thành một phương pháp hoàn thiện, nhận được sự quan tâm lớn của các nhà phát triển cũng như các tổ chức phát triển phần mềm Và thực tế cũng đã chứng minh những thành công của phương pháp lập trình cực hạn với việc phát triển các phần mềm có chất lượng tốt, đạt được

sự hài lòng cao của khách hàng

Với đặc điểm của việc phát triển phần mềm thuê ngoài là phát triển các tính năng phù hợp nhất với các yêu cầu của khách hàng mà các yêu cầu của khách hàng thường xuyên thay đổi thì việc áp dụng phương pháp lập trình cực hạn dường như là một giải pháp hết sức hợp lý Và thực tế là qua các dự án bước đầu

áp dụng phương pháp lập trình cực hạn, mặc dù còn gặp một vài khó khăn vướng mắc nhưng đã gặp hái được khá nhiều thành công, đưa ra được những sản phẩm phù hợp với yêu cầu của khách hàng được khách hàng và được khách hàng đánh giá cao

0 6 Đóng góp của đề tài

Việc áp dụng phương pháp lập trình cực hạn thành công vào việc phát triển phần mềm thuê ngoài thực sự là một đóng góp quan trọng cho các tổ chức thuê ngoài và cung ứng dịch vụ thuê ngoài Điều này giúp cho khách hàng có được phần mềm đúng như mong muốn, giúp cho tổ chức áp dụng được một phương thức phát triển phần mềm tốt, góp phần đảm bảo thành công cho việc phát triển phần mềm, giúp cho lập trình viên phát triển được các kỹ năng chuyên môn và tăng cường khả năng giao tiếp không chỉ trong đội mà cả với khách hàng

Hơn nữa, việc áp dụng thành công phương pháp lập trình cực hạn vào việc phát triển phần mềm thuê ngoài còn mở ra tiềm năng áp dụng phương pháp lập

trình cực hạn vào các dự án phát triển phần mềm phân tán, nhiều nhóm cùng phát triển hoặc phát triển các phần mềm mã nguồn mở

Chương 1 TỔNG QUAN PHƯƠNG PHÁP LẬP TRÌNH CỰC HẠN

1 1 Khái niệm phương pháp lập trình cực hạn

Phương pháp lập trình cực hạn (XP) là một phương pháp phát triển phần mềm tuân thủ triết lý phát triển phần mềm linh hoạt (Agile) XP là phương thức lấy người lập trình làm trung tâm, nhấn mạnh đến các phương pháp kỹ thuật phát triển phần mềm XP sử dụng nhóm nhỏ làm việc kết hợp bao gồm những người lập trình, khách hàng, và các nhà quản trị để phát triển phần mềm có chất lượng cao trong khoảng thời gian nhanh chóng

Thước đo đầu tiên của phương pháp lập trình cực hạn là một chương trình chạy được Từ thước đo này, XP xây dựng năm nguyên tắc cần thiết cho sự thành công là: sự giao tiếp, sự phản hồi, đơn giản hóa, sự tôn trọng và sự dũng cảm Có thể diễn giải các nguyên tắc trên như sau: “Một chương trình chạy được

và cung cấp ngay cho khách hàng để nhận được các phản hồi cũng như các đề xuất thay đổi từ phía khách hàng, người phát triển sẵn sàng, dũng cảm nhận các thay đổi về yêu cầu, môi trường và công nghệ để phát triển ra sản phẩm phù hợp nhất với yêu cầu người dùng Để làm được điều này, người phát triển phải luôn luôn giao tiếp với khách hàng cũng như đồng đội của họ để đảm bảo mọi người đều hiểu công việc cần làm là như nhau và kết quả mong muốn là giống nhau Đồng thời, họ phải thiết kế sao cho thật đơn giản và rõ ràng để dễ dàng truyền đạt lại việc mình đang làm và sẽ làm cho đồng đội, người dùng hiểu được Một điều hết sức quan trọng nữa là việc tôn trọng những giá trị thu được dù là nhỏ nhất Áp dụng XP đòi hỏi đội dự án phải tôn trọng ý kiến đánh giá phản hồi của người dùng; người dùng phải tôn trọng những giá trị mà đội dự án cung cấp vì

đó chưa phải là sản phẩm cuối cùng nhưng nó hàm chứa những cố gắng và nỗ lực phát triển của đội dự án.” Trong phần “1.2 Các nguyên tắc của XP” tôi sẽ đi sâu hơn vào từng nguyên tắc

Để đạt được các giá trị mà những nguyên tắc ở trên đã đề ra cũng như đảm bảo cho việc phát triển thành công dự án, XP đã xây dựng các phương pháp thực hành Các phương pháp thực hành đơn giản và hiệu quả kết hợp linh hoạt với nhau đảm bảo đội dự án phát triển đúng hướng, giữ được các giá trị mà các nguyên tắc đã đề ra Trong phần “1.3 Các phương pháp thực hành” tôi sẽ đề cập đến từng phương pháp thực hành cụ thể của XP

Phương pháp lập trình cực hạn hoạt động theo mô hình lặp, tăng trưởng Sản phẩm được chia ra thành các phần tăng trưởng nhỏ, mỗi phần được phát triển

trong vòng một hoặc vài tuần gọi là một vòng lặp Với mỗi phần tăng trưởng, đội dự án thực hiện tất cả các hoạt động: tìm hiểu yêu cầu, lập kế hoạch, phân tích, thiết kế, lập trình, kiểm thử và phát hành Các hoạt động này gọi là các pha Mỗi pha chỉ kéo dài từ vài ngày đến một vài tuần Với tiến trình hoạt động này, đội dự án sẽ nhanh chóng nhận được phản hồi của khách hàng cũng như áp dụng những thay đổi cần thiết trong các lần tăng trưởng tiếp theo Trong phần “1.4 Vòng đời của phương pháp phát triển XP” tôi sẽ đề cập sâu hơn về vòng đời phát triển của XP

Trong một dự án phần mềm, những hiểu biết về sản phẩm luôn được nắm giữ bởi nhiều cá nhân XP thừa nhận thực tế này bằng cách tạo ra một nhóm làm việc hỗn hợp với đầy đủ các vai trò cần thiết Một đội dự án XP thường được lập

và hoạt động theo kiểu tự tổ chức dựa trên các giai đoạn và công việc khác nhau Tôi sẽ đề cập về vấn đề này trong phần “1.5 Đội dự án XP”

1 2 Các nguyên tắc của XP:

XP phát triển dựa trên các quy tắc Nhưng XP không là một bộ quy tắc mà là một cách để làm việc hài hòa với các giá trị cá nhân và doanh nghiệp Bắt đầu với các nguyên tắc được liệt kê ở dưới đây, sau đó tùy từng dự án mà đội dự án

có thể thêm các nguyên tắc riêng bằng cách thể hiện những nguyên tắc của XP trong những thay đổi theo nguyên tắc của dự án[1]

1.2.1 Nguyên tắc trao đổi

Phương pháp lập trình cực hạn chú trọng việc trao đổi thông tin một cách

“trong suốt” giữa các thành viên trong nhóm phát triển Đề cao việc trao đổi trực

tiếp, giảm việc trao đổi gián tiếp hay hình thức thông qua các văn bản Việc trao đổi trực tiếp được yêu cầu rất cao, đặc biệt là trong các lần trao đổi với khách hàng, giữa các đội Trong XP, việc trao đổi trực tiếp được diễn ra liên tục, với các lập trình viên là từng giây, từng phút họ làm việc cùng nhau như được nêu trong phần “1.3.4 Lập trình theo căp”

Với phương pháp lập trình cực hạn, khách hàng tham gia trực tiếp vào việc thực hiện dự án với tư cách là một thành viên chính thức của nhóm phát triển Khách hàng sẽ giúp nhóm phát triển hiểu và nắm bắt được và kịp thời các yêu cầu của người sử dụng (cũng như sự thay đổi về yêu cầu) trong suốt quá trình thực hiện dự án Đồng thời, tất cả các thành viên đều tham gia vào mọi hoạt

động trong quá trình phát triển phần mềm Điều này sẽ nâng cao tính năng động của toàn bộ nhóm phát triển

1.2.2 Nguyên tắc phản hồi

Phản hồi sớm và liên tục từ khách hàng cũng như từ nhóm phát triển giúp cho dự án luôn đi theo đúng hướng Phương pháp lập trình cực hạn đều đặn giao sản phẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể 'làm mịn' và hoàn thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể Với sự trợ giúp của khách hàng, các nhà phát triển theo phương pháp lập trình cực hạn xây dựng một tập các phép thử phục vụ cho việc kiểm thử nghiệm thu một cách liên tục trong suốt quá trình phát triển phần mềm

Nguyên tắc trao đổi và nguyên tắc phản hồi là hai nguyên tắc tương trợ lẫn nhau Từ việc trao đổi trực tiếp giúp cho đội dự án cũng như khách hàng hiểu nhau hơn, nắm được yêu cầu và công việc đang tiến hành và từ đó đưa ra được các phản hồi tích cực giúp cho đội dự án hiểu công việc mình cần làm hơn

1.2.3 Nguyên tắc đơn giản

Phương pháp lập trình cực hạn đảm bảo chỉ phát triển những chức năng cần thiết và những chức năng mà khách hàng yêu cầu Phần thiết kế và mã nguồn được thiết lập một cách đơn giản nhất, cho phép có được đặc tính mở cao nhằm đáp ứng với các thay đổi liên tục và luôn duy trì được một tốc độ phát triển nhanh trong suốt quá trình phát triển phần mềm

1.2.4 Nguyên tắc tôn trọng

Mọi người cho và cảm nhận được sự tôn trọng xứng đáng với những gì họ đã cống hiến Tất cả mọi người đóng góp giá trị ngay cả khi nó chỉ đơn giản là sự nhiệt tình Các nhà phát triển tôn trọng chuyên môn của khách hàng và ngược lại Nhà quản lý tôn trọng quyền nhận trách nhiệm của nhà phát triển và trao quyền để họ thực hiện công việc của chính họ

1.2.5 Nguyên tắc dũng cảm

Phương pháp lập trình cực hạn cho rằng phải có lòng dũng cảm thì mỗi thành viên mới thực hiện được các nguyên tắc kể trên Lòng dũng cảm có nghĩa là dám thay đổi, dám đề xuất cái mới, khi làm việc nhóm hay lập trình cặp đôi thì phải chỉ ra cái sai, sửa lỗi ngay lập tức Sẽ là hoàn toàn thất bại nếu áp dụng phương pháp lập trình cực hạn mà các thành viên không dám đề xuất cái mới, ngại

ngùng, cả nể không chỉ ra các lỗi phát sinh trong quá trình làm việc Lòng dũng cảm cũng là nói thật về tiến độ thực hiện và các dự toán về chi phí, thời gian, nguồn lực để thực hiện Dựa trên các nguyên tắc trao đổi, phản hồi và tôn trọng lẫn nhau, mọi thành viên trong đội dự án sẽ dũng cảm nhận trách nhiệm và thực hiện cùng nhau công việc của mình (không có một quyết định đơn độc và thực hiện công việc một cách đơn độc, mọi thành viên trong đội dự án luôn được hỗ trợ bởi các thành viên khác)

Cũng cần chú ý rằng, tuy phương pháp lập trình cực hạn không chỉ ra một cách rõ ràng, nhưng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng để thực hiện có hiệu quả phương pháp phát triển phần mềm cực hạn

1 3 Các phương pháp thực hành

Dựa trên phương pháp luận của phương pháp phát triển linh hoạt và bốn nguyên tắc ở trên, phương pháp lập trình cực hạn đưa ra các phương pháp thực hành, và điểm mạnh của phương pháp lập trình cực hạn chính là đã kết hợp một cách hợp lý các phương pháp này Mỗi một phương án tuy đơn giản nhưng rất cần thiết phải nắm vững Sau đây tôi xin đi vào từng phương pháp thực hành [7]:

1.3.1 Khách hàng cùng tham gia

Chúng ta mong muốn khách hàng và nhóm phát triển làm việc chung với nhau để họ hiểu các vấn đề của nhau và cùng giải quyết các vấn đề đó Vâ ̣y ai là khách hàng? Khách hàng của một nhóm phát triển theo phương pháp lập trình cực hạn là một hoặc một nhóm người định nghĩa và xác định độ ưu tiên của chức năng hệ thống (hay sản phẩm) Đôi khi khách hàng là nhóm nhà phân tích nghiệp vụ hoặc chuyên gia phát triển thị trường làm việc cùng một công ty phần mềm với nhóm phát triển Đôi khi khách hàng là một đại diện của người dùng Đôi khi khách hàng cũng chính là người trả tiền Nhưng trong một dự án áp dụng phương pháp lập trình cực hạn, bất kể khách hàng là ai thì họ cũng là một thành viên của nhóm phát triển

Trong quá trình phát triển, khách hàng sẽ tham gia cách trực tiếp trong suốt quá trình phát triển phần mềm Sự tham gia này sẽ giúp cho nhóm phát triển có điều kiện tham khảo trực tiếp ý kiến của khách hàng, trao đổi về hệ thống cần được phát triển, tránh được nhầm lẫn trong cách hiểu về hệ thống cần phát triển Tình huống tốt nhất là khách hàng làm việc với nhóm phát triển trong cùng một phòng Hoặc chí ít là làm việc ở nơi nào đó cách độ một trăm bước chân so

với phòng làm việc của nhóm phát triển Khoảng cách càng xa thì càng khó thỏa mãn điều kiện khách hàng là một thành viên trong nhóm phát triển Nếu khách hàng làm việc trong môt tòa nhà khác hoặc ở một quốc gia khác thì càng khó mà yêu cầu họ tham gia cùng với nhóm Nếu khách hàng không thể ở gần nhóm phát triển thì hãy tìm ai đó sẵn lòng làm việc chung và có thể đứng ở vai trò của một khách hàng thực thụ

1.3.2 Lập kế hoạch liên tục

Trong XP, việc lập kế hoạch là một quá trình liên tục bao gồm 2 mức: lập kế hoạch phát hành và lập kế hoạch lặp dựa tính năng và thứ tự ưu tiên mà khách hàng đưa ra và ước lượng công sức của nhóm phát triển Tức là khách hàng xác định giá trị, nhóm phát triển xác định chi phí cần bỏ ra

Mục tiêu của kế hoạch phát hành là xác định các tính năng cần thiết cho lần phát hành tiếp theo Về cơ bản kế hoạch phát hành thực hiện như sau:

- Khách hàng xác định một danh sách các tính năng mong muốn hệ thống đáp ứng;

- Nhóm phát triển ước tính công sức cần bỏ ra để thực hiện danh sách các tính năng mà khách hàng đã đưa ra

- Khách hàng sẽ quyết định xem thứ tự ưu tiên cho việc thực hiện phát triển các tính năng đó và đưa ra kế hoạch phát hành tổng thể

Mục tiêu của việc lập kế hoạch lặp cũng tương tự như việc lập kế hoạch phát hành, khách hàng sau khi xác định được yêu cầu cho một lần lặp mới sẽ trình bầy cho nhóm phát triển, nhóm phát triển sẽ ước lượng và phân chia công việc

để thực hiện

1.3.3 Phát hành từng phần

Theo phương pháp thực hành này, đội phát triển sẽ phát triển dần dần phần mềm, từ đơn giản đến phức tạp, từ tập các tính năng hữu dụng nhỏ nhất Từng phần sẽ được chuyển giao sớm và thường xuyên cho khách hàng để có được ngay sự phản hồi từ phía khách hàng Từ đó sẽ có thể điều chỉnh ngay được sản phẩm cho phù hợp với yêu cầu của khách hàng Khách hàng cũng có điều kiện

để bổ sung hay thay đổi yêu cầu phần mềm

Việc phát hành sớm và thường xuyên giúp cho khách hàng có thể sử dụng được ngay các tính năng cần thiết mà không phải chờ cho đến khi có đầy đủ các

tính năng khác mới sử dụng được Hơn nữa, do nhận được các bản phát hành sớm, khách hàng có thể thấy được các yêu cầu cần thay đổi, các yêu cầu cần thêm mới và đặc biệt là các yêu cầu đã lỗi thời để loại bỏ đi Điều này sẽ tiết kiệm rất lớn cho khách hàng về chi phí cũng như giúp đội dự án không phải phát triển các tính năng đã lỗi thời, không cần thiết

Việc phát hành từng phần nghĩa là nhóm dự án sẽ cố gắng để đưa hệ thống vào sản xuất càng sớm càng tốt và thậm chí cả trước khi nó đã giải quyết toàn bộ vấn đề Họ cũng làm phát hành rất thường xuyên, có thể được bất cứ nơi nào từ một ngày đến một cơ sở hàng tháng Những gì được phát hành không phải là một bản giới thiệu để nhận xét rồi sau đó đặt sang một bên, mà là (một phần của) một hệ thống thực tế mà khách hàng đưa vào sử dụng sản xuất Lý do là điều này sẽ cung cấp lợi ích sớm và thường xuyên cho khách hàng trong việc cung cấp giá trị kinh doanh thực sự Nó cũng sẽ cung cấp thông tin phản hồi sớm và thường xuyên đến các nhà phát triển để họ có thể tìm hiểu những gì khách hàng muốn

1.3.4 Lập trình theo cặp

Lập trình theo cặp nghĩa là tất cả mã nguồn sản phẩm được viết bởi các cặp lập trình viên làm việc với nhau trên cùng một máy tính Một thành viên của một cặp sẽ giữ bàn phím và đánh mã nguồn Thành viên còn lại của cặp sẽ quan sát

mã nguồn được đánh và tìm kiếm lỗi và cải tiến mã Cả hai tương tác với nhau một cách liên tục và cả hai cùng bận rộn cho công việc viết phần mềm Vai trò được thay đổi thường xuyên Người giữ phím sẽ mệt mỏi và dẫn đến dễ sai lầm Người còn lại (trong cặp) sẽ nhận lại bàn phím và điều khiển nó Bàn phím được hoán đổi nhiều lần giữa hai người trong một giờ Mã nguồn kết quả được thiết

kế và đươ ̣c viết bởi cả hai người Công sức của cả hai là như nhau

Mối quan hệ theo cặp sẽ được thay đổi ít nhất một lần trong ngày để mỗi lập trình viên được làm việc ít nhất với hai người trong ngày Xuyên suốt một bước lặp của phương pháp lập trình cực hạn, mỗi thành viên của nhóm phát triển phải làm việc với mọi thành viên khác trong nhóm Và họ chỉ làm những công việc của trong nội dung của bước lặp đó mà thôi Điều này tăng cường sự trãi rộng kiến thức cho toàn nhóm Trong khi kỹ thuật đặc trưng vẫn còn nguyên vẹn và các công việc yêu cầu kỹ thuật đặc trưng vẫn thường được giao cho các chuyên gia thì các chuyên gia này làm việc với hầu hết các thành viên còn lại trong

nhóm Điều này sẽ trải rộng kiến thứ c cho toàn nhóm để các thành viên khác có thể thay thế cho chuyên gia trong các trường hợp khẩn cấp

1.3.5 Phát triển định hướng kiểm thử

Các lập trình viên sẽ viết các đơn vị kiểm nghiệm trước khi viết mã nguồn (thiết kế kiểm thử đầu tiên) Tất cả các đơn vị kiểm nghiệm đều được thực hiện thường xuyên trong quá trình phát triển sản phẩm trong từng khối mã nguồn của từng lập trình viên Các lập trình viên có thể thay đổi một cách linh hoạt vì quy trình thử nghiệm có thể mắc lỗi hay sai so với thiết kế ban đầu

Tất cả các mã nguồn sản phẩm được viết để làm cho các đơn vị kiểm thử thành công Đầu tiên, chúng ta viết một đơn vị kiểm thử chạy sai bởi vì chức năng dự định kiểm thử vẫn chưa tồn tại Sau đó chúng ta viết mã để đơn vị kiểm thử này thực hiện thành công Thời gian lặp lại giữa viết kiểm thử rồi viết mã nguồn xảy ra rất nhanh , trong khoảng một vài phút Các bô ̣ kiểm thử và mã nguồn cùng tăng trưởng , trong đó bô ̣ kiểm thử luôn dẫn trước mã mộ t khoảng cách rất ngắn

Kết quả là các bô ̣ kiểm thử phát triển cùng lúc với mã nguồn sản phẩm Những bộ kiểm thử này cho phép các lập trình viên kiểm tra chương trình (đang phát triển) có chạy hay không Nếu một cặp nào đó thưc hiện một thay đổi nhỏ,

họ có thể chạy lại các bộ kiểm thử để chắc chắn rằng họ không làm hỏng các đoạn mã nguồn khác

Khi bạn viết mã để các bộ kiểm thử thành công, thì mã nguồn đó được gọi là

mã khả kiểm Ngoài ra, còn có một mục tiêu rất quan trọng là bạn có thể tách bạch các khối mã nguồn sao cho chúng có thể được kiểm thử một cách độc lập Như vậy, bản thiết kế theo hướng này cho kết quả là mã nguồn ít bị trùng lặp nhất Các nguyên lý thiết kế hướng đối tượng đóng vai trò là công cụ mạnh mẽ giúp bạn tránh được mã trùng lặp

Chi tiết về yêu cầu người dùng được thu thập trong dạng thức của các bộ kiểm thử nghiệm thu được đặc tả bởi khách hàng Các bộ kiểm thử nghiệm thu của một yêu cầu được viết ngay trước hoặc cùng lúc với việc cài đặt yêu cầu đó Chúng được viết theo một ngôn ngữ kịch bản bất kỳ nào cho phép chúng chạy tự động và có thể lặp lại Ngôn ngữ của bộ kiểm thử nghiệm thu được phát triển và tiến hóa cùng với hệ thống Khách hàng có thể thuê nhóm phát triển tạo một hệ thống thực thi kịch bản đơn giản hoặc có thể họ có bộ phận kiểm soát chất lượng

riêng để phát triển nó Nhiều khách hàng nhờ bộ phận kiểm soát chất lượng phát triển công cụ cho việc kiểm tra đô ̣ thỏa mãn của sản phẩm và trực tiếp viết các bản kiểm thử nghiệm thu

Mỗi khi một bản kiểm thử nghiệm thu thành công, nó được thêm vào nhóm của những bản kiểm thử nghiệm đã thành công trước đó, và không bao giờ được phép thất bại Nhóm kiểm thử nghiệm tăng trưởng lên và sẽ được chạy nhiều lần trong ngày, hoặc chạy mỗi khi xây dựng hệ thống Nếu như các bản kiểm thử nghiệm thu thất bại thì bản xây dựng này được báo cáo là hỏng Như vậy mỗi khi một yêu cầu được gọi là cài đặt xong thì nó sẽ không bao giờ bị vỡ Hệ thống chuyển từ trạng thái cũ sang trạng thái mới mà không bao giờ được phép không làm việc (nghĩa là phải th ỏa mãn các yêu cầu cũ lẫn mới) lâu hơn vài giờ

1.3.6 Tích hợp liên tục

Nhóm phát triển phải luôn luôn được làm việc trên các phiên bản mới nhất của phần mềm Do các thành viên nhóm khác nhau có thể có các phiên bản được lưu cục bộ với nhiều thay đổi và cải tiến, họ nên cố gắng để tải lên phiên bản hiện tại của họ để vào trong kho mã nguồn mỗi giờ, hoặc khi một tạo ra một điểm chốt quan trọng trong quá trình phát triển các tính năng vừa thành công Tích hợp liên tục sẽ tránh sự chậm trễ do vấn đề tích hợp, tránh được các vấn đề mâu thuẫn phát sinh mà đến lúc tích hợp mới phát hiện ra được

Bằng việc sử dụng các công cụ lưu giữ mã nguồn, các lập trình viên đẩy mã nguồn làm được lên kho chứa mã nguồn và tích hợp nhiều lần trong ngày Qui luật rất đơn giản, người đầu tiên sẽ đẩy mã nguồn lên, những người sau thì hợp nhất mã nguồn của mình với người đẩy lên trước và đẩy mã nguồn đã hợp nhất lên Phương pháp lập trình cực hạn sử dụng công cụ quản lý mã nguồn cho phép nhiều người được lấy mã nguồn xuống và phát triển một lúc Điều này có nghĩa

là các lập trình viên được phép lấy mã nguồn ở bất kỳ một khối mã nguồn nào

đó vào bất kỳ thời điểm nào đó Khi anh ta đẩy khối mã nguồn đã được chỉnh sửa, anh ta phải chuẩn bị hợp nhất với các thay đổi do một lập trình viên bất kỳ trước đó thưc hiện Để tránh phải hợp nhất quá nhiều trong 1 lúc, các thành viên nên đẩy mã nguồn mình mới thực hiện được lên kho chứa mã nguồn thường xuyên Một cặp sẽ làm một nhiêm vụ trong khoảng một hay hai giờ Họ tạo các

bộ kiểm thử và mã nguồn cho sản phẩm.Vào một thời điểm thích hợp, có thể là trước khi nhiệm vụ đó được hoàn thành, họ sẽ quyết định đẩy các các đoạn mã nguồn lên kho chứa mã nguồn Trước tiên, họ phải làm cho các bộ kiểm thử đều

thành công Sau đó, họ mới tích hợp phần mã nguồn mới vào phần đã có Nếu cần thì hợp nhất chúng lại Hoặc nếu cần, họ sẽ hỏi ý kiến lập trình viên đã đẩy

mã nguồn lên trước đó Một khi các thay đổi đã được tích hợp, họ xây dựng lại

hệ thống Họ chạy lại tất cả các bộ kiểm thử trong hệ thống, bao gồm cả việc kiểm thử nghiệm thu Nếu họ làm hỏng bất cứ thứ gì, họ phải sửa ngay Nếu các

bộ kiểm thử đều thành công, lúc này họ mới được gọi là hoàn thành xong một lần đẩy mã nguồn của mình lên kho chứa mã nguồn

Tích hợp liên tục là các đoạn mã lệnh mới được tích hợp ngay vào chương trình khi một nhiệm vụ hay một yêu cầu được hoàn thành Như là một phần của quy trình tích hợp đầu tiên bạn tích hợp mã chương trình mới nhất vào những thay đổi của riêng bạn, sau đó bạn phải chạy tất cả các kiểm thử một lần nữa để đảm bảo rằng tất cả các trường hợp kiểm thử đề vẫn hoạt động tốt và đoạn mã mới của bạn (hoặc thay đổi được thực hiện bởi những người khác) không phá vỡ chương trình đã phát triển Sau đó bạn có thể tích hợp mã của bạn vào chương trình và công bố cho các thành viên khác trong nhóm Việc kiểm thử như trên sẽ được thực hiện trong một môi trường "sạch" (có thể tích hợp trên một máy riêng biệt) và xây dựng từ đầu để tránh bị "nhiễu" từ các tập tin có thể tạm thời và để đảm bảo rằng những gì bạn sẽ tích hợp sau này cũng là những gì bạn thực sự đang kiểm thử Trong trường hợp những lập trình viên khác đã "phát hành" những thay đổi của họ vào mã nguồn chương trình chung sau khi bạn tích hợp

nó vào không gian làm việc của bạn, bạn sẽ phải bắt đầu tích hợp lại vào môi trường kiểm thử của bạn và kiểu thử lại Tuy nhiên, các bản "phát hành" sẽ được đẩy lên thường xuyên và lập trình viên sẽ chỉ tốn một khoảng thời gian ngắn để chạy các trường hợp kiểm thử, do đó, trường hợp này rất hiếm khi xẩy ra Việc tích hợp liên tục giúp tất cả mọi người luôn làm việc trên mã mới nhất, và giúp cho các đoạn mã lệnh trở nên thống nhất hơn, tránh được các xung đột khi tích hợp các đoạn mã mới của các cặp lập trình viên lên mã chung của cả đội

1.3.7 Tái cấu trúc hệ thống

Bởi vì phương pháp lập trình cực hạn ủng hộ phương pháp chỉ lập trình những gì cần thiết trong hiện tại, và thực hiện nó một cách đơn giản nhất có thể tại thời điểm này có thể dẫn đến những khó khăn có thể phát sinh trong việc phát triển hệ thống về sau Một trong những vấn đề phát sinh là sự cần thiết để bảo trì kép các phiên bản: thay đổi chức năng bắt đầu đòi hỏi phải thay đổi nhiều bản sao của mã nguồn tương tự như nhau Một vấn đề khác là những thay đổi trong một phần của mã này ảnh hưởng đến rất nhiều bộ phận khác

Nguyên nhân là do sau một thời gian phát triển để phục vụ một tính năng nào

đó, các đoạn mã nguồn thường được viết ra để phục vụ việc đáp ứng ngay được yêu cầu đó, vì vậy, phương pháp lập trình cực hạn khuyến khích tổ chức lại chương trình một cách đều đặn để nâng cao tính sáng sủa của chương trình, dễ

bổ sung các chức năng mới, nâng cao hiệu suất của chương trình Việc tổ chức lại chương trình là rất khả thi do phương pháp lập trình cực hạn có quy trình thử nghiệm tự động bắt lỗi do đó việc tổ chức lại chương trình sẽ không quá tốn công sức Hơn nữa, việc tổ chức lại chương trình giúp ta nhìn nhận lại toàn bộ chương trình, tổ chức lại mã nguồn cho phù hợp với yêu cầu hơn (do đã phát triển và rất hiểu yêu cầu) và giúp tối ưu hơn các đoạn mã nguồn Qua đó cũng

mở rộng và nâng cao kiến trúc thiết kế lên và làm cho nó đơn giản hơn

Sau phiên bản ban đầu, kiến trúc và thiết kế chung được đặt ra, mọi thứ đều tập trung vào việc thực hiện các yêu cầu của khách hàng và thực hiện các nhiệm

vụ để đạt được các yêu cầu đó Trong XP, đầu tiên, các lập trình viên sẽ tập trung vào việc viết các đoạn mã lệnh rồi sau đó sẽ thiết kế lại chương trình đã viết Sau một nhiệm vụ hay một yêu cầu người dùng được hoàn thành, trước khi

nó được phát hành các đoạn mã vào kho mã nguồn chung, các đoạn mã mới này

sẽ được biến đổi để đơn giản hóa cả về thiết kế lẫn đoạn mã lệnh Mục đích là để giữ cho các mã càng đơn giản càng tốt và cải thiện thiết kế trong khi vẫn duy trì các chức năng Tái cấu trúc nên được thực hiện như một loạt các bước hồi phục được, vì vậy bạn luôn có thể trở lại nếu một tái cấu trúc không hoạt động Đối với mỗi bước trong quá trình tái cấu trúc của bạn chắc chắn rằng mã chuyển đổi không phá vỡ bất cứ trường hợp kiểm thử nào Bằng cách này các lập trình viên

có thể thay đổi thiết kế ngay khi cần thiết, và do đó nhóm dự án không bị khóa chặt trong các quyết định thiết kế ban đầu

1.3.8 Sở hữu tập thể

Tất cả mã nguồn đều thuộc quyền sở hữu của mọi thành viên trong nhóm phát triển Theo đó, một cặp có quyền lấy mã nguồn về và chỉnh sửa, cải tiến một khối mã nguồn bất kỳ Không một lập trình viên nào chịu trách nhiệm cá nhân với một khối mã nguồn bất kỳ hoặc một kỹ thuật bất kỳ Mọi người cùng làm việc với giao diện người dùng Mọi người cùng làm việc với phần mềm lớp giữa Mọi người cùng làm việc với cơ sở dữ liệu Không ai có nhiều quyền lực hơn người khác về một kỹ thuật hay một khối mã nguồn nào đó Do Bất kỳ người nào trong đội dự án đều có quyền thay đổi mã trong quá trình làm việc với khách hàng chỉ cần tuân theo tiêu chuẩn lập trình và phải đảm bảo thực hiện thử

nghiệm lại toàn bộ sau khi hoàn tất công việc sửa đổi Điều này sẽ loại bỏ các vấn đề như là sai lệch về cấu trúc chương trình, … có thể xảy ra khi một cá nhân lập trình độc lập

Điều này không có nghĩa là phương pháp lập trình cực hạn phản đối việc chuyên môn hóa Nếu bạn có kỹ năng về lập trình giao diện người dùng, hẳn bạn thích các nhiệm vụ liên quan đến giao diện người dùng, nhưng bạn sẽ được yêu cầu bắt cặp với các nhiệm vụ ở lớp điều khiển (lớp logic) hoặc ở mức cơ sở dữ liệu Nếu bạn quyết định học một chuyên môn thứ hai, bạn có thể đăng ký các nhiệm vụ và làm việc với chuyên gia ở chuyên môn đó Họ sẽ dạy bạn và bạn sẽ không bị "giam giữ" trong chuyên môn của mình

Theo XP, tất cả mọi người sở hữu tất cả các đoạn mã lệnh mà nhóm viết ra Toàn bộ nhóm nghiên cứu sở hữu tất cả đoạn mã lệnh và được gọi chung là chịu trách nhiệm về nó Nếu một cặp lập trình viên làm việc trên một yêu cầu cụ thể cảm thấy cần phải thay đổi một số đoạn mã lệnh khác để thỏa mãn yêu cầu cụ thể của họ, họ được tự do để làm như vậy bất kỳ lúc nào mà không cần phải hỏi

và chờ đợi cho người khác để làm điều đó cho họ Trong thực tế, họ được khuyến khích để thay đổi hoặc tái cấu trúc lại bất cứ khi nào họ thấy rằng nó có thể được cải thiện Nếu họ cần thêm thông tin để thực hiện các thay đổi, họ có thể tìm các cặp lập trình viên đã thực hiện các đoạn mã lệnh này đầu tiên và thảo luận về nhưng thay đổi với họ Bởi vì, nếu cặp lập trình viên yêu cầu người khác

để thực hiện việc thay đổi mà họ cần có nghĩa là họ sẽ phải chờ đợi điều đó xảy

ra và có thể họ sẽ không nhận được sự thay đổi hoàn toàn đúng theo những điều

mà cặp lập trình viên này mong muốn Khi một cặp lập trình viên sửa các đoạn

mã lệnh để thực hiện những yêu cầu của khách hàng mà họ đảm nhận, họ sẽ luôn tìm thấy cái gì có thể cần được cải thiện và nó là trách nhiệm của cặp lập trình viên này dù họ không phải là tác giả gốc của đoạn mã lệnh này Khi một cặp lập trình viên hoàn thành một nhiệm vụ hay một yêu cầu, họ phát hành mã nguồn lên kho mã nguồn để đoạn mã nguồn đó có sẵn cho tất cả các thành viên khác trong nhóm Như một hệ quả của phương pháp thực hành sở hữu tập thể sẽ

có mã được thực hiện song song do hai hoặc nhiều cặp cùng thay đổi một đoạn

mã lệnh cùng một lúc

1.3.9 Thiết kế đơn giản

Phương pháp lập trình cực hạn khuyến khích tìm kiếm giải pháp đơn giản khi thiết kế phần mềm Chỉ thiết kế phần mềm thoả mãn yêu cầu hiện tại của khách

hàng, không nên tìm kiếm một giải pháp cho một hệ thống tương lai Theo đó, chỉ cần một thiết kế làm sao cho chương trình chạy được và thỏa mãn yêu cầu của khách hàng

Thiết kế đơn giản giúp cho giá thành của việc thay đổi được cắt giảm tối đa Nghĩa là không nên bỏ quá nhiều thời gian và công sức vào những việc mà sau này có thể cần hoặc cũng có thể không Các dự án áp dụng phương pháp lập trình cực hạn thường được đơn giản một cách tối đa, đảm bảo rằng sau này nếu

có cần thay đổi thì chi phí cũng rất nhỏ Đồng thời, một yêu cầu được đặt ra là mọi thành viên trong nhóm đều phải học và sử dụng thành thạo các mẫu thiết kế Thứ nhất, nó giúp cho cả nhóm làm việc với nhau một cách ăn ý (liên lạc tốt) Sau đó là giúp cho việc viết mã nguồn của từng thành viên được tốt và nhanh do tái sử dụng được kinh nghiệm từ người đi trước, điều này rất quan trọng, vì trong phương pháp lập trình cực hạn không có thiết kế chi tiết, từng đoạn mã/từng khối mã nguồn phải do từng thành viên của nhóm thể hiện, vì vậy nếu

áp dụng được thì sẽ giảm thiểu được quá trình điều chỉnh/tái chế

1.3.10 Hệ thống ký pháp

Việc trao đổi trong nhóm phát triển phương pháp lập trình cực hạn sẽ dùng chung một hệ thống các thuật ngữ để biểu diễn hệ thống cần phát triển Các thuật ngữ này sẽ được dùng trong khi trao đổi giữa các thành viên trong nhóm cũng như khi trao đổi với khách hàng Nó bao gồm một tập các khái niệm được đặt tên cho các lớp học và các phương pháp thường được dùng trong dự án giúp cho một thành viên trong nhóm có thể nắm bắt nhanh ý đồng đội định trình bầy

Hệ thống ký pháp này giúp đội dự án xây dựng dễ dàng từ điển thông dụng và giúp cho các thành viên nhanh chóng nắm bắt được yêu cầu cần phát triển

Hơn nữa, sử dụng hệ thống ký pháp có tác động lớn đến việc phát triển kiến trúc phần mềm Sử dụng ký pháp cho thấy được chương trình cần phát triển ở mức cao hơn, dễ hiểu và dễ tưởng tượng hơn đồng thời cho nhiều gợi ý về các chức năng cũng như các thiết kế ở mức cao hơn[8]

1.3.11 Làm việc lâu bền

Sử dụng phương pháp lập trình theo cặp, cường độ làm việc sẽ lớn hơn rất nhiều việc làm riêng lẻ Việc tôn trọng thời gian sử dụng chung của đồng nghiệp đang cặp với bạn đòi hỏi bạn phải luôn luôn có mặt và cuốn vào công việc đang phải đối mặt Việc phát triển phần mềm không phải là một cuộc chạy nước rút,

mà nó là một cuộc chạy đường dài Nhóm nào vừa rời vạch xuất phát đã chạy thật nhanh thì sẽ tiêu tốn hết năng lượng trước khi họ về đến đích Để hoàn tất được nhanh thì nhóm càng phải kiểm soát được tốc độ giống như một người chạy đua maraton, cần phải duy trì năng lượng và sự tỉnh táo, cần phải chạy với nhịp độ vừa phải và vững chắc

Qui tắc của phương pháp lập trình cực hạn là nhóm không được phép làm việc quá giờ Thường chỉ cho phép các lập trình viên làm việc 40 giờ một tuần Việc chọn 40 giờ hay 38 hay 42 giờ không phải là điều quan trọng nhất và không bắt buộc phải là 40 giờ, điều quan trọng là đội dự án làm việc hiệu quả trong một thời gian dài Đồng thời, XP cũng khuyến khích đội dự án có khoảng thời gian nghỉ ngơi giữa giờ mỗi khi hoàn thành một nhiệm vụ hoặc sau khoảng

2 tiếng làm việc liên tục Một ngoại lệ duy nhất là vào tuần cuối cùng của một phiên bản phát hành Nếu nhóm đang phải trong tình huống hoàn tất nhanh chóng kịp tiến độ phát hành thì có thể làm việc quá giờ

1.3.12 Chuẩn hóa mã nguồn

Chuẩn hóa mã nguồn là một thỏa thuận thiết lập các quy tắc để toàn bộ nhóm phát triển đồng ý tuân thủ trong suốt dự án Các quy tắc này quy định một phong cách nhất quán và định dạng mã nguồn, trong ngôn ngữ lập trình được lựa chọn, cũng như chương trình xây dựng và các mẫu khác nhau nên tránh để giảm xác suất của các lỗi phát sinh do hiểu nhầm, do trình bầy khó hiểu, khó kết hợp giữa các thành viên trong nhóm Các tiêu chuẩn mã nguồn có thể là một quy ước chuẩn quy định của nhà cung cấp ngôn ngữ (ví dụ: Các quy ước theo đề nghị của Sun cho các lập trình viên sử dụng ngôn ngữ Java hay của MicroSoft cho các lập trình viên sử dụng ngôn nghữ VB hay C# … ), hoặc tùy chỉnh được xác định bởi các nhóm phát triển

Các tiêu chuẩn mã nguồn giúp chương trình có thể hiểu được một cách dễ dàng, nhất là đối với các quy cách lập trình đôi và sở hữu tập thể, nhóm phát triển phải thống nhất cách viết chương trình Chúng quy định một cách cụ thể, rõ ràng về cách viết (ví dụ, cách đặt tên biến, cách bổ sung chú thích, v.v.) để làm sao tất cả đều hiểu được

Hình 1-1 Các phương pháp thực hành trong XP

1 4 Vòng đời phương pháp phát triển XP

Như đã trình bầy ở trên, phương pháp phát triển XP là mô hình lặp tăng trưởng, trong mỗi lần lặp gồm 6 pha: Pha khám phá, Pha lập kế hoạch, Pha lặp

để phát hành, Pha xuất xưởng, Pha bảo trì, Pha kết thúc

Hình 1-2: Vòng đời dự án theo XP 1.4.1 Khám phá yêu cầu

Trong pha khám phá, khách hàng sẽ viết ra những yêu cầu mà mình muốn hệ thống cung cấp Chúng được viết ra bởi khách hàng trong vài ba câu với thuật ngữ của khách hàng, văn phong tự do, không cần theo một định dạng nào Dựa

trên các yêu cầu người dùng này, đội dự án sẽ ước lượng thời gian và công sức cần bỏ ra để thỏa mãn yêu cầu này thông qua một buổi họp kế hoạch phát hành Đồng thời, dựa trên yêu cầu này đội dự án cùng khách hàng sẽ tạo ra bản kiểm thử chấp thuận để đảm bảo đội dự án và khách hàng không hiểu nhầm ý nhau Đội dự án sẽ ước lượng một yêu cầu mất bao nhiêu thời gian và công sức để thực hiện Thông thường, một yêu cầu mất khoảng 1, 2 hoặc 3 tuần là khoảng thời gian lý tưởng để thực hiện Khoảng thời gian này là hợp lý nếu việc thực hiện yêu cầu là khẩn trương, không bị sao nhãng cũng không làm ảnh hưởng đến các nhiệm vụ khác và người phát triển biết rõ việc họ cần phải làm Nếu một yêu cầu cần hơn 3 tuần để thực hiện thì cần chia nhỏ yêu cầu ra để yêu cầu được chi tiết hơn Còn nếu yêu cầu cần nhỏ hơn 1 tuần để thực hiện thì nên gộp lại và giảm mức chi tiết của yêu cầu lại Về kế hoạch phát hành, mỗi một bản phát hành nên bao gồm từ 60 đến 100 yêu cầu [13]

Cần chú ý rằng, yêu cầu trong XP khác với tài liệu yêu cầu trong các phương pháp phát triển phần mềm khác ở hai điểm Một là mức độ chi tiết của yêu cầu

và hai là trọng tâm hướng vào người dùng Ở mức độ chi tiết, yêu cầu của XP chỉ nên cung cấp ở mức độ đủ để giảm rủi ro khi ước lượng việc thực hiện yêu cầu đó, trong quá trình thực hiện người phát triển sẽ nhận được các yêu cầu chi tiết thông qua các cuộc trò chuyện trực tiếp Ở trọng tâm của yêu cầu, XP tránh việc mô tả yêu cầu ở mức thuật toán, cơ sở dữ liệu, công nghệ hay bố cục giao diện sử dụng mà giữ yêu cầu ở mức nhu cầu và lợi ích của người dùng

Hình 1-3 Pha khám phá yêu cầu

Trong pha khám phá, đôi khi đội dự án gặp phải các vấn đề thiết kế hoặc kỹ thuật hóc búa mà cần có các giải pháp đột phá Khi đó, đội dự án sẽ xây dựng một chương trình đơn giản để khám phá những giải pháp tiềm năng nhằm giảm rủi ro về phương diện kỹ thuật và tăng tính tin cậy cho việc ước lượng công sức

thực hiện yêu cầu Các giải pháp đột phá thường chỉ tập trung vào vấn đề cần kiểm tra và bỏ qua những lo lắng khác.[14]

1.4.2 Pha lập kế hoạch

Tiến trình lập kế hoạch trong phương pháp lập trình XP là một công việc được thực hiện liên tục Việc lập kế hoạch thường diễn ra lặp lại sau một khoảng thời gian (thường sau khoảng 1 tuần) Tiến trình lập kế hoạch được chia làm hai phần: lập kế hoạch phát hành và lập kế hoạch bước lặp.[15]

Lập kế hoạch phát hành

Kế hoạch phát hành của dự án được lập trong những tuần đầu tiên Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng Kế hoạch phát hành sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án

Tập trung vào việc xác định các yêu cầu được bao chứa trong lần phát hành gần nhất và khi nào chúng được bàn giao cho khách hàng Khách hàng và người phát triển cùng lên kế hoạch này tương ứng với mỗi bước trong 6 bước lặp Một bản phát hành thường là thành quả của 3 tháng làm việc Nó đại diện cho 1 lần giao hàng chính và thường sẽ được đưa vào sản phẩm Một bản phát hành cũng bao gồm một tập các yêu cầu được phân độ ưu tiên bởi khách hàng dựa trên ngân sách mà nhóm phát triển đưa ra

Nhóm phát triển xây dựng ngân sách cho 1 bản phát hành bằng cách đo chi phí tiêu tốn của những phiên bản phát hành trước Khách hàng có thể chọn số lượng bất kỳ các yêu cầu cho 1 bản phát hành sao cho tổng các chi phí ước lượng không vượt quá ngân sách Khách hàng cũng xác định trình tự các yêu cầu được cài đặt trong 1 bản phát hành Nếu muốn, nhóm phát triển cũng có thể đưa ra vài bước lập đầu tiên và xác định xem yêu cầu nào sẽ được cài đặt trong bước lặp nào

Các bản phát hành không cố định, khách hàng có thể thay đổi nội dung bất

kỳ lúc nào Họ có thể hủy hoặc viết một yêu cầu mới hoặc thay đổi độ ưu tiên của các yêu cầu

Hình 1-4 Pha lập kế hoạch

Việc lên kế hoạch phát hành thường bao gồm ba giai đoạn:

 Giai đoạn khảo sát: Trong giai đoạn này, khách hàng sẽ cung cấp một

danh sách ngắn các yêu cầu có giá trị cao cho hệ thống cần phát triển Chúng được viết ra vào các thẻ yêu cầu người dùng

 Giai đoạn cam kết: Trong giai đoạn này những người phát triển và

chuyên viên nghiệp vụ sẽ cam kết với nhau về những chức năng sẽ được phát triển trong lần phát hành tiếp theo

 Giai đoạn điều khiển: Trong pha điều khiển, kế hoạch có thể bị điều

chỉnh, những yêu cầu mới có thể được thêm vào, những yêu cầu đang tồn tại có thể bị thay đổi hoặc hủy bỏ

Hình 1-5 Lên kế hoạch phát hành Lên kế hoạch bước lặp

Đây là kế hoạch dành cho những hoạt động và nhiệm vụ của người phát triển Khách hàng không tham gia vào trong tiến trình này Việc lập kế hoạch bước lặp thường được vạch ra ở đầu mỗi bước lặp (Mỗi bước lặp thường kéo dài 2 tuần) Trong suốt thời gian này, nhà phát triển tự do cắt các yêu cầu thành các nhiệm

vụ và tự do cài đặt các nhiệm vụ này tùy theo thuận lợi về mặt kỹ thuật và kinh doanh

Việc lên kế hoạch bước lặp cũng bao gồm bao ba giai đoạn:

 Giai đoạn khảo sát: Trong giai đoạn này, yêu cầu sẽ được chuyển đổi

thành các nhiệm vụ Những nhiệm vụ sẽ được ghi lại và các thẻ nhiệm vụ

 Giai đoạn cam kết: Những nhiệm vụ sẽ được giao cho những lập trình

viên và khoảng thời gian cần để hoàn thành nó sẽ được ước lượng

 Giai đoạn điều khiển: Những nhiệm vụ được thực hiện và kết quả cuối

cùng hợp với yêu cầu người dùng ở trên

Để lên kế hoạch cho một dự án , chúng ta phải biết về yêu cầu , nhưng chúng

ta không nên biết nhiều lắm Với mục đích lập kế hoạch , chúng ta chỉ cần biết

đủ về yêu cầu để ước lượng chúng Bạn có thể nghĩ rằng để có thể ước lượng, bạn cần biết tất cả các chi tiết, nhưng điều này thường không đúng Bạn cần biết rằng thực tế có những chi tiết đó, và bạn phải biết rằng các chi tiết đó vô cùng hỗn tạp, nhưng bạn không cần tới các đặc tả của chúng Hơn nữa, các đặc tả chi tiết của một yêu cầu thì luôn thay đổi theo thời gian, đặc biệt là khi khách hàng bắt đầu nhìn thấy hệ thống vận hành như thế nào Không có cách xác định yêu cầu nào tốt hơn cách quan sát hệ thống được áp dụng vào thực tế như thế nào Vì vậy, thu thập đặc tả chi tiết yêu cầu quá sớm trước khi cài đặt hệ thống là quá vội vã và uổng phí Do đó, chúng ta sẽ không thu thập các chi tiết đó Khách hàng sẽ viết yêu cầu sơ lược (đã được thương lượng với nhóm phát triển) lên một thẻ ghi chú Thẻ này sẽ nhắc chúng ta nhớ về cuộc trao đổi này Cũng vào khoảng thời gian này, nhóm phát triển sẽ viết lên tờ card đó các ước lượng Họ ước lượng dựa trên cảm giác về các chi tiết nhận được trong cuộc đối thoại Mục đích của việc lập kế hoạch này là thay vì dự đoán chính xác ngày phát hành, nó nhắm đến việc điều hành dự án thông qua việc lên kế hoạch từng bước

và kế hoạch phát hành dựa trên việc thu thập các yêu cầu người dùng

Hình 1-6 Lên kế hoạch bước lặp 1.4.3 Pha lặp để phát hành

Trong pha lặp để pháp hành, mỗi bước lặp được chia thành một khoảng thời gian từ 1 đến 4 tuần để thực hiện và được lên kế hoạch trong pha lập kế hoạch bước lặp Bước lặp đầu tiên tạo ra kiến trúc tổng thể ban đầu cho hệ thống bằng việc lựa chọn những yêu cầu người dùng sẽ được thực thi Tại cuối mỗi bước lặp, đội phát triển và khách hàng sẽ thực hiện kiểm thử chức năng tương ứng với yêu cầu mà khách hàng đã đưa ra Nếu vẫn có lỗi hay chức năng chưa đúng với yêu cầu, thì đội dự án sẽ chỉnh sửa lại theo yêu cầu của khách hàng Bước lặp cuối cùng khi đã được khách hàng chấp thuận sẽ được chuyển sang pha xuất xưởng để chuẩn bị đưa vào triển khai trên thực tế

Sau khi đội dự án lên xong kế hoạch bước lặp, các yêu cầu của khách hàng được chuyển thành các nhiệm vụ và được trình bầy bằng ngôn ngữ kỹ thuật Các nhà phát triển sẽ nhận những nhiệm vụ của mình và ước tính thời gian, công sức cần thiết để hoàn thành Mỗi nhiệm vụ sẽ được ước lượng trong khoảng thời gian từ một đến ba ngày lập trình lý tưởng Thời gian lập trình lý tưởng là khoảng thời gian bạn cần để hoàn thành một nhiệm vụ mà không có sự sao nhãng Những nhiệm vụ cần ít hơn một ngày có thể được nhóm với nhiệm vụ khác, những nhiệm vụ lớn hơn ba ngày thì nên chia thành các nhiệm vụ con

1.4.4 Pha xuất xưởng

Trong pha xuất xưởng đòi hỏi phải kiểm thử thêm và kiểm tra hiệu suất hệ thống trước khi hệ thống có thể được chuyển tới tay khách hàng Tại pha này,

những thay đổi có thể vẫn được đưa ra và được quyết định phải thực hiện nếu chúng nằm trong lần phát hành này Trong suốt pha này, những bước lặp có thể cần phải diễn ra nhanh hơn từ ba tuần tới một tuần Những sáng kiến và đề xuất

sẽ được ghi nhận lại cho lần phát hành sau

1.4.5 Pha bảo trì

Sau bản phát hành đầu tiên được chuyển đến khách hàng, đội dự án phải giữ

cả hai hệ thống: hệ thống đang được sử dụng và hệ thống đang được phát triển mới Để thực hiện được điều này, pha bảo trì đòi hỏi sự nỗ lực của khách hàng

do đó đội dự án có thể giảm tốc độ sau khi hệ thống được đưa vào sử dụng Trong pha bảo trì, có thể có nhu cầu thêm thành viên mới hoặc thay đổi cơ cấu của đội dự án

1.4.6 Pha kết thúc

Pha kết thúc bắt đầu ngay khi các yêu cầu từ phía khách hàng đã được thực hiện và khách hàng không phát sinh yêu cầu mới Đây là thời điểm đội dự án cần viết tài liệu cũng có thể là lần cuối cùng mà hệ thống không thỏa mãn yêu cầu của khách hàng hoặc nó quá đắt để phát triển tiếp

1 5 Đội dự án XP

Một đội dự án theo phương pháp lập trình cực hạn làm việc cùng nhau trong một không gian mở không có các phòng riêng hoặc vách ngăn Vào đầu mỗi vòng lặp, đội tổ chức một cuộc họp kéo dài từ hai đến bốn giờ để tổng kết những công việc vừa hoàn thành và lập kế hoạch cho phần việc tiếp theo Hàng ngày,

cả đội tham gia một cuộc họp ngắn từ 5 đến 10 phút thảo luận về công việc trong ngày Ngoài hai kiểu họp chính thức này, từng thành viên tự lập kế hoạch làm việc cho mình Hình thức tự tổ chức là một đặc điểm chung của các dự án theo triết lý phát triển phần mềm linh hoạt

Trong một dự án phần mềm, những hiểu biết về sản phẩm luôn được nắm giữ bởi nhiều cá nhân Phương pháp lập trình cực hạn thừa nhận thực tế này bằng cách tạo ra một nhóm làm việc hỗn hợp với đầy đủ các vai trò cần thiết Một đội

dự án sử dụng XP thường bao gồm các thành viên sau đây:

1.5.1 Đại diện khách hàng

Chịu trách nhiệm xác định các yêu cầu cho phần mềm Công việc quan trọng nhất của người này là lập kế hoạch Khi bắt đầu dự án, đại diện khách hàng xác

định các tính năng cần có của phần mềm, tìm cách nhóm các tính năng này thành các phần nhỏ có thể phát triển được, bàn giao lần lượt và định ra lịch trình bàn giao từng phần Trong quá trình thực hiện dự án, đại diện khách hàng nhận phản hồi từ các thành viên khác và điều chỉnh kế hoạch cho phù hợp

Nhiệm vụ thứ hai của đại diện khách hàng là giúp các lập trình viên hiểu các yêu cầu chi tiết cho sản phẩm Trong các dự án áp dụng phương pháp lập trình cực hạn, tài liệu đặc tả chỉ là công cụ trợ giúp cho đại diện khách hàng mà thôi Người này sẽ đóng vai trò một tài liệu “sống”, luôn sẵn sàng trả lời các câu hỏi

từ các lập trình viên

Đại diện khách hàng không nhất thiết phải là khách hàng thật mà chỉ cần là một thành viên hiểu rõ các yêu cầu của phần mềm Thực nghiệm cho thấy giữa hai nhóm có chất lượng lập trình viên tương đương nhau thì nhóm có sự tham gia của khách hàng tạo ra sản phẩm tốt hơn hẳn Nếu khách hàng không thể đến ngồi ở văn phòng của bạn, hãy đưa đội dự án của bạn đến ngồi cùng với khách hàng Việc giao tiếp đối mặt là một hình thức giao tiếp rất quan trọng trong việc giao thiệp với khách hàng, đội dự án phải đảm bảo rằng khách hàng và đội dự án

có các hình thức giao thiệp hiệu quả nhất, và dễ dàng nhất có thể!

Thực nghiệm cũng cho thấy tỉ lệ hai đại diện khách hàng cho ba lập trình viên là phù hợp Tất nhiên, tỉ lệ này phụ thuộc vào độ phức tạp của sản phẩm Hãy ghi nhớ rằng khối lượng công việc của các đại diện khách hàng là rất lớn bởi họ luôn phải thực hiện việc lập ra và xác định mức ưu tiên công việc trước khi các lập trình viên bắt đầu công việc của mình

1.5.2 Người quản lý sản phẩm

Người này chịu trách nhiệm định hướng cho dự án và sản phẩm, bao gồm các công việc: Xác định các tính năng của sản phẩm và thứ tự ưu tiên của chúng, hướng dẫn đại diện khách hàng, làm việc với các bên liên quan đến dự án, đánh giá tiến độ dự án và giải quyết các vấn đề về tổ chức Ngoài ra, người quản lý sản phẩm còn chịu trách nhiệm đưa sản phẩm ra thị trường, bao gồm các việc quảng cáo, bán hàng và hỗ trợ khách hàng

Người quản lý sản phầm phải am hiểu thị trường và các lợi ích mà phần mềm

sẽ mang đến cho khách hàng Đồng thời, người này phải có khả năng cộng tác

và thỏa hiệp với các đòi hỏi đa dạng, nhiều khi mâu thuẫn nhau, từ các cá nhân

có quyền lợi liên quan đến dự án Người quản lý sản phẩm phải được trao đủ

quyền lực để có thể nói không với các yêu cầu không phù hợp Một dự án chỉ nên có duy nhất một người quản lý sản phầm nhằm đảm bảo tính thống nhất cho định hướng của dự án

1.5.3 Các chuyên gia nghiệp vụ

Các lập trình viên ít khi hiểu biết tường tận về một lĩnh vực cụ thể nào đó, ví

dụ như tài chính hay hoá học Bởi vậy, phương pháp lập trình cực hạn yêu cầu

sự tham gia của các chuyên gia hiểu rõ lĩnh vực chuyên môn của phần mềm đang được phát triển, chẳng hạn như các chuyên gia phân tích tài chính hay các nhà nghiên cứu hoá học Những người này sẽ nghiên cứu nghiệp vụ của phần mềm để sẵn sàng trả lời câu hỏi của các lập trình viên Trong các dự án nhỏ, người quản lý sản phẩm thường kiêm luôn vai trò chuyên gia nghiệp vụ

1.5.4 Người thiết kế giao diện

Giao diện người dùng là bộ mặt của sản phẩm Người dùng thường đánh giá chất lượng phần mềm thông qua chất lượng giao diện mà họ tương tác hàng ngày Nhiệm vụ của người thiết kế giao diện là tìm hiểu mong muốn của khách hàng cũng như thói quen làm việc thường ngày của họ và từ đó thiết kế bộ mặt của sản phẩm

Đừng nhầm lẫn giữa người thiết kế giao diện và người thiết kế đồ họa Người thiết kế giao diện nghiên cứu tương tác giữa người dùng và sản phẩm Trong khi

đó người thiết kế đồ họa tạo ra các thành phần cụ thể như âm thanh, hình ảnh hay cách bố trí giao diện

1.5.5 Lập trình viên

Nếu nhiệm vụ của người đại diện khách hàng là tối đa hóa giá trị của sản phẩm thì nhiệm vụ của các lập trình viên là tối thiểu hóa chi phí bằng việc lập trình theo cách hiệu quả nhất Nhiệm vụ của các lập trình viên trong dự án áp dụng phương pháp lập trình cực hạn là: Ước lượng thời gian và nguồn lực cần thiết để thực hiện các chức năng của phần mềm, từ đó trợ giúp đại diện khách hàng trong việc lập kế hoạch Lập trình viên cũng trao đổi trực tiếp với đại diện khách hàng để làm rõ các yêu cầu của phần mềm

Các lập trình viên làm việc theo cặp và sử dụng phương pháp phát triển dựa trên kiểm thử Mỗi lập trình viên có trách nhiệm viết các bộ kiểm thử đơn vị, viết và tối ưu hóa mã nguồn, thiết kế và liên tục cải tiến thiết kế của chương

trình Mã nguồn được xem là sở hữu tập thể, tất cả các lập trình viên đều có quyền và nghĩa vụ sửa các lỗi mà họ phát hiện ra, bất kể lỗi đó do ai gây ra Tiêu chuẩn lập trình đóng vai trò thiết yếu hỗ trợ cho cách làm việc này Các lập trình viên liên tục tích hợp mã nguồn vào hệ thống và kiểm thử một cách cẩn thận nhằm đảo bảo rằng phần mềm đủ tiêu chuẩn để đóng gói và bàn giao cho khách hàng vào cuối mỗi chu kì phát triển Các lập trình viên chỉ viết tài liệu khi cần thiết nhằm trợ giúp cho việc bảo trì phần mềm trong tương lai

Trong đội lập trình cần có một số thành viên có kinh nghiệm thiết kế phần mềm, có trách nhiệm hướng dẫn các lập trình viên khác Đội cũng cần các thành viên có kinh nghiệm về các lĩnh vực cụ thể như cơ sở dữ liệu hay bảo mật Thực nghiệm cho thấy một dự án áp dụng phương pháp lập trình cực hạn nên có từ 4 đến 10 lập trình viên

1.5.6 Người kiểm thử

Các dự án áp dụng phương pháp lập trình cực hạn nói chung không cần nhiều người kiểm thử Các lập trình viên được trông đợi sẽ chuyển giao các chương trình gần như không có lỗi cho người kiểm thử Các chương trình tự động kiểm thử cũng làm giảm sự cần thiết về số lượng người kiểm thử

Các dự án áp dụng phương pháp lập trình cực hạn thường có tỉ lệ người kiểm thử trên lập trình viên từ 1/4 đến 1/6 Một số dự án còn không có người kiểm thử

mà sử dụng đại diện khách hàng và lập trình viên vào vai trò này!

1.5.7 Quản lý dự án/Hướng dẫn viên

Quản lý dự án là những người có kinh nghiệm về phương pháp lập trình cực hạn, làm nhiệm vụ giúp đỡ các thành viên khác thực hiện các quy tắc của phương pháp lập trình cực hạn cũng như giao tiếp với các cá nhân bên ngoài dự

án Người quản lý dự án phải đảm bảo môi trường làm việc cho đội dự án với khách hàng, giao thiệp với các bên liên quan, đàm phán về các bước phát triển, yêu cầu cũng như thành quả của dự án

1.5.8 Các thành viên khác

Hãy nhớ rằng có rất nhiều người có lợi ích liên quan đến dự án nhưng không làm việc cùng đội dự án Họ là những người dùng cuối, lãnh đạo cấp cao, phòng nhân sự…(gọi chung là các bên liên quan) Những người này dù không có mặt trực tiếp trong dự án nhưng đều có ảnh hưởng đến thành công của dự án Người

quản lý sản phẩm phải thấu hiểu được những yêu cầu rất đa dạng của đội ngũ này Đây là một việc rất khó vì có những người bị bỏ qua trong khi họ thực sự

có ảnh hưởng đến thành công của dự án

Một dự án áp dụng phương pháp lập trình cực hạn không nhất thiết phải có đầy đủ các thành viên nói trên, hoặc ngược lại có thể sử dụng thêm các thành viên khác nếu cần Một thành viên trong dự án có thể đảm nhiệm nhiều vai trò cũng lúc Chẳng hạn, người quản lý sản phẩm có thể đồng thời là chuyên gia nghiệp vụ hoặc quản lý dự án Đại diện khách hàng có thể kiêm vai trò thiết kế giao diện Các lập trình viên có thể làm công việc của người kiểm thử

Một dự án áp dụng phương pháp lập trình cực hạn thường có từ 4 đến 10 lập trình viên Một dự án có 6 lập trình viên thường cần 4 đại diện khách hàng, 1 người kiểm thử và 1 người quản lý sản phẩm, tổng cộng là 12 thành viên Nếu

số lập trình viên là 10, sẽ cần đến 6 đại diện khách hàng, 3 người kiểm thử và một người quản lý sản phẩm, hợp thành một nhóm 20 người Đây cũng là con số tối đa của một dự án áp dụng theo phương pháp lập trình cực hạn thông thường Kích thước nhóm lớn sẽ gây khó khăn cho việc giao tiếp giữa các thành viên Bởi vậy, phương pháp lập trình cực hạn khuyến khích tuyển dụng các thành viên

có kinh nghiệm thay vì tăng số lượng người

1 6 Điều kiện để áp dụng

Nhóm phát triển nhỏ hơn 10 người: Phương pháp lập trình cực hạn có thể áp dụng một cách có hiệu quả trong các nhóm phát triển có số lượng nhỏ hơn 10 người ( quá 10 người thì việc trao đổi giữa các thành viên sẽ rất khó thực hiện được một cách hữu hiệu) Phương pháp lập trình cực hạn đặc biệt có hiệu quả trong việc phát triển các phần mềm có yêu cầu luôn thay đổi, khách hàng không định trước được một cách rõ ràng yêu cầu phần mềm Đối với các dự án lớn, người ta có thể phân chia công việc cho từng nhóm nhỏ áp dụng theo phương pháp lập trình cực hạn Tuy nhiên, cho đến nay các tác giả của phương pháp lập trình cực hạn chưa đưa ra phương án nào để quản lý, phối hợp hoạt động của các nhóm này Theo tôi, trong trường hợp này, có thể dựa vào ISO9001 hay mô hình trưởng thành về năng lực để kết lập một quy trình quản lý hoạt động của các nhóm nhỏ áp dụng phương pháp lập trình cực hạn, hoặc áp dụng theo các đề xuất đã được đưa ra ở phần chương 2 để áp dụng liên kết các nhóm nhỏ thành một nhóm lớn

Làm việc theo nhóm: Phương pháp lập trình cực hạn đòi hỏi phải có tính năng làm việc tập thể rất cao Mọi thành viên phải có thái độ hợp tác trong quá trình làm việc bởi vì mọi hoạt động của dự án áp dụng phương pháp lập trình cực hạn đều mang tính tập thể Nếu ai đó tách ra khỏi nhóm, làm việc một cách độc lập theo kiểu anh hùng cá nhân có thể gây bất lợi lớn đến việc phát triển của

dự án

Tính kỷ luật: Mọi thành viên phải tự giác chấp hành các quy định của nhóm phát triển Ví dụ, tất cả đều phải viết chương trình theo một quy định đã thống nhất Có như vậy thì chương trình mới có thể trong suốt và dễ hiểu với tất cả nhóm, dẫn đến dễ sửa đổi và thêm chức năng mới vào chương trình

Trình độ thành viên: Với phương pháp lập trình cực hạn, mọi thành viên sẽ tham gia vào mọi hoạt động trong quá trình phát triển phần mềm Do vậy, các thành viên cần phải được trang bị kiến thức tốt về nhiều mặt và cần có nhiều kinh nghiệm trong nhiều lĩnh vực khác nhau

Vai trò của khách hàng: Sự tham gia trực tiếp của khách hàng trong suốt quá trình thực hiện dự án phần mềm là một yếu tố không thể thiếu cho sự thành bại của dự án Khách hàng tham gia với tư cách là một thành viên biên chế của nhóm phát triển sẽ giúp cho nhóm luôn phát triển sản phẩm theo đúng yêu cầu của khách hàng cũng như thỏa mãn được các yêu cầu khách của khách hàng (ví

dụ như thời điểm bàn giao sản phẩm, giá thành sản phẩm, v.v.)

Chương 2 PHẦN MỀM THUÊ NGOÀI VÀ XP

2 1 Dịch vụ thuê ngoài

2.1.1 Khái niệm dịch vụ thuê ngoài

Theo định nghĩa của OffshoreXperts[10], dịch vụ thuê ngoài là việc quản lý và/hoặc thực hiện toàn bộ một chức năng kinh doanh được giao cho một nhà cung cấp dịch vụ bên ngoài Dịch vụ có thể được cung cấp bên trong hay bên ngoài công ty khách hàng; có thể thuộc nước sở tại hoặc ở nước ngoài

Cần phân biệt khái niệm dịch vụ thuê ngoài với việc sử dụng nguồn lực bên ngoài trong quy trình kinh doanh, BPO thường bao gồm việc di chuyển dịch vụ tới nhà cung cấp bên ngoài chẳng hạn các tổng đài điện thoại (call center), kế toán tài chính, nguồn nhân lực Dịch vụ thuê ngoài áp dụng trong các hoạt động sản xuất, công nghệ thông tin và hoạt động văn phòng, tận dụng lợi thế so sánh ở các vùng, các quốc gia khác nhau

2.1.2 Lợi thế của dịch vụ thuê ngoài

Chiến lược sử dụng nguồn lực bên ngoài trước hết tạo ra đòn bẩy cho nguồn lực công ty, truyền tư tưởng, kỹ năng và kinh nghiệm mới đồng thời rút ngắn thời gian tiếp cận thị trường, tạo ra lợi thế so sánh cũng như thúc đẩy Các lợi thế chiến lược của việc sử dụng nguồn lực bên ngoài bao gồm:

- Tiết kiệm chi phí: Một trong những lợi thế của dịch vụ thuê ngoài là bạn sẽ tiết kiệm được nhiều chi phí và tăng lợi nhuận Đồng thời, bạn sẽ tiết kiệm được thời gian, công sức, cơ sở hạ tầng và nguồn lực Chi phí cho dịch vụ dịch vụ thuê ngoài thường thấp hơn so với chi phí xây dựng một cơ cấu làm việc trong doanh nghiệp, vì thế với cùng một công việc, cùng một yêu cầu về chất lượng, bạn sẽ mất ít chi phí hơn khi sử dụng dịch vụ thuê ngoài, tiết kiệm phí tổn về vốn khi không phải đầu tư và duy trì thêm cơ sở hạ tầng Khi sử dụng dịch vụ thuê ngoài, bạn không tốn chi phí để đào tạo nhân viên, không phải trả cho các khoản tiền đóng bảo hiểm xã hội, bảo hiểm y tế, bảo hiểm thất nghiệp, thuế thu nhập cá nhân v.v… Ngoài ra, việc tạo dựng cơ cấu tổ chức nhân sự làm việc toàn phần trong doanh nghiệp đòi hỏi bạn phải có đủ diện tích văn phòng, các trang thiết bị làm việc,… dịch vụ thuê ngoài sẽ giúp bạn giải quyết các vấn đề

đó Tiếp cận với các dịch vụ chất lượng cao với mức chi phí thấp là lợi ích lớn nhất mà doanh nghiệp của bạn có được khi sử dụng dịch vụ thuê ngoài