Để bắt đầu. Scrum và Agile - sự khác biệt là gì? Tóm lại, Agile là một triết lý, một họ các phương pháp tiếp cận linh hoạt để phát triển phần mềm. Scrum là một trong những cách tiếp cận như vậy. Anh ấy có một người anh trai - Kanban. Nó cũng là cách tiếp cận được sử dụng trong Agile.

Elena Truskova nói:

Tuần này, tôi đã tham gia khóa đào tạo Agile / Scrum hai ngày (phát âm là "nhanh nhẹn" và "scrum"). Rất nhiều tài liệu trừu tượng và không quá được viết trên các phương pháp luận phát triển phần mềm linh hoạt, tôi đã đọc rất nhiều. Nhưng chỉ sau hai ngày đắm chìm trong chủ đề, tôi cuối cùng đã hiểu cơ bản về chủ đề mà từ đó tôi viết ghi chú này.

Agile và Scrum giúp tổ chức quá trình làm việc nhóm theo cách để phát hành một sản phẩm thú vị cho người dùng một cách thường xuyên và thường xuyên.

Ở một số ngân hàng, nhờ nhanh nhẹn, con đường của một ý tưởng đến người dùng đã giảm từ hai năm xuống sáu tháng - ở các công ty khác, chu kỳ phát triển sáu tháng được nén thành ba. Trong những thời điểm bận rộn này, đây là một lợi thế cạnh tranh thực sự, đặc biệt là đối với những người chơi nhỏ hơn.

Các nguyên tắc Scrum có thể được áp dụng cho tất cả mọi thứ: ví dụ, để làm việc trên một sản phẩm sáng tạo. Tất nhiên, điều này không phải là “nhanh nhẹn kinh điển”, những người truyền bá phúc âm Scrum sẽ nghiến răng, nhưng các quy trình của bạn sẽ diễn ra vui vẻ hơn. Rô hay đi?

Một số Agile và Scrum thậm chí có thể được đưa vào công việc cá nhân. Đảm bảo thường xuyên xuất bản các bài đăng, đo lường tải đối với người thực hiện, đánh giá các nhiệm vụ trong tương lai về mặt thời gian và đừng quên phân tích chất lượng công việc đã hoàn thành - hãy nhìn xem, mọi thứ đã được chúng tôi nghĩ đến. Nó vẫn còn để thực hiện.

Nhanh nhẹn

(Tiếng Anh nhanh nhẹn - "nhanh nhẹn, thông minh, nhanh trí")

Khái niệm linh hoạt:

Thay thế loại hoạt động của bạn thay vì từ "phát triển" - và những nguyên tắc này sẽ trở nên gần gũi và dễ hiểu.

“Một sản phẩm đang hoạt động là chỉ số chính của sự tiến bộ”, “sự đơn giản là nghệ thuật giảm thiểu công việc không cần thiết” và “con người và sự tương tác quan trọng hơn quy trình và công cụ” - điều đó có hợp lý không?

Scrum

(eng. scrum - nghiền nát trong cuộc chiến giành bóng trong bóng bầu dục)

Ở đây cần nhắc lại rằng đây là quan điểm cá nhân và chủ quan của tôi về Scrum. Ở đây tôi phản ánh về khả năng ứng dụng của các yếu tố Scrum cả trong các dự án sáng tạo khác xa với CNTT và trong công việc cá nhân (giả sử trên blog). Nhiều chi tiết chính xác cho điều này sẽ phải được bỏ qua; Tôi cố gắng giữ cho văn bản đơn giản và không cung cấp cho người đọc quá nhiều thuật ngữ.

Sự cứng rắn của Scrum nằm ở cấu trúc. Có một số cách tiếp cận nhất định hoạt động cùng nhau tốt hơn là riêng lẻ. Rút cái gì ra dùng cho em, mong không ai cấm.

Scrum thường xảy ra khi có một sản phẩm nhất định có giá trị đối với người dùng và khách hàng, và bạn cần hiểu càng nhanh càng tốt về con đường đạt được mục tiêu liệu chúng ta có đang chạy đúng hướng hay cần điều chỉnh lại lộ trình. Định dạng Scrum cho phép bạn phát hành phiên bản tiếp theo thường xuyên hơn, nhận phản hồi thường xuyên và nhanh chóng tinh chỉnh sản phẩm, cũng như cải thiện quy trình làm việc.

Nếu bạn làm việc theo nhóm, Scrum yêu cầu tất cả những người tham gia trong quá trình phấn đấu về khả năng thay thế lẫn nhau, khả năng “nhận” một nhiệm vụ không mong muốn nếu một người hàng xóm bị ốm, trao đổi kỹ năng và trách nhiệm tập thể đối với sản phẩm. Có rất ít chủ nghĩa cá nhân trong Scrum. Các quyết định được đưa ra tập thể (theo nguyên tắc nghiêm ngặt), không ai có thể gây áp lực và buộc họ phải chọn giải pháp khác nếu cả đội chắc chắn rằng họ đã giải quyết đúng.

Có được sự tự tin như vậy trong Scrum không có gì đáng sợ, vì mỗi cuộc hành quân kéo dài đúng một lần chạy nước rút (một khoảng thời gian rõ ràng, thường là từ một đến bốn tuần). Sau khi nước rút kết thúc, có một chút phân tích: chúng ta đã vượt qua nó như thế nào? Điều gì có thể được thực hiện tốt hơn vào lần tới?

Do đó, ngay cả khi tất cả chúng ta đều tự tin chạy sai hướng, chúng ta sẽ có cơ hội để sửa sai và sửa chữa những gì đang dẫn chúng ta đi sai hướng vào cuối chặng nước rút. Nhóm trong Scrum tự tổ chức và tự điều chỉnh.

Nhóm trong Scrum

Quy mô tiêu chuẩn của một nhóm Scrum là 7 người và trừ 2 người. Đó là năm đến chín. Có khả năng mở rộng quy mô: bạn có thể xây dựng một hệ thống làm việc với một nhiệm vụ khổng lồ trong số 25 nhóm. Nhưng đơn vị cơ bản của Scrum là nhóm.

Mỗi đội có:

• người tham gia (trong trường hợp CNTT - nhà phát triển, bảy người này bạn có là ai - tự quyết định)
• product owner (chủ sở hữu sản phẩm, chủ sở hữu sản phẩm). Vai trò của anh: hiểu thị trường và người dùng, xây dựng các nhiệm vụ bằng ngôn ngữ của doanh nghiệp và người dùng, ghi nhớ nhận thức về hướng phát triển giá trị và lợi ích, để phát minh và lựa chọn các nhiệm vụ để phát triển sản phẩm. Một cái gì đó giống như một sản phẩm (không phải một nhóm) lãnh đạo.
• bậc thầy scrum (scrum master, scrum evangelist). Vai trò của anh ấy: theo dõi quy trình, quan sát cuộc sống bên trong của đội, động viên mọi người, loại bỏ các trở ngại. Kiểu như một huấn luyện viên.
  Xung quanh nhóm có người dùng và những người liên quan (các bên liên quan, khách hàng). Chủ sở hữu sản phẩm tìm đến những người này để xin lời khuyên.

Chạy nước rút thiết bị

Công việc Scrum bao gồm chạy nước rút. Tất cả các cuộc chạy nước rút đều được thiết lập theo cùng một cách. Giả định rằng với mỗi nước rút tiếp theo, nhóm trở nên hợp tác và hiệu quả hơn. Trong Scrum, bạn học được từ những sai lầm của mình, nhưng nhanh chóng - mỗi sprint bạn phân tích chính xác những gì bạn đã làm và cách bạn muốn sửa chữa nó.

Chủ sở hữu sản phẩm có một danh sách các ý tưởng kinh doanh để giữ cho người dùng hài lòng. Nó được gọi là "product backlog" (danh sách các ý tưởng về sản phẩm). Trong đó, các ý tưởng được sắp xếp theo mức độ quan trọng và ý nghĩa.

Mỗi sprint có một sprint tồn đọng (sprint backlog, một danh sách các nhiệm vụ cho một sprint) - một danh sách được sắp xếp các ý tưởng mà nhóm đã quyết định thực hiện trong sprint tiếp theo. Ý nghĩa của Scrum là nhóm tự đánh giá mức độ phức tạp của từng nhiệm vụ và quyết định nhiệm vụ nào sẽ được đưa vào sprint tiếp theo.

Nhiệm vụ trong sprint có sức nặng được cả đội biết trước (nó sẽ mất bao lâu), một người thực hiện gắn bó với nó, đó là điều dễ hiểu và quan trọng. Nếu bạn không biết một nhiệm vụ sẽ mất bao lâu, bạn cần chia nó thành các phần nhỏ hơn.

Khi bắt đầu cuộc sống của họ, nhóm luôn lập kế hoạch tồi tệ. Đây là một thực tế khách quan. Nhưng cô ấy giữ số liệu thống kê về những gì cô ấy quản lý để làm trong một cuộc chạy nước rút và lập kế hoạch chính xác hơn theo thời gian. Cô ấy được giúp đỡ bởi cuộc họp cuối cùng của nước rút - một cuộc hồi tưởng. Nó có thể thảo luận về những điểm yếu của sprint sắp tới và đưa ra những cách làm khác đi.

Thông thường 5 ý tưởng cộng hoặc trừ 2 sẽ phù hợp với một sprint. Nếu các ý tưởng quá lớn, nhóm sẽ chia nhỏ chúng ra để trong mỗi sprint sẽ có một cái gì đó nhỏ để thể hiện.

Trong Scrum, các ý tưởng được gọi là câu chuyện người dùng (câu chuyện người dùng, câu chuyện về người dùng) và được xây dựng như sau: “Tôi thích (vai trò?) Muốn (cái gì?) Để làm (tại sao?)”. Do đó, nhóm không chỉ nhìn thấy chức năng mà còn cả ý nghĩa của việc tạo ra nó và cho một vai trò cụ thể: người dùng, khách hàng, người mua.

Kết quả của một cuộc chạy nước rút luôn là điều cần thể hiện. Hiển thị công việc của nhóm trên bản demo khi kết thúc sprint.

Theo tôi, quy trình Scrum tương tự như làm việc trên blog nhóm. Quy trình như vậy sẽ giúp duy trì tính thường xuyên, tập hợp chuyên môn của các tác giả và không tuyển dụng quá nhiều mà bạn không thể làm được.

Cấu trúc Sprint

Chạy nước rút bắt đầu bằng việc lập kế hoạch: nhóm ngồi xuống và thảo luận: chúng tôi lấy ý tưởng này, chúng tôi không lấy ý tưởng kia. Trong CNTT, quá trình này có thể kéo dài trong vài giờ, bởi vì cuộc thảo luận đi xuống chi tiết. Trong trường hợp làm việc với blog, điều này có thể biến thành một cuộc thảo luận về các chủ đề và kế hoạch các bài viết, sau đó bạn phải ngồi xuống và viết - hiểu chúng ta viết gì, khi nào và tại sao.

Mỗi ngày có một cuộc họp đứng lên (cuộc họp đứng lên, cuộc họp thường trực) trong 15 phút. Điều quan trọng là phải làm điều đó khi đang đứng: nếu ai đó nói chuyện, những người còn lại sẽ hùng hồn chuyển từ chân này sang chân khác và ngoáy tai. Bạn có thể sử dụng một số đối tượng để chỉ một người tham gia nói tại một thời điểm và chuyển đối tượng đó theo vòng tròn.

Mỗi người tham gia đứng lần lượt trả lời ba câu hỏi:

• những gì tôi đã làm ngày hôm qua
• tôi sẽ làm gì hôm nay
• điều gì làm tôi chậm lại

Tất cả các cuộc trò chuyện chi tiết được ràng buộc trong quá trình này đều vượt ra ngoài giới hạn của chế độ độc lập. Chờ là thời điểm mà bạn có thể bắt gặp vấn đề hoặc phát hiện ra rằng vì lý do nào đó mà tôi và đồng nghiệp đang làm cùng một việc cùng lúc, điều đó có nghĩa là ai trong chúng ta có thể làm việc khác.

Nói chung, việc duy trì tất cả các quy tắc hành vi rõ ràng này nên được Scrum Master xử lý. Đây thường là những nhà tư tưởng về công nghệ, những người tin tưởng vào nó và sẵn sàng xây dựng một quy trình để đạt được hiệu quả tối đa trong khoảng thời gian dành cho nhau. Nếu không có Scrum Master, các quy trình sẽ giảm xuống mức tối thiểu có thể, bởi vì một người lười biếng và tiết kiệm.

Vào cuối sprint, có một bản trình diễn (demo, trình diễn) cho thấy những gì chúng tôi đã quản lý để tạo ra trong sprint, một bài đánh giá sprint (sprint review, sprint review) với một bản sửa đổi của sản phẩm tồn đọng và nói về NHỮNG GÌ chúng tôi làm, cũng như hồi tưởng (retro) - điều mà chúng tôi đã không làm một cách tốt nhất trong toàn bộ sprint và muốn cải thiện hơn nữa - về CÁCH chúng tôi thực hiện.

"Nếu tôi có tám giờ để chặt một cái cây, thì tôi sẽ dành sáu giờ để mài một chiếc rìu." (Được gán cho thợ rừng và Tổng thống Abraham Lincoln)

Scrum là một phương pháp luận phát triển linh hoạt của tác giả với sự phân bổ không theo tiêu chuẩn của các vai trò trong một nhóm và một tổ chức lặp lại duy nhất. Scrum, giống như các phương pháp quản lý dự án nhanh nhẹn khác, thúc đẩy phương pháp tiếp cận theo nhóm, lặp lại ngắn và cải tiến liên tục trong quy trình. Những nguyên tắc này được thực hiện thông qua một tập hợp các vai trò, quy tắc, quy trình và công cụ cụ thể giúp các nhóm sản xuất sản phẩm trong một nửa thời gian.

Trong các nhóm Scrum, các vị trí quan trọng do
đội sản xuất và chủ sở hữu sản phẩm,
bắt đầu lặp lại lập kế hoạch,
mà các thành viên trong nhóm "chơi"
Trong bài xì phé lập kế hoạch,
và kết thúc demo vớihồi tưởng.

Phương pháp luận Scrum được tạo ra bởi Jeff Sutherland, một nhà nghiên cứu và tư vấn kinh doanh người Mỹ, và Ken Schwaber, một lập trình viên hành nghề, vào năm 1993. Năm 1995, các tác giả của khái niệm này đã chính thức trình bày các cách tiếp cận của nó tại hội nghị khoa học của Hiệp hội Máy tính Máy tính ở Austin, Texas.

Ý tưởng của các đồng tác giả scrum không phải là mới: cả khái niệm và thậm chí cả cái tên mà họ lấy từ công trình nghiên cứu của các nhà nghiên cứu Nhật Bản trong lĩnh vực quản lý, xuất bản năm 1986. Ngay cả khi đó, các nhà sản xuất Nhật Bản đã sử dụng các cách tiếp cận đã hình thành nền tảng của Scrum. Và tên của phương pháp này được mượn từ từ vựng của các cầu thủ bóng bầu dục. Scrum, hoặc scrum, là một yếu tố của trò chơi cho thấy tầm quan trọng của tinh thần đồng đội để giành chiến thắng trên sân.

Scrum trong CNTT và hơn thế nữa

