Trong Scrum, các tác vụ như thiết lập môi trường phát triển và phát triển khả năng có nên được quản lý như các nhiệm vụ trong các câu chuyện người dùng thực tế không?

Đôi khi trong các dự án chúng ta cần dành thời gian cho các nhiệm vụ như:

1. khám phá các khung và công cụ thay thế
2. học khung và công cụ được chọn cho dự án
3. thiết lập các máy chủ và cơ sở hạ tầng dự án (kiểm soát phiên bản, xây dựng môi trường, cơ sở dữ liệu, v.v.)

Nếu chúng ta đang sử dụng Câu chuyện người dùng, tất cả công việc này nên đi đâu?

Một tùy chọn là làm cho tất cả chúng là một phần của câu chuyện người dùng đầu tiên (ví dụ: tạo trang chủ cho ứng dụng). Một lựa chọn khác là làm tăng đột biến cho các nhiệm vụ này. Tùy chọn thứ ba là biến nhiệm vụ thành một phần của Vấn đề / Trở ngại (ví dụ: môi trường phát triển chưa được chọn) thay vì Câu chuyện của người dùng.

Chúng tôi đã nghĩ về vấn đề này khá nhiều trong năm qua.

Mặc dù tôi đồng ý rằng một khung cơ bản nên tồn tại trước khi dự án bắt đầu, trong thực tế sử dụng, nó có thể là một phần của chính dự án. Vì vậy, bạn phải quản lý bằng cách nào đó.

Mặc dù trộn thiết lập dự án với các câu chuyện của người dùng có thể có ý nghĩa đôi khi chúng tôi đã giải quyết các tác vụ đơn giản có thể được thêm vào hồ sơ tồn đọng của sản phẩm và nhận được sự chú ý giống như các câu chuyện của người dùng. Chúng tôi biết rằng đôi khi các nhiệm vụ kỹ thuật này là cần thiết, nhưng chúng phải được chứng minh trong mọi trường hợp. Nếu nhóm nghĩ rằng họ thực sự cần thiết để đạt được một mục tiêu nhất định, họ sẽ là một phần của cuộc chạy nước rút.

Thật khó để nói những gì tốt nhất cho bạn, vì vậy hãy thử nghiệm ! Một sự tăng đột biến có thể đủ cho bây giờ, nhưng tôi nghĩ rằng bạn sẽ kết thúc với cùng một vấn đề sau đó, vì vậy hãy lên kế hoạch trước. Làm các nhiệm vụ là một giữ chỗ cho các hoạt động như vậy. Để tách nhiệm vụ khỏi câu chuyện hai, tôi sẽ nhanh chóng so sánh chúng dựa trên kinh nghiệm của tôi với chúng.

Nhiệm vụ: Một nhiệm vụ là một sự cần thiết kỹ thuật. Nó có thể là những thứ để quản lý cấu hình hoặc thiết lập dự án chung, như thiết lập một kho lưu trữ để xác nhận hoặc thêm công cụ đánh giá mã nóng nhất bạn từng thấy trong quá trình phát triển. Nhiệm vụ nên được xem xét trong kế hoạch, giống như một câu chuyện người dùng. Nếu nhóm có thể thuyết phục chủ sở hữu sản phẩm rằng có công cụ đánh giá mã mới nhất và lớn nhất sẽ tăng hiệu suất và tăng giao tiếp nhóm bằng cách loại bỏ các phiên lập trình cặp kéo dài hoặc đánh giá mã trực tiếp, thì nó sẽ thu hút sự chú ý của chủ sở hữu sản phẩm.

Câu chuyện : Chỉ tập trung vào quan điểm kinh doanh, những câu chuyện luôn tạo ra giá trị hữu hình cho khách hàng. Chất lượng nội bộ là một cái gì đó đi cùng với sản xuất giá trị kinh doanh.

Chúng tôi thậm chí chỉ định các điểm câu chuyện cho các nhiệm vụ và đôi khi làm việc với chúng giống như chúng ta sẽ làm với các câu chuyện.

Cuối cùng tôi sẽ đi đến giải pháp này trong trường hợp của bạn (cũng có thể được áp dụng chung):

1. Tách "thiết lập" và các công cụ kỹ thuật thành các nhiệm vụ (công cụ không trực tiếp tạo ra giá trị kinh doanh cho chủ sở hữu sản phẩm).
2. Có thể tăng đột biến trước khi thiết lập dự án để đưa các công cụ quan trọng nhất vào vị trí (SCM, công cụ dev, định nghĩa quy trình, tiêu chuẩn mã hóa, v.v.)
3. Chấp nhận rằng các nhiệm vụ này xuất hiện trong suốt thời gian của dự án và lập kế hoạch cho việc này bằng cách có một "loại" hoạt động riêng biệt ngoài các câu chuyện.

