Menyingkirkan kelincahan nyata dari kata kunci gesit dalam sebuah wawancara [ditutup]


14

Saya telah mewawancarai koperasi (magang berbayar) belakangan ini dan sejumlah besar perusahaan yang telah saya wawancarai mengatakan mereka menggunakan Scrum atau metodologi gesit lainnya (scrum menjadi yang paling populer). Saya tahu bahwa ada toko-toko gesit nyata dan ada tempat-tempat yang mengatakan mereka menggunakan metodologi tangkas tetapi benar-benar melakukan sesuatu yang lain dan menggunakan tangkas sebagai kata kunci.

Pertanyaan saya adalah, apa saja pertanyaan yang bisa saya tanyakan dalam sebuah wawancara yang akan memisahkan toko-toko ini?

EDIT: Sementara saya mencari magang, saya merasa bahwa pertanyaan-pertanyaan ini relevan untuk semua orang. Bagian magang adalah konteks.


14
Um, tanyakan pada mereka apakah mereka babi atau ayam?
Robert Harvey

1
@Robert Lolwut?
Matius Baca


@ indyK1ng 1. Apakah Anda tahu perusahaan mana pun yang benar-benar gesit? 2. Sebagian besar metodologi waktu harus disesuaikan dengan kenyataan dengan sebaliknya. PS Saya setuju tentang kata kunci!
Amir Rezaei

Jawaban:


8

Saya selalu mulai dengan mengajukan pertanyaan ini:

Berapa lama iterasi Anda?

Nilai jawaban mereka:

1 minggu luar biasa, 2 minggu luar biasa, 3 ok dan 4 biasa-biasa saja. Lebih lama dari itu menunjukkan mereka berjuang dan lebih dari 8 minggu hanya aneh. Jika jawabannya tergantung , Anda tahu mereka tidak tahu sama sekali.

Tindak lanjuti dengan:

Seberapa sering Anda melepaskan?

Ini untuk memverifikasi pertanyaan pertama. Jawaban yang tepat adalah setiap hari atau akhir dari setiap sprint . Seorang agonis akan tahu seharusnya tidak ada perbedaan teknis antara rilis internal dan eksternal.


5
Standar defacto adalah 2 - 4 minggu. Sprint 1 minggu ...? Hmm ... saya akan curiga.
Aaron McIver

5
Tidak ada "standar"; itu bervariasi antara perusahaan / tim / situasi. Saya menemukan bahwa overhead dari Scrum adalah, sebagai bagian dari panjang sprint, terlalu boros untuk sprint satu minggu, oleh karena itu kami menggunakan dua.
Christopher

1
Saya telah menguji banyak durasi berbeda dan saya suka 1 untuk proyek yang sangat kecil dalam tim kecil, tetapi untuk proyek perusahaan besar, 3 atau 4 memberi saya hasil yang lebih baik.

3
Saya pikir ini istilah "nyata" vs "mempermudah" tangkas yang mengganggu saya. Saya selalu menerapkan konsep dan prinsip Agile Manifesto, tetapi tidak pernah menggunakan salah satu versi Agile yang bermerek. Bersikeras pada hanya satu dari banyak metodologi lincah melanggar prinsip pertama dari manifesto. Tapi saya mengerti apa yang Anda katakan.
Berin Loritsch

2
Bagi saya, gesit "nyata" gesit yang menerapkan manifesto dan 12 prinsipnya - terlepas dari apa namanya. Ada banyak kata kunci yang menambah makna inti dari gesit dan kemudian mengklaim Anda tidak gesit jika Anda tidak melakukannya.
Berin Loritsch

6

Minta mereka untuk membela metodologi lincah. Dan kemudian minta mereka untuk membantahnya dengan menjabarkan kelemahannya. Poin bonus jika mereka dapat menavigasi kursus ini tanpa mengotori dengan kata kunci yang tidak berarti.


4
+1 Selalu baik untuk menemukan cara untuk mewawancarai perusahaan.
Jeremy Heiler

@ Jeremy sayangnya mereka tidak akan menerimanya dengan baik. Saya tidak akan merekomendasikan itu!
Amir Rezaei

