Pengantar Utama Untuk Manajemen Proyek Agile

Singkat

Anda bertanggung jawab untuk memberikan inisiatif terbaru dan terbesar perusahaan Anda yang akan mengubah wajah "Widget Internasional" selamanya. Ini adalah proyek perangkat lunak yang akan melibatkan dan memikat pelanggan Anda, membuat hidup rekan kerja Anda lebih mudah, dan menghasilkan jutaan pendapatan bagi perusahaan. Ada banyak antisipasi, semangat, kegembiraan, dan harapan. Anda harus menyelesaikannya secepat mungkin agar bisnis Anda dapat mulai menuai keuntungan. Keberhasilan masa depan perusahaan tergantung pada Anda. Semua mata tertuju padamu. Anda tidak bisa gagal.

Pada awalnya, Anda berpikir pada diri sendiri, “Luar biasa, saya siap menghadapi tantangan. Ayo selesaikan urusan ini!” Anda berhenti sejenak, mundur, dan berpikir dalam hati, “Oke, jadi bagaimana kita melakukan ini?” Anda mulai berbicara dengan kolega dan rekan kerja Anda. Anda menghabiskan waktu mencari praktik terbaik pengembangan perangkat lunak dan teknik manajemen proyek, tetapi pilihan dan pendekatannya tidak terhitung banyaknya. Ada banyak akronim dan metodologi. Yang terkenal naik ke atas. Keraguan merayap masuk. Yang mana yang harus kita gunakan? Bagaimana saya bisa menjamin kesuksesan? Bagaimana jika saya membuat keputusan yang salah?

Dalam hal mengelola proyek perangkat lunak, ada banyak pilihan yang didukung oleh banyak sekali pendapat. Suara-suara dari sudut ruangan berbisik, “Coba lakukan dengan cara ini”; yang lain berteriak, “Ini adalah satu-satunya cara untuk melakukannya”; dan sisanya hanya merengek, “Jangan diatur sama sekali, lanjutkan saja.” Pada kenyataannya, semua suara itu berbicara beberapa kebenaran. Tetapi yang penting adalah mencari tahu apa yang tepat untuk kebutuhan Anda, tim Anda, bisnis Anda, dan pelanggan Anda.

Mengatur Adegan

Ada suatu masa ketika manajemen proyek perangkat lunak duduk tepat di salah satu dari tiga kubu. Ada kerangka kerja berat yang memungkinkan Anda membuat keputusan tentang bagaimana Anda mengeksekusi dan menyampaikan sambil menawarkan struktur untuk mempertahankan kontrol dan tata kelola. Ada metodologi sekuensial preskriptif seperti air terjun yang memaksa Anda untuk merencanakan proyek yang panjang, memahami dan berkomitmen untuk semua persyaratan Anda, merancang dan menandatangani sistem yang kompleks, menulis banyak kode, dan kemudian menguji (semua sebelum pelanggan Anda dapat melihatnya untuk yang pertama waktu). Dan akhirnya, siklus hidup pengembangan perangkat lunak (SDLC) yang kurang preskriptif tetapi berulang yang mendorong pembuatan prototipe cepat atau sistem yang lebih besar untuk dirancang, dibangun, dan disampaikan dalam langkah-langkah tambahan, masing-masing membangun di atas yang lain.

Pengembangan perangkat lunak Agile dan manajemen proyek Agile lahir dari kekurangan air terjun dan manfaat dari pendekatan berulang untuk pengiriman perangkat lunak. Mereka dapat melacak akar mereka ke tahun 1950-an, kepemimpinan pemikiran di tahun 70-an, kedewasaan di tahun 90-an, dan adopsi hingga tahun 00-an. Pada tahun 2001, sekelompok praktisi dan pakar menciptakan Agile Manifesto, yang bertujuan untuk mendefinisikan 4 nilai dan 12 prinsip panduan yang berupaya mewujudkan semangat pengembangan perangkat lunak Agile dan untuk mendorong evolusinya. Dan itu pasti telah berkembang.

Sekarang, hanya memanggil sesuatu Agile tidak terlalu membantu. Kata tersebut, bahkan dalam konteks perangkat lunak, memiliki arti yang berbeda bagi orang atau organisasi yang berbeda. Ada banyak segi, definisi, implementasi, dan interpretasi. Setiap tubuh yang menganut Agile cenderung mencoba memberikan definisinya sendiri.

Cukuplah untuk mengatakan bahwa pengembangan perangkat lunak Agile dan manajemen proyek adalah sekelompok perilaku, kerangka kerja, teknik, dan konsep terkait yang pada dasarnya mendukung pengiriman perangkat lunak yang berfungsi dengan benar sedini dan sesering mungkin secara realistis.

Saya sebutkan sebelumnya bahwa Agile, seperti yang diterapkan pada pengembangan perangkat lunak atau manajemen proyek, dapat menjadi hal yang berbeda. Singkatnya, pengembangan perangkat lunak Agile menangani pengembangan perangkat lunak hebat dalam konteks bisnis seperti biasa (BAU) atau proyek. Manajemen proyek tangkas, di sisi lain, menangani tata kelola dan kontrol yang diperlukan untuk memberikan proyek yang kompleks termasuk tetapi tidak terbatas pada perangkat lunak.

Ada banyak metode pengembangan perangkat lunak Agile yang tersedia, seperti Scrum, Kanban, XP, dan Lean Software Development. Tapi sama seperti permainan rugby lebih dari sekadar scrum, begitu pula Agile. Secara terpisah, paradigma Agile ini tidak membahas siklus hidup penuh manajemen proyek yang diperlukan dalam proyek kompleks seperti tata kelola, sumber daya, keuangan, manajemen risiko eksplisit, dan banyak konsep manajemen proyek penting lainnya. Untuk ini, Anda mungkin ingin mempertimbangkan PMI Agile atau PRINCE2 Agile—anggap saja sebagai “Governed Agility.”

Mengapa Kita Perlu Agile?

Dahulu kala, kami menjelajahi tanah untuk mengumpulkan makanan dan tempat berteduh untuk bertahan hidup. Mereka adalah kebutuhan sederhana, tetapi cukup gesit. Beberapa waktu kemudian, negara dan ekonomi tumbuh dan makmur di belakang Revolusi Industri. Ini adalah kelahiran manajemen dan kontrol dan hilangnya kelincahan. Sekarang kita berada di Era Informasi atau Revolusi, di mana bisnis mempekerjakan pekerja berpengetahuan. Pekerja pengetahuan adalah Anda, mitra Anda, dan kolega serta rekan kerja Anda, yang berusaha keras untuk menciptakan solusi hebat bagi masalah pelanggan, bisnis, sosial, ekonomi, dan dunia. Pekerja pengetahuan menerapkan analisis, pengetahuan, penalaran, pemahaman, keahlian, dan keterampilan untuk kebutuhan yang sering didefinisikan secara longgar dan berubah. Bisnis dan pekerja ini membutuhkan metode dan teknik yang tidak dapat dipenuhi oleh proses dan prosedur Zaman Industri lama. Agile mendukung interaksi.

