Chương trình Tô mỳ Minh duy

Giải quyết hiệu quả vấn đề trong những mối quan hệ

Lập trình cực độ — Truyện hệ

Lập
trình cực độ & Truyện hệ

Chu
trình Yêu sách Kỹ thuật – Hồi 2

Đọc
tại Nguồn

Hồi
1
có nói: Nếu không
biết cách viết truyện hệ của phương pháp lập trình cực độ thì bạn cũng chưa làm
việc theo kiểu VietnamQA được.
Nhân viên và cộng sự nhóm
Xây Web Việt
ai cũng phải biết cách làm việc theo kiểu VietnamQA: dùng
đại việt ngữ viết truyện hệ làm việc theo phương pháp lập trình cực độ, như
được giải thích tận tượng dưới đây.

Lập
trình cực độ, viết tắt là LTCĐ hoặc XP cho cụm từ
extreme programming
, là một phương thức công nghệ phần mềm, một phương
thức nổi bật nhất trong số vài phương thức phát triển phần mềm lanh lợi. Làm
như những phương thức lanh lợi khác, lập trình cực độ khác với các phương thức
truyền thống trước hết qua việc đặt cao giá trị khả năng thích ứng hơn là khả
năng dự đoán. Giới biện hộ LTCĐ coi các thay đổi yêu sách luôn diễn ra như là
một khía cạnh tự nhiên, không tránh được và đáng khát khao của những dự án phát
triển phần mềm. Họ tin rằng hiện là khả năng thích ứng tới việc cần thay đổi
những yêu sách ở bất cứ thời điểm nào trong đời sống dự án là một phương sách
thực tế hơn và tốt hơn là việc toan định nghĩa tất cả những đòi hỏi trước khi
khởi đầu một dự án và rồi lại phải tiêu dùng công sức điều khiển các thay đổi
cho những đòi hỏi đó.

LTCĐ
kê đơn một bộ thông lệ thường ngày cho các quản lý gia và các nhà phát triển.
Những thông lệ đó là để hiện thân và khuyến khích các giá trị đặc thù. Giới
biện hộ tin rằng việc dùng những thông lệ này, tức là những thông lệ truyền
thống của công nghệ phần mềm nhưng lại được đưa lên tới mức “cực độ”, sẽ dẫn
một quá trình phát triển tới tình trạng sẵn sàng đáp ứng nhu cầu khách hàng
(“lanh lợi”) nhiều hơn là các phương pháp truyền thống trong cùng một lúc tạo
được phần mềm có chất lượng tốt hơn.

Nói
một cách ngắn gọn, LTCĐ là một bộ các giá trị, nguyên lý và thông lệ dùng để
phát triển hoặc khuếch trương tuyệt nhanh phần mềm có chất lượng cao nhằm chu
cấp giá trị cao nhất cho khách hàng bằng con đường ngắn nhất. Sự cực độ trong
LTCĐ có nghĩa là lấy 12 “thông lệ tốt nhất”, xem
Hoàng Thanh
, trong các phương sách phát triển phần mềm lừng danh rồi
cùng một lúc thực hiện một cách tột đỉnh từng thông lệ một.