@ Amir: Tolong jelaskan! Saya tidak pernah meninggalkan wawancara tanpa mereka bertanya apakah saya memiliki pertanyaan. Apa yang salah dengan pencari kerja yang ingin tahu lebih banyak tentang perusahaan? Jika mereka tidak melakukannya dengan baik, itu pertanda pasti saya tidak ingin bekerja untuk mereka!
Jeremy Heiler

1
Saya tahu beberapa perusahaan sebenarnya tidak suka ketika diwawancarai mereka tidak mengajukan pertanyaan ... kepada mereka itu menunjukkan kurangnya minat dalam pekerjaan.
Rachel

2
Saya pikir meminta mereka "untuk membela metodologi yang gesit" mungkin bukan metode terbaik untuk bertanya;)
Matius Baca

6

Tanyakan kepada mereka mengapa mereka menggunakannya .

Anda akan segera tahu.


8
Ini bisa dijawab dengan cukup mudah meskipun dengan jawaban kalengan. "Untuk mengurangi waktu kita ke pasar dan tetap kompetitif." Itu harus menjadi pendekatan yang lebih bolak-balik. Jika OP terbiasa dengan Agile / Scrum dan ingin memastikan bisnisnya juga; Saya akan mengumpulkan OP harus memiliki banyak pertanyaan tentang masalah ini ... khususnya apa yang mengganggu mereka di tempat kerja sebelumnya dan bagaimana mungkin bisnis baru mengatasi ini.
Aaron McIver

2
Jawaban yang Anda sebutkan tidak bisa diucapkan oleh seseorang yang memahami kelincahan. Ini adalah indikasi yang cukup bagus bahwa mereka tidak tahu mengapa mereka harus menggunakan scrum. Setiap perusahaan berusaha mengurangi waktu ke pasar dan tetap kompetitif. Jika Anda menjawab pertanyaan saya, saya akan menjawab "itu satu-satunya metodologi yang disesuaikan dengan pengembangan perangkat lunak" atau "itu membawa banyak visibilitas pada apa yang harus kita tingkatkan".

@Pierre 303 Apa pun alasan untuk menyarankan mengapa, dari pendirian bisnis, bahwa adopsi Agile adalah suatu proses yang dapat meningkatkan waktu kita untuk memasarkan dan tetap bersaing dengan rilis tepat waktu dari perangkat lunak kita tidak valid dan akan mendefinisikan individu tersebut sebagai tidak tahu mengapa harus gunakan Scrum? Anda harus memahami bahwa manajer perekrutan tidak selalu memiliki kecenderungan teknis tetapi hal itu benar-benar berarti bahwa penggunaan Scrum dalam organisasi adalah sia-sia.
Aaron McIver

1
@Pierre 303 Bisakah Anda sedikit menguraikan jawaban Anda? Alasan untuk menggunakan metode pengembangan perangkat lunak adalah untuk "memberikan nilai seefisien mungkin kepada pelanggan kami" dan itu berlaku untuk tangkas serta RUP dan lainnya.
Martin Wickman

1
Setuju. Tanyakan mengapa mereka memilih Agile. Padat. +1
Agile Scout

5

Saya akan meminta mereka untuk menggambarkan siklus hidup pengembangan perangkat lunak ketika menggunakan metodologi Agile. Jika mereka terbiasa dengan itu mereka harus dapat menggambarkan setiap fase di SDLC secara akurat.

EDIT : Saya baru menyadari bahwa Anda bertanya dari sudut pandang orang yang diwawancarai, bukan pewawancara. Dalam hal ini saya mungkin akan bertanya kepada mereka tentang SDLC mereka dan melihat apakah langkah-langkah yang mereka katakan cocok dengan apa sebenarnya Agile.


Poin bagus tentang bertanya tentang SDLC. Namun saya telah berada di organisasi di mana mereka mengikuti semua langkah di SDLC tetapi tim menerapkan metodologi dengan buruk.
Amir Rezaei

@ Amir: Jika itu masalahnya saya akan menganggap mereka setidaknya mencoba mengikuti metodologi tangkas. Kemungkinan mereka memiliki alasan yang baik untuk menyimpang darinya, atau mereka tidak tahu apa yang mereka lakukan dan akan mau belajar jika Anda meluangkan waktu untuk mengajar mereka.
Rachel