Scrum lần đầu tiên được sử dụng trong các công ty phần mềm. Dự án đầu tiên mà J. Sutherland giám sát ngay cả trước khi Scrum trình bày chính thức là việc tạo ra phần mềm cho mạng ATM (1983). Các nhóm lập trình trong các công ty và bộ phận CNTT vẫn là những người tiêu dùng chính của scrum. Tuy nhiên, tác giả của phương pháp này khẳng định rằng Scrum có thể áp dụng để giải quyết bất kỳ vấn đề nào và đưa ra các ví dụ về việc sử dụng Scrum trong sản xuất, xây dựng, giáo dục, chính trị và thậm chí trong việc giải quyết các công việc hàng ngày như tổng vệ sinh hoặc tổ chức kỳ nghỉ.

Thật vậy, theo Liên minh Scrum cho năm 2016, 21% dự án được hoàn thành theo Scrum không liên quan đến lĩnh vực CNTT. Xem những phòng ban nào đang sử dụng thành công scrum:

Scrum so với Agile và Waterfall

Scrum thuộc nhóm các phương pháp linh hoạt hay còn gọi là các phương pháp linh hoạt. Agile không phải là một phương pháp luận riêng biệt, mà là toàn bộ triết lý phát triển phần mềm, các phương pháp tiếp cận chính của nó đã được ghi nhận vào năm 2001. Tuyên ngôn liệt kê các nguyên tắc cơ bản của nhanh nhẹn - tầm quan trọng của nhóm, tập trung vào sản phẩm, không dựa trên tài liệu, minh bạch quy trình, cải tiến liên tục, kết quả nhanh chóng.

Scrum là một trong những khung công tác linh hoạt, một phương pháp luận được chính thức hóa để làm việc trong các dự án. Các phương pháp luận Agile, ngoài scrum, bao gồm các phương pháp tiếp cận hiện đại khác. Một giải pháp thay thế cho scrum có thể là Scrumban và các loại khác. Có nghĩa là, Scrum nhanh nhẹn, nhưng nhanh nhẹn không chỉ có Scrum.

Hãy tưởng tượng rằng nhanh nhẹn là Cơ đốc giáo, và cáu kỉnh là một trong những trào lưu của nó, chẳng hạn, Đạo Tin lành. Và mặc dù những người theo đạo Thiên chúa nói chung và những người theo đạo Tin lành nói riêng tuyên xưng những nguyên tắc giống nhau, nhưng những người theo đạo Tin lành lại có những nghi lễ độc đáo của riêng mình để thể hiện đức tin.

Theo đó, sự khác biệt về hình ảnh và sự tương đồng giữaScrum vàAgile có thể được hình dung như thế này:

* Đồ tạo tác trong scrum, đây là những đối tượng được tạo ra bởi nhóm trong khi làm việc trong dự án. Chúng bao gồm tồn đọng sản phẩm, tồn đọng sprint và gia số sản phẩm, nghĩa là, phần chức năng hoạt động mà nhóm thể hiện ở cuối sprint.

Các phương pháp phát triển Agile chống lại mô hình thác (thác nước, thác nước, thác nước), trong những năm 90 đã được hầu hết các nhóm phát triển sử dụng.

Bản chất của mô hình thác nước là thực hiện theo từng giai đoạn của dự án và công việc trên mỗi giai đoạn tiếp theo chỉ bắt đầu sau khi kết thúc giai đoạn trước đó. Về sơ đồ, mô hình thác trông như thế này:

Nhưng cách tiếp cận theo phương pháp phân tầng không hiệu quả — các nhóm đã bỏ lỡ thời hạn và hết ngân sách. Phương pháp thác nước đã không tính đến các vấn đề mới nảy sinh, sự chậm trễ và thất bại, thay đổi yêu cầu của khách hàng và môi trường. Cần phải tìm kiếm giải pháp thay thế và thay đổi quy trình làm việc - thường xuyên nhìn lại, phân tích công việc đã thực hiện và ngay lập tức loại bỏ những trở ngại và thực hiện thay đổi. Do đó, các phương pháp luận nhanh nhẹn linh hoạt đã xuất hiện và các dẫn xuất của nó.

Cách làm việc với Scrum

Các vai trò trong Scrum

Nhóm Scrum

Scrum dựa trên một nhóm hoặc một nhóm - một cơ quan phối hợp nhịp nhàng của các chuyên gia. Nhóm Scrum tự chủ, các thành viên tự quyết định cách hoàn thành nhiệm vụ. Chúng đa chức năng - kiến ​​thức và kỹ năng của các thành viên trong nhóm là đủ để giải quyết vấn đề.

Scrum yêu cầu một đội nhỏ: 7 ± 2 người. Với nhiều người hơn, các thành viên trong nhóm dành quá nhiều tài nguyên cho giao tiếp. Vào giữa những năm 90, Lawrence Putnam đã phân tích 491 nhóm phát triển: họ đều đang tạo ra một sản phẩm mới và có quy mô khác nhau. Nghiên cứu chỉ ra rằng các nhóm lớn (9-20 người) cần thời gian và nỗ lực gấp 4 lần để giải quyết một vấn đề so với các nhóm nhỏ (3-7 người).

Đội sản xuất

Scrum Master là người lãnh đạo chính thức của nhóm Scrum, một trợ lý giám sát việc áp dụng đúng phương pháp và duy trì tinh thần của nhóm. Anh ấy chịu trách nhiệm về cách thực hiện công việc.

Chủ sở hữu sản phẩm, Chủ sở hữu sản phẩm

Chủ sở hữu sản phẩm là người chịu trách nhiệm về chức năng của sản phẩm cuối cùng. Anh ấy biên soạn một danh sách các câu chuyện của người dùng (dự án tồn đọng) và duy trì nó trong suốt dự án. Lĩnh vực trách nhiệm của anh ấy là những gì cần làm trong dự án và giao tiếp với khách hàng.

khách hàng

Khách hàng hoặc khách hàng là người mà dự án đang được thực hiện. Khách hàng có thể là bên thứ ba hoặc tổ chức hoặc người trong cuộc. Ví dụ, một bộ phận bán hàng đã đặt hàng các nhà phát triển phát triển một hệ thống CRM.

Các cuộc họp Scrum thường xuyên và chương trình làm việc

Lập kế hoạch

Cuộc họp đầu tiên bắt đầu cuộc chạy nước rút. Trên đó, nhóm, với sự trợ giúp của Scrum Master và Product Owner, chọn các nhiệm vụ từ đầu công việc tồn đọng mà họ sẽ có thời gian để hoàn thành.

Các nhiệm vụ đã chọn được đưa vào dự án nước rút với thời hạn và người thực hiện.

Các cuộc họp hàng ngày khi đang di chuyển

Tất cả các thành viên trong nhóm họp vào cùng một thời điểm mỗi ngày để đánh giá tiến độ và trao đổi thông tin.

Để làm điều này, họ trả lời ba câu hỏi:

1. tôi đã làm gì ngày hôm qua để giúp nhóm đạt được mục tiêu?
2. tôi sẽ làm gì hôm nay để nhóm đạt được mục tiêu?
3. điều gì đã ngăn cản tôi làm công việc của mình?

Các cuộc họp kéo dài không quá 15 phút và được tổ chức thường trực.

Đối với cuộc họp này, mọi người có thể xem Báo cáo của họ cho ngày đã chọn.

Đánh giá Demo hoặc Sprint

Được tiến hành khi công việc chạy nước rút hoàn thành. Đây là một minh chứng cho khách hàng và tất cả các bên quan tâm về chức năng mà nhóm đã tạo ra trong quá trình chạy nước rút. Ở giai đoạn này, khách hàng bày tỏ ý kiến ​​của mình, thực hiện các điều chỉnh, yêu cầu bổ sung chức năng, v.v.

Các báo cáo được sử dụng cho khoảng thời gian tương ứng, "khách hàng tiếp cận" các dự án (có thể nhìn thấy tiến độ, không nhìn thấy bếp nội bộ), nhận xét và cảm xúc.

hồi tưởng

Đây là cuộc họp trong đó nhóm thảo luận về các nhiệm vụ đã hoàn thành trong sprint, mức độ hoàn thành của chúng và các vấn đề cần giải quyết. Tỷ lệ các nhiệm vụ được lập kế hoạch và hoàn thành quyết định hiệu quả của nhóm. Nhìn lại, tìm cách cải thiện.

Các báo cáo trong khoảng thời gian tương ứng của Người, Bộ phận, Tài khoản và Chi tiết được sử dụng.

Thuật toán. Để làm gì?

1. Chọn Chủ sở hữu sản phẩm trong đó xác định rõ ràng những gì cần phải làm.

2. Thành lập Nhóm Scrum.

3. Bổ nhiệm một Scrum Master.

4. Tạo một dự án tồn đọng dưới dạng một danh sách các câu chuyện của người dùng. Bao gồm tất cả các nhiệm vụ mà nhóm có thể làm cho dự án và ưu tiên chúng. Đưa ra các nhiệm vụ chứa chức năng chính của dự án và điều đó sẽ mang lại thu nhập cho khách hàng.

Công việc tồn đọng là một danh sách đầy đủ các công việc cần hoàn thành.
Câu chuyện người dùng, Câu chuyện người dùng là các yêu cầu về chức năng của sản phẩm, được nói thay cho người dùng cuối. Ví dụ: tôi, với tư cách là người mua một cửa hàng trực tuyến, muốn tìm kiếm sản phẩm mong muốn trên trang web (thanh toán khi mua hàng bằng thẻ, lưu hàng vào giỏ, v.v.).

5. Ước tính các nhiệm vụ từ công việc tồn đọng, sử dụng các giá trị tương đối, chẳng hạn như kích thước áo phông hoặc số từ dãy Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, v.v. Ước tính nhiệm vụ với cả nhóm bằng cách lập kế hoạch chơi bài xì phé: sử dụng bộ bài hoặc ứng dụng trên điện thoại thông minh.

Lập kế hoạch poker là một bộ bài đặc biệt có số Fibonacci. Mỗi thành viên trong nhóm nhận được thiết lập của riêng họ. Khi Scrum Master thông báo nhiệm vụ, các thành viên trong nhóm đồng thời đặt thẻ lên bàn với các con số mà họ cho rằng tương ứng với độ khó của nhiệm vụ. Nếu các thẻ của những người tham gia khác nhau một hoặc hai đơn vị, chẳng hạn như 3 và 8, thì nhiệm vụ được giao có độ phức tạp bằng trung bình cộng của những con số này. Nếu sự khác biệt lớn hơn, thì những người tham gia đã ném ra các thẻ nhỏ nhất và lớn nhất sẽ giải thích quyết định của họ. Sau đó, tất cả các thành viên trong nhóm lại xếp thẻ. Và cứ tiếp tục như vậy, cho đến khi mọi người đi đến thống nhất.

6. Lập kế hoạch Sprint: Chọn nhiệm vụ và phân phối chúng giữa những người thực hiện.

7. Nhận Scrum Board, chia nó thành ba phần: được thực hiện, đang tiến hành, đã hoàn thành. Di chuyển nhãn dán với các nhiệm vụ để xem động lực của công việc. Sử dụng bảng trắng thực hoặc ảo.

8. Đừng quên các cuộc họp hàng ngày của bạn.

9. Trình diễn khi kết thúc sprint.

10. Cùng nhau hồi tưởng, thảo luận làm thế nào để cải thiện công việc, những trở ngại nào cần tháo gỡ. Nó có thể là một máy pha cà phê không hoạt động, một máy tính chậm, nhiệt độ không khí khó chịu, một đồng nghiệp nóng nảy, một nhà thầu vô đạo đức. Khi nhóm bắt đầu làm việc trên Scrum, các vấn đề đã được gác lại trong nhiều tháng sẽ được giải quyết.

11. Bắt đầu nước rút tiếp theo của bạn với việc lập kế hoạch(điểm 6).

Hướng dẫn Scrum. Hướng dẫn dứt khoát về Scrum: Quy tắc của trò chơi / Ken Schwaber, Jeff Sutherland

Nguyên tắc Scrum: Mô tả các vai trò, hoạt động, các tạo tác Scrum và cách sử dụng chúng. được biên soạn và duy trì bởi các đồng tác giả của phương pháp Scrum.

Scrum. Một phương pháp quản lý dự án mang tính cách mạng / Jeff Sutherland

Quản lý sản phẩm trong Scrum. Các phương pháp linh hoạt cho doanh nghiệp của bạn / Roman Pikhler

Một phần đáng kể được dành cho chủ sở hữu của sản phẩm: chức năng, phẩm chất, lỗi của nó. Tác giả xem xét chi tiết quá trình tạo ra một sản phẩm theo phương pháp Scrum, bắt đầu bằng việc suy nghĩ thông qua khái niệm về một sản phẩm trong tương lai và kết thúc bằng việc tạo ra các báo cáo.

Scrum và XP: Ghi chú từ Front Line / Henrik Kniberg

Về ứng dụng thực tế của các phương pháp tiếp cận nhanh hiện đại - Lập trình Scrum và Cực đoan - trong một nhóm cụ thể. Rất nhiều ví dụ, công cụ, phương pháp Scrum hoạt động mà không cần nước và lý thuyết.

Tuyên ngôn Phát triển Phần mềm Agile

Bao gồm một số dòng dựa trên các phương pháp luận linh hoạt.

Ưu điểm và nhược điểm của Scrum trong CNTT

Scrum là một phương pháp luận tuyệt vời: hiệu quả cao, minh bạch, thúc đẩy. Đây là cách tiếp cận đôi bên cùng có lợi, mang lại lợi ích cho cả nhóm và khách hàng.

1. Tính minh bạch.Nhóm có sự trao đổi cởi mở về thông tin, kiến ​​thức, các vấn đề, mọi người đều cảm thấy tham gia vào một mục tiêu chung. Khách hàng luôn nhận thức được tiến độ công việc, thực hiện các thay đổi trong quy trình, nhận được thông tin đáng tin cậy về thời hạn.
2. Quyền tự chủ của đội. H Các thành viên của nhóm quyết định cách thức làm việc trong dự án, tự do hành động và thúc đẩy trách nhiệm. Khách hàng trao đổi trực tiếp các yêu cầu với nhóm, không có điện thoại bị hỏng.
3. Động lực bởi kết quả.Khái niệm scrum cho phép mỗi thành viên trong nhóm nhìn thấy những thành tựu chung và riêng của họ hàng ngày. Khách hàng nhận được sự gia tăng về chức năng với mỗi lần lặp lại.
4. Giảm thiểu rủi ro thị trường.Nhóm nhanh chóng đáp ứng các yêu cầu thay đổi của dự án và không làm thêm công việc. Khách hàng nhận được những gì họ muốn và những gì đang có nhu cầu trên thị trường.
5. Giảm thiểu rủi ro tài chính.Ít thời gian và tiền bạc được dành cho việc loại bỏ lỗi và thêm chức năng, mọi thứ đều được đầu tư vào ngân sách.

Nhưng Scrum là một phương pháp luận được chính thức hóa, và đối với một số dự án, nó không dễ áp ​​dụng.

Dưới đây là những nhược điểm rõ ràng của Scrum:

• không phù hợp với các dự án có yêu cầu mơ hồ về sản phẩm cuối cùng, bởi vì khách hàng có thể tăng chức năng lên vô hạn;
• rất khó để học cách sắp xếp thứ tự ưu tiên và đánh giá đúng các nhiệm vụ;
• sự thành công của dự án phụ thuộc quá nhiều vào Scrum Master;
• Scrum khó sử dụng trong các dự án lớn, bạn phải mở rộng phương pháp luận và giới thiệu các cuộc họp scrums. Các cuộc họp này có sự tham gia của đại diện của một số nhóm Scrum làm việc trên các sản phẩm liên quan.

Trong dự án của chúng tôi, họ ngay lập tức cố gắng thực hành scrum hai cấp: toàn cầu và ở cấp bộ phận (bán hàng, tiếp thị, tài chính, v.v.). Đầu tiên, các trưởng bộ phận xác định các nhiệm vụ trong kế hoạch toàn cầu, sau đó họ giảm dần xuống cấp bộ phận. Chúng tôi đã làm kém - kết quả cuối cùng là quá mờ.

