Perencanaan jangka panjang dan gesit?

Tim saya baru-baru ini melalui proses menyusun rencana hampir satu tahun untuk pekerjaan kami. Kami memisahkan rencana menjadi tiga fase. Setiap fase akan mencakup beberapa peluncuran.

Saya ingin tahu, dari sudut pandang Anda yang lincah, apakah ini salah? Saya pikir itu bukan ide yang buruk, karena kami tidak menghabiskan terlalu banyak waktu untuk mendesain apa pun kecuali beberapa langkah pertama. Mungkin bagi kita untuk mengubah arah. Pada saat yang sama itu bagus bahwa kita tidak bertindak hanya dengan waktu dekat yang terlihat.

Memiliki visi tentang ke mana proyek akan pergi adalah Good Thing ^TM .

Percaya bahwa itulah tepatnya yang akan terjadi bukanlah.

"Dalam mempersiapkan pertempuran aku selalu menemukan bahwa rencana itu tidak berguna, tetapi perencanaan sangat diperlukan."

- Dwight D. Eisenhower

Metodologi Agile mengambil pendekatan adalah untuk memecah hal-hal menjadi bagian-bagian yang dapat dicerna, dan menyesuaikan kembali visi setelah masing-masing bagian telah dicerna.

Itu berarti titik akhir Anda dalam satu tahun dari sekarang tidak akan persis seperti yang Anda pikirkan sekarang. Namun, Anda harus menangani semua item bernilai tinggi di daftar Anda dan membuat para pemangku kepentingan Anda tetap terlibat dan bahagia saat Anda bergerak maju.

OK, manajemen telah disajikan dengan mitos untuk direncanakan oleh. Saya harap, demi Anda, bahwa mereka tidak menahan Anda untuk itu. Karena, tanpa terlihat, saya berani bertaruh uang bahwa tim Anda tidak akan mencapai apa pun seperti apa yang dikatakan rencana jangka panjang. Bahkan jika Anda mencapai rata-rata industri, Anda akan kehilangan sekitar faktor 2. Dan di sebagian besar organisasi, satu perkiraan, setelah diberikan, menjadi klub mereka bebas untuk mengalahkan Anda dengan sebanyak yang mereka inginkan.

Anda mungkin berpikir bahwa saya hanya bersikap sinis. Lagi pula, Anda baru saja mengomunikasikan waktu yang tidak jelas untuk serangkaian fitur yang tidak ditentukan yang diketahui semua orang bisa terjadi jauh lebih lambat atau lebih cepat daripada yang diproyeksikan, kan? Maaf, sebagian besar itu mungkin benar, tetapi bukan itu yang cenderung orang dengar angka-angka itu. Mereka telah mendengar kencan, dan kencan yang pernah diucapkan cenderung terdengar lebih solid daripada yang Anda katakan. Selanjutnya jika ada rantai komunikasi, itu akan menjadi lebih solid lagi. Dan begitu pelanggan eksternal dijanjikan sesuatu berdasarkan penjualan berdasarkan apa yang Anda katakan, tiba-tiba Anda akan menemukan bahwa ada jauh lebih sedikit fleksibilitas dalam angka-angka itu daripada yang seharusnya. Dan saya jamin Anda meremehkan waktu yang dibutuhkan.

Dengan poin yang jelas itu, saya akan merekomendasikan Anda membaca Estimasi Perangkat Lunak untuk mempelajari sesuatu tentang bagaimana estimasi perangkat lunak harus benar - benar dilakukan. Anda akan belajar banyak tentang kesalahan Anda, dan bagaimana melakukan lebih baik lain kali. (Dalam prosesnya Anda akan belajar mengapa saya begitu yakin bahwa Anda terlalu tinggi memperkirakan apa yang akan Anda lakukan.)

Yang mengatakan, lincah sebagian besar tentang mengurangi proses untuk apa yang sesuai untuk tim kecil. Seringkali cara yang baik untuk mengurangi proses adalah mencoba mengurangi perencanaan jangka panjang berskala besar demi perencanaan hal-hal kecil dalam jangka pendek. Itu juga cenderung lebih jujur ​​- karena Anda tidak tahu apa yang akan terjadi di masa depan. Namun itu sering tidak sesuai dengan kebutuhan bisnis yang lebih besar, dan, terlepas dari apakah Anda menyatakan diri Anda gesit, Anda terkadang perlu menyusun rencana yang lebih panjang.

