Agile untuk Pengembang Solo


133

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


77
Saya hanya mencoba mengadopsi pemrograman berpasangan sebagai pengembang tunggal, dan itu meningkatkan kualitas pekerjaan saya!
Wizard79

Jawaban:


66
  • 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.


18
Saya akan sangat tidak setuju dengan pernyataan bahwa pengembangan "Cowboy" adalah Agile, bahkan untuk pengembang solo
Travis Christian

4
@ TravisChristian - Ini lebih Lone Ranger.
JeffO

9
Berikut ini tautan ke tesis , yang coba dibiarkan oleh @ a.brookshollar sebagai sunting.
Scott Whitlock

6
Saya akan bertaruh bahwa baik Travis maupun ke-11 orang yang memberikan komentarnya belum membaca tesis tersebut. Judul lengkapnya adalah "Cowboy: Metodologi Pemrograman Agile Untuk Programmer Solo" dan, meski agak ketinggalan zaman, patut dibaca.
Brien Malone

2
Tautan ke tesis sudah mati, tetapi arsip memilikinya: web.archive.org/web/20150914220334/http://…
Tobias Kienzler

39

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.

Tumpukan produk, burndown, estimasi relatif (poin cerita) dan kecepatan adalah praktik penting yang tangkas. Tak satu pun dari mereka yang spesifik untuk situasi praktisi solo.
azheglov

4
... seperti halnya TDD, sprint, dan kontak pelanggan ...
Damovisa

5
akan lebih baik jika Anda juga mengatakan apa arti semua istilah ini. Saya tidak tahu apa-apa sebelum saya membaca jawaban ini ..
Klik Upvote

2
@Damovisa: Saya tidak butuh deskripsi atau pencarian web, terima kasih banyak. Anda menggambarkan dengan cukup akurat beberapa praktik umum Scrum. Ini adalah titik awal dari pertanyaan OP. Ya, praktik ini ada, tetapi berorientasi pada tim, bagaimana cara menerapkannya pada skala mikro? Tidak ada dalam deskripsi Anda yang khusus untuk skala mikro.
azheglov

4
@azheglov Wow, tidak perlu menyinggung. Saya menyoroti yang bagian dari Scrum saya pikir yang paling berguna dalam skenario pengembang solo ketimbang bagaimana menerapkannya. Tidak satu pun dari teknik ini yang dapat berubah sama sekali untuk tim solo vs, jadi mereka akan diterapkan dengan cara yang persis sama. Untuk mencerminkan kata-kata Anda - tidak ada dalam teknik ini yang spesifik untuk skala mikro.
Damovisa

21
  • 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


9
  • 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."


3

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.


0

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.


8
Itu PALING dari nilai yang saya dapatkan dari suatu tempat seperti stackoverflow. Saya tidak bisa memberi tahu Anda berapa banyak pertanyaan yang telah saya ketikkan dan kemudian tekan tombol kirim.
Dan Ray


2
Karet ducking adalah konsep yang hebat (dibahas dalam pertanyaan yang relevan di sini) tetapi bagaimana ini menjawab pertanyaan yang diajukan? "Bagaimana seseorang menerapkan konsep proses Agile sebagai pengembang solo?"
nyamuk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.