Những điều thiết yếu trong quản lý dự án

 Kế hoạch dự án là một phương tiện rất tốt cho việc bày ra những gì bạn nghĩ bạn sẽ làm, một bản phác thảo cho biết làm thế nào để dự án thực hiện được, và bạn lên kế hoạch như thế nào

Chương3 Những điều thiết yếu trong quản lý dự án.

Quản lý dự án là một nhóm các nhiệm vụ phức tạp có liên quan đến nhau Những nhiệm vụ liên quan đến phát triển phần mềm nhiều nhất là:

 Lên kế hoạch dự án

 Dự toán và lên lịch làm việc

 Quản lý tài nguyên

 Giám sát dự án

 Duyệt và trình bày dự án

 “Mổ xẻ” dự án

1.Lên k ho ch d án ế ạ ự

Việc lên kế hoạch dự án sẽ kéo dài suốt thời gian thực hiện dự án

“Bản kế hoạch” sẽ không bao giờ cố định, bởi vì những thứ trong một

dự án phần mềm điển hình luôn luôn biến đổi

Kế hoạch dự án là một văn kiện được viết bởi người quản lý dự án, được ký duyệt và phê chuẩn bởi đội ngũ phát triển và quản lý cấp cao

Thực chất đó là 1 bản giao kèo, cam kết về những gì đội dự định làm

và cách thức làm điều đó Nó cũng nói lên được dự án được quản lý như thế nào, và trong một vài trường hợp đặc biệt, thậm chí nó mô tả các bước làm thế nào và lúc nào tài liệu sẽ được điều chỉnh

Các thành phần của 1 kế hoạch dự án :

1 Giới thiệu và giải thích dự án

2 Tổ chức dự án

3 Phân tích rủi ro

4 Phần cứng, phần mềm, và nguồn nhân lực cần thiết

5 Dự toán chi tiết công việc và nhiệm vụ.

6 Lịch thực hiện dự án

7 Giám sát dự án.

Không phải tất cả những điều trên là cần thiết cho mọi dự án hoặc mô hình

-Dự án theo định hướng kế hoạch : sử dụng tất cả

- Dự án linh hoạt : chỉ dùng một vài phần

 Kế hoạch dự án là một phương tiện rất tốt cho việc bày ra những gì bạn nghĩ bạn sẽ làm, một bản phác thảo cho biết làm thế nào để dự

án thực hiện được, và bạn lên kế hoạch như thế nào trong việc thực hiện bản phác thảo đó

 Rắc rối của một kế hoạch dự án là nó cố định Một khi nó đã được viết và kí duyệt, quản lý cấp cao sẽ nghĩ rằng dự án sẽ tiến hành chính xác theo các bước trong kế hoạch Nhưng thực tế ???

2.Tổ chức dự án

Tổ chức dự án phải trả lời 3 câu hỏi :

 Bạn sẽ tổ chức nhóm như thế nào?

 Dự án được tổ chức theo Mô hình nào ?

 Dự án sẽ chạy trên nền tảng nào?

Nếu bạn làm việc trong một nhóm có kinh nghiệm, tất cả những điều

đó mọi người đều đã nắm vững, vậy thì phần tổ chức dự án có thể là

“Chúng ta sẽ làm theo những gì chúng ta thường làm”

Tuy nhiên, phần này rất quan trọng cho những dự án mới toanh và

những nhóm thiếu kinh nghiệm, bởi vì phần tổ chức sẽ cho bạn một cái

gì đó để dựa vào khi bạn bắt đầu một dự án thực sự

3.Phân tích r i ro ủ

Trong phần phân tích rủi ro, bạn cần phải nghĩ về những nguy cơ, những điều tồi tệ Kế hoạch này có thể đổ bể vì những lí do gì? Điều gì tệ nhất có thể xảy ra? Chúng ta sẽ phải làm gì khi điều đấy thành sự thực?

Đây là một vài rủi ro nên phòng tránh:

 Chệch lịch làm việc: một công việc chỉ nên làm trong 3 ngày nhưng đã mất

3 tuần để hoàn thành Trong một dự án định hướng kế hoạch, đây có thể là một vấn đề nếu bạn không có các cuộc họp báo cáo tình hình thường

xuyên Đợi 3 tuần để nói với sếp rằng bạn bị muộn luôn tệ hơn là nói bạn sẽ