Hampir tidak ada proyek perangkat lunak yang dapat dengan percaya diri dimulai di awal dan mengetahui semua yang dibutuhkan untuk memberikan perangkat lunak yang berfungsi tanpa perubahan. Perubahan menghadirkan peluang dan risiko bagi keberhasilan suatu proyek. Peluang yang tidak dikelola dapat berarti perbedaan antara perusahaan yang hebat dan perusahaan yang luar biasa. Risiko yang tidak dikelola berarti bencana dan kehancuran. Agile mengelola perubahan.

Mengadopsi Agile memungkinkan Anda untuk responsif terhadap perubahan atau persyaratan baru. Ini memberdayakan tim pengembangan untuk menjadi ahli dan membuat keputusan yang didukung oleh bisnis yang terlibat, percaya, dan terinformasi. Ini memungkinkan Anda untuk memberikan kepada pelanggan apa yang benar-benar mereka inginkan. Pada akhirnya, ini membuat Anda dan organisasi Anda memegang kendali dalam memberikan perangkat lunak berkualitas tinggi dan berharga yang memenuhi kebutuhan dan harapan pelanggan sambil mengekstraksi pengembalian uang investasi Anda sedini mungkin. Agile menciptakan nilai.

Ada biaya untuk mengadopsi Agile. Itu tidak datang secara gratis. Mengubah ke pendekatan Agile untuk pengiriman perangkat lunak bisa menjadi jalan yang sulit untuk diikuti. Namun, jika Anda menginternalisasi filosofi Agile, melangkah dengan hati-hati, melibatkan tim yang tepat dengan sikap yang benar, memecah segalanya, membuatnya dapat dicapai dan realistis, dan menanggapi umpan balik, Anda akan menuai imbalan. Agile menekankan kolaborasi.

Berikut daftar beberapa manfaat yang dapat Anda harapkan:

• Kecepatan ke pasar
• Generasi pendapatan sebelumnya
• Pengiriman reguler dari nilai nyata
• Perlindungan untuk investasi Anda
• Data, data, data
• Kualitas produk yang lebih baik
• Harapan yang dapat dikelola
• Kepuasan pelanggan yang lebih besar
• Tim berkinerja lebih tinggi
• Peningkatan visibilitas pada kemajuan
• Prediktabilitas, transparansi, dan kepercayaan diri
• Risiko yang dapat dikelola

Sukses bukanlah final, kegagalan bukanlah hal yang fatal: keberanian untuk melanjutkan yang diperhitungkan.

Winston Churchill mungkin tidak pernah benar-benar mengatakan ini, tapi saya pikir ini adalah ringkasan yang cukup bagus dari Agile. Kami tahu Agile adalah langkah maju terbaik untuk sebagian besar proyek. Ini mendorong Anda untuk berusaha keras untuk sukses, tetapi kami selalu mengulangi dan terus membangunnya. Agile akan mendorong Anda untuk gagal, tetapi gagal lebih awal dan terus maju. Keberanian untuk melanjutkan dan membangun solusi yang tepat berdasarkan wawasan yang diinformasikan oleh pelanggan Anda adalah hal yang membawa imbalan.

Hal yang perlu diingat adalah Anda dapat menyesuaikan Agile dengan kebutuhan Anda. Gunakan metode dan tata kelola yang tepat untuk bisnis Anda. Di mana pun Anda memulai, jujurlah pada konten, konteks, dan semangat metode yang Anda gunakan—tetaplah vanila. Jika Anda baru memulai, belajarlah . Jika Anda sudah melakukannya untuk sementara waktu, mengerti . Jika Anda menjadi luar biasa, terapkan . Terakhir, jika bisnis dan proyek Anda kompleks dan saling bergantung, atur . Seiring waktu, Anda dan tim Anda akan mencari tahu apa yang terbaik untuk bisnis Anda.

Kelayakan

Jadi sekarang Anda berpikir, “Oke, saya mengerti. Bagaimana cara memulai? Di mana saya memulai?" Nah, dengan semua hal baik, kita mulai dari awal. Dan dengan Agile, itu dengan bertanya pada diri sendiri “Nilai bisnis apa yang ingin saya berikan?” Bagaimanapun, itu sebabnya kami melakukan proyek, untuk menghasilkan nilai bisnis. Untuk menentukan apakah proyek tersebut layak dilakukan untuk mendapatkan nilai bisnis, Anda perlu memahami apakah itu layak.

Penglihatan

Apakah proyek Anda diproyeksikan untuk meningkatkan pendapatan, memasuki pasar baru, memperoleh lebih banyak pelanggan, meningkatkan persepsi pelanggan, atau membuat hidup lebih mudah untuk masalah tertentu yang telah Anda identifikasi? Dengan mengingat hal ini, Anda dapat menyatakan "visi" Anda.

• Visi Anda mungkin berasal dari sumber yang berbeda—startup berani Anda sendiri untuk memperbaiki masalah umum, strategi manajemen bisnis, proyek kesayangan CEO Anda, tim produk tertentu, atau bahkan kebutuhan pelanggan Anda.
• Cobalah untuk mundur selangkah dari sepatu Anda sendiri dan "lihat" seperti apa masa depan dengan produk atau layanan baru Anda di tangan pelanggan Anda.
• Libatkan pemangku kepentingan Anda—CEO, staf produk, dan pelanggan. Lokakarya itu, jangan coba ini secara terpisah. Tantang asumsi dan validasi argumen.
• Tulislah, singkat saja. Fokus pada nilai bisnis.
• Perbaiki sampai Anda semua setuju bahwa visi itu beresonansi dengan semua orang dan memenuhi interpretasi umum yang menyatakan ke mana Anda menuju.
• Visi Anda, jika valid, jarang berubah. Bagaimana Anda sampai di sana pasti akan.

Orang tidak membeli apa yang Anda lakukan, atau bagaimana Anda melakukannya. Mereka membeli "mengapa" Anda melakukannya. Inilah yang menciptakan hubungan emosional antara bisnis Anda dan pelanggan Anda. Visi akan membantu menggambarkan hal ini.

Apakah Layak?

Kelayakan datang setidaknya dalam beberapa warna. Biasanya, Anda ingin memahami apakah visi Anda tentang masa depan yang lebih cerah untuk bisnis dan pelanggan Anda layak secara teknis dan layak bagi bisnis Anda untuk mewujudkannya.

• Jika visi Anda adalah melakukan perjalanan ke mana saja di seluruh dunia dalam waktu kurang dari satu jam, Anda mungkin memiliki masalah dengan kelayakan teknis. Karena sains, fisika, dan teknologi belum sepenuhnya mengejar mimpi itu, solusi teknis Anda mungkin tidak dapat dijalankan selain teori. Selain itu, jika solusi Anda baru, ini akan melampaui gagasan produk yang layak minimum (MVP).

• Untuk menguji kelayakan teknis produk Anda, pertimbangkan untuk menjelajahinya lebih lanjut dalam proyek prototipe Discovery atau dengan menjalankan lonjakan pada tahap awal proyek. Anda akan mengetahui metode mana yang akan digunakan dengan memikirkan skala atau kompleksitas solusi yang Anda pikirkan.

  “Beberapa pengetahuan terbaik yang diperoleh tim saya dalam memahami kelayakan teknis berasal dari melakukan lonjakan. Dan seringkali, itu adalah solusi paling sederhana yang menang!”

