Kế hoạch dài hạn và nhanh nhẹn?

Nhóm của tôi gần đây đã trải qua quá trình đưa ra kế hoạch gần một năm cho công việc của chúng tôi. Chúng tôi tách kế hoạch thành ba giai đoạn. Mỗi giai đoạn sẽ bao gồm một vài lần ra mắt.

Tôi tự hỏi, từ một điểm nhanh nhẹn của bạn, điều này là sai? Tôi nghĩ đó không phải là một ý tưởng tồi, bởi vì chúng tôi đã không dành quá nhiều thời gian để thiết kế bất cứ thứ gì ngoại trừ vài bước đầu tiên. Chúng tôi có thể thay đổi hướng. Đồng thời, thật tuyệt khi chúng ta không hành động chỉ với thời hạn gần.

Có một tầm nhìn về nơi dự án là để đi là một điều tốt ^TM .

Tin rằng đó là chính xác những gì sẽ xảy ra là không.

Chuẩn bị cho trận chiến Tôi luôn thấy rằng các kế hoạch là vô ích, nhưng kế hoạch là không thể thiếu.

- Dwight D. Eisenhower

Phương pháp mà Agile thực hiện là chia mọi thứ thành các phần dễ tiêu hóa và điều chỉnh lại tầm nhìn sau khi từng phần được tiêu hóa.

Điều đó có nghĩa là điểm kết thúc của bạn trong một năm kể từ bây giờ sẽ không chính xác như những gì bạn nghĩ bây giờ. Tuy nhiên, bạn nên xử lý tất cả các mục có giá trị cao trong danh sách của mình và giữ cho các bên liên quan của bạn tham gia và hạnh phúc khi bạn tiến về phía trước.

OK, quản lý đã được trình bày với một huyền thoại để lên kế hoạch. Tôi hy vọng, vì lợi ích của bạn, rằng họ không giữ bạn cho nó. Bởi vì, không nhìn thấy gì, tôi sẵn sàng đặt cược tiền rằng nhóm của bạn sẽ không hoàn thành bất cứ điều gì giống như những gì kế hoạch dài hạn nói. Trong thực tế, nếu bạn đạt mức trung bình của ngành, bạn sẽ bỏ lỡ khoảng 2 nhân tố. Và trong hầu hết các tổ chức, một ước tính, một khi được đưa ra, sẽ trở thành câu lạc bộ họ có thể tự do đánh bại bạn nhiều như họ muốn.

Bạn có thể nghĩ rằng tôi chỉ là hoài nghi. Sau tất cả, bạn chỉ truyền đạt thời gian mơ hồ cho các bộ tính năng không xác định mà mọi người biết có thể xảy ra chậm hơn hoặc nhanh hơn nhiều so với dự kiến, phải không? Xin lỗi, hầu hết điều đó có thể đúng, nhưng đó không phải là cách mọi người có xu hướng nghe những con số đó. Họ đã nghe thấy ngày tháng, và một cuộc hẹn hò một lần được nói có xu hướng nghe chắc chắn hơn bạn nói. Hơn nữa, nếu có một chuỗi giao tiếp, nó sẽ trở nên vững chắc hơn. Và một khi khách hàng bên ngoài đã được hứa hẹn một điều gì đó bằng doanh số dựa trên những gì bạn nói, bạn sẽ đột nhiên thấy rằng những con số đó kém linh hoạt hơn rất nhiều so với những gì nên có. Và tôi đảm bảo rằng bạn đã đánh giá thấp thời gian mọi thứ sẽ mất.

Với quan điểm rõ ràng trên đường đi, tôi sẽ khuyên bạn nên đọc Dự toán phần mềm để tìm hiểu điều gì đó về cách ước tính phần mềm thực sự nên được thực hiện. Bạn sẽ học được rất nhiều về những gì bạn đã làm sai và làm thế nào để làm tốt hơn vào lần tới. (Trong quá trình bạn sẽ tìm hiểu lý do tại sao tôi rất tự tin rằng bạn đã ước tính quá mức những gì bạn sẽ làm.)

Điều đó nói rằng, nhanh nhẹn chủ yếu là về việc giảm quá trình để phù hợp với một nhóm nhỏ. Thường thì một cách tốt để giảm quá trình là cố gắng cắt giảm quy hoạch dài hạn quy mô lớn có lợi cho việc lập kế hoạch cho những việc nhỏ hơn trong ngắn hạn. Nó cũng có xu hướng trung thực hơn - bởi vì bạn không biết điều gì sẽ xảy ra trong tương lai. Tuy nhiên, điều đó thường không phù hợp với nhu cầu kinh doanh lớn hơn, và vì vậy, bất kể bạn có tuyên bố mình là người nhanh nhẹn hay không, đôi khi bạn cần phải nằm trong kế hoạch dài hơn.

