Metodologi pemrograman mana yang cocok untuk kita?

Sayangnya, seseorang telah mengajarkan manajemen puncak kita kata "Agile" dan sekarang mereka ingin kita bergerak ke arah itu. Saya memiliki pemahaman perifer tentang gesit (pada prinsipnya) tetapi tidak pernah menggunakannya dalam praktik. Dari yang saya tahu, itu tidak akan cocok untuk organisasi kita. Saat ini, semuanya sangat kasar. Begini caranya;

Kami adalah tim yang sangat kecil - dua pengembang, satu DBA, satu desainer. Perusahaan tempat saya bekerja menghasilkan uang dalam jumlah besar secara tidak proporsional relatif terhadap ukurannya, dan hampir 95% darinya merupakan penjualan online murni.

Dari perspektif pengembangan, kami mengalami banyak serbuan meja pada hari-hari biasa (kami adalah dukungan teknis dan juga pengembang), pekerjaan dapat secara teratur jatuh begitu saja ketika pemberitahuan jika anggota tim penjualan menjanjikan sesuatu kepada seseorang . Kami melakukan proyek yang lebih besar juga, dan itu adalah mimpi buruk dengan gangguan konstan. Beberapa dari kita mulai merobek rambut kita! Rencana proyek disusun oleh manajer non teknis dalam spreadsheet excel, di mana mereka mencoba dan memecah tugas menjadi kalimat berukuran gigitan yang dapat mereka pahami dan menempatkan tanggal di samping masing-masing. Tanggal-tanggal ini selalu sangat tidak realistis dan sering terlewatkan, dan pertemuan kami (yang kami lakukan setiap minggu) secara teratur diisi dengan momen-momen canggung dengan orang-orang yang bertanya "mengapa ini belum dilakukan".

Saya cukup yakin Agile bukan yang cocok untuk kita. Sekarang, mengingat bahwa (dan saya telah mencoba) perusahaan ini tidak akan mengubah caranya , dan hanya tim pengembang yang mau berubah, adakah metodologi pengembangan yang bisa kita adopsi yang cocok untuk menyelamatkan kita sedikit kewarasan?

Agile sebenarnya dirancang untuk mengatasi banyak masalah persis yang Anda alami. Jika manajemen benar-benar membeli dan tidak akan memutarbalikkan proses, Anda bisa melihat peningkatan besar. Biarkan saya mengatasi masalah Anda poin demi poin. Pengalaman saya adalah dengan scrum, jadi saya akan berbicara dari sudut pandang itu, tapi saya yakin implementasi lain memiliki manfaat yang sama.

• pekerjaan jatuh dari langit Cerita-cerita ini diletakkan di bagian bawah tumpukan sampai pemilik produk dan tim dapat bertemu untuk setuju untuk memindahkannya. Prioritasnya ditentukan relatif terhadap semua komitmen tim Anda lainnya, dan prioritas itu terlihat oleh setiap pemangku kepentingan yang tertarik untuk melihatnya. Seharusnya sangat jarang menambahkan fitur baru di tengah sprint, dan hanya bug prioritas tertinggi yang boleh mengganggu sprint. Sungguh menakjubkan berapa banyak "keadaan darurat" yang bisa menunggu sampai akhir minggu depan ketika hal itu dijadikan harapan biasa.
• melakukan proyek yang lebih besar Anda akan memiliki visibilitas untuk menunjukkan bagaimana prioritas jangka pendek berdampak pada proyek jangka panjang Anda. Jika orang terus-menerus memindahkan cerita pengguna di depan proyek jangka panjang Anda, tidak apa-apa, tetapi untuk membuat keputusan itu semua orang akan tahu dampaknya pada jadwal proyek jangka panjang.
• rencana proyek disusun oleh manajer non teknis. Cerita pengguna seharusnya ditulis dari sudut pandang non-teknis, tetapi tim scrum Anda harus diberdayakan untuk membuat perkiraan dan menentukan detail implementasi.
• Tanggal benar-benar tidak realistis . Tim Anda menangani semua perkiraan, karena Andalah yang tahu apa yang Anda lakukan. Jika perkiraan tersebut tidak dapat diterima oleh bisnis, mereka harus memutuskan bagaimana memprioritaskan fitur. Jika mereka membutuhkan lebih banyak pekerjaan daripada yang bisa Anda tangani, kebutuhan untuk merekrut lebih banyak orang akan terlihat jelas.
• tanggal sering terlewatkan Pertama, perkiraan Anda akan lebih realistis, yang seharusnya membantu. Juga, Anda menggigit potongan yang lebih kecil dan benar - benar menyelesaikannya , yang membantu bisnis merasa seperti Anda telah menghasilkan sesuatu yang berguna bahkan jika fitur tidak lengkap.
• pertemuan yang dipenuhi dengan momen canggung Agile memiliki visibilitas lebih dan siklus umpan balik yang lebih cepat, dengan pemilik produk sangat terlibat. Masalah pemblokiran Anda dan alasan penundaan seharusnya tidak mengejutkan.
• juga melakukan dukungan teknis Bertentangan dengan kepercayaan populer, lincah tidak kompatibel dengan jadwal yang dibagi. Faktor scrum dalam gangguan Anda menjadi kecepatan tim Anda. Jika Anda biasanya menghabiskan setengah dari waktu Anda melakukan dukungan teknis, Anda hanya akan memiliki setengah kecepatan.