• Bayangan kelayakan kedua yang perlu dipertimbangkan adalah apakah Anda, tim Anda, atau bisnis Anda memiliki keterampilan dan motivasi untuk membuatnya berhasil. Menggunakan contoh, jika Anda hebat membuat kue di rumah untuk ulang tahun anak-anak Anda, itu manis. Tetapi jika Anda ingin mengubahnya menjadi bisnis yang menjual kue terbaik ke dunia, Anda perlu memahami apakah Anda dapat membuatnya berkembang, menangani bisnis serta produksi, mengelola distribusi dan pemenuhan, dan menjaga layanan pelanggan.
• Jenis visi ini mungkin dapat dicapai dalam jangka panjang. Tapi untuk saat ini, mungkin tidak. Jadi skala kembali, berpikir kecil, ambil potongan kecil yang terlihat realistis dan berkonsentrasi untuk memberikan aspirasi kecil terbaik yang Anda bisa. Jika itu berhasil melibatkan dan menyenangkan pelanggan Anda, buat mereka datang kembali untuk lebih banyak dan memberi tahu teman-teman mereka, kemudian tingkatkan dari sana menggunakan umpan balik pelanggan Anda sebagai panduan dan kompas Anda.
• Juga, Anda perlu tahu apakah proyek Anda layak dari segi anggaran dan jangka waktu. Apakah bisnis Anda mampu memberikan proyek ini? Apakah jangka waktunya dapat dicapai? Waktu dan uang adalah dua dari tiga kendala dalam proyek Agile yang diperbaiki. Kami bertujuan untuk memberikan dalam waktu tetap tertentu dan dalam anggaran tetap yang diberikan.
• Kualitas produk mengacu pada produk akhir yang digunakan pelanggan Anda dan praktik teknik yang digunakan tim Anda untuk menghadirkan perangkat lunak yang hebat, kuat, dan andal. Kualitas juga sesuatu yang tidak bisa kita ubah. Kriteria kualitas, di sisi lain, dapat berubah. Jika Anda tidak berencana untuk membuat Ferrari, produk tersebut mungkin tidak memiliki persepsi kualitas yang tinggi. Jika Anda tidak membuat roket luar angkasa, toleransi yang dicapai dalam hal produksi mungkin jauh lebih tinggi. Tetapkan nada dan harapan yang sesuai sejak dini.

Jadi sekarang Anda telah memastikan bahwa impian Anda lebih dari sekadar kemewahan cokelat, mulailah menguji asumsi Anda dan buktikan kepada orang-orang bahwa usaha ini layak untuk diinvestasikan.

Pembenaran

Sekarang, tergantung pada keadaan Anda, pembenaran akan datang dalam bentuk yang berbeda. Tetapi pada dasarnya, Anda ingin membuktikan bahwa proyek ini akan memenuhi kriteria keberhasilan pelanggan, memiliki peluang sukses, akan memberikan nilai, dan terjangkau.

• Nyatakan asumsi Anda berdasarkan kebutuhan pelanggan Anda, lalu validasikan. Lean Startup memberikan panduan hebat untuk mengidentifikasi dan membuktikan bahwa produk Anda dibutuhkan oleh pelanggan Anda dan akan menciptakan nilai.

• Tulis, uji, dan validasi rencana bisnis Anda. Sekarang ini tidak terlihat seperti yang bank Anda atau jurusan bisnis dan keuangan Anda suruh Anda produksi. Jangan gunakan—itu akan kedaluwarsa sebelum tinta mengering. Sebagai gantinya, lihat Kanvas Model Bisnis. Ini pada dasarnya adalah rencana bisnis jangka pendek yang menjaga fokus Anda pada proposisi nilai Anda, pelanggan Anda, pendapatan, dan biaya. Gunakan untuk memvalidasi jika Anda memiliki bisnis yang akan bekerja.

  “Saya mengabaikan nasihat ini sekali dan menghabiskan waktu lama untuk menulis rencana bisnis tradisional sepanjang 50 halaman. Itu tidak membawaku kemana-mana. Semua asumsi yang saya buat tidak berdasar, dan semua proyeksi yang saya buat tidak dapat divalidasi. Itu adalah pengalaman yang menyakitkan dan mahal yang mengajari saya untuk tidak pernah melakukannya lagi.”

• Jika Anda berada dalam bisnis yang matang dengan portofolio proyek yang disampaikan dalam lingkungan yang kompleks, maka pemodelan keuangan mungkin diperlukan. Jika harus, lakukan ini hanya setelah Anda membuktikan hal di atas.
• Setelah Anda membangun MVP, mungkin ada kasus untuk membuat rencana bisnis yang lebih tradisional—misalnya, jika Anda harus mencari pendanaan atau seleksi dalam portofolio proyek dan sumber daya yang bersaing di perusahaan Anda. Tapi ini akan menjadi rencana bisnis berdasarkan dan diinformasikan oleh alat yang digunakan di atas. Ini juga akan lebih ringan.
• Bagaimanapun, gunakan alat-alat ini sebagai artefak yang hidup dan bernafas. Gunakan mereka sebagai panduan dan pemimpin Anda. Mereka tidak pernah statis. Lihat mereka dan revisi mereka saat proyek atau bisnis Anda berkembang.

Setelah Anda memiliki pembenaran dan semua pemangku kepentingan Anda setuju, Anda akan bersemangat.

Fase kelayakan biasanya dilakukan sekali dalam kehidupan proyek Anda. Anda mungkin menemukan Anda meninjau kembali visi dan kelayakan proyek, terutama jika data, pelanggan, pasar, atau bisnis Anda menunjukkan demikian. Paling tidak, mereka akan menjadi lampu penuntun Anda selama ini.

Inisiasi

Luar biasa. Keputusan telah dibuat, proyek memiliki lampu hijau dan Anda siap untuk membangun. Yah, hampir. Saya tahu Anda berpikir, “Ayo, benarkah? Jika kita tidak melakukan ini sekarang, kita tidak akan pernah melakukannya. Mari kita tampilkan pertunjukan ini di jalan!” Tapi pertimbangkan ini—Agile bukan apa-apa jika bukan tentang memberikan nilai lebih awal dan sering sambil menyenangkan pelanggan Anda di sepanjang jalan. Meluangkan waktu untuk mencari tahu cara terbaik untuk menyampaikan proyek Anda adalah landasan terbaik untuk sukses.

Tim

Dalam olahraga, dengan memikirkan permainan tim favorit Anda, Anda akan dapat mengenali peran kunci yang memungkinkan tim tampil seperti yang mereka lakukan. Secara tradisional, Anda akan menemukan manajer, kapten, dan anggota tim lainnya. Di luar itu, Anda akan menemukan pelatih, fisioterapis, ahli gizi, dan berbagai staf pendukung. Tetapi jika kita melihat permainan rugby, ada tim di dalam tim: para pemain yang membentuk scrum. Paket ini terdiri dari pemain yang ditunjuk yang tugasnya adalah memenangkan bola kembali dan melanjutkan permainan. Ketika scrum dimainkan, para pemain dari masing-masing sisi kemudian bekerja, tanpa pemimpin, sebagai satu kesatuan yang kolaboratif, komunikatif, dan seefisien mungkin untuk mendapatkan bola kembali dalam penguasaan. Ini adalah permainan rugby yang menginspirasi Jeff Sutherland untuk menamai metodologi pengembangan perangkat lunaknya "Scrum."

