Bagaimana cara mengelola pengembang Agile bekerja dengan pelaku bisnis tradisional (serial)? [Tutup]

Selamat sore,

Lingkungan kerja saya memiliki beberapa masalah. Tim IT kami berusaha menjadi lebih gesit, tetapi kami tidak benar-benar menerima dukungan dari bisnis. Mereka menghadiri stand-up harian kami dan ulasan sprint, dan mereka membantu dengan perencanaan sprint, tetapi kemudian mereka berbalik dan melakukan 4 bulan persyaratan pengumpulan untuk proyek sebelum bergerak maju dengan gaya pengembangan serial (kebanyakan). Sasaran sprint adalah hal-hal seperti "dapatkan XX% lebih dekat untuk dirilis".

Untuk tim IT, mereka telah mengubah Sprint menjadi semacam pawai kematian. Kami mengakhiri Sprint suatu hari dan memulai Sprint baru pada hari berikutnya. Tidak ada refleksi atau perubahan yang dilakukan antara sprint, hanya selama.

Karena belum pernah melakukan metodologi tangkas seperti sebelumnya, saya belum pernah memiliki perkenalan yang menyenangkan. Jadi pertanyaan saya adalah:

1) Haruskah ada waktu (mungkin seminggu atau lebih) antara sprint untuk melakukan refleksi / introspeksi / perubahan / dll? Atau apakah back-to-back-to-back berlari norma?

2) Apakah ada peluang untuk bertahan hidup bagi tim yang gesit tanpa rekan bisnis yang gesit? Jika tidak, apakah ada beberapa metodologi transisi atau bahkan kiat untuk menggerakkan bisnis menuju pola pikir yang berulang jika tidak selalu gesit?

3) Haruskah seluruh tim Anda berada di setiap sprint? Kami memiliki hampir 20 programmer dalam satu sprint tetapi bekerja pada proyek yang sangat berbeda (biasanya tim 3-5, kadang-kadang lebih besar). Apakah normal memiliki satu sprint atau haruskah kita mencoba mengelola beberapa sprint independen? Haruskah kita mencoba untuk menjaga beberapa sprint berjalan berbarengan atau haruskah jadwalnya dibiarkan tumpang tindih dan fleksibel?

Setiap pemikiran atau saran sangat dihargai. Ini adalah pertama kalinya saya datang dari SO untuk sebuah pertanyaan, jadi tolong beri tahu saya jika ada cara yang lebih baik untuk mengutarakan pertanyaan-pertanyaan semacam ini (faq agak membantu, tetapi masih tidak yakin saya mengikutinya dengan sempurna). Terima kasih!

1) Biasanya Anda bisa meninjau sprint terakhir dalam satu pertemuan, merencanakan yang berikutnya dan memulainya. Terutama tinjau seberapa akurat perkiraan tugas dan masukkan ini ke dalam perkiraan untuk sprint berikutnya. Anda dapat menunda sprint berikutnya jika Anda perlu menunggu umpan balik pelanggan dari hasil yang sebelumnya dan Anda berpikir bahwa umpan balik akan mempengaruhi tugas untuk sprint berikutnya.

2) Ini tidak akan membuatnya lebih mudah, tetapi tim tentu saja dapat berhasil. Komentar Anda

Tujuan sprint adalah hal-hal seperti "dapatkan XX% lebih dekat untuk dirilis"

agak mengkhawatirkan karena idealnya Anda ingin menyertakan fitur / fungsi yang dapat dibuktikan sebagai tujuan dalam sprint.

3) Anda mengatakan ada 3-5 proyek yang sama sekali berbeda. Jika keduanya tidak terkait, yaitu untuk produk yang berbeda, tidak perlu disinkronkan, tetapi masing-masing harus diperlakukan sebagai sprint independen. Sepertinya tim Anda untuk setiap sprint mungkin ukuran yang bagus.

1) Haruskah ada waktu (mungkin seminggu atau lebih) antara sprint untuk melakukan refleksi / introspeksi / perubahan / dll?

Tidak. Seminggu? Kamu pasti gila. 2 jam adalah batasnya.

Atau apakah back-to-back-to-back berlari norma?

Benar. Kalau tidak, Anda memutar roda Anda.

