Apakah menetapkan tanggal pengiriman untuk elemen merupakan cara kerja yang “Agile”?

Kami terus diberi tahu bahwa kami akan bekerja dengan gesit dalam proyek baru oleh manajemen senior. Mereka telah mengatur stand-up, perencanaan sprint, retrospektif dll. Namun, mereka sekarang telah datang dengan rencana yang merinci semua pekerjaan yang mereka ingin kami sampaikan dengan tanggal terhadap setiap elemen dan menampilkan tanggal lagi dengan apa yang akan diperagakan di masing-masing satu. Paket ini berlaku untuk Q2 2017.

Bagi saya ini sepertinya Air Terjun dalam pengertian terburuk, sebuah rencana tanpa masukan dari tim teknis telah disusun di mana cerita-cerita tertentu pada rencana itu sangat tidak jelas dan tidak ada yang diperkirakan oleh tim pengembang.

Namun, saya tahu argumen mereka adalah "para pemangku kepentingan senior harus memiliki tanggal dan harus ada rencana, kita tidak bisa hanya bekerja dari jaminan simpanan." Bagi saya ini tampaknya para pemangku kepentingan senior belum membeli ke Agile dan oleh karena itu kita pasti gagal menerapkannya di tingkat yang lebih rendah.

Apakah ini penilaian yang adil atau apakah saya bereaksi berlebihan terhadap rencana ini !?

Ada perbedaan antara memenuhi tenggat waktu dan memenuhi semua persyaratan. Ini seperti pepatah lama "cepat, bagus atau murah, pilih dua".

Jadi di sini Anda memiliki tanggal pengiriman yang pasti - itu bagus, itu berarti Anda memiliki kotak waktu sehingga apa yang Anda hasilkan pada akhir sprint terakhir Anda akan menjadi produk akhir. Anda ingat bahwa Anda selalu harus merilis perangkat lunak yang berfungsi di akhir setiap sprint bukan.

Apa yang mungkin terjadi adalah bahwa perangkat lunak akhir akan kehilangan beberapa fitur. Nah, ini terjadi dengan semua metodologi pengembangan, termasuk air terjun. Semua yang akan terjadi adalah bahwa Anda akan ditugasi memproduksi rilis patch setelahnya, atau versi 2. Itu mengasumsikan pengiriman akhir Anda cukup bagus tentunya!

Jadi tanggal tetap bukan cara kerja yang tidak gesit. Agile bukan berarti ada anggaran tak terbatas untuk Anda mainkan dengan alat perencanaan baru Anda. Itu berarti Anda harus fokus pada pengiriman, itu bukan hal yang buruk.

Tidak. Ini adalah jenis persis hal yang cenderung dilakukan oleh perusahaan non-perangkat lunak. Ada rencana, tenggat waktu, dan anggaran. Dan itu pasti akan gagal, karena manusia payah dalam memprediksi masa depan.

Mari kita membahas berbagai poin di sini:

Kami terus diberi tahu bahwa kami akan bekerja dengan gesit dalam proyek baru oleh manajemen senior.

Jika Anda tangkas, maka Anda akan memiliki tim yang terorganisir sendiri, tidak diberi tahu cara bekerja oleh manajemen.

Namun, mereka sekarang telah datang dengan rencana yang merinci semua pekerjaan yang mereka ingin kami sampaikan dengan tanggal terhadap setiap elemen dan menampilkan tanggal lagi dengan apa yang akan diperagakan di masing-masing.

Nggak. Itu cukup banyak antitesis dari pengembangan berulang. Sesuatu akan terjadi (seseorang sakit, seseorang pergi, beberapa persyaratan dilupakan, server Anda mati, apa pun) dan kemudian Anda kehilangan salah satu dari tujuan ini. Sekarang manajemen dapat menghitung ulang seluruh rencana, atau memecahkan cambuk pada pengembangan.

tidak ada yang diperkirakan oleh tim pengembang.

Jadi bagaimana manajemen tahu bahwa rencana ini layak sama sekali ? Di Agile, bekerja adalah negosiasi. Bisnis berkata: kami ingin ini. Rekayasa mengatakan: oke, anggap XYZ, itu akan memakan waktu 3 minggu. Tidak ada kolaborasi pelanggan dalam apa yang Anda gambarkan. Tidak ada individu dan interaksi.

Bagi saya ini tampaknya para pemangku kepentingan senior belum membeli ke Agile dan oleh karena itu kita pasti gagal menerapkannya di tingkat yang lebih rendah.

Anda belum tentu dikutuk, tetapi jika tidak, itu hanya kebetulan. Ketika semua pekerjaan muncul karena manajemen tidak dapat melihat masa depan, Anda akan kehilangan tanggal Anda (atau menghasilkan kode jelek, atau membutuhkan lebih banyak sumber daya dari yang diharapkan). Itu akan menjadi kesalahan Anda . Manajemen kemungkinan akan menekan Anda untuk bekerja lebih lama untuk mencapai tanggal tersebut, atau mungkin membuat orang lain bermasalah.