• Scrum bukan satu-satunya metode pengembangan perangkat lunak dalam buku pedoman Agile. Tapi itu adalah salah satu yang paling menggambarkan konsep Agile dan perilaku bekerja sebagai tim, memotivasi individu, menciptakan hubungan saling percaya, pengorganisasian diri, kepemimpinan yang melayani, komunikasi, transparansi, dan kolaborasi.
• Tim Anda akan dibentuk sebagian besar oleh keadaan yang Anda hadapi. Anda mungkin memiliki pengembang yang tersedia untuk Anda. Beberapa, tidak ada, atau semuanya mungkin akrab dengan Agile hingga tingkat yang berbeda-beda. Anda mungkin ingin menyewa tim baru atau bermitra dengan pihak ketiga.
• Peran lain akan diperlukan juga, tetapi kita akan membahasnya nanti.
• Dikatakan bahwa jika Anda membentuk tim pengembangan Anda, maka Anda telah memilih teknologi Anda. Bergantung dari mana Anda menyatukan tim, mereka akan datang dengan keahlian khusus. Jadi, pikirkan baik-baik bagaimana Anda membentuk tim pengembangan Anda dan apakah Anda perlu melakukan evaluasi teknis sebelum Anda mencapai titik ini dalam perjalanan Anda.
• Ini membawa kita ke tim lintas fungsi. Tim bekerja paling baik ketika mereka bekerja sama, ketika individu bekerja sama untuk menyelesaikan pekerjaan terlepas dari gelar mereka. Cobalah untuk membangun tim yang mandiri dan individu yang mengambil lebih dari satu peran.
• Bangun lingkungan, budaya, dan pusat hubungan—tempat di mana tim dapat menyampaikan, tidak terbebani oleh kendala atau batasan. Berikan tim alat, orang, sumber daya, dan ruang untuk menjadi efektif dan berkinerja.
• Pertahankan ukuran tim tidak lebih dari tujuh atau delapan. Jika Anda membutuhkan lebih banyak pengembang, bagi tim menjadi beberapa tim baru. Setiap tim kemudian mungkin bertanggung jawab untuk area fungsional tertentu. Jika Anda memiliki banyak tim di beberapa lokasi, pertimbangkan untuk mengadakan Scrum of Scrums. Dan di mana ini banyak di lingkungan yang kompleks, gunakan manajemen proyek Agile.
• Pastikan bahwa tim, bisnis, pemangku kepentingan, dan bahkan pelanggan memiliki akses satu sama lain. Pastikan mereka berkomunikasi dan berkolaborasi, dan singkirkan apa pun yang menghalangi kemajuan. Komunikasi harian adalah obat terbaik untuk penyakit proyek. Ketika orang berbicara, mereka menyelesaikan sesuatu.

Ada banyak cara sebuah tim dapat disatukan untuk memberikan perangkat lunak.

Proyek Singkat

Pada langkah kelayakan, Anda menemukan "mengapa" proyek Anda dan membangun kepercayaan diri Anda untuk terus maju dengan startup Anda atau mendapat dukungan untuk melanjutkan. Proyek singkat adalah dokumen hidup yang menyatukan "mengapa" dengan "apa" dan "kapan" dan "siapa." Ini "hidup" karena, seiring kemajuan Anda, pengetahuan, pemahaman, dan jalan Anda dapat berubah. Untuk meninggalkan dokumen ini setelah ditulis dan tidak pernah kembali ke sana hanya menyerahkan pikiran Anda ke titik waktu. Di dunia Agile, referensi titik waktu Anda dapat berubah setiap minggu atau bahkan setiap hari sejak awal, jadi penting untuk tetap memperbaruinya.

• Alat hebat untuk merangkum dan mempertahankan ringkasan proyek Anda adalah sesuatu yang oleh Jonathan Rasmusson disebut sebagai "dek awal" dalam bukunya The Agile Samurai . Di sini, Anda akan menemukan saran bagus untuk memastikan bahwa semua orang yang tertarik, terpengaruh, atau terlibat dengan proyek Anda berada di halaman yang sama.
• Musuh terbesar untuk memberikan proyek adalah memiliki pemahaman yang tidak jelas, tidak konsisten, atau hanya berbeda tentang apa proyek itu dan "persyaratan" apa yang harus dipenuhi. Jika bahkan satu pemangku kepentingan penting memiliki pemahaman atau pandangan yang berbeda tentang apa yang Anda lakukan, konsekuensinya bisa sangat besar.
• Ringkasan proyek yang baik mengomunikasikan:
  1. Harapan bersama dan disepakati antara pemangku kepentingan dan anggota tim.
  2. Pemahaman tentang proyek, dengan pemahaman yang sama di semua pihak.
  3. Tujuan, visi, tujuan, ruang lingkup, dan konteks proyek.
• Anda akan memiliki banyak informasi bagus untuk ringkasan yang dikumpulkan dari kelayakan. Ringkasan proyek akan membantu Anda menentukan dan menemukan jawaban atas pertanyaan pencarian. Ini akan menyatukan pemangku kepentingan, raison d'etre Anda, cakupan tingkat tinggi, risiko, solusi target, anggaran, garis waktu, harapan, dan prioritas.

Seorang rekan pernah menghentikan saya di sebuah koridor dan bertanya di mana dia bisa mendapatkan ringkasan proyek untuk proyek tersebut. Saya menyindir 'Kami tidak perlu brief, kami Agile'. Dia tampak bingung, seolah-olah dia mempertanyakan kewarasan atau otoritasku. Dia benar untuk melakukannya.

Sebelum Anda melanjutkan, pastikan Anda memiliki semua orang di halaman yang sama, kerjakan, ajukan pertanyaan sulit, dan paku di suatu tempat di mana orang dapat berhenti, membacanya, mengomentarinya, dan membantu merevisinya.

Budaya dan Cara Kerja

Anda tahu cara bisnis Anda bekerja dan budayanya, cara mereka menyelesaikan pekerjaan. Agile, pada dasarnya, mungkin menantang beberapa cara kerja yang telah dikembangkan bisnis Anda selama bertahun-tahun. Jangan berharap Agile diimplementasikan dan semua orang dengan penuh kasih mengadopsinya sejak awal. Beberapa orang mungkin merasa bingung dan melihatnya hanya dengan rasa takut dan takut. Beberapa orang mungkin secara terbuka menolak untuk terlibat di dalamnya. Ini adalah tantangan dan persepsi yang harus Anda atasi. Tetapi di hari-hari awal Anda, jangan berkeliling melambaikan tongkat Agile memukuli siapa pun yang tidak mau mendengarkannya. Itu tidak akan membangun kepercayaan, adopsi, atau keterlibatan.

Saya adalah penggemar melambaikan tongkat pepatah besar sekali, dan itu memberi saya banyak pers negatif. Saya membalikkannya, tetapi tidak sebelum menderita rasa sakit yang cukup besar terlebih dahulu.

