Saya bekerja di sebuah perusahaan yang telah berulang kali memotong ukuran tim pengembangannya, sampai-sampai tim 10 orang sebelumnya sekarang turun ke satu pengembang per produk (dan beberapa penguji berbagi antara 5 produk). Kami dulunya adalah perusahaan yang cukup berat, yang merupakan spin-off dari perusahaan yang lebih besar, dan mewarisi proses air terjun multi-tahap.

Sudah turun dari tim eksekutif bahwa kami tidak merilis perangkat lunak cukup cepat, dan bahwa ini kemungkinan kesalahan proses (yang mungkin menjadi kontributor, meskipun hilangnya 90% tenaga kerja mungkin tidak membantu). Ada dorongan bagi kami untuk beralih ke proses Agile untuk menghindari menghabiskan waktu menulis dokumen desain, dll.

Saya rasa saya hanya ingin tahu apakah beralih ke Agile akan membantu tim satu orang. Adalah pemahaman saya bahwa banyak manfaat berasal dari visibilitas yang lebih tinggi dan lebih banyak komunikasi antara anggota tim, tetapi saya tahu apa yang saya lakukan dan begitu pula manajer saya. Saya sudah melakukan TDD karena kita tidak memiliki siapa pun untuk menguji produk.

TL; Versi DR: Saya kira apa yang sebenarnya saya tanyakan adalah, dapatkah Anda menerapkan Agile dengan 'tim' satu orang, dan apakah Anda melihat manfaat darinya, atau apakah itu biasanya sesuatu yang lebih efektif untuk tim yang lebih besar?

Lihat https://groups.google.com/forum/#!forum/solo-scrum

dan /programming/829497/agile-methods-specifically-taylored-to-working-solo

Pembaruan:
Tautan pertama adalah ke Grup Google Scrum Solo. Manfaat paling jelas yang dibicarakan di sini adalah menggunakan sprint kotak-waktu untuk mengelola ruang lingkup dan menentukan kecepatan proyek - keduanya hal yang sangat baik.

Tautan kedua adalah ke diskusi sebelumnya tentang Stackoverflow, yang mungkin mengindikasikan ini adalah pertanyaan rangkap, tapi saya pikir akan lebih bermanfaat untuk menautkannya. Ini pada gilirannya link ke http://c2.com/xp/ExtremeProgrammingForOne.html yang memiliki banyak tautan dan info tentang melakukan XP solo (tanpa pemrograman pasangan).

satu

ukuran tim minimum adalah satu

Agile adalah kumpulan prinsip dan praktik, yang Anda pilih untuk menyesuaikan alur kerja. Jika Anda adalah one-man show, Anda memilih yang sesuai untuk Anda.

XP / TDD bekerja dengan baik untuk tim satu orang. Dan Anda bisa melewatkan praktik berpotensi yang menghabiskan waktu dari pertemuan harian dan pemrograman pasangan.

Masalah utama Anda bukan "gesit", tetapi dokumentasi. Artikel ini pada dokumentasi Agile / Lean oleh Scott Ambler mungkin akan menjadi bacaan yang menarik untuk Anda dan rekan kerja Anda.

Agile bukan tentang tidak mendokumentasikan. Anda masih mendokumentasikan, hanya saja Anda memilih apa dan bagaimana Anda akan mendokumentasikan untuk memaksimalkan nilai sambil meminimalkan waktu yang dihabiskan untuk membuatnya. Anda masih menangkap persyaratan, melaksanakan desain, mendokumentasikan keputusan implementasi Anda, dan memiliki keterlacakan penuh sepanjang siklus hidup sesuai kebutuhan, tetapi hanya sejauh yang dibutuhkan proyek. Tidak menangkap informasi dan keputusan utama proyek adalah cara yang pasti untuk membuat proyek gagal.

Untuk bonus kecil yang menyenangkan, inilah pendapat saya tentang individu yang gesit:

Metodologi tangkas dirancang untuk tim. Scrum biasanya membutuhkan sekitar 3-9 pengembang bersama dengan Pemilik Produk dan Master Scrum (dan Pemilik Produk dan Master Scrum tidak boleh orang yang sama). Pemrograman Ekstrim sering memanggil 4-7 orang.

Alasannya adalah bahwa sejumlah praktik yang umum digunakan dalam metodologi lincah arus utama tidak menurun ke pengembang tunggal. Contoh utama dari ini adalah penekanan pada pemrograman pasangan dan ulasan kode di XP - Anda benar-benar tidak dapat melakukan ini dengan pengembang solo.

Seorang pengembang tunggal bisa gesit, tetapi harus merupakan proses yang disesuaikan. Sebagian besar metode gesit membutuhkan beberapa kombinasi dari integrasi berkelanjutan, pengujian unit, pengembangan berbasis tes, refactoring, prinsip KISS dan YAGNI, dan sebagainya. Banyak dari ini telah menjadi "praktik terbaik", bahkan pada metodologi yang lebih didorong oleh rencana. Tidak ada alasan mengapa pengembang solo tidak dapat mengambil keuntungan dari beberapa dari mereka, selama mereka tidak mengganggu produksi dan pengiriman perangkat lunak.

