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

Trong thực tế, 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

ĐẠI HỌC QUỐC GIA HÀ NỘI

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

Môn học

QUẢN LÝ DỰ ÁN PHẦN MỀM

Chủ đề tìm hiểu

Managing Agile Projects

Chương 6: Các luật đơn giản (Simple Rules)

GVHD: TS Trương Anh Hoàng, TS Phạm Ngọc Hùng

Nhóm thực hiện (Nhóm 6):

1- Đinh Quang Đạt

2- Trần Mạnh Đông

3- Nguyễn Văn Trãi

4- Nguyễn Khoa Hải

5- Phạm Thanh Tùng

Hà Nội, 12/2012

MỤC LỤC

I Tổng quan 3

II Các hoạt động 5

II.1 Hoạt Động: Đánh giá hiện trạng 6

II.2 Hoạt động: Tùy chỉnh các phương pháp 8

II.3 Hoạt động: Cộng tác nhóm để thay đổi 17

II.4 Hoạt động: Phát triển một kế hoạch phát hành/ tính năng tồn đọng 20

II.5 Hoạt động: Phát triển các kế hoạch lặp /các nhiệm vụ tồn đọng 24

II.6 Hoạt độ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 27

II.7 Hoạt động: Tiến hành kiểm thử chấp nhận 30

II.8 Hoạt động: Quản lý phát hành phần mềm 30

II.9 Hoạt động: Tập trung vào giá trị kinh doanh 31

III Tổng kết 33

IV Tham khảo 33

I Tổng quan

Những mục đích và những nguyên tắc đơn giản, rõ ràng làm phát sinh các hành vi phức tạp, thông minh Những luật, những quy định phức tạp làm phát sinh các hành vi đơn giản, ngu ngốc

Các phương pháp phát triển trong ngành công nghệ phần mềm trải qua từ các phương pháp tình thế thường thấy ở các tổ chức nhỏ cho tới các phương pháp cứng nhắc, phức tạp ở các công ty lớn Bất chấp sự sai lệch về kích thước và độ phức tạp, rất nhiều người trong ngành công nghiệp phần mềm vẫn nhầm lẫn tin rằng cách kiểm soát phức tạp và cứng nhắc tương đương với kỷ luật và có giá trị Bởi vì những suy nghĩ này, một phương pháp được đưa ra, thậm chí ngay ở các tổ chức nhỏ, dường như không thể thay đổi để tăng trưởng về kích cỡ và tính phức tạp Khi các nhà quản lý thấy khó khăn để dẫn dắt đội của họ trong việc hoàn thành các yêu cầu của các phương pháp luận phức tạp với các

kế hoạch chi tiết, rối rắm và tài liệu Sự chuyên nghiệp của họ được đặt trong câu hỏi Đó

là luận điểm của tôi cho rằng tính kỷ luật và độ chín trong việc áp dụng thường xuyên và nhất quán các yếu tố cốt yếu là cần thiết để cung cấp các kết quả nhanh chóng và đáng tin cậy

Trong thực tế, 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 Các hệ thống thích nghi với sự phức tạp (CAS) được giới thiệu trong bài 1, “Agile Project Management Defined”, cho rằng, hành vi thông minh, phức tạp xuất hiện từ sự tương tác của các thanh viên trong nhóm theo quy tắc đơn giản, tự phát Các hiệu quả tốt hơn đạt được bằng cách xác định các quy tắc đơn giản cho các đội trong dự án và khuyến khích sự sáng tạo của họ, chứ không phải cố gắng thực thi các quy tắc phức tạp, cứng nhắc Phương pháp Agile hỗ trợ hướng tiếp cận này thông qua tư duy “hầu như không đủ” hướng tới kế hoạch, quy trình, kiểm soát, và tập trung vào cung cấp kết quả kinh doanh

Cụm phức hợp từ những quy tắc đơn giản

Sự phối hợp phức tạp và thích ứng trong chuyến bay của một đàn chim là thực sự là một cảnh đẹp 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 người khác?

Mô hình máy tính đã sao chép hành vi này bằng cách cho mỗi con chim mô phỏng một mức độ năng lực ra quyết định.Trong các mô hình này, 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

 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 Mặc dù các "tác nhân" riêng

