Làm thế nào để phát hành thường xuyên với Lean/Kanban?

Question

Tôi khá mới với Lean/Kanban, nhưng đã đổ qua các tài nguyên trực tuyến trong vài tuần qua và đã đưa ra một câu hỏi mà tôi đã không tìm thấy câu trả lời hay cho. Lean/Kanban có vẻ khác phù hợp với công ty chúng tôi, người đã sử dụng Scrum, nhưng đã đạt đến một số hạn chế bên trong phương pháp đó. Tôi hy vọng một ai đó ở đây có thể cho tôi một ý tưởng hay.

Như tôi đã thấy, một trong những lợi thế lớn nhất của Scrum trên Thác là sử dụng chạy nước rút. Bằng cách chuẩn bị mọi thứ cứ 14 ngày một lần, bạn có chu kỳ phản hồi ngắn và có thể phát hành thường xuyên. Tuy nhiên, như tôi đã hiểu từ việc đọc về Lean, có một số chi phí liên quan đến điều này (ví dụ, thời gian dành cho các cuộc họp lập kế hoạch chạy nước rút, các cuộc họp cam kết nhóm & một số vấn đề với việc tìm kiếm điều gì đó hữu ích cho mọi người ở cuối nước rút).

Lean/Kanban sẽ xóa các chất thải này, nhưng chỉ với chi phí không thể phát hành sau 14 ngày. Hay tôi đã bỏ lỡ một điểm quan trọng? Đối với, tại Kanban, làm thế nào bạn có thể làm việc trên các nhiệm vụ phát triển mới và phát hành cùng một lúc? Làm thế nào để bạn chắc chắn rằng bạn không gửi một cái gì đó mà chỉ nửa chừng được thực hiện? Và làm thế nào bạn có thể kiểm tra nó đúng cách?

"giải pháp/ý tưởng" My tốt nhất cho đến nay là:

• Đừng phát hành thường xuyên và cho phép chất thải liên quan đến cạn kiệt các nhiệm vụ phát triển mới. Không thực sự là một giải pháp cho câu hỏi được hỏi mặc dù.
• Phát triển trong các nhánh và sau đó nhập vào thân chính. Làm cho bạn phải hỗ trợ ít nhất hai chi nhánh liên tục trong nội bộ.
• Sử dụng một số hệ thống ghi nhãn tự động thông minh để chỉ tự động xây dựng một số tác vụ đã hoàn thành nhất định chứ không phải chỉ các tác vụ khác.

Tóm tắt, câu hỏi của tôi là: Khi bạn sử dụng Lean/Kanban, bạn có thể phát hành thường xuyên mà không giới thiệu rác thải không? Hoặc là phát hành thường là không phải là một phần của Lean/Kanban?

Bổ sung thông tin cụ thể để công ty của tôi: Chúng tôi sử dụng Team System Foundation & Nguồn Kiểm soát và trước đây đã có một số kinh nghiệm xấu liên quan đến phân nhánh và sáp nhập. Điều này có thể được giải quyết đơn giản bằng cách đưa vào một số chuyên môn trong lĩnh vực này?

Answer 1

Sự cố bạn mô tả có vẻ là chương trình kiểm soát nguồn hơn - cách tách các tính năng được thực hiện khỏi các tính năng đang diễn ra, so với Kanban. Bạn dường như đặt một hình phạt nặng nề khi chạy nhiều nhánh - đó là trường hợp cho các hệ thống kiểm soát nguồn không dựa trên ý tưởng của nhiều nhánh. Trên các hệ thống kiểm soát nguồn phân tán, chẳng hạn như GIT và Mercury, mọi thứ là một chi nhánh, có chúng và làm việc với chúng là nhẹ.

Tôi giả sử bạn đọc this blog về Kanban so với SCRUM và hướng dẫn thực tiễn liên quan?

Và, để trả lời câu hỏi của bạn, có, bạn có thể phát hành thường xuyên với Kanban.

Answer 2

Nhóm tôi quản lý sử dụng Kanban và chúng tôi phát hành khoảng hai tuần một lần. Nếu bạn nghiêm túc về những gì được tích hợp vào chi nhánh mã vạch chính của bạn (các bài kiểm tra đi qua, khách hàng đã được phê duyệt, v.v.), Kanban cho phép bạn phát hành bất cứ khi nào bạn muốn.Bạn cần đảm bảo rằng các câu chuyện di chuyển qua hệ thống của bạn không phải là phụ thuộc để thực hiện việc này, nhưng nhóm của tôi thường không phải là vấn đề - một phần lớn công việc của chúng tôi liên quan đến bảo trì, bao gồm một số sửa lỗi không liên quan/tính năng trên mỗi bản phát hành.