Saat Anda memulai jalan adopsi Anda, melangkahlah dengan hati-hati, penuh hormat, dan dengan empati. Jika Anda berada dalam bisnis tradisional lama yang berderit, mungkin itu bukan pendekatan terbaik untuk menyelaraskan seluruh bisnis. Mulailah dari yang kecil dan secara bertahap dapatkan rasa hormat dan pengakuan. Mulailah dengan tim Anda saja. Setelah Anda mulai memberikan perangkat lunak yang lebih cepat dengan kualitas yang lebih baik dari sebelumnya, orang-orang akan mulai memperhatikan dan ingin datang memainkan permainan Anda. Ketika mereka melakukannya, tawarkan mereka bola, bawa mereka keluar untuk minum kopi, dan bawa mereka ke dunia baru Anda. Bantu mereka.

Dengan tim Anda, sekarang setelah mereka mengetahui tentang proyek tersebut dan rencana Anda untuk adopsi Agile telah disetujui, biarkan tim memutuskan bagaimana mereka ingin berperilaku dan beroperasi sebagai sebuah tim.

• Pandu tim Anda untuk mengidentifikasi konsep, teknik, perilaku, dan kerangka kerja Agile yang menurut Anda sesuai dengan kebutuhan kolektif Anda.
• Terima permintaan dari anggota tim Anda tentang persyaratan apa yang mereka miliki untuk membantu mereka bekerja sebaik mungkin. Beberapa dari permintaan ini, Anda dapat segera menyelesaikannya. Lainnya, Anda mungkin perlu mendapatkan anggaran atau bantuan dari luar. Lakukan apa yang Anda bisa untuk mewujudkannya.
• Ini adalah langkah pertama Anda untuk menjadi pemimpin-pelayan sejati.
• Pertimbangkan untuk mengatur beberapa pelatihan yang sesuai dalam konsep dan teknik yang dipilih oleh tim Anda untuk diadopsi. Ini adalah cara terbaik untuk memastikan semua anggota tim Anda, bahkan pemangku kepentingan, berada di halaman yang sama dan mendapatkan pesan yang sama. Bekerja dengan organisasi pemasok yang dapat menyesuaikan penawaran mereka dengan kebutuhan Anda.
• Berhati-hatilah. Tidak ada yang akan menjadi ninja Agile setelah beberapa hari di bengkel belajar bagaimana menjadi Agile. Jalanmu akan panjang. Kata "menjadi" cukup menentukan. Hanya ketika Anda benar-benar merangkul Agile, Anda akan melihat nilainya. Itu harus menggairahkan Anda. Jika itu menggairahkan Anda, maka pergilah menggairahkan orang lain juga.
• Sekarang tim Anda telah menyetujui konsep dan teknik, keinginan mereka terpenuhi, dan berada dalam pelatihan Agile, alihkan perhatian tim Anda ke diri mereka sendiri dan apa yang mereka harapkan dari Anda, bisnis, dan satu sama lain.
• Tentukan beberapa cara kerja (WoW) di dalam dan oleh tim membantu membangun kepercayaan, hubungan, dan harapan. WoW bukanlah Perang dan Damai . Itu harus pendek dan to the point, antara tujuh dan sepuluh kalimat runcing. Kalimat-kalimat ini menyatakan dengan jelas bagaimana orang berperilaku, berkomunikasi, berkolaborasi, mendukung, menyampaikan, dan tampil bersama. Itu juga harus menyatakan apa yang diharapkan tim dari bisnis.

• Agile adalah pola pikir seperti halnya membimbing prinsip dan konsep. Ini membantu Anda berkembang dalam cara Anda berperilaku, berpikir, bernegosiasi, berinteraksi, berkomunikasi, melakukan, dan meningkatkan. Itu bergantung pada individu yang termotivasi yang saling mendukung untuk mencapai tujuan bersama, bersama sebagai satu kesatuan. Ada pepatah Afrika:

Sekarang, tim Anda harus sangat bersemangat, bersemangat, dan termotivasi. Sekarang, libatkan mereka lebih jauh dengan tumpukan cerita pengguna Anda.

Jaminan simpanan

Jangan ragu dalam pikiran Anda bahwa ada ketidakpastian yang terlibat dalam proyek Anda. Anda tidak mungkin tahu persis apa yang diperlukan untuk membangun produk yang tepat bagi pelanggan Anda sejak awal. Anda tidak dapat menatap dengan sedih ke dalam bola kristal dan memprediksi masa depan.

“Backlog” atau “Product Backlog” adalah tempat tinggal kebutuhan Anda. Agile menyukai penulisan pernyataan singkat dan padat yang menangkap esensi dari "persyaratan". Backlog hanyalah daftar panjang entri, setiap entri mendefinisikan satu "persyaratan" terpisah sebagai cerita pengguna. Dan mulai sekarang, kita akan menggunakan kata cerita pengguna, dan bukan "persyaratan". Anda mungkin bertanya "mengapa?" Itu pertanyaan yang bagus. Untuk apa yang tampak seperti selamanya, menyatakan fitur atau aspek yang dibutuhkan dalam proyek perangkat lunak oleh pelanggan selalu disebut sebagai persyaratan. Kata itu memiliki interpretasi yang tidak memiliki nilai di Agile. Kamus Oxford mendefinisikannya sebagai:

Sesuatu yang dibutuhkan atau diinginkan. Atau, Suatu hal yang wajib; suatu kondisi yang diperlukan.

Dan sayangnya, jika kita menetapkan apa yang seharusnya menjadi solusi kita, menyatakan bahwa segala sesuatunya “wajib”, kita akan berakhir dalam masalah. Terlalu mudah untuk mengatakan bahwa semua cerita pengguna ini wajib. Jika kami mengambil pandangan itu, kami menghadapi risiko melebihi jadwal dan anggaran dalam upaya untuk memberikan semua cakupan yang diberikan. Tidak masalah untuk mengatakan bahwa, untuk produk ini, cerita-cerita ini diperlukan agar solusi dapat berjalan, kami hanya ingin menghindari interpretasi kata tertentu.

• Selalu menulis cerita dari sudut pandang persona. Persona mewakili pengguna atau pemangku kepentingan dari solusi. Sebaiknya kembangkan persona ini sebelum Anda memulai backlog.
• Pada tahap ini, hanya tulis pernyataan singkat dan sederhana yang pada dasarnya menyarankan pengingat untuk melakukan percakapan yang lebih dalam tentang cerita pengguna ketika waktunya tepat.
• Orang-orang nyata berpikir dalam hal tugas yang harus mereka selesaikan untuk mencapai suatu tujuan. Tulis cerita Anda dari perspektif persona dan dalam hal apa yang harus mereka selesaikan.
• Anda tidak perlu menulis backlog lengkap—cukup tulis sebanyak yang Anda bayangkan akan dibutuhkan pelanggan agar produk Anda dapat bertahan.
• Anda akan menemukan nanti melalui kehidupan produk bahwa cerita pengguna akan berubah, menjadi lebih atau kurang penting, atau dapat dihapus sepenuhnya. Melepaskan sering, mendapatkan umpan balik, dan menilai apa yang menjadi prioritas akan menginformasikan perilaku ini.
• Jangan menulis cerita sendirian. Libatkan tim Anda, pemangku kepentingan, bahkan pelanggan Anda. Cerita dapat diperbarui kapan saja selama proyek berlangsung, tetapi sebaiknya tidak diubah setelah pekerjaan pengembangan dimulai.
• Beberapa cerita Anda mungkin dianggap "epik". Ini adalah cerita besar yang mencakup banyak hal, dan akan dipecah mendekati waktu pengiriman menjadi cerita yang lebih kecil.
• Pertimbangkan untuk menggunakan model INVEST, daftar periksa untuk memvalidasi kualitas cerita pengguna yang baik.
• Siapa saja dapat menambahkan cerita ke backlog. Itu harus ditempatkan di bagian bawah, atau di "tempat parkir" yang dibuat khusus. Cerita tambahan ini berfungsi sebagai petunjuk untuk berdiskusi dengan tim dan bisnis. Jika bisnis dan tim mendukungnya, maka dapat diperkirakan dan diprioritaskan
• Anda juga dapat mempertimbangkan bagian-bagian dari sistem yang paling berisiko. Jika Anda memiliki cerita pengguna atau fitur yang kompleks, baru, atau tidak diketahui secara teknis, prioritaskan ini di bagian atas backlog Anda. Dengan cara ini, Anda tidak akan mencoba memberikan bagian yang menantang dan penting dari produk Anda hanya beberapa minggu sebelum rilis pertama Anda.