lẻ trong các nhóm có quy tắc chiến lược và năng lực riêng, hành vi chung của họ được đặc trưng bởi một sự sắp xếp phủ nhau, tự tổ chức, và trí thông minh tập thể lớn hơn của các bộ phận Mục đích thực tiễn của các quy tắc đơn giản là thực hiện một tập hợp các quy tắc đơn giản, các phương pháp luận thích nghi cho phép các đội cung cấp những giá trị thương mại một cách nhanh chóng và đáng tin cậy Một ví dụ như vậy, chương này trình bày cách cho người quản lý nhanh để tùy chỉnh và thực hiện eXtreme Programming (XP) thực hành cho các đội phát triển phần mềm nhanh Các hoạt động liên quan với thực hành này có ý nghĩa sau đây:

 Đánh giá hoàn cảnh để xác định đặc điểm của nó

 Xác định và thực hiện một tập hợp các quy tắc đơn giản phù hợp với hoàn cảnh

 Rèn luyện tính kỷ luật cần thiết cho các ứng dụng liên tục và nhất quán của các quy tắc đơn giản

Các hoạt động được nhóm lại thành hai nhóm hoạt động cần thiết để lập nên các quy tắc đơn giản: tùy biến các quy tắc đối với hoàn cảnh và thực hiện các quy tắc, bao phủ các bước kế tiếp

Để thực hiện phương pháp "hầu như không đủ" thông qua một tập tối thiểu các quy tắc quá trình đơn giản, bạn cần phải xác định một vài kỷ luật cần thiết và ranh giới tạo ra một môi trường tự do và đổi mới mà trong đó các thành viên trong nhóm có thể làm việc cộng tác hướng đến những kết quả kinh doanh mong muốn Bảng 6-1 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

Bảng 6-1 Thiết lập quy tắc đơn giản: Trách nhiệm của người quản lý Agile

 Chiêu mộ đội ngũ dành cho sự thay đổi Thực hiện các quy tắc Quản lý:

 Xây dựng kế hoạch chính thức/ những tính năng tồn đọng

 Xây dựng những kế hoạch nhắc lại/ những nhiệm vụ tồn đọng

 Tạo điều kiện thuận lợi cho thiết kế phần mềm, code, test, triển khai

 Tiến hành kiểm tra nghiệm thu

 Quản lý việc ra mắt phần mềm Lãnh đạo:

 Tập trung vào giá trị thương mại

Chỉnh sửa các quy tắc cho môi trường

Hai yếu tố chính ảnh hưởng đến phương pháp thực hiện là môi trường phù hợp và sự tương tác trong môi trường Môi trường phù hợp là quan trọng bởi vì môi trường của các

tổ chức khác nhau yêu cầu quy trình của các quy tắc cũng khác nhau.Trong khi đó, một

số môi trường có thể có nhiều cấu trúc hơn và cần các quy trình nặng nề hơn, những môi trường khác có thể nhanh nhẹn hơn và cần các quy trình nhẹ hơn

Sự tương tác trong môi trường cũng đóng góp một phần, bởi vì các đội dự án "hệ thống mở" tương tác với môi trường của tổ chức liên tục thông qua các chu kỳ của đầu vào, chuyển đổi, đầu ra, và thông tin phản hồi, trong đó ngụ ý rằng có trong không có bộ các quy tắc đơn giản nào đại diện cho “tốt nhất” Cả hai yếu tố này cần được xem xét khi thực hiện các nguyên tắc phương pháp luận để tránh những vấn đề về lệch chi tiết, để định hướng cho các quy tắc về hướng kết quả kinh doanh mong muốn, và để tăng cường tính áp dụng của chúng Các hoạt động để giải quyết phù hợp với môi trường là đánh giá hiện trạng và tùy chỉnh phương pháp luận Các hoạt động để giải quyết tương tác môi trường là tranh thủ đội ngũ cho sự thay đổi

II.1 Hoạt Động: Đánh giá hiện trạng

Dữ liệu về tổ chức của bạn cần phải được thu thập trước khi thực hiện phương pháp luận được tùy chỉnh có thể được phát triển Để thu thập các dữ liệu này, cho dù giới thiệu một phương pháp nhanh trên một dự án hoàn toàn mới "Greenfield" hoặc xây dựng trên một

dự án hiện có, bạn cần tiến hành đánh giá nhanh chóng nhưng chăc chắn về trạng thái tổ chức của bạn và các quy trình phát triển của nó Cách tốt nhất để đánh giá hiện trạng để

