Làm cách nào để tránh tính năng creep trên một dự án solo?

Vì vậy, tôi có một chương trình tôi đã làm việc trở lại vào năm 2011 và suốt năm 2012, nhưng lần phát hành cuối cùng là vào tháng 12 năm 2011 . Tôi đã tích cực làm việc với nó, nhưng tính năng creep đã thu hút cái đầu xấu xí của nó và bây giờ nó chứa đầy hàng tấn các tính năng chưa hoàn thành.

Điều tồi tệ là khi tôi triển khai một tính năng, một creep mới. Tôi có thể làm gì để tránh creep tính năng trong tương lai để tôi thực sự có thể phát hành trong hơn một năm ?

Dự án dựa trên iOS và được sử dụng để có các bản phát hành xung quanh mỗi bản cập nhật phiên bản iOS, nhưng bản cuối cùng đã trở lại với 5.1 (2011). Tôi muốn có thể lấy lại chu kỳ phát hành ổn định đó, nhưng nó đã được chứng minh là quá khó.

Theo kinh nghiệm của tôi, thật dễ dàng nếu bạn có thể phát triển và giải phóng nhịp mà không cản trở những gì bạn muốn hoàn thành. Đây là cách tôi đã thực hiện:

1. Viết các tính năng xuống và đưa ra xếp hạng phản ánh mức độ bạn muốn làm việc với nó và mức độ bạn nghĩ nó sẽ mang lại lợi ích cho người dùng (có thể thu hút người dùng thực tế cho việc này). Sau đó viết chúng theo thứ tự đó.
2. Trước khi bạn đăng ký / đẩy một tính năng, hãy đảm bảo rằng bạn có bản dựng ổn định, có thể triển khai (xem xét mạnh mẽ hệ thống CI để tạo điều kiện thuận lợi cho việc đó).

Bằng cách này, bạn chỉ có thể đẩy một bản phát hành sau mỗi tính năng nếu bạn muốn ... hoặc đợi bản giới thiệu cung cấp giá trị mà bạn muốn bản phát hành có.

Ghi chú:

• Một tính năng không bao giờ có thể được ưu tiên cao hơn tính năng bạn đang làm việc (hoặc có thể, nhưng nó không thể làm gián đoạn tính năng bạn đang làm việc). Nó có thể đến tiếp theo nhưng không bao giờ bây giờ . Điều đó có nghĩa là khi bạn đi từ bây giờ đến tiếp theo, bạn sẽ có cơ hội cắt bản dựng phát hành nếu muốn.

Câu trả lời là rất hay và thường không thể: từ chối thêm các tính năng bổ sung.

Sâu hơn, câu trả lời thực sự thuộc về điều gì làm cho một tính năng mới rơi vào tính năng creep bin? Nếu chúng ta giả định rằng các tính năng của creep là những tính năng được thêm vào dự án mặc dù thực tế là chức năng của chúng chỉ tiếp tuyến với mục đích sử dụng của dự án và các tính năng leo là hữu ích, không thừa, câu trả lời là chuyển chúng sang riêng , nhưng các công cụ liên quan. Sử dụng triết lý Unix về xây dựng các công cụ trực giao và dán chúng lại với nhau.

Từ quan điểm quản lý dự án, câu trả lời là tương đương. Quyết định thời gian bạn sẵn sàng dành cho bản phát hành tiếp theo và đặt thời hạn. Ước tính các tính năng và cắt đủ để thực hiện thời hạn. Nếu có các bên liên quan khác ngoài chính bạn, hãy khiến họ chọn điều quan trọng nhất với họ.

Một tổng quan tốt về Lập lịch có thể được tìm thấy trên Joel trên Phần mềm:

http://www.joelonsoftware.com/articles/fog0000000245.html

Một trong những bài học quan trọng nhất trong sự phát triển là biết khi nào thời gian dừng lại.