Dengan itu, saya sangat menyarankan Anda untuk menemukan fakta kunci tentang tanggal yang Anda komunikasikan, yang sayangnya kemungkinan akan kembali sebagai tenggat waktu untuk menggigit Anda. Dan fakta itu adalah ini. Mana yang dipedulikan orang, tanggal, atau set fitur? Inilah yang saya maksud dengan itu. Seringkali organisasi memiliki tanggal spesifik yang penting. Misalnya menyelesaikan sesuatu untuk konferensi atau sebelum liburan terburu-buru. Dalam hal ini yang penting adalah melepaskan sesuatu, dan tidak begitu banyak apakah sesuatu itu selesai. Lain kali ada satu set fitur yang benar-benar perlu dirilis bersama, dan kelengkapan lebih penting daripada kapan tepatnya itu terjadi. Jika Anda dapat menemukan situasi di mana Anda berada, maka tim Anda akan berada dalam posisi yang jauh lebih baik untuk merencanakan cara menangani (hampir) krisis yang tak terhindarkan yang akan datang.

Tidak masalah memiliki rencana selama Anda menganggapnya masih dalam proses dan bukan sesuatu yang ditulis dalam batu.

Kuncinya di sini adalah membuat rilis secara teratur (setidaknya setiap bulan), mengumpulkan umpan balik nyata dari pengguna Anda dan memperbarui rencana Anda berdasarkan umpan balik itu.

Ini berarti bahwa rencana Anda akan berubah ketika ruang lingkup proyek berubah. Ini adalah hal yang baik , karena itu berarti pengguna Anda telah belajar lebih banyak tentang apa yang mereka inginkan.

Dengan asumsi oleh project-managementdan agileAnda berarti Scrum, ini tidak akan menjadi cara yang tepat untuk pergi.

Dalam Scrumperspektif, jika Anda memiliki rencana satu tahun, Anda setidaknya harus memiliki Sprint sebanyak bulan dalam setahun. Karenanya, rencana satu tahun Anda menjadi lebih gesit karena dapat diubah antara dua Sprint.

A Sprinttidak boleh lebih dari sebulan, di mana Teamberkomitmen untuk membawa Sprint Backlog Itemske status Done.

Doneadalah kata yang penting di sini, dan masing-masing Scrum Teamharus memiliki satu definisi selesai, yaitu, di mana tidak ada pekerjaan yang tersisa untuk dilakukan. Ketika Sprint Backlog Itemsedang Selesai , ini berarti bahwa analisis, arsitektur dan teknis dokumentasi tertulis, dan bahwa fitur tersebut telah diuji secara menyeluruh (unit test, tes integrasi, tes fungsional ...).

Setelah Product Backlogada, dan Item diprioritaskan dengan fitur yang kurang penting di bagian bawah, dan yang paling penting di atas, Tim (pengembang) menentukan berapa lama pengembangan masing-masing Product Backlog Itemakan didasarkan pada pengalaman mereka sendiri. Di situlah Anda dapat menentukan bahwa proyek akan membutuhkan satu tahun penuh kerja. Anggap itu hanyaProduct Ownerharus memprioritaskan Barang karena dialah yang bertanggung jawab atas pengembalian investasi, atau yang lain, tahu apa yang paling penting bagi pengguna akhir. Plus, Tim akan mengevaluasi waktu yang diperlukan untuk mengembangkan fitur sepenuhnya walaupun mungkin ada potongan kode yang dapat digunakan kembali di sana-sini yang dapat sesuai dengan kebutuhan fitur ini, yaitu, untuk menghindari kerumitan lebih lanjut dan memastikan bahwa suatu Item tidak boleh diambil. lebih lama dari apa yang dibutuhkan oleh Tim. Product Backlog tidak harus sempurna! Penghitungan sederhana cerita pengguna yang dapat kita pikirkan tentang sistem untuk dikembangkan sudah cukup pada langkah proses itu.