Setelah Anda memiliki backlog yang memenuhi kebutuhan Anda, Anda dapat memperkirakan cerita di dalamnya, memberi peringkat berdasarkan prioritas, dan membuat rencana rilis.

Estimasi dan Prioritas Tingkat Tinggi

Estimasi tingkat tinggi adalah proses mengukur backlog Anda. Seberapa "besar" proyek tersebut, dan nilai apa yang dihasilkannya? Prioritas adalah proses memutuskan cerita mana yang paling penting bagi Anda, kelangsungan hidup produk, dan minat pelanggan Anda. Kami ingin mengirimkan barang dengan nilai tertinggi paling awal untuk memberikan nilai tertinggi bagi bisnis, mendapatkan umpan balik dari pelanggan, dan tidak memusingkan hal-hal kecil. Outputnya akan menjadi backlog yang dipesan yang diberi peringkat prioritas dan ukuran yang tepat.

• Cerita di atas dianggap paling berharga. Kami ingin mengirimkan barang paling berharga sedini mungkin.
• Ada banyak teknik untuk mengukur dan memperkirakan, tetapi pada titik ini, Anda hanya ingin mendapatkan gambaran indikatif yang baik tentang ukuran sebuah cerita.
  • Gunakan ukuran kaos, ukuran relatif, hari ideal, atau poin cerita.
• Anda juga tidak akan memiliki semua informasi yang tersedia pada saat ini, dan tidak apa-apa. Jalankan saja dengan itu.
• Libatkan pemangku kepentingan bisnis atau manajer produk Anda jika Anda memilikinya, dan tim yang akan melakukan pekerjaan itu.
• Kami ingin mereka yang akan merancang, mengembangkan, dan menguji pekerjaan untuk mengukurnya, karena orang terbaik untuk memperkirakan adalah para ahli.
• Tim mungkin mulai memecah cerita menjadi bagian-bagian yang lebih kecil. Jika ini terjadi, tulislah cerita yang lebih terperinci tetapi terpisah.
• Tim juga dapat mulai memberi peringkat pada beberapa cerita, karena secara alami beberapa hal harus disampaikan sebelum yang lain untuk mendukung teknologi atau perjalanan pengguna tertentu.
• Antara Anda dan tim, Anda mungkin juga mulai menemukan lubang di backlog yang perlu diisi. Isi saja lubang-lubang itu dengan cerita baru dan perkirakan serta prioritaskan yang sesuai.
• Prioritas paling mudah dilakukan dengan menggunakan analisis MoSCoW. MoSCoW adalah teknik sederhana yang membantu Anda memutuskan cerita mana yang "harus dimiliki" agar produk Anda sukses.
• Anda dapat melakukan penetapan prioritas sebelum estimasi dimulai. Namun, ukuran elemen tertentu juga dapat menentukan keputusan tentang prioritas dan nilai bisnis yang sebenarnya. Jadi mainkan estimasi dan prioritas satu sama lain, tapi jangan bertengkar!
• Tidak ada dua cerita yang bisa sama pentingnya dengan yang lain. Cerita di peringkat 1 lebih penting atau berharga daripada cerita di peringkat 2.
• Cara yang bagus untuk menunjukkan pentingnya atau nilai sebuah cerita adalah dengan menambahkan nilai uang ke dalamnya. Jika misalnya, cerita A dianggap menghasilkan $5000 pendapatan tambahan, dan cerita B mungkin menarik $100, maka cerita A lebih berharga. Demikian pula, jika cerita C menyelamatkan bisnis lebih dari cerita D, cerita C lebih berharga.
• Setelah Anda mengukur backlog Anda, Anda akan ditinggalkan dengan nomor. Ketika kami datang untuk merilis perencanaan, angka itu akan membantu kami memahami seberapa banyak yang dapat disampaikan oleh tim kami dalam jangka waktu tertentu.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Bekerja sedikit demi sedikit memiliki manfaat yang besar. Ini berarti Anda hanya berfokus pada pengiriman yang akan datang dan, dengan masukan, umpan balik, dan pembelajaran baru, Anda dapat merespons perubahan dalam siklus berulang yang singkat.
• Di awal rilis, lakukan sprint 0. Ini memungkinkan tim, bisnis, dan rilis proyek Anda bersiap dan menetapkan pola pikir untuk pengiriman yang sukses. Gambarkan kerangka teknis dan arsitektur dasar yang akan mendukung fondasi untuk rilis. Siapkan lingkungan, akun, dan alat. Lakukan paku untuk memahami masalah yang sulit atau tidak diketahui. Elaborasi cerita pengguna Anda dalam kesiapan untuk sprint 1. Sprint 0 adalah tentang bersiap-siap.
• Selama rilis, terus perbaiki backlog. Saat Anda lebih memahami atau mempelajari sesuatu yang baru, prioritas Anda mungkin berubah, persyaratan baru mungkin terungkap, dan apa yang sebelumnya Anda anggap sebagai fitur hebat mungkin akan dihapus seluruhnya.
• Jangan memulai pekerjaan yang tidak memiliki peluang untuk diselesaikan dalam sprint. Jika tidak bisa, pecah menjadi potongan-potongan kecil. Dan jangan memulai pekerjaan baru ketika pekerjaan yang dimulai sebelumnya belum selesai. Anda tidak menciptakan nilai dengan memulai banyak hal yang tidak dapat dianggap selesai. Selanjutnya, hindari konteks-switching. Ini adalah aktivitas memulai satu tugas, terganggu, memulai yang lain dan, yang paling bermasalah, tidak menyelesaikan keduanya.
• Batasi jumlah pekerjaan yang sedang berlangsung oleh tim pada satu waktu. Misalnya, jika Anda memiliki tiga pengembang dan satu penguji, Anda dapat memberikan batas WIP pada pengembang dan penguji.
• Jangan pernah menambahkan lebih banyak pekerjaan ke sprint setelah direncanakan. Jangan pernah menghentikan sprint di tengah jalan. Pengecualian untuk ini adalah:
  • Jika Anda tampil lebih cepat dari yang diharapkan, pertimbangkan untuk mengambil cerita berikutnya dari bagian atas backlog, selama itu dipersiapkan dengan tepat.
  • Jika sprint berkinerja sangat buruk sehingga tidak akan selesai. Ini biasanya hanya terjadi di mana telah terjadi bencana dari beberapa deskripsi.
  • Jika tujuan sprint tidak dapat lagi didukung karena perubahan kebutuhan bisnis yang segera.