xây dựng một hồ sơ cá nhân trên cơ sở dữ liệu về văn hóa và các quá trình của tổ chức của bạn Dữ liệu bạn sẽ cần cho cấu hình này bao gồm:

 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 các lực lượng 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ì? Mục đính để bảo vệ cái đã có hay là kinh doanh

 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?

 Văn hóa của công ty như thế nào? Mọi người dường như xuất hiện để làm việc, không có động lực và xem đồng hồ, hay họ dường như có đông lực và tràn đầy năng lượng? Có một bầu không khí thân thiện và tin tưởng hay bầu không khí là

dữ liệu thu được Đặt thanh trượt khoảng nơi mà bạn nghĩ môi trường và các hệ thống con đang liên tục có liên quan Ví dụ, nếu cấu trúc của tổ chức là cực kỳ quan liêu, nơi

mà thanh trượt tất cả các cách bên trái Nếu phong cách quản lý của nó là hình thức nhưng không khá độc đoán, nơi mà thanh trượt về phía giữa.Nói chung, bạn sẽ thấy rằng các thanh trượt có xu hướng cụm lại với nhau

Hình 6.1: Hồ sơ tổ chức [1]

Các cụm của các thanh trượt cung cấp các chỉ dẫn hợp lý rõ ràng về bản chất của việc thực hiện mà bạn nên sử dụng Các cơ quan với sự quản lý dân chủ và có tổ chức trong môi trường biến động (nhóm thanh trượt về phía bên phải) Các tổ chức với môi trường

ổn định hơn, chiến lược phòng thủ, và có cơ cấu hành chính (nhóm thanh trượt về phía bên trái) Trong thực tế, nếu tất cả các thanh trượt kết thúc đường bên trái, xem xét lại việc thực hiện các phương pháp nhanh và thay bằng một phương pháp ổn định và chắc chắn

Sau khi bạn đánh giá hiện trạng và xây dựng các thanh trượt của tổ chức, bạn nên có các thông tin cần thiết để tùy chỉnh phương pháp nhanh của bạn, như mô tả tiếp theo

II.2 Hoạt động: Tùy chỉnh các phương pháp

− Phiên bản ra mắt nhỏ: Đưa một hệ thống đơn giản vào chế tạo một cách nhanh chóng, và sau đó phát hành phiên bản mới trên một chu kỳ rất ngắn

− Ẩn dụ (Metaphor): Hướng dẫn mọi sự phát triển với sự chia sẻ đơn giản về cách hoạt động của toàn bộ hệ thống

− Thiết kế đơn giản: Thiết kế hệ thống càng đơn giản càng tốt tại bất kỳ thời điểm nào Bỏ đi sự phức tạp không cần thiết ngay sau khi nó được phát hiện

− Kiểm tra: Các lập trình viên liên tục viết các unit test phải chạy hoàn hảo cho sự phát triển tiếp tục Khách hàng viết bài kiểm tra thể hiện rằng các đặc tính đã hoàn thành

− Tái cấu trúc mã nguồn (refactoring): Các lập trình viên cơ cấu lại hệ thống mà không cần thay đổi hành vi của hệ thống để loại bỏ trùng lặp, cải thiện sự giao tiếp giữa các thành phần, và đơn giản hóa hoặc thêm tính linh hoạt

- Lập trình đôi (pair programming): Tất cả các code viết bởi với hai người lập trình trên cùng một máy

− Sở hữu tập thể: Bất cứ ai cũng có thể thay đổi code ở bất cứ nơi nào trong hệ thống vào bất cứ lúc nào

− Liên tục hội nhập: Tích hợp và xây dựng hệ thống nhiều lần một ngày, mỗi khi một nhiệm vụ được hoàn thành

− Bước đi vững chắc: Không bao giờ làm việc thêm giờ trong một tuần liên tiếp

− Về phía khách hàng: Có một thực tế, Người sử dụng trực tiếp trong nhóm có thể

có toàn bộ thời gian để trả lời mọi câu hỏi

− Viết mã chuẩn: Các lập trình viên viết tất cả code phù hợp với quy tắc tăng cường

sự giao tiếp thông qua code

Theo Eisenhardt và Sull, quy tắc đơn giản có thể được phân loại như: quy tắc như thế nào, giới hạn của quy tắc,các quy tắc ưu tiên, các quy định thời gian, và quy tắc thoát ra Quản lý nhanh có thể 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

 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

Hai kịch bản sau đây được coi là minh họa chi tiết: làm thế nào cách phân loại này có thể được sử dụng để tùy chỉnh cách thức mà XP được thực hiện

Kịch bản 1: Thời gian tới giá trị