bị muộn ngay khi bạn biết điều đó Trong một dự án linh hoạt thì chuyện này không thường xảy ra, bởi vì hầu hết những dự án agile có các cuộc họp báo cáo tính trạng hàng này

 Tỉ lệ lỗi cao: kiểm tra ra rất nhiều lỗi => tiếp tục thêm các tính năng mới hay

dừng lại để chữa lỗi ? Đây có thể là một vấn đề thực trong một dự án mà việc tích hợp xảy ra theo một kế hoạch định sẵn - mỗi tuần một lần Với dự án mà tích hợp xảy ra mỗi ngày, bạn có thể theo kịp với các khuyết tật dễ dàng hơn Trong cả hai trường hợp, nếu bạn đang gặp phải một số sai sót cao, tốt nhất là dừng lại, quan sát và tìm ra nguyên nhân gốc rễ của khiếm khuyết trước khi thêm nhiều chức

năng hơn Điều này có thể không dễ với quan điểm của nhà quản lý dự án, nhưng sau đó bạn sẽ phải cảm ơn mình

 Hiểu lầm yêu cầu: nhũng cái ta làm không phải là cái mà khách hàng yêu cầu

Lỗi kinh điển này là kết quả của việc khách hàng và người phát triển sống ở hai thế giới khác nhau Khách hàng thì chỉ hiểu từ góc độ của người sử dụng những

gì anh ta muốn sản phẩm mình làm được Các nhà phát triển thì hiểu từ góc độ kĩ thuật là sản phẩm sẽ làm việc như thế nào Thỉnh thoảng, họ hiểu ý nhau và điều

đó rất tốt; nhưng nhiều khi họ không hiểu ý nhau và đấy là lúc bạn mắc lỗi hiểu lầm yêu cầu của khách hàng Cách tốt nhất để tránh trường hợp này là luôn hỏi ý kiến khách hàng và cho ra mắt sản phẩm của mình thường xuyên khi có thể

 Có quá nhiều yêu cầu: các tính năng mới, các tính năng thay đổi, các tính

năng bị xóa… những khó khăn không bao giờ kết thúc ? Quá nhiều yêu cầu có lẽ là lí do lớn nhất của việc chậm kì hạn, tỉ lệ lỗi cao, và dự án thất bại Điều này xảy ra khi khách hàng (hoặc chính kế hoạch tiếp thị của

bạn, hoặc do đội ngũ phát triển) liên tục thay đổi yêu cầu khi việc phát triển đang được tiến hành Nó dẫn đến phải làm lại một lượng lớn công việc trong việc lập trình, kiểm tra lại các phác thảo cơ bản, và sự chậm trễ kéo dài Quản lý các yêu cầu là việc quan trọng nhất của quản lý dự

án Trong tiến trình định hướng kế hoạch thường có một hội đồng kiểm soát sự thay đổi (CCB), họ kiểm tra mỗi yêu cầu mới và quyết định có nên thêm vào danh sách các tính năng bổ sung hay không Có thể có một thành viên trong nhóm phát triển ở CCB, nhưng điều đấy không cần thiết,

và sự nguy hiểm ở đây là CCB sẽ thêm vài tính năng mới mà không hiểu

rõ được toàn bộ lịch trình và nỗ lực phân nhánh Trong agile, nhóm phát triển thường nắm được danh sách các yêu cầu được ưu tiên (product

backlog - Scrum), và chỉ điều chỉnh danh sách ở những điểm quan trọng trong dự án – sau khi lặp lại ở XP, và sau mỗi lần sprint trong Scrum

 Điều chỉnh nhân sự: nhà phát triển có kinh nghiệm nhất của bạn quyết

định tham gia một việc khác trước khi ra mắt sản phẩm ba tuần Cách tốt nhất để giảm sự điều chỉnh nhân sự này là :

(1) cho những nhà phát triển một công việc thú vị,

(2) tạo một môi trường làm việc thoải mái thân thiện và

(3) để họ tự làm chủ thời khóa biểu của mình

Kì lạ ở chỗ, tiền không phải là động lực chính của các nhà phát triển Điều đó không có nghĩa là họ không muốn được trả lương hậu hĩnh, mà nó

có nghĩa là trả thêm thêm tiền cho họ để họ làm việc chăm chỉ hơn hoặc

