Các nhóm Agile có nên cung cấp các tính năng mới hàng ngày?

Công ty của tôi đang trong giai đoạn chuyển đổi từ phát triển theo kiểu thác nước sang Agile / Scrum. Trong số những thứ khác, chúng tôi đã nói rằng kỳ vọng là chúng tôi sẽ có các tính năng mới hoạt động, có thể kiểm tra (bằng QA) vào cuối mỗi ngày.

Hầu hết các nhà phát triển của chúng tôi mất khoảng 2 giờ mỗi ngày cho các cuộc họp và các doanh nghiệp khác. Điều này có nghĩa là trong bất kỳ khoảng thời gian 6 giờ (tốt nhất) nào, chúng tôi phải thiết kế, viết, kiểm tra đơn vị, xây dựng và triển khai (có ghi chú phát hành) để tạo ra một tính năng hoàn chỉnh cho QA để chơi. Tôi hiểu rằng các ghi chú xây dựng / triển khai / phát hành có thể được tự động hóa với một thiết lập CI thích hợp nhưng chúng tôi chưa có.

Chúng tôi cũng có một đội ngũ lớn ở nước ngoài viết mã phía máy chủ của chúng tôi và sự khác biệt về thời gian 12 giờ làm cho điều này thậm chí còn khó khăn hơn.

Chúng tôi cố gắng phân chia các câu chuyện thành các lát cắt hẹp, sâu dọc để hoàn thành các tính năng từ đầu đến cuối nhanh nhất có thể, nhưng hầu hết các ngày đều cảm thấy khá điên cuồng và tôi thường bắt mọi người dùng các phím tắt ngu ngốc, mỏng manh để đảm bảo QA có bản dựng. Vấn đề này được giải quyết sau khi nước rút đã được tiến hành trong một vài ngày, khi các khiếm khuyết không thể tránh khỏi bắt đầu xuất hiện và phải nằm gọn trong cùng một cửa sổ 6 giờ.

Đây có phải là một tốc độ bình thường cho các đội Agile? Ngay cả khi chúng tôi quản lý để thực hiện thiết lập CI, tôi không thể thấy cách chúng tôi có thể duy trì tốc độ này mà vẫn tạo ra phần mềm chất lượng.

Chỉnh sửa: Có một số câu trả lời tốt ở đây. Nó khiến tôi nhận ra rằng điều tôi thực sự yêu cầu là, các nhóm Agile có nên cung cấp các tính năng mới hàng ngày không. Tôi cập nhật tiêu đề cho phù hợp.

Những tội ác được thực hiện nhân danh Agile những ngày này làm tôi buồn. Rất nhiều người đang gặp khó khăn khi thực hiện quá trình chuyển đổi này.

Tuyên ngôn Agile: "Chúng tôi đánh giá cao con người và sự tương tác qua quy trình và công cụ.". Khi người dân rõ ràng bị tổn thương, quá trình là sai. Tôi không muốn nói với bạn cách làm, nhưng sẽ chia sẻ cách tôi làm.

Trong các đội của tôi, phần quan trọng là tránh cam kết mã repo được chia sẻ bị phá vỡ theo cách sẽ lãng phí thời gian còn lại của đội. Theo nghĩa này, tôi cố gắng 'cung cấp mã làm việc mỗi ngày'. Đừng phá QA. Đừng chặn các nhà phát triển khác. Lý tưởng nhất là tôi không bao giờ kiểm tra bất kỳ lỗi nào. (ha ha).

Hàm ý không phải là bạn phải cam kết một điều gì đó mỗi ngày. Hàm ý là bạn chỉ nên cam kết những thứ tốt, để mỗi ngày bạn có thể có được một bản dựng của tất cả những thứ tốt mà bất cứ ai đã cam kết. Bằng cách này, đội tiếp tục bắn vào tất cả các xi lanh.

