Bisakah freelancer menggunakan pengembangan lincah?

Saya ingin meningkatkan cara saya mengembangkan perangkat lunak. Saya ingin mengembangkan kode yang lebih cepat dan hebat! Hari ini saya menggunakan metode waterfall sebagai freelancer, menulis barang-barang web (situs, sistem, dll). Apakah ada cara untuk menggunakan pengembangan tangkas (XP, SCRUM, dll) bekerja dengan cara ini? Saya tidak tahu apa-apa tentang pengembangan gesit, di mana saya harus mulai? Terima kasih banyak.

... Selain pemrograman pasangan, tentu saja. ;-)

Serius, saya juga seorang freelancer dan saya menggunakan teknik lincah sebanyak yang saya bisa. Ini bekerja dengan baik untuk saya. Saya banyak menggunakan TDD,

Tidak ada orang di mana pun yang menggunakan 100% XP atau Scrum, tetapi semua orang menggunakan bagiannya, mencoba mengadopsi sebanyak mungkin hasil kerjanya. Menurut pendapat saya, semakin banyak yang Anda adopsi, semakin baik Anda.

Hal yang paling saya lewatkan adalah pemrograman pasangan. Cara Anda mengatasinya adalah

1. Pergi ke banyak pertemuan grup pengguna.
2. Temukan beberapa orang yang Anda hormati sebagai pengembang.
3. Minta mereka untuk menemui Anda sambil minum kopi atau sesuatu untuk menulis kode. Beri mereka bagian dari upah per jam Anda sesekali jika Anda merasa perlu atau merespons dengan baik untuk mengerjakan kode mereka.
4. Hadiri atau buat Klub Hack seperti ini: http://www.DallasHackClub.org .

Berikut beberapa sumber yang saya gunakan:

• Pemrograman Ekstrim - panduan online yang cepat, tetapi menyeluruh melalui XP.
• Ikhtisar Scrum yang bagus .
• Buku pendek dan fantastis . Sempurna untukmu!

Jadi saya akan mengatakan ada tiga "poin hebat" utama untuk menggunakan Agile sebagai freelancer:

1. Untuk klien yang lebih besar, Pekerjaan / tagihan dalam iterasi. Pada akhir iterasi, pelanggan dapat melanjutkan pekerjaan pada proyek, atau mengakhiri proyek (yaitu: ia mencapai tujuannya). Saya tahu (dari pengalaman) saya tidak bisa memperkirakan lebih dari beberapa minggu, dan bayar per iterasi juga membuat arus kas masuk. Tidak menyenangkan berada di bulan 6 dari proyek 3 bulan, dan menunggu untuk menyelesaikan proyek sehingga Anda dapat ...

2. Agile berarti perubahan terjadi. Saya telah melakukan banyak proyek penawaran tetap (yang menurut Anda dapat Anda lakukan dengan air terjun) yang telah kehilangan uang saya, karena permintaan pelanggan di tengah siklus. Terjadi perubahan: pelanggan dapat kehilangan harga tiket untuk menyelesaikan pekerjaan lain lebih cepat, atau mungkin Anda salah menebak dan tidak mendapatkan sebanyak yang Anda harapkan.

3. Alat kolaborasi pelanggan yang baik. Perkiraan standar saya (untuk sesuatu yang lebih kecil dari nilai pekerjaan iterasi) sebenarnya adalah serangkaian langkah Pengembangan Berbasis Perilaku yang berasal dari harapan klien. Saya mengirim ini ke klien dan berkata "Apakah ini benar?". Itu memastikan semua orang ada di halaman yang sama.

4. Hal paling sederhana yang mungkin bisa berhasil. Ini sesuatu yang perlu diingat saat Anda bekerja: jangan takut untuk kembali ke klien dan berkata, "Ini akan jauh lebih sederhana (atau lebih kuat, atau apa pun) jika kita melakukannya dengan cara ini ... "

