Fleksibilitas adalah hal yang baik, dan manifest Agile masuk akal. Dibandingkan dengan praktik rapuh yang disebut air terjun, Agile terasa lebih baik. Namun, dalam praktiknya, pendekatan yang fleksibel sering menyebabkan kerusakan yang dalam, dan pada kenyataannya, dikotomi Agile / Waterfall hampir tidak tepat di sini.

Saya melihat berapa banyak varian Agile yang disebut Scrum benar-benar membunuh perusahaan. Dengan "membunuh" saya tidak bermaksud "kemerosotan budaya", melainkan ketika saham perusahaan turun hampir 90% dalam dua tahun.

Apa itu Agile?

Agile tumbuh dari lingkungan konsultasi web di mana ia memberikan beberapa manfaat: ketika bekerja dengan klien rewel yang tidak tahu apa yang mereka inginkan, Anda biasanya harus memilih dari dua opsi. Atau untuk mengalahkan klien: menetapkan harapan, pembayaran yang sesuai untuk perubahan dan menjaga hubungan kesetaraan, bukan subordinasi. Atau terima perilaku yang salah dari klien (seperti, katakanlah, banyak desainer harus) dan mengarahkan alur kerja di sekitar disfungsi klien.

Programmer biasanya tidak bekerja dengan baik dengan klien. Kami orang yang terlalu harfiah. Kami menyukai sistem dengan perilaku yang jelas. Ini mempersulit interaksi kita dengan humaniora, karena kita cenderung menerima setiap permintaan secara harfiah, daripada mencari tahu apa yang sebenarnya mereka inginkan. Di tingkat perusahaan, metode gesit (di luar lingkungan konsultasi) melangkah lebih jauh dan menyarankan bahwa para insinyur tidak cukup pintar untuk memahami apa yang diinginkan "pelanggan" internal mereka. Ini berarti bahwa pekerjaan disemprotkan pada "cerita pengguna" dan "iterasi", yang sering kali membuat kita tidak puas dengan pekerjaan yang dilakukan, serta harapan visi jangka panjang tentang ke mana hal-hal itu pergi.

Secara umum, dua jenis pekerjaan biasanya dibuat, baik di dalam perusahaan atau untuk kontraktor. Pada tingkat tinggi, spesialis berkualifikasi tinggi dipekerjakan. Di bagian bawah - semua pekerjaan yang tidak ingin mereka lakukan terlempar ke samping. Jelas, satu kelas konsultan menerima rasa hormat, sementara yang lain tidak. Perusahaan konsultan yang dikelola dengan buruk seringkali berakhir sebagai tempat pembuangan sampah untuk pekerjaan berketerampilan rendah. Scrum tampaknya telah diciptakan untuk organisasi di mana hubungan pelanggan sangat buruk sehingga insinyur perlu diawasi setiap hari, karena mereka telah menjadi tangki sedimentasi untuk pekerjaan dasar, tidak berguna untuk karier yang tidak seorang pun ingin melakukan (dan mungkin ini bukan pekerjaan yang sangat penting) , karenanya harga rendah dan hormat).

Transparansi yang keras

Ada banyak tren di tempat kerja TI yang membuat karier pemrograman sangat tidak menarik, terutama bagi orang-orang yang kreatif dan cerdas.

Contoh paling mengerikan adalah kantor terbuka. Mereka tidak produktif. Sulit berkonsentrasi di dalamnya. Mereka anti-intelektual, karena orang takut ketahuan membaca buku (atau hanya berpikir) di tempat kerja. Ketika Anda membuat orang berpura-pura menjadi produktif, mereka sebenarnya kehilangan produktivitas. Kantor rencana terbuka umumnya bukan untuk produktivitas. Ini adalah citra perusahaan. Startup yang dibiayai usaha menggunakan tata letak ini untuk menunjukkan kepada investor untuk membuat kantor terlihat sibuk. (Sederhananya, seorang programmer rencana terbuka lebih dihargai sebagai perabot kantor, daripada kode yang menulis). Karena berbagai alasan budaya, ini membuat opsi rencana terbuka “keren” dan “kotor,” dan sekarang ia menginfeksi dunia korporat secara keseluruhan.

