1. Trang chủ
  2. » Luận Văn - Báo Cáo

Chủ đề tìm hiểu managing agile projects QUẢN lý dự án PHẦN mềm

36 479 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Quản lý dự án phần mềm
Tác giả Đinh Quang Đạt, Trần Mạnh Đông, Nguyễn Văn Trãi, Nguyễn Khoa Hải, Phạm Thanh Tùng
Người hướng dẫn TS. Trương Anh Hoàng, TS. Phạm Ngọc Hùng
Trường học Trường Đại Học Công Nghệ Thông Tin
Chuyên ngành Quản lý dự án phần mềm
Thể loại Bài tập lớn
Thành phố Thành phố Hồ Chí Minh
Định dạng
Số trang 36
Dung lượng 415,09 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

 Phát triển các kế hoạch lặp/ các nhiệm vụ tồn đọng Tạo điều kiện thuận lợi cho thiết kế phần mềm, viết mã, kiểm thử, và triển khai  Tiến hành kiểm thử chấp nhận  Quản lý phát hành

Trang 1

• Nguyễn Văn Trãi

• Nguyễn Khoa Hải

• Phạm Thanh Tùng

Trang 2

 Phát triển các kế hoạch lặp/ các nhiệm vụ tồn đọng

 Tạo điều kiện thuận lợi cho thiết kế phần mềm, viết

mã, kiểm thử, và triển khai

 Tiến hành kiểm thử chấp nhận

 Quản lý phát hành phần mềm

 Tập trung vào giá trị kinh doanh

Trang 3

Tổng quan

• Các phương pháp phát triển :

Phương pháp tình thế phương pháp phức tạp

• Các tổ chức có kỷ luật tốt nhất là những tổ chức luôn áp dụng các phương pháp đơn giản, dể hiểu được chỉnh sửa cho phù hợp vời điều kiện của họ

để đội của họ có thể cung cấp các phần mềm nhanh chóng và đáng tin cậy

Trang 4

Tổng quan

• Một ví dụ :

Sự phối hợp phức tạp và thích ứng trong chuyến bay của một đàn chim Hiện tượng đầy cảm hứng này xảy ra như thế nào? Có một con chim quản lý phối hợp và chỉ đạo những con khác?

=> Mỗi con chim làm cho tất cả các quyết định phù hợp với các quy tắc đơn giản.

Trang 5

Tổng quan

• Sử dụng 3 quy tắc :

– Tách biệt: tránh tụ tập thành nhóm hoặc va vào

chướng ngại vật – Định hướng: Chỉ đạo theo hướng chung của nhóm – Kết hợp: Di chuyển hướng tới khoảng cách trung bình từ các thành viên của nhóm

Ba quy tắc đơn giản cho kết quả trong hành vi cụm phức tạp

Trang 6

Tổng quan

• Bảng sau đây cho thấy trách nhiệm lãnh đạo và quản lý cần thiết để thiết lập các quy tắc đơn giản một dự án nhanh

Trang 7

Tổng quan

Trang 8

Đánh giá hiện trạng

• Môi trường của tổ chức ổn định hoặc biến động?

– Bao nhiều lần hoặc bao lâu là nó bị ảnh hưởng bởi thị

trường, các vấn đề về lao động, và những xem xét về tài chính?

• Những kế hoạch chiến lược làm gì?

• Những công nghệ thừa hưởng như thế nào?

– Hệ thống kỹ thuật đơn giản mà không tích hợp, hoặc chúng phức tạp và tích hợp?Có một kiến trúc doanh nghiệp bao trùm?

Trang 9

Đánh giá hiện trạng

• Văn hóa của công ty như thế nào?

– Có một bầu không khí thân thiện và tin tưởng hay bầu

không khí là sự cạnh tranh và ngờ vực?

• Cơ quan có tổ chức hay là quan liêu?

• Quan điểm của nhân viên với quản lý như thế nào?

– Là độc tài hay là dân chủ?

Trang 10

Tùy chỉnh phương pháp

• Theo Eisenhardt và Sull, quy tắc đơn giản có thể được phân thành 5 loại, sử dụng 5 loại đó để tùy chỉnh XP cho môi trường của một tổ chức và có được kết quả kinh doanh mong muốn

– Quy tắc như thế nào: mô tả những đặc tính chính của tiến trình XP

– Giới hạn của quy tắc: phân định điều kiện giới hạn chi phối các hành động cho phép

Trang 11

Tùy chỉnh phương pháp

• Theo Eisenhardt và Sull, quy tắc đơn giản có thể được phân thành 5 loại, sử dụng 5 loại đó để tùy chỉnh XP cho môi trường của một tổ chức và có