Selama Sprint Planning MeetingTim harus berkomitmen pada apa yang akan dikembangkan untuk selanjutnya Sprint, sehingga menciptakan Sprint Backlog. The Sprint Backlogterdiri dari subset berdasarkan Product Backlog Itemsbahwa Teamkomit harus dilakukan pada akhir Sprint. Mempertimbangkan, misalnya, Backlog Produk yang terdiri dari 50 Item, dan semua 50 Item akan membutuhkan waktu satu tahun untuk diselesaikan, maka Tim mungkin ingin memilih katakanlah 5 Item dari Product Backlog, dan buat Sprint Backlog dengan 5 Item ini. 5 Item yang sama ini dapat diperluas / meledak menjadi beberapa Item lainnya bila diperlukan, sehingga membuat Tim mungkin berubah pikiran setelah revisi dan berkomitmen untuk melakukan hanya 4 Item dari 5 Item yang sebelumnya dipilih dari Product Backlog.

Setelah Rapat Perencanaan Sprint selesai, yang dapat berlangsung tidak lebih dari 8 jam selama sebulan penuh Sprint, di mana Tim tidak hanya berkomitmen untuk melakukan pekerjaan untuk Item yang dipilih, tetapi merencanakan bagaimana hal itu akan menyelesaikan pekerjaan sehingga setiap orang dalam Tim tahu persis apa yang harus dia lakukan, Sprintakan dimulai. Penting bagi Tim untuk berfungsi lintas fungsi demi proyek.

Yang mengatakan, pada akhir setiap Sprint, yang berlangsung sebulan dalam situasi saat ini, semua Item yang Teamberkomitmen untuk dilakukan adalah fitur fungsional yang dapat dikirim yang menargetkan Item yang dipilih dari Product Backlog. Itu harus disampaikan, tetapi tidak wajib bahwa itu disampaikan jika tidak masuk akal untuk melakukannya sesuai dengan Product Owner.

Adalah selama di Sprint Review Meetingmana Product Ownerdiminta untuk dipanggil yang Teammenunjukkan apa yang dilakukan selama Sprint, dan di mana ia perlu memberi tahu mengapa itu tidak dilakukan, jika berlaku, semua pekerjaan yang dilakukan. Pekerjaan yang dibatalkan kemudian dimasukkan kembali ke dalam Product Backlogdan tersedia untuk selanjutnya Sprint. Tentu Item-item yang dibatalkan ini harus dimasukkan dalam Sprint berikutnya kecuali dinyatakan lain oleh Pemilik Produk, jika tujuannya telah berubah. Tetapi yang paling penting, meskipun tujuan sistem berubah selama Sprint, jangan menyela kecuali benar-benar diperlukan. Hanya Pemilik Produk yang memiliki wewenang untuk mengganggu Sprint.

Setelah Sprint Review Meetingselesai, yang seharusnya tidak lebih dari 4 jam untuk Sprint bulanan (jika saya ingat dengan benar), sekarang saatnya untuk sampai ke Sprint Retrospective Meeting. The Sprint Retrospectivediperlukan untuk Teamterjadi sehingga dapat mendiskusikan, di hadapan Master Scrum dan Pemilik Produk (opsional) apa yang salah, bagaimana Tim Scrum dapat meningkatkan kinerjanya, dll dan membawa penyesuaian sesuai.

Ketika kotak waktu untuk Sprint Retrospectiveselesai, maka yang baru Sprint Planning Meetingakan terjadi untuk merencanakan yang berikutnya Sprintdan membuat yang baru Sprint Backlog.

Ingat, penanggung Teamjawab untuk mempertahankan Daily Scrumyang merupakan pertemuan berdiri 15 menit di mana setiap Anggota Tim menjawab tiga pertanyaan (tidak dalam urutan tertentu):

1. Apa yang telah Anda lakukan sejak Scrum Harian terakhir?
2. Apa yang Anda rencanakan untuk dilakukan hingga Scrum Harian berikutnya?
3. Apa masalah atau hambatan yang Anda temui sejak Scrum Harian terakhir?