Làm bất cứ điều gì có ý nghĩa nhất trong công ty của bạn. Đừng bao giờ để người khác làm những điều gây trở ngại cho lẽ thường.

Nhưng tôi sẽ nói rằng tất cả các nhiệm vụ này nghe có vẻ như là điều gì đó sẽ xảy ra rất lâu trước khi bạn bắt đầu phát triển. Vì vậy, tôi đặt câu hỏi liệu Scrum thậm chí có liên quan đến các nhiệm vụ này. Có một số bảo trì liên tục và như vậy để kiểm soát nguồn và cơ sở dữ liệu, nhưng chúng không nên được lên lịch, chúng chỉ nên là những thứ xảy ra và ảnh hưởng đến vận tốc của bạn.

Sẽ có lúc bạn phải chọn một khung công tác hoặc bất cứ điều gì trong một dự án, nhưng khi tôi nói rằng tôi có nghĩa là một khung như nHibernate, không phải là một khung như .NET. Trong những trường hợp đó, nghiên cứu nên được tăng vọt và thời gian, không đề cập đến khá ngắn. Cố gắng quản lý nó như thể bạn có một nhà phát triển bị ốm trong một vài ngày.

Chuyển giao kiến ​​thức là một quá trình liên tục khác cần được quản lý ngoài tốc độ phát triển chung.

Có một cái tên để đưa ra càng nhiều quyết định thiết kế càng tốt trước khi bắt đầu "chính thức" dự án của bạn. Nó được gọi là thác nước. Không có gì sai với những câu chuyện của người dùng như "Là một nhà phát triển, tôi cần chọn một khung công tác, vì vậy chúng tôi có một điểm khởi đầu cho trang web." Nếu nó quá lớn để phù hợp với một lần lặp, hãy thử chia nhỏ nó ra, "Là một nhà phát triển, tôi cần triển khai một trang chủ cơ bản trong Drupal, vì vậy chúng tôi sẽ biết liệu nó có phù hợp với nhu cầu của chúng tôi không."

Một tùy chọn là làm cho tất cả chúng là một phần của câu chuyện người dùng đầu tiên, ví dụ: tạo trang chủ cho ứng dụng.

Phá vỡ "câu chuyện người dùng" như một khái niệm. Những gì người dùng có liên quan trong việc này? Không ai. Đây là công việc bạn nên đã làm.

Một lựa chọn khác là làm tăng đột biến cho việc này.

Không tệ.

Tùy chọn thứ ba là biến nhiệm vụ thành một phần của Vấn đề (ví dụ: môi trường phát triển chưa được chọn) thay vì Câu chuyện của người dùng.

Về giống như một sự tăng đột biến khi có liên quan đến kế hoạch và chi phí chung.

Thiết lập không phải là một câu chuyện người dùng.

Đó là những gì bạn nên có tại chỗ trước khi bạn bắt đầu dự án này.

Bạn không thể thực sự bắt đầu dự án trừ khi bạn có thiết lập khung / công cụ và máy chủ và sẵn sàng hoạt động.

Tôi biết rõ rằng nhiều tổ chức không thực sự tồn tại cho đến khi hợp đồng được ký kết. Tôi cũng nhận thức được rằng nhiều tổ chức không chọn công nghệ cho đến khi hợp đồng được ký kết. Đây là tất cả những điều không hiệu quả nằm ngoài bất kỳ câu chuyện của người dùng.

Trong công việc, chúng tôi sử dụng một nhiệm vụ để chuẩn bị môi trường. Nó có thể gây nhầm lẫn cho một số người nhưng nhiệm vụ chúng ta sử dụng rất giống với nhiệm vụ từ câu chuyện của người dùng. Nhiệm vụ không thuộc về câu chuyện của người dùng nhưng được ước tính theo giờ và phải được chủ sở hữu sản phẩm đồng ý để hoàn thành trong một lần chạy nước rút cụ thể.

Chúng tôi cũng sử dụng tác vụ cho công việc kiến ​​trúc không có giá trị kinh doanh "rõ ràng" nhưng điều đó làm tăng chất lượng cho sản phẩm đặc biệt đối với một sản phẩm hiện có với cơ sở mã lớn.

Chúng có thể không áp dụng trong môi trường làm việc của bạn nhưng nó hoạt động tốt với chúng tôi.

Tôi nghĩ rằng bạn đang trộn lẫn hai thứ độc lập. Một câu chuyện người dùng không nên bao gồm bất kỳ chi tiết kỹ thuật.

Việc lựa chọn khung, thiết lập kho lưu trữ và máy chủ và các tác vụ khác, sẽ đi vào bước lặp ban đầu.

