Apa artinya menjadi gesit?

Kami memiliki proyek yang semua orang katakan akan kami lakukan dengan gesit tetapi saya ragu kami telah memahami dengan jelas apa itu gesit.

Dalam proyek-proyek sebelumnya, kami mengadakan pertemuan perencanaan, kemudian menetapkan log produk kembali dan mengalokasikan pekerjaan untuk pengembang dalam sprint 2 hingga 3 minggu. Setiap pagi kami mengadakan rapat scrum (yang tampaknya berlangsung selama 1/2 jam setiap kali) dan setiap pengembang melanjutkannya setelah itu. Hampir tidak ada yang menulis tes apa pun sampai pada akhir sprint dan pekerjaan yang tidak selesai ditambahkan ke sprint berikutnya.

Pengembang hampir tidak berbicara satu sama lain dan tidak ada TDD yang terlibat dalam pengembangan. Bahkan sebagian besar pengembang memiliki spesifikasi di awal dan baru saja menggunakannya selama 2 atau 3 minggu sprint diatur. Nyaris tidak ada komunikasi dengan klien / pemegang pasak.

QA terlibat biasanya beberapa bulan kemudian dan saat itu kami menemukan persyaratan yang hilang yang selanjutnya menambah jumlah pekerjaan yang harus kami lakukan. Jelas tidak ada loop umpan balik.

Jadi pertanyaan saya adalah, di mana kami salah dan bagaimana saya bisa mencegah tim melakukan kesalahan yang sama.

agile

— JD01
sumber

Sepertinya duplikat dari programmers.stackexchange.com/questions/15928/... Itu suara seperti kalian tidak benar-benar tahu apa yang harus dilakukan dan tidak memiliki manajemen nyata untuk menegakkan proses

— sylvanaar

Ya saya setuju dengan Anda 100%. Manajer saya membaca sebuah buku tentang gesit dan baru saja melakukannya (walaupun sangat buruk). Saya menggunakan TDD di sisi server proyek tetapi yang lain tidak ingin mempelajarinya atau melihat manfaatnya. Kami memiliki kerangka kerja (di sisi klien) yang berlangsung selamanya dan pengembang terus berdebat bahwa ia hanya perlu melanjutkannya (tanpa campur tangan).

— JD01

Meskipun judulnya tampaknya merupakan duplikat, saya pikir pertanyaan ini sangat membantu karena banyak tim membaca penjelasan "generik" tentang apa yang tangkas (dan bahkan mengambil kelas pelatihan dan menyewa konsultan) dan kemudian mengalami masalah yang sama persis seperti JD01's tim tetap. Jadi untuk memasukkan pertanyaan ke dalam konteks tim khusus ini, mungkin menjelaskan masalah dan solusi spesifik yang tidak akan dibahas oleh pertanyaan umum lainnya.

— DXM

Jawaban:

Apa yang Anda gambarkan bukanlah Agile menurut definisi (Agile Manifesto) melainkan Air Terjun dengan pertemuan status harian. Agile berarti mudah beradaptasi dengan perubahan, jika tidak ada umpan balik interaktif dengan pemilik produk dan dengan demikian pelanggan, lalu perubahan apa yang terjadi?

Agile adalah tentang kegagalan yang cepat, melalui komunikasi yang konstan dengan pemilik produk / pelanggan. Lebih baik gagal lebih cepat daripada nanti, lebih sedikit pekerjaan yang dilakukan, dan lebih sedikit "hilang". Dan Anda tidak terjebak dengan argumen, bahwa "kita tidak punya waktu untuk melakukannya dengan benar, karena kita menghabiskan begitu banyak waktu melakukan kesalahan, kita hanya perlu melanjutkan jalan yang sama, meskipun itu mengarah pada kegagalan ".

Kedengarannya seperti manajemen Anda melakukan "SCRUM, tapi ..." di mana "tapi" adalah di mana mereka membuang semua hal-hal SCRUM yang tidak mereka pahami atau setujui dan hanya melakukan hal-hal dengan cara yang sama seperti air terjun serampangan seperti biasa, tetapi dengan nama kata kunci baru yang mengilap untuk semuanya.

Dalam SCRUM, pendirian harian BUKAN tentang memberikan status kepada manajemen, itu adalah untuk memaksa interaksi pengembang, sehingga Anda tahu apa yang dilakukan oleh sesama anggota tim Anda dan dapat saling membantu dan tidak menduplikasi pekerjaan. Jika dibutuhkan lebih dari 45 detik per orang, Anda salah melakukannya. Ini adalah tentang transparansi untuk tim, jika seseorang memberikan status yang sama beberapa hari untuk sesuatu yang seharusnya bernilai satu hari kerja, tim dapat menyelesaikan masalah orang tersebut lebih cepat daripada nanti.