• Jika Anda membatalkan sprint, lakukan dengan anggun, luangkan waktu untuk memfokuskan kembali, dan mulai sprint baru seperti yang Anda lakukan lainnya.
• Menjelang akhir rilis, pertimbangkan sprint rilis final. Tidak ada fitur baru yang ditulis, beberapa bug dapat dibersihkan, dan persiapan dapat dilakukan untuk benar-benar merilis versi baru produk Anda kepada pelanggan. Itu tidak berarti Anda tidak dapat membuat rilis pelanggan tambahan untuk sementara—hanya saja ini adalah mekanisme rilis yang terkontrol, terukur, dan berkelanjutan.
• Di akhir rilis, Anda dapat mempertimbangkan sprint satu minggu. Dalam sprint ini, Anda mungkin bekerja dengan tim untuk memecahkan beberapa ide baru atau menemukan beberapa teknologi baru. Ini adalah alat hebat yang menguntungkan bisnis, dan memberi tim beberapa ruang pengarahan untuk berpikir dan menjadi kreatif. Ini bukan untuk main-main dan masih akan menciptakan nilai. Sama, setiap orang butuh istirahat. Berlibur pada saat ini membantu menjaga irama dan kecepatan Anda dalam kondisi yang baik saat Anda melakukan mid-release.

Mendefinisikan Selesai

Mendefinisikan apa yang "selesai" benar-benar berarti sangat penting. Ada banyak versi "selesai" dalam kehidupan proyek Anda—apa artinya "selesai" dengan sebuah cerita, rilis, atau keseluruhan proyek. Semuanya bermuara pada apa yang Anda, tim Anda, dan bisnis akan anggap lengkap dengan tingkat kualitas yang tepat untuk memenuhi kesiapan pengiriman.

Untuk tim Anda, definisi cerita "selesai" akan menjadi sesuatu seperti semua kode lengkap, peer review, memenuhi kriteria penerimaan yang ditentukan, unit diuji, UAT'ed, dan didorong ke repositori kode Anda. Untuk memungkinkan penyampaian cerita dari perancang ke pengembang ke penguji, definisi "selesai" harus diterima oleh orang berikutnya dalam rantai. Pemilik produk Anda akan memiliki harapan tentang apa artinya ini bagi mereka untuk merilis peningkatan produk kepada pelanggan Anda. Bagaimanapun, setiap orang harus menyadari apa artinya "selesai" dan menjadi pihak yang bertanggung jawab dalam memastikan maknanya terpenuhi. Definisikan definisi Anda tentang "selesai," komunikasikan, setujui, dan kembangkan. Selesai selesai.

Pengukuran terus menerus

Jika Anda tidak dapat mengukurnya, Anda tidak dapat mengelolanya. Hal yang sama berlaku untuk perbaikan. Kebutuhan untuk mengumpulkan data empiris dalam proyek Agile hampir sama pentingnya dengan aliran darah melalui pembuluh darah Anda! Bagaimana Anda tahu apa yang perlu dikelola, diperbaiki, atau ditingkatkan jika tidak ada data? Sederhananya, Anda akan mengandalkan firasat dan tebakan yang tidak berdasar, yang berantakan dengan cepat di bawah pengawasan. Dan tergantung pada siapa yang melakukan pemeriksaan, ini bisa menjadi tempat yang agak tidak nyaman. Jadi sejak awal proyek Anda, pastikan Anda tahu bagaimana Anda akan menunjukkan kemajuan dan dengan ukuran apa orang lain akan melihat kesuksesan Anda.

Untungnya, Agile hadir dengan alat dan teknik yang berguna. Hal pertama yang harus dilakukan adalah kembali ke Agile Manifesto, ketik kata-kata berikut ke dalam pengolah kata favorit Anda, ledakkan hingga 96pt, cetak, dan terapkan ke dinding untuk dilihat semua orang:

Kekuatan terbesar Anda yang dapat dibuktikan dalam menghadirkan perangkat lunak adalah menunjukkannya kepada orang-orang yang bekerja, melakukan apa yang seharusnya dilakukan. Ini tidak hanya akan membuat pelanggan Anda senang, itu akan membuat tim Anda sangat dihormati dan melumasi roda untuk adopsi yang lebih besar melalui bisnis.

Berikut beberapa alat lainnya:

• Standup harian: Ada beberapa variasi dari upacara ini, tetapi intinya adalah agar semua anggota tim berbicara satu sama lain secara langsung: Tetap singkat, tetap fokus, dan tetap ringan. Jika ada yang membutuhkan diskusi panjang lebar, parkirlah untuk percakapan yang lebih panjang antara mereka yang diperlukan setelah standup. Jika hambatan muncul, tulislah seperti sebuah cerita, tambahkan ke backlog Anda, dan selesaikan secepatnya. Apa pun yang menghambat tim Anda memperlambat kemajuan mereka dan akan ditunjukkan dalam pengurangan kecepatan dan perangkat lunak yang tidak memenuhi harapan.
• Kecepatan: Apakah alat sejarah. Ini sedikit seperti peringatan keuangan yang Anda dapatkan yang mengatakan kinerja masa lalu bukanlah jaminan kinerja masa depan. Namun dalam kasus Agile, kami berharap dapat mencapai kecepatan tim yang sebagian besar lancar. Ini kecepatan yang memungkinkan kita untuk memproyeksikan kinerja masa depan dan keyakinan dalam rencana kami. Mungkin ada pengaruh di luar kendali Anda yang mungkin menurunkan jumlah output poin cerita untuk sprint tertentu. Jika ini terjadi, Anda mungkin bisa pulih. Jangan pernah menggunakan kecepatan sebagai tongkat untuk mengalahkan tim Anda; itu tidak akan memenangkan Anda. Satu hal yang pasti adalah bahwa kecepatan akan tidak menentu untuk 2–4 sprint pertama. Namun, di suatu tempat dalam jangka waktu itu, Anda harus mulai melihat konsistensi dan stabilitas. Jika kecepatan Anda goyah dari satu ekstrem ke ekstrem lainnya, Anda memiliki masalah yang harus diselesaikan dengan tim Anda.
• Bagan burndown: Sekarang ukuran kemajuan ini sulit. Untuk alasan itu, saya belum memberikan tautan untuk mencari tahu lebih lanjut—Anda harus melakukan riset sendiri dan setuju sebagai tim dan bisnis yang cocok untuk Anda. Alasan itu berduri? Yah, tidak ada satu pun sumber di luar sana yang menceritakan kisah yang sama! Satu hal yang disepakati adalah bahwa itu akan menunjukkan, dalam sprint atau rilis, bagaimana kinerja Anda terhadap kotak waktu Anda. Jika dipertahankan setiap hari, itu akan menunjukkan jika Anda berada di jalur atau menyimpang. Beberapa tim menggunakannya untuk menunjukkan berapa banyak nilai yang tersisa untuk dibuat, lebih sering daripada tidak, yang lain menggunakannya untuk menunjukkan berapa banyak pekerjaan yang tersisa untuk diselesaikan. Yang pertama adalah perayaan kesuksesan dan generasi nilai, yang terakhir kurang menginspirasi dan memotivasi.
• Bagan burnup: Jika Anda harus menunjukkan tingkat penyelesaian pekerjaan, gunakan bagan burndown untuk itu. Tetapi menggunakan grafik burnup memungkinkan Anda untuk menunjukkan berapa banyak nilai yang telah dibuat dan berapa banyak lagi nilai yang Anda rencanakan untuk dibuat pada akhir sprint. Alat yang jauh lebih memotivasi bagi tim untuk menunjukkan kepada bisnis apa yang telah dilakukan (atau sedikit jika hal-hal tidak berjalan dengan baik…) dan apa yang masih mereka tuju. Bagaimanapun, gunakan grafik untuk melihat di mana kemajuan tidak mengikuti seperti yang diharapkan dan mencari pola atau penyimpangan dan mengatasinya untuk memperbaiki masalah mendasar sesegera mungkin. Perbarui setiap hari untuk sprint dan sekali di akhir sprint untuk grafik versi rilis.
• Papan tugas: Ini adalah radiator visual yang bagus untuk menunjukkan nilai yang sedang dibuat. Ketika diperbarui setiap hari, atau kapan saja dalam sehari, mereka segera menunjukkan kemajuan yang dibuat. Jika dikombinasikan dengan Kanban, mereka juga merupakan alat yang hebat untuk memvisualisasikan aliran dan penyumbatan dalam sistem. Jika Anda dapat melihat bahwa banyak pengembangan telah selesai, tetapi pengujian tidak seproduktif ini, Anda dapat melihat masalah terjadi dan merespons dengan tepat dan cepat.