Apakah ada peluang untuk bertahan hidup bagi tim yang gesit tanpa bagian bisnis yang gesit?

Bisnis tidak pernah "Agile". Agile adalah sesuatu yang Anda lakukan. Bukan mereka. Memang, tidak pernah mereka. Mereka hanya meminta barang acak. Anda mengelolanya.

Jika tidak, apakah ada beberapa metodologi transisi atau bahkan kiat untuk menggerakkan bisnis menuju pola pikir yang berulang jika tidak selalu gesit?

Tidak ada Anda menguraikan persyaratan menjadi sprint. Ini disiplin Anda. Bukan milik mereka.

Haruskah seluruh tim Anda ada di setiap sprint?

Iya.

Kami memiliki hampir 20 programmer dalam satu sprint tetapi bekerja pada proyek yang sangat berbeda (biasanya tim 3-5, kadang-kadang lebih besar).

Apa? Itu bukan tim. Itu sekelompok tim. 4 atau mungkin 5 tim yang terpisah.

Apakah normal memiliki satu sprint atau haruskah kita mencoba mengelola beberapa sprint independen?

Tidak tahu apa yang Anda bicarakan. Tapi, karena Anda tampaknya memiliki 4 atau 5 tim yang dihancurkan bersama-sama, jelas bahwa Anda akan memiliki kebingungan besar.

Haruskah kita mencoba untuk menjaga beberapa sprint berjalan berbarengan atau haruskah jadwalnya dibiarkan tumpang tindih dan fleksibel?

Setiap tim - dan sprint tim - adalah masalah tim. Tidak ada orang lain.

Beberapa hal yang orang-orang proyek besar seperti ini harus menjadi "Scrum of Scrums". Tim menetapkan tujuan mereka, membangun barang-barang mereka. Perwakilan dari setiap tim berkumpul bersama secara berkala untuk mengoordinasikan tim untuk mendapatkan rilis yang saling menguntungkan.

Maaf karena Anda berada dalam organisasi yang jelas-jelas tidak berfungsi.

Jika Anda ingin memiliki kemampuan untuk mengukur kemajuan, sangat penting bahwa Anda merencanakan dalam hal tonggak 100% lengkap. Jika ada ruang untuk ketidaksepakatan yang jujur ​​tentang apa tonggak sejarah tertentu, kecenderungan alami bagi orang yang melakukan pekerjaan untuk mengambil interpretasi yang paling optimis tentang seberapa banyak yang telah mereka lakukan, dan orang yang mendengar apa yang mereka katakan dengar itu. dengan cara yang paling optimis. Ini berarti bahwa berita menjadi lebih baik dan lebih baik ketika Anda naik rantai, mengarah ke pemutusan total antara kenyataan dan apa yang didengar top. http://www.davar.net/HUMOR/JOKES/SHIT.HTM adalah orang yang lucu, dan sepenuhnya realistis dalam menghadapi fenomena ini.

Seberapa buruk pemutusan ini? Pertimbangkan ini. Dalam proyek rata-rata, waktu aktual yang dibutuhkan untuk menyelesaikan (jika Anda pernah sampai di sana) rata-rata dua kali lipat dari perkiraan semula. Tetapi tidak peduli berapa banyak proyek yang tertunda, biasanya orang-orang di atas tidak mendapatkan petunjuk pertama bahwa proyek berada di belakang sampai sekitar 2 minggu sebelum tanggal jatuh tempo, karena itu adalah titik di mana putusnya hubungan antara harapan dan kenyataan tidak bisa lagi disembunyikan.

Oleh karena itu, tujuan yang mendekati XX% bukanlah persyaratan aktual. Secara harfiah tim Anda harus menolak untuk menerima itu sebagai persyaratan aktual. Adalah tugas Anda untuk mendidik mereka bahwa Anda memerlukan tugas-tugas konkret, dapat ditindaklanjuti, dan dalam perencanaan mereka perlu dipecah menjadi tugas-tugas spesifik yang dapat diperkirakan memakan waktu paling banyak beberapa jam.