Jika Anda tidak menguji satu sama lain kode seperti yang tertulis, maka Anda tidak melakukannya dengan benar. Pengujian harus tertanam ke dalam proses bukan setelah pikiran. QA harus dimasukkan dalam sesi perencanaan dan memberikan perkiraan pada berapa lama hal-hal akan dilakukan untuk menguji.

Jika Anda tidak memenuhi komitmen Sprint dan membalikkan keadaan, Anda tidak melakukannya dengan benar. Sprint adalah tentang komitmen jika Anda terlalu banyak melakukan pekerjaan, berhenti melakukan itu, tidak ada cara Anda dapat memperkenalkan prediktabilitas atau pengulangan jika Anda tidak dapat secara akurat berkomitmen pada hasil kerja.

Terima kasih Jarrod atas jawaban Anda. Haruskah TDD terpisah tangkas? Sulit membuat pengembang berpikir seperti ini. Pada akhirnya seperti yang saya sebutkan mereka melakukan beberapa tes pada akhirnya (jika mereka ingat) dan mengatakan itu adalah TDD. Saya setuju dengan semua yang Anda katakan. Pengulangan umpan balik hampir tidak ada karena manajer saya merasa itu mengganggu "kerangka kerja" yang membutuhkan berbulan-bulan dan berbulan-bulan untuk benar. Pada saat itu kami terjebak mengimplementasikan fungsi yang tidak memenuhi persyaratan pelanggan.

— JD01

TDD adalah herring merah, saya tidak setuju dengan itu sebagai agama secara pribadi, apa gunanya tes untuk kode yang tidak memenuhi kebutuhan pelanggan. Dan karena pengujian harus tertanam dan tidak ada yang dikirim dan didemokan yang tidak diuji, TDD sebagai mantra tidak berguna. Jika tidak berhasil, Anda tidak memperagakannya. Jika Anda tidak melakukan demo, pemilik produk / pelanggan tidak dapat menerimanya.

Saya mulai melakukan banyak TDD tetapi sekarang beralih ke BDD yang lebih sesuai dengan kebutuhan pelanggan sebagai tes penerimaan. Meskipun saya merasa bahwa TDD membantu menciptakan desain, saya tidak akan melihat sebaliknya selain memberikan tes.

— JD01

Alasan utama TDD adalah untuk memungkinkan refactoring terus menerus, mengurangi tingkat akumulasi utang teknis. Jika ada kode yang Anda takut untuk diubah karena pengujian ulang akan terlalu mahal, proyek akan menemui akhir yang prematur.

— kevin cline

Saya sudah mendengar banyak orang mengabarkan TDD, saya hanya belum pernah melihatnya dalam praktek. Secara pribadi otak saya tidak berfungsi seperti itu. Saya cenderung memiliki gagasan umum yang baik tentang apa yang saya tulis, tetapi ketika saya menulis, saya menyeimbangkan kembali dan memindahkan berbagai hal. Menulis tes pertama tidak mungkin bagi saya. Saya memang menulis unit test, biasanya sebagai bagian dari penulisan kode, tetapi mereka ditulis saat saya menulis kode, bukan sebelumnya.

— DaveG

Jarrod memberikan jawaban yang bagus (+1 untuk itu) dan saya ingin sedikit memperluasnya.

Agile bukan hanya tentang kegagalan yang cepat dan umpan balik antara pemilik produk (pelanggan) dan tim; ini adalah tentang umpan balik cepat antara semua pemangku kepentingan yang terlibat. Menjadi benar-benar gesit (dan ini langsung dari manifesto ) adalah mengakui bahwa proses itu ada hanya untuk membantu pengembang dalam memberikan produk yang lebih baik. Orang-orang di atas proses berarti bahwa begitu tim mengenali proses Anda saat ini tidak berhasil, Anda mengubahnya dan membuatnya bekerja.

"Scrum tapi ..." juga merupakan masalah, tetapi ada dua sisi pada koin ini. Jika Anda melihat manifesto Anda akan melihat bahwa ini tentang tim dan membuat alat / proses bekerja untuk Anda. Tidak ada dua tim yang sama dan karenanya masing-masing akan beroperasi sedikit berbeda dan itu tidak masalah. Anda tentu bisa, mengambil seluruh metodologi Scrum dan mencoba mengikutinya ke surat dan melihat apakah itu bekerja untuk tim Anda.