Sudah diketahui bahwa orang-orang kreatif kehilangan kreativitas mereka jika mereka diminta untuk menjelaskan selama bekerja. Hal yang sama dengan perangkat lunak. Programmer sering harus bekerja dalam transparansi satu sisi. Sistem Agile ini sering disalahgunakan dan membutuhkan transparansi operasi yang memalukan, meskipun tidak ada timbal balik. Alih-alih bekerja pada proyek-proyek jangka panjang aktual yang mungkin diminati seseorang, mereka direduksi menjadi “cerita pengguna” yang dikabutkan dan fungsional dan sering dilarang mengerjakan perbaikan yang tidak terkait dengan kebutuhan bisnis jangka pendek yang mendesak (seringkali turun dari atas). Versi Agile yang salah tetapi umum ini mengecualikan konsep kepemilikan dan menganggap programmer sebagai komponen yang dapat dipertukarkan dan identik.

Scrum adalah pilihan terburuk, dengan kebodohan "iterasi" dua minggu. Hal ini menyebabkan kekhawatiran yang tidak perlu tentang mikrofluktuasi kinerja manusia. Sama sekali tidak ada bukti bahwa pendekatan ini benar-benar mempercepat atau meningkatkan pembangunan dalam jangka panjang. Itu hanya membuat orang gugup. Banyak orang di bisnis ini menganggap ini pendekatan yang baik, karena pekerjaan "berjalan lebih cepat." Saya telah berkecimpung di industri TI selama sepuluh tahun, sebagai manajer dan sebagai lebah yang bekerja. Ini tidak benar.

Agile dan Scrum cacat spesifik

1. Pengembangan berorientasi bisnis.

Agile sering disajikan dibandingkan dengan "air terjun." Apa itu air terjun?

Pendekatan Air Terjun benar-benar mengerikan. Di dalamnya, "pekerjaan bergulir", di mana setiap tingkat hierarki organisasi memilih apa yang dianggapnya sebagai "materi yang menarik", dan meneruskannya. Proyek ditentukan oleh manajer, arsitektur dirancang oleh arsitek, tenggat waktu pribadi ditentukan oleh manajer menengah, implementasi dilakukan oleh pekerja tingkat atas (programmer), dan kemudian operasi dan pengujian dipindahkan ke kuda tingkat bawah. Ini adalah skema yang sangat tidak fungsional. Ketika orang merasa bahwa semua keputusan penting telah dibuat, mereka tidak memiliki motivasi untuk bekerja sebaik mungkin.

Air terjun mereproduksi model sosial organisasi disfungsional dengan hierarki tertentu. Pada gilirannya, Agile cukup sering mereplikasi model sosial organisasi yang disfungsional tanpa hierarki yang jelas.

Saya memiliki beragam pendapat tentang jabatan seperti "senior" dan "direktur," dan sejenisnya. Itu penting, dan saya sendiri mungkin tidak akan menerima posisi di bawah level direktur, tapi saya benci kepentingan mereka. Jika Anda melihat Scrum, itu secara spesifik merampas hak-hak senior, insinyur yang paling cakap, karena di sini mereka diwajibkan untuk mematuhi proses yang telah mapan (hanya bekerja pada tugas-tugas yang dibuat, 5-10 jam seminggu untuk meluncur). Proses-proses ini dirancang untuk orang-orang yang memulai pemrograman sebulan yang lalu.

Seperti negara komunis yang gagal, yang menyamakan orang dengan menyebarkan kemiskinan, Scrum dalam bentuknya yang paling murni menempatkan seluruh perkembangan pada tingkat yang sama rendah: tidak didefinisikan dengan jelas, tetapi jelas di bawah tingkat pebisnis yang diberi kekuatan penuh untuk memutuskan apa yang harus dikerjakan.

Agile, dalam implementasinya yang biasa, meningkatkan frekuensi umpan balik, masih tidak memberi insinyur kekuatan nyata. Ini adalah kesepakatan yang hilang karena itu berarti bahwa programmer lebih mungkin ditarik atau dihukum ketika pekerjaan itu memakan waktu lebih lama dari yang seharusnya. Ini menciptakan banyak kegelisahan dan tergesa-gesa, tetapi pada kenyataannya itu tidak ada hubungannya dengan yang benar-benar penting: menciptakan produk hebat.