Apa yang harus disadari oleh manajemen dan penjualan adalah bahwa gesit bukanlah cara untuk melakukan kontrol yang lebih ketat terhadap tim pengembangan, itu memberi tim lebih banyak otonomi untuk melakukan apa yang mereka lakukan dengan baik sambil membantu bisnis secara realistis mempertimbangkan semua prioritasnya setiap kali menugaskan pekerjaan ke tim.

Saya akan mengatakan mengambil keuntungan dari tingkah manajemen Anda! Sepertinya mereka membantu Anda dan memberi Anda pengaruh untuk meningkatkan metode kerja Anda.

Katakan kepada mereka OK kita akan gesit itu membutuhkan antara lain: -

• pemisahan pembangunan dan dukungan
• proses pengumpulan persyaratan formal - di bawah kendali tim TI. "Cerita" dll. Kedengarannya sangat kabur - tetapi sebenarnya metode "formal" yang didandani terlihat informal.
• penjadwalan di bawah kendali tim TI.

Jika mereka tidak menerima ini maka katakan pada mereka Anda tidak bisa gesit.

Agile bukan metodologi pemrograman, Agile adalah metodologi manajemen proyek. Jika manajemen atas benar-benar ingin Anda mencoba kata kunci baru yang mereka temukan ini, mereka harus dapat memahami bahwa metode Agile dimulai dari atas dan melibatkan manajemen melalui setiap langkah. Jika Anda perlu memberi mereka dosis kenyataan, mungkin mengatur presentasi Powerpoint 30 menit tentang Agile untuk memberi mereka sedikit pendidikan. Manajer menyukai Powerpoint.

Namun jika, seperti yang Anda katakan, tim pengembang adalah satu-satunya orang yang mau berubah, maka tidak ada metodologi pengembangan yang dapat membantu Anda. Tanpa mengurangi sisa tugas Anda, interupsi akan terus terjadi dan Anda akan terus diminta untuk memenuhi tenggat waktu yang tidak bisa Anda penuhi.

Saran saya dalam skenario ini adalah untuk mendidik, bukan mencaci, manajemen bagaimana sebenarnya di garis depan.

Tidak ada pengembangan perangkat lunak dan metodologi manajemen proyek yang dapat membantu dalam suatu organisasi di mana tenaga penjualan menentukan jadwal harian. Bagaimana Anda seharusnya mengelola proyek di tengah minggu kerja yang semrawut dan kacau seperti itu?

Begitu banyak manajer tingkat atas melihat nilai Agile dan menginginkan manfaatnya, tetapi mereka hampir tidak pernah mampu membuat perubahan internal yang diperlukan untuk memastikan langkah itu berhasil. Satu-satunya toko Agile yang sukses yang saya kenal sudah mulai seperti itu. Saya tidak dapat mengingat satu contoh pun dalam pengalaman profesional saya tentang penjualan yang dikelola atau pengembangan toko perangkat lunak air terjun yang bergerak karena memerlukan perubahan mendasar dalam budaya.

Apakah perubahan budaya ini mungkin? Ya, tetapi dalam kasus Anda hampir pasti tidak.

Perubahan budaya biasanya diperlukan oleh pesaing yang mengancam keberadaan perusahaan atau membuat atau menghancurkan situasi atau situasi lain yang serupa untuk membenarkan re-org. Dalam situasi Anda, perusahaan Anda berada di ujung lain dari spektrum di mana uang saat ini mudah dan semua orang menjadi gemuk.

Perusahaan TIDAK PERNAH berubah dari dalam ketika uang itu mudah. Mengapa mereka, mereka berhasil meskipun kegagalan pengembangan perangkat lunak, bukan karena keberhasilan pengembangan perangkat lunak.

Nasihat terakhir saya adalah jika saya adalah Anda, saya akan mencari sesuatu yang lebih baik. Orang-orang di sini punya saran bagus tapi saya sudah pernah melihat lagu dan tarian ini sebelumnya dan itu tidak berhasil dalam situasi Anda.

lihat extremeeprogramming.org - XP adalah bentuk Agile dengan aspek yang mudah dipahami yang dapat Anda pilih dan pilih a la cart; tempat yang sangat bagus untuk memulai

