0. 7 Kết cấu đề tài
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 (adsbygoogle = window.adsbygoogle || []).push({});
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,