Kedua, seperti yang orang lain katakan, Anda benar-benar perlu memecah tim Anda menjadi unit-unit yang lebih kecil, yang mungkin perlu berada pada jadwal yang berbeda. Penelitian menunjukkan bahwa satu tim perangkat lunak yang terdiri dari 20 orang yang mengerjakan satu hal dapat mencapai sebanyak tim yang terdiri dari 5-8 orang. (Saya menemukan fakta mengejutkan ini dalam buku Estimasi Perangkat Lunak Steve McConnell yang sangat bagus .)

Ketiga itu adalah bendera merah yang sangat besar sehingga rasanya seperti pawai kematian. Jika rasanya seperti pawai kematian, mungkin pawai kematian. Pengembang perangkat lunak cenderung berada pada kinerja puncak ketika mereka bekerja 35-40 jam seminggu. (Saya mendapatkan angka itu dari Perkembangan Cepat Steve McConnell .) Bekerja berjam-jam bisa mendapatkan peningkatan kinerja sementara, dengan biaya pengurangan kinerja jangka panjang. Proyek besar adalah maraton, Anda perlu mengatur kecepatan diri sendiri.

Keempat, benar-benar perlu ritme untuk lari cepat. Ketika saya bekerja dalam tim yang melakukan scrum, kami merasa sangat berguna untuk membagi setiap sprint menjadi dua bagian yang kami sebut "fokus panjang" dan "fokus pendek". Selama "fokus panjang" kami melakukan pengembangan perangkat lunak pada tugas-tugas yang telah disepakati untuk sprint itu. Selama "fokus singkat" kami melakukan semua hal yang diperlukan untuk melibatkan banyak gangguan dan pengalihan tugas. Jadi saat itulah kami melakukan QA, memperbaiki bug, berbagai pertemuan, memperkirakan tugas untuk sprint berikutnya, dan akhirnya menyepakati apa yang akan dan tidak akan terjadi dalam sprint berikutnya. Ini bekerja sangat baik bagi kami karena banyak pengembangan perangkat lunak hanya dapat dilakukan ketika Anda berada di "zona", yang umumnya tidak

Jika Anda mengikuti ritme seperti itu, maka Anda mendapatkan kemenangan lagi karena memiliki jadwal yang berbeda antar tim: orang-orang QA Anda selalu dapat bekerja pada tim apa pun yang saat ini berada di QA, yang membuat mereka tetap memiliki tingkat pekerjaan yang konstan.

Semoga beruntung, dan sadarilah bahwa tanpa dukungan dari atas Anda mungkin tidak dapat memperbaiki disfungsi. Jika itu masalahnya, maka pilihan realistis Anda yang terbaik adalah menemukan organisasi yang lebih sehat untuk menjadi bagian daripada mencoba menjadikan organisasi Anda menjadi sesuatu yang tidak akan terjadi.

1. Pengalaman saya adalah bahwa sprint pada umumnya kembali ke belakang dengan beberapa kehilangan waktu untuk melakukan retrospektif, menunjukkan fungsionalitas, dan merencanakan sprint berikutnya. Misalnya, hari terakhir sprint akan sering dianggap sebagai penghapusan karena akan ada 3 pertemuan yang berlangsung pada hari itu sehingga sprint 2 minggu setara dengan 9 hari kerja. Retrospektif pada akhir sprint dapat membawa perubahan untuk dicoba dalam sprint berikutnya yang dimulai segera dalam arti.

2. Kesempatan ya tapi agak kecil seolah-olah Anda menggunakan Scrum harus ada pemilik produk yang disetujui oleh manajemen untuk mengarahkan prioritas seberapa cepat beberapa cerita dibandingkan dengan yang lain. Harus ada beberapa pemahaman tentang tanggung jawab apa yang mereka miliki meskipun bagian lain adalah bahwa "XX% lebih dekat untuk melepaskan" adalah metrik yang agak buruk dalam pikiran saya karena ini cenderung tidak termasuk bug dan masalah menit terakhir lainnya yang hampir mustahil untuk dilakukan dengan benar memperkirakan dalam pengalaman saya yang terbatas. Ada juga sesuatu yang bisa dikatakan untuk dipahami ketika perubahan prioritas dapat diketahui oleh tim dan digunakan dalam perencanaan sprint. Dukungan manajemen sangat penting karena jika mereka tidak mengerti apa yang Anda lakukan, mungkin itu seperti mencoba melakukan pengiriman sambil berjalan di atas tapak stasioner yang stasioner. Saat kaki Anda bergerak, Anda tidak