được kết quả kinh doanh mong muốn

– Quy tắc ưu tiên: giúp cho những cơ hội về thứ hạng cho sự phát triển tính năng theo thứ tự giá trị kinh doanh.

– Các quy định về thời gian : xác định tốc độ cung cấp và đồng bộ nó trên nhiều đội

– Quy tắc thoát ra : định nghĩa một chiến lược để tránh chi phí rơi vào những khu vực mà lợi nhuận giảm dần.

Trang 12

Cộng tác nhóm để thay đổi

Cách thay đổi “cục bộ” là cô lập phần được chỉ định

cần thay đổi trong quá trình phát triển mà không xem xét bất kì ảnh hưởng nào từ khía cạnh tổ chức

• Cách tiếp cận của Agile:

– Xem xét quá trình phát triển và cơ cấu tổ chức như một thể thống nhất

– Xác định được bức tranh toàn cảnh cũng như các tiến trình phát triển riêng lẻ

– Thay đổi ảnh hưởng đến việc tổ chức nhóm trong toàn bộ vòng đời phát triển của phần mềm, do đó không được tách rời sự thay đổi trong quá trình phát triển với khía cạnh về tổ chức

Trang 13

Cộng tác nhóm để thay đổi

• Quản lý Agile cần giúp toàn bộ nhóm xác định được bối cảnh lớn của sự thay đổi và các tiến trình riêng mà thay đổi yêu cầu

• Sử dụng công cụ phân tích động lực để thực hiện

– Đánh giá hoàn cảnh hiện tại và mong muốn thay đổi

– Liệt kê các động lực thúc đẩy thay đổi vào một cột, các hạn chế khi thay đổi vào một cột khác

– Gán số điểm từ 1 đến 5 cho mỗi động lực thúc đẩy/ hạn chế

Trang 14

– Tham khảo ý kiến chuyên gia khi không thống nhất được

• Chuẩn bị các quy tắc đơn giản để đối phó với các thay đổi tiềm tàng của nhóm

Trang 16

Kế hoạch phát hành/tính năng tồn đọng

Trang 17

bộ thời gian phát triển dự án

• Thực tế là thời gian càng dài thì càng khó lập ước lượng

Trang 18

Kế hoạch phát hành/tính năng

tồn đọng

• Để đối phó với sự không chắc chắn trong tương lai, lập kế hoạch thích ứng xử lý những thay đổi trong yêu cầu bằng cách duy trì một kế hoạch dài hạn, linh hoạt, ở mức cao và chỉ lập kế hoạch chi tiết cho mỗi bước lặp ở thời điểm hiện tại

• Trong XP kế hoạch ở mức cao được gọi là kế hoạch phát hành (release plan) và kế hoạch chi tiết được gọi là kế hoạch lặp (iteration plans)

Trang 19

Kế hoạch phát hành/tính năng

tồn đọng

1 Kế hoạch phát hành bắt đầu với việc khách hàng

trình bày các tính năng mong muốn cho người phát triển

2 Nhà phát triển đáp ứng với cố gắng ước lượng ở

mức cao

3 Cân bằng kết quả ước lượng với tầm quan trọng

của các tính năng, khách hàng sẽ quyết định tính năng nào sẽ đưa vào kế hoạch phát hành và đưa chúng ra phát triển lặp theo thứ tự quan trong của nghiệp vụ

Trang 20

Kế hoạch phát hành/tính năng

tồn đọng

4 Kế hoạch phát hành đôi khi cũng được coi là các

tính năng tồn đọng (feature backlog)

5 Các tính năng có giá trị cao nhất được phát triển

đầu tiên, để phát triển một kế hoạch phát hành, bắt đầu với khách hàng và chuẩn bị các user story của

họ (vẽ ra bức tranh phạm vi/mục tiêu và danh sách các tính năng mong muốn ở mức cao)

Trang 21

cả các cách tới lưu trữ dữ liệu

• User Story nghĩa là “hợp đồng qua đàm thoại” (contracts for conversation), không định nghĩa tất cả yêu cầu

Trang 22

Kế hoạch phát hành/tính năng

tồn đọng

• Nhóm XP sử dụng User Story như một cơ sở cho việc đối thoại trực tiếp giữa khách hàng và nhà phát triển

• User Story mức cao (mất 1-3 tuần thực hiện) mô tả các tính năng đưa vào kế hoạch phát hành

• User Story chi tiết (1-3 ngày thực hiện) đi vào các

kế hoạch lặp

Trang 23

1) Khách hàng giải thích về nhu cầu tổng thể và kỳ vọng của