komitmen pelanggan untuk tidak mengubah pikiran mereka selama interasi akan menjadi tempat awal yang baik untuk lingkungan Anda, dari suaranya ;-)

Jika seseorang mempertimbangkan lanskap metodologi, baik tradisional maupun kontemporer, orang akan menyadari bahwa "Agile" lebih merupakan "anti-metodologi" daripada metodologi. Pola bertujuan untuk menggambarkan solusi "kasus terbaik" untuk masalah yang diberikan dalam konteks tertentu. Upaya untuk secara langsung melanggar solusi atau pola seperti itu, umumnya disebut sebagai "anti-pola" atau praktik yang lebih buruk. Demikian juga, sementara metodologi pengembangan perangkat lunak yang sebenarnya mencoba untuk meresepkan praktik kasus terbaik dalam mengembangkan solusi, "Agile" (Scrum, XP, dll.) Berupaya untuk secara langsung melanggar setiap dan semua struktur dalam proses pengembangan perangkat lunak, dengan alasan kekacauan, serampangan pendekatan - yang (akhir-akhir ini), juga tampaknya menuntut tepuk tangan dari (naif) penonton.

Dengan mengatakan itu, adalah tepat untuk mengingat konteks di mana filsafat Agile muncul. Meskipun metodologi iteratif canggih (misalnya Proses Terpadu) ada pada saat itu, metodologi utama masih pendekatan air terjun tua, yang menetapkan "praktik terbaik" dari analisis persyaratan lengkap, kemudian desain lengkap, kemudian kembangkan / kode solusi, kemudian implementasikan solusinya. Jelas, pendekatan rekayasa untuk pengembangan perangkat lunak ini keliru - dan menghasilkan tumpukan dokumen sebelum (dan kadang-kadang tanpa pernah) melihat solusi yang dapat dieksekusi.

Namun, itu masih tidak menjamin membuang bayi dengan air mandi, seperti halnya dengan conjurers Agile. Pendekatan Agile hampir memberlakukan negasi langsung terhadap apa pun yang digunakan sebelumnya - kecuali mungkin pengkodean aktual dari solusi. Jelas, ini adalah indikasi dari wawasan yang terbatas pada bagian dari pencetusnya, atau mungkin itu hanya kasus "tidak ada yang buta, seperti mereka yang tidak ingin melihat".

Namun demikian, kelebihan tangkas adalah mendorong proses yang disederhanakan dan berfokus pada kode yang dapat dieksekusi - yang pasti merupakan hasil akhir Anda.

SEKARANG, untuk menjawab pertanyaan Anda lebih langsung:

Mengingat gambaran umum Anda tentang lingkungan Anda, saya sarankan Anda terlebih dahulu memilih implementasi Agile (yaitu Scrum, XP, dll). Kemudian sesuaikan pendekatan untuk menyesuaikan lingkungan Anda, menggambarkan proses yang jelas tentang bagaimana tim Anda akan bekerja, misalnya:

• Terima permintaan dari pengguna;

• Prioritaskan permintaan pengguna;

• Dampak peningkatan pengukur pada sistem yang ada (mungkin selama pertemuan harian / mingguan);

• Perkirakan waktu pengembangan setiap peningkatan - dan komunikasikan kembali ini ke berbagai pengguna yang meminta;

• Lakukan peningkatan yang sebenarnya pada sistem yang ada (yaitu pengkodean).

• Lakukan pengujian pengguna - dan dapatkan komitmen dari pengguna (mis. Melalui email) bahwa perubahan yang diminta telah berhasil dilaksanakan.

Ini harus menyediakan beberapa struktur (dan ketertiban), sementara juga mempertahankan beberapa kemiripan pendekatan Agile.

Dengan kata di atas, ingatlah bahwa kiasan bahasa Inggris kuno, "As Agile as a monyet", tidak diciptakan tanpa alasan!

Saya akan mengatakan Anda memerlukan metodologi seperti Agile sangat penting untuk tim Anda. Karena perusahaan Anda sangat tidak terorganisir, Anda perlu lebih terorganisir dalam tim pengembang Anda sendiri. Namun saya tidak berpikir manajer non teknis Anda harus ada hubungannya dengan itu.

Jika Anda akan mendorong kembali tenaga penjualan Anda dan menuntut tenggat waktu yang realistis, Anda perlu membenarkan hal itu dengan rencana yang terorganisir.

Juga pada seprate note jika mereka mendatangi Anda dengan perkiraan tanpa berkonsultasi dengan teknis maka cukup tolak saja.