3. Tidak harus tetapi kadang-kadang itu bisa terjadi. Kuncinya adalah untuk mengetahui berapa banyak masing-masing pengembang dialokasikan untuk proyek dan menjaga ini konsisten sehingga ketika ada kecepatan dari beberapa sprint awal pertama, ini berguna dalam memprediksi kecepatan masa depan daripada tidak berguna karena jumlah jam kerja pada proyek memantul terlalu banyak untuk memperkirakan lebih mudah berapa banyak poin yang dapat dilakukan dalam sprint. Setiap proyek harus memiliki set sprint sendiri jika proyek tersebut cukup besar untuk rentang minggu kerja.

Semoga sukses dalam mendidik manajemen dalam hal apa yang harus mereka lakukan dan bagaimana ini bekerja karena itu mungkin menjadi rintangan besar Anda untuk diatasi di sini.

Jika proyek Anda menggunakan Scrum, maka Anda harus memiliki Scrummaster yang tugasnya adalah untuk mendidik semua pihak tentang bagaimana sebenarnya proses seharusnya bekerja. Jika Anda melakukan Scrum, sepertinya scrummaster tidak melakukan pekerjaannya, karena tidak memiliki buyoff dari sisi bisnis proyek adalah penghalang besar (dan tidak jarang).

Beritahu orang-orang program untuk mengacaukannya jika mereka mengatakan mendapatkan XX% lebih dekat untuk selesai. Beri tahu mereka bahwa Anda akan menyelesaikan X, Y, dan Z yang diperlukan pada tanggal ini dan itu. Jika mereka ingin mengontrak jadwal, tanyakan kepada mereka apa yang ingin mereka hapus, jika mereka menolak mengatakan bahwa mereka menghapus barang atau menambah waktu. Mengatakan menyelesaikannya atau tidak akan ada gunanya. Jika mereka mendorong menetapkan kode manajer proyek Anda untuk menyelesaikan sprint itu. Ingatlah Agile adalah upaya tim. Jika orang-orang manajemen proyek tidak bekerja 12 jam sehari, mereka lebih baik pergi ke sana untuk mengambil pizza dan soda untuk orang-orang yang ada dan bonus apa pun untuk menyelesaikan sesuatu atau lebih cepat dari jadwal, lebih baik pergi ke orang-orang yang melakukan pekerjaan juga. Beri tahu mgmt atas jika Anda juga, mereka mungkin yang mendorong Agile kepada Anda tanpa melatih orang-orang manajemen proyek.

Lacak kemajuan Anda, buat penyesuaian, lalu pilih persyaratan berikutnya yang harus dipenuhi. Jika proyek tidak akan dikirim sampai semuanya selesai, jangan khawatir tentang prioritas fitur, khawatir tentang fitur apa yang penting bagi Anda bahwa mereka akan dilakukan untuk bagian selanjutnya. Anda harus mengambil kepemilikan ini. Seharusnya tidak menjadi pawai kematian juga. Proyek scrum harus mengukur jumlah pekerjaan yang dapat Anda selesaikan selama sprint NORMAL. Itu 10 (atau 9 seperti disebutkan di atas) normal 8 jam hari kerja.

Satu hal yang saya dengar pada konferensi Agile beberapa tahun yang lalu adalah bahwa tim Anda seperti sebuah pabrik dan dapat menghasilkan jumlah X mobil (atau dalam fitur kasus Anda) per sprint.

Juga tim sprint Anda harus 3 hingga 5 orang bukan 20. Itu bisa menjadi bagian dari masalah. Setiap tim harus memilih cerita mereka (persyaratan item baris jika Anda suka) dan bekerja untuk itu. Mereka harus scrum secara terpisah, tetapi bertemu kelompok besar berdasarkan beberapa untuk berbagi ide.

Ketika mengelola jenis tim ini, mungkin lebih baik bagi manajer untuk scrum secara terpisah untuk menentukan tugas lintas tim apa yang dibutuhkan dan menghubungkan orang yang tepat. Standup 20 orang monoton dan membosankan bagi mereka yang terlibat.