Kasus terbaik , manajemen sebenarnya gesit, dan cukup pintar untuk mengurangi ruang lingkup. Berarti mereka hanya menghabiskan semua waktu ini untuk membangun rencana terperinci besar yang tidak berharga.

Jika ada harapan bahwa serangkaian fitur tertentu akan dikirimkan pada tanggal tertentu, maka tidak, ini bukan manajemen proyek yang gesit. Manajemen proyek yang gesit bersifat empiris. Proyeksi tidak dibuat berdasarkan keinginan eksekutif tetapi lebih pada analisis kinerja sebelumnya.

Deskripsi Anda cocok dengan apa yang saya anggap gesit dalam kargo. Fokusnya adalah pada proses dan upacara khusus dan bukan pada konsep inti manajemen proyek berbasis bukti. Anda mungkin beruntung membuat pebisnis mengerti jika Anda menghubungkan ini dengan Lean atau TPS . Masalah sebenarnya yang perlu Anda selesaikan di sini adalah manajemen mengatasi ketakutan mereka terhadap hal yang tidak diketahui. Jawaban yang tepat untuk para eksekutif adalah "kami tidak dapat memberi tahu Anda sekarang ketika hal-hal akan dilakukan tetapi begitu kami mulai memberikan nilai, kami dapat membangun proyeksi berdasarkan pengalaman kami." Pengembang cenderung mengatakan hal-hal seperti "selesai ketika sudah selesai" dan "Saya tidak tahu kapan akan selesai." Manajer tidak akan mengatakan hal-hal seperti itu kepada para eksekutif, itu membuat mereka terdengar seperti orang bodoh.

Kemungkinan besar, rencana itu akan gagal dan perlu direvisi. Risiko terbesar bagi tim adalah bahwa akan ada dorongan besar untuk mencapai tenggat waktu dan kualitas akan menurun. Pada titik tertentu Anda tidak akan tepat sasaran (kemungkinan besar, itu akan menjadi batas waktu pertama) dan akan ada dorongan untuk mencapai tanggal tersebut. Lembur akan diharapkan dan akan ada tekanan untuk mengambil jalan pintas (lewati uji unit, ulasan kode, dll.) Ini adalah lereng yang licin dan sekali Anda memulai jalur ini, itu sedikit spiral ke bawah dan segalanya akan menjadi jelek. Produktivitas akan bertambah buruk ketika proyek berlanjut dengan cara ini.