Answer 3

Để kiểm soát nguồn, tôi rất muốn giới thiệu Perforce. Nó làm cho phân nhánh và tích hợp các thay đổi từ các nhánh khác tương đối đơn giản, và cung cấp giao diện tốt nhất để kiểm soát nguồn mà tôi đã thấy cho đến nay.

Việc tích hợp liên tục cũng giúp - nghĩa là nhiều lần commit nhỏ, nhiều hơn hàng ngày thay vì các hợp nhất lớn và có khả năng gây khó khăn. Các công cụ như CruiseControl có thể giúp làm nổi bật khi nguồn bị hỏng do cam kết xấu. Ngoài ra, nếu mọi người tạo ra nhiều thay đổi nhỏ thì những thay đổi xung đột sẽ rất hiếm.

Tôi cũng khuyên bạn không nên cố gắng làm theo những thứ như nạc, scrum, kanban & co. quá chặt chẽ. Chỉ cần tự giải quyết vấn đề, tìm đến những ý tưởng này để được hướng dẫn hơn là hướng dẫn. Các chi tiết cụ thể về vấn đề của bạn sẽ nhiều hơn khả năng đòi hỏi sự linh hoạt để quản lý tốt nhất.

Answer 4

Cách chúng tôi xử lý các bản phát hành hàng tuần trên một dự án kỹ thuật bền vững đã sử dụng Kanban là triển khai chiến lược phân nhánh. Các nhà phát triển đã làm việc trong một chi nhánh sandbox và thực hiện một lần kiểm tra cho mỗi mục công việc. Người thử nghiệm của chúng tôi sẽ kiểm tra mục công việc trong hộp cát; nếu nó vượt qua các kiểm tra hồi quy thì checkin sẽ được di chuyển đến nhánh phát hành của chúng ta. Chúng tôi đã khóa chi nhánh phát hành từ trưa thứ hai cho đến khi bản phát hành ra mắt (thường là vào thứ Tư, đôi khi vào thứ Năm, ngày mất ngày thứ sáu), và chạy lại các kiểm tra hồi quy cho tất cả các kiểm tra di trú cũng như kiểm tra tích hợp cho sản phẩm, thả một bản phát hành sau khi tất cả các bài kiểm tra được thông qua.

Chiến lược này cho phép các nhà phát triển liên tục làm việc về các vấn đề mà không bị đóng băng khỏi chi nhánh của họ trong quá trình phát hành. Nó cũng cho phép họ làm việc về các vấn đề mất hơn một tuần để giải quyết; nếu nó không được kiểm tra và kiểm tra/phê duyệt thì nó không được di chuyển.

Nếu tôi đang chạy Kanban cho phiên bản mới của dự án, tôi sẽ sử dụng một chiến lược tương tự nhưng nhóm tất cả các đăng ký có liên quan dưới dạng 'đối tượng', di chuyển tính năng vi vu vào chi nhánh phát hành thực hiện và sau đó thực hiện kiểm tra đơn vị/tích hợp/chấp nhận/hồi quy bổ sung trong nhánh phát hành trước khi thả bản phát hành có tính năng đó. Lưu ý rằng khái niệm quan trọng của Kanban đang hạn chế công việc đang diễn ra, vì vậy tôi có thể hạn chế nhóm của tôi làm việc trên một tính năng cùng một lúc (điều này có thể là một số mục công việc/câu chuyện của người dùng).

Answer 5

Có nhiều điều này hơn là chỉ kiểm soát nguồn, nhưng sự lựa chọn của bạn của TFS sẽ giới hạn bạn. Khi dự án Burton được hình thành vào năm 2004, Microsoft đã không chú ý đến Agile, Lean ít hơn nhiều. Nó sẽ là liên kết cơ học yếu nhất của bạn trong một thời gian. Các tin tặc của bạn nên được nuôi dưỡng bởi sự chấp nhận riêng của Mercurial của CodePlex sau khi được cung cấp cho cộng đồng Microsoft như là đứa trẻ áp phích thực hiện TFS.

Một vấn đề nổi bật hơn ở đây là Thiết kế công việc. Nó bao gồm thứ tự mà bạn chọn để thực hiện các tính năng (lịch làm việc), cũng như ưu tiên và chi phí chậm trễ, và hình dạng và kích thước của các mục công việc.

Scrum thường được hiểu là nói rằng "Chủ sở hữu sản phẩm" phi kỹ thuật có thể xác định lịch làm việc chỉ dựa trên mối quan tâm của riêng họ. Nếu bạn đi theo con đường này, bạn sẽ phải chịu rất nhiều lãng phí do không tận dụng cơ hội làm việc cùng nhau. Công việc thuộc về nhau không thể chỉ được xác định bởi mong muốn của Chủ sở hữu sản phẩm. Các cơ hội kỹ thuật và lực lượng lao động (kỹ năng) cũng phải được xem xét.