Kịch bản 1 có một đội ngũ sự phát triển triển nhỏ của bốn lập trình viên cao cấp trong một tổ chức nhỏ mong muốn bắt đầu với XP và sẵn sàng cam kết cho mọi sự rèn luyện

Nó có một khách hàng sẵn lòng và nhiệt tình, có một nhu cầu cấp thiết để tạo ra và phát hành một sản phẩm phần mềm nhanh chóng và bắt đầu gặt hái lợi nhuận trên sản phẩm

đó trong vòng vài tháng Chất lượng sản phẩm cần phải được tốt, nhưng nó không phải là xem xét chính.Phần mềm này có đủ sự linh hoạt để xử lý các chức năng bổ sung Mục tiêu kinh doanh chính của nhóm nghiên cứu là để phát triển và phát hành một sản phẩm

cơ bản cho người sử dụng càng nhanh càng tốt và xây dựng từng bước từ cơ sở đó Hồ sơ

cá nhân tổ chức, thể hiện trong Hình 6.2, chỉ ra rằng dự án này là phù hợp cho việc thực hiện nghèo nàn

Hình 6.2: Kịch bản 1 hồ sơ tổ chức

Bảng 6-2 cung cấp một tập tối thiểu các quy tắc đơn giản cho dự án này Các quy tắc làm thế nào để chỉ định các thực hiện XP cần thiết để tạo ra phần mềm chất lượng Đối với kịch bản này, Tất cả các hoạt động phát triển của XP đã được lựa chọn ngoại trừ lập trình theo cặp Bởi vì bốn lập trình viên tin rằng họ có thể mã nhanh hơn cá nhân, họ sẽ cố gắng lập trình cặp lặp đi lặp lại, nhưng đã sẵn sàng cho chương trình một mình Để giảm thiểu tác động về chất lượng , họ đồng ý để chung nhau và xem xét mã của nhau mỗi ngày

Bảng 6.2: Các luật dự án đơn giản “Thời gian – giá trị”

Luật “Làm thế nào” Các tính năng chính của XP  Phát triển hướng thử

nghiệm

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

 Tái cấu trúc mã nguồn

 Mã hóa theo chuẩn

 Ẩn dụ

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

 Sở hữu chung Luật biên Sử dụng các điều kiện biên

để phân định hành động được phép

 Tại khách hàng

 Khách hàng và lập trình viên cùng hợp tác

 Bạn sẽ không cần đến

nó

 Làm những cái đơn giản nhất có thể Luật ưu tiên Giúp phân hạng cơ hội công

việc

 Lập kế hoạch sẽ tiến hành

Luật thời gian Xác định và đồng bộ tiến độ

bàn giao

 Nhỏ, phát hành hàng tháng

 Lặp lại theo 1 tuần Luật kết thúc Xác định một chiến lược kết

thúc để giảm thiểu tối đa chi phí ngầm

 Giữ vững tiến độ

 Các tùy chọn hủy bỏ, chuyển đổi, trì hoãn hoặc phát triển gia tăng

Luật biên khoanh định các hành động được phép Khách hàng và lập trình viên cùng thống nhất để đạt được sự cân bằng trách nhiệm của hai bên: Khách hàng đặc tả các tính năng và độ ưu tiên, lập trình viên ước lượng và phát triển Sự cân bằng này đảm bảo rằng giá trị cao nhất của công việc luôn đạt được (bởi vì chính khách hàng chỉ định điều này) Luật “Bạn sẽ không cần đến nó” yêu cầu thực thi khi thực sự cần thiết, không phải khi nó được dự đoán là cần thiết, và đảm bảo rằng chỉ những điều thực sự cần thiết được thực thi giảm thời gian – giá trị Luật “Làm cái đơn giản nhất có thể” thúc đẩy sử dụng các giải

pháp tối thiểu và khẳng định rằng mọi việc được thực hiện một cách đơn giản, nhanh chóng, và chuyên nghiệp

Thực tế việc lập kế hoạch trong XP cung cấp các quy tắc ưu tiên Khách hàng đưa ra đặc

tả ưu tiên công việc do đó các tính năng được nhân theo giá trị của công việc theo thứ tự

