Scrum untuk seorang programmer tunggal? [Tutup]

Saya ditagih sebagai "Pakar Windows" di perusahaan saya yang sangat kecil, yang terdiri dari diri saya sendiri, seorang insinyur mekanik yang bekerja dalam peran penjualan dan pelatihan, dan presiden perusahaan, yang bekerja dalam peran desain, pengembangan, dan dukungan.

Peran saya sama umum, tetapi terutama saya merancang dan mengimplementasikan pemrograman apa pun pada produk kami yang harus dilakukan agar barang-barang kami dapat berjalan pada versi Windows mana pun yang saat ini.

Saya baru saja selesai menonton ikhtisar tingkat tinggi dari paradigma Scrum, yang diberikan dalam webcast. Pertanyaan saya adalah: Apakah sepadan dengan waktu saya untuk mempelajari lebih lanjut tentang pendekatan pengembangan produk ini, mengingat bahwa item pekerjaan pengembangan saya biasanya diberikan pada tingkat yang sangat tinggi, seperti "menginternasionalkan dan melokalkan produk".

Jika ya, bagaimana Anda menyarankan mengadaptasi Scrum untuk penggunaan hanya satu programmer? Alat apa, berbasis cloud atau sebaliknya, yang berguna untuk tujuan itu?

Jika tidak, pendekatan apa yang akan Anda sarankan untuk seorang programmer tunggal untuk mengatur upayanya dari hari ke hari? (Mungkin pertanyaannya direduksi menjadi pertanyaan sederhana itu.)

Learn Scrum: ya. Jika hanya untuk mempelajarinya untuk menambah keahlian umum Anda. (tapi rasanya "Larangan Scrum" mungkin adalah yang Anda cari ...)

Scrum adalah kerangka kerja yang bagus, tetapi prinsip inti adalah "Iterasi (Sprint) akan diperbaiki durasinya" Saya belum pernah melihat pekerjaan ini dalam tim yang sangat kecil yang lebih didorong oleh interupsi daripada tidak. Jika Anda benar-benar dapat mendaftar dan berkomitmen untuk bekerja dalam kotak waktu tetap (1 minggu?) Maka Scrum adalah kerangka kerja yang keren. Jika Anda tidak bisa ... maka Scrum menyenangkan untuk dipelajari karena ia memiliki beberapa konsep bagus yang menerjemahkan dengan baik untuk hal-hal lain ... seperti ....

Backlog - Scrum atau tidak, simpan daftar prioritas hal-hal yang perlu Anda lakukan. Saya suka Excel (atau Google Doc Spreadsheet ...) Anda mungkin menyukai yang lain. Saya akan menyimpan alat yang sangat kecil jika Anda adalah tim yang sangat kecil. (Spreadsheet >> Pengolah kata karena Anda dapat mengurutkan dengan mudah.)

Pemisahan perencanaan dan komitmen - Rencanakan dalam notasi abstrak (poin) dan konsisten (8pts adalah sekitar 2x cerita 4pt dan 4x cerita 2 poin) Ketika waktu untuk "melakukan pekerjaan" lihat kembali masalah dan buat sketsa keluar dalam hitungan jam. Jangan mengubah poin.

Komitmen - dapat dilihat oleh orang lain saat Anda berkomitmen, dan memenuhi komitmen Anda

Retrospektif - setelah Anda melahirkan, renungkan apa yang bisa dilakukan dengan lebih baik.

dll.

Scrum cukup mudah untuk dipahami bahwa itu mungkin merupakan titik awal yang baik. Jika Anda suka, saya akan mempertimbangkan menggunakan varian "Scrum-larangan" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Tidak ada hal lain yang menurut saya "sangat terdokumentasi dengan baik" dengan komunitas yang cukup aktif untuk mendukungnya.

Saya ingin juga merekomendasikan metodologi Crystal Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer dan http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Kecil / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), tetapi melibatkan cara membaca dan menggali lebih banyak.

Hal-hal seperti XP memberikan detail lebih lanjut tentang praktik tertentu, jadi saya juga mengatakan membaca buku: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= buku & ie = UTF8 & qid = 1304359834 & sr = 1-1