Những gì thường xảy ra là một nhà phát triển thêm một tính năng. Điều đó lần lượt truyền cảm hứng cho nhiều ý tưởng hơn. Vì vậy, nhiều tính năng được thêm vào. Đó là, như bạn đã nói, một trong những cách mà một dự án trở thành phần mềm. Nhà phát triển không bao giờ xem dự án là 'đã hoàn thành', vì vậy nó không bao giờ được phát hành.

Thói quen bạn muốn có được là ngừng suy nghĩ về một phiên bản / phiên bản như một dự án 'đã hoàn thành'. Thay vào đó, hãy xem sự phát triển là một quá trình lâu dài. Hãy nghĩ về việc phát hành như là những cột mốc trên con đường dẫn đến những gì bạn một ngày hy vọng chương trình sẽ diễn ra. Do đó, một bản phát hành / phiên bản chỉ là một ảnh chụp nhanh về nơi bạn đang ở trong quá trình dài hạn hơn ... một ảnh chụp nhanh được làm tròn và kiểm tra.

Những gì bạn có thể làm, về mặt thực tế, là ngồi xuống và chỉ ra bản phát hành tiếp theo của bạn. Nó không cần phải cực kỳ kỹ lưỡng. Viết ra 3-5 phần chính mới mà bạn tin là cần thiết cho phiên bản tiếp theo. ( số lượng tính năng thực tế có thể thay đổi tùy thuộc vào loại ứng dụng, không tính các sửa lỗi hoặc thay đổi gui nhỏ ) Hoạt động trên các tính năng đó. Nếu bạn đưa ra những ý tưởng khác, thì tốt thôi ... chỉ cần ghi chú và thực hiện chúng trong bản phát hành sau. Khi bạn hoàn thành 3-5 mục đó, bản phát hành của bạn đã sẵn sàng cho bản beta.

Khi tôi bắt đầu một ứng dụng mới, tôi thường nghĩ về 'tầm nhìn' cuối cùng cho ứng dụng. Điều đó, với tôi, là những gì tôi muốn trong phiên bản 3 của ứng dụng. Với điểm chuẩn đó, tôi có một ý tưởng về những gì sẽ tạo ra phiên bản vững chắc 1 - chỉ là những điều cơ bản.

Tóm lược:

Mỗi bản phát hành không phải là "tầm nhìn" hoàn thành của dự án. Chỉ là một cột mốc hướng tới tầm nhìn đó.

Sử dụng một hệ thống kiểm soát phiên bản có giá rẻ để tạo chi nhánh cho một số ý tưởng và tránh xa đường dẫn phát hành của bạn. Chẳng hạn git, bạn có thể "leo lên" một số ý tưởng, và sau đó git stashnó biến mất. Sau đó, bạn có thể xem lại các stash này và cherry chọn chúng theo bất kỳ thứ tự nào có vẻ thú vị.

Đối với các tính năng lớn hơn, tạo một nhánh thực sự (để bạn có thể thực hiện nhiều cam kết). Trường hợp cụ thể: khi tôi muốn thêm hỗ trợ thế hệ cho trình thu gom rác, tôi đã tạo một chi nhánh. Stash nắm bắt những thứ nhỏ gây mất tập trung rất tốt. Các tính năng lớn có thể bắt đầu dưới dạng stash, sau đó biến thành các nhánh và cuối cùng là hợp nhất khi chúng sẵn sàng.

Với stash và chi nhánh, bạn có thể nắm bắt các ý tưởng của mình, ưu tiên chúng và thiết lập một phạm vi cho các bản phát hành dự án solo của bạn, giống như một dự án nhóm được quản lý.

Hãy nhìn xem, khi bạn có một ý tưởng, nó phải đi đâu đó , và nơi tốt nhất là mã : repo. Tính năng leo tốt hơn là quên những ý tưởng tốt. Nhưng tất nhiên, nếu bạn chuyển tất cả các tính năng của mình vào cùng một dòng chính, nó sẽ tiếp tục trì hoãn phát hành, trừ khi bạn cắt các bản phát hành không gọn gàng đầy những thứ đã hoàn thành mà người dùng phải cảnh báo không sử dụng.