Như
có nói trong bài viết,
Triết Lý Lập Trình Cực Độ
, vừa là một triết lý vừa là một phương thức,
LTCĐ gồm có bốn đức hạnh, những giá trị mà được diễn đạt trong 12 thông lệ phát
triển phần mềm. Bất cứ đội ngũ nào cũng sẽ làm việc như một đơn vị cố kết hơn
nếu các đội viên chia sẻ cùng một số các giá trị. Phần lớn các đội chọn để cho
các giá trị của họ mặc định, nhưng LTCĐ làm ra cho các giá trị tự phê chuẩn qua
giấy tờ. Bốn giá trị chung để tất cả các đội LTCĐ là: thông tri, hồi tiếp, đơn
giản và can đảm.


  • Thông tri:
    Thông tri tốt
    quan trọng trong mỗi dự án, và phần lớn các hiệp thất bại dự án có thể truy
    nguyên đến thông tri nghèo hoặc non, tức là không hợp thời. LTCĐ nỗ lực giữ
    dòng thông tri trôi chảy bằng cách thiết lập các thông lệ đòi hỏi thông tri.

    Hoàng
    Thanh:
    XP chú trọng việc trao đổi thông tin một cách ‘trong suốt’ giữa
    các thành viên trong nhóm phát triển. Đề cao việc trao đổi trực tiếp, giảm việc
    trao đổi gián tiếp hay hinh thức thông qua các văn bản.


  • Hồi tiếp:
    Các đội LTCĐ cũng
    thiết lập thông lệ cho hồi tiếp là lệ thường. Hồi tiếp bao trùm cái độ chính
    xác của kế hoạch, hệ chức năng của cái hệ thống, và chất lượng của cả thiết kế
    lẫn mã nguồn. Hồi tiếp thường lệ cho phép một đội LTCĐ lèo lái dự án đi tới kết
    luận hiệu quả.

    Hoàng
    Thanh:
    Phản hồi sớm và liên tục từ khách hàng cũng như từ nhóm phát
    triển giúp cho dự án luôn đi theo đúng hướng. XP đều đặn giao sản phẩm cho
    khách hàng để kiểm tra, theo đó khách hàng có thể ‘làm mịn’ và hoàn thiện yêu
    cầu sản phẩm dựa trên các kết quả cụ thể. Với sự trợ giúp của khách hàng, XP
    xây dựng một tập các phép thử phụ vụ cho việc kiểm định (acceptation test) một
    cách liên tục trong suốt quá trình phát triển phần mềm.


  • Đơn giản:
    LTCĐ yêu cầu
    chúng ta nhìn vào cái đơn giản nhất mà có thể làm được việc, và phải kháng cự
    sự quyến rũ của sự tổng quát hoá hấp tấp. Các đội LTCĐ tin rằng mà thông tri
    tốt và hồi tiếp tốt sẽ cho họ biết khi nào và nơi nào các giải quyết đơn giản
    của họ cần phải trở nên tinh vi hơn.

    Hoàng
    Thanh:
    XP đảm bảo chỉ phát triển những chức năng mà khách hàng yêu cầu.
    Phần thiết kế và mã nguồn được thiết lập một cách đơn giản nhất, cho phép có
    được đặc tính ‘mở’ cao nhằm đáp ứng với các thay đổi liên tục và luôn duy trì
    được một tốc độ phát triển nhanh trong suốt quá trình phát triển phần mềm.


  • Dũng cảm:
    Trong một dự án
    LTCĐ, các đội viên đều được động viên để chỉ có làm mấy cái mà đem thêm giá trị
    đến với khách hàng, và chỉ làm những việc đó càng nhanh càng tốt. Nếu không có
    thông tri và hồi tiếp tốt thì nó chỉ là việc làm đốn đẽo mà thôi. Nếu không có
    một hệ thống khả thi đơn giản nhất thì nó chỉ là việc làm điên rồ. Nhưng trong
    văn cảnh có các giá trị khác, sự can đảm cho đội ngũ tối đa hoá cái giá trị của
    hệ thống chót.

    Hoàng
    Thanh:
    XP cho rằng phải có lòng dũng cảm thì mỗi thành viên mới thực
    hiện được các nguyên tắc kể trên. Tuy XP không chỉ ra một cách rõ ràng, nhưng
    cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng để thực hiện có
    hiệu quả phương pháp phát triển phần mềm XP.

Truyện
hệ là gì?

Văn
kiện nhỏ nhất trong LTCĐ gọi là truyện hệ. Không ai nhấn mạnh đầy đủ được tầm
quan trọng của truyện hệ trong quá trình LTCĐ.