Jika Anda bisa membuat tim dev untuk menghadirkan front yang terpadu, Anda harus mendorong dan mempertahankan kualitas. Pengalaman saya adalah bahwa manajer proyek cenderung berpikir bahwa output perangkat lunak itu linier. Artinya, setiap periode X akan menghasilkan Y 'presentase complete'. Artinya, jika Anda tidak "50% selesai" dengan setengah waktu yang diizinkan, klaxon mulai menggelegar. Pada kenyataannya, jika Anda melakukannya dengan benar, fitur pertama cenderung memakan waktu lebih lama daripada fitur ke-50 (dengan ukuran yang sama.) Jika Anda dapat melewati periode krisis bahaya awal ("apa yang terjadi?", "Saya tidak tahu." t melihat sesuatu dilakukan! ") Anda mungkin akan baik-baik saja.

Selamat datang di bisnis nyata.

Ada gaya bisnis yang lebih tua, yang cenderung saya sebut "pengembangan tradisional" dan kemudian ada gaya baru, "pengembangan gesit." Jika saya mencoba memperlakukan ini sebagai cita-cita yang berlawanan, kita melihat pembagian langsung di tengah: rencana dan persyaratan masuk pada kolom tradisional, penemuan dan evolusi masuk dalam kolom lincah. Rapi, rapi, dan salah.

Pada kenyataannya, bisnis adalah pencarian media yang membahagiakan di antara keduanya. Sangat mudah untuk menunjukkan bahwa kedua ekstrim benar-benar jatuh datar di wajahnya. Kami yang mencintai Agile dengan penuh semangat menunjukkan semua masalah dari cita-cita murni pengembangan tradisional, dan ada banyak yang dapat menunjukkan banyak cara Agile yang murni hancur berantakan. Perusahaan tangkas yang sukses adalah yang menemukan keseimbangan khusus antara keduanya. Perusahaan tradisional yang sukses adalah yang menemukan keseimbangan khusus antara keduanya. Anda tidak dapat memiliki satu tanpa yang lain.

Bahkan proses SCRUM kita yang diberkati menunjukkan keseimbangan di antara keduanya. Meskipun ada upaya yang jelas untuk memaksimalkan kelincahan, ada beberapa tradeoff kunci yang dibuat. Sebagai contoh, Pemilik Produk memiliki tugas advokasi yang kuat untuk semua pelanggan. SCRUM sengaja tidak menentukan bagaimana interaksi itu bekerja. Itu sengaja menyerahkan fakta bahwa setiap orang perlu dibayar pada akhir hari. Adalah tugas Pemilik Produk untuk menciptakan ilusi bahwa itu tidak masalah.

(Sangat menarik untuk dicatat bahwa kelincahan murni berfungsi dengan baik, asalkan Anda tidak dibayar sampai Anda menghasilkan produk, dan Anda tidak mendapatkan akses ke informasi hak milik sampai Anda berada di tangan. Saya pikir satu-satunya insinyur perangkat lunak yang nyaman dengan perdagangan ini adalah pengusaha)

Jadi manajemen telah menentukan fitur apa yang akan ada di sana dan kapan mereka harus ada di sana. Tidak apa-apa. Sebuah frasa yang saya dengar adalah "pelanggan memilih apa dan kapan, produser memilih siapa dan bagaimana." Anda telah mendaftar untuk "apa" dan "kapan". Mereka belum menyatakan apa-apa tentang siapa atau bagaimana, selain menawarkan Anda kesempatan untuk menggunakan "Agile" sebagai cara Anda. Yang tersisa adalah membantu manajemen memahami berapa banyak orang yang akan mereka perlu sewa untuk memenuhi kebutuhan mereka.

Di dunia yang sempurna, perusahaan Anda gesit dari luar. Ini berinteraksi dengan pelanggannya dengan cara yang gesit, membiarkan pengembang berkembang dengan tangkas untuk mereka. Namun, sangat sering perusahaan harus berinteraksi dengan pihak luar sambil berkembang dengan tangkas di dalam. Di antara selalu ada satu set pengorbanan yang kompleks, unik untuk masing-masing perusahaan.

Secara pribadi, saya memperlakukan situasi ini sebagai ujian bagi siapa pun yang berpikir mereka memahami perkembangan gesit. Pada titik tertentu di masa depan, Anda harus mengembangkan produk untuk tenggat waktu, dan pasangan produk / tenggat waktu akan relatif tetap. Jika produk tetap / tenggat waktu menghancurkan proses Anda, dapatkah Anda benar-benar mengatakan bahwa Anda Agile sejak awal?

Saran saya: jangan menganggap ini sebagai air terjun. Anda masih mengendalikan "bagaimana." Anda masih dapat melakukan semua sprinting cepat dan prototyping fleksibel yang Agile sangat terkenal. Anda hanya perlu menyadari bahwa karet memenuhi jalan, dan Anda harus mengirimkannya. Ini adalah dunia nyata, bukan dunia ideal. Akankah lebih baik bagi mereka untuk meminta Anda sejak awal? Tentu. Itu mungkin bukan panggilan Anda. Mungkin ada seribu alasan yang terkait dengan bisnis untuk melakukannya dengan cara yang Anda tidak mengerti sepenuhnya. Jangan ragu untuk menekan mereka, tetapi pahamilah bahwa mereka mungkin memiliki alasan yang sangat baik untuk apa yang mereka lakukan.

Agile tidak mencegah Anda dari merencanakan tonggak (Misalnya kami akan merilis V 1.0 dalam 3 bulan), tetapi apa yang masuk ke setiap tonggak tidak dapat diperbaiki.

Saya pikir bagaimana Anda harus bereaksi tergantung pada sifat proyek. Jika proyek ini akan mengirim seorang pria ke bulan pada Q2 2017 semua orang akan setuju bahwa itu pasti akan gagal. Jika Anda pikir Anda dapat mengirimkan MVP pada akhir Q2 2017, Anda harus mengerjakannya sprint demi sprint.

Jika manajemen berpikir tim Anda melakukan yang terbaik dan Anda dapat menunjukkan kemajuan dengan setiap sprint, Anda harus dapat bernegosiasi untuk waktu yang lebih lama.

SETIAP proyek bisnis yang relevan memiliki kendala:

• Waktu
• Sumber daya
• Kumpulan fitur minimum yang diharapkan

Ini tidak lain. Berkembang tangkas tidak berarti "orang membayar kita uang, jadi kita bisa mengembangkan apa pun yang kita inginkan kapan pun siap" - Anda akan selalu memiliki kerangka waktu. Akan selalu ada beberapa tanggal dengan beberapa persyaratan minimum dan jika tidak terpenuhi proyek akan dibatalkan dan disebut gagal. Kadang-kadang mereka mungkin implisit - jadi manajer tahu "Jika saya tidak memiliki UI yang berfungsi dengan fitur-fitur ini setelah 4 minggu, proyek ini pasti gagal" - atau mungkin ada pemegang saham yang menetapkan tujuan.

Ada banyak proyek yang dihasilkan dari undang-undang. - Jika pemerintah memutuskan Anda harus mengimplementasikan Fitur X hingga 2017 untuk menghormati undang-undang baru, Anda akan memiliki tenggat waktu yang tidak dapat dinegosiasikan dan serangkaian fitur yang harus siap. Satu-satunya variabel adalah jumlah sumber daya yang dapat dialokasikan manajemen untuk tugas tersebut. - Dan dalam proyek-proyek ini, di mana tenggat waktu adalah keputusan eksternal, mereka akan perlu mengawasi kemajuan Anda, mendengar prognosis Anda dan menyiapkan tim atau meng-outsource bagian dari pekerjaan untuk memenuhi tujuan mereka.

Semua ini tidak menentang pengembangan gesit. Anda masih akan memiliki sprint Anda, kembangkan fitur-fitur Anda dalam kerangka waktu Anda sendiri. Anda akan selalu mendapatkan prioritas fitur dari klien - dan Anda akan berupaya memberikan sebanyak mungkin fitur ini hingga tenggat waktu.

Jika tenggat waktu benar-benar akan dipenuhi dengan sumber daya yang tersedia adalah masalah manajemen. Anda dapat memberikan prognosis dan pembaruan status mingguan / harian Anda dan mereka dapat memutuskan apakah mereka membutuhkan lebih banyak sumber daya. Kalau tidak, Anda akan terus bekerja dalam sprint dan memberikan runnables - sama seperti proyek apa pun.

Seperti yang telah ditunjukkan seseorang sebelum manifesto mengatakan:

Individu dan interaksi selama proses

Saya akan menyarankan Anda melihat rencana yang diajukan dan menyarankan perubahan padanya. Ingat Manifesto mengatakan bahwa jaminan tidak pernah final, itu terus berkembang.

Jadi, Anda bisa membawa saran Anda ke tim. Jika Anda memiliki alasan yang masuk akal dan tim menyetujuinya, setiap pemilik produk yang bernilai garamnya akan mempertimbangkannya dan menghindari tumpukan simpanan untuk mencerminkan pendapat seluruh tim.

Ini adalah titik di mana ia bisa pergi dua arah.

1. Pemilik produk dan bisnis setuju dengan alasan Anda dan dapat menambah sumber daya untuk memenuhi tenggat waktu jika itu pilihan ATAU mereka dapat memilih untuk membatalkan beberapa fitur untuk memenuhi tenggat waktu.

2. Mereka mungkin masih ingin tetap berpegang pada versi mereka sendiri terhadap opini kolektif tim.

Jika hasilnya adalah # 2 maka ini bukan Agile.

Jika Anda berakhir dengan # 1 maka saya akan mengatakan tim berada di jalur yang benar, karena Agile bukan hanya tentang Devs "Menanggapi perubahan" itu juga tentang bisnis yang mampu merespons perubahan.

Bayangkan meminta seseorang untuk melukis dinding, rumah dan kemudian seluruh jalan untuk Anda, berapa banyak waktu yang Anda berikan kepada orang itu untuk melakukannya?

Apa pun jawaban Anda, Anda akan salah. Itu dia.

Tidak mungkin mereka bisa benar tentang kencan jika mereka tidak bertanya kepada orang-orang yang perlu melakukan pekerjaan apa yang mereka pikirkan.

Ngomong-ngomong, jika Anda (sebagai tim) menerima tanggal ini, Anda salah di sana.

Anda harus meminta waktu untuk mengerjakan perencanaan ini bersama dengan para pemangku kepentingan, sehingga Anda dapat menetapkan prioritas tergantung pada seberapa mudah dan cepat menyelesaikan pekerjaan.

Misalnya, mungkin tugas akhir akan memakan waktu dua kali lebih lama dari yang mereka kira, tetapi mereka bisa menggunakan beta lebih cepat dari yang mereka harapkan.

Secara keseluruhan, Anda tidak bisa membiarkan orang berpikir Anda dapat melakukan X dalam waktu Y jika Anda tidak bisa atau bisa lebih cepat, itu tanggung jawab Anda untuk memperjelas tentang apa yang Anda butuhkan dalam hal detail dan waktu.

Ini bukan perencanaan aglie no.

Tetapi jika Anda berpura-pura tidak tahu rencana dan hanya bekerja sprint demi sprint. Bisa jadi bekerja dengan berat.

Akan selalu ada tanggal dan anggaran. Selalu ada risiko mereka akan terlewatkan atau dibanjiri dan ketika itu terjadi Anda selalu harus kembali ke rencana B.

Jika Anda telah bekerja dengan cara yang gesit maka rencana B semoga menjadi demo sprint terakhir