Như đã nói, tôi thực sự khuyên bạn nên khám phá một sự thật quan trọng về những ngày bạn đã liên lạc, rất tiếc có khả năng quay lại là thời hạn để cắn bạn. Và thực tế là đây. Những gì mọi người quan tâm, ngày, hoặc bộ tính năng? Đây là những gì tôi có ý nghĩa bởi điều đó. Các tổ chức thường xuyên có ngày cụ thể quan trọng. Ví dụ, có được một cái gì đó được thực hiện cho một hội nghị hoặc trước khi kỳ nghỉ vội vàng. Trong trường hợp đó, điều quan trọng là phát hành một cái gì đó, và không quá nhiều cho dù điều đó đã hoàn thành. Những lần khác, có một bộ các tính năng thực sự cần được phát hành cùng nhau, và tính đầy đủ quan trọng hơn so với khi chính xác nó xảy ra. Nếu bạn có thể khám phá ra bạn đang ở trong tình huống nào, thì nhóm của bạn sẽ ở một vị trí tốt hơn nhiều để lên kế hoạch xử lý các cuộc khủng hoảng không thể tránh khỏi (gần như) sắp xảy ra.

Sẽ ổn khi có một kế hoạch miễn là bạn coi đó là tiến trình thực hiện và không phải là một cái gì đó được viết bằng đá.

Chìa khóa ở đây là phát hành thường xuyên (ít nhất là hàng tháng), thu thập phản hồi thực từ người dùng của bạn và cập nhật gói của bạn dựa trên phản hồi đó.

Điều này có nghĩa là kế hoạch của bạn sẽ thay đổi khi phạm vi của dự án thay đổi. Đây là một điều tốt , bởi vì nó có nghĩa là người dùng của bạn đã tìm hiểu thêm về những gì họ muốn.

Giả sử bởi project-managementvàagile bạn có nghĩa là Scrum, đây sẽ không phải là cách chính xác để đi.

bên trong Scrum quan điểm, nếu bạn có kế hoạch một năm, ít nhất bạn nên có nhiều Sprint như có nhiều tháng trong một năm. Do đó, kế hoạch một năm của bạn ngày càng nhanh nhẹn hơn vì nó có thể thay đổi giữa hai Sprint.

A Sprintcó thể không quá một tháng, trong đó các Teamcam kết mang lại Sprint Backlog Itemstrạng thái của Done.

Donelà một từ quan trọng ở đây, và mỗi trong số Scrum Teamphải có một định nghĩa được thực hiện, đó là, nơi không còn công việc nào phải làm. Khi a Sprint Backlog Itemđược thực hiện , điều này có nghĩa là phân tích, kiến ​​trúc và tài liệu kỹ thuật được viết và tính năng này đã được kiểm tra kỹ lưỡng (kiểm tra đơn vị, kiểm tra tích hợp, kiểm tra chức năng ...).

Một khi các ưu tiên sẽ ưu tiên các hạng mục vì chính người chịu trách nhiệm hoàn vốn đầu tư, nếu không, sẽ biết điều gì là quan trọng nhất đối với người dùng cuối. Ngoài ra, Nhóm sẽ đánh giá thời gian cần thiết để phát triển đầy đủ một tính năng mặc dù có thể có các đoạn mã có thể tái sử dụng ở đây và ở đó có thể phù hợp với nhu cầu của tính năng này, nghĩa là để tránh sự phức tạp hơn nữa và chắc chắn rằng một Vật phẩm không nên sử dụng lâu hơn những gì Đội nói sẽ yêu cầu. Product Backlog không cần phải hoàn hảo! Việc liệt kê đơn giản các câu chuyện của người dùng mà chúng ta có thể nghĩ về hệ thống để phát triển là đủ ở bước đó của quy trình.Product Backlog có, và các Mục được ưu tiên với các tính năng ít quan trọng hơn ở dưới cùng và các mục quan trọng nhất ở trên cùng, Nhóm (của nhà phát triển) sẽ xác định thời gian phát triển của mỗi mục Product Backlog Itemsẽ dựa trên kinh nghiệm của chính họ. Đó là nơi bạn có thể xác định rằng dự án sẽ yêu cầu cả năm làm việc. Chỉ xem xét rằngProduct Owner