Lembah Silikon telah melakukan banyak kesalahan, terutama dalam lima tahun terakhir, tetapi telah melakukan sesuatu yang benar. Termasuk memperkenalkan konsep "rekayasa" perusahaan. Tidak selalu lebih baik bagi insinyur untuk mengelola seluruh perusahaan, tetapi ketika insinyur mengelola pengembangan dan menetapkan prioritas, semua orang menang: insinyur senang dengan pekerjaan yang ditugaskan pada mereka (atau, bahkan lebih baik, mereka ditugaskan untuk diri mereka sendiri), dan bisnis mendapatkan kualitas pengembangan yang jauh lebih tinggi.

Tetapi Anda memiliki "perusahaan bisnis", itu tidak masalah. Maka jangan mempekerjakan insinyur pada staf jika Anda membutuhkan bakat. Anda bisa mendapatkan orang-orang terbaik sebagai konsultan (mulai dari $ 200 per jam dan naik tajam dari level ini), tetapi tidak sebagai karyawan penuh waktu dari "perusahaan bisnis". Insinyur yang baik ingin bekerja di perusahaan yang dijalankan oleh insinyur, di mana mereka akan berpartisipasi dalam perencanaan kerja tanpa harus membuat alasan kepada "scrum master," "pemilik produk," dan beberapa tingkat manajer humaniora.

Pada akhirnya, Agile (seperti yang dipraktikkan) dan Waterfall adalah bentuk pengembangan berorientasi bisnis, dan oleh karena itu, tidak ada yang cocok untuk mengembangkan perangkat lunak berkualitas atau memotivasi karyawan.

2. Posisi bawahan kaum muda.

Sayangnya, dalam pengembangan perangkat lunak budaya subordinasi muda telah berkembang dengan konsep pemrograman (yang sangat keliru) sebagai “mainan anak muda”, meskipun hampir tidak ada insinyur terbaik yang muda, dan beberapa yang terbaik bukanlah laki-laki sama sekali.

Masalah dengan iterasi Agile dua minggu (atau sprint) dan cerita pengguna adalah bahwa tidak ada strategi keluar. Tidak ada pilihan "Kami tidak perlu melakukan ini lagi ketika kami mencapai [X]." Sistem ini seharusnya selamanya: demonstrasi berorientasi bisnis tidak akan pernah hilang. Arsitektur, R&D dan pengembangan produk meninggalkan pekerjaan programmer karena mereka tidak cocok dengan "cerita pengguna" yang dikabutkan dan sprint dua minggu.

Akibatnya, untuk programmer yang kurang lebih berpengalaman, tidak nyaman untuk bekerja dengan cara ini, karena mereka ingin mengambil jenis proyek yang diabaikan dalam struktur ini, dan proyek seperti itu sulit untuk dibenarkan dalam hal nilai bisnis jangka pendek. Keunggulan teknis penting, tetapi sangat sulit untuk meyakinkan orang tentang fakta ini jika mereka keras kepala tidak mau diyakinkan.

Saya pernah bekerja untuk sebuah perusahaan di mana seorang manajer produk mengatakan bahwa perbedaan antara insinyur senior dan insinyur junior adalah kemampuan untuk memberikan perkiraan waktu yang lebih akurat. Sebenarnya tidak. Dan itu bahkan menghina. Saya benci evaluasi karena mereka menghasilkan kebijakan dan tidak benar-benar melakukan pekerjaan lebih cepat atau lebih baik (pada kenyataannya, biasanya sebaliknya).

Bagian terburuk dari evaluasi adalah bahwa mereka merangsang kinerja pekerjaan yang dapat dievaluasi. Hal ini membuat programmer memberikan preferensi pada hal-hal sederhana tingkat rendah yang tidak benar-benar dibutuhkan bisnis (bahkan jika manajer tingkat menengah yang canggung berpikir berbeda), tetapi itu “aman.” Segala sesuatu yang benar-benar layak dilakukan memiliki peluang kegagalan yang tidak nol dan terlalu banyak parameter yang tidak diketahui untuk perkiraan jangka waktu yang wajar. Fokus Agile pada nilai bisnis jangka pendek pada akhirnya mendorong orang menjauh dari pekerjaan yang benar-benar dibutuhkan perusahaan, untuk mengelola reputasi setiap programmer secara waktu nyata.

