Một freelancer có thể sử dụng phát triển nhanh?

Tôi muốn cải thiện cách mà tôi phát triển phần mềm. Tôi muốn phát triển nhanh hơn và một mã tuyệt vời! Hôm nay tôi sử dụng phương pháp thác nước như freelancer, viết nội dung web (trang web, hệ thống, v.v.). Có cách nào để sử dụng phát triển nhanh (XP, SCRUM, v.v.) làm việc theo cách này không? Tôi không biết gì về phát triển nhanh, tôi nên bắt đầu từ đâu? Cảm ơn rât nhiều.

... Khác với lập trình cặp, chắc chắn. ;-)

Nghiêm túc mà nói, tôi cũng là một freelancer và tôi sử dụng các kỹ thuật nhanh nhất có thể. Nó làm việc cho tôi rất tốt. Tôi sử dụng rất nhiều TDD,

Không ai ở đâu sử dụng 100% XP hoặc Scrum, nhưng mọi người đều sử dụng các phần của nó, cố gắng áp dụng nhiều như công việc cho họ. Theo tôi, bạn càng nhận nuôi nhiều, bạn càng có lợi.

Điều tôi nhớ nhất là lập trình cặp. Cách bạn vượt qua đó là

1. Đi đến nhiều cuộc họp nhóm người dùng.
2. Tìm một vài người mà bạn tôn trọng là nhà phát triển.
3. Yêu cầu họ gặp bạn qua cà phê hoặc một cái gì đó để viết mã. Thỉnh thoảng hãy cho họ một phần tiền lương hàng giờ của bạn nếu bạn cảm thấy cần thiết hoặc chỉ trả lời bằng hiện vật để làm việc với mã của họ.
4. Tham dự hoặc tạo Câu lạc bộ Hack như thế này: http://www.DallasHackClub.org .

Dưới đây là một số tài nguyên tôi sử dụng:

• Lập trình cực đoan - một hướng dẫn trực tuyến nhanh chóng, nhưng kỹ lưỡng thông qua XP.
• Một tổng quan tuyệt vời về Scrum .
• Cuốn sách tuyệt vời và ngắn . Hoàn hảo cho bạn!

Vì vậy, tôi muốn nói có ba "điểm tuyệt vời" chính khi sử dụng Agile như một freelancer:

1. Đối với khách hàng lớn hơn, Công việc / hóa đơn trong các lần lặp. Khi kết thúc việc lặp lại, khách hàng có thể tiếp tục thực hiện dự án hoặc kết thúc dự án (nghĩa là: nó đã hoàn thành mục tiêu của mình). Tôi biết (từ kinh nghiệm) Tôi không thể ước tính tốt hơn một vài tuần và việc trả tiền mỗi lần lặp lại cũng khiến dòng tiền đến. Không có gì vui khi ở tháng 6 của dự án 3 tháng và chờ đợi để hoàn thành dự án để bạn có thể ...

2. Agile có nghĩa là thay đổi xảy ra. Tôi đã thực hiện một tấn các dự án giá thầu cố định (mà bạn nghĩ rằng bạn có thể làm với thác nước) đã làm tôi mất tiền, vì một yêu cầu của khách hàng ở giữa chu kỳ. Thay đổi xảy ra: khách hàng có thể hủy cấp vé để hoàn thành một số công việc khác nhanh hơn hoặc có thể bạn đã bỏ qua sai và không thực hiện được nhiều như bạn mong đợi.

3. Công cụ cộng tác khách hàng tốt. Ước tính tiêu chuẩn của tôi (đối với một cái gì đó nhỏ hơn giá trị công việc lặp đi lặp lại) thực sự là một loạt các bước Phát triển hướng hành vi xuất phát từ mong đợi của khách hàng. Tôi gửi cái này cho khách hàng và nói "Điều này có đúng không?". Nó đảm bảo tất cả mọi người ở trên cùng một trang.

4. Điều đơn giản nhất có thể có thể làm việc. Đó là điều cần lưu ý khi bạn làm việc: đừng ngại quay lại với khách hàng và nói: "Điều này sẽ đơn giản hơn nhiều (hoặc mạnh mẽ hơn, hoặc bất cứ điều gì) nếu chúng ta làm theo cách này ... "