Mereka punya alasan yang bagus. Mereka menyesuaikan metodologi dengan realitas mereka.
Amir Rezaei

3

Pendekatan yang saya ambil benar-benar tidak ada hubungannya dengan kata kunci gesit, tetapi itu ada hubungannya dengan praktik tangkas. Salah satu kesamaan dalam semua tim tangkas adalah iterasi pendek, kebanyakan orang mendapatkan bagian itu (itu salah satu dari 12 prinsip di belakang tangkas di situs http://agilemanifesto.org ). Tujuan dari iterasi singkat ini adalah untuk mendapatkan umpan balik sejak dini mengenai kualitas perangkat lunak yang dikembangkan. Di sinilah saya mulai.

  1. Tanyakan tentang pengujian unit. Sangat banyak jawaban yang saya dapatkan di sini adalah "eh, kami hentikan itu karena kami tidak punya cukup waktu" (catatan: 2 bendera peringatan pertama - tidak ada waktu dan tidak ada pengujian unit)
  2. Tanyakan tentang kapan perangkat lunak diuji, dan seberapa sering. Jawaban dapat menjadi kreatif di sini. Terutama jika tim menggunakan "Agile" sebagai alasan untuk membuang semua proses. Jika jawabannya menjelang akhir proyek, atau apa pun selain dengan setiap iterasi, mereka tidak tahu apa itu lincah.

Sejauh ini, saya tidak perlu melangkah lebih jauh dari ini untuk mengetahui bahwa orang itu tidak tahu apa itu lincah. Saya juga hanya berada dalam satu wawancara dengan perusahaan yang sudah memiliki proses tangkas yang sudah mapan.

Ada lebih dari satu cara lincah, dan saya lebih peduli pada prinsip lincah daripada merek atau kata kunci tertentu.


2

Ada beberapa hal yang memisahkan mereka yang "melakukan" gesit dari mereka yang gesit:

  • Tanyakan tentang integrasi berkelanjutan jika mereka tidak menggunakan CI mengurangi poin. Tambahkan titik jika mereka. Poin ekstra:
    1. Tambahkan 1 jika mereka menggunakan komit dua fase (kode harus berhasil dibuat sebelum pengembang dapat check-in).
    2. Tambahkan 1 jika skrip build menyertakan menjalankan test suite
    3. Tambahkan 1 jika build gagal jika cakupan kode berada di bawah ambang tertentu
    4. Tambahkan 2 jika memungkinkan untuk menyebarkan aplikasi sehingga siap dijalankan dalam satu klik
  • Tanyakan tentang TDD (pengembangan berbasis tes) kurangi 2 poin jika mereka tidak menggunakan TDD tambahkan 1 jika mereka melakukannya.
  • Tanyakan tentang iterasi, berapa lama (kurangi 2 poin jika tidak melakukan pengembangan berulang, kurangi 1 jika iterasi lebih dari sebulan atau kurang dari dua minggu, tambahkan 1 jika 2 minggu)
  • Tanyakan bagaimana estimasi dilakukan, tambahkan 1 jika mereka menggunakan poin cerita, tambahkan 2 jika mereka merencanakan poker atau sesuatu yang serupa, kurangi satu jika mereka menggunakan estimasi waktu absolut, kurangi 2 jika pengembang tidak terlibat dalam proses estimasi.
  • Tanyakan bagaimana fitur dibangun, tambahkan 1 jika pengembang bertanggung jawab atas fitur dari atas ke bawah (potongan vertikal) kurangi 1 jika pengembang bertanggung jawab atas lapisan tertentu (potongan horizontal)

Ada sejumlah indikator lain, tetapi itu saja harus memberi Anda gambaran yang baik jika tim benar-benar tangkas. Tim dengan 5 poin atau lebih yang memenuhi syarat. Ada lagi yang berarti mereka "melakukan" gesit. Agile bukan hanya tentang iterasi, ini tentang memungkinkan tim untuk beradaptasi dengan perubahan dengan mudah. Jika Anda menulis berulang-ulang kode yang belum diuji, kacau, ditulis di bawah tekanan eksternal, Anda hanya menulis kode omong kosong di iterasi. Perhatikan bahwa Anda bisa mendapatkan banyak poin hanya dari peluru integrasi berkelanjutan. Tetapi itu saja tidak cukup untuk membawa Anda lebih dari 5 jika Anda tidak mengikuti praktik lain.


1
"Tanyakan tentang TDD (pengembangan berbasis tes) kurangi 2 poin jika mereka tidak menggunakan TDD, tambahkan 1 jika mereka" tidak masuk akal. Tambahkan saja 3 jika ada.
cbrandolino

Saya mengerti apa yang Anda katakan ... Saya tidak menyederhanakan formula saya ... tapi saya pikir poin saya jelas.
Michael Brown

1
WTF ada hubungannya dengan CI dan TDD dengan Agile? Tentu, membuat rilis lebih mudah tetapi Anda benar-benar tidak membutuhkannya untuk bekerja dengan cara yang gesit. Dan percayalah, saya tahu perusahaan dengan TDD dan CI yang TIDAK gesit sama sekali.
gbjbaanb

TDD dan CI sendiri tidak membuat lingkungan menjadi gesit. Namun, kehilangan elemen-elemen itu adalah tanda peringatan bahwa tidak ada komitmen sejati untuk menjadi gesit.
Michael Brown

2

Seperti halnya semua hal ini, Anda meminta contoh dunia nyata dari proyek yang telah mereka kerjakan , bukan teori. Menerima jawaban teoretis adalah cara termudah untuk ditipu oleh seseorang yang belum benar-benar ada.

Jadi Anda meminta untuk berbicara dengan pengembang yang sebenarnya dan menanyakan hal-hal seperti:

  • Jadi, bicaralah dengan saya melalui proyek Anda saat ini. Apa tujuan akhir awal? Apa yang terkandung dalam sprint pertama dan apa yang bisa dilakukan oleh perangkat lunak di akhir?
  • Bisakah Anda memberi saya contoh fungsionalitas atau desain pada proyek terakhir Anda yang Anda yakini bekerja berbeda dari yang Anda lakukan sebagai proyek air terjun?
  • Berikan saya contoh bagaimana sebagian besar fungsionalitas dipecah menjadi beberapa sprint? Inefisiensi / pengerjaan ulang apa yang menyebabkan hal ini? Dan apa perbaikan atau perubahan dari apa yang awalnya dibayangkan.
  • Ketika Anda mulai bekerja dengan gesit, hal-hal apa yang Anda lakukan selama sprint awal yang Anda ubah selama sprint kemudian (atau proyek) saat Anda mulai terbiasa dengan metodologi?

Terus bawa mereka kembali ke proyek aktual - apa yang mereka coba capai, contoh apa yang ada di setiap sprint, contoh hal-hal yang muncul dalam rapat, contoh interaksi dengan pengguna.

Jangan terima teori, jangan terima proyek orang lain, hanya hal-hal yang mereka kerjakan sendiri dan bisa bicarakan dari pengalaman langsung.

Mereka harus menjadi pembohong yang sangat baik untuk dapat membuat barang senilai 10 - 15 menit yang akan melewati Anda jika Anda tahu barang-barang Anda.


2

Jika Anda tidak ingin membuat mereka bersikap defensif, saya telah menemukan pertanyaan berikut akan memulai percakapan yang akan memberi tahu Anda semua yang perlu Anda ketahui tentang apakah mereka benar-benar menggunakan pendekatan Agile atau hanya membayarnya dengan layanan bibir:

Siapa yang bertanggung jawab atas persyaratan / spesifikasi penulisan untuk proyek perangkat lunak Anda?

Saya telah melihat banyak perusahaan yang mengklaim gesit dan bahkan menginginkan sertifikasi Scrum Master menggambarkan proses desain besar di muka saat Anda bertanya tentang proses pengumpulan persyaratan mereka.


2

Hal yang menonjol bagi saya adalah bahwa Anda mencari magang, yang membuat saya bertanya-tanya apa tujuan Anda mengajukan pertanyaan-pertanyaan ini. Apakah Anda mencoba mengajukan pertanyaan tentang gesit untuk menjadikan wawancara berjalan dengan baik, atau apakah Anda benar-benar menolak tawaran dari perusahaan yang menggunakan kata kunci gesit? Jika Anda benar-benar mencari lingkungan yang gesit, pilih satu pertanyaan (mengapa Anda menggunakan gesit, jam berapa standup Anda, berapa lama iterasi, apa pun), dan tanyakan melalui telepon atau email tanpa membuang waktu untuk wawancara. Jika Anda mencari penghasilan, tunggu wawancara, dan ajukan pertanyaan yang menunjukkan pengetahuan / kegembiraan Anda tentang metodologi lincah (Ceritakan tentang siklus pengembangan perangkat lunak Anda) tanpa mempermalukan pewawancara jika mereka menggunakan kekejian semi-gesit.


Ini adalah pertanyaan yang akan saya tanyakan selama bagian "Apakah Anda memiliki pertanyaan untuk saya" dalam wawancara. Saya mengajukan pertanyaan untuk menentukan apakah mereka mengatakan yang sebenarnya ketika mereka mengatakan mereka gesit. Saya sudah berada di lingkungan koboi dan ingin mencegah hal itu terjadi. Saya tahu bahwa ada organisasi yang menggunakan gesit sebagai kata kunci, jadi saya mencoba untuk menyaringnya. Juga, wawancara berjalan dua arah, saya mewawancarai perusahaan saat mereka mewawancarai saya.
indyK1ng

1

Saya meminta mereka untuk menggambarkan permintaan yang khas, dari awal hingga akhir pengiriman ke klien.

Saya juga bertanya apakah mereka biasanya menangani dukungan jangka panjang untuk produk yang mereka berikan kepada klien (karena tim yang pada umumnya akan membangun produk yang lebih baik, mengetahui bahwa mereka akan menjadi orang yang memperbaikinya pada pukul 01:00 pada hari Minggu selama akhir pekan Hari Buruh).

Saya juga bertanya bagaimana manajemen melihat perannya selama proses. Sangat mudah untuk melihat apakah mereka memiliki sikap api-dan-lupa (kami luncurkan, Anda terbang, kami bertanya apakah Anda mengenai sasaran) atau sikap "kami membantu Anda mendayung perahu menyusuri sungai".

Ini umumnya akan menunjukkan kepada Anda bagaimana mereka benar-benar melakukan sesuatu, bukan bagaimana mereka seharusnya melakukannya, atau bagaimana mereka mengklaim melakukannya.


1

Cara terbaik yang saya temukan untuk melihat apakah seseorang tahu apa yang mereka lakukan dari perspektif SDLC adalah bertanya di mana mereka telah mengacau di masa lalu, dan bagaimana mereka melakukannya secara berbeda. Orang-orang yang telah melalui proses beberapa kali dan akan sepenuhnya mengakui di mana mereka mengacau, dan umumnya cukup terperinci. Mereka terbuka untuk membahasnya menunjukkan tingkat kepercayaan, karena mereka mengakui bahwa mereka tidak sempurna. Menghindari pertanyaan dengan mengatakan "Mereka cukup sering melakukannya OK setiap saat," adalah tanda peringatan nyata.


1

Seberapa sering mereka melepaskan produksi. Semakin lama waktu mereka semakin gesit. Seberapa sering mereka mengadakan lokakarya refleksi. Jika mereka tahu apa yang Anda bicarakan maka bagus. Seberapa sering mereka mengadakan pertemuan 'penangkapan' tim. Setiap hari bagus, bulanan buruk. Apakah mereka memiliki server integrasi berkelanjutan. Ini bukan harus dimiliki tetapi akan memberi Anda gagasan tentang penggunaan alat mereka. Seberapa sering pengguna akhir duduk dengan pengembang. Tidak pernah berarti mereka tidak tangkas.


+1 IMO, hal pertama yang mati di organisasi lincah-wannabe adalah retrospektif. Itu benar-benar lebih konsep Scrum, tetapi lincah yang berhasil datang dengan memahami seberapa baik proses Anda memungkinkan bukannya menonaktifkan organisasi Anda. Tanpa mekanisme introspeksi saya tidak melihat bagaimana itu mungkin.
MIA

0
  • Beri mereka sebuah situasi dan minta mereka untuk menyelesaikannya dengan gesit;
  • Tanyakan kepada mereka tentang praktik tangkas favorit mereka (perencanaan poker, pemrograman pasangan, bdd / tdd, kanban);
  • Tanyakan kepada mereka mengapa mereka tidak memilih atau pindah dari metodologi lain (air terjun, rup, dll.)
  • Apa yang paling dikenal orang-orang di dunia metodologi tangkas, yang menciptakan istilah dan apa buku paling populer yang ditulis tentang hal itu.

1
Jujur, saya akan gagal poin keempat. Saya tahu apa yang lincah, dan saya telah membaca sejumlah sumber daya online tentang bagaimana orang yang berbeda berjalan keluar. Namun, jalan saya untuk gesit selalu menjadi kebiasaan untuk tim / lingkungan tempat saya bekerja.
Berin Loritsch

0

Jika mereka menggunakan Scrum, Anda bisa bertanya apakah Anda bisa menonton stand-up berikutnya. Jika mereka tidak memilikinya, maka tanyakan mengapa tidak karena itu biasanya akan menjadi bagian dari metodologi.

Ada beberapa aspek untuk Agile yang juga bisa disebut. Mintalah untuk melihat papan cerita, seberapa besar log belakang, atau apa saja yang menjadi sorotan dalam retrospektif terakhir, untuk beberapa ide lain. Kuncinya di sini adalah untuk mencapai sesuatu yang nyata yang menunjukkan apa yang terjadi dibandingkan dengan kata-kata lembut yang tidak terlalu berarti.


0

Tanyakan kepada mereka bagaimana mereka menangani desain. Jika mereka memberi tahu Anda bahwa tidak ada desain yang gesit, mereka tidak mendapatkannya.

Tanyakan kepada mereka bagaimana mereka mengelola perubahan persyaratan. Jika kedengarannya seperti mengubah persyaratan memiliki prosesnya sendiri, mereka mungkin tidak mendapatkannya.

Jika mereka mengklaim menggunakan Scrum, lihat bagaimana mereka menulisnya. Toko-toko yang melakukan Scrum dengan baik cenderung cukup tahu cara menulisnya. Petunjuk: ini bukan SCRUM.

Itu mungkin tampak seperti kesederhanaan, tapi saya sangat yakin bahwa untuk berhasil menerapkan templat proses seperti Scrum, RUP, XP, atau apa pun, Anda perlu memahami filosofi dan "mengapa" sehingga Anda tahu bagaimana beradaptasi "apa" untuk organisasi Anda. Di Scrum, kebanyakan orang yang mengerjakan pekerjaan rumah mereka akan menemukan sedikit info. Orang-orang yang mencari resep buku resep untuk manajemen proyek biasanya akan melewatkan detail itu.


0

Yang masuk akal bagi saya adalah meminta mereka untuk menjelaskan bagaimana mereka menangani bagian dari proses Agile. Saat ini favorit saya adalah awal dari iterasi, tetapi Anda mungkin mengembangkan favorit Anda sendiri.

Tanyakan: "diberi setumpuk tiket di awal sprint, jelaskan alur kerja Anda dari sini"

Poin-poin penting untuk didengarkan di sini:

  • Apakah para devs memperkirakan tiket?
  • Apakah Anda melacak kecepatan?
  • Apa yang terjadi ketika perkiraan Anda melebihi kecepatan Anda?
  • Apa yang terjadi ketika perkiraan Anda melebihi kecepatan Anda ketika Anda memiliki tenggat waktu? (Perhatikan putaran di sini: apakah mereka mengurangi kompleksitas, atau memprioritaskan ulang, atau hanya membuat kematian tim pengembangan?)

Tak satu pun dari ini adalah deal breaker sendiri, tetapi jika jawaban mereka terhadap cukup banyak pertanyaan ini membuat Anda bertanya-tanya, maka mungkin mereka tertarik pada ritual tangkas , bukan perkembangan tangkas yang sebenarnya .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.