5. Scrum itu penting. Saya suka mengirim email kepada klien saya setiap hari saya mengerjakan proyek mereka. Ini seperti scrum saya kepada mereka: "apa yang saya kerjakan hari ini", "apa / kapan saya akan mengerjakan proyek mereka selanjutnya?", "Apakah ada yang menghalangi saya?", Dan "Secara keseluruhan, bagaimana kemajuan berlangsung ? "

6. Pengembangan yang digerakkan oleh tes juga sangat berguna, bahkan sebagai programmer tunggal. "Perkiraan saya dengan cerita BDD di dalamnya" membantu saya memberi makan proses ini.

Cara yang bagus untuk memulai perjalanan Agile Anda adalah mengatur alur kerja Anda menggunakan sistem KANBAN.

Kami hanya memiliki 3 swimlanes:

1. TO-DO atau Backlog kami
2. Apa yang sedang kami kerjakan atau DALAM KEMAJUAN
3. Hal-hal yang kita selesaikan atau SELESAI.

Alur kerja Agile yang sederhana ini adalah cara yang bagus untuk memulai.

Dalam hal pengkodean, saya akan merekomendasikan menggunakan test-driven development (TDD). Kami menyertakan banyak tautan hebat yang menggambarkan TDD dalam artikel kami, tetapi akan menyalinnya kembali di sini:

Untuk informasi lebih lanjut, periksa sumber daya berikut:

• AgileData.org - Sumber yang bagus untuk pengembangan yang digerakkan oleh Tes.
• JamesShore.com - Perincian hebat lainnya untuk TDD
• Net Tuts - Pengantar menyenangkan untuk TDD yang saya suka!
• Artima - Wawancara dengan Martin Fowler
• Games From Within - Studi kasus TDD yang bagus
• DaniWeb - Pengantar TDD untuk pengembang
• Mark Levison - Artikel tentang TDD

Karena Anda seorang individu, yang terbaik adalah Anda mendekati metodologi gesit sebagai sesuatu yang ada di sana untuk membantu Anda memahami apa yang paling cocok untuk Anda . Mereka ada di sana untuk membantu Anda mencapai dataran "tidak ada sendok", tetapi bagaimana tepatnya hal itu akan terjadi sepenuhnya terserah Anda dan apa yang Anda hasilkan pada akhirnya akan sangat tumpang tindih dengan beberapa metodologi pada berbagai tingkatan, namun itu akan menjadi sesuatu yang sepenuhnya milikmu.

Karena Anda berusaha menemukan cara Anda sendiri dalam melakukan berbagai hal untuk meningkatkan efektivitas Anda secara keseluruhan, berikut adalah beberapa petunjuk yang dapat membantu Anda setidaknya tidak membuat kesalahan yang sama seperti yang saya lakukan:

Lupakan semua solusi perangkat lunak yang secara eksklusif menargetkan metodologi gesit, selama Anda bisa.

Fakta bahwa mereka lebih cocok untuk memfasilitasi kolaborasi tim adalah tidak penting. Tahan godaan. Anda tidak mengotak-atik diri Anda dengan cara melakukan sesuatu dan kemudian berharap mengadopsinya akan berhasil untuk yang terbaik. Tidak, itu hanya membuat Anda frustrasi. Pertama-tama Anda menemukan cara Anda melakukan sesuatu dan kemudian mencari solusi perangkat lunak yang sesuai. Saya akhirnya menggunakan papan tulis (dimulai dengan satu, tapi sekarang saya punya dua di kamar saya) untuk melacak / mengembangkan cerita dan Teknik Pomodoro | To Do Today daftar untuk melacak tugas pengembangan saya dan itu friggin 2011. Tetap berpegang pada dasar-dasarnya sampai kita mendapatkan beberapa antarmuka seperti yang keluar dari Iron Man 2 atau mobil terbang mulai muncul.

Refleksi, refleksi, refleksi

