2010-01-22 33 views
7

Nếu người dùng sử dụng Scrum cho phần phát triển phần mềm của dự án, thì vẫn sử dụng PMBOK hoặc một số phương pháp quản lý dự án khác cho các tác vụ "khác" trên dự án, ví dụ: các công việc kinh doanh, tiếp thị, đào tạo. Quản lý dự án của các nhiệm vụ phát triển phần mềm không được gọi là quản lý dự án truyền thống là gì?Quản lý dự án Agile

+0

Tôi nghĩ câu hỏi này sẽ tốt cho [Programmers.SE], nếu nó không quá cũ để di chuyển nó. –

Trả lời

0

Chúng tôi đã mở rộng scrum cho các phòng ban khác trong công ty, người mẫu, họa tiết và nghệ sĩ hoạt hình. Chúng tôi đã phải thích ứng với phương pháp này một chút, nhưng nó hoạt động tốt. Chúng tôi đã gặp sự cố đã được giải quyết bằng cách sử dụng phương pháp nhanh nhẹn. Một số phòng ban nhỏ hơn (âm thanh, hiệu ứng đặc biệt) đã hoạt động tốt nên chúng tôi đã không cố gắng khắc phục những gì không bị hỏng. Agile đã thêm vào một chi phí không cần thiết cho họ.

Nó không phải là cần thiết cho tất cả các phòng ban trong một công ty sử dụng cùng một phương pháp, tốt nhất là để thích nghi với nhu cầu của mọi người. Nhưng scrum có thể là giải pháp cho những người không phải là lập trình viên, nhưng có thể cần một chút thích ứng. Hàng ngày đứng lên, chạy nước rút, backlog, những người có thể là một điều tốt cho nhiều loại công việc.

+0

Bạn đã triển khai SCRUM như thế nào trong các phòng ban khác, bạn có danh sách các nhiệm vụ mà mọi người tình nguyện hoặc bạn có giao nhiệm vụ không? – Joanne

-1

Scrum KHÔNG phải là phương pháp phát triển phần mềm mà là phương pháp quản lý dự án.

Bên cạnh Scrum thường được giới thiệu với Lego hoặc các đồ tạo tác khác (tìm kiếm "59 phút Scrum"). Vì vậy nó có thể được sử dụng để xử lý tất cả các nhiệm vụ của một dự án, bất kể bản chất của chúng.

-1

Trong khi tìm hiểu về các kỹ thuật này là tuyệt vời, tôi có thể đề xuất trọng tâm chính của bạn thực sự là đang chạy dự án và hoàn thành công việc không?

EDIT: đó là một điểm nghiêm trọng bằng cách này, không phải là một quip throwaway.

2

Dự án được xác định trong PMBOK như là một thứ gì đó có phạm vi, thời lượng và ngân sách cố định. Thất bại của dự án được định nghĩa là phá vỡ bên ngoài một trong ba mặt của "tam giác sắt" này. Scrum là một tập hợp các nguyên tắc và một số thực hành cụ thể để xử lý tất cả các loại công việc kiến ​​thức, dựa trên giá trị Agile và được thiết kế đặc biệt cho các nỗ lực phát triển có thể không phải là dự án hoặc có thể có phạm vi, thời lượng hoặc ngân sách linh hoạt.

Bạn nói đúng rằng Scrum chỉ đề cập đến một vài khía cạnh của quá trình phát triển phần mềm, chẳng hạn như lập kế hoạch. Nó chỉ định nghĩa một vài vai trò, các cuộc họp và hiện vật, điều này là để giữ cho nó linh hoạt nhất có thể. Scrum có thể, và nên, giải quyết các phần của luồng giá trị bên ngoài bản thân phát triển phần mềm. Tuy nhiên, như bạn đã đề cập, nó không giải quyết được nhiều thứ, chẳng hạn như thực hành kỹ nghệ phần mềm và phân tích trường hợp kinh doanh.

Thường thì giải pháp Scrum chuẩn là "để nhóm quyết định" về các vấn đề không được Scrum chỉ định trực tiếp. Thường thì các hướng dẫn để giải quyết các vấn đề này đến từ các nền văn hóa và giá trị hoặc các hệ thống nguyên tắc khác trong thế giới Agile, chẳng hạn như XP, hoặc phát triển phần mềm nạc. Các nền văn hóa khác cung cấp nội dung hữu ích cho các nhóm Scrum bao gồm các tùy chọn thực, phương pháp tài trợ tăng dần, Evo.

Một số công cụ PMBOK có thể hữu ích đối với "người quản lý dự án" hoặc PO trong nhóm Scrum, tuy nhiên người ta phải thận trọng vì nội dung PMBOK ngụ ý một hệ thống giá trị khác với Scrum dựa trên đó. Nó thường là tốt nhất để tìm kiếm các giải pháp trong nền văn hóa Agile. Một số các công cụ PMBOK vẫn áp dụng trong một bối cảnh nhanh nhẹn mặc dù.

Nếu bạn tìm kiếm danh sách gửi thư liên quan đến "quản lý dự án nhanh", bạn sẽ tìm thấy nhiều cộng đồng thịnh vượng thảo luận các chủ đề như vậy.

0

Nếu nỗ lực phát triển phần mềm của bạn chỉ là một khía cạnh của một dự án lớn hơn - ví dụ, tung ra một sản phẩm tài chính mới - thì chắc chắn, bạn sẽ phải sử dụng một số phương pháp quản lý dự án để dàn dựng tất cả công việc có tính liên quan. Tuy nhiên, việc áp dụng một nỗ lực phát triển phần mềm dựa trên Scrum vào một dự án được quản lý theo các nguyên tắc PMBOK có thể là một thách thức, vì PMBOK quy định một phương pháp tuyến tính, theo giai đoạn để thực hiện dự án trong khi Scrum, giống như các phương pháp Agile khác. Đó không phải là để nói rằng cả hai không thể cùng tồn tại. Giống như mọi thứ khác, nó đi xuống để thực hiện. Chỉ cần nhớ là thực dụng và thích ứng với các phương pháp luận theo nhu cầu của bạn, không phải theo cách khác.

2

Phát triển nhanh và không nên trộn lẫn PMBOK. NẾU bạn có, bạn có khả năng kết thúc với Scrummerfall.Tôi đã thấy điều này xảy ra với các nhà quản lý dự án truyền thống, những người chuyển đổi thành nhanh nhẹn. Họ chỉ không nhận được nó và dường như rơi trở lại mô hình cũ.

Tuy nhiên, theo ý kiến ​​của tôi, SCRUM không bao gồm tất cả những gì bạn cần để quản lý dự án. Nó thiếu một chiến lược tổng thể để cai trị. Một khả năng là kết hợp SCRUM với EVO project/value management hoặc các phương pháp quản lý giá trị khác. Tuy nhiên, nó sẽ yêu cầu một loại hợp đồng pháp lý khác với khách hàng. Các dự án sau đó giống như một quá trình liên tục là thời gian đóng hộp, bị hạn chế bởi ngân sách hoặc kết thúc khi khách hàng cảm thấy anh ta ít hơn đầu tư của mình (sử dụng các trường hợp kinh doanh và các biện pháp mục tiêu). Một lợi ích bổ sung là khách hàng sẽ thấy bạn như một đối tác lâu dài hơn là một nhà cung cấp ngắn hạn.

+0

Tôi đã thử đọc về quản lý dự án/giá trị EVO nhưng thấy tài liệu rất phức tạp và tiết tú. Bạn đã sử dụng thành công chưa? – Joanne

Các vấn đề liên quan