Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Workflow

SCRUM: Kisah Tim Agile

by
Difficulty:AdvancedLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Suci Rohini (you can also view the original English article)

Scrum adalah salah satu teknik tangkas yang paling banyak digunakan. Ini bukan tentang pengkodean; melainkan berfokus pada organisasi dan manajemen proyek. Jika Anda memiliki beberapa saat, izinkan saya memberi tahu Anda tentang tim tempat saya bekerja, dan bagaimana kita mengadopsi teknik Scrum.


Sedikit Sejarah

Akar Scrum sebenarnya melampaui era Agile.

Akar Scrum sebenarnya melampaui era Agile. Penyebutan pertama teknik ini dapat ditemukan pada tahun 1986, oleh Hirotaka Takeuchi dan Ikujiro Nonaka, untuk pengembangan produk komersial. Naskah resmi pertama yang mendefinisikan Scrum, yang ditulis oleh Jeff Sutherland dan Ken Schwaber, disajikan pada tahun 1995.

Popularitas Scrum tumbuh tak lama setelah penerbitan Agile Manifesto 2001, serta buku Agile Software Development dengan Scrum, ditulis bersama oleh Ken Schwaber dan Mike Beedle.


Beberapa Fakta

Scrum mendefinisikan satu set rekomendasi, yang mana tim didorong untuk mengikuti. Ini juga mendefinisikan beberapa aktor - atau peran, jika Anda lebih suka terminologi itu - bersama dengan proses produksi dan perencanaan periodik yang berulang. Ada beberapa tool, yang mengakomodasi proses Scrum. Saya akan referensi beberapa di artikel ini, tetapi tool yang paling kuat adalah papan tulis dan catatan tempel.

Tidak ada, dan tidak akan pernah ada, daftar "Praktik Terbaik Scrum," karena tim dan konteks proyek mengalahkan semua pertimbangan lain. -- Mike Cohn

Peranan

Semuanya dimulai dengan babi dan ayam. Ayam bertanya kepada babi apakah dia tertarik untuk membuka restoran bersama. Ayam itu mengatakan mereka bisa menyebutnya, "Ham-and-Eggs." Babi menjawab, "Tidak, terima kasih. Saya akan berkomitmen, tetapi Anda hanya akan terlibat!"

Itu Scrum! Ini menentukan satu set peran konkret, yang dibagi menjadi dua kelompok:

  • Berkomitmen - mereka yang secara langsung bertanggung jawab untuk produksi dan pengiriman produk akhir. Peran ini termasuk tim secara keseluruhan, anggotanya, master scrum, dan pemilik produk.
  • Terlibat - mewakili orang lain yang tertarik dengan proyek, tetapi yang tidak mengambil bagian aktif atau langsung dalam proses produksi dan pengiriman. Peran ini biasanya adalah pemangku kepentingan dan manajer.

Ini adalah Cara Kita Memulai

Semuanya tergantung pada dedikasi dan niat baik. Jika Anda ingin tim Anda menjadi efisien, produktif, dan tepat waktu, Anda membutuhkan seseorang untuk merangkul beberapa bentuk teknik Agile. Scrum mungkin atau mungkin tidak ideal untuk Anda, tetapi itu pasti salah satu tempat terbaik untuk memulai. Temukan bahwa seseorang di tim Anda yang bersedia membantu orang lain, atau Anda sendiri, dapat mengambil tanggung jawab untuk memperkenalkan Scrum.

Anda mungkin bertanya mengapa Anda harus peduli bagaimana tim lain, seperti saya, melakukan Scrum. Anda harus peduli karena kita semua belajar bagaimana melakukan Scrum dengan lebih baik dengan mendengar cerita tentang bagaimana hal itu dilakukan oleh orang lain - terutama mereka yang melakukannya dengan baik. - Mike Cohn

Tim berbakat yang bekerja dengan saya sudah tahu banyak tentang Agile. Kita beralih dari pengembangan Waterfall ke proses yang lebih gesit, dan dirilis cukup sering. Kita berhasil berhasil merilis setiap tiga hingga enam bulan, memiliki jumlah bug yang cukup rendah setelah setiap rilis.

Tapi, tetap saja, kita jauh dari apa yang bisa dicapai hari ini. Melewatkan proses, atau aturan, yang akan memaksa kita mengubah perspektif tentang produk dan proses. Itulah saat ketika manajer tim memperkenalkan kita kepada Scrum, sebuah istilah yang, pada waktu itu, belum pernah didengar.

Orang ini mengambil peran Scrum Master.

Scrum Master

Master Scrum dengan mudah adalah salah satu peran yang paling penting. Orang ini bertanggung jawab untuk menciptakan jembatan antara Product Owner (didefinisikan di bawah) dan Team (juga ditentukan kemudian). Orang ini biasanya memiliki pengetahuan teknis yang kuat, dan secara aktif berpartisipasi dalam proses pengembangan. Dia juga berkomunikasi dengan Product Owner tentang User Stories, dan bagaimana mengatur Backlog.

Guru Scrum mengkoordinasikan proses pengembangan, tetapi dia tidak mengelola mikro (tim ini diatur sendiri). Pada awal proses, bagaimanapun, Scrum Master mungkin mengelola mikro bagian dari tim, untuk meningkatkan interaksi tim mereka dan teknik pengaturan diri.

Scrum Masters memiliki lebih banyak tanggung jawab, dan saya akan membahasnya saat kita membahas proses ini.


Memperkenalkan Istilah "Sprint"