Tôi đã tham gia một khóa học Scrum gần đây và người hướng dẫn gợi ý rằng một cuộc chạy nước rút đặc biệt có tên Sprint 0 nên được sử dụng để giải quyết chính xác các loại vấn đề này. Có những người trong khóa học với các mức độ kinh nghiệm khác nhau trong Scrum và gần như tất cả những người có kinh nghiệm đều đồng ý, nói rằng họ đã làm điều tương tự. Trong một số trường hợp, các công ty đã sử dụng Sprint 0 để đánh giá dự án và quyết định xem nó có khả thi hay không.

Đối với một người mới làm quen với phương pháp Scrum như tôi, nó có vẻ là một giải pháp tuyệt vời vì nó giúp bạn không bị câu chuyện của người dùng và tất cả các khía cạnh khác của một lần chạy nước rút bình thường như phản hồi của người dùng.

Vì Sprint 0 có cùng thời gian với các lần chạy nước rút khác của bạn, nó hoạt động như một cách đảm bảo bạn không mất quá nhiều thời gian để thiết lập mọi thứ vì chúng luôn có thể được điều chỉnh sau đó. Điểm chính là đưa bản thân vào trạng thái mà bạn thực sự có thể bắt đầu phát triển sản phẩm.

khám phá 2-3 khung / công cụ thay thế

Đôi khi điều này có thể xảy ra nếu bạn có yêu cầu đặc biệt, bạn phải thực hiện một số POC để chọn công cụ tốt nhất để giải quyết yêu cầu. Đây là những gì tăng đột biến vì không biết bạn sẽ sử dụng khuôn khổ nào, có lẽ bạn không thể ước tính câu chuyện và lưu trữ mà không ước tính không thể được lên kế hoạch và chia thành các nhiệm vụ.

sau đó học về khung công tác chúng tôi chọn cho dự án

Tốt. Điều này khá nguy hiểm. Khi khách hàng trả tiền cho bạn cho một SW, anh ta hy vọng rằng bạn là người chuyên nghiệp, người đã biết cách sử dụng các công cụ của anh ta. Khách hàng không trả tiền cho bạn cho việc học hoặc phương pháp phát triển thử nghiệm / thất bại. Nhà phát triển có trách nhiệm tìm hiểu các công cụ mới trong thời gian rảnh hoặc trong thời gian được phân bổ đặc biệt do nhân viên của mình trả không phải bởi khách hàng. Tiêu tiền của khách hàng cho việc học mà không thông báo cho khách hàng là không chuyên nghiệp.

Nếu bạn thực sự phải sử dụng thứ gì đó đặc biệt (ví dụ: một số khách hàng API hoặc công cụ của khách hàng đã chọn) mà bạn chưa từng sử dụng trước khi bạn phải thông báo cho khách hàng rằng giá sẽ tăng theo thời gian cần thiết để tìm hiểu cách sử dụng API. Có thể khách hàng sẽ thay đổi ý định nếu mức tăng giá sẽ quá lớn.

Chắc chắn, tôi không có nghĩa là tình huống mà bạn phải tìm kiếm một số vấn đề mới cụ thể trong khuôn khổ bạn đã sử dụng nhiều lần. Ý tôi là tình huống bạn bắt đầu sử dụng API hoặc khung mới mà không dành thời gian đáng kể (bên ngoài dự án) để học.

Nếu bạn vi phạm điều này, nó sẽ được hiển thị trong vận tốc của bạn bởi vì bạn sẽ cung cấp một lượng rất nhỏ giá trị doanh nghiệp trên mỗi lần lặp. Nếu khách hàng không biết lý do, rất có thể anh ta sẽ hủy dự án.

Điều này vẫn hợp lệ trong trường hợp các dự án nội bộ - bạn phải thông báo cho người quản lý / doanh nghiệp của mình về thời gian cần thiết để học API hoặc công cụ mới. Nó thường có hậu quả rất xấu nếu người quản lý tính với năng suất bình thường của bạn và năng suất của bạn chỉ là một phần nhỏ do API mới mà bạn đang cố gắng học trong các nhiệm vụ của mình. Điều đó rõ ràng còn tồi tệ hơn nếu một số người bán hàng tính toán với năng suất bình thường khi ký hợp đồng với khách hàng.

khi thiết lập máy chủ (SVN, Cơ sở dữ liệu, v.v.)

Đó là cơ sở hạ tầng và chi phí nội bộ của bạn. Khi bạn bắt đầu dự án, dự kiến ​​bạn đã chuẩn bị cơ sở hạ tầng. Thiết lập môi trường phát triển của bạn không có giá trị cho khách hàng và không nên là một phần của bất kỳ chỉ số nào liên quan đến dự án - ví dụ như vận tốc trong Scrum. Tôi thấy điều này được thực hiện như là lần lặp trước dự án đặc biệt chỉ được sử dụng để thiết lập môi trường, tạo cơ sở hạ tầng cơ bản, v.v.