Làm thế nào thường xuyên để bạn phát hành trong một lần chạy nước rút. Chỉ ở cuối giai đoạn nước rút hoặc mỗi khi một tính năng đã sẵn sàng. Và làm thế nào để bạn xử lý các bản phát hành lỗi?
Câu trả lời:
TL; DR: Phát hành bất cứ khi nào thích hợp
Chúng tôi phát hành bất cứ khi nào có giá trị trong việc phát hành. Đôi khi, điều đó có nghĩa là thực hiện một bản phát hành sau khi một tính năng hoặc sửa lỗi hoàn thành. Đôi khi điều đó có nghĩa là phát hành một bộ sưu tập các tính năng và / hoặc sửa lỗi.
Điều này không có nghĩa là chúng ta thường có "tình huống khẩn cấp" đòi hỏi phải phát hành nhanh. Điều đó có nghĩa là chúng tôi đã làm việc chăm chỉ để phát hành dễ dàng. Mã của chúng tôi được kiểm tra, gắn thẻ và đóng gói với mọi bản dựng. Chúng tôi sử dụng các thử nghiệm chấp nhận tự động và kết quả là chúng tôi đã phát triển độ tin cậy cao đối với mã vượt qua các thử nghiệm của nó. Vì các gói của chúng tôi ngay lập tức có sẵn thông qua một repo yum địa phương triển khai một bản phát hành là không đáng kể.
Không bao giờ trong thời gian. Điều đó vi phạm tiền đề cơ bản của một "nước rút". Bạn chạy cho đến khi bạn hoàn thành những gì bạn cam kết hoàn thành. Sau khi bạn hoàn thành, nó thực sự được thực hiện và thực sự hoạt động. Sau đó bạn có thể phát hành nó.
Phát hành có thể là một loại nước rút riêng biệt, nơi mọi thứ được đóng gói để phát hành.
Phát hành sửa lỗi có thể chỉ là nước rút ngắn. Không có một lịch trình thường xuyên của nước rút cùng chiều dài được nhiều người coi là một ý tưởng tồi. Do đó, quy tắc thông thường là sửa lỗi đơn giản là công việc có mức độ ưu tiên cao xảy ra trong lần chạy nước rút tiếp theo .
Nếu đó là một trường hợp khẩn cấp, bạn đã có quá nhiều thứ đang diễn ra - hỗ trợ và phát triển - và bạn nên xem xét việc thay đổi tổ chức để có ít việc xảy ra hơn.
Nếu công việc mà nhóm cam kết thực hiện có lợi cho việc thực hiện nhiều bản phát hành trong giai đoạn nước rút, hãy phát hành nó bao nhiêu lần bạn muốn.
Điều tương tự cũng đúng đối với các bản phát hành sửa lỗi - nếu có ý nghĩa để phát hành chúng, hãy làm như vậy.
Công việc Agile cuối cùng tôi làm việc đã phát hành mọi lần chạy nước rút; mã đã bị đóng băng vào mỗi thứ Năm khác (nước rút hai tuần), và sau đó sản phẩm được đóng gói và xuất bản lên máy chủ UAT để khách hàng của chúng tôi làm việc. Điều này là trong quá trình phát triển ban đầu của sản phẩm; đối với một sản phẩm trưởng thành, đặc biệt là chương trình có thể phân phối và không phải là ứng dụng web, có lẽ bạn sẽ không muốn gây gánh nặng cho người dùng của mình khi nâng cấp cứ sau hai đến ba tuần.
Hầu như tất cả các bản phát hành của chúng tôi bao gồm một hỗn hợp các điểm câu chuyện và khiếm khuyết (lỗi). Khiếm khuyết được tính là "giờ không lý tưởng"; có 5 giờ lý tưởng trong một ngày làm việc, nghĩa là mã hóa từ đầu xuống của công việc điểm mới. Ba đến bốn giờ khác mỗi ngày là các cuộc họp, thảo luận, thiết kế, đôi khi là "gai" (nghiên cứu tập trung / phát triển bằng chứng khái niệm) và công việc khiếm khuyết; những thứ đóng góp cho một sản phẩm tốt hơn và là một phần cần thiết của quy trình, nhưng đơn giản là không thể chiếm toàn bộ nước rút của toàn đội. Lần duy nhất chúng tôi thực hiện các bản phát hành chỉ khiếm khuyết là khi không có tác phẩm điểm truyện có sẵn trong hồ sơ tồn đọng như một IPM; sau đó chúng tôi chỉ cần lên lịch chạy nước rút QA nơi chúng tôi được hướng dẫn "tiêu diệt càng nhiều khuyết điểm càng tốt". Bởi vì không có yêu cầu sẵn sàng để đi là LUÔN LUÔN lỗi của PO (và PO làm việc cho khách hàng), chúng tôi chỉ đơn giản là có thể đưa ra một thông báo thay đổi hợp đồng và làm việc với những gì chúng tôi đã có. Tất nhiên, một khi công việc câu chuyện thực tế đã kết thúc và chúng tôi đã phát triển "bảo hành", tất cả đều có lỗi.
Trong một dự án Agile được quản lý tốt, không bao giờ xảy ra yêu cầu; tồn đọng phải luôn luôn có giá trị công việc chạy nước rút sẵn sàng để nhận. Nhưng, đôi khi PO bị ngập trong các yêu cầu sản xuất; đôi khi các BA / người kiểm tra giữ việc phát hành các câu chuyện cho tồn đọng phát triển, vì các lý do liên quan đến chất lượng yêu cầu hoặc xung đột câu chuyện; đôi khi một nhóm quyết định họ phải "dồn nén" vào một câu chuyện không được xác định rõ ràng hoặc được ước tính tốt, và không có thứ gì có thể dễ dàng chiếm các chu kỳ còn lại. Trong ngắn hạn, ngay cả trong Agile, shit xảy ra.
Bạn có ý nghĩa gì khi phát hành? Nếu bạn có nghĩa là PSP - có thể là sản phẩm có thể chuyển đổi, bạn có hai tùy chọn:
Sự khác biệt chính giữa cấp 2 và cấp 3 là ở cấp 2, bạn phải nỗ lực để tạo PSP cuối cùng ở cuối nước rút, nhưng ở cấp 3, bạn đã bỏ ra một số tiền và công sức ban đầu cho các công cụ và cấu hình của mình và bạn đã chuẩn bị PSP tự động mọi lúc = không có nỗ lực thủ công liên quan. Hoàn toàn đạt được cấp 3 là rất hiếm.
Hoàn toàn không có quy tắc nào trong Scrum về thời điểm các tính năng mới có thể được triển khai. Mỗi nhóm cần có một "định nghĩa hoàn thành", luôn luôn bao gồm một số tiêu chí về thử nghiệm. Khi một tính năng được "hoàn thành", nó đã sẵn sàng cho thế giới thực và nếu không có bất kỳ sự phụ thuộc hoặc điều kiện nào khác cần được đáp ứng trước khi có thể triển khai, thì không có lý do gì để chờ kết thúc Sprint triển khai nó.
Không có nghĩa là nó không được trình bày tại cuộc họp Lập kế hoạch / Đánh giá của Sprint. Khái niệm này là mọi thứ mà Nhóm đã hoàn thành được hiển thị cho PO (và các doanh nghiệp vừa và nhỏ khác của khách hàng) để họ có thể kết hợp nó vào sự hiểu biết ngày càng tăng của họ về hệ thống khi nó phát triển.
Sau một vài tuần, chúng tôi tìm thấy một giải pháp tốt phù hợp với nhu cầu của chúng tôi. Chúng tôi quyết định phát hành khi nào chúng tôi muốn. Làm thế nào chúng ta làm điều đó:
Đó là nó. Chúng tôi sử dụng git và maven làm hệ thống CI và chúng tôi có phạm vi kiểm tra tốt. Đó là một trong những lý do chúng ta có thể làm như thế này.
Trả lời một câu hỏi gần 2 tuổi có thể hơi dư thừa, nhưng để hy vọng thêm giá trị cho những người khác đến với câu hỏi này, tôi muốn thêm 2 tuổi hoặc hơn. :)
Để trả lời câu hỏi: Tốt nhất bạn nên phát hành những gì đã cam kết trong lần chạy nước rút, vào cuối giai đoạn nước rút đó. Làm như vậy liên kết với tất cả các bộ phận / quy trình / hướng dẫn khác của scrum nhằm hướng đến việc đạt được giá trị kinh doanh tốt nhất vào đúng thời điểm.
NHƯNG trường hợp khẩn cấp, lỗi, sự kiện bất ngờ, vv có thể buộc bạn, đó là nơi mà khái niệm nếu "Lập kế hoạch phát hành" có thể có ích. Với "Lập kế hoạch phát hành", tôi không có nghĩa là lập kế hoạch theo kiểu thác nước mà là lập kế hoạch cho những kỳ vọng có thể giúp quản lý tồn đọng sản phẩm và mức độ ưu tiên của các câu chuyện trong các lần chạy nước rút.
Nhưng có lẽ nhận xét của David về câu hỏi là điều cần xem xét tốt nhất. Scrum không phải lúc nào cũng là câu trả lời đúng.