Saran bacaan terakhir: Selama Anda setuju dengan manifesto Agile, dan ikuti prinsip-prinsip: http://agilemanifesto.org/principles.html Anda harus dalam kondisi yang layak.

Rekomendasi pribadi: Adopsi TDD (tidak dapat dinegosiasikan, IMHO) Pertahankan jaminan simpanan (sesuai Scrum) Selalu pertahankan ukurannya dan urutkan berdasarkan prioritas. Segerakan hal-hal "terlalu besar untuk dilakukan di antara interupsi" ke dalam potongan-potongan kecil. Buat orang lain menetapkan / meninjau prioritas (tidak ada dua item mendapatkan prioritas yang sama. ever.) Membuat lingkungan build Anda dapat membangun / menguji / menyebarkan (ke lab env) dalam 5-10 menit Tunjukkan kepada pelanggan Anda (internal dan eksternal) hasil penyelesaian sebuah cerita. Cerita tidak selesai sampai pelanggan Anda setuju. Tarik Cerita dari atas tumpukan dan kerjakan saat Anda menyelesaikan cerita saat ini. Jangan biarkan lebih dari 2 hal terbuka sekaligus. Selesaikan satu gangguan sebelum memulai yang lain.

semoga ini membantu

Anda dapat menggunakan beberapa praktik yang digunakan dalam Scrum seperti jaminan simpanan produk, penentuan prioritas, estimasi relatif, pengiriman tambahan tetapi menggunakan Scrum secara keseluruhan sebagai proses untuk mengelola pengembangan produk oleh tim anggota lintas fungsi yang dikelola sendiri mungkin bukan cara yang tepat untuk pertunjukan satu orang. .

Pertanyaannya adalah apakah Anda dapat memecah item pekerjaan Anda menjadi potongan-potongan kecil yang dapat dikirim secara bertahap? Jika tidak menggunakan sebagian besar praktik tidak masuk akal. Scrum juga tentang kerja sama yang tinggi dengan pemilik / pelanggan Produk. Seharusnya tidak seperti: "Di sini Anda memiliki tugas dan kembali setelah selesai".

Meskipun saya tidak akan mengatakan apa pun untuk atau menentang Srum 1 orang, saya akan mengatakan bahwa sistem tarik Kanban 1 orang bekerja dengan sangat baik. Kanban dikombinasikan dengan Unit-Testing otomatis telah membuat saya jauh lebih produktif dan "didokumentasikan". Meskipun tidak ada metodologi yang benar-benar bagus, tetapi lebih banyak alat (dan yang sangat berbeda pada saat itu), keduanya memaksa saya untuk memecah proyek solo yang besar menjadi potongan-potongan kecil, juga memberi saya semacam ritual untuk mendorong saya untuk menyelesaikan lebih banyak hal yang dilakukan masing-masing hari. Tidak ada yang cukup memuaskan dengan mengklik "jalankan semua tes" dan melihat setiap item berubah hijau ... tidak ada yang lain selain mengambil kartu dari kolom "Dalam Kemajuan" di papan Kanban saya ke "Dalam Pengujian" (atau seluruhnya dari papan seluruhnya) .

Saya pikir masalah sebenarnya dengan bekerja solo, adalah bahwa Anda telah memilih dan memilih dari beberapa metodologi, yang benar-benar dimaksudkan untuk kelompok pengembang, dan menyesuaikannya agar sesuai dengan Anda. Tujuan akhirnya adalah hanya untuk membuat Anda bertanggung jawab, produktif, dan bahagia. Siapa yang tahu bagaimana melakukan itu lebih baik daripada diri Anda (dengan sedikit ditarik dari sini dan sedikit dari sana).

Saya memang mencoba ini ketika saya sedang bekerja sendirian di satu titik. Hal-hal yang bekerja dengan baik adalah:

1. Memiliki semua benda kerja di papan tulis. Saya bisa dengan cepat melihat pekerjaan luar biasa apa yang ada; di mana dependensi dan penyumbatan berada. Juga, banyak orang akan mampir ke papan saya dan membacanya - dan kami akan mengobrol tentang hal itu. Saya pikir itu membantu mereka memahami apa yang dilakukan "geek" sepanjang hari ;-)
2. Grafik burn-down juga bagus. Saya hanya menggunakan Excel untuk ini. Itu memungkinkan saya untuk menjadi lebih baik dalam membuat estimasi di lingkungan itu. Itu memberi saya gambaran yang bagus tentang ke mana saya menuju dengan iterasi. Manajer saya, yang bukan orang teknis, juga suka ini karena dia bisa melihat semua hal berbeda yang terlibat dalam fitur, dan di mana mereka berada.
3. Stand up harian. Sebisa mungkin saya bisa. Setiap pagi, saya memperbarui semua item-pekerjaan dan grafik burn-down dan membuat catatan semua hambatan yang perlu diselesaikan.
4. Pengujian otomatis dan integrasi berkelanjutan (MSTest / TFS), lebih disukai TDD, akan membantu tim pengembangan apa pun, menggunakan metodologi apa pun - tetapi layak disebutkan di sini.
5. Iterasi singkat (1 minggu) sangat membantu saya untuk fokus dalam memberikan sesuatu.
6. Mempertahankan jaminan sangat bagus karena ketika saya diberi pekerjaan baru saya bisa menempatkannya dalam konteks semua pekerjaan lain dan membuat pemilik produk untuk memprioritaskan kembali.

Yang tidak berhasil adalah:

1. Bekerja sendiri, Anda tidak pernah mendapatkan dorongan dari berkolaborasi dengan orang-orang yang berpikiran sama; atau rasa kompetisi dan fokus yang berasal dari tim dengan moral dan budaya yang sangat hebat. Tidak ada otak lain yang bisa diambil ketika Anda terjebak, jadi penyumbatan seperti itu tidak bisa dihilangkan oleh master scrum dalam berdiri sehari-hari.
2. Tidak ada master scrum - jadi tidak ada yang menghentikan interupsi. Saya memiliki banyak masalah dengan orang-orang yang terus-menerus bertanya tentang hal-hal lain dan memutuskan aliran saya. Di bawah master scrum yang baik, hal-hal seperti itu akan dicegat dan Anda bisa melanjutkan. Saya tidak pernah ingin bersikap kasar kepada orang-orang (mungkin saya lunak) jadi itu masalah. Juga, tanpa master scrum, Anda dapat menjelajahi proses dengan mudah.

Itu adalah latihan yang menarik, tetapi saya berhenti melakukannya setelah sedikit. Saya pikir manfaat Scrum harus dilihat berbeda dengan tim air terjun tradisional. Tapi keduanya bisa diperdebatkan saat Anda sendirian. Tidak ada komunikasi, atau masalah kolaborasi - Anda hanya membajak pekerjaan yang sudah diatur dan kemudian Anda selesai.

Saya pikir semua orang harus menyimpan log-kembali, dan melakukan TDD sekalipun.

Elemen Agile / Scrum / Kanban yang menurut saya masuk akal dalam satu dunia pengembang tunggal:

1. Memiliki papan di mana Anda mengatur cerita pengguna Anda / item-backlog aktif, pada kartu indeks, seperti kanban.

2. Dapatkan dukungan dari non-pengembang atas nilai prinsip-prinsip ini:

   • Beri saya waktu untuk bekerja tanpa mengubah prioritas saya pada saya atau manajemen mikro (titik sprint). Beri saya waktu dan saya akan mencoba mencari tahu sebelumnya berapa banyak yang bisa saya lakukan, dan saya akan melakukan yang terbaik untuk melakukan itu.

   • Jika saya memerlukan sesuatu (saya diblokir), dan saya datang kepada Anda, dan Anda tidak dapat mengurutkannya untuk saya, maka sprint mungkin harus dibatalkan secara tidak normal. (Itu hanya berarti kita perlu rencana baru.)

   • Tidak ada yang mengubah apa pun di tengah sprint. Atau, jika kami melakukannya, kami hanya membatalkan sprint, dan kami membuat yang baru. jika ini sering terjadi, produktivitas akan turun.

   • komunikasi antara orang-orang yang menjadi pemangku kepentingan dapat terjadi pada pertemuan harian reguler, yang mengomunikasikan sebagian besar hal yang sama dengan scrum biasa, termasuk prestasi pengembang Anda untuk hari itu. Pada dasarnya, Anda dapat melaporkan hal-hal yang membutuhkan waktu lebih lama dari yang Anda duga, atau berjalan dengan baik, dan setiap penyesuaian yang Anda lakukan pada rencana implementasi Anda. (Saya menemukan empat bug baru dan mencatatnya, saya pikir mereka lebih penting daripada fitur opsional ini, jadi saya pikir saya akan menghabiskan waktu dan memperbaikinya dan menyingkirkan fitur opsional ini.)