Secara pribadi, kita tidak memiliki masalah dengan rilis tiga hingga enam bulan, tetapi awalnya saya tidak dapat membayangkan jadwal rilis yang sering. Saya pikir itu terlalu cepat, dan tidak memberi kita waktu yang diperlukan untuk mengintegrasikan dan men-debug produk. Tapi kemudian, Scrum Master kita memperkenalkan pada istilah, sprint.

Sprint: unit dasar pengembangan di Scrum. Ini bisa memakan waktu antara satu minggu dan satu bulan, dan produk dalam keadaan stabil setelah setiap sprint.

Itu terdengar keterlaluan! Stabil setiap minggu > Tidak Mungkin! Tapi, sebenarnya, itu sangat mungkin. Pertama, kita mengurangi siklus produksi dari tiga bulan menjadi satu setengah bulan, dan akhirnya menjadi satu bulan. Semua ini dilakukan tanpa mengubah gaya kita. Namun, Anda harus memperkenalkan beberapa aturan untuk sprint kurang dari tiga puluh hari. Tidak ada aturan-aturan sihir di sini; aturan harus menguntungkan proyek Anda.

Jika saya ingat dengan benar, perubahan signifikan pertama dalam proses pengembangan kita datang dengan pengenalan perencanaan sprint.

Perencanaan Sprint

Ini adalah salah satu dari beberapa pertemuan yang direkomendasikan Scrum. Sebelum setiap sprint baru, tim, pemilik produk, dan master scrum merencanakan sprint berikutnya. Pertemuan ini dapat memakan waktu satu hari penuh, tetapi sprint yang lebih pendek mungkin hanya membutuhkan beberapa jam atau lebih.

Proses kita kebanyakan meninjau backlog produk, dan memutuskan subkumpulan cerita pengguna yang akan dimasukkan dalam sprint berikutnya. Keputusan ini dibuat melalui negosiasi langsung antara tim, yang diwakili oleh master scrum, dan pemilik produk.

Pemilik Produk

Mengatur arah suatu produk dengan menebak fitur kecil mana yang akan memberikan nilai paling banyak mungkin merupakan tugas yang paling sulit.

Orang ini bertanggung jawab untuk mendefinisikan Cerita Pengguna dan mempertahankan Product Backlog. Ia juga merupakan jembatan antara tim dan manajemen yang lebih tinggi. Pemilik produk mengevaluasi permintaan dari pemangku kepentingan, manajemen yang lebih tinggi, pengguna, dan umpan balik lainnya (seperti laporan bug, survei pengguna, dll).

Dia memprioritaskan backlog ini, memberikan nilai maksimum kepada para pemangku kepentingan dalam waktu sesingkat mungkin. Pemilik produk mencapai ini dengan merencanakan cerita pengguna yang paling berharga yang dapat diselesaikan tepat waktu. Ini mungkin terdengar canggih - tentu! Bahkan, menetapkan arah suatu produk dengan menebak fitur kecil mana yang akan memberikan nilai paling banyak mungkin merupakan tugas tersulit dari keseluruhan proses. Di sisi lain, terkadang agak mudah. Anda mungkin memiliki seribu pengguna yang meminta fitur tertentu. Dalam kasus ini, pilihan yang benar sudah jelas.

Jika pengguna tersebut mewakili sebagian besar basis pengguna Anda, asalkan fitur spesifik itu meningkatkan loyalitas.

Tetapi sekali lagi, ini adalah pilihan yang sulit. Bagaimana jika Anda dapat meningkatkan basis pengguna Anda sebesar 100% dengan menerapkan fitur yang berbeda? Jadi, Anda dapat meningkatkan loyalitas pengguna Anda saat ini, atau meningkatkan basis pengguna. Apa pilihan yang benar? Itu semua tergantung pada arah bisnis saat ini, dan pemilik produk harus memutuskan di mana mengambil produk.

Di perusahaan tempat saya bekerja, keputusan ini menyebar ke tim. Ini bukan persyaratan proses Scrum, tetapi sangat berguna dengan tim baru. Berbagi informasi sangat membantu semua orang memahami mengapa beberapa keputusan dibuat, dan mengapa fitur yang tampaknya jelas dapat ditunda atau dijatuhkan.


Badan Perencanaan

Saya ingat pagi itu terjadi: Saya tiba di kantor, hanya untuk menemukan guru scrum kita menyiapkan papan perencanaan darurat dengan kertas A4 dan pita transparan. Saya tidak tahu apa yang dia lakukan. Seperti setiap pagi, saya menyiapkan teko kopi, dan menunggu untuk melihat.

Setelah selesai, sebuah papan putih ditempatkan di dinding. Itu memiliki beberapa kolom, dan berubah menjadi bentuk persegi panjang. Beberapa catatan tempel berwarna membumbui "papan". Itu dua tahun lalu.


Papan sekarang mengakomodasi Proses Pengembangan Lean yang digunakan hari ini. Ingat, Agile adalah tentang perubahan dan beradaptasi untuk berubah. Jangan membabi buta mengikuti aturan.

Jadi, apa yang ada di papan itu?

Kolom untuk Proses Pengembangan