• các nhóm có hiệu suất cao thư giãn và ngừng cải thiện. Một chỉ báo cho thấy sự hiện diện của một vấn đề là sự suy giảm động lực thực hiện của các cuộc chạy nước rút. Scrum Master phải truyền đạt mức độ nghiêm trọng của vấn đề cho nhóm. Nếu nhóm không tự thoát ra khỏi bế tắc, ban lãnh đạo sẽ can thiệp: nhân viên mới được thuê, nhân sự được luân chuyển.

Các công ty Scrum

Theo báo cáo Scrumalliance, 70% công ty CNTT sử dụng Scrum. Trong số đó có những gã khổng lồ như Google, Amazon, Salesforce.com, Microsoft, Adobe.

Salesforce.com

Người Mỹ, nhà phát triển hàng đầu của hệ thống CRM dành cho doanh nghiệp. Sản phẩm của nó được sử dụng bởi 150.000 công ty. Trong nhiều năm, ông đã sử dụng các phương pháp tiếp cận phương pháp linh hoạt được dẫn dắt bởi Scrum, trên cơ sở đó, tạo ra một sự kết hợp độc đáo của một số khung công tác linh hoạt.

Đã sử dụng các thực hành nhanh từ năm 1999 và đến năm 2004, một số nhóm phát triển đã sử dụng Scrum. Đến năm 2009, hầu hết các nhà phát triển đã được chuyển sang Scrum một cách có chủ đích.

Spotify

Một dịch vụ âm nhạc kỹ thuật số cạnh tranh thành công với những gã khổng lồ Google, Apple và Amazon. Spotify coi lợi thế cạnh tranh của mình là việc sử dụng tối đa các cơ hội Scrum. Ban quản lý của công ty thuê các Huấn luyện viên Scrum giỏi nhất để làm Scrum Master. Công việc được thực hiện bởi các nhóm nhỏ tự trị, được coi như các công ty khởi nghiệp.

Đã sử dụng Scrum từ năm 2008, 4 nghìn nhà phát triển trong hàng trăm nhóm gồm 10-12 người làm việc theo phương pháp Scrum, phát hành một sản phẩm mới ba tuần một lần. Công ty đã thành công trong việc mở rộng Scrum để phù hợp với quy mô của nó.

Thực tế là Scrum không chỉ được sử dụng trong lĩnh vực CNTT được chứng minh qua dự án - sáng kiến ​​của một giáo viên hóa học tại một trường học ở thị trấn Alphen aan den Rijn của Hà Lan. Với sự hỗ trợ của cộng đồng doanh nghiệp ở Hà Lan, Tổ chức eduScrum được thành lập nhằm đào tạo giáo viên sử dụng Scrum trong lớp học. Sinh viên làm việc trong các nhóm Scrum học tốt hơn và vui vẻ hơn so với các bạn cùng lứa tuổi.

Dự án Sentinel cho FBI

Sự ra đời của phương pháp Scrum đã cứu dự án hàng triệu đô la của chính phủ Mỹ khỏi sự sụp đổ - một cơ sở dữ liệu duy nhất là "Người bảo vệ" cho FBI. The Guardian là nỗ lực thứ hai nhằm phát triển một hệ thống thông tin thống nhất cho FBI. Cái đầu tiên thất bại mà không cần đến một ngày làm việc.

"Người giám hộ" bắt đầu được tạo ra vào năm 2005 theo mô hình thác nước. Dự án được phân bổ 4 năm và 450 triệu đô la. Vào đầu năm thứ năm, công ty nhà thầu đã hoàn thành một nửa công việc và chi tiêu 95% ngân sách. Theo các chuyên gia, sẽ phải mất thêm 350 triệu USD và 6-8 năm để hoàn thành dự án.

Khi các nhóm scrum thay thế mô hình thác nước vào đầu năm 2010, năng suất của nhà phát triển đã tăng gấp ba lần và vào ngày 2 tháng 7 năm 2012, Sentinel đã được các đặc vụ FBI ở mọi bang sử dụng.

Các ứng dụng

Công việc trên các dự án Scrum được thực hiện trong các ứng dụng và chương trình đặc biệt. Một giao diện đa chức năng cho phép bạn theo dõi tiến độ của dự án từ các góc độ khác nhau.

Đơn giản và trực quan để làm việc trên các dự án và giải quyết các vấn đề kinh doanh khác nhau.

Worksection hiện đang hoàn thiện và thử nghiệm các tính năng cho scrum trước khi triển khai (tính đến tháng 10 năm 2017): biểu đồ hoàn thiện nhiệm vụ và công việc tồn đọng hoàn toàn là các công cụ Scrum. Có thể sẽ cólập kế hoạch chơi poker.Chuyên gia tư vấn của chúng tôi trong vấn đề này,

Gần đây, tôi thường được hỏi Scrum là gì bởi những người có mối quan hệ rất xa với CNTT. Về vấn đề này, tôi quyết định giải thích bằng những thuật ngữ đơn giản Scrum nghĩa là gì. Vì vậy, các quý ông theo Scrum đừng phán xét tôi khắt khe.

Scrum (Scrum) không phải là viết tắt, thuật ngữ này được lấy từ môn bóng bầu dục, có nghĩa là cuộc chiến xung quanh trái bóng tròn.

Bản thân thuật ngữ Scrum, tôi sẽ định nghĩa như sau, là một phương pháp luận quản lý dự án được xây dựng dựa trên các nguyên tắc quản lý thời gian. Đặc điểm chính của nó là sự tham gia vào quá trình của tất cả những người tham gia và mỗi người tham gia có vai trò cụ thể của riêng mình. Điểm mấu chốt là không chỉ nhóm đang làm việc để giải quyết vấn đề, mà tất cả những người quan tâm đến việc giải quyết vấn đề không chỉ đặt nó và thư giãn, mà liên tục "làm việc" với nhóm, và công việc này không có nghĩa là duy nhất. kiểm soát liên tục.

Các thuật ngữ chính được sử dụng trong phương pháp luận là:

Chủ sở hữu sản phẩm - một người quan tâm trực tiếp đến sản phẩm cuối cùng có chất lượng, anh ta hiểu sản phẩm này trông như thế nào / hoạt động như thế nào. Người này không làm việc theo nhóm, anh ta làm việc về phía khách hàng / khách hàng (có thể là công ty khác hoặc bộ phận khác), nhưng người này làm việc theo nhóm. Và đây là người ưu tiên các nhiệm vụ.

Đội sản xuất - đây là một người có thể được gọi là giám đốc dự án, mặc dù điều này không hoàn toàn đúng. Vấn đề chính là đây là một người “bị nhiễm trực khuẩn Scrum” đến mức anh ta mang nó cho cả nhóm của mình và cho khách hàng, và do đó đảm bảo rằng tất cả các nguyên tắc Scrum đều được tuân thủ.

Nhóm Scrum là một nhóm chấp nhận tất cả các nguyên tắc Scrum và sẵn sàng làm việc với chúng.

tăng tốc - một khoảng thời gian được thực hiện để hoàn thành một danh sách các nhiệm vụ cụ thể (có giới hạn). Nên thực hiện 2-4 tuần (thời gian do nhóm xác định một lần).

Backlog (tồn đọng) là danh sách tất cả các công việc. Có thể nói đây là một cuốn nhật ký sử dụng chung 🙂

Có 2 loại tồn đọng: Product Backlog và Sprint Backlog.

Tồn đọng sản phẩm - đây là danh sách đầy đủ tất cả các công việc, trong quá trình thực hiện chúng ta sẽ có được sản phẩm cuối cùng.

Sprint backlog là danh sách công việc mà nhóm đã xác định và thống nhất với Product Owner cho kỳ báo cáo tiếp theo (sprint). Các nhiệm vụ trong sprint backlog được lấy từ product backlog.

kế hoạch nước rút là một cuộc họp có sự tham gia của tất cả mọi người (nhóm, Scrum Master, Product Owner). Trong cuộc họp này, Product Owner ưu tiên các nhiệm vụ mà anh ấy muốn thấy đã hoàn thành vào cuối sprint. Theo thời gian, nhóm sẽ đánh giá xem họ có thể hoàn thành được bao nhiêu phần trăm mong muốn. Kết quả là một danh sách các nhiệm vụ không thể thay đổi trong suốt sprint và phải được hoàn thành đầy đủ vào cuối sprint.

Tôi sẽ cố gắng giải thích tất cả điều này bằng cách sử dụng ví dụ về công việc của một cơ quan PR, nó sẽ như thế nào nếu họ làm việc theo Scrum.

Công ty khách hàng "X" muốn tổ chức một sự kiện quy mô lớn cho các đối tác và nhà báo của mình trong 2 tháng. Công ty "X" đã đặt hàng dịch vụ tổ chức một sự kiện như vậy từ đại lý "Z". Công ty "X" được đại diện bởi người quản lý PR, người chịu trách nhiệm tổ chức sự kiện thay mặt cho khách hàng. Trong thuật ngữ Scrum, người này được gọi là Chủ sở hữu sản phẩm. Về phía đại lý, người quản lý tài khoản chịu trách nhiệm tổ chức sự kiện ( Đội sản xuất), phụ thuộc vào lệnh ( Nhóm Scrum). Tại một cuộc họp chung kế hoạch nước rút) công ty và cơ quan quyết định rằng họ sẽ báo cáo kế hoạch 2 tuần một lần ( chiều dài nước rút). Trong 2 tuần đầu tiên, họ đã lên kế hoạch cho một danh sách các nhiệm vụ ( Sprint backlog), tuy nhiên, nhóm ước tính rằng họ sẽ không thể hoàn thành tất cả danh sách này. Sau đó là giám đốc PR (hay còn gọi là Chủ sở hữu sản phẩm), cho biết danh sách nhiệm vụ nào được ưu tiên hơn trong 2 tuần tới, sau đó nhóm sẽ nhận nhiệm vụ. Điều duy nhất cần lưu ý ở đây là tại thời điểm lập kế hoạch cho sprint đầu tiên, nên lập kế hoạch toàn bộ danh sách nhiệm vụ cho 2 tháng ( tồn đọng sản phẩm), để không xảy ra trường hợp đến khi sự kiện được tổ chức, một cái gì đó vẫn chưa được hoàn thành.

Tóm lại, tôi muốn nói rằng thực ra còn nhiều thuật ngữ hơn nữa và toàn bộ phương pháp luận sâu hơn nhiều. Tôi hy vọng rằng tất cả những điều trên sẽ đủ để bổ sung ý tưởng đầu tiên 🙂

Scrum bằng ngôn ngữ đơn giản

"Trong tất cả những khó khăn mà NASA phải đối mặt khi đưa một người lên mặt trăng, điều khiển có lẽ là nhiệm vụ khó khăn nhất."

- Roger Launis, Nhà sử học NASA

Trong suốt lịch sử, nhân loại đã tích lũy một danh sách ấn tượng về các dự án phức tạp được thực hiện thành công. Từ việc xây dựng các Kim tự tháp ở Giza đến việc đưa một người lên mặt trăng, những nỗ lực táo bạo nhất của con người đã đòi hỏi sự phối hợp của hàng nghìn người. Và điều này ngụ ý một hệ thống quản lý dự án phức tạp.

Và mặc dù chỉ một số ít người trong chúng ta sẽ phải đối mặt với các nhiệm vụ tầm cỡ này, hầu hết độc giả của blog này sẽ trải nghiệm quản lý dự án theo cách này hay cách khác. Đến năm 2020, các PMI được ước tính sẽ ở đó - và nhiều chuyên gia khác thường phải quản lý các dự án nhỏ, ít nhất là ở cấp độ cá nhân.

Nói một cách dễ hiểu, Quản lý dự án là tất cả về việc quản lý và tổ chức mọi thứ cần thiết để đạt được mục tiêu - tất nhiên là đúng thời gian và trong phạm vi ngân sách. Cho dù đó là phát triển phần mềm mới, chạy chiến dịch tiếp thị hay đưa người lên sao Hỏa, quản lý dự án đều có thể thành công.

Tất cả các dự án đều khác nhau. Không có hệ thống quản lý dự án hoàn hảo cho mọi loại dự án. Ngoài ra, không có hệ thống nào phù hợp với mọi nhà lãnh đạo và thuận tiện cho tất cả các thành viên trong nhóm. Tuy nhiên, trong quá trình tồn tại của quản lý dự án, nhiều cách tiếp cận, phương pháp và tiêu chuẩn hiệu quả đã được tạo ra có thể được áp dụng. Chúng tôi sẽ nói về chúng phổ biến nhất hiện nay.

Các phương pháp tiếp cận được phát triển rất khác nhau. Chúng khác nhau về phạm vi, chi tiết, mức độ tự túc và hình thức hóa. Trong tiêu đề, chúng tôi gọi chúng là "phương pháp" cho thuận tiện, nhưng trên thực tế, bài báo trình bày các tiêu chuẩn, khái niệm, phương pháp và khuôn khổ được sử dụng trong quản lý dự án. Mục đích của bài viết này là cung cấp cái nhìn tổng quan nhất về các cách tiếp cận hiện có trong quản lý dự án.

Trong bài viết này, chúng ta sẽ xem xét:

• Quản lý dự án cổ điển
• Nhanh nhẹn
• Scrum
• Độ nghiêng
• Kanban
• SáuSigma
• PRINCE2

Và trước khi xem xét các phương pháp cụ thể, hãy trả lời câu hỏi rõ ràng - "Tại sao chúng ta cần các hệ thống và phương pháp quản lý dự án?"- Tất nhiên, chúng ta hãy xem xét ngắn gọn lịch sử của quản lý dự án và xác định các thuật ngữ cơ bản của quản lý dự án.

Tại sao lại là "quản lý dự án"?

Tên tuổi của Neil Armstrong và Buzz Aldrin sẽ mãi mãi đi vào lịch sử như biểu tượng của một trong những thành tựu vĩ đại nhất của nhân loại - hạ cánh con người lên mặt trăng. Tuy nhiên, những người đóng góp chính cho sự kiện này là 400.000 nhân viên NASA và 20.000 công ty và trường đại học đã làm việc cùng nhau trong sứ mệnh Apollo.

Năm 1961, John F. Kennedy đặt nhiệm vụ hạ cánh một người đàn ông lên vệ tinh của Trái đất và đưa anh ta trở lại - mặc dù thực tế là vào thời điểm đó NASA đã đưa một người lên vũ trụ chỉ trong 15 phút. Một mục tiêu đầy tham vọng như vậy đòi hỏi một lượng lớn nguồn lực, sự hợp tác, đổi mới và lập kế hoạch.

Như cuốn sách Quản lý Chương trình Mặt trăng của NASA đã nêu, vấn đề chính không phải là “ phải làm gì? " và trong đó, " làm thế nào để làm được nhiều như vậy trong một thời gian ngắn? Theo Tiến sĩ Max Faget, trưởng bộ phận kỹ thuật tại Trung tâm Không gian Lyndon Johnson (Trung tâm vũ trụ Lyndon B. Johnson, JSC), NASA không biết làm thế nào để thực hiện tất cả các hành động cần thiết trong 10 năm. Vì vậy, bước đầu tiên là "chia nhỏ dự án thành các bước có thể quản lý được."