họ đối với bản phát hành 2) Đội phát triển ước lượng thời gian phát triển lý tưởng của mỗi User Story (1-3 tuần)

3) Khách hàng chỉ định các mức ưu tiên cho mỗi Story Mỗi thẻ chỉ mục nhận một trong các mức ưu tiên: Cao, trung bình, thấp

4) Khách hàng và nhóm phát triển di chuyển các thẻ vòng quanh 1 chiếc bàn lớn để tạo ra một tập hợp các Story được thực hiện như bản phát hành Các User Story thuộc nhóm có độ ưu tiên cao được thực hiện trước

Trang 24

Kế hoạch phát hành/tính năng tồn đọng

Trang 25

Kế hoạch lặp/nhiệm vụ tồn đọng

• Để giải quyết phần chi tiết trong lập kế hoạch thích ứng cần tạo kế hoạch lặp (đôi khi cũng gọi là nhiệm

vụ tồn đọng – task backlogs) cho mỗi lần lặp

• Chuẩn bị xây dựng kế hoạch lặp bằng cách làm việc với khách hàng để in hoặc viết chi tiết các User Story lên các thẻ chỉ mục

• Các User Story cần chi tiết tới mức mà có thể thực hiện trong thời gian ít hơn 3 ngày

• Cần thực hiện các chức năng hệ thống như trong User Story mức cao trong kế hoạch phát hành

Trang 26

Kế hoạch lặp/nhiệm vụ tồn đọng

• Để tạo kế hoạch lặp, tổ chức một cuộc họp kế

hoạch lặp khi bắt đầu mỗi lần lặp với nội dung sau:– Khách hàng lựa chọn những User Story giá trị nhất từ kế hoạch phát hành

– Mỗi User Story được chia thành các nhiệm vụ (task) cần được hoàn thành Các nhiệm vụ này và các nhiệm vụ không phải lập trình khác (tài liệu, thiết kế…) được viết vào các thẻ giống như các Story

Trang 27

Kế hoạch lặp/nhiệm vụ tồn đọng

– Các nhà phát triển đăng kí cho thẻ và ước lượng mất bao lâu để hoàn thành nhiệm vụ trên đó trong thời gian lý tưởng Mỗi nhiệm vụ được ước lượng tối đa 3 ngày Nhiệm

vụ nào ước lượng lớn hơn 3 ngày cần được chia nhỏ thành các nhiệm vụ nhỏ hơn

Trang 28

Kế hoạch lặp/nhiệm vụ tồn đọng

Trang 29

Đơn giản hóa thiết kế phần mềm, viết mã, kiểm thử, và triển khai

• Thực hành theo XP:

– Các chuẩn cho việc viết mã

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

– Tái cấu trúc mã nguồn (Refactoring)

– Lập trình cặp

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

• Theo dõi tốc độ (velocity) dự án

Trang 30

Tiến hành kiểm thử chấp nhận

• Mục tiêu: Xác nhận khách hàng các tiêu chí chấp nhận

• Các công việc phải làm: Trình diễn cho khách hàng các chức năng và tính năng của hệ thống

• Tài liệu: Bản tóm tắt nhu cầu người dung được

hoàn thành

Trang 32

Tập trung vào giá trị nghiệp vụ

• Ưu tiên thứ tự nghiệp vụ

• Ưu tiên nên luôn luôn được thực hiện bởi khách

hàng hoặc người đại diện kinh doanh của họ, không phải người lập trình

• Tất cả các bản tóm tắt nhu cầu người dùng ràng

buộc vào tầm nhìn định hướng (Guiding Vision)

Trang 33

Tập trung vào giá trị nghiệp vụ…

• Tầm nhìn định hướng nên được liên kết với các

mục tiêu chiến lược của tổ chức

• Mỗi phân đoạn đưa ra một hệ thống làm việc kiểm tra đầy đủ với sự tiến bộ trong chức năng của nó

• Hệ thống cần được phát hành cho người dùng cuối thường xuyên

Trang 34

– Tích hợp các quy tắc vào trong nhóm phát triển linh hoạt để tạo ra các giá trị nghiệp vụ nhanh chóng và tin cậy.

Trang 35

Tham khảo

[1] Sanjiv Augustine “Managing Agile Projects”

Prentice Hall PTR, May 2005

• [2] Eisenhardt, Kathleen M., and Donald Sull

"Strategy as Simple Rules." Harvard Business

Review, January 2001

Trang 36

Thank You!

Ngày đăng: 14/12/2013, 15:02

TỪ KHÓA LIÊN QUAN

w