Alternatif lain adalah alih-alih mendorong proses lain ke dalam tim dan membuat semua orang mengikuti apa yang disarankan Scrum untuk Anda lakukan, cobalah pendekatan gesit : Berkomunikasi dengan tim dan lihat apakah bersama-sama Anda dapat mengidentifikasi area masalah dan solusi untuk masing-masing. Kemudian secara bertahap memperkenalkan perubahan dalam cara Anda bekerja sehingga masalah ditangani.

Mungkin butuh beberapa saat, tapi ...

Anda akan memperbaiki masalah terbesar terlebih dahulu yang akan memiliki dampak terbesar pada kemampuan tim Anda untuk mengirimkan produk
Dengan mengidentifikasi masalah langsung dan berpartisipasi dalam memberikan solusi, anggota tim Anda akan memahami mengapa praktik tertentu itu penting dan tidak akan begitu saja dilakukan karena mereka disuruh melakukannya.

Jika kita menggambar analogi antara Scrum dan pola desain, bekerja dengan cara yang saya usulkan akan mirip dengan pengkodean menjadi pola, di mana Anda menyimpan kode sesederhana mungkin dan hanya menyatu pada pola desain bila diperlukan. Berbeda dengan hanya memilih pola desain dan menggulungnya (yaitu memilih secara acak Scrum dan semua prosesnya sebagai satu set), yang terkadang membuat kode lebih kompleks dan lebih sulit untuk dipelihara daripada seharusnya.

Kunci untuk memahami adalah lincah bukan tentang datang dengan proses baru untuk melakukan sesuatu; ini tentang perubahan terus menerus dan penyesuaian konstan untuk proses / praktik yang ada.

— DXM
sumber

to the downvoter: care to elaborate? Apakah saya mengacak-acak beberapa bulu karena saya katakan jangan membabi buta mengadopsi Scrum atau itu sesuatu yang lain?

— DXM

ya konyol Saya akan memberi +1 untuk info terperinci Anda.

— Michael Durrant

+1 untuk " Kunci untuk memahami adalah gesit bukan tentang membuat proses baru untuk melakukan sesuatu; ini tentang perubahan terus-menerus dan penyesuaian konstan untuk proses / praktik yang ada. "

— David 'the botak jahe'

-2

jika tim (dan manajemennya) benar-benar ingin "gesit," mereka harus mulai dengan membaca dan berdiskusi sebagai tim Manifesto Agile dan para kepala sekolahnya. Kemudian pilih salah satu metodologi lincah yang telah dibuat ( Scrum , misalnya), dapatkan pelatihan di dalamnya, dan mulai dengan mengikuti itu. Saya akan merekomendasikan mengikuti cukup dekat untuk sementara waktu sebelum memodifikasinya, tapi itu hanya saya.

Mereka juga harus melihat secara mendalam ke dalam Praktek Teknik yang digunakan untuk mendukung metodologi proyek tangkas tertentu yang dipilih.

— StevenV
sumber

Saya menurunkan suara karena saya pikir ini tidak menjawab pertanyaan awal.

— Bryan Oakley

cukup adil, saya kira. Saya berbicara dengan premis awal OP: "Kami memiliki proyek yang semua orang katakan akan kami lakukan dengan gesit tetapi saya ragu kami telah dengan jelas memahami apa itu gesit." Banyak orang mengatakan bahwa mereka, atau bahwa mereka ingin, "lincah" atau "lincah" tanpa memahami apa Filosofi Agile atau Metodologi yang mendukungnya.

— StevenV

Saya tidak setuju dengan membabi buta mengikuti metodologi tertentu sepenuhnya. Menjadi "sungguh-sungguh" Agile, berarti Anda tidak mengunci diri pada tren atau metodologi tertentu kecuali cocok dengan perusahaan dan tim Anda. Lebih baik menggunakan metodologi sebagai titik awal, dan kemudian setelah Anda mendapatkan pelatihan kecil dan pengalaman yang lebih baik, sesuaikan dengan kebutuhan khusus Anda. Yang lebih penting, jika proyek berikutnya dan pelanggan membutuhkan sesuatu yang sedikit berbeda, sesuaikan metodologi dengan suite. bukan ITU yang benar-benar tangkas.

— S.Robins

mengunjungi kembali jawaban saya, saya setuju dengan S.Robins di atas dan telah memodifikasi jawaban saya untuk mencerminkan hal itu.

— StevenV