Sau đó, điều quan trọng là phải tăng tốc độ thực hiện từng giai đoạn riêng lẻ và đảm bảo rằng các nhóm và công ty làm việc trong từng giai đoạn giao tiếp hiệu quả với nhau và mang lại kết quả đúng thời hạn. Nhiệm vụ này được giao cho Tiến sĩ George E. Muller, người quản lý mọi bộ phận của dự án Apollo, từ Nhà Trắng đến nhà cung cấp bộ phận nhỏ nhất. Để dễ dàng kiểm soát dự án hơn, ông quyết định chia dự án thành 5 lĩnh vực: Kiểm soát chương trình, Kỹ thuật hệ thống, Thử nghiệm, Độ tin cậy và chất lượng, và Hoạt động bay. Sơ đồ điều khiển cho chương trình Apollo được thể hiện trong Hình 1.

Hệ thống 5 giai đoạn này - được gọi là "Các giai đoạn GEM" theo tên viết tắt của Tiến sĩ Muller - được thiết kế "tập trung vào việc thử nghiệm sản phẩm và phát triển sản phẩm với kiến ​​thức rằng nó sẽ được thử nghiệm", như chính Muller lưu ý. Kiểm soát Chương trình xác định những gì cần phải được thực hiện, quản lý ngân sách và các yêu cầu cũng như quản lý mối quan hệ của các yếu tố trong chương trình. Hệ thống Kỹ thuật chịu trách nhiệm phát triển các thiết bị và cụm lắp ráp mới, Kiểm tra chịu trách nhiệm đảm bảo rằng các yếu tố mới này hoạt động, Độ tin cậy và Chất lượng kiểm tra các yếu tố đã phát triển để tuân thủ các yêu cầu và tiêu chuẩn và Hoạt động bay chịu trách nhiệm đảm bảo rằng các nút này sẽ hoạt động trong suốt chuyến bay.

Ban đầu, nhiều người nghi ngờ phương pháp của Muller, nhưng cuối cùng ông đã thuyết phục được các thành viên của chương trình về sự cần thiết phải tuân theo thuật toán này. Hệ thống này đã cho thấy hiệu quả của nó - dự án đã được hoàn thành thành công, và người ta thậm chí có thể nói một cách đắc thắng, trước thời hạn đã nêu. Điều này chỉ có thể thực hiện được bằng cách chia nhỏ một dự án quy mô lớn thành các bước có thể quản lý và lặp lại được, cho phép nhiều công ty và chuyên gia riêng lẻ làm việc cùng một tốc độ. Đây là cách quản lý dự án chứng minh tính hiệu quả của nó trong Cuộc đua không gian.

Sơ lược về lịch sử quản lý dự án

Quản lý dự án không được phát minh bởi NASA và Tiến sĩ Muller. Các kim tự tháp Ai Cập và Vạn Lý Trường Thành của Trung Quốc là sản phẩm của việc quản lý dự án từ thời tiền sử. Thật không may, không có bằng chứng tài liệu nào về việc thực hiện và quản lý các dự án này đã diễn ra như thế nào, và việc quản lý dự án hiện tại khác với kiến ​​thức của nhiều thế kỷ trước.

Cách rõ ràng nhất để thực hiện một dự án là chia nó thành các giai đoạn hoặc các nhiệm vụ riêng lẻ. Giống như một công thức, bạn mua các nguyên liệu, trộn chúng đúng cách, nấu và phục vụ chúng. Công cụ quản lý dự án đơn giản nhất là danh sách kiểm tra các hành động phải thực hiện để đạt được mục tiêu. Đơn giản và hiệu quả.

Tuy nhiên, nếu bạn là một đầu bếp và bạn đang chuẩn bị nhiều món ăn, nhưng một vài món, chẳng hạn như salad (bao gồm 3 công đoạn) và món tráng miệng (chỉ cần phục vụ), thì bạn sẽ cần một công cụ cho phép bạn theo dõi thời gian dành cho từng mục và khi nào chúng nên sẵn sàng. Và đây là một trong những công cụ quản lý dự án hiện đại đầu tiên đã giải cứu được: biểu đồ Gantt, được trình bày trên Hình 2.

Được phát minh độc lập bởi K Về Trong vai trò của Korol Adamecki và Henry L. Gantt vào đầu thế kỷ 20, biểu đồ Gantt hiển thị lịch trình của dự án dựa trên ngày đến hạn và ngày đến hạn cho các nhiệm vụ. Các nhiệm vụ, thời lượng và mối quan hệ của chúng được nhập vào đó, và sau đó đường dẫn quan trọng được tính toán - chuỗi dài nhất các nhiệm vụ được kết nối với nhau quyết định thời gian của dự án. Mối quan hệ giữa việc bắt đầu và kết thúc các nhiệm vụ khác nhau là rất quan trọng - bạn không thể phục vụ món súp cho khách của mình cho đến khi bạn đã nấu xong, phải không?

Vì vậy, một dự án điển hình rất giống với một dự án nấu ăn và phục vụ bữa tối, chỉ khác là nó có nhiều nhiệm vụ, mối quan hệ, thời hạn và các loại tài nguyên hơn. Đối với các dự án có thời hạn chặt chẽ, biểu đồ Gantt giúp quyết định thời điểm tốt hơn để bắt đầu một số nhiệm vụ nhất định để giảm thời gian thực hiện. Và đối với các dự án có hạn chế về nguồn lực mạnh, biểu đồ Gantt cung cấp cơ hội để xây dựng một lược đồ dưới dạng một chuỗi quy trình hướng sự kiện để lập kế hoạch nguồn lực.

Các dự án khác nhau cần mức độ kiểm soát khác nhau. Ví dụ, nếu bạn đang xuất bản một loạt bài báo, thì thời hạn chặt chẽ không quan trọng lắm. Quan trọng hơn nhiều là một quy trình rõ ràng, trong đó có thể cấu trúc từng bài báo, phác thảo từng bài báo, nhận phản hồi, chỉnh sửa, hoàn thành bài báo, hiệu đính và xuất bản. Thay vì quản lý thời gian và tài nguyên, bạn quản lý quy trình.

Các phương pháp quản lý dự án Agile và các phương pháp tiếp cận liên quan như Lean, Kanban, và các phương pháp khác phù hợp hơn cho các dự án như vậy. Ngoài ra còn có các phương pháp cho phép bạn quản lý cả quy trình làm việc lẫn thời gian và tài nguyên - 6 Sigma và Scrum.

Các hệ thống quản lý dự án phổ biến

Trong suốt lịch sử của quản lý dự án, nhiều phương pháp quản lý dự án khác nhau đã được tạo ra cho hầu hết mọi nhu cầu. Ngay cả khi bạn không gửi một người đàn ông lên mặt trăng và không có một lượng tài nguyên tương tự, bạn vẫn sẽ tìm thấy công cụ phù hợp cho mình. Điều chính là hiểu điều gì là quan trọng nhất đối với dự án của bạn - thời hạn, nguồn lực, tuân thủ quy trình hoặc một số yếu tố cùng một lúc - và sau đó chọn phương pháp quản lý dự án tập trung vào việc đạt được chỉ số này.

Trước khi bắt đầu xem xét các phương pháp phổ biến nhất, chúng ta hãy xác định một số thuật ngữ chính.

Các điều khoản cơ bản về quản lý dự án

Nhanh nhẹn Một cách tiếp cận linh hoạt lặp đi lặp lại-gia tăng đối với quản lý dự án và sản phẩm tập trung vào việc hình thành năng động các yêu cầu và đảm bảo việc thực hiện chúng là kết quả của sự tương tác liên tục trong các nhóm làm việc tự tổ chức bao gồm các chuyên gia của nhiều hồ sơ khác nhau. Có nhiều phương pháp dựa trên các ý tưởng của Agile, trong đó phổ biến nhất là Scrum và Kanban.

Đường dẫn tới hạn: Một chuỗi các hoạt động và sự kiện liên tục từ đầu đến cuối mất nhiều thời gian nhất để hoàn thành.

Chuỗi quy trình sự kiện (Sơ đồ EPC): một sơ đồ thể hiện trình tự thực hiện công việc dự án dựa trên sự sẵn có và khối lượng công việc của các nguồn lực

Dự trữ thời gian: Khoảng thời gian mà việc bắt đầu công việc có thể bị trì hoãn mà không ảnh hưởng đến toàn bộ thời gian của dự án. Do đó, sự chùng xuống cho các hoạt động trên con đường quan trọng sẽ bằng không.

cột mốc (trạm kiểm soát,cột mốc): Ví dụ: một sự kiện quan trọng đánh dấu sự kết thúc của một giai đoạn. Trong biểu đồ Gantt, nó được biểu thị bằng một nhiệm vụ có thời lượng bằng không.

Quản lý dự án (trưởng dự án,dự ánngười quản lý,BUỔI CHIỀU ): Trưởng nhóm dự án chịu trách nhiệm quản lý dự án (lập kế hoạch, thực hiện và kết thúc dự án).

Tài nguyên: Các yếu tố cần thiết cho việc thực hiện dự án. Nguồn lực là thời gian, thiết bị, vật liệu, nhân viên, v.v.

Tăng tốc (Tăng tốc): Lặp lại (chu kỳ làm việc) trong Scrum, kéo dài từ một tuần đến một tháng, trong đó phiên bản làm việc của sản phẩm hoặc phần tử của nó được tạo ra có giá trị đối với khách hàng.

Quản lý dự án "cổ điển" hoặc "truyền thống": Phương pháp quản lý dự án được sử dụng rộng rãi nhất, dựa trên cái gọi là "Thác nước" (Waterfall) hay chu trình xếp tầng, trong đó nhiệm vụ được chuyển tuần tự qua các giai đoạn, giống như một dòng chảy.

Quản lý dự án cổ điển

Cách rõ ràng nhất để làm cho dự án của bạn dễ quản lý hơn là chia nhỏ nó thành các bước liên tiếp. Đó là trên cấu trúc tuyến tính này mà quản lý dự án truyền thống được dựa trên. Theo nghĩa này, nó giống như một trò chơi máy tính - bạn không thể lên cấp độ tiếp theo mà không hoàn thành cấp độ trước đó. Sơ đồ quy trình làm việc được hiển thị trong Hình 3.

Cách tiếp cận này tập trung vào các dự án trong đó có những hạn chế nghiêm ngặt về trình tự các nhiệm vụ. Ví dụ, xây một ngôi nhà - bạn không thể xây tường mà không có móng.

Thông thường, có 5 giai đoạn quản lý dự án cổ điển, nhưng các giai đoạn bổ sung có thể được thêm vào nếu dự án yêu cầu.

5 giai đoạn của quản lý truyền thống:

Giai đoạn 1. Khởi xướng. Người quản lý dự án và nhóm xác định các yêu cầu cho dự án. Ở giai đoạn này, các cuộc họp và các buổi động não thường được tổ chức để xác định sản phẩm của dự án nên là gì.

Giai đoạn 2. Lập kế hoạch.Ở giai đoạn này, nhóm quyết định làm thế nào để đạt được mục tiêu đã đặt ra trong giai đoạn trước. Ở giai đoạn này, nhóm nghiên cứu sàng lọc và chi tiết hóa các mục tiêu và kết quả của dự án, cũng như phạm vi công việc của dự án. Dựa trên thông tin này, nhóm tạo ra một lịch trình và ngân sách, đánh giá rủi ro và xác định các bên liên quan.

Giai đoạn 3. Phát triển. Giai đoạn này không được thực hiện cho tất cả các dự án - theo quy luật, nó là một phần của giai đoạn lập kế hoạch. Trong giai đoạn phát triển, đặc điểm của các dự án công nghệ, cấu hình của dự án và / hoặc sản phẩm trong tương lai và các phương tiện kỹ thuật để đạt được nó được xác định. Ví dụ, trong các dự án CNTT, một ngôn ngữ lập trình được chọn ở giai đoạn này. ( Trong thực tế trong nước, giai đoạn này thường không được phân biệt và thuật ngữ "phát triển" không được sử dụng - ước chừng. Dịch.)

Giai đoạn 4. Thực hiện và thử nghiệm.Ở giai đoạn này, công việc chính của dự án thực sự diễn ra - viết mã, lắp dựng một tòa nhà, và những thứ tương tự. Sau các kế hoạch đã phát triển, nội dung của dự án, được xác định trước đó, bắt đầu được tạo, kiểm soát được thực hiện theo các số liệu đã chọn. Trong phần thứ hai của giai đoạn này, sản phẩm được thử nghiệm, kiểm tra sự phù hợp với các yêu cầu của Khách hàng và các bên quan tâm. Về mặt thử nghiệm, các khiếm khuyết của sản phẩm được xác định và sửa chữa.

Giai đoạn 5. Giám sát và hoàn thành dự án. Tùy thuộc vào dự án, giai đoạn này có thể bao gồm việc chuyển giao kết quả dự án đơn giản cho Khách hàng hoặc một quá trình tương tác kéo dài với khách hàng để cải thiện dự án và tăng sự hài lòng của họ cũng như hỗ trợ kết quả của dự án. Sau đó đề cập đến các dự án trong lĩnh vực dịch vụ khách hàng và phần mềm.

Những gì được mô tả ở trên là cơ sở mà các phương pháp quản lý dự án khác nhau được xây dựng. Các dự án khác nhau cần các giai đoạn thực hiện khác nhau - một số cần ba giai đoạn, những dự án khác nhiều hơn nữa. Đôi khi cái gọi là "thác nước lặp đi lặp lại" được sử dụng, trong đó mỗi giai đoạn là một loại dự án con, trong đó các nhiệm vụ được thực hiện theo các lần lặp cố định. Nhưng bản chất vẫn giống nhau - dự án được chia thành các giai đoạn được thực hiện theo một trình tự được xác định chặt chẽ.

Do thực tế là quản lý dự án cổ điển bị ràng buộc chặt chẽ với thời gian thực hiện nhiệm vụ, như một quy luật, được xác định trước ở giai đoạn lập kế hoạch, nên các công cụ lập kế hoạch mạng lịch là tuyệt vời để thực hiện các dự án trong khuôn khổ của cách tiếp cận này. Công cụ lập lịch phổ biến nhất là biểu đồ Gantt đã đề cập trước đây. Có rất nhiều công cụ để xây dựng nó, từ các bảng tính đơn giản như Excel và Smartsheet đến các gói phần mềm chuyên nghiệp như Microsoft Project và Primavera.

Điểm mạnh của quản lý dự án cổ điển

Ngày nay, người ta thường cho rằng cách tiếp cận thác nước cổ điển đã lỗi thời, nhưng anh ấy thậm chí không nghĩ đến việc mất đất. Ưu điểm lớn của cách tiếp cận này là nó yêu cầu Khách hàng và ban quản lý công ty xác định những gì họ muốn nhận được ở giai đoạn đầu tiên của dự án. Việc đưa vào sớm mang lại sự ổn định nhất định cho công việc của dự án và việc lập kế hoạch cho phép bạn sắp xếp hợp lý việc thực hiện dự án. Ngoài ra, cách tiếp cận này liên quan đến việc giám sát các chỉ số và thử nghiệm, điều này hoàn toàn cần thiết cho các dự án thực tế ở nhiều quy mô khác nhau.

Về mặt tiềm năng, phương pháp cổ điển tránh được căng thẳng do có thời gian rảnh rỗi ở mỗi giai đoạn, được bố trí trong trường hợp có bất kỳ biến chứng nào và việc thực hiện rủi ro. Ngoài ra, với một giai đoạn lập kế hoạch được tiến hành đúng đắn, người quản lý dự án luôn biết mình có những nguồn lực nào. Ngay cả khi ước tính này không phải lúc nào cũng chính xác.

Điểm yếu của quản lý dự án cổ điển

Điểm yếu chính của quản lý dự án cổ điển là không chịu thay đổi. Ban lãnh đạo của Toyota, nổi tiếng với việc tạo ra các hệ thống như Lean và Kanban, thường bị chỉ trích vì áp dụng cách tiếp cận cổ điển để phát triển phần mềm cho công ty của họ, và thiếu tính linh hoạt.