giữ chân họ nhìn chung không hiệu quả Và nếu, dù cho bạn đã rất cố gắng, người phát triển giỏi nhất của bạn vẫn rời đi, thì bạn vẫn phải tiếp tục Tuy nhiên, đấy không phải là ngày tận thế Hãy làm giảm ảnh hưởng của việc mất nhân sự = cách truyền đạt hiểu biết về dự án cho toàn bộ developer

Team Những nguyên tắc như quyền sở hữu code chung và những kĩ thuật như lập trình cặp sẽ rất hữu ích

Một khi bạn đã có danh sách các rủi ro của dự án, bạn cần liên lạc từng người và nói về hai vấn đề: phòng tránh và xử lý Đối với mỗi rủi ro, nghĩ về cách bạn tránh

nó Xác định những kẽ hở trong lịch làm việc, duyệt code, chốt các yêu cầu sớm, cho ra sản phẩm thường xuyên, yêu cầu lập trình theo cặp để có thể truyền đạt sự hiểu biết của mình về đoạn code Sau đó bạn cần nghĩ về những gì bạn sẽ làm nếu trường hợp xấu nhất xảy ra, đây là phần xử lý Loại bỏ những đặc tính lỗi khỏi sản phẩn, dừng làm việc trên các đặc tính mới và tiến hành dò lỗi, điều chỉnh các tính năng mới ở các sản phẩm sau, và cứ như vậy Nếu một rủi ro trở thành hiện thực, bạn sẽ phải làm một điều gì đó vì nó, sẽ tốt hơn khi lên kế hoạch trước việc bạn sẽ làm gì

Một khi bạn nói tới phòng tránh và xử lý, bạn sẽ phải có một kế hoạch trình bày làm sao để xử lý các rủi ro đã biết Điều này không hoàn toàn giúp bạn tránh khỏi rắc rối, bởi vì sẽ có giới hạn những rủi ro bạn tránh được; nhưng kinh nghiệm tiếp xúc với rủi ro bạn nghĩ đến sẽ giúp bạn xử lí tốt những rủi ro mới mà bạn bất ngờ gặp trong suốt quá trình làm dự án Nếu dự án của bạn đang sử dụng mô hình lặp ,

đó là một ý kiến tốt để xem lại lỗi của bạn sau mỗi lần lặp lại và xem lỗi nào đã thay đổi, định hình lại những lỗi mới, và loại bỏ những lỗi nào không có khả năng xảy ra nữa

4.Các yêu cầu về tài nguyên

 Phần này rất dễ Có bao nhiêu người bạn cần cho dự án? Họ có cần phải bắt đầu cùng lúc không, hoặc họ có thể bắt đầu dự án vào những giai đoạn được đề sẵn không? Có bao nhiêu máy tính mà bạn cần? Bạn sẽ sử dụng phần mềm nào để phát triển? Môi trường phát triển nào mà bạn cần? Mọi người có được đào tạo trong môi trường đó không? Những phần mềm và phần cứng hỗ trợ nào mà bạn cần có? => cần một hệ

thống quản lý cấu hình

 Rất nhiều các câu hỏi trên thường được giải đáp cho bạn bởi nền tảng

mà bạn đang nhắm tới và miền ứng dụng mà bạn đang làm việc Đấy là phần dễ Câu hỏi về kích thước nhóm, ngày bắt đầu, và các bước của dự

án sẽ gần như không trả lời được cho đến khi bạn bắt đầu ước tính công việc và lên lịch làm việc

5.Dự toán công việc và lên lịch làm việc

 Bước đầu tiên của việc lên lịch dự án là xem bạn sẽ làm gì và mỗi bước mất bao lâu Đây là vấn đề con gà-quả trứng kinh điển Bạn không thể dự toán được cho tới khi bạn biết chi tiết những nhiệm vụ trong công việc

Nhưng quản lý của bạn luôn luôn muốn các dự toán và lịch làm việc trước khi bạn bắt đầu thực hiện Hãy từ chối điều đó Để việc thiết kế của bạn là

ưu tiên hàng đầu một khi bạn đã có vài ý tưởng về các yêu cầu Nếu bạn chọn một phần nhỏ của các yêu cầu có ưu tiên cao, và rồi thiết kế một giải pháp cho điều đó, và bạn có thể ước lượng sự lặp lại đó Đừng lo rằng