Budaya seperti itu menunjukkan bahwa pemrograman adalah kekanak-kanakan, yang harus Anda singkirkan pada usia 35 tahun. Saya tidak setuju dengan pendapat ini. Sebenarnya, saya pikir ini adalah pemikiran yang buruk. Umur saya di atas 30, dan saya merasa seperti baru mulai memprogram dengan baik. Melecehkan programmer senior hanya karena mereka cukup berpengalaman untuk mengetahui bahwa proses fleksibel / scrum ini tidak ada hubungannya dengan ilmu komputer dan bahwa itu tidak menambah nilai adalah ide yang mengerikan.

3. Pendekatan jangka pendek, yang bodoh dan berbahaya.

Agile ditujukan untuk perusahaan konsultan sekunder yang tidak memiliki kredit yang cukup untuk dipercaya untuk bernegosiasi dengan rekan sejawat, dan yang menghadapi tenggat waktu yang ketat, dan setiap proyek klien merupakan risiko eksistensial. Dia adalah untuk orang luar "marginal". Tapi inilah masalahnya: Scrum sering digunakan untuk perusahaan besar dan mendanai startup. Tetapi orang-orang pergi ke perusahaan seperti itu karena mereka tidak ingin menjadi orang luar . Mereka menginginkan keamanan. Itulah sebabnya mereka bekerja di perusahaan-perusahaan ini, daripada menciptakan perusahaan mereka sendiri. Tidak ada yang mau ketinggalan jika tidak ada keuntungan pribadi yang signifikan. Agile dalam korporasi berarti rasa sakit dan risiko tanpa imbalan.

Ketika setiap proyek klien membawa risiko reputasi eksistensial atau serius, Agile mungkin solusi yang tepat, karena fokus pada iterasi jangka pendek berguna ketika perusahaan dalam risiko dan mungkin menghilang dalam jangka panjang. Manajemen proyek yang agresif masuk akal dalam keadaan darurat. Ini tidak masuk akal sebagai pengaturan permanen; setidaknya tidak untuk pemrogram berbakat yang memiliki pilihan lebih sedikit stres dan lebih menyenangkan.

Sebagai bagian dari Agile, hutang teknis menumpuk dan tidak terselesaikan karena pebisnis yang menugaskan tugas tidak akan melihat masalah sampai terlambat atau setidaknya terlalu mahal untuk memperbaikinya. Selain itu, insinyur individu diberi penghargaan atau dihukum hanya berdasarkan "sprint" dua minggu saat ini, yaitu, tidak ada yang melihat lima "sprint" di muka. Agile hanyalah satu “sprint” sia-sia, picik demi satu: tidak ada kemajuan, tidak ada perbaikan, hanya tiket demi tiket, oleh tiket.

Orang-orang yang setuju dengan pengocokan tugas yang tidak berarti dapat menanggungnya, tetapi insinyur yang sangat baik benci akan bekerja pada Senin pagi, tidak tahu apa yang akan mereka kerjakan pada hari itu.

4. Dia tidak ada hubungannya dengan membangun karier.

Kisah-kisah pengguna perorangan tidak baik untuk karier teknik. Pada usia 30, Anda diharapkan dapat bekerja di level seluruh proyek dan Anda setidaknya siap untuk melampaui level itu dalam infrastruktur, arsitektur, penelitian, atau kepemimpinan.

Dalam keadaan darurat, apakah itu konsultasi yang berupaya meyakinkan klien penting atau "ruang perang" perusahaan, pemikiran tentang resume dapat menunggu. Beberapa orang menyerah beberapa minggu dari pekerjaan yang tidak menyenangkan atau lainnya yang tidak terkait dengan pengembangan karir, jika itu benar-benar penting bagi perusahaan. Pentingnya pekerjaan adalah prioritas di sini. Jika Anda dapat mengatakan, "Saya duduk di kantor pusat dan berbicara dengan CEO selama 20 menit sehari," yang membenarkan melakukan pekerjaan bodoh.

Tetapi jika tidak ada keadaan darurat, programmer berharap karir mereka dianggap serius. Kalau tidak, mereka akan pergi. "Aku berada di tim Scrum" berarti kamu adalah karung tinju. Adalah satu hal untuk melakukan pekerjaan bodoh, karena CEO mengakui bahwa tugas yang tidak menyenangkan akan menambah nilai jutaan dolar (dan dia akan menghargainya sesuai dengan itu). Tetapi jika Anda hanya diberi "cerita pengguna" dan tiket Jira, maka Anda dianggap sebagai pecundang.