Jika Anda ingin membatasi dokumentasi, saya akan fokus pada itu jika ini menghambat Anda. Dokumentasi hanya sepotong gesit dan tidak terdengar seperti ada orang di perusahaan Anda yang akan tahu bagaimana menerapkannya. Ini bisa menunda rilis kode Anda dalam jangka pendek karena pelatihan, pembelian, penyesuaian, dll. Kekuatan yang ada hanya akan membuangnya dan mencari obat mujarab besar berikutnya untuk penundaan produksi setelah PHK 90%.

Datang dari tim satu orang (meskipun semoga tidak lama).

Saya berusaha untuk mencapai Agile untuk diri saya sendiri dalam arti bahwa saya bermaksud agar mereka menjadi lebih banyak pengembang daripada hanya saya sendiri untuk proyek-proyek masa depan. Saya menulis WBS tingkat tinggi, saya membuat cerita pengguna, tugas di bawah cerita pengguna, menguji kasus, dan melacak proyek dengan baik sehingga manajer saya dapat melihat dan memahami. Ini bisa menjadi sedikit rumit karena saya "hanya tahu" di kepala saya di mana saya berada tetapi saya meluangkan waktu untuk melakukannya tetap murni untuk tetap rajin untuk tim masa depan mitos yang telah dijanjikan kepada saya tetapi belum terjadi. Saya ingin berpikir bahwa saya mengikuti proses yang baik untuk orang-orang yang akan datang setelah saya.

Dokumentasi yang saya lakukan dalam jumlah kecil dan itu sebagian besar diagram alir dan menggunakan diagram kasus tetapi umumnya tidak ada level rendah kecuali ada sesuatu yang sangat rumit atau penting tentang hal itu yang saya tidak ingin lupa. Saya juga membuat diagram penempatan untuk kepentingan orang-orang masa depan ketika mereka harus memunculkan lingkungan baru untuk "pelatihan" atau sejenisnya.

Saya belajar sendiri TDD perlahan tapi saya belum menyempurnakannya, ini sangat sulit dilakukan dalam arti murni untuk aplikasi lawas tanpa refactoring petak fungsionalitas yang besar dan berisiko. Fungsionalitas baru yang rumit saya masih berjuang dengan tetapi saya masih bertujuan untuk cakupan 100% yang merupakan permainan akhir TDD setelah semua. Saya mungkin tidak mengambil jalan terbaik untuk sampai ke sana.

Pasti bisa dilakukan, tetapi karena kebutuhan sebagian besar.

Mengapa Agile sebagai tim satu orang, padahal Anda bisa membentuk satu tim yang terdiri dari lima pengembang dengan jaminan produk tunggal untuk lima produk Anda. Cobalah satu atau dua minggu pengulangan dan fokus pada satu produk pada satu waktu dan lihat bagaimana produktivitas Anda meningkat dengan lima insinyur bekerja bersama sebagai tim yang mengatur diri sendiri secara kohesif. Bergantung pada seberapa sering Anda berencana untuk merilis, Anda mungkin perlu menyesuaikan panjang sprint. Saya menduga bisnis mungkin tidak ingin menunggu 10 minggu antara pembaruan untuk suatu produk, dalam hal ini panjang sprint 1 minggu dapat bekerja lebih baik. Anda dapat mengerjakan dua produk dalam satu sprint tetapi saya akan berusaha sebaik mungkin untuk menghindari ini sehingga Anda dapat fokus pada satu tujuan produk dan melakukan itu secara produktif dan berkualitas.

IMO memiliki satu orang yang didedikasikan untuk satu produk mungkin merupakan pendekatan yang tidak bijaksana ketika ada lima pengembang dan lima proyek total, terlepas dari metodologi yang Anda pilih.

Banyak praktik lincah membuahkan hasil untuk tim> 0. Kontrol sumber dan pengembangan tanpa gesekan, misalnya, dan itu akan selalu membuahkan hasil, sekecil apa pun tim.

Ini benar-benar tergantung pada apakah ada dukungan dari sisi bisnis, atau hanya hal baru bagi manajemen untuk disalahkan pada pengembangan (yang terdengar seperti situasi, berdasarkan pengurangan 90% dalam ukuran tim). Itu higher visibility and more communication between team memberstidak hanya berarti antara pengembang. Penting bagi sisi bisnis untuk melihat ke mana waktu Anda pergi, dan menetapkan prioritas yang benar.

Kami telah melihat peningkatan besar dalam kepercayaan antara sisi bisnis dan TI perusahaan kami, karena setiap tim sekarang memiliki Pemilik Produk yang ikut serta dalam stand-up harian, dan mereka melihat ke mana perginya waktu kami, dan mereka adalah yang membuat keputusan tentang apa yang kita kerjakan selanjutnya. Alih-alih manajer terus-menerus dibombardir dengan permintaan, dan kemudian pengembangan disalahkan ketika hal-hal menyelinap melalui celah-celah atau tidak ada cukup waktu dalam sehari untuk menyelesaikan semuanya, sekarang Pemilik Produk yang bertanggung jawab untuk menetapkan prioritas, dan membuat keputusan tentang apa yang dimasukkan dalam sprint.

Jadi, jika ada komitmen dari Pemilik Produk yang akan terlibat dalam proses, maka ya, proses Agile bisa sangat efektif bahkan untuk tim yang terdiri dari satu orang. Tetapi jika ini hanyalah cara lain untuk membuat pengembang menjadi kambing hitam, maka Agile akan gagal untuk semua orang.