Ada empat kolom utama:

  • Release Backlog - Di mana semua cerita berada untuk rilis saat ini. Ya, produk siap dirilis setelah setiap sprint, tetapi itu tidak berarti bahwa kita benar-benar melepaskannya. Kita biasanya memiliki sprint lima hari.
  • Sprint Backlog - Saat merencanakan, kita menegosiasikan apa yang ingin diselesaikan oleh pemilik produk dalam sprint. Bagaimana kita memutuskan apa yang bisa dan tidak bisa diselesaikan? Dengan memperkirakan kesulitan masing-masing cerita (lihat di bawah - Memperkirakan cerita). Hasil akhirnya adalah sekumpulan cerita yang dipindahkan dari rilis backlog ke backlog sprint. Tim berkonsentrasi untuk menyelesaikan cerita-cerita itu di minggu mendatang.
  • Mengerjakan - Yang ini sederhana. Ketika anggota tim mengambil cerita, mereka menambahkannya ke kolom ini, untuk menunjukkan kepada semua orang apa yang sedang mereka kerjakan. Ini dimaksudkan untuk kontrol karyawan, tetapi untuk berkomunikasi dengan anggota tim. Setiap orang harus selalu tahu apa yang rekan kerjanya sedang kerjakan. Dalam gambar di atas, penanda kecil yang menempel pada catatan tempel berisi nama anggota tim saya.
  • Selesai - Selesaikan semua hal! Ya, ini adalah cerita yang sudah selesai. Namun, penting untuk mendefinisikan "apa yang sudah dilakukan." Pada akhir sprint yang ideal, semua cerita dan bug dari backlog sprint harus dimuat dalam kolom ini.

Tips: Banyak tim ingin membagi kolom Working On menjadi beberapa yang lain untuk lebih mendefinisikan berbagai tahap kerja. Kita bagi menjadi Desain kita, Pengembangan, dan Pengujian. Jangan ragu untuk membuat langkah Anda sendiri, sesuai dengan proses Anda.

Definisi Selesai

Apa yang sudah dilakukan? Kapan Anda bisa dengan yakin menyatakan bahwa sebuah cerita selesai? Bagaimana Anda tahu?

"Selesai" harus didefinisikan dengan jelas dan tepat, sehingga semua orang tahu kapan sebuah cerita selesai. Definisi "selesai" dapat berbeda dari tim ke tim, dan bahkan dari proyek ke proyek. Tidak ada aturan pasti. Saya menyarankan Anda mengangkat masalah ini pada rapat tim, dan putuskan apa yang menentukan cerita yang lengkap. Berikut beberapa ide yang mungkin ingin Anda pertimbangkan:

  • Buat desain minimalis.
  • Buat mockup GUI.
  • Gunakan TDD atau pastikan ada tes unit.
  • Tulis kodenya.
  • Biarkan anggota tim lain secara manual menguji cerita Anda.
  • Seluruh sistem dapat dibangun dan dikompilasi dengan kode baru.
  • Tes fungsional atau penerimaan lulus seperti yang diharapkan, setelah kode baru diintegrasikan ke dalam sistem.

Ada beberapa ide yang dapat dimasukkan dalam definisi yang sudah dilakukan. Ambil apa yang Anda anggap perlu untuk tim Anda dan gunakan itu. Juga, jangan lupa untuk menyesuaikan definisi ini dari waktu ke waktu. Jika Anda melihat bahwa definisi Anda menjadi ketinggalan zaman, Anda dapat mempertimbangkan untuk menghapus beberapa elemen atau menambahkan ide yang diperlukan, tetapi sering dilupakan.

Pada gambar di atas, catatan tempel hijau menggambarkan apa yang kita anggap dilakukan, untuk setiap bagian dari proses.


Mengisi Papan

Itulah pertanyaan yang ditanyakan pada diri sendiri. Sampai titik ini, kita tidak menggunakan catatan tempel untuk perencanaan. Kita menggunakan software untuk melacak cerita dan bug pengguna, tetapi, selain itu, kita tidak menggunakan apa pun. Setelah peluncuran, master scrum mempersembahkan gunung dengan catatan tempel berwarna. Setelah menyiapkan selusin catatan, dia menjelaskannya kepada kita.

Kisah Pengguna

Kisah pengguna adalah definisi singkat, satu kalimat tentang fitur atau fungsionalitas.

Ini mewakili fitur utama yang ingin diterapkan. Kisah pengguna adalah definisi singkat, satu kalimat tentang fitur atau fungsionalitas. Ini disebut sebagai cerita pengguna, karena disajikan dari perspektif pengguna. Biasanya, istilah pengguna adalah orang yang menggunakan aplikasi kita. Orang ini dapat berada dalam satu atau lebih kategori yang berbeda: administrator sistem, pengguna terbatas, manajer, dll.

Contoh cerita seperti itu mungkin terdengar seperti, "Sebagai pengguna, saya ingin berbagi folder dengan rekan tim saya."

Pada saat itu, kita tidak memiliki pemilik produk yang ditentukan, jadi scrum master kita menciptakan kisah-kisah ini. Ini dapat diterima di awal, tetapi saya sangat menyarankan Anda untuk memisahkan dua peran ini. Kalau tidak, bagaimana bisa scrum master menegosiasikan backlog sprint dengan pemilik produk?

Anda mungkin berpikir pada diri sendiri, "Mengapa bernegosiasi? Bukankah lebih baik satu orang memutuskan apa yang harus dilakukan dan kapan?" Tidak terlalu. Dua peran akan dipengaruhi oleh pandangan satu orang dari sistem atau proyek. Dua orang, di sisi lain, memiliki kesempatan yang lebih baik untuk menyediakan jalur yang lebih obyektif bagi tim, memastikan tujuan akhir (software berharga yang lebih baik) tercapai.

Pemilik produk harus menentukan cerita pengguna; tim harus menegosiasikan eksekusinya, dan scrum master mewakili mereka.