Đó là trong quá trình Sprint Planning MeetingNhóm sẽ cam kết về những gì sẽ được phát triển cho lần tiếp theo Sprint, do đó tạo ra Sprint Backlog. Nó Sprint Backlogbao gồm một tập hợp con dựa trên Product Backlog Itemscác Teamcam kết sẽ được thực hiện ở cuối Sprint. Ví dụ, xem xét một tồn đọng sản phẩm của 50 mặt hàng và tất cả 50 mặt hàng sẽ cần một năm để hoàn thành, sau đó Nhóm có thể muốn chọn giả sử 5 mặt hàng từ tồn đọng sản phẩm và tạo ra tồn đọng Sprint với 5 mặt hàng này. 5 Mục tương tự này có thể được mở rộng / phát nổ thành nhiều Mục khác khi được yêu cầu, do đó, Nhóm có thể thay đổi ý định sau khi sửa đổi và cam kết chỉ thực hiện 4 Mục trong số 5 Mục đã chọn trước đó từ Product Backlog.

Khi Cuộc họp Lập kế hoạch Sprint kết thúc, có thể kéo dài không quá 8 giờ cho cả tháng Sprint, trong đó Nhóm không chỉ cam kết thực hiện công việc cho các Mục đã chọn, nhưng lên kế hoạch về cách nó sẽ hoàn thành công việc để mọi người trong Đội biết chính xác những gì cô ấy / anh ấy phải làm, Sprintsẽ bắt đầu. Điều quan trọng là Nhóm phải có chức năng chéo vì lợi ích của dự án.

Điều đó nói rằng, vào cuối mỗi Sprint, kéo dài một tháng trong tình huống hiện tại, tất cả các Mục mà Teamcam kết thực hiện sẽ là một phần có thể cung cấp của (các) tính năng đầy đủ chức năng nhắm mục tiêu các Mục được chọn từ Product Backlog. Nó phải được giao, nhưng không bắt buộc phải giao nếu nó không có ý nghĩa để làm như vậy theo Product Owner.

Đó là trong trường Sprint Review Meetinghợp Product Ownerbắt buộc phải triệu tập rằng nó Teamthể hiện những gì đã được thực hiện trong Sprint và nơi nó cần cho biết tại sao nó không được thực hiện, nếu có thể, tất cả các công việc mà nó cam kết. Công việc hoàn tác sau đó được đưa trở lại Product Backlogvà có sẵn cho lần tiếp theo Sprint. Chắc chắn các Mục hoàn tác này sẽ được đưa vào Sprint tiếp theo trừ khi Chủ sở hữu sản phẩm nói khác, trong trường hợp mục tiêu đã thay đổi. Nhưng quan trọng nhất, mặc dù mục tiêu của một hệ thống đã thay đổi trong Sprint, nhưng đừng làm gián đoạn nó trừ khi thực sự cần thiết. Chỉ Chủ sở hữu sản phẩm mới có quyền làm gián đoạn Sprint.

Khi quá trình Sprint Review Meetingkết thúc, sẽ kéo dài không quá 4 giờ cho một Sprint hàng tháng (nếu tôi nhớ chính xác), đã đến lúc đi đến Sprint Retrospective Meeting. Điều Sprint Retrospectivebắt buộc Teamphải xảy ra để có thể thảo luận, với sự có mặt của Scrum Master và Chủ sở hữu sản phẩm (tùy chọn) đã xảy ra lỗi, Nhóm Scrum có thể cải thiện hiệu suất của mình như thế nào, v.v. và đưa ra các điều chỉnh phù hợp.

Khi hộp thời gian cho kết Sprint Retrospectivethúc, sau đó cái mới Sprint Planning Meetingsẽ xảy ra để lập kế hoạch tiếp theo Sprintvà tạo cái mới Sprint Backlog.

Hãy nhớ rằng, Teamcó trách nhiệm duy trì Daily Scrumcuộc họp độc lập kéo dài 15 phút trong đó mỗi Thành viên trong nhóm trả lời ba câu hỏi (không theo thứ tự cụ thể đó):

1. Bạn đã làm gì kể từ Scrum hàng ngày cuối cùng?
2. Bạn dự định làm gì cho đến Scrum hàng ngày tiếp theo?
3. Các vấn đề hoặc trở ngại mà bạn gặp phải kể từ Scrum hàng ngày cuối cùng là gì?