Mereka Scrum Mastertidak diwajibkan berada di sana tetapi diharuskan untuk memastikan bahwa Tim bertemu di Scrum Harian dan bahwa Anggota menjawab tiga pertanyaan dengan benar.

Scrum Master bertanggung jawab untuk menghormati Aturan Scrum oleh Anggota Tim Scrum lainnya (Master Scrum, Pemilik Produk, dan Tim).

Pada akhirnya, mengikuti aturan sederhana ini, tim pengembangan Anda akan menjadi gesit. Agility adalah kemampuan untuk mengejar perubahan apa pun secepat Tim dapat, yaitu, pada akhir setiap Sprint, di mana ia dapat mengetahui perubahan yang dibawa oleh Pemilik Produk ke Product Backlog. Dalam hal total bencana dan perubahan orientasi sepenuhnya, kerugian maksimum yang harus diserap oleh perusahaan adalah satu bulan pengembangan, yang cukup dapat diabaikan, mengingat bahwa hanya ada sekitar 20 hari kerja dalam sebulan.

Jika Anda memerlukan informasi terperinci lebih lanjut tentang Scrum dan Pengembangan Perangkat Lunak Agile, silakan merujuk ke Scrum.org dan Panduan Scrum mereka .

Ya, itu jawaban yang cukup! Saya berharap ini setidaknya akan membantu Anda melalui manajemen proyek Anda.

EDIT # 1

Sementara Anda berencana untuk melakukan tiga atau empat fase, seperti yang Anda sebut, kemungkinan besar Tim Anda akan kehilangan fokus dari sudut pandang objektif utama. Jika Anda mendemonstrasikan hanya setelah kuartal pertama apa yang telah dilakukan oleh Tim Anda, mungkin ada beberapa perubahan penting untuk dilakukan yang akan memerlukan pendesainan ulang dan pemikiran ulang pada arsitektur perangkat lunak Anda, melanjutkannya mungkin lebih dari 20 hari kerja yang hilang. Prinsip kelincahan adalah mampu mengejar ketinggalan dengan perubahan segera setelah terjadi, atau secepat mungkin dalam jumlah waktu yang masuk akal, yaitu, untuk Scrum, kotak waktu Sprint.

1. Saya pikir Anda harus memiliki banyak peluncuran yang Anda bisa. Satu-satunya umpan balik / metrik nyata untuk kemajuan dalam pengembangan perangkat lunak adalah kode yang digunakan dalam produksi. Jadi, apa pun proses yang Anda gunakan, semakin sering Anda menyebarkan langsung, semakin gesit yang Anda dapatkan. Yaitu, Anda mendapatkan umpan balik nyata dari pengguna nyata sebelumnya, dan dapat beradaptasi lebih awal.

2. Meskipun Anda tidak boleh melakukan Big Design Up Front , saya pikir ada baiknya untuk memikirkan gambaran besar setiap kali Anda akan menyesuaikan dan mengisi backlog, baik untuk Scrum (untuk sprint berikutnya) dan Kanban / aliran (ketika ada ruang dalam batas WIP). Jika Anda mempertimbangkan keseluruhan (produk, layanan, dll), lebih mudah untuk mempertimbangkan item pekerjaan apa yang akan memberi Anda nilai lebih selanjutnya.

3. Sadarilah bahwa gambaran besarnya berubah. Seringkali Anda mempertimbangkan jaminan simpanan, menyesuaikan prioritas, dll., Juga mempertimbangkan perubahan pada gambaran besarnya. Banyak hal berubah dari waktu ke waktu, termasuk kebutuhan pelanggan tertentu dan bahkan seluruh pasar. Gambaran besar Anda harus mencerminkan hal ini sehingga prioritas Anda dapat diselaraskan dengan kenyataan setiap kali Anda mengisi simpanan, dan tidak hanya di awal ketika Anda membuat rencana.

Singkatnya, saya pikir Anda semakin gesit semakin Anda memeriksa dan beradaptasi.