Một
truyện hệ là một yêu sách hệ thống phần mềm có công thức ra một hoặc hai câu
văn dùng ngôn ngữ thường ngày của người dùng. Các truyện hệ cùng với những bài
cuộc trắc nghiệm chấp thuận chính là đặc tả của những yêu sách trong phương
pháp lập trình cực độ. Mỗi truyện hệ thường được viết thành văn bản trên một
thiếp giấy nhỏ để đảm bảo rằng nó sẽ không trở nên quá dài. Khách hàng nên là
những người viết truyện hệ đó cho dự án và đó là phương tiện chính cho họ ảnh
hưởng trực tiếp sự phát triển phần mềm.

Các
truyện hệ là một cách xử lý yêu sách khách hàng nhanh mà không cần phải lo về
một tài liệu yêu sách chính thức to lớn và các công tác chán ngắt liên quan đến
việc vẫn phải tiếp tục duy trì tài liệu đó. Chủ ý là để có khả năng hưởng ứng
nhanh hơn và với tốn ít tổng phí hơn tới những đòi hỏi ngoài đời thay đổi nhanh
xiết.

Một
truyện hệ là một lời tuyên bố thân mật của yêu sách. Khi một truyện hệ cần phải
được thực hiện đầy đủ, khách hàng nên viết một văn bản định nghĩa cuộc trắc
nghiệm chấp thuận để đảm bảo rằng sau này ai cũng có thể xác định xem những mục
tiểu của truyện hệ đó đã được thực hiện y theo nguyện vọng khách hàng.

Các
truyện hệ (user stories) phục vụ cùng một chủ tâm như các cảnh hệ (use cases)
nhưng không cùng là một thứ. Không cần phải nói về cảnh hệ nhưng nó là một cách
cho thấy đặc điểm hệ thống bằng cách trình diễn một phần của hệ chức năng. Mỗi
cảnh hệ thành lập một tiến trình hoàn tất hành động do một diễn viên khởi
xướng, và nó định rõ tương tác giữa diễn viên và hệ thống. Toàn bộ các cảnh hệ
định rõ tất cả các cách dùng sẳn có của cái hệ thống.

Trở
về truyện hệ, chúng ta dùng một truyện hệ để tạo ước lượng thời gian cho cuộc
họp ra kế hoạch phóng thích sản phẩm nào đó. Chúng ta dùng truyện hệ thay vì
một yêu sách to lớn chứa đầy những lời đòi hỏi phức tạp. Các truyện hệ là do
các khách hàng viết ra thành văn bản cho biết cái hệ thống cần phải làm gì cho
họ. Các truyện hệ có những điểm tương tự như các diễn xuất sử dụng (user
scenarios), ngoại trừ rằng chúng không bị giới hạn chỉ diễn tả một giao diện
người dùng nào đó mà thôi. Chúng nằm trong khuôn khổ có hai ba câu văn do khách
hàng tự viết dùng thuật ngữ hệ của khách hàng và không có cú pháp kỹ thuật.

Các
truyện hệ cũng thúc đẩy việc tạo các cuộc trắc nghiệm chấp thuận. Phải có một
hoặc nhiều cuộc trắc nghiệm chấp thuận tự động để kiểm lại cho thấy truyện hệ
đã được thực hiện đầy đủ và đúng tiêu chuẩn.

Một
trong những nỗi hiểu lầm lớn nhất với các truyện hệ là cách chúng khác với các
văn kiện yêu sách truyền thống. Sự khác biệt lớn nhất là ở cái mức độ chi tiết.
Các truyện hệ chu cấp chỉ đủ chi tiết để đem nguy cơ xuống mức độ thấp phải
chăng khi ước lượng cần phải có bao lầu để thực hiện đầy đủ câu truyện đó. Khi
tới lúc thực hiện câu truyện các nhà phát triển truyện hệ sẽ đi tới đối diện
với khách hàng nhận thêm chi tiết diện mạo của những đòi trong truyện hệ.