Kisah-kisah pengguna menentukan semua hal baru yang perlu dilakukan; mereka diwakili oleh catatan tempel kuning di papan kita.

Bug, Bug, Bug

Melacak bug Anda sangat penting.

Kita juga membuat daftar bug di papan. Apakah Anda melihat catatan tempel merah itu? Itu adalah bug yang harus diperbaiki untuk rilis berikutnya.

Tim yang berbeda memperlakukan bug dengan cara yang berbeda. Tim kita mencampur bug dengan cerita, tetapi kita selalu memulai sprint dengan memperbaiki bug.

Saya tahu tim lain yang menumpuk bug selama jangka waktu tiga sprint, dan menghabiskan setiap sprint keempat untuk memperbaikinya. Lainnya membagi sprint ke 25/75 untuk bug/cerita. Selanjutnya, tim lain dapat mengerjakan cerita di pagi hari, dan bug setelah makan siang; itu hanya tergantung pada perusahaan.

Terserah Anda untuk menemukan solusi terbaik untuk tim Anda, dan tentu saja, melacak bug Anda. Tuliskan pada catatan tempel sehingga Anda dapat melacak masalah sistem Anda dan perbaikan untuk masalah tersebut. Melacak bug Anda sangat penting.

Tugas atau Sub-Cerita

Tugas ditulis sebagai kalimat sederhana dari sudut pandang pengembang.

Idealnya, setiap cerita harus cukup singkat untuk diselesaikan dengan relatif mudah, tetapi membagi cerita ke cerita lain dapat menjadi sulit. Beberapa proyek tidak memiliki kemungkinan ini. Namun, Anda akan menemukan cerita besar yang dapat dikerjakan oleh beberapa anggota tim. Sangat penting untuk membagi potongan besar pekerjaan menjadi lebih kecil, lebih mudah untuk mengelola potongan.

Salah satu pendekatan membagi cerita besar ke Tasks. Tugas ditulis sebagai kalimat sederhana dari sudut pandang pengembang. Misalnya, folder berbagi cerita sebelumnya mungkin dibagi menjadi beberapa tugas, seperti: "Buat UI untuk berbagi", "Menerapkan mekanisme pembagian publik", "Terapkan fungsi kontrol akses", "Tambahkan kotak centang Kontrol Akses ke UI", dan seterusnya. Intinya adalah Anda harus berpikir lebih banyak tentang cerita setiap kali Anda memecahnya menjadi tugas yang lebih kecil. Tim Anda akan memiliki kendali yang lebih besar terhadap sebuah cerita, ketika Anda menganalisis setiap bagian.

Kita menggunakan catatan tempel berwarna biru muda untuk tugas di papan kita. Lihat di kolom terakhir (kolom "Selesai"), dan Anda akan menemukan tugas kita di bawah kisah pengguna. Cerita khusus itu dibagi menjadi sekitar empat tugas.


Tugas Teknis

Kegiatan tertentu harus diselesaikan untuk menyelesaikan tugas, cerita, atau sprint secara keseluruhan. Tugas-tugas ini biasanya terkait dengan infrastruktur, tetapi Anda mungkin menemukan bahwa tugas tersebut membutuhkan perubahan pada sistem. Proses ini mungkin atau mungkin bukan bagian dari sebuah cerita. Misalnya, Anda mungkin menemukan bahwa aplikasi pihak ketiga harus diinstal, untuk menerapkan kemampuan berbagi aplikasi Anda. Apakah ini bagian dari cerita pengguna kami? Mungkin, tapi mungkin tidak.

Kita memutuskan bahwa tugas-tugas ini harus dipisahkan dari cerita yang sebenarnya. Ini membantu untuk lebih baik melacak tugas tambahan ini. Di papan, Anda dapat menemukan tugas-tugas ini pada catatan tempel hijau. Ada satu di backlog sprint, dan sekitar tiga dalam pengujian.

The Backlog Teknis

Untuk tim muda dengan sedikit pengalaman dengan Agile dan Scrum, sangat membantu untuk menyoroti tugas-tugas ini dengan back-backlog.

Backlog ini untuk tugas-tugas infrastruktur, seperti memperbarui sistem pengujian otomatis, mengkonfigurasi server baru, dan hal-hal lain, yang membuat pekerjaan pembangunan kita sehari-hari menjadi lebih mudah. Ini adalah hal-hal yang harus diselesaikan pada titik tertentu, tetapi tidak terkait langsung dengan pembangunan.

Anda tidak harus memasukkan barang-barang ini ke dalam backlog terpisah. Bahkan, saya tahu tim yang tidak memisahkan mereka. Tim kita menjatuhkan jaminan teknis beberapa bulan yang lalu; kita memutuskan bahwa tugas infrastruktur sama pentingnya dengan tugas lain. Namun, untuk tim muda dengan sedikit pengalaman di Agile dan Scrum, sangat membantu untuk menyoroti tugas-tugas ini dengan back-backlog. Jadi, saya sarankan Anda mencobanya. Ini dapat bekerja untuk Anda, dan, jika tidak, maka letakkan saja Tugas-tugas Infrastruktur di papan perencanaan Anda, mungkin dengan warna yang berbeda.


Tantangan Besar: Estimasi

Selama pertemuan perencanaan, kita memutuskan cerita dan bug pengguna mana saja dari backlog produk (atau rilis backlog dalam kasus kita) untuk disertakan dalam sprint berikutnya. Ini mungkin terdengar sederhana, tetapi, dalam kenyataannya, itu cukup rumit.