Mungkin fokus pada aspek inkremental / iteratif adalah apa yang dibutuhkan oleh kedua tim Anda, dan para pemangku kepentingan yang jatuh cinta untuk dapat menyampaikan secara teratur dan konsisten. Seiring waktu, tim penjualan dan manajemen akan mendapatkan kepercayaan bahwa ketika mereka memasukkan permintaan fitur baru, mereka dapat yakin tim Anda akan mengirimkan dalam jangka waktu yang sesuai.

Tentu saja, Anda perlu berinvestasi dalam pengujian unit / sistem / regresi, build otomatis, dogfooding, dll, untuk sampai ke sana jika Anda belum berada di sana.

Pertama saya sarankan mengumpulkan beberapa data. Duduklah di waktu yang sunyi dan cari tahu apa sebenarnya status quo - bagaimana segala sesuatunya dilakukan. Jika manajemen sangat ingin menerapkan sesuatu yang mereka sebut lincah, maka cari tahu sesuatu yang akan bekerja untuk tim Anda, buat dokumen, tampar "Agile" pada nama dan Anda baik-baik saja. Perlu diingat bahwa satu-satunya hal yang benar-benar mereka ketahui tentang lincah adalah kata, dan beberapa asosiasi samar dengan cepat untuk definisi yang biasa dalam bahasa Inggris. Jadi yang saya anjurkan adalah bahwa tim Anda keluar di depan masalah, menemukan rasa yang cocok untuk Anda, dan kemudian menyajikannya kepada manajemen Anda sebagai cara Agile (tm). Kalau tidak, beberapa PHB akan mengambil buku dan mencoba memasukkan pasak persegi ke dalam lubang bundar dan tidak ada yang akan senang.

Jika Anda menggunakan bentuk lincah "murni", mungkin akan sulit jika tim Anda harus memenuhi peran dukungan juga. Mari kita hadapi itu, bos Anda mungkin merasa sulit untuk menerima anggota tim Anda menanggapi permintaan help-desk dengan mengatakan "biarkan saya membuat item jaminan, saya akan sampai di (waktu untuk mengakhiri sprint) minggu."

Rintangan terbesar adalah uang. Jika semuanya saus hijau, akan lebih sulit untuk mengatakan ada sesuatu yang salah dan perlu diubah.

Semoga berhasil.

Sebaliknya, bagi saya terdengar seperti metode Agile yang Anda butuhkan untuk mengatasi tenggat waktu yang terlewat, harapan yang tidak realistis, dan proyek yang tidak direncanakan dengan baik.

Manajemen Anda telah menunjukkan bahwa mereka tertarik pada kata Buzz baru ini. Kemungkinan besar mereka akan ingin menggunakannya untuk meningkatkan pemasaran produk Anda. ini tidak selalu merupakan hal yang buruk, tetapi perlu dikelola dengan sangat hati-hati jika Anda ingin membuat metode Agile bekerja untuk Anda.

Setengah pertempuran adalah mendapatkan dukungan dari manajemen. Memiliki mereka menerima ide Agile adalah sebagian besar pertempuran. Sisanya adalah untuk memastikan bahwa harapan mereka dikelola sehingga mereka terus ingin Anda gesit, dan untuk menghindari mereka menjadi kecewa ketika dan jika manajer Anda merasa seolah-olah kontrol mereka atas manajemen proyek sebagian besar menyelinap melalui jari-jari mereka.

Sebelum perusahaan Anda memutuskan apa pun, saya akan merekomendasikan untuk mendapatkan pelatih Agile untuk melakukan seminar setengah hari dan lokakarya. Buat Anda semua berpikir sebagai tim - baik manajer maupun pengembang - tentang apa itu tentang Agile yang menurut Anda akan berhasil bagi Anda, dan apa yang Anda rasa tidak akan berhasil. Jika di sisi lain manajemen memercayai penilaian Anda, maka Anda harus menjadi sangat terbiasa dengan sejumlah praktik dan Metode Agile, dan membuat seminar atau Anda sendiri. Secara pribadi, saya akan mengarahkan untuk mendapatkan pelatih yang berpengalaman, sehingga Anda tidak membuang banyak waktu, dan untuk menjaga momentum. Sementara itu, ambil beberapa buku Agile bagus sebagai referensi, bacalah dengan seksama, tetapi juga tinggalkan di sekitar meja Anda di mana manajemen dapat melihatnya. Psikologi bawah sadar dapat bekerja secara menakjubkan dalam situasi seperti yang telah Anda gambarkan.

Saya paling tidak merekomendasikan untuk membaca yang berikut ini:

• Pengembangan Perangkat Lunak Ramping - Mary & Tom Poppendieck
• Pengembangan Perangkat Lunak Agile - Robert C. Martin

dan untuk kredit tambahan (karena saya pikir itu adalah teman yang hebat untuk buku-buku lain yang saya sebutkan):

• Kode Bersih - Robert C. Martin