it-swarm-id.com

Agile untuk Pengembang Solo

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

136
kelleystar
  • 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.

66

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

  • Menyimpan jaminan produk
    Tumpukan produk pada dasarnya adalah daftar semua item yang ingin Anda selesaikan pada tahap tertentu untuk produk ini.
  • Mempertahankan sprint burndown dan produk burndown
    . 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 jaminan produk
  • Mengadopsi konsep estimasi dan kecepatan relatif
    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 "poin" untuk tugas A benar relatif terhadap harapan itu.
    Penekanannya bukan pada menebak dengan benar jumlah pekerjaan yang dibutuhkan, tetapi menjaga perkiraan yang konsisten satu sama lain.
    Kecepatan 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 lakukan dalam sprint mendatang. Perhatikan bahwa kecepatan harus terus direvisi.
39
Damovisa
  • Batasi pekerjaan yang sedang berlangsung (selain waktu-tinju). 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, buatlah rasio dari 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, sehingga 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

21
azheglov
  • Baik bekerja dengan sprint yang terdefinisi dengan baik, atau 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 mereka terlihat seperti bekerja di masa lalu."

9
MIA

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/cycle/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.

3
S.Robins

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 saya pikiran 90% dari waktu.

1
codeyoung