ưu tiên đó Các tính năng với độ ưu tiên cao nhất được nhận trước, đảm bảo rằng cực tiểu hóa thời gian – giá trị Các nhà phát triển xác định các rủi ro qua đặc điểm công nghệ Các rủi ro này được giải quyết đầu tiên để giảm thiểu rủi ro chung của dự án về sau Với kịch bản đầu tiên, các luật thời gian là quan trọng nhất Chúng được chọn để cực tiểu thời gian – giá trị và thiết lập một đội trên một lịch thích hợp Các thông báo nhỏ sẽ được thông báo mỗi tháng cho người dùng cuối Mỗi bước lặp sẽ chính xác lại mỗi tuần, và các tính năng của phần mềm sẽ được giao cho khách hàng ở cuối mỗi lần lặp Đội thực hiện

sẽ sử dụng tiến độ ổn định để đảm bảo rằng nó không bị mệt mỏi bởi làm việc nhiều hơn một tuần liên tục

Luật kết thúc được bao phủ bằng cách cung cấp cho khách hàng với các tùy chọn linh hoạt ở phần cuối của mỗi lần lặp Lặp lại hàng tuần và phát hành hàng thán cho phép thẩm định nhanh chóng bất kì giả định nào về sản phẩm Dữ liệu phản hồi về khả năng tồn tại sản phẩm thực sự có sẵn bởi vì người dùng cuối được tham gia để thông qua tất cả Khách hàng có thể chọn từ bỏ dự án vào cuối mỗi lần lặp bất kỳ, chuyển đổi mức ưu tiên tại bất kỳ ranh giới lặp dựa trên các thay đổi hoàn cảnh, hoặc trì hoãn hoạt phát triển chức năng dựa tên người dùng cuối và phản hồi của người dùng cuối và thị trường

Kịch bản 2: Phục hồi và ổn định

Kịch bản 2 liên quan tới một tổ chức lớn với một đội ngũ phát triển vừa phải mà sẽ thất bại trong việc cung cấp phần mềm làm việc được, đã quá thời hạn, và đã bàn giao phần mềm với các vấn đề nghiêm trọng Tổ chức này có một khách hàng muốn có ít nhất một sản phẩm cơ bản nhanh nhất có thể và ít lỗi hơn Mặc dù không phải là vấn đề chính cần

xem xét, tốc độ bàn giao cần phải phù hợp Mục tiêu kinh doanh chính của tổ chức là như vậy, nỗ lực phục hồi và ổn định Về mặt hậu cần, tổ chức không thể đặt chung tất cả nhân lực phát triển Nó sẽ sử dụng các nhà phân tích kinh doanh như là một ủy nhiệm để đại diện cho khách hàng Bởi vì nó thuộc nhiều quy định và giám sát của chính quyền, nó cần được kiểm soát và chi tiết tài liệu nhiều hơn công ty trong kịch bản 1 Đây là hồ sơ tổ chức, được thể hiện trong Hình 6.3, chỉ ra rằng dự án đó được phù hợp cho đại diện thực hiện nặng hơn, bậc cao hơn

Hình 6.3: Hồ sơ tổ chức kịch bản 1

Bảng 6.3 cung cấp một tập các luật cơ bản cho dự án này Đối với kịch bản trên, luật

“Làm thế nào” trong XP được chọn sử dụng Lập trình cặp, sở hữu chung, và tiêu chuẩn

mã hóa được lựa chọn để giúp truyền đạt những hiểu biết về XP từ các chuyên gia cho người mới một cách nhanh chóng và nâng cao chất lượng Bởi vì thiết kế đơn giản là không thể bởi vì sự kế thừa code sẽ không tốt dần, nó được thay thế bởi các đánh giá tiêu chuẩn thiết kế Tái cấu trúc mã nguồn được chọn, mặc dù thực tế bị hạn chế bởi vì không

có các kiểm tra tự động được đưa ra Bởi vì việc liên tục tích hợp là không thể, một xây dựng hàng ngày được sử dụng thay thế Đại diện của khách hàng sẽ thay mặt khách hàng

Cuối cùng, để xác định các khuyết tật và nâng cao chất lương, các hệ thống kiểm thử chuyên dụng được thực hiện tự động

Bảng 6.3: Các luật cơ bản “Khôi phục và ổn định”

Luật làm thế nào Các tính năng chính của XP  Lập trình cặp

 Đánh giá thiết kế

 Tái cấu trúc mã nguồn

định các hành động được phép

 Tự động kiểm thử chấp nhận

 Khách hàng và lập trình viên cũng thống nhất

 Phát triển hướng kiểm thử (chỉ đối với

mã mới)

 Yêu cầu chi tiết, kiến trúc hẹ thống, kế hoạch kiểm thử, và phát hành tài liệu chú

