Bagaimana kami melakukan SCRUM

Impian yang mengerikan dari tim pengembang adalah ketika Anda perlu "menyelam" ke area subjek yang tidak diketahui dan "memperkirakan-perkiraan" ide setengah matang sebelum memulai pengembangan. Dalam hal ini, Anda harus secara harfiah " menandatangani darah " untuk hasil pada waktu yang ditentukan untuk jumlah uang tetap.

Bahkan, memberikan penilaian akurat tentang persyaratan yang tidak akurat tidak realistis. Cara khas dalam manajemen proyek adalah menyusun TOR terperinci sebelum memulai pengembangan. Dan kemudian mengimplementasikan semua fungsi dalam satu bagian besar. Tetapi pendekatan " air terjun " seperti itu mengancam dengan risiko lain: meluncurkan proyek dengan gaya " big bang " - ketika Anda mendapatkan hasil pertama di akhir proyek. Dan itu bisa sangat jauh dari tujuan bisnis nyata dan kebutuhan pengguna.

Mengapa mengambil risiko seperti itu jika Anda bisa menempuh cara yang sama sekali berbeda?

Kenapa SCRUM

Saat membiasakan diri dengan proyek, ada pemahaman "kami tahu bahwa kami tidak tahu ini" dan bahkan "kami tidak tahu di mana batas-batas apa yang tidak kami ketahui" membantu SCRUM



Spesifik SCRUM dapat menakut-nakuti, jika Anda belum pernah bekerja dengan kerangka kerja ini, oleh fakta bahwa pada awalnya panjang jalan yang harus Anda tempuh untuk mendapatkan proyek yang berfungsi dan kepuasan 100% belum diketahui.

Sulit bagi pelanggan - ia TIDAK bisa menyiapkan rencana strategis untuk pengembangan proyek dengan tanggal rilis yang andal. Yang tidak diketahui itu menakutkan, terutama ketika Anda harus membayar dengan cara ini sekarang.

Tetapi ada beberapa kelebihannya : pelanggan pada awalnya tidak harus menjelaskan secara terperinci dan dengan cermat semua fungsi dan fitur sistem masa depan yang besar. Dan itu juga dapat mengubah prioritas kapan saja dan menyesuaikan dengan pasar eksternal yang kompetitif.

Ngomong-ngomong, ini juga merupakan kasus dalam kasus ini , tetapi segera Anda akan melihat bagaimana kami meluncur keluar dari situasi yang sulit, ketika bersama-sama dengan pelanggan kami menemukan apa dan bagaimana menerapkan sudah di sepanjang jalan.

SCRUM bergantung pada konsep langkah-langkah kecil: merilis versi yang menjalankan perangkat lunak secara teratur, sesering mungkin dan sebelumnya. Setiap iterasi adalah tahap pengembangan mikro, segera diverifikasi oleh praktik.

Ini berarti bahwa setelah iterasi pertama, pelanggan menerima cukup berguna, meskipun kecil, tetapi berfungsi, memeriksanya dalam praktik, segera memberikan umpan balik.



Lihat bagaimana kami mengorganisasikan semua pekerjaan: keputusan kunci penting - apa nilai berikutnya untuk memberikan bisnis - tim mengambil sebelum setiap iterasi baru, sebagai akibatnya, sistem berkembang di sepanjang jalur optimal yang kritis sampai menjadi yang paling tepat untuk bisnis. Pelanggan di sini adalah bagian dari tim. Baik kontraktor maupun pelanggan bertanggung jawab atas keberhasilan pengembangan. Mereka berada di satu sisi barikade.

Itu yang terjadi dengan kita, mari kita lihat?

Kami ingin berbicara tentang cara kami mengadaptasi kerangka SCRUM klasik untuk bekerja pada sistem kontrol otomatis untuk A + Academy of Modern Education - ini adalah pusat pendidikan modern di Kiev, yang mencakup sekolah, taman kanak-kanak, pusat pengembangan awal, musik, tari dan olah raga sekolah, studio seni dan pusat studi bahasa asing. Secara total, lebih dari seribu anak menghadiri hampir 150 kursus berbeda di Akademi.

SCRUM adalah kerangka kerja yang membantu menyelesaikan tugas-tugas yang berubah selama proses kerja, agar dapat secara efisien dan kreatif mengirimkan produk ke pelanggan dengan nilai setinggi mungkin

Keuntungan dari SCRUM dan, bagi sebagian orang, kerugiannya adalah ia merupakan kerangka kerja yang sangat ringan. Itu tidak mengandung jawaban untuk semua pertanyaan dan instruksi terperinci untuk anggota tim. Scrum - "sengaja tidak lengkap", dan karena universal ini.