Saya telah melakukan banyak pekerjaan sebagai pengembang tunggal, dan saya dapat mengatakan dengan pasti, bahwa kepercayaan antara pengembang tunggal dan atasan / atasan non-pengembangnya, dan komunikasi yang baik adalah kuncinya, bukan metodologi. Tetapi Anda selalu dapat lebih efektif, jika Anda mengikuti prinsip-prinsip yang baik.

Saya telah membaca beberapa blog tentang ini dan saya pikir ini dapat membantu Anda dengan pertanyaan Anda.

Bagian pertama: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Bagian kedua: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Anda mungkin menemukan lebih banyak info di blog ini.

Saya sama sekali tidak terhubung; hanya sesuatu yang saya miliki di favorit saya. Semoga ini bisa membantu Anda.

Iya nih. Dan perlu diingat bahwa Scrum tidak harus melibatkan alat-alat mewah, itu hanya bisa menjadi pertemuan sederhana 15 menit di mana semua orang berbicara tentang apa yang sedang mereka kerjakan. Keuntungan Scrum adalah semua orang tahu apa yang sedang terjadi, dan itu membuatnya lebih mudah untuk menyelesaikan masalah sebelum timbul, dan mengantisipasi masalah di ujung jalan.

Banyak dari jawaban ini yang hilang satu poin penting.

Tim scrum tidak perlu sepenuhnya terdiri dari programmer.

Salah satu kolega Anda melakukan 'desain' / 'pengembangan' dan satu lagi melakukan 'penjualan'.

Mungkin kolega 'penjualan' Anda dapat menjadi pemilik produk (proxy). Apa harapan pelanggan?

Desain dan pengembangan kolega Anda yang lain benar-benar terdengar seperti disiplin tim scrum bagi saya. Pengembangan scrum tidak bertahap tetapi vertikal (persyaratan, desain dan implementasi dalam satu sprint).

Anda bisa melakukan proses scrum dengan Anda bertiga.

Apa yang diperlukan untuk menyelesaikan 'ini'? Pertemuan perencanaan sprint Scrum memperbesar pertanyaan apa 'ini'. Apa yang diharapkan oleh pemilik produk agar dianggap selesai?

Selama pertemuan perencanaan sprint, Anda dapat memberi konteks kepada kolega Anda yang lain tentang mengapa 'menginternasionalkan dan melokalkan produk' mungkin secara teknis sulit diterapkan.

Banyak alasan untuk menggunakan scrum imho.

Saya akan menyarankan mencoba Kanban, dan mulai dengan dasar-dasar: visualisasi dan membatasi work-in-progress (WIP).

Bahkan jika Anda menghentikannya nanti, Anda akan lebih gesit dalam prosesnya. Dan meskipun Kanban bagus untuk pengembangan perangkat lunak "normal", Kanban + proses berbasis aliran (berlawanan dengan iterasi) mengungguli alat proses lainnya ketika Anda menghadapi situasi dengan pengembangan fitur dan pemeliharaan baru.

Saya merekomendasikan buku Kanban karya David Anderson, dan Anda juga dapat melihat slide saya dari pertemuan lokal tentang mengapa dan bagaimana cara memulai dengan Kanban sederhana , atau crisp.se/kanban untuk intro singkat.

Untuk konteks Anda, saya punya beberapa pemikiran:

• visibilitas adalah kunci, jadi gunakan papan tulis fisik daripada alat digital jika Anda tidak dapat menampilkannya di layar (besar) secara permanen (jika Anda berada di lokasi yang sama)
• mulai dengan proses Anda saat ini
• mulailah dengan lingkup pengaruh Anda saja, termasuk fase hand-off upstream dan downstrean (menjadi antrian untuk Anda, misalnya, fitur yang dirancang siap untuk dev, atau antrian dari Anda, misalnya, fitur jadi, siap untuk penjualan)
• jika kolega Anda tertarik untuk memperluas visualisasi hulu atau hilir, semuanya lebih baik. Mungkin Anda akan akhirnya memvisualisasikan seluruh aliran nilai (atau jaringan) untuk perusahaan Anda, yaitu, bagaimana nilai mengalir dari konsep ke uang tunai
• meminimalkan multitasking (!) dengan membatasi WIP. Jika aliran pekerjaan terlihat oleh kolega Anda, mereka harus mengerti mengapa, dan dengan mudah melihat apa yang ada di piring Anda
• mungkin akan berguna untuk memisahkan pekerjaan menjadi 3 atau 4 jenis pekerjaan (kelas layanan), yang memiliki tuntutan berbeda atas mereka: f.ex. bug, masalah kritis, bekerja dengan tenggat waktu keras, bekerja tanpa tenggat waktu
• amati bagaimana pekerjaan Anda mengalir, misalnya, jika Anda mendapatkan kemacetan di suatu tempat, atau pekerjaan tersumbat atau Anda "kelaparan" untuk bekerja dalam pola yang agak dapat diprediksi. Ini lebih mudah untuk jangka panjang jika Anda menggunakan alat digital, ref beberapa slide terakhir saya.
• meningkatkan alur kerja langkah demi langkah

Jika Anda ingin mencoba sesuatu sekarang, hari ini, saat Anda membuat keputusan, saya sarankan mencoba kanban pribadi di dinding atau jendela atau lemari di samping Anda, seperti yang saya lakukan minggu lalu ...

Setelah membaca semua jawaban lain di sini, saya pikir jawaban pragmatis sederhana adalah:

Gunakan proses atau teknik atau metode yang digunakan untuk BELAJAR sesuatu yang akan membantu Anda melakukan pekerjaan Anda dengan lebih baik.

Sekarang ini mungkin berarti memprioritaskan tugas Anda - setiap hari - secara agama.

Ini mungkin berarti mengerjakan backlog.

Ini mungkin berarti melaporkan kemajuan - kepada atasan Anda (bahkan jika dia tidak peduli ... melakukan itu adalah hal yang baik untuk secara mental mengizinkan ANDA untuk mengetahui di mana Anda berada).

Anda mungkin menggunakan segala macam metode atau teknik karena pada akhirnya membiarkan Anda bekerja lebih baik, yang = tidur lebih baik di malam hari.

Lakukan hal-hal yang berhasil (untuk Anda, dalam keadaan Anda saat ini), buang hal-hal yang tidak berhasil.

Kecuali Anda memiliki yang berikut di tempat

• Berarti mengatur dan memprioritaskan persyaratan yang masuk.

• Untuk memperkirakan secara akurat upaya yang akan dilakukan sehingga Anda akan tahu apa yang dapat Anda lakukan dalam iterasi

• Iterasi dan Peningkatan Berkesinambungan - Konsep iterasi di mana seseorang terus-menerus memeriksa dan beradaptasi sangat berharga. Praktek ini mendorong eksperimen dan membangun pembelajaran berkelanjutan. Scrum di Gereja, halaman 4

• Ya, Anda tidak bisa melakukan rapat scrum setiap hari, tetapi setidaknya Anda bisa mengingatkan diri sendiri tentang tugas yang akan Anda lakukan hari ini. Rapat scrum harian digunakan agar tim dapat saling sinkron tentang apa yang mereka lakukan.

• Refleksi setelah sprint - dalam scrum itu disebut Sprint Retrospective, pada akhir setiap iterasi, Anda dapat merenungkan apa yang terjadi setelah iterasi, dan memikirkan apa yang salah dan bagaimana Anda dapat memperbaikinya, apa praktik terbaik untuk mempertahankannya perbuatan

Saya menyarankan agar Anda mengambil pendekatan minimalis, dan dengan perbaikan terus-menerus, Anda dapat memiliki scrum yang sesuai dengan kebutuhan Anda.

Scrum bukan scrum jika Anda tidak dapat menyesuaikannya dengan kebutuhan Anda dan beradaptasi dengan situasi Anda saat ini.