Các
nhà phát triển ước lượng cần bao lâu để thực hiện đầy đủ các truyện hệ. Từng
truyện một sẽ được ước lượng bằng thời gian phát triển lý tưởng: 1, 2 hoặc 3
tuần. Thời gian phát triển lý tưởng này là số giờ cần phải có để mã hoá đầy đủ
truyện hệ nếu không bị làm lãng trí, không có các việc giao phó khác, và bạn đã
biết xác đáng cần phải làm gì. Lâu hơn hơn là 3 tuần có nghĩa là bạn cần phải
tách truyện đó ra thành nhiều truyện nhỏ hơn. Ít hơn một tuần thì bạn ở một mức
độ quá đầy chi tiết, nên phối hợp với vài truyện khác. Độ chừng 80 truyện hệ
cộng hoặc trừ 20 là một con số hoàn hảo để ra tạo một kế hoạch phóng thích
trong thời kỳ đặt kế hoạch phóng thích.

Một
sự khác biệt khác giữa các truyện hệ và một văn kiện yêu sách là tiêu điểm trên
các điều thiết cần của người dùng. Bạn nên cố để tránh các chi tiết của công
nghệ đặc điểm, cách dàn trận cơ sở dữ liệu, và các thuật toán. Bạn nên cố giữ
các truyện hệ hội tụ vào các điều thiết cần của và các phúc lợi cho người dùng,
trái ngược với việc định rõ cách dàn trận giao diện minh hoạ (GUI).

Cách
soạn thảo Truyện hệ

Một
truyện hệ tốt phải (a) chú tâm vào khách hàng, (b) bằng 100% tiếng Việt ngắn
gọn dễ cho cha mẹ mình hiểu trong 60 giây hoặc dùng
Đại Việt Ngữ
, (c) không có quá lớn mà cũng không có quá nhỏ, và (d)
kiểm duyệt lại được.

Nội
dung truyện hệ không nên có dấu ngoặc nào cả, làm khó hiểu hơn. Nếu tác giả
truyện hệ cảm thấy cần phải giải thích thêm cho người khác hiểu thì nội dung
truyện hệ quá phức tạp và không
dễ cho cha mẹ mình hiểu trong 60 giây
.

Trong
một cuộc chat, khi nào đề nghị nội dung mới cho bất kỳ một truyện hệ nào thì
cũng phải đánh số độc đáo nhận diện nội dung đó nhằm làm dễ việc tham khảo. Ví
dụ: th1a, th2b, th3c, v. v. Trong cùng một cuộc chat, không bao giờ sử dụng bất
cứ một số nhận diện nào lần thứ hai cho nội dung mới.

Không
bao giờ làm truyện hệ con trước khi nắm bắt được lời phê chuẩn của khách hàng
về truyện hệ cha. Bằng không thì, nếu khách hàng không đồng ý với nội dung
truyện hệ cha thì các truyện hệ con có thể trở thành việc mất công.

Hội Tụ Vào Khách Hàng

Làm
cho truyện hệ hội tụ, chú tâm vào khách hàng. Cách dễ nhất để làm việc này là
để cho khách hàng phát sinh truyện hệ. Nếu họ không thực hiện được thì bạn phải
chơi trò đóng vai khách hàng. Một thí dụ truyện hệ hội tụ vào nhà phát triển
là: xây thêm chức năng mới,
bản mục lục loại tụm lại, vào cái bảng liệt kê các đơn đặt hàng
. Truyện
hệ như thế không có nghĩa lý gì nhiều đối với đại đa số các khách hàng, và một
khách hàng thực sự (trừ phi họ là một nhà quản trị cơ sở dữ liệu), chắc không
bao giờ viết một truyện hệ như vậy. Thay vì vậy, truyện hệ có nội dung như là,
cải tiến sức năng phát sinh tường trình đơn mua
, diễn đạt được cùng một
thông tin, nhưng lại dễ hiểu cho mọi người trong đội ngũ.

Thân Thiện Cho Thang Máy