5. Scrum rất quan trọng. Tôi thích gửi email cho khách hàng mỗi ngày tôi làm việc trong dự án của họ. Điều này giống như câu trả lời của tôi đối với họ: "những gì tôi đã làm hôm nay", "những gì / khi tôi sẽ làm việc cho dự án của họ tiếp theo?", "Có gì theo cách của tôi không?", Và "Nói chung, tiến triển như thế nào ? "

6. Phát triển theo hướng thử nghiệm cũng thực sự hữu ích, ngay cả khi là một lập trình viên duy nhất. "Ước tính với các câu chuyện BDD trong đó" giúp tôi cung cấp quy trình này.

Một cách tuyệt vời để bắt đầu hành trình Agile của bạn là thiết lập quy trình làm việc của bạn bằng hệ thống KANBAN.

Chúng tôi chỉ đơn giản là có 3 đường bơi:

1. TO-DO của chúng tôi hoặc tồn đọng
2. Những gì chúng tôi đang làm việc hoặc TIẾN ĐỘ
3. Những điều mà chúng tôi hoàn thành hoặc làm.

Quy trình làm việc Agile đơn giản này là một cách tuyệt vời để bắt đầu.

Về mặt mã hóa, tôi khuyên bạn nên sử dụng phát triển dựa trên thử nghiệm (TDD). Chúng tôi bao gồm rất nhiều liên kết tuyệt vời mô tả TDD trong bài viết của chúng tôi nhưng sẽ sao chép lại chúng ở đây:

Để biết thêm thông tin, hãy kiểm tra các tài nguyên sau:

• AgileData.org - Một tài nguyên tuyệt vời để phát triển dựa trên thử nghiệm.
• JamesShore.com - Một sự cố tuyệt vời khác cho TDD
• Net Tuts - Một giới thiệu thú vị về TDD tôi thích!
• Artima - Phỏng vấn Martin Fowler
• Các trò chơi từ bên trong - Một nghiên cứu điển hình về TDD
• DaniWeb - Giới thiệu về TDD cho các nhà phát triển
• Mark Levison - Bài viết về TDD

Vì là một cá nhân của bạn, tốt nhất bạn nên tiếp cận các phương pháp nhanh như một thứ gì đó có sẵn để giúp bạn tìm ra những gì phù hợp nhất với bạn . Họ ở đó để giúp bạn đạt đến cao nguyên "không có thìa", nhưng chính xác thì điều đó sẽ xảy ra như thế nào hoàn toàn phụ thuộc vào bạn và cuối cùng bạn sẽ nghĩ ra điều gì sẽ trùng lặp với một số phương pháp ở nhiều cấp độ khác nhau nó sẽ là một cái gì đó hoàn toàn của bạn.

Vì bạn đang cố gắng tìm một cách riêng để làm mọi thứ để cải thiện hiệu quả chung của bạn, đây là một số gợi ý có thể giúp bạn ít nhất không mắc phải những sai lầm tương tự tôi đã làm:

Từ bỏ tất cả các giải pháp phần mềm độc quyền nhắm mục tiêu các phương pháp nhanh, miễn là bạn có thể.

Thực tế là họ phù hợp hơn để tạo điều kiện hợp tác nhóm là bên cạnh điểm. Chống lại sự cám dỗ. Bạn không tự đóng hộp mình trong cách làm việc và sau đó hy vọng việc áp dụng nó sẽ mang lại kết quả tốt nhất. Nó không, nó chỉ làm bạn thất vọng. Trước tiên, bạn tìm cách làm việc của mình và sau đó tìm kiếm một giải pháp phần mềm phù hợp. Tôi đã kết thúc với việc sử dụng bảng trắng (bắt đầu với một, nhưng bây giờ tôi có hai cái trong phòng) để theo dõi / phát triển câu chuyện và Kỹ thuật Pomodoro | Danh sách những việc cần làm hôm nay để theo dõi các nhiệm vụ phát triển của tôi và đó là kết quả năm 2011. Bám sát những điều cơ bản cho đến khi chúng tôi nhận được một số giao diện như những người ngoài Iron Man 2 hoặc những chiếc ô tô bay bắt đầu xuất hiện.

Suy tư, suy tư, suy tư