Trong đội của tôi QA là không đổi. Tôi xây dựng các sản phẩm thương mại, vì vậy dự án không bao giờ kết thúc cho đến khi sản phẩm bị lỗi thời. Kỹ sư QA kiểm tra các tính năng có sẵn để kiểm tra. Kỹ sư QA luôn luôn tồn đọng. Không bao giờ có đủ thời gian QA để kiểm tra hoặc tự động hóa mọi thứ chúng ta muốn một cách lý tưởng.

Nếu các nhà phát triển cần nhiều ngày trước khi hợp nhất các thay đổi cho một tính năng hoặc sửa lỗi, thật tốt, được khuyến khích nếu điều đó giúp họ có được mã ngay trước khi mạo hiểm thời gian của chúng tôi. Các nhà phát triển có thể cam kết mã cho repo hoặc chi nhánh riêng của họ mà không ảnh hưởng đến nhóm hoặc QA. Các nhà phát triển có thể chạy thử nghiệm đơn vị hoặc tự động hồi quy trên mã được xây dựng từ repo hoặc chi nhánh riêng của nhà phát triển. Trong các trường hợp đặc biệt rủi ro, Kỹ sư QA sẽ làm việc với nhà phát triển để kiểm tra trước khi hợp nhất, để bảo vệ nhóm khỏi sự chậm trễ.

Theo nghĩa này, tôi thực hành những gì người quản lý của bạn muốn. Hầu như mỗi ngày trong 12 năm qua, các nhóm phát triển của tôi đã có mã hoạt động trong kho lưu trữ được chia sẻ. Chúng tôi luôn sẵn sàng để vận chuyển. Đôi khi chúng tôi không đạt được điều này nhưng chúng tôi không lo lắng quá nhiều về nó. Đôi khi nó là cố ý, để chứa các thay đổi công cụ chính hoặc sáp nhập khó khăn.

Tuyên ngôn Agile, với tôi, tổng hợp những suy nghĩ tốt nhất về quá trình phát triển xuất hiện vào những năm 1990. Tôi gần như là một người tin tưởng thực sự vào những nguyên tắc đó, nhưng chi tiết về quy trình có thể khác nhau. Như tôi thấy, quan điểm của Agile là điều chỉnh quy trình của bạn theo nhu cầu của sản phẩm và khách hàng, không phải là nô lệ cho quy trình.

Nếu bạn có phần mềm làm việc ngày hôm qua, tại sao hôm nay nó không hoạt động? Nếu bạn không hoàn thành bất kỳ nhiệm vụ nào hôm nay, việc xây dựng ngày hôm nay sẽ giống như ngày hôm qua. Xây dựng hàng ngày và tốc độ phát triển là những điều riêng biệt. Chỉ vì bạn có các bản dựng hàng ngày không có nghĩa là bạn có các tính năng mới trong mọi bản dựng.

Cuối cùng khi một số tính năng được hoàn thành và đăng ký tại chi nhánh chính, thì bạn nên có quy trình tự động xây dựng phần mềm và chạy thử nghiệm. Nếu có vấn đề với việc xây dựng hoặc chạy thử nghiệm, nhóm được thông báo và họ tập trung nỗ lực để làm cho nó hoạt động trở lại. Đó là cách CI hoạt động và cách nó giúp bạn phát hành phần mềm làm việc mọi lúc.

Trả lời ngắn gọn: Không . Nó chỉ đơn giản là không thể được thực hiện hàng ngày.

Tuy nhiên, nhóm nhanh nhẹn có nhiệm vụ cung cấp các phần mềm hoạt động hoặc câu chuyện người dùng trong mỗi lần chạy nước rút . Thông thường, cuộc họp trạng thái được tổ chức hàng ngày để xem tiến trình và trở ngại.

