5. Phát triển hướng vào tính năng (Feature Driven Development)
5.1Quy trình
- Nhưđã đề cập trước đó, FDD bao gồm 5 tiến trình tuần tự trong suốt quá trình đó việc thiết kế và xây dựng hệ thống được tiến hành (hình 19). Phần lặp đi lặp lại của quy trình FDD (Thiết kế và Xây dựng) hỗ trợ cho việc phát triển linh hoạt bằng cách đáp ứng nhanh chóng những thay đổi vào khúc cuối trong yêu cầu và nhu cầu kinh doanh. Thông thường, một tính năng đòi hỏi một nhóm làm việc khoảng từ 1 đến 3 tuần sau đó quy trình này sẽ lặp lại cho tính năng khác tương tự như vậy.
Agile methodology - 38 -
Hình 19: Các quy trình của FDD
- Theo sau, từng quy trình trong 5 quy trình sẽđược mô tả theo Palmer (2002).
5.1.1Phát triển một mô hình tổng thể
- Khi bắt đầu phát triển một mô hình tổng thể, các chuyên gia phạm vi/tên miền (domain) (xem mục 5.2) đã nhận thức về phạm vi, ngữ cảnh và yêu cầu của hệ thống cần xây dựng (Palmer và Felsing 2002). Các yêu cầu tài liệu chẳng hạn như use-case hoặc các đặc tả chức năng có thể tồn tại ở giai đoạn này. Tuy nhiên, FDD không đề cập rõ ràng đến vấn đề thu thập và quản lý các yêu cầu. Các chuyên gia phạm vi/lĩnh vực trình bày một cái gọi là "walkthrough"(buổi hướng dẫn đầu tiên) mà ởđó các thành viên trong nhóm và kiến trúc sư trưởng sẽđược cho biết về bản mô tả cấp cao của hệ thống.
- Phạm vi tổng thể (overall domain) được chia thành các vùng phạm vi
(domain areas) khác nhau và có nhiều hướng dẫn (walkthrough) chi tiết hơn được tổ chức cho từng vùng phạm vi bởi các thành viên phạm vi. Sau mỗi hướng dẫn (walkthrough), một đội phát triển làm việc trong các nhóm nhỏđể đề xuất ra các mô hình đối tượng (object models) cho vùng phạm vi (domain area) sắp tới. Sau đó đội phát triển thảo luận và quyết định dựa trên các mô hình đối tượng thích hợp cho từng vùng phạm vi. Song song đó, hình dạng của mô hình tổng thểđược xây dựng cho hệ thống (Palmer và Felsing 2002).
5.1.2Xây dựng danh sách các tính năng
- Thông qua walkthrough, các mô hình đối tượng và tài liệu(đặc tả, use-case, diagram,..) yêu cầu đang có làm nền tảng tốt để xây dựng một danh sách các tính năng toàn diện cho hệ thống đang được phát triển. Trong danh sách
Agile methodology - 39 -
này, nhóm phát triển giới thiệu từng chức năng có giá trị khách hàng
(client valued functions) có trong hệ thống. Các chức năng này được trình
bày đối với mỗi vùng phạm vi và các nhóm chức năng này chứa cái gọi là các bộ tính năng chính yếu. Ngoài ra, các bộ tính năng chính được chia thành nhiều bộ tính năng hơn. Chúng thể hiện các hoạt động khác nhau trong các vùng phạm vi cụ thể. Danh sách tính năng được xem xét bởi những người sử dụng và các nhà tài trợ hệ thống về tính hợp lệ và đầy đủ của chúng.
5.1.3Lập kế hoạch theo tính năng
- Lập kế hoạch theo tính năng bao gồm việc tạo ra một kế hoạch cấp cao, trong đó các bộ tính năng sẽđược sắp xếp theo độưu tiên và sự phụ thuộc của chúng và được phân công cho các lập trình viên trưởng (xem mục 5.2). Hơn nữa, các lớp được xác định trong tiến trình "phát triển một mô hình tổng thể" được giao cho các nhà phát triển cá nhân, tức là những người sở
hữu/nắm giữ lớp (xem mục 5.2). Ngoài ra lịch trình và cột mốc chính có thể được thiết lập cho các bộ tính năng.
5.1.4Thiết kế theo tính năng và xây dựng theo tính năng
- Một nhóm nhỏ các tính năng được chọn từ các bộ tính năng và các đội tính năng cần thiết cho việc phát triển các tính năng được chọn được hình thành/thiết lập bởi những người sở hữu lớp. Các quy trình thiết kế theo tính năng và xây dựng theo tính năng là các thủ tục lặp đi lặp lại, trong thời gian đó các tính năng được lựa chọn sẽđược sản xuất. Mỗi lần lặp đi lặp lại nên mất từ một vài ngày đến tối đa là hai tuần. Có thể có các đội đa tính năng (xem mục 5.2) đồng thời thiết kế và xây dựng bộ các tính năng riêng của họ. Tiến trình lặp đi lặp lại này bao gồm các nhiệm vụ như kiểm tra thiết kế, lập trình, kiểm tra đơn vị (unit testing), tích hợp và kiểm tra mã. Sau khi lặp lại thành công, các tính năng hoàn thành được đẩy cho khâu xây dựng chính trong khi việc lặp đi lặp lại khâu thiết kế và xây dựng bắt đầu với một nhóm các tính năng mới được lấy từ bộ tính năng (xem hình bên dưới).
Agile methodology - 40 -
Hình 20: Tiến trình thiết kế theo tính năng và xây dựng theo tính năng của FDD
5.2Các vai trò và trách nhiệm
- FDD phân loại vai trò của mình thành ba loại: vai trò chính, vai trò hỗ trợ và vai trò bổ sung (key roles, supporting roles and additional roles) (Palmer và Felsing 2002). Vai trò chính trong một dự án FDD là: nhà quản lý dự án, kiến trúc sư trưởng, nhà quản lý phát triển, lập trình viên trưởng, người sở hữu lớp và các chuyên gia phạm vi. Năm vai trò hỗ trợ bao gồm: nhà quản lý phát hành, luật sư ngôn ngữ/ chuyên gia ngôn ngữ, kỹ sư xây dựng, người thợ công cụ (toolsmith) và nhà quản trị hệ thống. Thêm ba vai trò cần thiết trong bất kỳ dự án nào là những tester, những người triển khai (deployers) và người viết kỹ thuật (technical writers). Một thành viên của nhóm có thểđóng nhiều vai trò, và một vai trò có thểđược chia sẻ bởi nhiều người (Palmer và Felsing 2002).
- Theo sau là các nhiệm vụ và trách nhiệm của các vai trò khác nhau, được trình bày bởi Palmer (2002), được mô tả ngắn gọn.
5.2.1Nhà quản lý dự án
- Người quản lý dự án là nhà lãnh đạo về hành chính và tài chính của dự án. Một trong những nhiệm vụ của mình là bảo vệ nhóm dự án khỏi phiền nhiễu
Agile methodology - 41 -
từ bên ngoài và cho phép nhóm làm việc và cung cấp điều kiện làm việc thích hợp. Trong FDD, người quản lý dự án có tiếng nói cuối cùng về phạm vi, kế hoạch làm việc, và nhân sự của dự án.
5.2.2Kiến trúc sư trưởng
- Các nhà thiết kế trưởng chịu trách nhiệm về thiết kế tổng thể hệ thống và mở các phiên họp thiết kế workshop (hội thảo/phân xưởng) được tổ chức cho đội ngũ(Palmer và Felsing 2002). Kiến trúc sư trưởng cũng ra các quyết định cuối cùng về tất cả các vấn đề thiết kế. Nếu cần thiết, vai trò này có thể
được chia thành các vai trò của kiến trúc sư phạm vi và kiến trúc sư kỹ thuật. (adsbygoogle = window.adsbygoogle || []).push({});
5.2.3Nhà quản lý phát triển
- Nhà quản lý phát triển chỉđạo các hoạt động phát triển hàng ngày và giải quyết bất kỳ cuộc xung đột nào có thể xảy ra trong nhóm. Ngoài ra, vai trò này phải chịu trách nhiệm giải quyết các vấn đề về nguồn lực. Các nhiệm vụ của vai trò này có thểđược kết hợp với những nhà kiến trúc sư trưởng hay nhà quản lý dự án.
5.2.4Lập trình viên trưởng
- Các lập trình viên trưởng là một nhà phát triển giàu kinh nghiệm, những người làm trong khâu phân tích và thiết kế các yêu cầu của các dự án. Các lập trình viên trưởng chịu trách nhiệm chỉ huy các nhóm nhỏ trong việc phân tích, thiết kế và phát triển các tính năng mới. Lựa chọn các tính năng từ tập tính năng được phát triển trong bước lặp kế tiếp của quy trình "thiết kế theo tính năng và xây dựng theo tính năng" và xác định các lớp và những người sở hữu lớp mà cần thiết cho bước lặp đi lặp lại trong đội tính năng cũng thuộc về trách nhiệm của các lập trình viên trưởng, đồng thời hợp tác với các lập trình viên trưởng khác để giải quyết các vấn đề kỹ thuật và nguồn lực, và báo cáo tiến độ của nhóm hàng tuần.
5.2.5Người sở hữu lớp
- Người sở hữu lớp làm việc dưới sự hướng dẫn của các lập trình viên trưởng trong nhiệm vụ thiết kế, lập trình, thử nghiệm và viết tài liệu. Người sở hữu lớp chịu trách nhiệm phát triển lớp mà anh ấy đã được giao là người sở hữu nó. Những người sở hữu lớp tạo thành các nhóm tính năng. Đối với mỗi lần lặp, những chủ sở hữu lớp đó có liên quan đến lớp của họđược bao gồm
Agile methodology - 42 -
trong các tính năng được lựa chọn cho sự lặp đi lặp lại việc phát triển tiếp theo.
5.2.6Các chuyên gia phạm vi
- Các chuyên gia phạm vi có thể là người sử dụng, một khách hàng, một nhà tài trợ, một nhà phân tích kinh doanh hoặc kết hợp giữa họ. Nhiệm vụ của các chuyên gia là thu thập kiến thức về các yêu cầu khác nhau để phát triển hệ thống nên thực hiện như thế nào. Chuyên gia phạm vi truyền những kiến thức này cho các nhà phát triển đểđảm bảo rằng các nhà phát triển cung cấp một hệ thống có đầy đủ thích hợp.
5.2.7Nhà quản lý phạm vi
- Nhà quản lý phạm vi chỉ dẫn các chuyên gia phạm vi và giải quyết sự khác biệt ý kiến giữa họ liên quan đến các yêu cầu cho hệ thống.
5.2.8Nhà quản lý phát hành
- Nhà quản lý phát hành kiểm soát tiến độ của quy trình bằng cách xem xét các báo cáo tiến độ của các lập trình viên trưởng và tổ chức các cuộc họp tiến độ ngắn với họ, sau đó báo cáo tiến độ cho nhà quản lý dự án.
5.2.9Chuyên gia ngôn ngữ
- Một thành viên trong nhóm chịu trách nhiệm thu thập kiến thức toàn diện, ví dụ, một ngôn ngữ lập trình hoặc công nghệ cụ thể. Vai trò này đặc biệt quan trọng khi nhóm dự án đối mặt với một số công nghệ mới.
5.2.10Kỹ sư xây dựng
- Một người chịu trách nhiệm thiết lập, bảo trì và điều hành quá trình xây dựng, bao gồm các nhiệm vụ quản lý hệ thống kiểm soát phiên bản và xuất bản các tài liệu.
5.2.11Toolsmith
- Toolsmith chịu trách nhiệm xây dựng các công cụ nhỏ cho các nhóm phát triển, thử nghiệm và chuyển đổi dữ liệu trong dự án. Ngoài ra, một toolsmith có thể thiết lập và bảo trì cơ sở dữ liệu và các trang web cho các mục đích cụ thể của dự án.
5.2.12Nhà quản trị hệ thống
- Nhiệm vụ của một nhà quản trị hệ thống là cấu hình, quản lý và khắc phục sự cố các máy chủ, mạng lưới các máy trạm và phát triển và thử nghiệm các
Agile methodology - 43 -
môi trường được sử dụng bởi đội dự án. Ngoài ra, các nhà quản trị hệ thống có thểđược tham gia vào khâu sản xuất hệ thống đang được phát triển.
5.2.13Tester
- Các tester xác nhận rằng hệ thống đang được sản xuất có đáp ứng được các yêu cầu của khách hàng hay không. Có thể là một nhóm độc lập hoặc là một phần của nhóm dự án.
5.2.14Những người triển khai
- Công việc của những người triển khai có liên quan tới việc chuyển đổi dữ liệu hiện có sang định dạng được yêu cầu bởi hệ thống mới và tham gia vào việc triển khai các phiên bản mới. Có thể là một nhóm độc lập hoặc là một phần của nhóm dự án.
5.2.15Những người viết kỹ thuật
- Tài liệu hướng dẫn người dùng được chuẩn bị bởi những người viết kỹ thuật, những người này có thể hình thành một nhóm độc lập hoặc là một phần của nhóm dự án. (adsbygoogle = window.adsbygoogle || []).push({});
5.3Kiểm chứng thực tiễn (Practices)
- FDD chứa một tập hợp các "kiểm chứng thực tế tốt nhất" (best practices) và các nhà phát triển phương pháp tuyên bố rằng mặc dù các kiểm chứng được lựa chọn không phải là mới, nhưng sự pha trộn cụ thể của những thành phần này tạo ra duy nhất 5 quy trình FDD cho mỗi trường hợp. Palmer và Felsing cũng chủ trương rằng tất cả các kiểm chứng có sẵn nên được sử dụng để thu được nhiều lợi ích của các phương pháp này nhất như là không có thực hành duy nhất chi phối toàn bộ quy trình (2002). FDD liên quan đến các thực hành sau đây:
Mô hình hóa đối tượng phạm vi (Domain Object Modeling): Thăm dò và giải thích phạm vi của vấn đề. Các kết quả nằm trong một khuôn khổ mà ởđó các tính năng được thêm vào.
Phát triển theo tính năng: phát triển và theo dõi tiến độ thông qua một danh sách các chức năng nhỏ có giá trị với khách hàng và tách rời một cách hữu dụng.
Quyền sở hữu lớp (mã lệnh) riêng biệt: mỗi lớp có một người duy nhất được đề cử là người chịu trách nhiệm cho tính nhất quán, hiệu suất, và tính toàn vẹn về khái niệm của lớp.
Các đội tính năng (feature teams): đề cập đến các đội nhỏ được hình thành một cách năng nổ/sôi nổi.
Agile methodology - 44 -
Việc kiểm tra: đề cập đến việc sử dụng các cơ chế nổi tiếng nhất để phát hiện khuyết tật/nhược điểm.
Các xây dựng chính quy (regular builds): đề cập đến việc phải đảm bảo rằng luôn luôn có một hệ thống rõ ràng đang chạy sẵn. Các xây dựng chính quy tạo thành chuẩn để các tính năng mới được thêm vào.
Quản lý cấu hình: cho phép xác định và theo dõi lịch sử của các phiên bản mới nhất của mỗi tập tin mã nguồn đã hoàn tất.
Báo cáo tiến độ: tiến độ được báo cáo dựa trên công việc đã hoàn thành trên tất cả các cấp tổ chức cần thiết.
- Nhóm dự án phải sử dụng tất cả các kiểm chứng bên trên để tuân theo các quy tắc phát triển FDD. Tuy nhiên, nhóm này được phép thích ứng với chúng tùy theo mức độ kinh nghiệm của họ.
5.4Sự chấp nhận và kinh nghiệm
- FDD được sử dụng lần đầu tiên cho công tác phát triển một dự án xây dựng ứng dụng ngân hàng lớn và phức tạp vào cuối những năm 90. Theo Palmer và Felsing (2002), FDD thích hợp cho các dự án mới đang bắt đầu, các dự án đang tăng cường và nâng cấp mã nguồn hiện có, và các dự án được giao nhiệm vụ tạo ra phiên bản thứ hai của một ứng dụng hiện có. Các tác giả cũng đề nghị các tổ chức nên áp dụng phương pháp này dần dần từng phần nhỏ và cuối cùng là áp dụng toàn bộ nó khi dự án phát triển bắt đầu xuất phát.
5.5Phạm vi sử dụng
- Các tác giả còn nói rõ rằng FDD "xứng đáng được xem xét nghiêm túc bởi bất kỳ tổ chức phát triển phần mềm nào mà cần cung cấp các hệ thống phần mềm kinh doanh quan trọng và chất lượng đúng thời hạn". Thật không may, vẫn còn khó tìm các báo cáo thực nghiệm đáng tin cậy, mặc dù một số công ty tư vấn phần mềm có vẻủng hộ phương pháp như có thể dễ dàng được nhìn thấy trên Internet.
5.6Nghiên cứu hiện tại
- Vì không có các câu chuyện thành công đáng tin cậy hoặc các báo cáo thất bại trong việc sử dụng FDD, bất kỳ cuộc nghiên cứu, thảo luận và so sánh nào sẽ là điều thú vị nhất đối với các học giả cũng như các học viên, cho phép họ thực hiện FDD tốt hơn trong từng trường hợp cụ thể, để quyết định khi nào sử dụng FDD mà không phải là một số phương pháp phát triển nhanh khác, và khi không sử dụng phương pháp FDD. Tuy nhiên, nghiên cứu này vẫn
Agile methodology - 45 -
được thực hiện. Vì phương pháp này tương đối mới, nó vẫn còn đang phát triển, và ngày càng có nhiều công cụ hỗ trợ hơn sẽ có sẵn trong tương lai.