Đây là những gì tôi đã hiểu là phần quan trọng nhất của bất kỳ phương pháp nào cho một cá nhân. Đó là về việc phát triển quy trình công việc này mang đến cho bạn cái nhìn toàn diện về dự án của bạn để bạn có thể theo dõi những gì cần phải làm và khi nào dễ quản lý và khi các quyết định xấu hiếm khi được đưa ra và nổi bật để chúng có thể được sửa đổi nhanh chóng trước khi chúng gây ra bất kỳ thiệt hại nào ... nhưng bạn không thể lấy nó ra khỏi kệ. Bắt đầu từ đâu đó, bất cứ nơi đâu. Bạn gắn bó với nó miễn là nó hoạt động. Đầu tư vào việc theo dõi cái tốt, cái xấu và cái tương tự. Cải thiện các giả định của bạn, sau đó điều chỉnh cách bạn làm mọi việc cho phù hợp. Đó là cách duy nhất để bạn cải thiện.

Furget về thời hạn, tập trung vào việc bạn hoàn thành công việc nhanh như thế nào

Tôi có lẽ giống như anh chàng tiếp theo khi tôi bắt đầu, theo đuổi ngày tháng. Biểu đồ kiệt sức? Tôi đã từng nghĩ về chúng như một cách để hình dung theo dõi phát triển của mình trước thời hạn. Đó là một hiệu suất, không phải là một mô hình ước tính. Có thời gian để đo lường hiệu quả của bạn bằng cách phản ánh công việc bạn đã thực hiện trong một khung thời gian nhất định, không chỉ là một giá trị ngu ngốc để biểu thị khoảng cách trước khi cản trở thời hạn. Thực tế là mọi thứ sẽ được thực hiện khi nó được thực hiện và phương pháp của bạn nên giải thích cho điều đó.

Đi chệch hướng

Cuối cùng, ai nói bạn phải sử dụng câu chuyện của người dùng, hoặc bất cứ điều gì chúng ta biết về vấn đề đó? Đừng nghĩ như thế. Nếu bạn cảm thấy thoải mái hơn với việc suy nghĩ về các tính năng, thì bằng mọi cách, hãy thách thức cộng đồng phát triển toàn cầu và thực hiện theo cách của bạn, bởi vì hoàn thành công việc là tất cả những vấn đề vào cuối ngày. Nếu bạn cuối cùng cảm thấy như bạn làm điều gì đó sai, xin chúc mừng - bạn vừa kết luận rằng đã đến lúc phải nhảy sang một thứ khác. Đó là về những gì, không phải là hows.

Tôi sẽ trả lời "bạn muốn cải thiện cách bạn phát triển phần mềm như thế nào?". Đối với mô hình kinh doanh của bạn, các vấn đề lớn nhất bạn gặp phải khi sử dụng phương pháp thác nước là gì?

Là mục tiêu của bạn phát triển nhanh hơn, mã mạnh mẽ hơn, tái sử dụng nhiều hơn, đáp ứng / thích ứng với các yêu cầu thay đổi, v.v.? Phương pháp khác nhau tồn tại để khắc phục các vấn đề khác nhau.

Tất nhiên việc áp dụng một phương pháp thiết kế khác với Waterfall có thể rất hữu ích trong việc quản lý hiệu quả vòng đời dự án tùy thuộc vào yêu cầu kinh doanh của bạn. Để phát triển nhanh, có rất nhiều nguồn tài nguyên trực tuyến. Tôi sẽ xem xét AUP (Quy trình hợp nhất Agile) kết hợp TDD (Phát triển dựa trên thử nghiệm). Điều này có thể cực kỳ hữu ích khi xây dựng / quản lý các hệ thống có khả năng mở rộng lớn.

Không có "một kích thước phù hợp với phương pháp luận" và đây là lý do chính cho số lượng lớn các phương pháp khác nhau. Tôi sẽ bắt đầu suy nghĩ về nơi bạn cảm thấy những vướng mắc trong quá trình phát triển của mình và sau đó cố gắng áp dụng một phương pháp mới để khắc phục điều này.

Ví dụ, bạn có thường xuyên không đáp ứng thời hạn? Các tính năng mới có giới thiệu một số lượng lớn lỗi không? Do yêu cầu mới gây ra sự tái phát triển lớn? Có doanh nghiệp yêu cầu hệ thống làm việc thường xuyên phải được trình bày? Kiểm tra: Giới thiệu Agile , lặp đi lặp lại và Agile .