Một
truyện hệ tốt nên là cái gì đó bạn có thể trên một cái thang máy trong vòng độ
chừng 30 giây giải thích cho một đội viên khác hiểu, xem
Nghệ Thuật Rao Thang Máy (Elevator Pitch)
. Đừng có viết tiểu thuyết.
Nên nhớ, cái này chỉ là một cái giữ chỗ cho các đàm luận đầy chi tiết hơn,
không phải là văn kiện định nghĩa hết những đòi hỏi hoặc các đặc điểm kỹ thuật.

Kích Thước Cho Phải Chăng

Không
có quá lớn mà cũng không có quá nhỏ, có thể thực hiện được trong vòng 40 giờ lý
tưởng (1 tuần lý tưởng) khi ước lượng dụng công. Các truyện nhỏ thường không là
một vấn đề, nhưng nếu chúng nhỏ hơn một giờ bạn chắc muốn gom chúng lại thành
một loạt. Các sai sót thường là các tuyển viên tốt để cho hàng loạt vào một
truyện hệ đơn độc, miễn sao toàn bộ vẫn là nhỏ và dễ thực hiện đầy đủ.

Phải Kiểm Duyệt Lại Được

Một
truyện hệ không thử được có lẽ như là,
làm cho cái khung có đơn mua dễ dùng
. Nghe có vẻ xinh đẹp, nhưng không
một ai thực ra biết cái đó có nghĩa là gì, hoặc làm sao để kiểm lại nó một cách
khách quan. Một cách diễn đạt tốt hơn có lẽ là như vầy:
một người dùng mới tập việc có khả năng triệu hồi thông tin, cho dữ liệu vào,
và đệ trình một cái đơn mua không quá 5 phút
. À mà nó vẫn còn tỏ ra một
chút đáng ngờ, nhưng mình chắc có thể viết một bài định nghĩa cuộc thử nghiệm
chức năng đó như thế này: căn
cứ vào một nhóm mẫu có 10 người thì hết 8 nên có khả năng hoàn tất một đơn mua
một cuốn sách trong vòng 5 phút.

Trước
khi Giao tiếp thêm

Thiếu
chuyên nghiệp nhất là giao tiếp khách hàng trước khi tiêu hoá toàn bộ tất cả
các thông tin sẳn có nhờ khách hàng đã đưa cho từ trước rồi. Có thể thông tin
sẳn có chỉ có 5 lời viết và hình ảnh. Không nên coi thường uy lực các đồ hoạ.
Một bức minh hoạ có thể gợi ý cho ta viết ra thêm được 10, 20 truyện hệ khác
nhau dù có nhiều cái chưa hoàn tất được trước khi giao tiếp thêm với khách
hàng.

Trước
khi giao tiếp khách hàng nên gom góp lại tất cả các ý kiến sẳn có từ những lời
viết cũng như các hình ảnh đã nhận được từ khách hàng rồi cho hết vào một văn
kiện định nghĩa yêu sách hệ thống mong muốn, tức là ra một bài viết có danh
sách liệt kê bộ truyện hệ tối thiểu dùng để diễn đạt toàn diện hệ thống khách
hàng muốn chúng ta thực hiện cho họ. Trước khi giao tiếp khách hàng qua điện
thoại hoặc chat nên cho khách hàng có cơ hội điền thêm vào văn kiện những gì
chúng ta chưa thể nghĩ ra thêm cho họ được.

Nếu
đại diện kinh doanh không có thời gian hoặc không thể viết ra hoàn chỉnh một
truyện hệ dựa trên một món thực đơn nào đó trên minh hoạ sẳn có thì nên gợi ý
cho khách hàng thấy truyện hệ cần phải làm. Ví dụ, viết dở một truyện hệ như
sau:

TH123b.
Khi nhấp chuột vào món ABC trên thực đơn đầu trang web XYZ thì cho người dùng
chọn một trong những chức năng sau: (a) làm việc này, (b) làm việc kia, (c) đi
đâu khác, v. v.

Chuẩn
bị thêm một số truyện hệ mới trước khi tiếp tục giao tiếp với khách hàng là một
trong những cách tốt nhất nhằm thể hiện sự chuyên nghiệp của một tổ chức chuyên
xây và cải tiến các hệ thông tin cho khách hàng.

Dùng
Đại Việt Ngữ

Đại
Việt Ngữ
là ngôn ngữ tiếng Việt tiêu chuẩn dùng để thể hiện hoàn chỉnh
nhiều khái niệm tinh vi một cách dễ hiểu cho ngay cả học sinh tiểu học chưa
biết ngoại ngữ. Đây là ba mục ví dụ trong
từ điển Anh ngữ – Đại Việt Ngữ (ĐVN)
trên web ta: chất lát (silicon),
chất ống than phần tỉ (carbon nanotube), và chất huyết điệu (serotonin). Nếu
chưa có trong từ điển ĐVN thì không nên dùng trong truyện hệ.


Không Nên

Nên Dùng

Lý Do
định
nghĩa
không
nên sử dụng tiếng Việt ngoài từ điển phổ thông
không
phải Việt ngữ
sai
chính tả, sai văn phạm
phải
có chính tả, văn phạm tốt
thiếu
chuyên nghiệp
kích
vào
nhấp
vào
dễ
hiểu hơn
menu thực
đơn
tránh
ngoại ngữ
các
nút trên thanh nằm ngang
các
món trên Thực Đơn Đầu Trang
chuẩn
xác hơn
bạn
hoặc tôi
(nói
trổng)
thừa
lưu
ý hoặc dùng ngoặc đơn
nếu
không quan trọng, không nói; nếu nói, nói nguyên câu một cách chính qui
lưu
ý và ngoặc đơn làm khó hiểu hơn

Kế
Hoạch Chu Lặp

Một
chu lặp có thể coi như là một loại quy trình công tác. Các chu lặp
(iterations) trong văn cảnh một dự án nói về cái kỹ xảo của việc khuếch trương
và giao hàng một cách gia tăng các thành phần cho hệ chức năng doanh nghiệp.
Điều này hầu hết thường hay liên quan với sự phát triển phần mềm theo phong
cách lanh lợi, nhưng có thể tiềm tàng áp dụng được vào bất cứ vật liệu nào
khác. Các thành quả của một chu lặp đơn độc có thể là các gói hàng nhỏ nhưng
hoàn tất của việc làm dự án mà có thể cùng nhau trình diễn vài chức năng doanh
nghiệp hữu hình. Thực hiện nhiều chu lặp để tạo lập một sản phẩm tích hợp có
đầy đủ tất cả các chức năng mong đợi. Cách này thường hay được so sánh với
phương sách mô hình thác nước.

Nên
gọi một cuộc hội họp nhằm ra kế hoạch chu lặp vào lúc ban đầu của từng chu lặp
để ra kế hoạch cho các công việc lập trình trong chu lặp đó. Mỗi chu lặp dài từ
một đến 3 tuần.
Các truyện hệ
đã được khách hàng tuyển chọn cho chu lặp này từ cái kế
hoạch phóng thích trong thứ tự truyện quý giá nhất đối với khách hàng nằm trước
hết. Các cuộc trắc nghiệm chấp thuận bị hỏn cần phải được sửa chữa cũng được
tuyển. Khách hàng lựa
các truyện hệ
với ước lượng tổng số lên đến vận tốc dự án từ chu lặp
vừa rồi.

Các
truyện hệ
và các cuộc trắc nghiệm đã hỏn được tách ra thành các công
việc lập trình mà sẽ ủng hộ chúng. Các công việc được viết xuống thành văn bản
vào mấy tấm thiếp như là
các truyện hệ
. Trong lúc các truyện hệ dùng ngôn ngữ khách hàng, các
công việc viết bằng ngôn ngữ của nhà phát triển. Các công việc giống hệt nhau
phải dẹp qua. Những tấm thiếp này sẽ là kế hoạch chi tiết cho chu lặp đó.

Các
nhà phát triển tự nhận làm các công việc và khi đó ước lượng bao lâu họ sẽ hoàn
tất các công việc mình. Điều quan trọng là nhà phát triển chấp nhận một việc
cũng là người ước lượng bao lâu nó sẽ kết thúc. Không hoán đổi con người được
và người mà sẽ làm việc phải ước lượng công việc sẽ tốn bao lâu.

Mỗi
việc nên ước lượng dài 1, 2, hoặc 3 ngày lập trình lý tưởng trong thời kỳ đó.
Những ngày lập trình lý tưởng là thời gian cần phải có để hoàn tất công việc
nếu không bị làm lãng trí. Các công việc ngắn hơn 1 ngày có thể nhập lại thành
một nhóm với nhau. Các công việc lâu hơn 3 ngày nên tách ra nhỏ hơn nữa.

Bây
giờ vận tốc dự án được dùng để xác định nếu chu lặp thiếu giờ cho các việc
tuyển hay không. Tổng cộng thời gian ước lượng bằng số ngày lập trình lý tưởng
của các công việc, kết quả này phải không có trội hơn vận tốc dự án từ chu lặp
trước đó. Nếu chu lặp này có quá nhiều việc rồi thì khách hàng phải chọn các
truyện hệ cần phải đợi đến một chu lặp sau (xúc tuyết).

Nếu
chu lặp có quá ít truyện thì cho thêm truyện khác vào. Vận tốc ngày việc (kế
hoạch chu lặp) quan trọng hơn vận tốc trong tuần truyện (kế hoạch phóng thích)
vì nó đúng đắn hơn.

Người
ta thường hay báo động khi thấy các truyện hệ bị xúc tuyết. Đừng có hốt hoảng.
Nên nhớ điều quan trọng của việc trắc nghiệm đơn vị và tái hệ số (refactoring).
Một món nợ trong những khu vực này sẽ làm chậm việc. Tránh cho thêm vào bất cứ
hệ chức năng nào trước khi có thời biểu. Chỉ cho vào cái gì mà bạn cần cho hôm
nay mà thôi. Đem gì ngoại đạo vào sẽ làm chậm việc.

Đừng
bị cám dỗ vào thay đổi ước lượng việc và truyện mình. Quá trình ra kế hoạch dựa
vào thực tại lạnh lùng của ước lượng kiên định, làm giả dối để cho thấy thấp
hơn một chút tạo nhiều vấn đề hơn.

Giữ
một con mắt trên vận tốc dự án và việc xúc tuyết. Có thể cần phải tái ước lượng
tất cả cái các truyện và tái đàm phán kế hoạch phóng thích mỗi ba đến năm chu
lặp, là việc bình thường. Miễn sao luôn trước hết thực hiện đầy đủ các truyện
hệ quý giá nhất thì sẽ luôn làm càng nhiều càng tốt các việc khả thi cho đám
khách hàng và ban quản lý của mình.

Một
phong cách phát triển theo chu lặp có thể đem sự lanh lợi vào quá trinh phát
triển của mình. Chỉ cần ra kế hoạch kịp thời bằng cách không ra kế hoạch các
công việc lập trình đặc biệt sớm hơn dự liệu của chu lặp đương thời.

Chương
Trình Tô Mỳ Minh Duy

Nguồn

Thanh
toán lệ phí bản quyền trước khi đăng lại

Advertisements

About cttmmd

creator of www.tapsu.com

2 comments on “Lập trình cực độ — Truyện hệ

  1. Pingback: Cham tran voi Lap trinh Cuc do - Hiep 1 « Tô Mỳ Minh Duy (CTTMMD)

  2. Pingback: TH10302 Chọn lọc Song ngữ Anh Việt « Tô Mỳ Minh Duy (CTTMMD)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on 03-03-2007 by in CNTT, Dịch thuật, Làm Web, Lập trình, QA, Sự Nghiệp, Việc làm, Việt Ngữ, Văn hoá.
%d bloggers like this: