Khung thời gian

Một phần của loạt bài về
Phát triển phần mềm
Hoạt động cốt lõi Mô hình hóa dữ liệu Quy trình Yêu cầu Thiết kế Xây dựng Công nghệ Thử nghiệm Gỡ lỗi Triển khai Bảo trì
Mô hình và hình mẫu Linh hoạt Phòng sạch Tăng dần Nguyên mẫu Xoắn ốc Mô hình V Thác nước
Phương pháp và framework ASD DevOps DAD DSDM FDD IID Kanban Lean SD LeSS MDD MSF PSP RAD RUP SAFe Scrum SEMAT TDD TSP OpenUP UP XP
Các ngành hỗ trợ Quản lý cấu hình Tài liệu Đảm bảo chất lượng phần mềm Quản lý dự án Trải nghiệm người dùng
Thực hành ATDD BDD CCO CI CD DDD PP SBE Đứng TDD
Công cụ Trình biên dịch Trình gỡ lỗi Hồ sơ Trình thết kế GUI Mô hình hóa UML IDE Tự động hóa xây dựng Tự động hóa phát hành Cơ sở hạ tầng dưới dạng mã
Tiêu chuẩn và khối kiến thức CMMI Tiêu chuẩn IEEE ISO 9001 Tiêu chuẩn ISO/IEC PMBOK SWEBOK ITIL IREB OMG
Bảng thuật ngữ Trí tuệ nhân tạo Khoa học máy tính Kỹ thuật điện và điện tử
Sơ lược Sơ lược về phát triển phần mềm
x t s

Trong quản lý thời gian, lên khung thời gian nghĩa là phân bổ khoảng thời gian cố định gọi là khung thời gian, cho mỗi hoạt động được lên kế hoạch. Một số phương pháp quản lý dự án sử dụng khung thời gian. Nó cũng có thể được sử dụng để giải quyết các nhiệm vụ cá nhân trong một khung thời gian nhỏ hơn. Nó thường liên quan đến việc phân phối và thời hạn, điều này sẽ cải thiện năng suất của người dùng.

“	Lên khung thời gian — Không phải là lên khung phạm vi.<nowiki>	”
—Mary Poppendieck, Leading Lean Software Development[1]

Trong quản lý dự án

Lên khung thời gian được sử dụng như một kỹ thuật lập kế hoạch dự án. Lịch trình được chia thành một số khoảng thời gian riêng biệt (khung thời gian), với mỗi phần có phân phối, thời hạn và ngân sách riêng.

Thay thế cho phạm vi cố định

Trong quản lý dự án, ba ràng buộc là thời gian (đôi khi được lên lịch), chi phí (đôi khi là ngân sách) và phạm vi (đôi khi là hiệu suất).^[2][3][4] Chất lượng thường được thêm vào,^[5][6] đôi khi thay thế cho chi phí.^[7] Thay đổi một ràng buộc có thể sẽ ảnh hưởng đến phần còn lại.^[8]

Nếu không có khung thời gian, các dự án thường hoạt động với một phạm vi cố định, như khi rõ ràng là một số phân phối không thể hoàn thành, hoặc thời hạn (để cho phép nhiều thời gian hơn) hoặc nhiều người hơn tham gia (để làm nhiều hơn trong cùng một thời điểm). Thông thường cả hai xảy ra, giao hàng bị muộn, chi phí tăng lên, và thường chất lượng bị thiệt hại (theo nguyên tắc Mythical Man-Month).

Với việc lên khung thời gian, thời hạn đã được cố định, nhưng phạm vi có thể bị giảm. Điều này tập trung vào các phân phối quan trọng nhất. Vì lý do này, việc lên khung thời gian phụ thuộc vào mức độ ưu tiên (ví dụ như phương pháp MoSCoW) của các phân phối, để đảm bảo rằng đó là các bên liên quan của dự án xác định các phân phối quan trọng thay vì các nhà phát triển phần mềm.

Để quản lý rủi ro

Khung thời gian được sử dụng như một hình thức quản lý rủi ro, để xác định rõ ràng các mối quan hệ công việc / thời gian không chắc chắn, tức là, công việc có thể dễ dàng mở rộng qua thời hạn của nó. Các ràng buộc về thời gian thường là một trình điều khiển chính trong việc lập kế hoạch và không nên thay đổi mà không xem xét các đường dẫn quan trọng của dự án hoặc tiểu dự án. Đó là, nó thường quan trọng để đáp ứng thời hạn. Các yếu tố rủi ro cho thời hạn bị trễ có thể bao gồm các biến chứng ngược chiều của dự án, lập kế hoạch sai sót trong dự án, các vấn đề liên quan đến nhóm, hoặc thực hiện sai kế hoạch. Các vấn đề ngược chiều có thể bao gồm các thay đổi trong nhiệm vụ dự án hoặc hỗ trợ / hỗ trợ từ quản lý. Lỗi lập kế hoạch phổ biến là phân tích tác vụ không đầy đủ, điều này có thể dẫn đến đánh giá thấp thời gian cần thiết để thực hiện công việc. Các vấn đề liên quan đến nhóm có thể bao gồm sự cố với thông tin liên lạc giữa các nhóm; thiếu kinh nghiệm hoặc yêu cầu chức năng chéo; thiếu cam kết / động lực / động lực (nghĩa là xây dựng và quản lý nhóm tồi).

Để duy trì thời hạn, các hành động sau đối với ba ràng buộc thường được đánh giá:

• Giảm phạm vi: yêu cầu giảm tác động thấp hơn (những yêu cầu sẽ không bị người dùng bỏ qua trực tiếp)
• Thời gian là ràng buộc cố định ở đây
• Tăng chi phí: ví dụ: thêm giờ làm thêm hoặc tài nguyên

Ứng dụng trong phát triển phần mềm

Nhiều dự án phát triển phần mềm thành công sử dụng khung thời gian, đặc biệt là các dự án nhỏ hơn.^[9] Áp dụng khung thời gian giúp tăng năng suất gấp ba lần của nhà phát triển tại DuPont trong những năm 80. Trong một số trường hợp, các ứng dụng đã được phân phối hoàn toàn trong thời gian được ước tính để hoàn thành chỉ một đặc điểm kỹ thuật. Tuy nhiên, Steve McConnell lập luận rằng không phải mọi sản phẩm đều phù hợp và việc chấm công chỉ nên được sử dụng sau khi khách hàng đồng ý cắt các tính năng, chứ không phải chất lượng. Có rất ít bằng chứng cho việc áp dụng mạnh mẽ giữa các loại dự án lớn nhất.

Lên khung thời gian đã được chấp nhận bởi một số phương pháp phát triển phần mềm đáng chú ý:

• Phương pháp phát triển hệ thống động (DSDM)
• Trongphát triển phần mềm tinh gọn, lập kế hoạch thực hiện với Kanban cho phép quản lý thời gian ngắn hạn. Khi phát triển một hệ thống lớn và phức tạp, khi hoạch định dài hạn được yêu cầu, sự phân đoạn thời gian được phân lớp ở trên.^[10]
• Quy trình phát triển phần mềm phát triển ứng dụng nhanh (RAD) có tính năng phát triển lặp lại và tạo mẫu phần mềm. Theo Steve McConnell, quá trình lên khung thời gian là một "Thực hành tốt nhất" cho RAD và độ dài khung thời gian điển hình phải là 60–120 ngày.^[11]
• Scrum bị ảnh hưởng bởi những ý tưởng về thời gian và sự phát triển lặp lại.^[12] Các đơn vị thời gian thường được gọi là sprints tạo thành đơn vị phát triển cơ bản.^[13] Độ dài điển hình của chạy nước rút là 30 ngày.^[14] Lập kế hoạch nước rút, hồi tưởng về nước rút và các cuộc họp đánh giá chạy nước rút đã được định thời gian.^[15]
• Trong các phương pháp lập trình cực hạn, lập kế hoạch phát triển được định thời gian thành các lần lặp thường là 1, 2 hoặc 3 tuần. Doanh nghiệp đánh giá lại các câu chuyện của người dùng đang chờ xử lý trước mỗi lần lặp lại.^[6]

Những người ủng hộ phát triển phần mềm linh hoạt chuyển từ hướng kế hoạch đến phát triển định hướng giá trị. Chất lượng và thời gian được cố định nhưng linh hoạt trong phạm vi cho phép. Việc cung cấp các tính năng quan trọng nhất trước tiên dẫn đến lợi tức đầu tư sớm hơn mô hình thác nước.

Thiếu thông số kỹ thuật chi tiết thường là kết quả của việc thiếu thời gian hoặc thiếu kiến thức về kết quả cuối cùng mong muốn (giải pháp). Trong nhiều loại dự án, và đặc biệt là trong kỹ nghệ phần mềm, phân tích và xác định tất cả các yêu cầu và thông số kỹ thuật trước khi bắt đầu giai đoạn thực hiện là không thể. Lên khung thời gian có thể là một loại hợp đồng thuận lợi cho các dự án trong đó thời hạn là khía cạnh quan trọng nhất và khi không phải tất cả các yêu cầu đều được xác định hoàn toàn trước.

Đây cũng là một cấu trúc tốt hơn để cho phép những hiểu biết mới được phát triển trong suốt dự án được phản ánh trong kết quả cuối cùng.

Trong quản lý thời gian cá nhân

Cá nhân cũng có thể sử dụng tính năng lên khung thời gian cho các nhiệm vụ cá nhân. Kỹ thuật này sử dụng quy mô thời gian giảm (ví dụ: ba mươi phút thay vì một tuần) và phân phối (ví dụ: công việc thay vì thành phần của dự án kinh doanh). Lên khung thời gian cá nhân được cho là giúp hạn chế xu hướng cầu toàn (bằng cách thiết lập một thời gian vững chắc và không quá mức cho một nhiệm vụ).^[16] Nó cũng gợi ý rằng khung thời gian cá nhân tạo ra một áp lực gia tăng cho một cá nhân sẽ dẫn đến sự sáng tạo tốt hơn và tập trung hướng tới một nhiệm vụ.^[17]

Mối quan hệ với các phương pháp khác

Khung thời gian hoạt động như một khối kiến trúc trong các phương pháp quản lý thời gian cá nhân khác:

• Kỹ thuật Pomodoro dựa trên các khung thời gian tập trung 25 phút, được phân tách bằng cách phá vỡ cho phép tâm trí hồi phục.^[18]
• Andy Hunt dùng khung thời gian là 'T' trong SMART.^[19]

Xem thêm

• Mẹo vặt (Life hacking)

Chú thích

1. Poppendieck, Mary (2010). Leading Lean Software Development: Results Are Not the Point. Upper Saddle River, NJ: Addison-Wesley. tr. 139. ISBN 978-0-321-62070-5.
2. What are the Triple Constraints in Project Management Lưu trữ 2006-08-20 tại Archive.today Error in webarchive template: Check |url= value. Empty. , article by Rod Hutchings on Project Management Australia Error in webarchive template: Check |url= value. Empty. (22 Oct 2008)
3. “A short course in project management”.
4. . ISBN 1-56726-152-3. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
5. . ISBN 1-59749-037-7. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
6. ^ . ISBN 0-201-61641-6. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
7. . ISBN 978-0-595-67081-9 https://books.google.com/books?id=LQx3lab0KnIC. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
8. . ISBN 978-1-4277-9744-5. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
9. For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 function point) projects ranked 7 and rated a "Best Practice" by the survey in . ISBN 978-0-07-162162-5. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
10. . ISBN 978-0-321-62070-5. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
11. . ISBN 1-55615-900-5. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
12. . ISBN 978-0-470-68420-7 https://books.google.com/books?id=lpvY36MPMUwC. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
13. . ISBN 978-0-321-57936-2. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
14. . ISBN 978-0-321-63584-6 https://books.google.com/books?id=pTExbNmZwZUC. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
15. . ISBN 978-0-7356-3790-0 https://books.google.com/books?id=RpYX01XVMksC. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
16. Frankton, James (ngày 4 tháng 4 năm 2014). “40 Ways To Stop Procrastinating”. Why Am I Lazy?. Bản gốc lưu trữ ngày 14 tháng 10 năm 2017. Truy cập ngày 22 tháng 9 năm 2014.
17. . ISBN 978-1-118-13345-3 https://books.google.com/books?id=d-FYJceblAMC. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
18. . ISBN 978-1-934356-50-0. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)
19. . ISBN 978-1-934356-05-0. |title= trống hay bị thiếu (trợ giúp)|tựa đề= trống hay bị thiếu (trợ giúp)

Liên kết ngoài

• How To Use Timeboxing To Get More Done
• Agile Requirements Change Management
• Designing To Schedule Lưu trữ 2011-09-30 tại Wayback Machine
• MSDN - How To Use Timeboxing for Getting Results
• Using timeboxing for a motivation boost
• Why time boxed sprints? What happens to releases?