Agile untuk Pengembang Solo

Bagaimana seseorang menerapkan konsep proses Agile sebagai pengembang solo? Agile tampaknya bermanfaat untuk mengembangkan aplikasi dengan kecepatan lebih cepat, tetapi juga tampaknya sangat berorientasi pada tim ...

• Dengan melakukan pengembangan berbasis tes
• Dengan mengembangkan sprint kecil
• Dengan memiliki banyak kontak dengan pelanggan

Saya ingat pernah membaca tesis tentang Cowboy Development, yang penting Agile untuk pengembang solo, tapi saya tidak ingat di mana saya menemukannya.

Lebih jauh ke jawaban dari klez (semua saran bagus), saya sarankan yang berikut ini:

• Menyimpan jaminan produk Jaminan
  produk pada dasarnya adalah daftar semua item yang ingin Anda selesaikan pada tahap tertentu untuk produk ini.
• Mempertahankan burndown lari dan produk burndown
  A burndown lari dimulai dengan daftar semua tugas Anda memutuskan untuk menyelesaikan sprint ini (bagian dari backlog produk Anda akan selesai selama periode waktu tertentu - misalnya 2 minggu) bersama dengan estimasi pekerjaan yang dibutuhkan. Ketika Anda menandai sesuatu, Anda menandainya sebagai selesai; dengan demikian mengurangi (atau membakar) pekerjaan yang tersisa untuk sprint itu.
  Demikian pula, pembakaran produk melacak pekerjaan yang tersisa untuk seluruh simpanan produk
• Mengadopsi konsep estimasi relatif dan kecepatan
  Estimasi relatif adalah teknik estimasi yang menggunakan tugas-tugas lain (atau cerita) sebagai panduan. Misalnya, jika Anda tahu tugas A lebih mudah daripada tugas B dan sekitar dua kali lebih kompleks dari tugas C, Anda akan memastikan bahwa "poin" untuk tugas A benar relatif terhadap harapan itu.
  Penekanannya bukan pada menebak dengan benar jumlah pekerjaan yang dibutuhkan, tetapi menjaga estimasi konsisten satu sama lain.
  Velocity adalah ukuran dari berapa banyak "poin" yang Anda lakukan dalam sprint. Jika estimasi relatif Anda memastikan konsistensi, kecepatan ini dapat digunakan untuk memperkirakan tugas mana yang kemungkinan akan Anda selesaikan dalam sprint mendatang. Perhatikan bahwa kecepatan harus terus direvisi.

• Batasi pekerjaan yang sedang berjalan (selain tinju waktu). Bahkan jika Anda menggunakan metode berulang (tidak seperti Kanban), katakanlah kecepatan Anda adalah 8 poin per iterasi. Jangan mulai mengerjakan 8 semuanya sekaligus. Membatasi WIP baik dengan jumlah cerita atau poin cerita baik-baik saja.
• Miliki tes penerimaan otomatis untuk semua cerita pengguna Anda. Otomatiskan sebanyak yang Anda bisa secara umum.
• Kesalahan dalam membuat cerita pengguna terlalu kecil. Sebagai aturan praktis, buat rasio cerita terbesar ke terkecil 3: 1 . Jika Anda meremehkan sebuah cerita di Scrum dan ternyata terlalu besar, banyak pengembang dapat mengeroyoknya untuk mengembalikannya ke jalur yang benar. Tetapi Anda tidak memiliki cukup orang.
• Jika, dalam konteks tim berukuran biasa, Anda akan ragu apakah akan memisahkan lonjakan cerita pengguna - dalam konteks solo atau tim kecil, lakukan lonjakan tanpa ragu-ragu. Ini membantu menjaga cerita lebih kecil dan lebih mudah diprediksi.
• Retrospektif penting dalam tangkas secara umum, jadi Kanban (yang akan menjadi Kanban Pribadi) mendapat poin tambahan di sini, karena proses retrospektifnya lebih didorong oleh data. Sulit untuk memainkan Triple Nickels ketika Anda tidak memiliki cukup banyak orang.

Hal-hal ini mungkin berlaku untuk situasi solo dan tim kecil (2 atau 3 pengembang).

TAMBAH: beberapa saat setelah saya menulis jawaban ini, saya menemukan ceramah konferensi ini dan sangat terkesan: Personal Kanban: Mengoptimalkan Individual Coder

• Baik bekerja dengan sprint yang terdefinisi dengan baik, atau dengan sengaja memilih pendekatan Kanban. Jangan sampai berakhir di Kanban
• Bug pertama, fitur kedua.
• Tetap tetap fokus pada Value vs fitur mengasapi. (YAGNI atas Penyepuhan Emas)
• Retrospektif sama berharganya. Dan sama pentingnya, buat perubahan proses dalam potongan kecil. Jangan putuskan bahwa hari ini Anda akan mulai menggunakan TDD, Mock dan IoC dalam satu kesempatan kecuali Anda benar-benar tidak memiliki fitur eksternal untuk mengirimkan ATM. Bawa satu per satu.

Pada akhirnya, saya mendefinisikan Agile benar-benar sebagai "melakukan apa yang masuk akal bagi tim dan pelanggan Anda dan tidak mematuhi praktik lama karena kebetulan terlihat seperti mereka bekerja di masa lalu."

Agile bekerja dengan baik bagi individu maupun bagi tim. Ini tentang menemukan proses yang bekerja untuk Anda, dan memungkinkan Anda untuk beradaptasi dengan keadaan yang berubah begitu proyek Anda sudah dimulai. Ini juga tentang memberikan nilai kepada pelanggan Anda secara teratur, terlepas dari apakah perangkat lunak itu benar-benar "selesai" atau tidak.

Proses lincah sangat berulang. Pekerjaan dilakukan dalam TimeBoxes / sprints / cycles / iterations singkat. Beberapa pekerjaan desain mungkin diperlukan di muka, tetapi dapat di refactored saat Anda mempelajari lebih lanjut tentang apa yang Anda butuhkan dari sebuah sistem. Pengujian unit adalah tulang punggung dari hampir semua metode pengembangan Agile, memberi Anda indikasi apakah perangkat lunak Anda berfungsi, dan apakah penambahan / perubahan pada perangkat lunak Anda akan merusak basis kode yang ada.

Jika Anda mematuhi BDD / TDD, biarkan persyaratan Anda berubah dengan angin dan dapat menyesuaikan prioritas fitur Anda sesuai, jika Anda membangun seluruh sistem Anda dan menjalankan semua tes sering, dan jika Anda memberikan kode kerja pada akhir setiap sprint , Anda sudah tangkas.

Wow. Saya akan mencoba untuk menjaga teman di hook yang bisa saya hubungi ketika saya dalam kesulitan - dan berbicara melalui masalah pengkodean. Anda tahu apa yang saya maksud ... hanya tindakan menjelaskan masalah dengan keras membawa solusi ke pikiran saya 90% dari waktu.