5. Tujuannya adalah untuk menentukan tingkat yang rendah, tetapi tingkat hasil positif palsu sangat tinggi.

Scrum diusulkan sebagai cara yang baik untuk mengidentifikasi "karyawan yang tertinggal." Masalahnya adalah ia menciptakan lebih banyak programmer yang tidak efektif daripada yang diungkapkannya. Ini adalah sistem pelacakan total di mana insinyur individu menunjukkan secara rinci kemajuan pekerjaan mereka, dengan penilaian produktivitas.

Dalam sebuah perdebatan tentang kebebasan sipil, kesalahan umum sering disebutkan: argumen "tidak ada yang disembunyikan." Beberapa orang suka berargumen bahwa menyerbu privasi, katakan dengan penegakan hukum, bukan masalah, karena mereka sendiri bukan penjahat. Orang-orang ini kehilangan beberapa hal penting. Misalnya, undang-undang itu berubah. Tanyakan siapa saja yang seorang Yahudi di Eropa Tengah pada 1930-an. Bahkan untuk orang-orang terhormat, keadaan pengawasan adalah kondisi kecemasan.

Fakta pengamatan mengubah cara orang bekerja. Di bidang kreatif, itu menyakitkan. Hampir tidak mungkin untuk bekerja secara kreatif jika Anda perlu melaporkan pekerjaan setiap hari.

Topik lain muncul di benak: kepekaan terhadap status . Programmer suka berpura-pura bahwa mereka telah mengatasi beberapa juta tahun evolusi primata yang berkaitan dengan status sosial, tetapi kenyataannya adalah status sosial itu penting, dan tidak memalukan untuk mengakui fakta ini. Orang yang lebih tua, perempuan, ras minoritas dan orang-orang cacat umumnya peka terhadap status tempat kerja karena itu adalah masalah kelangsungan hidup bagi mereka. Pemantauan kerja yang terus-menerus menunjukkan kurangnya kepercayaan dan status sosial yang rendah, dan yang paling sensitif terhadap status (bahkan jika mereka adalah karyawan terbaik) adalah yang pertama kali menderita karena meningkatnya pemantauan. Jika mereka merasa bahwa mereka tidak dipercaya (dan apa lagi yang ditularkan oleh budaya, di mana setiap elemen pekerjaan harus disetujui?), Maka mereka dengan cepat kehilangan motivasi mereka.

Agile dan terutama Scrum rentan terhadap kesalahan "tidak ada yang disembunyikan". Jika Anda bukan "pekerja jahat", Anda tidak menentang meluncur setiap hari, bukan? Satu-satunya orang yang akan keberatan dengan laporan harian tentang pekerjaan mereka dalam hal nilai bisnis jangka pendek adalah "loafers" yang ingin mencuri uang dari perusahaan, kan? Ya tidak. Jelas tidak.

Budaya transparansi yang keras dirancang untuk yang paling tidak sensitif terhadap status: laki-laki muda, biasanya berkulit putih atau Asia, yang istimewa yang tidak pernah dipaksa bekerja. Bagi mereka yang berpikir bahwa SDM dan manajemen adalah buang-buang waktu, dan karyawan harus menelan penghinaan dan penghinaan.

Seringkali, karyawan terbaik menderita implementasi Agile / Scrum, karena R&D dihilangkan secara efektif. Obsesi dengan "iterasi" jangka pendek atau sprint berarti ketidakmampuan untuk mencoba sesuatu yang baru, berisiko.

Kebenaran tentang karyawan yang tertinggal adalah bahwa Anda dapat mengidentifikasi mereka tanpa Agile. Orang-orang tahu siapa mereka. Alasan mengapa beberapa tim dipenuhi dengan sepatu, orang yang tidak kompeten atau beracun adalah karena tidak ada yang melakukan sesuatu dengan mereka. Ini adalah masalah manajemen di tingkat staf, bukan di tingkat alur kerja.

6. Efek mabuk.

Tampaknya manajemen yang agresif dapat membuat beberapa orang yang sedikit tidak kompeten cukup mampu bekerja. Saya menyebutnya efek mabuk: ketika gadis-gadis menjadi begitu-begitu bugar, tetapi benar-benar lucu tidak lagi ingin ada hubungannya dengan Anda. — , , -.

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .