Halo, Habr! Nama saya Zhenya. Saya seorang analis sistem di NORBIT dan pemula Scrum-master. Saya telah lama melihat Scrum untuk mempelajari, mencoba, dan mengevaluasi kemampuannya dalam tim analis kami. Dan sekarang, setelah sedikit percakapan yang mengilhami dengan RP, saya menyadari: berhenti berpikir, sekarang saatnya untuk melakukannya.
Dalam artikel ini, saya akan berbicara tentang pengalaman kami mempersiapkan untuk menggunakan Scrum terbatas atas nama master Scrum: apa yang kami lakukan untuk memulai. Pada saat penulisan, sprint ke 15 selesai. Penerbangannya normal!
Saya sering mendengar tentang penggunaan kerangka Scrum di tim yang anggotanya bukan pengembang. Tim dari berbagai keahlian secara aktif bergabung dengan Agile. Saya pikir Scrum awalnya dibuat untuk tim pengembangan siklus penuh, dan karena itu ada sejumlah kesulitan atau poin menarik yang harus Anda perhatikan jika tim berbeda dari referensi yang dipikirkan oleh pencipta. Saya membedakan tim dalam arah keahlian dan tingkat partisipasi dalam siklus pengembangan produk. Arah keahlian, menurut saya, tidak membatasi penggunaan Scrum. Tetapi tingkat partisipasi dalam pengembangan produk dapat membatasi. Beberapa dari mereka dapat melakukan siklus penuh pekerjaan pada produk, bertanggung jawab atas hasil akhir yang tersedia bagi pelanggan - dan menurut pendapat saya, dalam tim seperti itu Anda dapat menggunakan Scrum lengkap. Dan yang lain hanya melakukan sebagian dari siklus penuh, menjadi bagian dari rantai kerja. Dalam hal ini, mungkin ada pertanyaan dan kesulitan dengan Scrum yang lengkap. Situasi desain seperti itu mungkin memerlukan kompromi.
Artikel ini akan fokus pada tim yang bertanggung jawab atas bagian dari siklus pengembangan produk dan persiapan untuk meluncurkan ScrumBut di dalamnya.
Rencana aksi kami untuk peluncuran adalah sebagai berikut:
- untuk mempelajari dan mengevaluasi situasi saat ini dan yang diinginkan
- membangun apa adanya dan menjadi model dalam terminologi ScrumBut,
- menyajikan dan menginspirasi tim
Bagaimana Saya Mempelajari Apa ScrumBut
Pertama saya googled dan dapatkan:
ScrumBut memiliki sintaks tertentu: (ScrumBut) (Reason) (Workaround). ScrumTetapi Contoh: "(Kami menggunakan Scrum, tetapi) (memiliki Scrum Harian setiap hari terlalu banyak overhead,) (jadi kami hanya punya satu per minggu.)" "(Kami menggunakan Scrum, tetapi) (Retrospektif hanya membuang-buang waktu ,) (jadi kami tidak melakukannya.) "
Yaitu ScrumBut adalah Scrum terbatas. Variasi kerangka kerja ini memungkinkan Anda untuk mengambil semua yang Anda butuhkan dari Scrum dan tidak mengambil apa yang, menurut pendapat kami, tidak diperlukan. Tentu saja, ini jalan yang licin, karena Untuk memahami apa yang perlu dan apa yang tidak diperlukan, penting untuk memiliki gagasan tentang Scrum klasik, penting bagi saya untuk memahami mengapa ini termasuk dalam versi lengkap.
Berguna bagi saya di materiel adalah:
- studi literatur: Agile-manifest dari pengembangan perangkat lunak , "metode manajemen proyek revolusioner SCRUM" (Joseph Sutherland), "Agile-team coaching" (Lissa Adkins);
- serangkaian konsultasi yang panjang dan menarik dengan master scrum bersertifikat aktif yang mempraktikkan klasik.
Bagaimana saya menilai situasi saat ini
Untuk mulai dengan, saya mengambil keuntungan dari visi saya dan mengajukan beberapa poin untuk evaluasi oleh manajer.
Mengumpulkan pendapat anggota tim dan mencatatnya.
Kami mendapat dua daftar: apa yang kami miliki di masukan dan apa yang ingin kami dapatkan.
Di sini saya akan membuat daftar konsolidasi dan umum.
Apa yang mereka miliki di pintu masuk
- Sebuah proyek besar untuk pengembangan sistem interpraise.
- Tim pengembang, pendukung, dan analis yang terpisah.
- Tim analis yang keren (sekitar 14 orang).
- Kemampuan untuk bertindak hanya dalam kerangka tim analis.
- Rilis rilis versi sistem.
- Model manajemen siklus hidup perangkat lunak Waterfall.
- Ketidakmungkinan perencanaan yang sulit, karena tugas dari pelanggan datang kapan saja.
- Analis beban kerja yang tidak merata.
- Distribusi fungsional zona pemeriksaan analis.
Apa yang ingin kita dapatkan
- Mampu merespons dengan cepat perubahan bisnis.
- Mempertimbangkan dan memprioritaskan tugas dalam pekerjaan
- Memiliki perkiraan pertumbuhan produk yang layak.
- Sprint pendek dapat memungkinkan Anda untuk melacak, merekam, dan menyelesaikan tugas, dan lebih akurat memprediksi kapan tugas akan dirilis.
- Buat tumpukan tugas untuk analis.
- Pada waktu tertentu, analis tahu apa yang harus dilakukan.
- Bertukar pengalaman dalam memecahkan masalah yang kompleks.
- Untuk membangun kerja tim sedemikian rupa untuk berbagi pengetahuan itu menyenangkan, nyaman dan saling menguntungkan.
- Atur Scrum Anda dengan Black Jack, dll. :)
- Cobalah hal-hal baru, tingkatkan semangat tim. Pria keren. Kenapa tidak
Pemodelan
Pada tahap pemodelan, kami mengalokasikan peran tim: kami mengidentifikasi pemilik produk, anggota tim, dan saya sebagai master scrum, durasi sprint, proses mengisi dan memprioritaskan jaminan simpanan.
Atribut wajib tugas, alur kerja untuk pelacakan, alat pelacakan, penugasan estimasi dalam jam manusia untuk setiap jenis tugas dan jumlah jam per minggu untuk setiap analis ditentukan, dengan mempertimbangkan pemenuhan rencana tim sprint, waktu dan keteraturan dari rapat umum harian dan retrospektif.
Pemilik produk dan orang yang mengatur jaminan adalah kepala sekelompok analis. Diputuskan untuk membuat tim 2-7 orang, memenuhi persyaratan jumlah 7 ± 2. Ini adalah dua tim, yang dibagi secara kondisional sesuai dengan atribut fungsional dari tugas-tugas yang diselesaikan, yang lebih dekat dengan model asli, tetapi lebih jauh dari tujuan yang dimaksudkan - fungsi silang.
Untuk pelacakan, kami memutuskan untuk menggunakan TFS yang ada, di mana lebih mudah untuk menempatkan tugas pada status "Baru", "Dalam Pekerjaan", "Selesai" di papan tulis dan dimungkinkan untuk mengumpulkan statistik kecil pada hasil untuk diskusi pada pertemuan retrospektif di akhir sprint. Papan TFS meniru papan Scrum fisik, tetapi kami juga memiliki papan fisik.
Presentasi
Tahap perencanaan berakhir dengan demonstrasi kepada tim presentasi tentang hasil pemodelan, “Getting Started Together Together”, diskusi dan koreksi atas apa yang tidak mendapat tanggapan dari para lelaki.
Scrum dan ScrumTetapi khususnya adalah kerja tim, koherensi, transparansi, dan penerimaan umum. Itu adalah momen penting dari mana kami memulai dengan inspirasi.
SumberKesimpulan dari persiapan peluncuran
Saat Anda mengerjakan proyek besar, tidak ada cara untuk pergi ke kolam dengan kepala Anda, sehingga Anda tidak dapat melakukannya tanpa perencanaan. Penting untuk memahami bagaimana jadinya dan hasil apa yang akan dihasilkannya, tetapi kami bertemu dengan perlunya dipersiapkan untuk fakta bahwa rencana dalam beberapa aspek akan tetap menjadi rencana. Ketika merencanakan, kami melukis dengan goresan besar, dan sudah pada tahap implementasi kami dapat menambahkan detail yang dibawa tim dan situasi desain.
Tim kami hanya bertanggung jawab untuk bagian dari siklus pengembangan perangkat lunak, sehingga ada kesulitan dengan apa yang harus disebut produk dan apa yang harus diterima sebagai peningkatan. Kami tahu itu harus holistik dan lengkap. Kami sepakat bahwa kami, sebagai bagian dari tim analis, sedang mempersiapkan beberapa jenis dokumen untuk berinteraksi dengan pelanggan dan menciptakan tugas bagi pengembang untuk menumpuknya. Dengan demikian, tugas jatuh ke dalam sprint ke pengembang. Menurut pendapat saya, jalur kompromi seperti itu dapat cocok untuk proyek-proyek di mana masing-masing tim analis, pengembang, penguji, dukungan, dan untuk proyek-proyek di mana jumlah orang memerlukan pemisahan menjadi beberapa tim. Ada juga minus dalam keputusan ini - anggota tim kami tidak dapat memengaruhi waktu ketersediaan fungsionalitas produk, kami hanya dapat memengaruhi kinerja bagian pekerjaan mereka. Ada plus - kelanjutan dari tugas analis untuk pengembang. Keputusan ini memungkinkan kami untuk menghindari upaya untuk menjadi satu tim lintas fungsi (analis = pengembang = penguji, dll.), Yang dalam kasus kami pada tahap ini tidak mungkin dilakukan, sambil mempertahankan siklus pengembangan produk dengan pembiasan kompromi di persimpangan interaksi tim.
Pada tahap presentasi, orang-orang kami dari
NORBIT bereaksi dengan sangat
antusias dan dengan penuh minat. Tetapi saya mengira bahwa respons emosional positif dari tim adalah manfaat dari mengerjakan tujuan dan hubungannya dengan masalah yang mendesak dan jelas.
Langkah-langkah yang dijelaskan di atas (studi teori, pemodelan dan presentasi) melakukan trik: kami mulai dengan sukses.
Tetapi memulai hanyalah langkah pertama. Saya akan memberi tahu Anda apa yang terjadi setelah peluncuran dan hasil apa yang dicapai dalam artikel saya berikutnya.