Trụ cột của cách tiếp cận cổ điển hiện nay là các dự án xây dựng và kỹ thuật, trong đó nội dung của dự án hầu như không thay đổi trong toàn bộ dự án. Nhưng nếu nguồn lực và thời gian không phải là những ràng buộc chính trong dự án của bạn và phạm vi của dự án có thể thay đổi, bạn có thể cần phải xem xét các hệ thống quản lý dự án khác.

Nhanh nhẹn

Như đã đề cập trước đó, không phải tất cả các dự án đều có thể được cấu trúc theo cách được thực hiện theo cách tiếp cận dự án cổ điển. Quay trở lại ví dụ về đầu bếp của chúng tôi, nấu một món ăn là hoàn hảo cho cách tiếp cận thác nước, nhưng việc chuẩn bị và phục vụ bữa tối bốn món đúng giờ sẽ là điều không thể nếu bạn phải đợi mỗi lần nấu xong một món trước khi bắt đầu món khác.

Và đây là lúc Agile phát huy tác dụng - một nhóm các phương pháp gia tăng lặp đi lặp lại linh hoạt để quản lý các dự án và sản phẩm. Theo cách tiếp cận này, dự án không được chia thành các giai đoạn kế tiếp nhau, mà thành các tiểu dự án nhỏ, sau đó được “lắp ráp” thành một sản phẩm hoàn chỉnh. Kế hoạch làm việc được hiển thị trên Hình 5.

Do đó, khởi đầu và lập kế hoạch cấp cao nhất được thực hiện cho toàn bộ dự án, và các giai đoạn tiếp theo: phát triển, thử nghiệm và các giai đoạn khác được thực hiện cho từng dự án nhỏ riêng biệt. Điều này cho phép bạn chuyển các kết quả của các dự án nhỏ này, cái gọi là phần tăng dần, nhanh hơn và khi bắt đầu một dự án con mới (lặp lại), bạn có thể thực hiện các thay đổi đối với nó mà không tốn kém chi phí cao và ảnh hưởng đến phần còn lại của dự án .

Mặc dù thực tế là Agile đã trở nên thịnh hành gần đây, nhưng ý tưởng về phát triển lặp đi lặp lại không phải là mới. (về lịch sử xuất hiệnAgile có thể được đọc - xấp xỉ mỗi.). Dòng phương pháp nhanh nhẹn có tên hiện tại vào năm 2001 với việc xuất bản Tuyên ngôn Agile (Agile Manifesto), trong đó hợp nhất các giá trị và nguyên tắc cốt lõi của phát triển phần mềm nhanh nhẹn, dựa trên tinh thần làm việc nhóm và thích ứng, thậm chí là “tình yêu” đối với biến đổi.

Bản thân Agile không phải là một phương pháp quản lý dự án. Nó đúng hơn là một tập hợp các ý tưởng và nguyên tắc về cách các dự án nên được thực hiện. Trên cơ sở các nguyên tắc và thực tiễn tốt nhất này, các phương pháp linh hoạt riêng biệt hoặc như đôi khi chúng được gọi là các khuôn khổ đã được phát triển: Scrum, Kanban, Crystal, và nhiều phương pháp khác. Những phương pháp này có thể khá khác biệt với nhau, nhưng chúng tuân theo các nguyên tắc giống nhau.

Điểm mạnhNhanh nhẹn

Ưu điểm quan trọng nhất của Agile là tính linh hoạt và khả năng thích ứng. Nó có thể thích ứng với hầu hết mọi điều kiện và quy trình của tổ chức. Đây là yếu tố quyết định sự phổ biến hiện tại của nó và có bao nhiêu hệ thống cho các lĩnh vực khác nhau đã được tạo ra dựa trên nó.

Một trong những nguyên tắc của Agile là: "Đáp ứng với sự thay đổi quan trọng hơn là tuân theo một kế hoạch." Đó là lý do tại sao nhiều công ty lớn cố gắng làm cho các quy trình của họ trở nên linh hoạt hơn. Ngoài ra, Agile rất tốt cho các dự án mở như bắt đầu một dịch vụ hoặc blog.

Lĩnh vực của Agile là sự phát triển của các sản phẩm mới, sáng tạo. Trong các dự án phát triển các sản phẩm như vậy, có mức độ không chắc chắn cao và thông tin về sản phẩm được tiết lộ trong quá trình thực hiện dự án. Trong điều kiện như vậy, việc triển khai dự án trên “thác nước” là không thể - không có thông tin quy hoạch.

Mặt yếuNhanh nhẹn

Không giống như PRINCE2 và PMBOK, Agile không phải là một phương pháp luận cũng không phải là một tiêu chuẩn. Agile là một tập hợp các nguyên tắc và giá trị. Mặt yếu là mỗi nhóm sẽ phải độc lập xây dựng hệ thống quản lý của riêng mình, được hướng dẫn bởi các nguyên tắc của Agile. Đây là một quá trình phức tạp và kéo dài, đòi hỏi những thay đổi trong toàn bộ tổ chức, từ các thủ tục đến các giá trị cốt lõi. Đây là một con đường đầy chông gai và không phải tổ chức nào cũng làm được.

Con đường này sẽ đòi hỏi từ người dẫn đầu sự thay đổi không chỉ kiến ​​thức và sự kiên trì, mà còn cả nguồn lực hành chính nghiêm túc, cũng như chi phí. May mắn thay, có những bộ thực hành được tạo sẵn giúp một tổ chức dễ dàng chuyển đổi Agile. Những bộ này bao gồm khung Scrum, phương pháp Kanban và nhiều bộ khác - Crystal, LeSS, SAFe, Nexus.

Scrum

Khung nhanh nhẹn, được tạo ra vào năm 1986, được coi là có cấu trúc nhất trong gia đình Agile. Được tạo ra vào năm 1986, nó kết hợp các yếu tố của quy trình cổ điển và những ý tưởng về cách tiếp cận nhanh nhẹn để quản lý dự án. Kết quả là sự kết hợp rất cân bằng giữa tính linh hoạt và cấu trúc.

Tuân theo các nguyên tắc của Agile, Scrum chia dự án thành các phần mà Khách hàng có thể sử dụng ngay lập tức để thu được giá trị, được gọi là tồn đọng sản phẩm. Và mặc dù thực tế là “product backlog” là một bản dịch khá chính xác và được sử dụng trong các tài liệu chuyên nghiệp, trong thực tế của Nga, chỉ đơn giản là “backlog” được sử dụng nhiều nhất. Sau đó những phần này được Product Owner - đại diện của Khách hàng trong nhóm ưu tiên thực hiện. Các "phần" quan trọng nhất là những phần đầu tiên được chọn để thực hiện trong Sprint - cái gọi là các bước lặp lại trong Scrum, kéo dài từ 2 đến 4 tuần. Vào cuối Sprint, Khách hàng được giới thiệu một phần gia tăng sản phẩm đang hoạt động - những "phần" quan trọng nhất đã có thể được sử dụng. Ví dụ: một trang web có một phần chức năng hoặc một chương trình đã hoạt động, mặc dù một phần. Sau đó, nhóm dự án tiến hành Sprint tiếp theo. Thời gian của Sprint là cố định, nhưng nhóm chọn nó một cách độc lập khi bắt đầu dự án, dựa trên dự án và hiệu suất của chính nó.

Để đảm bảo rằng dự án đáp ứng các yêu cầu của Khách hàng, có xu hướng thay đổi theo thời gian, trước khi bắt đầu mỗi Sprint, phạm vi dự án chưa được hoàn thành sẽ được đánh giá lại và thực hiện các thay đổi đối với phạm vi đó. Mọi người đều tham gia vào quá trình này - nhóm dự án, Scrum Master (Scrum Master, trưởng nhóm dự án) và Product Owner. Và mọi người đều phải chịu trách nhiệm cho quá trình này.

Như đã đề cập, Product Owner là đại diện của Khách hàng trong dự án hoặc nhân cách hóa tất cả các khách hàng của dự án tương lai, nếu Khách hàng không có mặt. Để làm được điều này, anh ta phải tìm hiểu kỹ nhu cầu và cách suy nghĩ của họ, cũng như hiểu rõ về sản phẩm và công nghệ sản xuất của nó. Scrum Master được thiết kế để giúp những người tham gia dự án hiểu rõ hơn và chấp nhận các giá trị, nguyên tắc và chuẩn mực của việc thực hành Scrum. Anh ấy là người lãnh đạo và trung gian giữa thế giới bên ngoài và đội bóng. Nhiệm vụ của anh ấy là đảm bảo rằng không ai can thiệp vào đội của họ và thoải mái làm việc với các nhiệm vụ. Nhóm chịu trách nhiệm đảm bảo rằng vào cuối sprint, tất cả các nhiệm vụ cần thiết được hoàn thành và việc giao hàng được hoàn thành.

Cấu trúc cơ bản của các quy trình Scrum xoay quanh 5 cuộc họp chính: Backlog Sequences, Sprint Planning, Sprint Meetings, Sprint Debriefing và Sprint Retrospective.

Đối với nhiều người, Scrum có vẻ khó thực hiện - một quy trình mới, vai trò mới, nhiều ủy quyền và một cơ cấu tổ chức hoàn toàn mới. Nhưng đó là một cách tiếp cận linh hoạt nhưng có cấu trúc để phân phối dự án, không giống như các nguyên tắc mơ hồ và chung chung của Agile, sẽ không để xảy ra sai sót.

Điểm mạnhScrum

Scrum được thiết kế cho các dự án yêu cầu "thắng nhanh" kết hợp với khả năng thay đổi. Ngoài ra, khuôn khổ này phù hợp với các tình huống mà không phải tất cả các thành viên trong nhóm đều có đủ kinh nghiệm trong lĩnh vực mà dự án đang được thực hiện - giao tiếp liên tục giữa các thành viên trong nhóm cho phép một số nhân viên thiếu kinh nghiệm hoặc trình độ do thông tin và sự giúp đỡ từ đồng nghiệp .

Kênh truyền hình trực tuyến Netflix là một ví dụ tuyệt vời về việc cung cấp kết quả một cách nhanh chóng. Trang web tài nguyên được cập nhật hai tuần một lần nhờ Scrum, không chỉ cho phép bạn làm việc với tốc độ cao mà còn tích lũy kinh nghiệm người dùng và giúp bạn có thể xác định điều quan trọng nhất đối với khách hàng.

Trong mỗi lần lặp lại, các nhà phát triển thêm và thử nghiệm các tính năng mới của trang web và xóa những tính năng không được khách hàng sử dụng. Theo nhóm Netflix, ưu điểm chính của Scrum là nó cho phép bạn "thất bại nhanh chóng". Thay vì một bản phát hành chính dài và tốn kém, các bản phân phối scrum có quy mô nhỏ. Chúng rất dễ theo dõi và nếu có vấn đề gì xảy ra, hãy nhanh chóng sửa chữa.

Mặt yếuScrum

Scrum yêu cầu rất cao đối với nhóm dự án. Nó phải có quy mô nhỏ (5-9 người) và đa chức năng - nghĩa là các thành viên trong nhóm phải có nhiều hơn một năng lực cần thiết để thực hiện dự án. Ví dụ, một nhà phát triển phần mềm phải có kiến ​​thức về thử nghiệm và thông minh kinh doanh. Điều này được thực hiện để một phần của nhóm không "nhàn rỗi" ở các giai đoạn khác nhau của dự án, cũng như để các nhân viên có thể giúp đỡ và thay thế lẫn nhau.

Ngoài ra, các thành viên trong nhóm phải là “người chơi đồng đội”, chủ động chịu trách nhiệm và có khả năng tự tổ chức. Tìm được một đội trưởng thành như vậy là rất khó!

Scrum không phù hợp với tất cả các nhóm và tổ chức cũng vì quy trình được đề xuất có thể không phù hợp với sự phát triển của một sản phẩm cụ thể - ví dụ: máy công nghiệp hoặc xây dựng một tòa nhà.

Độ nghiêng

Agile cho chúng ta biết những gì nên chia thành các gói công việc nhỏ, có thể quản lý được, nhưng nó không nói gì về cách quản lý sự phát triển của gói này. Scrum cung cấp cho chúng tôi các quy trình và thủ tục của nó. Lean, đến lượt nó, thêm một sơ đồ quy trình làm việc theo các nguyên tắc của Agile để mỗi lần lặp lại được thực hiện với chất lượng như nhau.

Trong Lean, cũng giống như trong Scrum, công việc được chia thành các gói phân phối nhỏ được thực hiện riêng biệt và độc lập. Nhưng trong Lean, để phát triển mỗi gói giao hàng, có một quy trình làm việc với các bước tương tự như những bước được tạo cho dự án Apollo. Như trong quản lý dự án cổ điển, đây có thể là các giai đoạn lập kế hoạch, phát triển, sản xuất, thử nghiệm và giao hàng - hoặc bất kỳ giai đoạn nào khác cần thiết cho việc thực hiện chất lượng của các dự án.

Các giai đoạn tinh gọn và tính linh hoạt của chúng cho phép bạn chắc chắn rằng từng phần của dự án được thực hiện theo yêu cầu. Lean không có ranh giới giai đoạn rõ ràng, như Scrum làm với các giới hạn của Sprint. Ngoài ra, không giống như quản lý dự án cổ điển, Lean cho phép bạn thực hiện song song một số nhiệm vụ ở các giai đoạn khác nhau, giúp tăng tính linh hoạt và tăng tốc độ thực hiện dự án.

Giống như Agile, Lean là một khái niệm, một cách suy nghĩ hơn là một thứ gì đó được sắp đặt sẵn trong đá. Sử dụng các ý tưởng của Lean, bạn có thể độc lập tạo ra một hệ thống đáp ứng các yêu cầu của bạn trong quản lý dự án.

Điểm mạnhĐộ nghiêng

Nếu bạn thích ý tưởng Agile, nhưng dự án đòi hỏi chất lượng rất trơn tru và thực thi chính xác, Lean cung cấp một bộ công cụ để đáp ứng những yêu cầu này. Lean kết hợp tính linh hoạt và cấu trúc giống như Scrum, nhưng theo một cách hơi khác.

Mặt yếuĐộ nghiêng

Không phải mọi phần của dự án đều yêu cầu sự nghiên cứu và chú ý chi tiết, tỉ mỉ như nhau. Nhưng Lean giả định chính xác cách tiếp cận này cho từng nhiệm vụ và giai đoạn. Đây là nhược điểm chính của việc sử dụng Lean cho các dự án lớn và không đồng nhất.

Ngoài ra, không giống như Scrum, Lean không đưa ra quy trình làm việc rõ ràng để thực hiện các “phần” của dự án, điều này góp phần kéo dài thời gian của dự án. Vấn đề này có thể được giải quyết với sự lãnh đạo hiệu quả và thông tin liên lạc rõ ràng - điều chính cần nhớ là điều này.

Kanban

Bản thân Lean có vẻ hơi trừu tượng, nhưng khi kết hợp với Kanban, việc sử dụng nó để xây dựng hệ thống quản lý dự án của riêng bạn trở nên dễ dàng hơn nhiều. Được tạo ra bởi kỹ sư Taiichi Ono của Toyota vào năm 1953, Kanban rất giống với sản xuất công nghiệp. Tại lối vào của quá trình này, một mảnh kim loại đi vào, và phần hoàn thiện sẽ thu được ở lối ra. Cũng trong Kanban, sản phẩm gia tăng được chuyển tiếp từ giai đoạn này sang giai đoạn khác và cuối cùng, sẽ có được một mặt hàng sẵn sàng giao hàng.