những yêu cầu có thể thay đổi, chúng sẽ thay đổi Bạn cần biết chi tiết các đặc tính trong các nhiệm vụ trước khi bạn làm ước toán

 Đừng bao giờ tin ai nói với bạn “cái chức năng đó sẽ mất sáu tháng để

làm” Đấy là một lời dự đoán không có cơ sở và không thực tế Bạn không thể ước tính điều gì lâu đến thế Điều tốt nhất bạn có thể làm là nói “Tôi đã từng làm 1 chức năng tương tự trong sáu tháng”

 Bạn phải chia nhỏ công việc của bạn thành các nhiệm vụ với thời hạn không quá một tuần Một hay hai ngày là tốt nhất Tốt nhất là dự tính chi tiết đến đơn vị người – giờ.

 Một khi bạn đã có danh sách các công việc cần làm, bạn có thể bắt đầu ước lượng khối lượng công việc và ước lượng các thứ khác Khối lượng việc luôn cần phải nghĩ đến trước, bởi vì bạn không thể biết được một công việc sẽ tốn bao nhiêu thời gian cho đến khi bạn biết được khối lượng việc đó

 Cuối cùng, bạn nên có đúng người – những nhà phát triển, người trực tiếp phát triển ht – làm tất cả các ước tính cho dự án Các nhà quản lý không bao giờ nên làm dự toán phát triển Ngay cả người quản lý đã từng làm phát triển trong quá khứ, trừ khi đã tham gia quá sâu vào công tác phát triển thực sự, không nên làm công việc dự toán phát

triển

6.Lập lịch – thời gian biểu

Một khi bạn đã có các ước tính về các công việc và nhân lực, bạn có thể tạo thời gian biểu Đây là vài việc cần làm :

 Phân tích sự phụ thuộc lẫn nhau giữa các nhiệm vụ Sẽ có vài nhiệm vụ không thể bắt đầu nếu cái khác chưa làm xong Có thể có vài nhiệm vụ bắt đầu được khi những cái khác làm xong được một nửa Sẽ có vài nhiệm vụ có thể bắt đầu cùng một lúc

 Tìm xem chu kì nhiệm vụ của bạn là gì Ngoài 8 tiếng mỗi ngày, có bao nhiêu tiếng đội ngũ phát triển của bạn thực sự làm việc? Bạn cần nhớ đọc thư, tham gia họp, duyệt code, nghỉ ngơi, đi tắm, toàn bộ đều ăn vào thời gian Bạn không thể giả sử một nhiệm vụ một giờ sẽ xong trong một ngày Thực tế, ngoài 8 tiếng mỗi ngày, 2 hoặc 4 tiếng sẽ ngốn vào các việc khác, vậy chu kì nhiệm vụ có thể thấp như 4 tiếng một ngày Chu kì nhiệm vụ có thể dựa trên văn hóa doanh

nghiệp, vậy bạn cần tìm hiểu xem bạn có những gì trước khi bắt đầu lên lịch

 Nghỉ cuối tuần, nghỉ lễ, các ngày ốm, đào tạo, và thêm những mối nới lỏng vào khi bạn lên lịch trình Nếu người phát triển có kinh

nghiệm của bạn có công việc ở một phần quan trọng trong dự án của bạn thì bạn cần phải biết rằng vị ấy sẽ nghỉ lễ ba tuần vào tháng

năm

 Bạn không thể lên lịch cho một lập trình viên làm hai nhiệm vụ

trong cùng một lúc Hầu hết các mô hình ptpm không cho bạn làm điều này, nhưng lại cho phép ghi đè lên nó Đừng làm vậy Có thể bạn muốn làm thế để kịp thời hạn - hãy chống lại điều đó Chỉ đổi thời khóa biểu khi bạn chắc chắn sẽ lỡ hạn

Dùng phần mềm lập kế hoạch dự án ?

 Với những dự án nhỏ, có thể dùng excel

 Với nhựng dự án lớn => nên dùng Ví dụ Fast Track Scheduling, hoặc Merlin

 Ưu điểm chính mà phần mềm quản lý dự án có thể làm mà bảng tính không thể

là theo dõi phụ thuộc, biết điều gì đó về sự phụ thuộc vào dự án có thể giúp quản

lý của những người làm việc trên những gì, và khi nào