thích Luật ưu tiên Giúp phân hạng cơ hội công

 Lặp lại 3 tuần một lần

Luật kết thúc Định nghĩa một chiến lược

kết thúc để cực tiểu các chi phí ngầm

 Tiến độ bền vững

 Lựa chọn từ bỏ, chuyển đổi, trì hoãn hoặc phát triển thêm

Luật biên bao gồm khách hàng và lập trình viên cùng thống nhất để cân bằng trách nhiệm của hai bên và một quy tắc để thực hiện phát triển hướng kiểm thử chỉ cho mã mới Ngoài ra, để đáp ứng yêu cầu về mặt pháp lý, các yêu cầu chi tiết, kiến trúc hệ thống, kế hoạch kiểm thử, và tài liệu chú thích được tạo ra Thời gian để tạo tài liệu sẽ phải thống nhất với khách hàng Nội dung và mức độ chi tiết sẽ đàm phán với khách hàng và một nhóm kiểm toán nội bộ

Ở đây cũng vậy, việc lập kế hoạch thực tế XP cung cấp các quy tắc ưu tiên Khách hàng chỉ định mức độ ưu tiên của các tính năng và bàn giao theo thứ tự giá trị ưu tiên đã định

ra Tuy nhiên, luật ưu tiên cũng được đưa ra như một thứ hỗ trợ trong việc ổn định dự án: giảm các khuyết tật thông qua thử nghiệm rộng rãi, tạo các xây dựng hàng ngày, và cho phép lặp đi lặp lại dài hơn

Các luật thời gian có liên quan nhưng ít quan trọng hơn trong kịch bản này, mặc dù độ dài cố định của việc lặp lại vẫn được tuân thủ nghiêm ngặt Các bản phát hành nhỏ sẽ được làm vài tháng một lần để chuyển tới người dùng cuối Mỗi lần lặp sẽ là 3 tuần để

chắc chắn rằng đủ thời gian chi phí cho việc lập kế hoạch trên toàn bộ đội và thích hợp với thời gian kiểm thử hệ thống Đội phát triển sẽ sử dụng tiến độ bền vững để đảm bảo rằng bản thân không bị mệt mỏi khi làm việc nhiều hơn một tuần liên tiếp

Các luật kết thúc được phủ bởi việc cung cấp cho khách hàng các lựa chọn linh động ở cuối mỗi lần lặp Khách hàng có thể chọn bỏ dự án ở cuối một lần lặp bất kỳ, chuyển đổi mức ưu tiên ở bất kì biên lặp nào dựa trên thay đổi các hoàn cảnh, hoặc trì hoãn hoặc phát triển thêm các tính năng dựa trên phản hồi

II.3 Hoạt động: Cộng tác nhóm để thay đổi

Để hoạt động với một tập hợp các luật xử lý đơn giản, có phát sinh, đội dự án thường cần quy định các thay đổi bởi cách họ phát triển phần mềm Thông thường, phương pháp tiếp cận từng phần được sử dụng để chuẩn bị cho sự thay đổi này là cô lập các phần chỉ định trong tiến trình phát triển phần mềm cần thay đổi mà không có bất kỳ cân nhắc tổ chức nào Điều này có thể dẫn tới nguy cơ mất đi nhiều thứ Một cách tiếp cận toàn diện, ngược lại, yêu cầu đội phát triển nhanh nhẹn để xem xét quy trình trong bối cảnh tổ chức phát triển như một thể thống nhất và xác định cả bức tranh tổ chức lớn cũng như các phần nhỏ quy trình xử lý phần mềm cá nhân Thay đổi có thể ảnh hưởng đến cách thức mà yêu cầu được xác định, cách mà trong đó phân tích và thiết kế được tổ chức, cách mà mã nguồn được viết, và cách mà nó được kiểm tra Những thay đổi này có ảnh hưởng đến các tổ chức nhóm có liên quan đến vòng đời phát triển phần mềm – người phát triển, kiểm thử, phân tích nghiệm vụ, … Do đó không thể tách rời quá trình phát triển phần mềm với sự thay đổi về mặt tổ chức

Để nhóm cộng tác cùng thay đổi, quản lý cần nhanh nhẹn để giúp toàn bộ nhóm xác định được cả bối cảnh chung của sự thay đổi và các thành phần quá trình thay đổi yêu cầu Một công cụ để thực hiện việc này là phân tích các động lực Phân tích các động lực là cách để tạo ra một cái nhìn toàn diện của tất cả các động lực ngăn cản lại sự thay đổi, làm