Liên quan đến phần mềm chất lượng , các quy trình tích hợp liên tục (CI) được thực hiện sẽ đảm bảo rằng kiểm soát chất lượng được áp dụng cho các nỗ lực nhỏ (đăng ký) và được thực hiện thường xuyên như được định cấu hình. Nó cũng nhắm mục tiêu để cải thiện quality of softwarevà giảm thời gian cung cấp nó, bằng cách thay thế thực hành truyền thống về áp dụng kiểm soát chất lượng sau khi hoàn thành tất cả sự phát triển.

Không, không nên có kỳ vọng cung cấp các tính năng mới mỗi ngày. Không phải tất cả các tính năng có thể được chia thành một kích thước nhỏ như vậy để có thể có một nhà phát triển hoàn thành tính năng này trong ~ 6 giờ thời gian phát triển.

Nếu bạn đang làm scrum, bạn nên thực hiện ở giai đoạn nước rút tối thiểu 2 tuần, với các tính năng có kích thước mất khoảng từ 0 đến 8 ngày để hoàn thành. Lời hứa với chủ sở hữu sản phẩm là cung cấp mã làm việc chính xác mới, đã được kiểm tra và xác minh có thể được đưa vào sản xuất vào cuối giai đoạn nước rút. (LƯU Ý: Bạn không thực sự phải đưa nó vào sản xuất nhưng mục tiêu là nó có thể là nếu bạn muốn)

Phương pháp tốt đề nghị bạn thiết lập máy chủ CI (Tích hợp liên tục) trong đó bạn tự động tạo ra ít nhất một bản dựng phần mềm làm việc hàng ngày. Ý tưởng là bạn kiểm tra mã của mình ngay khi bạn hoàn thành tính năng để nó có thể ở trong chu trình xây dựng tiếp theo và sau đó nằm trong tay QA để thử nghiệm.

Hãy nhớ mục tiêu là để các tính năng được thực hiện và kiểm tra vào cuối giai đoạn nước rút! Bạn sẽ không muốn làm QA đợi đến ngày cuối cùng của cuộc chạy nước rút để bạn thực hiện việc xây dựng và sau đó nhờ họ kiểm tra tất cả các tính năng. Họ sẽ không có thời gian để kiểm tra tất cả và bạn sẽ không có thời gian để sửa bất kỳ lỗi nào ...

Nếu bạn không thể thiết lập máy chủ CI thì thực tế là bạn cần tạo thủ công bản dựng mới cho QA mỗi khi nhà phát triển kiểm tra mã hoàn thành của mình và tuyên bố rằng anh ta đã hoàn thành một tính năng và sẵn sàng giao cho QA.

Nó thực sự phụ thuộc vào quy mô của dự án; nếu dự án là một dự án lớn thì không có cách nào khả thi để đạt được điều này.

Các bản dựng hàng ngày (hoặc thậm chí thường xuyên hơn) xuất phát từ các công cụ tích hợp liên tục, không có nghĩa là phần mềm hoạt động; nó hầu như không có nghĩa là mã có thể biên dịch được.

Có rất nhiều dự án ngoài kia cung cấp các bản dựng hàng ngày, nhờ tích hợp liên tục, là phần mềm hoạt động. Ít nhất là trong lý thuyết.

Nó có nghĩa là nó không nhất thiết phải chứa các tính năng mới. Có thể một vài sửa lỗi nhỏ, hoặc không có gì cả.

Về lý thuyết, nếu bạn không thể cung cấp thêm công việc cho QA hàng ngày, bạn phải tăng số lượng nhà phát triển hoặc giảm số lượng người thử nghiệm. Ý tưởng khủng khiếp!

Công việc của bạn là hoàn thành công việc

Nói với QA rằng họ sẽ lấy thứ gì đó để kiểm tra khi hoàn thành. Bạn cần phải giải thích cho họ tại sao.

Tôi nghĩ rằng bạn đang bối rối về ý tưởng của "CI". Bạn có thể muốn ghé thăm bài viết tuyệt vời này của Martin Fowler về cách CI hoạt động trong thực tế . Điều đó sẽ trả lời chính xác câu hỏi của bạn.