Pemilik produk datang ke depan dengan serangkaian cerita untuk dikerjakan. Daftar ini biasanya berisi lebih banyak pekerjaan daripada yang bisa dicapai dalam sprint. Master scrum, bersama dengan tim, harus meyakinkan pemilik produk apa yang bisa dilakukan selama sprint. Seiring waktu, proses ini menjadi lebih mudah, karena pemilik produk mempelajari perkiraan kecepatan tim. Kemudian lagi, tim dapat menjadi lebih produktif dengan setiap sprint, sehingga memungkinkan lebih banyak cerita untuk diselesaikan. Triknya adalah memiliki tim yang benar-benar ingin melebihi harapan!

Sekarang, pemilik produk ingin menyelesaikan lebih banyak cerita daripada yang bisa dilakukan di sprint. Kita perlu memperkirakan jumlah pekerjaan yang dapat kita lakukan sehubungan dengan cerita yang disampaikan oleh pemilik produk, dan kita dapat melakukan ini dengan berbagai cara.

Poin Cerita

Story Points adalah salah satu metode paling umum untuk memperkirakan cerita, bug, atau tugas. Mereka belum tentu merupakan pendekatan terbaik, tetapi mereka masih merupakan cara yang baik untuk memulai.

Jadi apa itu titik cerita? Pada awal proses, tim mencari cerita paling sederhana yang dapat mereka temukan di papan tulis. Tidak masalah seberapa sulitnya itu, atau berapa lama untuk menyelesaikannya. Ketika mereka menemukan cerita itu, mereka mengaturnya sebagai kisah referensi memiliki satu titik. Dalam beberapa proyek, kisah seperti itu dapat sesederhana memperbaiki elemen UI dalam sepuluh menit; sedangkan, cerita paling sederhana untuk sistem yang lebih kompleks mungkin membutuhkan waktu dua jam untuk tiga orang untuk menyelesaikannya. Sekarang setelah Anda memiliki baseline, evaluasi cerita dan bug lainnya dan beri mereka poin.

Ini bisa lebih sulit daripada kelihatannya, dan ada beberapa teknik titik untuk membantu memperkirakan cerita dengan lebih baik. Ini ada dua di antaranya:

  • Gunakan Nomor Fobinacci - 1,2,3,5,8 (dan mungkin 13, tapi cerita berukuran 13 berbau terlalu besar bagi saya).
  • Gunakan Kekuatan 2 - 1,2,4,8 (dan mungkin 16, tetapi jumlah ini harus dihindari).

Anda bebas memilih apa pun yang menurut Anda paling nyaman. Jadilah gesit! Mungkin Anda ingin menggunakan dua poin tambahan, karena tugas Anda paling tepat diperkirakan dengan cara itu. Bravo untukmu!

Semaphores

Angka-angka itu hebat, dan banyak orang teknis menyukainya. Anda mungkin menemukan, bagaimanapun, bahwa, pada titik tertentu, programmer mulai mengasosiasikan poin cerita dengan waktu. Mereka akan berpikir, "Butuh dua hari untuk melakukan ini. Mari kita beri lima poin". Ini salah. Perkiraan berubah dari buruk menjadi lebih buruk saat ini terjadi. Poin cerita tidak boleh berhubungan dengan waktu.

Menggunakan warna semaphore dapat membantu meringankan masalah ini. Daripada menetapkan angka ke cerita, tim dapat mengaitkan cerita-cerita tersebut dengan warna. Tim kita membuat perubahan ini beberapa bulan yang lalu, dan itu sangat membantu mengubah sudut pandang kami.

Secara alami, setiap warna memiliki arti yang berbeda.

  • Hijau menandakan tugas yang mudah yang dapat diselesaikan di sprint berikutnya.
  • Kuning mengacu pada tugas yang lebih sulit - yang membutuhkan lebih banyak upaya dari beberapa anggota tim. Ini juga memiliki kemungkinan tinggi untuk selesai di sprint berikutnya.
  • Label merah ditugaskan untuk cerita, yang sangat sulit dan mungkin tidak selesai dalam satu sprint. Seharusnya tidak ada atau tidak ada cerita semacam itu, tetapi jika Anda menggunakan sprint satu minggu, lima hari adalah waktu yang singkat.

Ukuran T-Shirt

Angka mungkin jelek bagi Anda, warna terlalu artistik. Sudah waktunya untuk ukuran t-shirt! Teknik ini menyarankan untuk berhenti membandingkan kompleksitas cerita dengan waktu penyelesaian. Sederhananya, alih-alih angka, Anda menggunakan ukuran seperti S, M, L, XL, XXL untuk cerita Anda.

Saya pribadi tidak pernah merasa tertarik dengan perkiraan semacam ini, tetapi, hei, beberapa merasa bahwa ini adalah cara terbaik untuk pergi. Cobalah, jika Anda merasa nyaman dengan ide itu.


Pemilik produk, pemegang saham, dan manajer harus tahu apa yang diharapkan dari ujung sprint. Mereka harus memutuskan apakah cerita yang dikerjakan harus dirilis, dan mereka harus tahu kapan fitur sudah siap. Ini bukan solusi yang baik untuk merilis setiap fitur baru di akhir siklus pengembangan produk; merilis fitur yang paling berharga secara lebih sering adalah cara yang jauh lebih baik untuk dilakukan. Untuk mencapai ini, mereka harus tahu apa yang akan tersedia dalam jangka pendek, dan informasi mereka harus berasal dari tim. Oleh karena itu, tim harus memperkirakan, sebaik mungkin, pekerjaan yang dapat mereka lakukan dalam sprint.


Mengukur Kecepatan Pengembangan