Lịch trình của Spolsky liệt kê bảy cột sau trong mỗi lịch trình:

 • Tên tính năng

 • Nhiệm vụ trong các tính năng

 • Các ưu tiên của công tác

 • Các ước tính gốc (trong người-giờ)

 • Những Ước tính hiện tại (trong người-giờ)

 • Thời gian đã làm việc trên từng nhiệm vụ (trong người-giờ)

 • Thời gian còn lại cho từng nhiệm vụ (còn trong người-giờ)

7.Giám sát dự án

 Giám sát dự án là theo dõi những gì xảy ra khi bạn đã có một lịch trình Một khi dự án của bạn bắt đầu, nhu cầu quản lý công việc sẽ nảy sinh Làm thế nào điều này xảy ra phụ thuộc vào quá trình bạn đang sử dụng Nhưng bất kể quá trình nào, bạn cần quản lý tiến độ, quản lý các nhà phát triển, quản lý

chính các quá trình , và trên tất cả, quản lý chính quản lý của bạn

 Là 1 kỹ thuật rất quan trọng của nhà quản lý để đảm bảo dự án đúng tiến độ

 Hãy đối xử với các nhà phát triển của bạn như con người, không phải tài

nguyên Hỗ trợ nhóm của bạn và giữ cho nhóm cách ly khỏi phiền nhiễu là

ưu tiên số một !

 Chỉ cung cấp tin tức tốt là thường có hại cho uy tín của bạn; một cái gì đó sẽ đi sai tại một số điểm, do đó, sẽ là tốt nhất nếu thoát ra khỏi chúng ngay Bạn phải truyền đạt tin xấu về dự án ngay khi có thể Đó là cách tốt nhất để giảm thiểu các vấn đề và nhận được sự hỗ trợ để tìm ra giải pháp

Các lỗi

 Chắc chắn, bạn sẽ đưa các lỗi vào chương trình của bạn Lỗi không

tự xuất hiện; nhà phát triển đặt chúng ở đó Là một nhà phát triển, mục tiêu của bạn là :

 Đưa càng ít lỗi càng tốt vào mã bạn viết.

 Loại bỏ càng nhiều lỗi càng tốt trước khi phát hành mã.

 Bug là không thể tránh khỏi

Mục tiêu của bạn là phát hành với ít lỗi nhất có thể và làm cho những lỗi đó không thực sự ảnh hưởng đến sản phẩm hoặc hiệu quả của nó

Các loại lỗi

1. Fatal: Sản phẩm bị lỗi, hoặc một phần nền tảng của chức năng không hoạt

động

2. Sereval: Một mảnh chính của chức năng không hoạt động, và khách hàng

cũng không có cách nào để thực hiện

3. Serious: Một mảnh chức năng không hoạt động, nhưng có một cách giải quyết

cho nó mà khách hàng có thể thực hiện

4. Annoying: Một khiếm khuyết nhỏ hoặc lỗi trong tài liệu mà có thể làm phiền

người sử dụng, nhưng không ảnh hưởng đến cách các chương trình hoạt động

5. New Feature Request: Đây không phải là một khiếm khuyết, nhưng có yêu

cầu mới đối với các sản phẩm

9.Sự mổ xẻ

Hầu hết các đội phát triển sẽ làm một “khám nghiệm tử thi” sau mỗi dự án Mổ xẻ là cơ hội để phản ánh về dự án mới hoàn thành và trả lời một số câu hỏi, như:

 Cái gì đã đúng? Lịch trình của dự án đã làm việc theo cách chúng ta mong đợi? Dự

án đã thực hiện tất cả các tính năng cần thiết cho khách hàng?

 Điều gì đã xảy ra? Tại sao dự án có rất nhiều lỗi? Tại sao chúng ta cần phải làm việc tuần 60 giờ cho những tháng cuối cùng của dự án?

 Những vấn đề nào đã phát sinh trong suốt quá trình? Những phần nào đã có vấn đề?

 Những gì chúng ta cần phải sửa chữa trong thời gian tới? Những gì chúng ta cần làm

để khắc phục quá trình làm việc của dự án, thói quen làm việc, hoặc môi trường cho các dự án tiếp theo?

 Ai chịu trách nhiệm đối với các bản sửa lỗi? Ai đó phải chịu trách nhiệm về những thay đổi tiến trình của dự án; đó là ai? (Đừng dành nó cho người quản lý; các nhóm phát triển nên làm chủ tiến trình này.)