Inilah yang saya pahami sebagai bagian terpenting dari setiap metodologi bagi seorang individu. Ini tentang mengembangkan alur kerja ini yang memberi Anda pandangan menyeluruh tentang proyek Anda sehingga Anda dapat melacak apa yang perlu dilakukan dan ketika dengan cara yang mudah dikelola dan di mana keputusan buruk jarang dibuat dan menonjol sehingga mereka dapat dengan cepat diamandemen sebelum mereka menyebabkan kerusakan ... tetapi Anda tidak bisa mengambilnya dari rak. Mulai dari suatu tempat, di mana saja. Anda tetap menggunakannya selama itu berhasil. Investasikan untuk melacak yang baik, yang buruk dan yang lainnya. Tingkatkan asumsi Anda, lalu sesuaikan cara Anda melakukan hal-hal yang sesuai. Itulah satu-satunya cara Anda akan meningkat.

Furget tentang tenggat waktu, fokus pada seberapa cepat Anda menyelesaikan sesuatu

Aku mungkin seperti lelaki berikutnya ketika aku mulai, mengejar kencan. Grafik burnout? Dulu saya menganggap mereka sebagai cara untuk memvisualisasikan jalur pengembangan saya terhadap tenggat waktu. Ini adalah kinerja, bukan model perkiraan. Waktu ada untuk mengukur efektivitas Anda dengan merefleksikan pekerjaan yang telah Anda lakukan dalam kerangka waktu tertentu, bukan hanya nilai bodoh untuk mewakili jarak sebelum menghambat tenggat waktu. Kenyataannya adalah bahwa hal-hal dilakukan ketika itu dilakukan dan metodologi Anda harus menjelaskan itu.

Menyimpang sesuai

Pada akhirnya, siapa bilang Anda harus menggunakan cerita pengguna, atau apa pun yang kami ketahui tentang hal itu? Jangan berpikir seperti itu. Jika Anda lebih nyaman dengan berfikir dalam fitur, maka tentu saja menentang komunitas pengembangan global dan melakukannya dengan cara Anda, karena menyelesaikan pekerjaan adalah yang terpenting di akhir hari. Jika Anda akhirnya merasa melakukan sesuatu yang salah, selamat - Anda baru saja menyimpulkan bahwa inilah saatnya untuk melompat ke sesuatu yang lain. Ini tentang apa, bukan bagaimana.

Saya akan menjawab "bagaimana Anda ingin meningkatkan cara Anda mengembangkan perangkat lunak?". Untuk model bisnis Anda, apa masalah terbesar yang Anda temui menggunakan metodologi air terjun?

Apakah tujuan Anda pengembangan lebih cepat, kode yang lebih kuat, penggunaan kembali yang lebih besar, memenuhi / beradaptasi dengan perubahan persyaratan dll? Ada berbagai metodologi untuk mengatasi masalah yang berbeda.

Tentu saja mengadopsi metodologi desain selain Air Terjun dapat sangat berguna dalam mengelola siklus proyek secara efektif tergantung pada kebutuhan bisnis Anda. Untuk pengembangan tangkas ada banyak sumber daya online. Saya akan melihat ke AUP (Agile Unified Process) yang menggabungkan TDD (Test Driven Development). Ini bisa sangat berguna ketika membangun / mengelola sistem berskala besar.

Tidak ada metodologi 'satu ukuran cocok untuk semua' dan ini adalah alasan utama banyaknya pendekatan yang berbeda. Saya akan mulai berpikir tentang di mana Anda merasa hambatan dalam proses pengembangan Anda saat ini dan kemudian mencoba mengadopsi metodologi baru untuk mengatasi hal ini.

Misalnya apakah Anda sering gagal memenuhi tenggat waktu? Apakah fitur baru memperkenalkan sejumlah besar bug? Apakah persyaratan baru menyebabkan pembangunan kembali yang besar? Apakah bisnis memerlukan sistem kerja reguler untuk disajikan? Lihat: Agile , Iterative , dan Agile Intro .