Jadi Anda ingin melihat seberapa baik Anda tampil di sprint saat ini? Metode yang sering digunakan adalah grafik burndown:


Dalam grafik ini, kita memiliki sprint lima hari, dan berasumsi bahwa kita dapat menyelesaikan sepuluh poin dalam sprint. Setiap titik nilai mewakili titik cerita yang tersisa di akhir setiap hari. Garis hijau menunjukkan jalur yang ideal: stabil dua poin per hari. Garis merah menunjukkan kinerja aktual kita, atau kecepatan pengembangan yang sebenarnya.

Ini tidak ada pada gambar papan perencanaan, tetapi tim saya biasanya memiliki selembar kertas A4 yang ditempatkan di atas papan perencanaan, dengan grafik peluruhan untuk setiap sprint. Pada akhir setiap hari, salah satu anggota tim bertanggung jawab untuk menghitung poin yang diselesaikan untuk hari itu. Ini sederhana: jika pemrogram memindahkan cerita dari kolom ke kolom saat mereka bekerja, menemukan sisa cerita yang belum selesai itu mudah.

Tidak ada cerita setengah jadi. Jika sebuah cerita selesai, itu sudah selesai. Jika tidak lengkap, maka tidak dihitung pada grafik burndown.

Tentu saja, Anda akan gagal - WAKTU BESAR - pada perkiraan! Ini terutama benar di awal. Tidak ada cara untuk menghindari hal ini, sayangnya. Tidak ada cara untuk mengetahui berapa banyak poin yang dapat Anda berikan. Bagan pertama Anda mungkin sangat mirip:


Grafik pertama kami pasti terlihat mirip dengan itu. Saya pikir kita bahkan belum menyelesaikan setengah dari komitmen. Mengapa? Yah, karena perkiraan itu sulit. Tidak peduli apa yang Anda lakukan, atau seberapa baik Anda, ketika seseorang bertanya betapa rumitnya hal yang belum pernah Anda lakukan sebelumnya, Anda akan kesulitan menyediakan perkiraan yang akurat. Jangan panik! Mencoba yang terbaik. Seiring waktu, hal-hal ini menjadi lebih mudah. Anda mungkin bisa memperkirakan dengan akurasi 70% di beberapa titik untuk sprint pendek. Jika sprint lebih panjang, akurasi Anda kemungkinan akan berkurang, karena akan ada lebih banyak cerita untuk diperkirakan dan lebih banyak variabel yang bisa salah.

Ketika ini terjadi, Anda menyesuaikan. Untuk sprint berikutnya, ambil empat poin. Seperti ini:


Ini buruk lagi. Anda terlalu konservatif, dan selesai lebih awal. Ini adalah reaksi alami bagi tim untuk menyesuaikan, berdasarkan kegagalan estimasi sebelumnya. Namun, ini adalah kegagalan lagi, tetapi di sisi lain jalan.

Masalah? Apa yang Anda lakukan setelah menyelesaikan apa yang Anda rencanakan? Cerita lain? Bagaimana Anda meletakkannya di grafik? Anda tidak dapat menggambar ulang baris asli.

Ketika bekerja dengan grafik burndown, disarankan untuk selalu membuat rata-rata dari 3-5 chart terakhir, untuk menentukan poin untuk sprint yang akan datang. Tentu saja, pada awalnya, Anda tidak memiliki informasi yang tersedia, jadi Anda tidak akan seakurat di masa depan. Tidak apa-apa.

Setelah beberapa waktu, bagan Anda akan mulai menyerupai contoh pertama semakin banyak. Anda akan, sebagian besar waktu, menyelesaikan semua cerita dan memiliki kecepatan yang berkelanjutan.

Kecepatan?

Istilah ini mengacu pada kecepatan perkembangan Anda. Ini berhubungan dengan seberapa banyak yang dapat Anda lakukan dalam sprint. Salah satu konsep terpenting dalam Agile adalah memiliki kecepatan yang konsisten. Buat tim berjalan dengan kecepatan konstan. Dengan manajemen proyek tradisional, kecepatan menurun seiring usia proyek. Kompleksitas dan kekakuan memaksa kecepatan pengembangan turun.

Metodologi dan teknik tangkas menargetkan untuk mempertahankan kecepatan konstan. Kirim cepat sekarang, dan sampaikan lebih cepat nanti. Bagaimana mereka melakukannya? Scrum adalah salah satu elemen dari teka-teki. Bagian penting lainnya termasuk teknik yang dapat digunakan programmer untuk membuat kode dan proses pengembangannya menjadi lebih baik. Misalnya, XP (Pemrograman eXtreme), Pemrograman Pasangan, TDD (Test Driven Development), dll. Semua ini, bersama-sama, dapat membuat tim benar-benar hebat.

Jadi kita mengukur kecepatan ini, tetapi apa yang sebenarnya kita lakukan dengannya?

Tips: Mengukur kecepatan adalah untuk membuat prediksi yang lebih baik; bukan untuk menilai tim atau anggotanya.

Gunakan kecepatan untuk mengetahui apa yang dapat dilakukan tim Anda. Gunakan kecepatan untuk mengetahui apa yang diharapkan. Gunakan kecepatan untuk membuat tim Anda menginginkan lebih banyak dan menjadi lebih baik. Jangan pernah menggunakan kecepatan untuk menilai tim Anda atau mengevaluasi produktivitas programmer Anda.


Selalu Lihat Kembali dan Tingkatkan