Để công việc được thực hiện theo cách hiệu quả nhất, bản thân công việc phải được thiết kế theo cách đó. Điều này có nghĩa là trong một nhóm phát triển sản phẩm Lan, quyết định không phải do một nhân viên phi kỹ thuật quyết định, mà bởi những gì Toyota gọi ai đó là "Năng lực kỹ thuật cao chót vót" gần sản phẩm, gần khách hàng và gần với nhóm .

Vai trò này tương phản hoàn toàn với đề xuất của Scrum. Một kỹ sư trưởng trên một đội ngũ Lean là chính mình (hoặc chính mình) tiếng nói của khách hàng, và vai trò của chủ sở hữu sản phẩm là không cần thiết.

"Chủ sản phẩm" của Scrum là sự công nhận vai trò kém phát triển trong các tổ chức phát triển phần mềm, nhưng nó không phải là một giải pháp bền vững luôn tránh lãng phí. Vai trò của "Kiến trúc sư phần mềm" thường không đủ, như trong một số nền văn hóa của nhà phát triển, kiến ​​trúc sư đã trở nên quá xa khỏi công việc.

Các vấn đề về triển khai liên tục của bạn chỉ được giải quyết một phần với công nghệ và công cụ. Xem xét các vấn đề về tổ chức, và có lẽ đưa ra một vài suy nghĩ về mục đích của Scrum như là một cách tiếp cận chuyển tiếp từ thác nước thay vì một cách có thể phục vụ cho tổ chức của bạn vô thời hạn.

Answer 6

Bạn cần hiểu hệ thống kéo, đó là những gì Kanban được thiết kế để quản lý.

Yêu cầu của khách hàng (hoặc chủ sở hữu sản phẩm hoặc tương tự) cho một tính năng trong hệ thống đang chạy là điều kích hoạt quá trình này.

Yêu cầu là tín hiệu đi vào triển khai. Triển khai tìm kiếm một mục được thử nghiệm với các thuộc tính phù hợp với yêu cầu. Nếu không có ở đó, bạn viết các bài kiểm tra và xem xét phát triển nếu có một khe phát triển có thể được sử dụng để thực hiện một cái gì đó đáp ứng các bài kiểm tra. Khi phát triển đã thực hiện phát triển của nó (có thể tìm kiếm một phân tích phù hợp đầu tiên và vv), kiểm tra thực hiện kiểm tra của nó và triển khai triển khai.

Yêu cầu chuyển ngược qua hệ thống là các quyền bắt đầu hoạt động. Ngay sau khi yêu cầu đến, điều này sẽ kích hoạt rất nhiều hoạt động, trong đó mỗi hoạt động sẽ được hoàn thành càng nhanh càng tốt. Ở đó bạn có triển khai turbo của bạn.

Cũng giống như yêu cầu xe ô tô đi đến đại lý nhìn vào con tàu báo hiệu cho nhà máy ô tô, người báo hiệu cho nhà cung cấp.

Kanban không phải là về việc đẩy yêu cầu thông qua hệ thống. Đó là về việc kéo chức năng ra khỏi hệ thống để đổi lấy yêu cầu đi qua bước cuối cùng.

Answer 7

Làm sao chúng ta làm điều đó:

Chúng tôi có một đường ống với các giai đoạn sau

1. Backlog
2. TODO
3. Trong tiến trình (Xây dựng và thử nghiệm nhanh)
4. xét Mã
5. Kiểm tra (Thử nghiệm nghiêm ngặt)
6. Integrat kiểm tra ion và chấp nhận chung kiểm tra
7. Triển khai

Mỗi câu chuyện được phát triển như là một chi nhánh dựa trên phiên bản mới nhất để rời khỏi sân khấu Deploy. Sau đó, chúng được tích hợp như là một phần của việc chuẩn bị thử nghiệm tích hợp.

QA kéo từ giai đoạn xem xét mã và có thể chuẩn bị bản phát hành theo bất kỳ tốc độ nào mong muốn. Tôi nghĩ rằng chúng tôi có một tốc độ khoảng một bản phát hành mỗi tuần.

Bằng cách xóa nhánh "chính" khỏi git và không thực hiện bất kỳ hợp nhất nào trước giai đoạn xem xét mã, chúng tôi đã đảm bảo rằng không có khả năng mã "lén" vào bản phát hành. Trong đó, như một sản phẩm phụ thú vị, đã buộc chúng tôi phải hình dung rất nhiều công việc từng bị ẩn.