Ngoài ra, người tạo ra Kanban đã lấy cảm hứng từ các siêu thị, cụ thể là nguyên tắc của họ - "chỉ giữ trên kệ những gì khách hàng cần." Do đó, Kanban cho phép bạn để lại một nhiệm vụ chưa hoàn thành ở một trong các giai đoạn nếu mức độ ưu tiên của nó đã thay đổi và có những nhiệm vụ khẩn cấp khác. Một bài đăng trên blog chưa được chỉnh sửa, bị treo mà không có ngày xuất bản hoặc một đoạn mã cho một tính năng có thể không có trong sản phẩm là tất cả những điều bình thường đối với công việc Kanban.

Kanban ít nghiêm ngặt hơn nhiều so với Scrum - nó không giới hạn thời gian chạy nước rút, không có vai trò nào, ngoại trừ chủ sở hữu sản phẩm. Kanban thậm chí còn cho phép một thành viên trong nhóm thực hiện đa nhiệm vụ, điều mà Scrum không cho phép. Ngoài ra, các cuộc họp về tình trạng của dự án không được quy định theo bất kỳ cách nào - bạn có thể làm điều đó tùy thích hoặc bạn không thể làm điều đó.

Để làm việc với Kanban, bạn cần xác định các bước quy trình làm việc. Trong Kanban, chúng được hiển thị dưới dạng cột và các nhiệm vụ đại diện cho các thẻ đặc biệt. Thẻ di chuyển qua các giai đoạn, giống như một bộ phận trong nhà máy chuyển từ máy này sang máy khác và ở mỗi giai đoạn tỷ lệ hoàn thành cao hơn. Kết quả là, chúng tôi có được một yếu tố sản phẩm sẵn sàng để giao cho khách hàng. Một bảng với các cột và thẻ có thể là cả thực và điện tử - thậm chí ở đây Kanban không áp đặt bất kỳ hạn chế nào đối với người dùng.

Hệ thống Kanban của riêng bạn có thể linh hoạt như bạn muốn, bởi vì theo nhiều cách, Kanban là hình dung của ý tưởng Agile. Nhưng Kanban có 4 trụ cột mà toàn bộ hệ thống dựa vào:

1. Thẻ:Đối với mỗi nhiệm vụ, một thẻ riêng lẻ được tạo, trong đó tất cả các thông tin cần thiết về nhiệm vụ được nhập. Vì vậy, tất cả các thông tin cần thiết về nhiệm vụ luôn ở trong tầm tay.
2. Giới hạn về số lượng nhiệm vụ mỗi giai đoạn: Số lượng thẻ ở một giai đoạn được quy định chặt chẽ. Nhờ đó, nó trở nên rõ ràng ngay lập tức khi xảy ra “tắc nghẽn” trong quy trình làm việc, được loại bỏ kịp thời.
3. Dòng chảy liên tục: Các nhiệm vụ từ công việc tồn đọng được sắp xếp theo thứ tự ưu tiên. Vì vậy, công việc không bao giờ dừng lại.
4. Cải tiến liên tục (kaizen)kaizen)): Khái niệm cải tiến liên tục xuất hiện ở Nhật Bản vào cuối thế kỷ 20. Bản chất của nó là không ngừng phân tích quá trình sản xuất và tìm kiếm các biện pháp để nâng cao năng suất.

Điểm mạnhKanban

Giống như Scrum, Kanban rất phù hợp với các nhóm khá chặt chẽ với khả năng giao tiếp tốt. Nhưng không giống như Scrum, Kanban không có thời hạn khó khăn, điều này rất tốt cho các nhóm có năng lực và kinh nghiệm cao.

Khi được thiết lập và quản lý đúng cách, Kanban có thể mang lại giá trị to lớn cho một nhóm dự án. Một tính toán chính xác về tải trọng của nhóm, vị trí chính xác của các hạn chế và tập trung vào cải tiến liên tục - tất cả điều này cho phép Kanban tiết kiệm nghiêm túc tài nguyên và phù hợp với thời hạn và ngân sách. Và tất cả điều này kết hợp với sự linh hoạt.

Mặt yếuKanban

Bạn thường có thể nghe nói rằng Kanban, không giống như Scrum, có thể làm việc với hầu hết mọi nhóm. Nhưng nó không phải là như vậy. Kanban phù hợp nhất cho các nhóm có kỹ năng của các thành viên trùng lặp. Bằng cách này, họ có thể giúp nhau vượt qua khó khăn trong việc giải quyết vấn đề. Nếu không có điều này, Kanban sẽ không hiệu quả như mong đợi. Ngoài ra, như đã đề cập, Kanban phù hợp hơn trong những trường hợp không có thời hạn khó. Đối với thời hạn chặt chẽ, cách tiếp cận cổ điển hoặc Scrum phù hợp hơn.

6 sigma (Six Sigma)

Motorola, cùng với Toyota, cũng đã đóng góp vào sự phát triển của quản lý dự án toàn cầu. Bill Smith, một kỹ sư tại công ty này, đã tạo ra khái niệm 6 Sigma vào năm 1986. Đây là một phiên bản có cấu trúc hơn của Kanban, bổ sung thêm kế hoạch để tiết kiệm tài nguyên, cải thiện chất lượng và giảm phế liệu và các vấn đề.

Mục tiêu cuối cùng của dự án là sự hài lòng của khách hàng đối với chất lượng của sản phẩm, có thể đạt được thông qua một quá trình cải tiến liên tục về mọi mặt của dự án, dựa trên sự phân tích kỹ lưỡng các chỉ số. Trong khái niệm 6 sigma, đặc biệt chú ý đến việc loại bỏ các vấn đề mới nảy sinh.

Đối với điều này, một quy trình 5 bước được gọi là DMEDI đã được đề xuất:

• Sự định nghĩa (định nghĩa): Giai đoạn đầu tiên rất giống với giai đoạn đầu của các hệ thống quản lý dự án khác. Nó xác định nội dung của dự án, thu thập thông tin về các điều kiện tiên quyết của dự án, thiết lập các mục tiêu.
• Kích thước (đo lường): 6 Sigma tập trung vào việc thu thập và phân tích dữ liệu định lượng về dự án. Ở giai đoạn này, người ta xác định những chỉ số nào sẽ quyết định sự thành công của dự án và những dữ liệu nào cần được thu thập và phân tích.
• Nghiên cứu (Khám phá): Trong giai đoạn nghiên cứu, người quản lý dự án quyết định cách thức nhóm có thể đạt được mục tiêu và đáp ứng tất cả các yêu cầu về thời gian và trong phạm vi ngân sách. Ở giai đoạn này, tư duy phi tiêu chuẩn của người quản lý dự án trong việc giải quyết các vấn đề nảy sinh là rất quan trọng.
• Sự phát triển (Phát triển, xây dựng):Ở giai đoạn này, các kế hoạch và quyết định đã đưa ra ở giai đoạn trước đang được thực hiện. Điều quan trọng là phải hiểu rằng ở giai đoạn này, một kế hoạch chi tiết là cần thiết, trong đó mô tả tất cả các hành động cần thiết để đạt được các mục tiêu. Tiến độ của dự án cũng được đo lường ở giai đoạn này.
• Điều khiển (Điều khiển): Một cột mốc quan trọng trong phương pháp 6 Sigma. Mục tiêu chính của nó là cải tiến lâu dài các quy trình thực hiện dự án. Giai đoạn này đòi hỏi phải có tài liệu cẩn thận về các bài học kinh nghiệm, phân tích dữ liệu thu thập được và áp dụng kiến ​​thức thu được vào cả các dự án và toàn công ty nói chung.

6 Sigma rất giống với Kanban, chỉ với các giai đoạn được thiết lập của việc thực hiện các nhiệm vụ - lập kế hoạch, thiết lập mục tiêu và kiểm tra chất lượng. Nhiều khả năng sẽ có nhiều cuộc họp nhóm với 6 Sigma hơn đáng kể so với Kanban, nhưng quá trình thực hiện dự án có cấu trúc hơn và nhóm khó đi chệch hướng hơn. Và giống như Kanban, 6 Sigma tương đối dễ dàng để thích ứng với nhu cầu của một công ty hoặc nhóm cụ thể. Một yêu cầu nghiêm ngặt chỉ là đo lường và kiểm soát kỹ lưỡng các chỉ số của dự án ở các giai đoạn thực hiện - nếu không có điều này, việc cải tiến liên tục trong thời gian dài đối với các quy trình thực hiện dự án là không thể.

Điểm mạnh của 6 Sigma

Six Sigma cung cấp một kế hoạch chi tiết rõ ràng để thực hiện dự án và cải tiến quy trình liên tục. Bằng cách xác định mục tiêu, sau đó phân tích và sửa đổi cẩn thận, bạn sẽ có được dữ liệu định lượng để hiểu sâu hơn về dự án và đưa ra quyết định tốt hơn. Mặc dù việc thu thập, phân tích và học tập dữ liệu có thể mất một khoảng thời gian, nhưng nó sẽ cải thiện và hợp lý hóa các quy trình thực hiện dự án và do đó tiết kiệm tài nguyên trong tương lai.

6 sigma phù hợp với các dự án khó với nhiều thao tác mới và phức tạp. Cách tiếp cận này cho phép bạn thực hiện các yếu tố của dự án, học hỏi từ những sai lầm và cải thiện chất lượng trong tương lai.

Điểm yếu của 6 Sigma

Vấn đề với 6 Sigma là mặc dù mục tiêu chính được tuyên bố là giảm chi phí và tăng hiệu quả, nhưng sự hài lòng của khách hàng thường được đặt lên hàng đầu. Do một số khác biệt về mục tiêu ở các giai đoạn khác nhau của dự án, các nhóm thường nhầm lẫn về các mức độ ưu tiên và việc tránh điều này là không dễ dàng.

Ngoài ra, leitmotif chính của 6 Sigma là: "Mọi thứ luôn có thể được làm tốt hơn nữa." Điều này có thể khiến những nhân viên không cảm thấy hài lòng với công việc đã hoàn thành. Ngoài ra, nếu dự án chỉ là một lần và công ty không có kế hoạch thực hiện các dự án tương tự trong tương lai, tất cả các chi phí phân tích và học hỏi có thể trở nên vô ích.

PRINCE2

NASA không phải là tổ chức chính phủ duy nhất đã đóng góp vào sự phát triển của quản lý dự án. Chính phủ Anh từ lâu đã đánh giá cao hiệu quả của việc quản lý dự án, và vào năm 1989, phương pháp PRINCE2 của Anh đã được tạo ra. Tên bắt nguồn từ từ viết tắt " PR các đối tượng TRONG C kiểm soát E phiên bản n Môi trường 2 ”, Được dịch là“ Dự án trong môi trường được kiểm soát phiên bản 2 ”. Không giống như các phương pháp nhanh nhẹn, PRINCE2 không sử dụng phương pháp thiết kế lặp đi lặp lại. Khi so sánh với các sản phẩm khác, PRINCE2 có thể được so sánh như một sự kết hợp giữa cách tiếp cận cổ điển để quản lý dự án và tập trung vào chất lượng từ 6 sigma.

Phương pháp PRINCE2, không giống như, chẳng hạn, phần thân kiến ​​thức PMBOK, không chứa:

• Các khía cạnh chuyên biệt của quản lý dự án, chẳng hạn như công nghiệp;
• Các thực hành cụ thể và các công cụ quản lý dự án như biểu đồ Gantt, WBS, v.v.

PRINCE2 tập trung vào các khía cạnh quản lý dự án được thể hiện trong 7 nguyên tắc, 7 quy trình và 7 chủ đề dự án.

• 7 nguyên tắc xác định các quy tắc chung để quản lý dự án theo PRINCE2, xác định cơ sở của phương pháp luận;
• 7 quy trình xác định các bước để chuyển qua chu trình dự án;
• 7 chủ đề là các khía cạnh được giám sát để đạt được thành công của dự án.

Khi bắt đầu một dự án, PRINCE2 yêu cầu chúng tôi xác định 3 khía cạnh chính của dự án:

• Khía cạnh Kinh doanh (Dự án này có mang lại lợi ích không?)
• Khía cạnh người tiêu dùng (Sản phẩm nào là cần thiết, chúng ta sẽ làm gì?)
• Khía cạnh nguồn lực (Chúng ta có đủ để đạt được mục tiêu không?)

PRINCE2 có cấu trúc nhóm dự án được xác định rõ ràng hơn hầu hết các phương pháp quản lý dự án. Điều này là do PRINCE2 tập trung vào các dự án quy mô lớn của chính phủ và các tổ chức lớn.

Theo PRINCE2, mỗi thành viên trong nhóm có một vai trò riêng biệt trong mỗi 7 quá trình:

• Bắt đầu dự án (Bắt đầuing lênmột dự án): Trong quá trình này, người quản lý dự án được chỉ định và các yêu cầu về hiệu suất tổng thể của sản phẩm được xác định. Người quản lý dự án, người có trách nhiệm chính là chú ý đến từng chi tiết, báo cáo với Ban chỉ đạo dự án, chịu trách nhiệm về định hướng chung của dự án. Ban chỉ đạo giữ cho dự án đi đúng hướng và chịu hoàn toàn trách nhiệm về sự thành công của dự án.
• Dự án ban đầumột dự án): Trong quá trình này, người quản lý dự án chuẩn bị một "Tài liệu Khởi đầu Dự án" có chứa kế hoạch theo từng giai đoạn của dự án. Các giai đoạn có thể kéo dài một khoảng thời gian khác nhau, nhưng, như trong cách tiếp cận cổ điển, chúng tuân thủ nghiêm ngặt từng giai đoạn.
• Quản lý dự án (Directing một dự án): Quá trình này cho phép Ban chỉ đạo chịu trách nhiệm chung về sự thành công của dự án mà không bị sa lầy vào các chi tiết nằm trong tầm ngắm của người quản lý dự án.
• Kiểm soát giai đoạn (Kiểm soátling một sân khấu): Trong quá trình thực hiện dự án, ngay cả trong điều kiện lý tưởng cũng sẽ có những thay đổi nhất định. Quy trình Kiểm soát giai đoạn thực hiện một trong những nguyên tắc của PRINCE2 - nguyên tắc quản lý theo các trường hợp ngoại lệ. Người quản lý dự án có trách nhiệm giám sát trong quá trình thực hiện các sai lệch của giai đoạn so với các thông số dự án đã lập kế hoạch về thời gian, phạm vi, ngân sách, v.v. Nếu những sai lệch này vượt quá thẩm quyền được Ban chỉ đạo giao cho người quản lý dự án (trong Thuật ngữ PRINCE2 - dung sai), người quản lý dự án phải thông báo cho Ban chỉ đạo và đề xuất cách thoát khỏi tình huống.
• Quản lý tạo sản phẩm (Quản lý sản phẩm vận chuyển): Quá trình quản lý tạo sản phẩm là sự tương tác giữa người quản lý dự án và người quản lý nhóm để tạo ra một trong những sản phẩm của dự án. Trách nhiệm của người quản lý dự án trong quá trình này bao gồm việc giao quyền tạo sản phẩm cho người quản lý nhóm và chấp nhận sản phẩm đã tạo.
• Quản lý ranh giới giai đoạn (Managing một sân khấu ranh giới): Trong quá trình này, người quản lý dự án cung cấp cho Ban chỉ đạo tất cả các thông tin cần thiết để đánh giá kết quả của giai đoạn đã thông qua và quyết định việc chuyển sang giai đoạn tiếp theo.
• Hoàn thành dự án (Đang kết thúcmột dự án): Một trong những điểm khác biệt trong PRINCE2 là quá trình hoàn thành dự án không được tách ra thành một giai đoạn hoặc một giai đoạn riêng biệt, như trong cách tiếp cận cổ điển, mà được thực hiện như một phần của giai đoạn cuối cùng của quá trình tạo ra sản phẩm. Mục đích của quá trình là để xác nhận rằng sản phẩm dự án đã được chấp nhận, hoặc dự án không còn có thể mang lại bất cứ điều gì hữu ích.