Perencanaan gambar besar tidak memakan waktu lama, dan penting bagi proyek-proyek besar untuk memiliki gambaran besar dalam pikiran ketika Anda mendefinisikan sprint Anda, jika tidak, pintasan yang diambil dalam sprint dapat menimbulkan masalah di kemudian hari.

Anda harus:

1. Miliki rencana induk (lebih disukai tanpa tenggat waktu terlampir), yang akan berkembang seiring berjalannya waktu.

2. Ketika Anda mendefinisikan sprint, Anda memastikan sprint konsisten dengan gambaran besar. Ini tidak selalu berarti Anda mengubah ide Anda tentang apa yang diinginkan untuk sprint. Terkadang Anda akan menemukan, ketika mendefinisikan sprint, bahwa gambar besar Anda harus disesuaikan. Salah satu cara rencana gambar besar dan sprint harus konsisten satu sama lain dalam sprint.

3. Rencana induk harus disesuaikan saat Anda pergi. Anda akan belajar banyak hal saat bekerja. Peluang baru akan muncul, titik-titik konflik dalam rencana akan muncul. Anda dapat menyesuaikan rencana induk dengan cepat, sambil melanjutkan. Tetapi hampir selalu Anda harus mengunjungi kembali di antara sprint - untuk memasukkan pelajaran dari sprint terakhir, dan untuk memastikan sprint berikutnya selaras dengan gambaran besar.

Saya pikir yang terbaik jika jaminan simpanan dan rencana proyek besar adalah struktur yang terpisah. Pemilik proyek besar menyimpan rencana induk dalam format garis hierarkis untuk mempertahankan konteks, dan kemudian fitur / tugas dapat ditarik darinya untuk memberi makan backlog, yang pada gilirannya akan memberi makan sprint berikutnya.

Tumpukan, tidak seperti rencana induk, dapat ditambahkan oleh anggota tim lainnya. Terserah pemilik proyek utama untuk memastikan item backlog dan rencana gambar besar tetap selaras - kadang-kadang menyesuaikan item backlog, dan kadang-kadang rencana gambar besar.

Metode ini mempertahankan kekuatan gesit, dan kekuatan menyelaraskan semua elemen proyek Anda sebaik mungkin pada waktu tertentu melalui perencanaan gambaran besar.

Jim

Saya akan menambahkan bentuk singkat kata-kata kasar anti-Agile saya di sini.

Agile bisa sangat merusak untuk proyek-proyek besar, terutama ketika membangun perpustakaan dan kerangka kerja yang akan menjadi dasar untuk pengembangan di masa depan. Perhatian yang sangat penting dalam fase awal adalah "akankah desain saya mendukung fitur yang perlu kami sampaikan di tahun berikutnya?". Kebanyakan strategi Agile tidak memungkinkan untuk pemikiran ke depan semacam itu, dan dengan demikian poin kegagalan proyek dibuat.

Saya agak sakit pada titik ini karena saya sendiri dibakar oleh ini. Kami sedang menulis ulang beberapa perpustakaan inti kami. Fase pertama dilakukan dan memenuhi tujuan fitur untuk sprint mereka. Itu semua sangat lincah. Kemudian, saya dibawa ke kapal untuk menambahkan beberapa fitur pemuatan dinamis. Namun, saya terhenti selama sekitar enam minggu karena apa yang ditulis sebelumnya diasumsikan tidak akan pernah ada pemuatan dinamis, saya membuang banyak waktu menulis ulang dan mengerjakan apa yang sudah ada di sana. Bagian terburuknya adalah, pemuatan dinamis dalam spesifikasi di awal; seandainya pekerjaan awal mengingat semua persyaratan di masa depan dan melakukan 'pekerjaan desain besar di muka' yang dianggap praktik buruk, saya bisa menerapkan fitur saya dalam beberapa hari.

Pelajarannya adalah, gunakan gesit untuk hal-hal kecil yang bersedia Anda buang. Terkadang itu bisa menjadi luar biasa. Namun, ini bukan Cara Pengembangan Perangkat Lunak Sejati. Saat menulis kode dasar yang berisiko tinggi atau akan memiliki umur panjang, lakukan desain besar.