Setelah beberapa sprint pertama, ahli scrum kita mengumpulkan seluruh tim. Dia mulai bertanya tentang hal-hal baik dan buruk dari minggu lalu. Ini mungkin tidak nyaman di awal, tetapi masih sangat penting. Menggambarkan apa yang Anda rasakan salah dalam seminggu terakhir akan menciptakan kesadaran. Dan, tentu saja, juga bermanfaat untuk menyoroti apa yang berjalan dengan baik!

Pertemuan-pertemuan ini biasanya disebut sebagai Retrospektif. Mereka menawarkan ruang lingkup untuk menyoroti apa yang baik dan apa yang salah. Berikut beberapa contoh dari retrospektif saya sendiri.

Hal-hal Buruk

  • Anggota tim terlalu banyak bertempur
  • Anggota tim X atau Y tidak kolaboratif ketika memprogram pasangan
  • Kita kehilangan terlalu banyak waktu dengan hal-hal kecil, seperti X atau Y
  • Kita tidak memasangkan program setiap saat
  • Kita tidak menulis tes unit untuk modul M

Ketika mendiskusikan masalah, cobalah mengesampingkan perasaan pribadi Anda; berbicara tentang apa yang mengganggumu. Ini adalah satu-satunya cara bagi tim untuk menyelesaikan masalah ini. Yang paling penting adalah segera mengajukan solusi untuk setiap masalah. Jangan hanya membiarkan daftar itu ditulis dan dilupakan; tinggal selama beberapa menit, dan minta seluruh tim memikirkan apa yang dapat dilakukan untuk menghindarinya minggu depan.

Hal-hal Baik

  • Kita selesai tepat waktu
  • Kita mampu berbicara tanpa berkelahi
  • Beberapa dari kita menjadi lebih mudah menerima saran dan ide
  • Kita menulis semua kode dengan TDD

Sekali lagi, sorot sebanyak mungkin hal yang baik - terutama di awal atau dengan programmer junior. Misalnya, memiliki semua kode yang ditulis dengan TDD mungkin merupakan pencapaian besar bagi tim junior. Buat mereka merasa sangat baik tentang hal itu, buat mereka ingin melakukannya lebih dan lebih lagi. Hal yang sama berlaku untuk tim senior; mereka hanya memiliki hal-hal lain untuk disoroti (TDD dilakukan dengan refleks).


Saya Ingin Melihat Apa Yang Anda Lakukan Sprint Ini

Demo ini untuk menunjukkan pemegang saham (dan pemilik produk) kemajuan proyek.

Judul ini berasal dari kata-kata master scrum saya. Pada saat itu, dia juga adalah pemilik produk. Sebelum akhir sprint, dia akan meminta untuk menyajikannya dengan apa yang dicapai. Kita Demo, atau contoh yang berfungsi dalam lingkungan yang terkendali.

Scrum mengusulkan demo ini di akhir setiap sprint. Ini harus dilakukan sebelum pertemuan retrospektif yang kita diskusikan di atas. Tim harus menyiapkan lingkungan khusus, dan memastikan bahwa produk mampu menampilkan fitur-fitur yang dilakukan dalam sprint ini. Demo ini untuk menunjukkan pemegang saham (dan pemilik produk) kemajuan proyek.

Anda mungkin bertanya pada diri sendiri mengapa saya menyebutkan lingkungan yang terkendali, ketika produk kita harus siap produksi pada setiap akhir sprint. Ya, produk harus sedekat mungkin dengan produksi siap, tetapi itu tidak berarti bahwa fitur itu sendiri, sudah siap. Seringkali, akan ada fitur yang terlalu besar untuk muat dalam satu sprint. Produk akan tetap stabil, tetapi fitur tidak akan cukup siap. Ketika stakeholder melihat demo, mereka ingin meninjau fitur dan apa yang bisa dilakukan. Dalam banyak kasus, untuk menampilkan beberapa fungsi untuk fitur yang belum selesai, lingkungan khusus harus disiapkan terlebih dahulu.

Selain itu, berdasarkan demo ini, pemilik produk dapat menentukan bahwa fitur yang lebih besar cukup bagus, dan versi baru dari produk tersebut harus dipublikasikan dan dikirim kepada pengguna. Sebagian besar waktu, bahkan jika fitur tidak cukup lengkap, rilis akan membantu proyek mendapatkan umpan balik pengguna yang berharga, dan berkonsentrasi penyelesaian fitur dengan cara yang akan memuaskan pengguna sebanyak mungkin.

Yah, ini kedengarannya cukup sederhana. Anda adalah tim yang gesit, Anda menjaga pengujian selalu hijau, dan produk Anda dalam keadaan stabil. Seberapa sulitkah menyiapkan demo cepat? Ini lebih sulit dari yang Anda kira!

Tim kita membutuhkan, jika saya ingat dengan benar, lebih dari lima upaya sebelum kita berhasil menyiapkan demo dengan benar. Untungnya bagi kita, para pemegang saham tidak termasuk dalam demo gagal pertama ini!


Namun, Kita Membutuhkan Lebih Banyak Panduan

Dalam pertemuan ini, setiap anggota tim harus menjawab tiga pertanyaan.

Itu adalah saat ketika guru scrum kita mengusulkan untuk mengadakan pertemuan setiap hari. Iya nih! Setiap hari, setiap pagi, pada jam yang tepat!