PRINCE2 có thể được điều chỉnh cho phù hợp với các dự án ở bất kỳ quy mô nào và bất kỳ lĩnh vực nào. Phương pháp luận đưa ra các khuyến nghị cụ thể để thay đổi vòng đời dự án, mô hình vai trò và bộ tài liệu cần thiết phù hợp với nhu cầu của dự án.

Điểm mạnh của PRINCE2

• Khả năng thích ứng với các đặc điểm của tổ chức;
• Sự hiện diện của một mô tả rõ ràng về các vai trò và sự phân bổ trách nhiệm;
• Nhấn mạnh vào sản phẩm của dự án;
• Các cấp quản lý nhất định;
• Chú trọng đến tính khả thi về kinh tế;
• Trình tự các công việc của dự án;
• Nhấn mạnh vào việc nắm bắt kinh nghiệm và cải tiến liên tục.

Điểm yếu của PRINCE2

• Thiếu các thông lệ trong ngành;
• Thiếu các công cụ cụ thể để làm việc trong dự án.

Hệ thống quản lý dự án tốt nhất ... dành cho bạn!

Quản lý dự án là một khoa học, nhưng khoa học này không phải là khoa học chính xác nhất. Không có nền tảng vững chắc và các giải pháp phổ quát trong lĩnh vực này. Nếu bạn quản lý để tìm ra một phương pháp hoàn toàn phù hợp với dự án của mình, hãy tự coi mình là người rất may mắn, bởi vì hầu hết các nhà quản lý kém may mắn đều phải nỗ lực tạo ra và tùy chỉnh hệ thống quản lý dự án của riêng họ. Các hệ thống này có thể được tạo thành từ các yếu tố của các hệ thống hiện có, hoặc thậm chí được tạo ra hoàn toàn từ đầu, như trong trường hợp của sứ mệnh Apollo. Điều chính là sử dụng một cái gì đó cung cấp cho bạn ít nhất một số cấu trúc và cho phép bạn nhớ những gì quan trọng đối với dự án của bạn.

« Sự hoài nghi là phản ứng của ý thức chúng ta đối với cảm giác tuyệt vọng.».
Jeff Sutherland

Giải pháp thay thế PM mạnh đến mức nào?

Đóng vai trò là người quản lý hàng đầu và người quản lý dự án, tôi đã bắt gặp khái niệm Scrum như một dạng thay thế kỳ lạ cho quản lý dự án cổ điển. Tôi muốn hiểu các tính năng tư tưởng và công nghệ của phương pháp này là gì, và trên thực tế, đâu là cuộc cách mạng của phương pháp này? Tôi đã đọc một số chuyên khảo. Thành thật mà nói, sau cuộc gặp đầu tiên, tôi không nhìn thấy nhiều chiều sâu. Phương pháp Scrum có vẻ hơi thiên lệch và không cụ thể.

Ở lần xem xét thứ hai, chi tiết hơn về phương pháp Scrum, các tính năng mà theo tôi, vẫn đáng được cộng đồng doanh nghiệp quan tâm, bắt đầu được hiện thực hóa. Có vẻ như phương pháp này không chỉ thú vị đối với lĩnh vực thương mại-công nghiệp, mà còn đối với các thể chế khác của xã hội chúng ta. Phương pháp này có thể áp dụng trong việc thiết kế các mô hình giáo dục, R&D, xây dựng nhà nước và thành phố. Tuy nhiên, đối với bất kỳ sản phẩm mới nào, điều quan trọng là:

• loại trừ tính tuyệt đối và tính không hoàn hảo theo toa của công nghệ được xem xét;
• lưu ý rằng phương pháp Scrum là thô sơ về mặt ý thức hệ và có thể chỉ đơn giản là “không nằm trên đất của chúng ta” với các cách thức và truyền thống của nó;
• xem những điểm xung đột mà phương pháp này mang lại;
• hiểu rằng phương pháp Scrum yêu cầu một hệ tư tưởng minh bạch của nhà nước và doanh nghiệp liên quan đến "luật chơi" với các nhân sự tham gia phát triển.

Mô hình quản lý dự án hiện đại, tiêu chuẩn quốc tế và quốc gia (Hướng dẫn ANSI PMbok, PM ICB IPMA, NTK) có phải là sản phẩm mà người tiêu dùng sử dụng: nhà nước, tổ chức, doanh nghiệp không? Ồ chắc chắn rồi. Những vấn đề nào tồn tại trong thực hành thiết kế hiện đại dựa trên phương pháp luận làm việc? Có một số trong số đó, nhưng có hai nguyên nhân chính: không đáp ứng được thời hạn của dự án và vượt quá ngân sách dự án.

Có một quy tắc nổi tiếng trong quản lý: nếu một nhiệm vụ đã có tiền lệ để giải quyết và đã được thực hiện nhiều lần, nó sẽ tập trung vào các quá trình và những khó khăn trong việc giải quyết nó có bản chất cụ thể. Nếu không có kinh nghiệm trong việc giải quyết nó, thì nhiệm vụ, một mặt, là một dự án lý tưởng về bản chất, mặt khác, phương pháp thực hiện nó kém rõ ràng, có hình ảnh mơ hồ. Căng thẳng lớn nhất đối với người quản lý dự án là quá trình lập kế hoạch cho dự án lý tưởng về phạm vi và thời gian. Đồng thời, đôi khi khách hàng rất khó phân tích kết quả của nhiệm vụ dự án, dựa trên thành phần của các giá trị mà anh ta mong đợi nhận được.

Tính chất này của các dự án đặc biệt quan trọng trong các lĩnh vực đòi hỏi một cách tiếp cận sáng tạo. Phương pháp Scrum có thể giảm thiểu đáng kể những vấn đề này. Vào đầu những năm 2000, nó là kết quả của công việc của hai nhà cải tiến D. Sutherland và K. Schwaber (Mỹ). Trong quá trình phát triển của mình, các tác giả của phương pháp này đã sử dụng các yếu tố lý thuyết của H. Takeuchi và I. Nonaka, cũng như các ý tưởng về hệ thống Toyota (Taiichi Ohno). Và với tư cách là một phương pháp quản lý dự án mang tính cách mạng, mô hình Scrum đã được công nhận ở các nước phương Tây và ngày nay việc áp dụng mô hình này không chỉ giới hạn trong lĩnh vực kinh doanh.

Thuật ngữ phương pháp

Các tác giả của phương pháp này đã chỉ trích một cách hợp lý mô hình lập kế hoạch dự án cổ điển, đã được sử dụng trong khoảng 100 năm dựa trên cách tiếp cận của G. Gantt. Thật vậy, không có gì có thể phản bác lại tuyên bố rằng biểu đồ Gantt trực quan về cơ bản là sử dụng một lần. Không chỉ làm mất nhiều thời gian, gần như ngay sau khi bắt đầu công việc thiết kế, mô hình thác nước trong hầu hết các trường hợp đều trở nên vô dụng.

Lý do rất đơn giản: các công trình tinh thần về nội dung và thời gian hoạt động không bao giờ trùng khớp với các sự kiện thực tế của công trình. Một phương pháp thay thế cho việc lập kế hoạch dự án thác nước, phương pháp luận Scrum cung cấp một cơ chế lập kế hoạch linh hoạt. Chúng ta sẽ xem xét nó sau một chút, nhưng bây giờ chúng ta sẽ phân tích các khái niệm cơ bản mà phương pháp Scrum vận hành.

1. Chủ sở hữu sản phẩm. Con số này chịu trách nhiệm đảm bảo rằng làm việc theo nhóm tạo ra một kết quả mang lại lợi nhuận (lợi ích) cho công ty. Anh ta phải thông thạo bản chất của sản phẩm, khả năng của nhóm và các ưu tiên của thị trường.
2. Đội sản xuất. Nói một cách ẩn dụ, đây là một vai diễn rất thú vị. “Người lãnh đạo đầy tớ”, “đội trưởng”, “huấn luyện viên”. Nhiệm vụ chính của anh ấy là dẫn dắt đội trên con đường cải tiến liên tục, loại bỏ những trở ngại và nguyên nhân gây nhiễu.
3. Bảng Scrum. Một hội đồng văn phòng bình thường được chia thành các phần: “tồn đọng”, “công việc”, “đang làm việc”, “xem xét”, “hoàn thành!”. Hình dán dính với các nhiệm vụ di chuyển dọc theo nó.
4. Bộ sưu tập Scrum. Cuộc họp cuối cùng khi kết thúc sprint.
5. Tăng tốc. Khoảng thời gian từ 1 đến 4 tuần, thiết lập nhịp điệu làm việc của nhóm Scrum để tạo ra chức năng mới.
6. Các cuộc họp khi đang di chuyển hoặc Scrum hàng ngày. Các cuộc họp ngắn của nhóm dự án để trả lời các câu hỏi của Scrum Master về kết quả, kế hoạch trong ngày và những trở ngại hiện tại.
7. Backlog (tồn đọng). Danh sách các yêu cầu-nhiệm vụ hiện tại để tạo chức năng của sản phẩm dự án.
8. Sơ đồ nguyên công. Biểu đồ hiển thị số lượng công việc đã hoàn thành và còn lại của một nhiệm vụ nhất định.
9. Chuỗi Fibonacci. Một quy luật toán học vốn có trong bản chất của Vũ trụ của chúng ta, theo đó một thứ tự đặc biệt của các con số hoạt động. Trình tự này có thể áp dụng tốt cho một ước tính thay thế về thời gian của dự án, nhờ vào việc sử dụng cái gọi là "poker lên lịch". Dưới đây là mô hình trực quan của dãy số.
10. Suhari (Shu Ha Ri). Shuhari là một trong những khái niệm về thực hành võ thuật Nhật Bản (ví dụ, aikido), được đưa vào các nguyên tắc của phương pháp Scrum như một phép ẩn dụ cho khả năng đạt được thành tích xuất sắc của nhóm dự án theo từng giai đoạn (lặp đi lặp lại).
11. OODA. Nguyên tắc của phương pháp Scrum để thực hiện theo chu kỳ: quan sát, điều hướng, quyết định, hành động.

Mô hình trình tự Fibonacci

Mô hình cơ bản của phương pháp Scrum. Nguồn: Askhat Urazbaev. Tổng quan ngắn gọn về phương pháp Scrum

Mô tả ngắn gọn về quy trình

Phương pháp luận Scrum, như nó vốn có, nhúng kết cấu của việc thực hiện nhiệm vụ dự án vào một nhịp điệu chạy nước rút theo chu kỳ khá cứng nhắc. Không giống như các hoạt động dự án tiêu chuẩn, trong phương pháp luận, thông điệp ban đầu cho việc lập kế hoạch không phải là các nhiệm vụ (mặc dù nhiệm vụ dự án không bị hủy bỏ), mà là các câu chuyện và sự kiện giúp hiểu được các giá trị và nhu cầu của người dùng, khách hàng của dự án. sản phẩm. Cần phải hiểu động cơ gây ra nhu cầu của anh ta đối với sản phẩm.

Trong hoạt động dự án cổ điển, công việc này được thực hiện ở giai đoạn phát triển điều lệ dự án, nhưng ở đó nó mang tính hình thức hơn nhiều. Một số câu chuyện người dùng cũng được hình thành ở đây, ngắn gọn và thuận tiện cho việc phân mảnh sau này. Xin lưu ý rằng với sự phân hủy truyền thống của các nhiệm vụ thiết kế, sự nô dịch cuối cùng của chúng thành dạng ngôn ngữ khô khan của sự rõ ràng sẽ xảy ra. Ngược lại, trong phương pháp Scrum, quá trình giải phóng diễn ra - để các câu chuyện tạo ra hình ảnh có giá trị về sản phẩm dự án.

Việc thực hiện dự án sử dụng các quy trình Scrum bao gồm bốn khối chính.

1. Điền các vai trò trong nhóm Scrum.
2. Hình thành các tạo tác Scrum.
3. Triển khai hoạt động.
4. Tái tạo chu trình Scrum.

Mô hình trực quan của quy trình phương pháp Scrum

Thành phần của các vai trò trong phương pháp Scrum rất đơn giản: chủ sở hữu sản phẩm, người điều hành scrum và nhóm. Theo thứ tự tương tự, mọi người được chọn cho những vai trò này. Gần nhất với vai trò cổ điển của người quản lý dự án là chủ sở hữu sản phẩm, anh ta chịu trách nhiệm về sự hình thành và thay đổi thường xuyên của sản phẩm tồn đọng. Sau khi công việc tồn đọng được hình thành, nhóm dự án bắt đầu lên kế hoạch cho sprint sắp tới. Đồng thời, “lập kế hoạch chơi poker” được sử dụng tích cực như một công cụ khách quan và cân bằng hơn, dựa trên phương pháp Delphi và chuỗi Fibonacci. Do đó, một công việc tồn đọng cục bộ được hình thành cho chu kỳ sắp tới của nước rút mới.

Scrum tạo tác trong phương pháp được hiểu là: sản phẩm và sprint tồn đọng, một sản phẩm dự án với chức năng mới. Mỗi sprint đều có mục tiêu là tạo ra một chức năng mới của sản phẩm, mặc dù có một chút tiến bộ, nhưng sẽ trở nên rõ ràng và có thể được trình bày cho khách hàng dự án và các bên quan tâm khác. Trong môi trường nội bộ của chu kỳ nước rút, nhóm hoạt động một cách tự chủ, đi kèm với “các cuộc họp khi đang chạy” và các nhãn dán di chuyển trên bảng Scrum. Dưới đây là một ví dụ về sự xuất hiện của bảng.

Ví dụ về bảng Scrum

Thành phần của các thuộc tính hội đồng quản trị Scrum có thể phản ánh các đặc điểm cụ thể trong cách tiếp cận thiết kế của công ty. Ngoài ra, có thể bao gồm biểu đồ hoàn thành nhiệm vụ, tuyên bố mục tiêu chạy nước rút, v.v. Sau khi hoàn thành Sprint, hai sự kiện dự án được tổ chức: Họp Tổng kết Sprint và Họp Tổng kết. Đầu ra của cuộc họp đánh giá là một sản phẩm của dự án có chức năng đã được sửa đổi hoặc hoàn thiện. Sau khi phân tích hồi cứu, có một danh sách các cải tiến cần thiết trong công việc của nhóm Scrum. Chu kỳ khép lại, sản phẩm tồn đọng được điều chỉnh. Các nhiệm vụ mới được "lấy" từ nó và quá trình bắt đầu lại.

Nhận xét về việc điền vào các vai trò

Một trong những chuyên khảo mà tôi đã tìm cách làm quen là cuốn sách của D. Sutherland, trong đó Scrum được trình bày như một phương pháp quản lý dự án mang tính cách mạng. Tác phẩm có rất nhiều ví dụ từ kinh nghiệm cá nhân của tác giả, các quyết định thiết kế thành công và các tên tuổi lớn. Màu sắc cảm xúc của lập luận rất ấn tượng. Nhìn chung, cách tiếp cận là truyền thống của trường phái phương pháp luận Bắc Mỹ. Mặc dù logic hơi khó hiểu, nhưng hiểu được phương pháp thiết kế không khó. Trợ giúp tốt là trong Phụ lục. Ba bước đầu tiên của công nghệ này khá hợp lý dành riêng cho các vai trò trong nhóm Scrum.