SCRUM perlu disesuaikan dengan setiap proyek tertentu

Bagaimana pelanggan dan kontraktor mulai bekerja di SCRUM?

Untuk bekerja dalam paradigma yang tidak dikenal, terkadang pelanggan harus mengubah kebiasaan berpikir. Untuk berada dalam konteks yang sama dengan pemain. Karena itu, sebelum mengembangkan sistem untuk Akademi, kami mengadakan pelatihan bersama dengan orang-orang dari Scrum Ukraina . Tujuan utamanya adalah untuk mengenal satu sama lain, memahami terminologi, untuk mengetahui semua teknik dalam bentuk permainan, untuk mensimulasikan kegiatan utama, untuk memahami di mana memulai, untuk mendistribusikan peran dan mendaftarkan tanggung jawab.









Selama pelatihan bersama tiga hari, kami, menggunakan apa yang disebut pandangan helikopter , membentuk sistem masa depan dengan pukulan besar dan memperbaikinya pada jalur sementara dalam bentuk Roadmap Proyek.

tampilan helikopter - deskripsi umum atau pendapat tentang suatu situasi, bukan yang rinci


Roadmap Produk Global

Apa kesimpulan kami setelah tahap ini?

1. Pelatihan bersama membantu mengubah pemikiran pelanggan dan tim.
2. Product RoadMap memungkinkan Anda memvisualisasikan rencana pengembangan tingkat tinggi dan secara kasar merencanakan rilis. Penting untuk dipahami bahwa ini adalah "peta jalan langsung" yang akan berubah seiring ditemukannya detail pengembangan baru
3. Perjanjian tentang aturan global permainan diperlukan "di pantai": pemilik produk setelah setiap sprint menerima nilai - sistem kerja yang harus segera digunakan, dan kemudian memberikan umpan balik.

Paragraf ketiga wajib, tanpa itu tidak ada yang akan berhasil. Karena harapan untuk meluncurkan setelah kesiapan penuh abstrak di akhir menuju kekecewaan, di kedua sisi:

• Di pihak pelanggan: "Ini yang kami minta, tapi ini bukan yang kami butuhkan."
• Di pihak penampil: “Kami jelas melakukan apa yang Anda minta. Dan sekarang persyaratan Anda terdengar sangat berbeda bagi kami. Kami setuju untuk mengulang semuanya, tetapi dengan biaya Anda. Secara umum, ada begitu banyak perubahan yang penyelesaiannya akan memakan waktu enam bulan lagi. "

Pemilik produk - pemilik produk bertanggung jawab untuk mencapai nilai maksimum produk sebagai hasil dari pekerjaan yang dilakukan oleh Tim Pengembangan. Satu-satunya orang yang bertanggung jawab untuk pengembangan produk

Semua pengaturan kami dalam daftar pendek.

Langkah # 1: Adaptasi Analisis dan Metodologi Bisnis

Kami memulai pengembangan proyek apa pun dengan analisis bisnis: Anda perlu memahami secara spesifik. Selalu ada banyak proses di perusahaan mana pun, dan tugas kami dalam penelitian ini adalah untuk mengetahui bagaimana peserta dalam sistem berinteraksi satu sama lain sebelum membangun sistem.

Setelah putaran wawancara yang bermasalah dan memproses informasi yang diterima, kami menerima deskripsi area subjek dalam bentuk contoh penggunaan.



Meskipun SCRUM tidak memerlukan spesifikasi pengembangan, fakta bahwa kami memiliki deskripsi bidang subjek yang siap adalah nilai tambah yang besar. Dokumen ini menjadi dasar dari jaminan produk - dasar untuk peluncuran SCRUM. Product backlog - daftar persyaratan, cerita, fungsi, yang dipesan berdasarkan kepentingan. Dengan daftar seperti itu, semuanya dimulai. Selain itu, semua persyaratan dijelaskan dalam bahasa yang dapat dimengerti oleh pelanggan. Elemen dari daftar ini adalah kisah pengguna , "kisah pengguna".

Cerita pengguna adalah deskripsi dari skenario pengguna paling sederhana untuk menggunakan sistem, esensi yang dapat dirumuskan sebagai berikut: "siapa, apa, untuk apa, apa fitur dan batasannya."









Tumpukan produk kami sebanyak 203 cerita, dengan mudah dikelompokkan berdasarkan segmen


Contoh kisah pengguna

Apa kesimpulan kami setelah tahap ini?

1. Sprint kami akan bertahan 2 minggu. Mengapa Sprint pendek nyaman. Mereka memungkinkan tim untuk menjadi "fleksibel" mungkin: siap untuk sering menyesuaikan rencana mereka. Sprint pendek berarti loop umpan balik pendek, yang mengarah ke rilis yang sering. Rilis yang sering = ulasan cepat dari pelanggan = lebih sedikit waktu untuk bekerja ke arah yang salah = pelatihan cepat, peningkatan, dll.
2. Sprint panjang memiliki kelebihan - kurang overhead, seperti perencanaan sprint, demo, dll. Tapi kami memilih yang pendek agar fleksibel dan mengurangi risiko.

Sprint - periode waktu di mana "Ready" dibuat, yaitu, produk yang cocok untuk digunakan dan dirilis

Langkah # 2: perencanaan sprint. Bagaimana kami mengadaptasi perencanaan Sprint

Nilai bisnis pertama kami adalah majalah elektronik. Untuk pengembang yang paling berpengalaman, ini akan tampak utopis: kami memiliki lembar kosong, tidak ada direktori tunggal, antarmuka pengguna, sistem otorisasi, atau entitas bisnis tunggal, dan kami berkomitmen untuk menyediakan salah satu fungsi sistem yang paling kompleks.



Bagaimana itu tadi? Bagi kami, itu perlu untuk mendapatkan 2 hal: tujuan sprint yang dinyatakan dan backlog sprint yang disetujui.

Pemilik produk kami selalu memulai perencanaan sprint dengan deskripsi tentang apa yang perlu dilakukan terlebih dahulu, kisah yang paling signifikan. Setelah itu, tim mengevaluasi biaya tenaga kerja untuk semua cerita pengguna, dimulai dengan yang paling penting. Dalam prosesnya, tim memiliki banyak pertanyaan tentang bagaimana ini seharusnya bekerja.

Perencanaan sprint adalah kegiatan SCRUM yang sangat penting. Setiap orang menyadari tanggung jawab untuk penilaian yang benar, karena:

• ini memungkinkan bisnis untuk memahami fungsionalitas apa yang dapat diharapkan pada akhir sprint. Mari kita menjadi tim yang dapat diprediksi dan “berada di halaman yang sama” dengan pelanggan
• nilai setengah cerita yang direalisasikan adalah nol, oleh karena itu semua cerita yang direncanakan dalam kerangka kerja sprint perlu diputuskan.
• setiap perubahan skor selama sprint diabaikan;

Tujuan dari sprint adalah untuk apa sprint itu. Yang terpenting, tujuannya harus ditunjukkan dalam hal bisnis, bukan teknis. Yaitu, dalam bahasa yang dapat dimengerti bahkan oleh orang-orang di luar tim, dan jaminan Sprint adalah pilihan cerita dari jaminan produk . Ini adalah daftar cerita yang diidentifikasi tim sebagai yang paling penting pada tahap ini dan berkomitmen untuk diselesaikan selama sprint.


Contoh sprint backlog

E-magazine setelah sprint pertama

Penyederhanaan dan asumsi untuk sprint pertama . Dalam sistem - 2 pengguna: guru dan orang tua; satu kelas - 5 "A"; komposisi sebenarnya dari kelas, secara manual dimasukkan langsung melalui query SQL; jadwal saat ini untuk 5 "A", juga dibentuk langsung melalui entri pada tabel.

Cerita pengguna # 1 : guru login ke sistem dan memberikan peringkat untuk setiap mata pelajaran dari jadwal kelas untuk hari itu. Sebuah sistem dengan satu fungsi sederhana namun sudah berfungsi. Sudah di sprint demo, guru mengatakan apa yang harus digunakan dengan mudah dan apa yang tidak, sehingga di sprint berikutnya tim dapat merencanakan koreksi dan memberikan alat yang diperbarui.

Apa nilai nyata memberi: kinerja digital dari kelas nyata, penilaian saat ini, prospek untuk persiapan otomatis laporan bulanan, semester, triwulanan.

Kisah pengguna # 2 : Laporan mingguan kepada orang tua tentang kinerja surat.

Nilai tambah apa: memberi tahu orang tua tentang kinerja saat ini; komentar guru tentang pekerjaan rumah; analitik minimal tapi nyata.

Setelah beberapa sprint, saya memutuskan bahwa ada cukup fungsionalitas bagi para guru untuk bekerja dengan jurnal elektronik. Oleh karena itu, kami menghentikan sebentar pengembangan alat ini dan mengalihkan fokus ke perancang jadwal. Ini normal untuk SCRUM. Saya kembali ke majalah elektronik fokus pengembangan setelah selusin sprint, dan, setelah membuang sebagian fungsi yang disederhanakan, kami membawa jurnal elektronik ke negara yang diperlukan untuk analisis kinerja tahunan. Kami membutuhkan fungsi ini pada waktu itu. Kami telah memperoleh nilai yang cukup dan mengalihkan pengembangan aktif ke bagian-bagian sistem yang lebih tinggi prioritasnya.

Svyatoslav, Pemilik produk

Untuk referensi : untuk memperbaiki versi final (ideal), kami harus kembali ke jurnal elektronik untuk beberapa sprint.


Inilah yang tampak seperti majalah setelah sprint pertama, tetapi sudah mungkin untuk bekerja dengannya.


Versi majalah elektronik ini diterima setelah 12 sprint dan dapat diperlihatkan kepada orang tua.

Contoh nyata lain dari pendekatan SCRUM berulang adalah konstruktor jadwal.

Pelanggan menerima desainer jadwal pertama 2 bulan setelah dimulainya proyek. Itu adalah "editor brutal" untuk pengguna yang sangat maju. Tapi dia mengizinkan kami untuk memperkenalkan jadwal untuk semua kelas lima dan menguji sistem pada jadwal nyata.

Butuh tiga sprint untuk memperbaikinya menjadi "editor visual". Fokus pengembangan telah beralih beberapa kali, tetapi pada awal tahun ajaran sekolah, pelanggan menerima perancang jadwal yang berfungsi penuh, dengan bantuan yang ia perkenalkan dari jadwal dari pertama (A, B, C, D) ke siswa kelas delapan hanya dalam satu jam.

Mari kita ikuti rute "editor brutal untuk admin sungguhan" - "editor visual" - "desainer jadwal"

Dan bagaimana Anda membuat jadwal sebelumnya?

Jadwalnya disusun pada lembar kertas Whatman A1 yang direkatkan secara manual: dicat, disorot dengan spidol berwarna, direkatkan. Kepala sekolah membutuhkan waktu berminggu-minggu dan berbulan-bulan untuk melakukan ini.


Versi pertama editor: "Editor brutal untuk admin" - yang membuat jadwal untuk 2018


Versi kedua, versi yang ditingkatkan, dengan bantuan yang membuat jadwal 2018/2019


Jadwalkan Desainer - Versi Terakhir

Apa kesimpulan kami setelah tahap ini?

1. Setiap sprint harus memiliki tujuan yang jelas.
2. Menyederhanakan fungsi dan kemudian mengembangkannya adalah hal yang normal. Mengapa SCRUM begitu baik: tidak ada cara yang benar dalam pengembangan produk. Ini bukan tutorial dengan tugas dan jawaban yang benar di akhir. Anda selalu dapat mempertimbangkan banyak opsi alternatif dan menjalankannya dalam urutan yang berbeda. Jika pada akhir sprint klien menerima nilai lengkap yang dengannya ia dapat bekerja, menguji, memasukkan data baru, dan ini bergerak maju ke tugas akhir global, ini adalah cara yang benar.
3. Filosofi utama SCRUM: bukan untuk mengejar kode yang indah di awal, tetapi untuk berkonsentrasi memberi pelanggan alat kerja. Oleh karena itu, Anda dapat menghadapi kesalahan dalam pekerjaan, tetapi Anda perlu memahami: cara terbaik untuk mengidentifikasi kesalahan ini adalah dengan berhenti memikirkan kode ideal pada tingkat arsitektur dan desain, dan pertama-tama memberikan prototipe yang berfungsi pada bisnis.
4. Penting selama diskusi untuk membuat perubahan pada cerita pengguna, dan untuk menyimpan dan melampirkan semua artefak ke kartu.

Cara membuat tim mengevaluasi cerita pengguna secara realistis

Tim akan selalu mengevaluasi cerita pengguna secara memadai jika persyaratan terpenuhi: perilaku pengguna nyata dijelaskan secara rinci, batas - batas penggunaan dan asumsi diindikasikan, kriteria penerimaan dicantumkan. Artinya, tim memahami "apa" perlu dilakukan dan kira-kira menyarankan "bagaimana".

Mengapa penting untuk merumuskan "kriteria penerimaan" dan "batas penggunaan" - ini memberikan pemahaman yang sama tentang ruang lingkup pekerjaan untuk cerita dari pemilik produk dan tim.

Skala penilaian, atau SCRUM-poker

Dalam SCRUM, evaluasi cerita dilakukan bukan dalam hitungan jam atau hari, tetapi dalam poin cerita. Ini adalah campuran dari kompleksitas, risiko dan upaya yang harus dihabiskan tim untuk menyelesaikan sebuah cerita. Untuk setiap tim, 1 poin cerita adalah nilai empiris individu, tetapi setiap anggota tim merasakannya.

Perhatikan bahwa urutan nilai pada kartu adalah non-linear. Misalnya, tidak ada antara 13 dan 21. Kenapa begitu



Pertama, ini perlu untuk menghindari munculnya rasa akurasi yang salah untuk peringkat besar. Jika cerita diperkirakan sekitar 17 poin cerita, maka tidak ada gunanya membahas apakah itu harus 15, atau 18, atau 21. Yang perlu kita ketahui adalah sejarah, sulit untuk mengevaluasi. Karena itu, kami memberinya peringkat 21. Kira-kira.

Kedua, orang cenderung melebih-lebihkan kemampuan mereka, dan skalanya tidak memungkinkan banyak kesalahan dengan penilaian waktu dan sumber daya. Misalnya, tim sepakat bahwa 6 poin cerita sudah cukup untuk salah satu tugas. Tetapi jika Anda tidak yakin bahwa 5 sudah cukup, maka lebih baik untuk memilih 8. Ini memungkinkan Anda untuk menetapkan istilah nyata di mana tim akan cocok dengan tepat. Plus, itu membantu untuk memulai dialog antara para peserta, membagikan visi Anda tentang implementasi cerita , menyuarakan risikonya dan mencapai konsensus.

Sangat penting : setiap anggota tim harus memberikan penilaian. Mengapa

• Untuk penilaian yang masuk akal, setiap peserta harus benar-benar memahami apa inti dari cerita ini. Dengan menerima penilaian dari setiap anggota tim, kami memastikan bahwa semua orang tahu tentang apa yang dipertaruhkan. Ini meningkatkan kemungkinan bantuan timbal balik selama sprint. Dan yang paling penting: pertanyaan paling penting pada cerita ini akan muncul sedini mungkin.
• Pandangan yang komprehensif tentang masalah mengarah ke penyebaran penilaian yang luas. Perbedaan pendapat seperti itu paling baik diidentifikasi dan didiskusikan sedini mungkin. Setelah diskusi ketidaksepakatan - evaluasi ulang, pemungutan suara. Biasanya beberapa siklus penilaian sudah cukup untuk memperjelas poin-poin utama dan menciptakan pemahaman bersama.

Kami menunjukkan ini dengan contoh variasi luas dalam perkiraan untuk salah satu cerita. Kisah itu disebut Buzz .

Penting : Selama perencanaan, kami biasanya tidak tahu siapa yang akan melakukan bagian ini atau itu. Implementasi dari kisah pengguna membutuhkan partisipasi spesialis untuk berbagai jenis pekerjaan: arsitektur, front-end, back-end, pengujian, persiapan data nyata. Secara terpisah, ada kelompok kerja seperti desain dan desain antarmuka pengguna.

Bright Case: Buzz

Dalam sistem manajemen sekolah, banyak peristiwa dengan berbagai tingkat signifikansi muncul. Misalnya, seorang siswa menerima nilai; penggantian telah terjadi, dan alih-alih matematika akan ada biologi dengan guru lain; Sebuah insiden yang menjengkelkan telah terjadi dengan siswa dan orang tua harus segera diinformasikan; Guru menulis komentar penting tentang DZ.

Sangat tidak nyaman bagi pengguna untuk mengirim data ini dengan metode standar ke pesan instan atau melalui surat, dan memang kemarin. Plus, pesan dapat berhubungan dengan beberapa orang sekaligus: guru perlu mengirim orang tua bahwa siswa meninggalkan sekolah selama pelajaran. Dalam dokumen asli, aturan-aturan ini dikumpulkan pada 10 halaman


Buzz dalam implementasi akhir

Bright Case: Buzz

, « ».



, story points . , , : - 50, 5 story points. , . , . , .

1. , , QA UX .
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

Rapat SCRUM harian, atau stand-up, dan seluruh SCRUM adalah cerita tentang komunikasi yang efektif yang membantu menghemat waktu dan upaya tim. Ini bukan hanya "pertemuan" dan "percakapan". Mereka tidak menyita waktu yang bisa dihabiskan untuk bekerja, tetapi membantu mengoptimalkan upaya. Salah satu prinsip SCRUM adalah: "Orang dan interaksi lebih penting daripada proses dan alat."



Setiap anggota tim melaporkan secara singkat, menurut daftar periksa yang dirancang khusus, apa yang dia lakukan, masalah apa yang dia hadapi, apa yang akan dia lakukan selanjutnya. Seseorang tidak dibiarkan sendirian dengan masalah, mereka dengan cepat dibantu untuk menyelesaikannya dengan cara yang paling efektif. Jadi, seorang insinyur tidak menghabiskan waktu untuk upaya yang gagal, setelah itu Anda mungkin harus mengulanginya dari awal, sehingga menghemat sumber daya seluruh tim.

:

- , . .

.

, . : - , .

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. Penting untuk menggeser penekanan dan memahami bahwa SCRUM harian diperlukan untuk komunikasi, dan bukan untuk administrasi.
3. Setiap sprint berikutnya harus mempertimbangkan pengalaman yang sebelumnya.

Bagaimana melakukan pertemuan SCRUM harian

Langkah nomor 4: Bagaimana kami melakukan demonstrasi hasil. Adaptasi kami terhadap sprint demo

Pengembang bergantian menunjukkan fungsionalitas baru secara langsung pada data nyata. Fokusnya adalah pada APA yang telah kita lakukan, dan bukan BAGAIMANA kita melakukannya. Secara umum, kami terus berupaya untuk membuat demo kami berorientasi bisnis, tanpa menyebutkan detail teknis.

Cara mengetahui apakah suatu solusi cocok untuk pelanggan

Di sini sekali lagi tujuan sprint muncul . Demo kami sering dihadiri oleh guru yang diundang secara khusus dan kepala sekolah yang tidak merencanakan. Mereka tahu tentang produk hanya secara umum. Kami selalu menyambut bahwa setelah setiap cerita diperlihatkan, pelanggan sendiri mencoba melakukan sesuatu dalam sistem. Kemudian pengguna akhir memeriksa setiap item dari kriteria penerimaan. Dia mengatakan apa yang cocok dan apa yang tidak, aspek apa yang bisa diperbaiki. Dan - untuk setiap kisah pengguna yang direncanakan untuk sprint ini.





Kesimpulan apa yang kami ambil dari metodologi untuk menunjukkan hasilnya

1. Komposisi wajib untuk demo: pemilik produk, ahli scrum, perwakilan pelanggan, dan pengguna akhir yang akan bekerja dengan alat, tim.
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

— sprint demo. , - . , .





— . . , , 5 story points, , 13story points , , — - . — .

: . Scrum Master sprint backlog, . , , — — . , . . , , :

• Ketika seorang pengembang membuat front-end dan kami mulai menerapkannya, perlu bahwa desainer 100% dapat diakses.
• Diskusikan dengan PO pencantuman jam metodologis.
• Dalam ergonomi, penting untuk mendapatkan dokumentasi terbanyak.
• Utang teknis tidak boleh diakumulasikan, selaraskan 10% untuk cerita teknis dengan PO.
• Harus ada spesialis yang akan menyelesaikan masalah teknis saat mereka muncul.
• Sebelum setiap perencanaan sprint, sangat penting untuk melakukan perawatan sprint.

“Setelah tim bertukar pikiran tentang semua stiker yang bermasalah, saya akan melakukan“ pemilihan tempat ”: setiap anggota tim memiliki tiga suara (tiga titik penanda pada stiker). Dia dapat memberikan semua suaranya sekaligus untuk satu masalah, atau dia dapat mendistribusikan secara berbeda. Berdasarkan pemilihan tim ini, kami memilih 2-3 perangkat tambahan yang kami fokuskan di sprint berikutnya. Dan di awal retrospektif berikutnya, kami akan memeriksa apa yang terjadi. Jadi bisa dikatakan, "memeriksa pekerjaan rumah" :) "

Pavel Kamyshov , Pelatih Agile

Ya, SCRUM membutuhkan keterlibatan aktif semua anggota tim. Untuk kegiatan seperti perawatan, perencanaan, SCRUM harian, kami membutuhkan sekitar 12% dari waktu yang dibayarkan - ini adalah semacam harga untuk transparansi, kepastian dan pengurangan risiko.

Satu minggu kerja dapat menghemat satu jam perencanaan.

Pavel Kamyshov , Pelatih Agile Scrum Ukraina

12% banyak, tapi itu sepadan, karena dalam "air terjun" klasik harga menggunakan metodologi adalah peran yang terpisah untuk manajer proyek. Rata-rata, sekitar 15% dari biaya pengembangan dihabiskan untuk manajemen di segmen pasar kami.

Kesimpulan apa yang kami ambil dari metodologi retrospektif

1. Bagi kami, retrospektif adalah peristiwa terpenting kedua di SCRUM setelah perencanaan sprint.
2. Setiap anggota tim berbicara sehingga semua orang berada di bidang info yang sama.
3. Setiap perubahan memiliki harga. Anda harus setuju dengan PO untuk memasukkan cerita teknis dan jam metodologi dalam tumpukan sprint.
4. Jam metodologis dibayar oleh pelanggan.

Retrospektif Sprint adalah kesempatan bagi tim untuk melakukan inspeksi yang ditujukan pada diri mereka sendiri dan membuat rencana untuk meningkatkan kerja tim di Sprint berikutnya.

Langkah nomor 6: Bagaimana kami mengadaptasi perbaikan jaminan simpanan produk, atau Perawatan

Banyak kolega yang akrab dengan spesifikasi TI meragukan: bagaimana bisa begitu jelas bagi tim selama perencanaan sprint sehingga siap untuk memberikan penilaian untuk semua cerita pengguna.



Ya, memang, tanpa persiapan koherensi seperti itu tidak akan berhasil. Agar ini bekerja dengan cara ini, ada aktivitas SCRUM khusus: penyempurnaan jaminan simpanan produk. Untuk melaksanakannya, Anda perlu meminta pemilik produk untuk memberikan horison perencanaan: menguraikan cerita apa yang bisa menjadi kandidat untuk sprint berikutnya. Jika ada cerita di antara mereka yang membutuhkan studi mendalam atau kompetensi khusus yang tidak dimiliki tim, pertemuan disebut - perawatan / pra-perencanaan.


Hasil perawatan

Pemilik produk kami sangat kompeten, jadi kami selalu memiliki cakrawala visi yang memadai tentang bagaimana sistem akan berkembang, dan secara teratur melakukan penyempurnaan. Memang, transparansi adalah salah satu prinsip dasar SCRUM.


Itu terlihat seperti rencana perawatan

Kesimpulan apa yang telah kami buat tentang metodologi untuk penyempurnaan

1. Ini adalah acara penting yang memungkinkan kita untuk mengklarifikasi apa yang tidak kita ketahui, kompetensi apa yang kurang. Jadi, setelah diputuskan untuk menarik pengembang-konsultan pihak ketiga dalam masalah-masalah spesifik, solusinya tidak kita miliki saat itu.
2. Diskusi ini sangat efektif bagi kami, kami mempertimbangkan banyak alternatif dan opsi, yang memungkinkan kami untuk mengingat masalahnya, dan untuk perencanaan sprint, cerita yang paling rumit sudah “ditata”.
3. Masalah yang kompleks dan tampaknya tidak dapat diselesaikan menemukan solusi yang jelas. Terkadang cukup hanya dengan membeli perpustakaan daripada mengembangkan sendiri situs yang kompleks.

Penyempurnaan adalah dasar untuk siap memberikan penilaian terhadap kompleksitas cerita dalam berbagai kondisi implementasi selama perencanaan sprint, karena kita perlu memahami volume dan kompleksitasnya.

Gagal

Ya, kami terus terang senang dengan pengembangan metodologi SCRUM, tetapi ini tidak berarti bahwa semuanya berjalan lancar. Berikut adalah tiga poin di mana kami akan meletakkan sedotan jika kami tahu sebelumnya bahwa itu akan berjalan seperti itu.

Kerjakan pola-pola yang umum

Dalam salah satu retrospektif, kami menganalisis secara rinci alasan penyimpangan abnormal "produktivitas nyata" tim dalam semua cerita yang melibatkan desainer. Kinerja aktual biasanya dihitung dengan menggunakan rumus: kinerja yang diproyeksikan / kinerja aktual.

Kami menemukan dari kebiasaan bahwa mereka mengatur ke dalam air terjun berurutan yang akrab.

Akibatnya: tugas dilakukan secara berurutan, pengembang menghabiskan waktu untuk beralih berurutan pada tahap yang berbeda dengan penundaan yang disebabkan oleh kebutuhan untuk menyelesaikan tugas yang sudah dimulai.

Kesimpulan: Mungkin kisah yang paling menyakitkan bagi kita, yang paling membahayakan dan tidak segera diungkapkan. Penting untuk secara teratur memeriksa apakah semua anggota tim telah beralih untuk bekerja sesuai dengan standar baru.

Kerja ekstra pada fungsi yang tidak perlu

Pada sprint kedua, pemilik produk menyerah pada pendapat salah satu guru kepala, yang percaya bahwa "jurnal kurator" adalah fungsi yang sangat penting. Kami mengambil cerita ini dalam sprint, menghabiskan upaya di atasnya.

Mengapa terjadi kesalahan: alat ini hanya dapat diuji pada tahap selanjutnya, karena memerlukan akumulasi data, yang pada saat itu tidak ada.

Akibatnya: tidak diuji, tidak digunakan, tidak dikembangkan. Fungsi-fungsi yang diperlukan dipecahkan secara berbeda dan sama sekali tidak dengan cara yang dipikirkan kepala sekolah, melalui alat yang sama sekali berbeda. Kesimpulan: mulai bekerja hanya apa yang Anda akan segera mulai gunakan.

Setara dengan Pengguna Lanjutan

Pada satu tahap, kami mengambil cerita dengan "editor pengganti" ke dalam pengembangan, di mana seorang guru, seorang pengguna komputer yang sangat berpengalaman, berpartisipasi. Sebagai hasilnya, kami memiliki alat yang hebat, tetapi itu tidak dapat digunakan oleh guru sekolah biasa yang tidak begitu mahir.

Kesimpulan: konfirmasikan cerita di pelanggan reguler.

Kesimpulan umum

Kesimpulan nomor 1

Fleksibilitas pro: SCRUM memungkinkan Anda menjadi tim yang efektif

Hasil dari setiap sprint tergantung pada tugas pengantar, efisiensi, koordinasi, tanggung jawab tim, dan umpan balik kualitas.

Masukan diberikan oleh pemilik produk. Dia juga bertanggung jawab untuk konteks di mana fungsi akan digunakan, kualitas perumusan persyaratan, memberikan kedalaman detail yang cukup.

SCRUM mengharuskan tim untuk menyelesaikan pekerjaan yang benar-benar nyata, yang memungkinkan mereka untuk mendapatkan nilai, yaitu alat yang dapat diberikan kepada pengguna pada akhir setiap iterasi. Ini membantu untuk melihat solusi di tempat kerja dan pada tahap awal untuk memahami apa yang perlu diubah untuk melanjutkan.

Kesimpulan nomor 2

Tentang penggunaan sumber daya yang paling efisien

SCRUM - suatu bentuk organisasi kerja yang bermanfaat bagi pelanggan dan kontraktor. Apa?
Bekerja dengan iterasi sudah di tahap awal memungkinkan Anda untuk memahami apa yang salah, yang berarti bahwa Anda perlu melakukan penyesuaian dalam waktu. Persiapan untuk setiap sprint dan spesifikasi organisasinya membantu setiap kali hanya melakukan apa yang dibutuhkan pelanggan dan tidak menyingkir. Dan itu memberikan EFISIENSI yang luar biasa dari sumber daya yang dihabiskan, waktu dan upaya.
Pada tahap awal, pelanggan menerima bagian kerja dari sistem: setelah sprint pertama, ia mengambil fungsionalitas yang telah ia lakukan dalam pekerjaan dan mengujinya dalam praktik.

SCRUM - ketika kedua belah pihak diasuransikan terhadap risiko

Lihat bagaimana tanggung jawab dibagi antara pelanggan dan kontraktor
Barikade menghilang, di kedua sisi mana kontraktor dan pelanggan berada dalam manajemen proyek klasik. Pada prinsipnya, posisi pelanggan dan kontraktor menghilang, tim tetap ada. Dan tidak ada syarat untuk kemungkinan konfrontasi.

PELANGGAN

Pelanggan hanya membayar jika semua tujuan sprint telah tercapai. Jika alat tidak dikembangkan sehingga pelanggan dapat menjalankannya besok, sprint tidak masuk hitungan.

Pelanggan membayar jumlah tetap untuk setiap sprint, dan membuat bisnisnya selangkah lebih efisien

Pemain

Kontraktor tertarik untuk menyiapkan alat baru, nilai baru bagi pelanggan selama setiap sprint, karena ini akan memberikan umpan balik dan informasi / pengalaman baru. Yang dapat digunakan untuk pengembangan produk lebih lanjut.

Setiap sprint meningkatkan tingkat kompetensi pemain, mempercepatnya dalam implementasi proyek.

Secara total, hanya dalam 7 bulan, kami membuat sistem yang berfungsi dan benar-benar memuaskan bagi pelanggan, diuji olehnya dalam praktik dan mencerminkan semua keinginan, dan tidak memberikan sistem yang dirancang secara teoritis sesuai dengan spesifikasi teknis, yang perlu diselesaikan beberapa bulan lagi, karena praktiknya mau tidak mau akan membuat koreksi sendiri.

Secara global, kasus ini adalah tentang teknik manajemen proyek yang dipilih dengan benar dalam kondisi tingkat ketidakpastian yang tinggi dan waktu yang terbatas sebelum diluncurkan.

Dengan pelanggan yang begitu menuntut, dengan standar kualitas tinggi, kadang-kadang sangat sulit bagi kami, tetapi pada saat yang sama sangat menarik. Tantangan-tantangan yang kita atasi, kesalahan yang dibuat, namun, dalam waktu, sadar dan dikoreksi, kesimpulan yang dibuat, selamanya mengubah budaya di tim kami

Mungkin untuk waktu yang lama semua orang tertarik untuk mengetahui tentang produk itu sendiri, yang ternyata.

Pelanggan menerima produk unggulan: seperangkat alat untuk sekolah modern yang dapat dengan cepat mengubahnya menjadi sekolah masa depan