Saya menemukan ini menjadi hal yang sangat baik untuk tim baru - untuk orang-orang yang belum nyaman satu sama lain, atau dengan proyek. Pertemuan harian ini, yang disebut Daily Scrum, disimpan bersama tim, pada waktu tertentu setiap hari. Ini harus disimpan sebelum pekerjaan dilakukan untuk hari yang bersangkutan. Di tim saya, kita mengatur waktu hingga jam 10 pagi setiap pagi, yang sulit dilakukan. Meskipun demikian, itu adalah keputusan yang benar.

Scrum harian adalah pertemuan singkat dan sederhana (tidak lebih dari lima belas menit). Ruang lingkupnya adalah untuk membantu anggota tim melihat siapa yang melakukan apa, dan menentukan di mana masalah dan kemacetan dalam proyek pembangunan.

Tips: Karena kita ingin memastikan bahwa rapat ini tetap singkat, kita berdiri. Orang biasanya lelah setelah 15 menit berdiri, yang sempurna! Jika Anda menemukan rekan kerja mencari tempat untuk duduk dan beristirahat, rapat Anda kemungkinan sudah terlalu lama.

Dalam pertemuan ini, setiap anggota tim harus menjawab tiga pertanyaan:

  • Apa yang kamu lakukan kemarin? - Jawaban singkat diharapkan - maksimal 2-3 kalimat.
  • Apa rencanamu hari ini? - Jenis jawaban singkat yang sama, hal-hal seperti "Saya akan mengerjakan kisah ini hari ini."
  • Apakah ada masalah dengan proses Anda? Jika ya, apa? Bisakah mereka cepat dipecahkan? Ini harus menjadi jawaban yang menyoroti masalah dan solusi, jika diketahui. Tidak ada diskusi terperinci yang harus dilakukan, sementara pertemuan ini berlangsung. Master scrum harus memperhatikan masalah, dan bekerja untuk menyelesaikannya bersama dengan tim, setelah pertemuan ditunda.

Memecahkan masalah dan hambatan di jalan pengembang harus menjadi prioritas utama bagi tim, sehingga mereka dapat melanjutkan pengembangan mereka sesegera mungkin. Seringkali, orang yang memiliki masalah mampu menyelesaikannya tepat waktu. Di lain waktu, dia membutuhkan bantuan seorang rekan tim. Dan di lain waktu, masalahnya bisa sangat serius sehingga tim harus menghentikan pengembangan dan berkonsentrasi secara eksklusif untuk menyelesaikan satu hal yang mencegah mereka melanjutkan pekerjaan mereka.

Saya ingat tim saya menghadapi rintangan besar ini pada beberapa kesempatan yang berbeda. Ada tugas dan cerita, yang tampaknya cukup jelas di situs pertama, tetapi, setelah sepasang atau programmer tunggal memiliki kesempatan untuk menggali masalah, yang jelas menjadi membingungkan dan salah. Kita menemukan beberapa kali bahwa perpustakaan pihak ketiga tidak dapat memberi fungsi yang diperlukan, dan akhirnya memusatkan semua upaya untuk menemukan perpustakaan lain yang lebih mampu - atau bahkan menerapkan solusi sendiri.

Sebagian besar proyek ditulis dalam PHP. Pada titik tertentu, kita harus menghubungkan proyek dengan VMWare. Meninjau pustaka resmi untuk VMWare API, dan menemukan ada versi Java dan Perl. Ada juga opsi Ruby tidak resmi. Kita yakin bahwa kita bisa menggunakan salah satunya, dan cukup melakukan beberapa exec() panggilan dari PHP untuk menangkap output sebagai string. Seperti yang diduga, parsing dari sana pastilah sepotong kue.

Ternyata ini hampir mustahil. Perpustakaan API tidak berfungsi sebagaimana yang diharapkan. Beberapa ditinggalkan atau tidak lengkap, dan hampir tidak mungkin untuk menguraikan output. Pada akhirnya, kita terpaksa melakukan sesuatu yang belum pernah dilakukan sebelumnya: mengimplementasikan perpustakaan API VMWare di PHP. Sayangnya, tidak ada cara lain yang dapat diterima untuk melakukannya.

Masalah ini sangat besar; itu mengatur kembali rencana awal oleh minggu! Tentu saja, pemilik produk kita segera diberitahu, dan, bersama dengan dia, kita merencanakan jadwal baru, dan mengembangkan cerita baru, yang termasuk pembuatan perpustakaan API ini.

Lebih sering daripada tidak, masalah Anda akan jauh lebih kecil. Orang mungkin terjebak dengan logika yang lebih canggih, tetapi, berkali-kali, pada pagi berikutnya, mereka sudah memiliki ide dan solusi. Di lain waktu, mereka hanya akan berada di jalan yang salah, dan rekan tim perlu membantu mereka kembali ke jalurnya. Ini mewakili masalah khas Anda.


Kesimpulan

Kita sampai pada kesimpulan. Setidaknya, ini adalah bagaimana tim saya memulai dengan Scrum. Beberapa aturan sangat berguna; yang lainnya kurang begitu. Lebih lanjut, beberapa aturan hanya berguna untuk waktu yang singkat, sementara yang lain masih dihormati secara religius oleh tim kami.

Saya hanya dapat merekomendasikan agar Anda merangkul proses gesit, mencoba Scrum, dan membentuk kesimpulan Anda sendiri. Saya yakin Anda akan menemukan banyak potongan untuk diadopsi untuk tim Anda. Bersikaplah gesit, sesuaikan dengan gaya pekerjaan Anda, untuk proyek dan kepribadian Anda, dan jangan takut menambahkan aturan kustom Anda sendiri.

Setelah semua, Agile mengacu pada adaptasi, tidak membabi buta mengikuti seperangkat aturan yang telah ditentukan!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.