Bước 1 của thuật toán phương pháp Scrum

Khi xem xét kỹ hơn, các kết luận-ẩn dụ được đưa ra cho mỗi phần của phương pháp đã hóa ra rất hiệu quả. Hơn nữa, nhận xét của tôi về các phần của thuật toán sẽ được xây dựng trên nguyên tắc tìm kiếm các khía cạnh tích cực giúp phân biệt Scrum với phương pháp luận dự án truyền thống. Sau đó, tôi định đặt ra các câu hỏi làm dấy lên nghi ngờ của tôi hoặc yêu cầu giải quyết các điều kiện hành nghề thiết kế của Nga. Trong số những điểm tích cực trong bước đầu tiên của phương pháp, tôi thấy:

• chuyển đổi có thẩm quyền về mặt ngữ nghĩa của vai trò của người quản lý dự án thành chủ sở hữu sản phẩm, từ vị trí NLP, lập trình chính xác cho người lãnh đạo cho kết quả của nhiệm vụ dự án;
• xếp hạng danh sách các nhiệm vụ (tồn đọng) của dự án theo giá trị (đối với khách hàng) và rủi ro;
• linh hoạt trong việc chấp nhận những thay đổi về giá trị của sản phẩm đối với khách hàng của dự án;
• cho điểm các nhiệm vụ và khả năng thay thế các nhiệm vụ dự án trong quá trình phân bổ lại các ưu tiên và dừng chạy nước rút.

Bước 2 của thuật toán phương pháp Scrum

Theo tôi, thông điệp phương pháp luận có giá trị nhất của bước 2 là “đổ lỗi là ngu ngốc”. "Tiêu chuẩn vàng" về quy mô nhóm Scrum cũng được chấp nhận mà không bị phản đối. Đối với một loại văn hóa nhóm dự án nhất định, chẳng hạn như tính chính danh hoặc có sự tham gia, trong một cách phân loại khác, tôi hoàn toàn đồng ý với nguyên tắc tự chủ của nhóm Scrum. Tất cả các luận điểm khác của bước 2 đều phổ biến và giống với cách tiếp cận dự án cổ điển.

Bước 3 của thuật toán phương pháp Scrum

Tám phép ẩn dụ đầu tiên cho bước tiếp theo của Scrum cũng có thể được coi là các quy tắc cho hoạt động kinh doanh hoặc bất kỳ loại hoạt động nào khác, bao gồm cả các dự án. Bạn bất giác tự hỏi mình câu hỏi: tại sao trong thực tế thiết kế không thể nhìn thấy điều này? Tôi nghĩ cần phải làm rõ thêm một số điểm để trả lời nó.

1. Nếu “người lãnh đạo không phải là sếp” mà Scrum Master là “người chơi-huấn luyện viên”, thì ai quản lý nhóm Scrum? Theo tôi, tự quản lý không phù hợp với khái niệm quản lý dự án.
2. Câu hỏi đặt ra về động lực của chủ sở hữu sản phẩm dự án, Scrum Master và nhóm Scrum. Phương pháp này mô tả nguyên tắc mở của thông tin, bao gồm quyền truy cập vào dữ liệu tài chính của dự án. Đó không phải là một ý tưởng tồi, nhưng với quan điểm của Machiavellian hiện diện trong nhiều công ty Nga, một cơ hội như vậy giữa các nhà lãnh đạo có lẽ sẽ có nhiều đối thủ.

Câu hỏi về sự hình thành của các hiện vật

Bốn bước tiếp theo của thuật toán phương pháp Scrum được dành cho việc hình thành và làm việc với các tạo tác mô hình. Thông qua chúng, chúng ta sẽ hiểu được thông tin và các đối tượng vật chất đóng vai trò là điểm khởi đầu cho một giai đoạn hoạt động nhất định, các hành động dẫn đến kết quả trung gian hoặc cuối cùng của dự án. Bước tạo một sản phẩm tồn đọng đáng chú ý là các tính năng của nó.

Vấn đề chính là danh sách các yêu cầu Scrum này không được coi là thứ được tìm thấy một lần và không thể lay chuyển được. Sản phẩm tồn đọng sẽ được xem xét lại năng động mỗi lần sau khi kết thúc nước rút. Và điều này rất có giá trị, theo ý kiến ​​của tôi. Tôi có thể nói từ kinh nghiệm của bản thân rằng một cơ chế như vậy còn thiếu trong mô hình quản lý dự án cổ điển.

Bước 4 của thuật toán phương pháp Scrum

Bước thứ năm của thuật toán Scrum cũng không kém phần thú vị. Tôi hoàn toàn không muốn đi sâu vào các khía cạnh huyền bí của các con số. Nhưng chúng tôi có một nhiệm vụ thực dụng bình thường: đưa ra dự báo tốt nhất về thời gian của dự án, sử dụng đánh giá khách quan nhất của chuyên gia. Thật không may, việc "bói" bằng cách bỏ giờ trong MS Project không còn gì thê lương và mệt mỏi hơn, ngay cả khi có sự tham gia của các chuyên gia am hiểu. Tôi có thể tự tin tuyên bố rằng tôi chưa bao giờ gặp một phương pháp nào tốt hơn là “lập kế hoạch chơi poker” trong thực tế dự án. Phương pháp được biết đến rộng rãi, vì vậy chúng tôi sẽ không tập trung vào nó. Tôi sẽ chỉ lưu ý rằng sự kết hợp của phương pháp Delphi và dãy Fibonacci cho kết quả đáng kinh ngạc.

Ví dụ về Solitaire về Phương pháp Poker Lập kế hoạch

Có một số lý do để coi phương pháp Scrum không phải là sự điều chỉnh của học thuyết PM hiện đại, mà là một phương pháp thực sự mang tính cách mạng trong quản lý dự án. Một trong số đó là thái độ mô tả công việc thực hiện nhiệm vụ dự án từ góc độ truyện, ngược với cách tiếp cận quy trình của D. Champi và M. Hammer. Mọi người thực sự nghĩ bằng hình ảnh. Một mặt, khó có thể đồng ý rằng người ta có thể không sợ mất đi sự giải thích rõ ràng về kết quả của công việc. Mặt khác, nếu bạn gạt bỏ áp lực công việc và nhìn vấn đề từ góc độ thực sự tập trung vào khách hàng, thì những câu chuyện nhẹ nhàng có thể làm được nhiều việc hơn để đạt được kết quả nhiệm vụ phù hợp.

Bước 5 của thuật toán phương pháp Scrum

Nhìn vào bước 5 và 6, không nghi ngờ gì về cơ chế tính toán động lực học hiệu suất, thời gian tồn đọng của sprint, ngày hoàn thành dự án và khả năng tăng tốc. Mọi thứ đều khá rõ ràng. Khó khăn trong việc hiểu biết nảy sinh liên quan đến một câu hỏi: làm thế nào vào cuối mỗi sprint để đạt được sự gia tăng trực quan về chức năng của sản phẩm? Đối với các dự án phát triển phần mềm, điều này là hoàn toàn có thể. Nhưng ví dụ, khi thực hiện một dự án triển khai hệ thống lập ngân sách bằng phương pháp Scrum, nơi có nhiều giai đoạn chuẩn bị, mà ở đó không có sự gia tăng chức năng nào rõ ràng? Có vẻ như phần của phương pháp này cần phải ngâm thêm.

Bước 6 của thuật toán phương pháp Scrum

Các vấn đề về Hành động Hoạt động trong Quy trình

Khối thủ tục thứ ba của phương pháp Scrum là việc thực hiện các hoạt động. Bằng các hoạt động, chúng tôi muốn nói đến các hành động của chủ sở hữu sản phẩm, Scrum Master và toàn bộ nhóm Scrum để đạt được kết quả cục bộ của sprint hiện tại hoặc toàn bộ dự án. Bước thứ bảy của quá trình thiết kế đang gây tranh cãi. Một mặt, chúng ta đang nói về những công cụ làm việc khá hiệu quả cho công việc tập thể, mang lại mức độ công khai cao, sự thông thoáng, khả năng hiển thị. Chúng ta đang nói về việc sử dụng bảng Scrum, nhãn dán, biểu đồ hoàn thành nhiệm vụ. Mặt khác, không chỉ đối với tôi, mà còn đối với nhiều nhà quản lý Nga, việc nhìn nhận phạm trù hạnh phúc như một yếu tố của công nghệ quản lý là điều khá khó khăn. Tôi sẽ dành hẳn một phần của bài viết cho vấn đề này.

Bước 7 của thuật toán phương pháp Scrum

Một trong những phát hiện rõ ràng về phương pháp Scrum, tôi coi đó là kỹ thuật họp hàng ngày khi đang di chuyển. Một phương tiện tương tác và động lực rất ngắn gọn và hiệu quả của nhóm dự án trong sprint. Vận động viên vĩ đại của thế kỷ 20, Mohammed Ali, rất coi trọng một nghi thức thường xuyên để thành công trong bất kỳ hoạt động kinh doanh nào. Cuộc họp Scrum Hàng ngày có nghĩa là một nghi thức thường xuyên mạnh mẽ thúc đẩy sự hợp nhất nhóm trong thời gian ngắn. Hỗ trợ huấn luyện, một không gian lãnh thổ duy nhất, không có sự phân chia theo “cấp bậc và cấp bậc” - tất cả những điều này hoạt động để đảm bảo rằng nhóm Scrum hành động với tốc độ triển khai dự án.

Bước 8 của thuật toán phương pháp Scrum

Tại bước 9 của thuật toán phương pháp Scrum, những gì bạn lo lắng sẽ xuất hiện và một lần nữa quay trở lại việc xây dựng các nhiệm vụ cho sprint. Trong nhiều năm, tôi đã phải nuôi dưỡng niềm tin rằng bối cảnh nhiệm vụ của quản lý dự án bao hàm sự rõ ràng của việc xây dựng kết quả theo nghĩa "đạt được - không đạt được". Kết quả nào được coi là không quan trọng: nhiệm vụ cấp cao nhất hay nhiệm vụ bị phân rã. Trong mọi trường hợp, giám đốc của nhiệm vụ dự án và nguồn lực chịu trách nhiệm nên bị tước đi cơ hội vận dụng sự mơ hồ của từ ngữ.

Bước 9 của thuật toán phương pháp Scrum

Chu kỳ chạy nước rút kết thúc với bước thứ mười, là bước đánh giá đồng cấp về quá trình chạy nước rút đã hoàn thành. Chế độ huấn luyện tương tác với nhóm Scrum được bật lại trong quá trình đánh giá tiến độ thực hiện các nhiệm vụ và tìm kiếm các cải tiến. Tâm lý người Nga luôn được đặc trưng bởi những phán xét giá trị với hàm ý tiêu cực về kết quả không thành công và đổ vỡ. Trong trường hợp này, “người chuyển mạch” nên luôn được chỉ định - một thành viên của nhóm dự án, thông qua lỗi của người mà tổn thất xảy ra. Càng có giá trị hơn là các nguyên tắc về tính ưu tiên của lỗi hệ thống đối với hành động của những người tham gia trong quy trình Scrum với tư cách là đối tượng của hoạt động dự án và việc từ chối nhân cách hóa cảm giác tội lỗi.

Bước 10 của thuật toán phương pháp Scrum

Scrum như một quy tắc chống chủ nghĩa hoài nghi

Tôi thích phép ẩn dụ được trình bày trong phụ đề. Nó thuộc về Jeff Sutherland, và có một cảm giác hoài nghi sâu sắc trong nó như một thứ quan trọng của kinh doanh hiện đại. Nói chung, quan điểm của tác giả của phương pháp Scrum chắc chắn là chân thành. Nó thật quyến rũ. Và, về nguyên tắc, không tệ chút nào khi Sutherland đưa một thành phần của hạnh phúc vào bối cảnh quản lý. Điều này được thực hiện theo cách của người Mỹ. Đồng thời, tôi muốn hiểu tại sao từ "hạnh phúc", và mọi thứ liên quan đến nó trong học thuyết thiết kế được coi là mang tính cách mạng, lại gây ra sự khó chịu trong nội bộ công ty. Đó chỉ là một nhận thức chủ quan-cá nhân, hay là một quan điểm văn hóa chung nào đó về cách tiếp cận được đề xuất?

Bạn và tôi rất có thể nhớ những gì đã xảy ra ở Nga vào cuối những năm 1990 và đầu những năm 2000. Đất nước này thực sự tràn ngập “những người giàu mới” từ khắp nơi trên thế giới, và chủ yếu là từ Hoa Kỳ, truyền đi “sự thật” về thành công của cá nhân và doanh nghiệp. Thành thật mà nói, những “tiết lộ” như vậy đã không trôi qua một cách vô cớ, nhiều nhà kinh doanh đã áp dụng những khía cạnh then chốt của các lý thuyết quản lý mang đến từ phương Tây. Tôi đặc biệt không nêu tên các khóa đào tạo, lý thuyết của tác giả và các trường nổi tiếng. Ai đã trải qua chúng sẽ hiểu.

70 năm quyền lực của Liên Xô đã làm thay đổi rất nhiều nền văn hóa nội tại của con người, nhưng mã di truyền của con người Nga không bị mất hoàn toàn, vì nó được hình thành qua nhiều thế kỷ. Tuy nhiên, khi khả năng giao tiếp và quan hệ kinh doanh rộng rãi nhất mở ra, các bộ lọc tự nhiên của các doanh nhân và nhà quản lý bị phá vỡ. Và nhiều ý tưởng đã được chấp nhận như một tiên đề, trong khi các nguyên tắc của trí tuệ sơ đẳng không được áp dụng. Đây là những chi phí của khoảng thời gian, hiện đã kết thúc.

Có một sự tỉnh táo nhanh chóng cả ở cấp tiểu bang và cấp doanh nhân. Và họ bắt đầu hiểu rằng một số giải pháp được đưa ra, cách kinh doanh, xây dựng mối quan hệ với nhân viên không chỉ hữu ích mà còn phục vụ cho những mục đích thù địch và phá hoại, dẫn đến sự phá vỡ văn hóa dân tộc của chúng ta, trong đó có văn hóa quản lý. Tôi sẽ đưa ra một ví dụ duy nhất về sự đối lập của hai hệ tư tưởng: "Chia để trị!" và "Lời nói của một thương gia có giá trị hơn một hợp đồng!".

Sự tỉnh táo này là lý do cho một thái độ rất thận trọng đối với việc áp đặt nguồn hạnh phúc như một phương tiện kiểm soát. Trong truyền thống của Nga, với cộng đồng lâu đời hàng thế kỷ, nguồn gốc Chính thống giáo và Hồi giáo, "hạnh phúc" đề cập đến các phạm trù đạo đức và tâm linh cao. Nó không thể được xem xét một cách toàn diện dưới góc độ đạo đức, từ góc độ trạng thái tâm lý, dưới góc độ lĩnh hội trí tuệ, nâng cao thể chất và tinh thần.

Những điều trên không làm giảm giá trị của phương pháp Scrum được thảo luận trong bài báo. Nếu bạn loại bỏ bức màn của sự tuyệt đối hóa, nói nhỏ và một số bệnh lý, thì đây là một công cụ hữu ích cho thiết kế. Cái mới luôn khó tìm ra con đường của nó. Đầu tiên, đây là những ý tưởng cao, sau đó là những ví dụ riêng biệt, và cuối cùng, có một giai đoạn được chấp nhận rộng rãi. Có vẻ như tương lai thuộc về các thuật toán lai để tiến hành các hoạt động dự án và khả năng thay đổi linh hoạt trong việc sử dụng các phương pháp tiếp cận truyền thống và cách mạng.