Các Scrum Masterkhông có nghĩa vụ phải có mặt ở đó nhưng là cần thiết để đảm bảo rằng đội gặp tại Scrum hàng ngày và các thành viên trả lời ba câu hỏi đúng.

Scrum Master chịu trách nhiệm tôn trọng các Quy tắc Scrum của các Thành viên Nhóm Scrum khác (Scrum Master, Chủ sở hữu sản phẩm và Nhóm).

Cuối cùng, tuân theo các quy tắc đơn giản này, nhóm phát triển của bạn sẽ trở nên nhanh nhẹn. Agility là khả năng bắt kịp mọi thay đổi nhanh nhất có thể, đó là vào cuối mỗi Sprint, nơi nó có thể nhận ra những thay đổi do Chủ sở hữu sản phẩm mang lại cho Product Backlog. Trong trường hợp thảm họa hoàn toàn và thay đổi hoàn toàn định hướng, số tiền bị mất tối đa mà công ty phải chịu là một tháng phát triển, điều này khá lơ là, vì chỉ có khoảng 20 ngày làm việc trong một tháng.

Nếu bạn cần thêm thông tin chi tiết về Phát triển phần mềm Scrum và Agile, vui lòng tham khảo Scrum.org và Hướng dẫn Scrum của họ .

Vâng, đó là một câu trả lời khá! Tôi hy vọng điều này ít nhất sẽ giúp bạn thông qua quản lý dự án của bạn.

EDIT # 1

Mặc dù bạn đang lên kế hoạch thực hiện ba hoặc bốn giai đoạn, như bạn gọi nó, nhiều khả năng Nhóm của bạn sẽ mất tập trung từ quan điểm mục tiêu chính. Nếu bạn chứng minh chỉ sau quý đầu tiên những gì Nhóm của bạn đã thực hiện, có thể có một số thay đổi quan trọng sẽ yêu cầu thiết kế lại quan trọng và suy nghĩ lại về kiến ​​trúc phần mềm của bạn, có thể mất hơn 20 ngày làm việc. Nguyên tắc nhanh nhẹn là có thể bắt kịp với những thay đổi ngay khi chúng xảy ra, hoặc ngay khi có thể trong một khoảng thời gian hợp lý, đó là đối với Scrum, hộp thời gian của Sprint.

1. Tôi nghĩ bạn nên có nhiều lần ra mắt nhất có thể. Phản hồi / số liệu thực sự duy nhất cho tiến trình phát triển phần mềm là mã được triển khai trong sản xuất. Vì vậy, bất cứ quy trình nào bạn sử dụng, bạn càng thường xuyên triển khai trực tiếp, bạn càng nhanh nhẹn hơn. Tức là, bạn nhận được phản hồi thực từ người dùng thực sự sớm hơn và có thể thích nghi sớm hơn.

2. Mặc dù bạn không nên thực hiện Big Design Up Front , tôi nghĩ thật tốt khi nghĩ về bức tranh lớn mỗi khi bạn điều chỉnh và bổ sung lượng tồn đọng, cho cả Scrum (cho lần chạy nước rút tiếp theo) và Kanban / dòng chảy (khi có phòng trong giới hạn WIP). Nếu bạn xem xét toàn bộ (sản phẩm, dịch vụ, v.v.), sẽ dễ dàng hơn để xem xét những mục công việc nào sẽ mang lại cho bạn nhiều giá trị hơn tiếp theo.

3. Hãy nhận biết rằng bức tranh lớn thay đổi. Như thường xuyên khi bạn xem xét tồn đọng, điều chỉnh các ưu tiên, vv, cũng xem xét các thay đổi đối với bức tranh lớn. Mọi thứ thay đổi theo thời gian, bao gồm nhu cầu của khách hàng cụ thể và thậm chí toàn bộ thị trường. Bức tranh lớn của bạn nên phản ánh điều này để các ưu tiên của bạn có thể được liên kết với thực tế mỗi khi bạn bổ sung hồ sơ tồn đọng, và không chỉ khi bắt đầu khi bạn thực hiện kế hoạch.

Tóm lại, tôi nghĩ rằng bạn càng nhanh nhẹn thì bạn càng kiểm tra và thích nghi.

Kế hoạch hình ảnh lớn không mất nhiều thời gian và điều quan trọng đối với các dự án lớn là phải có bức tranh lớn khi bạn xác định nước rút của mình, các phím tắt khác được thực hiện trong một lần chạy nước rút có thể gây ra vấn đề về sau.

Bạn nên:

1. Có một kế hoạch tổng thể (tốt nhất là không có thời hạn kèm theo), điều đó sẽ phát triển khi bạn đi.

2. Khi bạn xác định một lần chạy nước rút, bạn chắc chắn rằng cuộc chạy nước rút phù hợp với bức tranh lớn. Điều này không phải lúc nào cũng có nghĩa là bạn thay đổi ý tưởng về những gì mong muốn cho lần chạy nước rút. Đôi khi bạn sẽ phát hiện ra, khi xác định một lần chạy nước rút, bức tranh lớn của bạn nên được điều chỉnh. Bằng cách này hay cách khác, kế hoạch hình ảnh lớn và nước rút phải phù hợp với nhau đi vào nước rút.

3. Kế hoạch tổng thể nên được điều chỉnh khi bạn đi. Bạn sẽ học được những điều khi bạn làm việc. Cơ hội mới sẽ xuất hiện, những điểm xung đột trong kế hoạch sẽ xuất hiện. Bạn có thể điều chỉnh kế hoạch tổng thể khi đang bay. Nhưng hầu như luôn luôn bạn nên xem lại nó giữa các lần chạy nước rút - để kết hợp các bài học từ lần chạy nước rút cuối cùng, và để đảm bảo lần chạy nước rút tiếp theo hài hòa với bức tranh lớn.

Tôi nghĩ rằng tốt nhất nếu tồn đọng và kế hoạch dự án lớn là các cấu trúc riêng biệt. Chủ dự án lớn giữ kế hoạch tổng thể ở định dạng phác thảo phân cấp để duy trì bối cảnh, và sau đó các tính năng / nhiệm vụ có thể được kéo từ đó để cung cấp cho hồ sơ tồn đọng, từ đó sẽ đưa nước rút tiếp theo.

Các hồ sơ tồn đọng, không giống như kế hoạch tổng thể, có thể được thêm vào bởi các thành viên khác trong nhóm. Tùy thuộc vào chủ dự án chính để đảm bảo các mục tồn đọng và kế hoạch hình ảnh lớn luôn hài hòa - đôi khi điều chỉnh mục tồn đọng và đôi khi là kế hoạch hình ảnh lớn.

Phương pháp này duy trì sức mạnh của sự nhanh nhẹn và sức mạnh của việc sắp xếp tất cả các yếu tố của dự án của bạn tốt nhất có thể tại một thời điểm nhất định thông qua kế hoạch hình ảnh lớn.

Jim

Tôi sẽ thêm hình thức ngắn của câu thần chú chống Agile của tôi vào đây.

Agile có thể rất phá hoại đối với các dự án lớn, đặc biệt là khi xây dựng các thư viện và khung công tác sẽ là nền tảng cho sự phát triển trong tương lai. Một mối quan tâm thực sự quan trọng trong giai đoạn đầu là "thiết kế của tôi có hỗ trợ các tính năng chúng tôi cần cung cấp trong năm tới không?". Hầu hết các chiến lược Agile không cho phép kiểu suy nghĩ chuyển tiếp đó và do đó, các điểm thất bại của dự án được tạo ra.

Tôi hơi đau về điểm này vì bản thân tôi vừa bị bỏng. Chúng tôi đang viết lại một số thư viện cốt lõi của chúng tôi. Các giai đoạn đầu tiên đã được thực hiện và đáp ứng các mục tiêu tính năng cho lần chạy nước rút của họ. Tất cả đều rất nhanh nhẹn. Sau đó, tôi được đưa lên tàu để thêm một số tính năng tải động. Tuy nhiên, tôi đã bị đình trệ khoảng sáu tuần vì những gì được viết trước đây giả định sẽ không bao giờ tải động, tôi đã lãng phí rất nhiều thời gian để viết lại và làm việc xung quanh những gì đã có. Phần tồi tệ nhất là, tải động là trong thông số kỹ thuật khi bắt đầu; có công việc ban đầu ghi nhớ tất cả các yêu cầu trong tương lai và thực hiện 'công việc thiết kế lớn lên phía trước' mà các thực tiễn nhanh nhẹn coi là xấu, tôi có thể đã thực hiện tính năng của mình trong vài ngày.

Bài học là, sử dụng nhanh nhẹn cho những việc nhỏ bạn sẵn sàng vứt bỏ. Nó có thể là tuyệt vời đôi khi. Tuy nhiên, đó không phải là Cách phát triển phần mềm đích thực. Khi viết mã nền tảng có rủi ro cao hoặc sẽ có tuổi thọ dài, hãy thực hiện thiết kế lớn.