Alat lain yang perlu dipertimbangkan adalah nilai yang diperoleh Agile, waktu siklus, dan diagram alir kumulatif (CFD's).

Pertahankan ukuran, bagan, dan alat lain ini terlihat, lebih disukai keras dan bangga di dinding untuk dilihat semua orang. Tim, pemangku kepentingan, dan pihak lain yang berkepentingan dapat langsung melihat status suatu proyek. Ini transparan dan berfungsi sebagai alat komunikasi yang berharga. Jika Anda tidak dapat meletakkan artefak ini di dinding, gunakan alat yang dapat dibagikan dan kolaboratif dan pastikan mereka yang menginginkan akses memilikinya.

Perbaikan terus-menerus

Sepanjang hidup Agile Anda, berusahalah untuk mengidentifikasi dan mempelajari di mana perbaikan dapat dilakukan. Pelajaran tidak ditangkap dan dipelajari di akhir proyek. Ini seperti lulus ujian mengemudi dan mencoba mengemudi pertama tanpa instruktur. Anda akan tahu apa yang berhasil dan apa yang harus Anda lakukan, tetapi seiring waktu Anda akan menyesuaikan keterampilan dan kemampuan mengemudi Anda, mempelajari teknik-teknik baru. Anda bahkan akan mengambil kebiasaan buruk. Cari mereka, pahami, dan temukan cara untuk meningkatkan.

Ada banyak peluang untuk mengidentifikasi apa yang tidak berhasil dan menerapkan solusi. Pendekatan bawaan untuk ini di Agile adalah retrospektif. Ini adalah alat utama untuk refleksi dan penyesuaian. Di akhir setiap sprint, luangkan waktu bersama tim untuk meningkatkan bagaimana pekerjaan diselesaikan, bagaimana kualitas disampaikan, bagaimana efisiensi dapat dimaksimalkan, bagaimana pemborosan dapat diminimalkan, dan bagaimana kapasitas ditingkatkan. Ketika Anda mengidentifikasi langkah-langkah untuk perbaikan, jangan tergoda untuk segera memperbaiki semua masalah Anda. Identifikasi yang paling berdampak dan dapat diterapkan di sprint berikutnya. Ukur dan amati. Jika itu memiliki dampak yang diinginkan, kuncilah, tuliskan ke dalam cara kerja Anda dan definisi selesai. Jika tidak berhasil, pikirkan lagi. Pelajaran apa pun yang tidak dimasukkan ke dalam sprint yang akan datang dapat diparkir dan diprioritaskan untuk diperhatikan di sprint berikutnya.

Sesuaikan prosesnya. Hapus apa pun yang tidak berfungsi. Hapus hambatan. Kedewasaan Anda sebagai tim Agile tidak akan mengenal batas jika Anda membiarkannya.

Melampaui Manajemen Proyek Agile

Sangat penting untuk mengetahui apa yang terjadi setelah proyek dikirimkan. Dukungan dan pemeliharaan adalah kunci untuk memastikan bahwa, setelah proyek berada di tangan pelanggan, proyek tetap berkinerja; umpan balik pelanggan dapat diperhitungkan dalam rilis mendatang; dan masalah pelanggan ditangani dengan tepat. Proyek adalah usaha yang unik dan dibatasi waktu. Produk yang diberikannya memiliki kehidupan setelah tim proyek dibubarkan. Pastikan bahwa Anda mampu mendukung produk setelah itu hidup.

Proyek tangkas hidup berdampingan dengan pendekatan yang lebih tradisional. Menyeimbangkan persyaratan untuk kontrol anggaran dan visibilitas pemangku kepentingan dengan tujuan fleksibilitas dan daya tanggap Agile.

Kerangka tata kelola atau model tata kelola Agile digunakan bersama dengan proses standar Agile, seperti Scrum. Mereka bekerja dengan dua cara khusus:

• Mereka menyediakan pembungkus untuk proyek Agile dengan mengklarifikasi proses yang terjadi di luar iterasi pengembangan (sprint). Ini termasuk memberikan kriteria yang jelas untuk keberhasilan penyelesaian inisiasi proyek dan validasi yang tepat dari keputusan dan rencana.
• Mereka menggeser penekanan bagian-bagian tertentu dari proses Agile standar dan menyoroti prinsip-prinsip dan teknik-teknik tertentu yang memerlukan tata kelola atau dukungan tata kelola.

Di dunia yang terus berubah saat ini, organisasi dan bisnis tertarik untuk mengadopsi pendekatan yang lebih fleksibel dalam memberikan proyek, dan ingin menjadi lebih Agile. Namun, untuk organisasi yang memberikan proyek dan program, dan di mana proses manajemen proyek formal yang sudah ada, informalitas dari banyak pendekatan Agile menakutkan dan terkadang dianggap terlalu berisiko. Organisasi yang berfokus pada proyek ini memerlukan pendekatan tangkas yang matang—kelincahan dalam konsep penyampaian proyek— Manajemen proyek tangkas .

Belajar dan berkembang dengan adopsi Agile Anda. Lakukan hanya apa yang membuat tim Anda nyaman, pastikan suara mereka didengar, dan bertindak sesuai permintaan mereka. Dorong tim Anda untuk mengadopsi teknik baru dan lebih berharga ketika waktunya tepat. Bernegosiasi dengan bisnis dan dorong mereka untuk memahami apa artinya menjadi organisasi Agile.

Nikmati perjalanan.