Refleksi tentang Agile

Ukuran kecerdasan adalah
kemampuan untuk berubah.
Albert einstein

Kata Pengantar

Saya memperkenalkan "Refleksi tentang Agile" ke komunitas TI, atau bisakah artikel ini disebut "Agile, apakah ini masih merupakan filosofi atau metodologi desain?"

Tujuan dari artikel ini adalah untuk membahas dengan komunitas TI masalah Agile yang saya miliki setelah bertahun-tahun praktik proyek, kesimpulan dan resume yang saya buat berdasarkan analisis masalah ini.

Pertanyaan itu sendiri dikutip agak lebih rendah, karena untuk melanjutkannya, masuk akal untuk menyatakan beberapa argumen dan kesimpulan.

Topik serupa telah dikemukakan tentang Habré dalam berbagai utas diskusi, sehingga masalah ini mendesak dan memiliki sejarahnya sendiri.

Menurut pendapat saya, sebagian besar artikel tidak memberikan jawaban yang jelas untuk pertanyaan saya, jadi artikel ini mungkin menarik bagi banyak orang.

Beberapa artikel tentang Habré dengan topik:

• Agile: masalah ideologis terbesar di TI. (19 April 2019)
  
  
• Mengapa Agile tidak bekerja dan apa yang harus dilakukan. (20 Desember 2017)
  
  
• Krisis yang gesit. Apa yang harus dilakukan (23 Juni 2019)
  
  

Secara singkat tentang materi pelajaran

Untuk membuatnya sedikit jelas di mana "angin bertiup", saya mencatat bahwa pengalaman saya di bidang TIK lebih dari 10 tahun. Pada awal karirnya, ia bekerja aktif di bidang telekomunikasi, saya baru saja bekerja dalam pengembangan perangkat lunak, tidak lebih dari empat tahun.

Sepanjang karirnya, ia berpartisipasi dalam berbagai proyek IT dan Telecom, dalam peran Project Manager, dalam beberapa tahun terakhir ia juga seorang analis bisnis, dan mencoba dirinya sebagai seorang programmer. Sebagai hasil dari perendaman singkat tapi banyak di Jawa - pengembangan, ia memperoleh tidak besar, tetapi pengalaman, dalam pengembangan independen, memompa keterampilan teknis sebagai programmer junior.

Sekarang saya aktif bekerja di bidang pengembangan perangkat lunak sebagai Manajer Proyek, secara opsional bertindak sebagai Business Analytics.

Dengan demikian, pokok bahasan artikel ini adalah praktik manajemen proyek untuk pengembangan produk perangkat lunak, apalagi, terkait dengan pengembangan dalam negeri.

Memahami pertanyaan oleh penulis

Selama pengalaman proyeknya di TIK, ia membuat aturan utama: mengelola proyek menggunakan metodologi proyek itu baik, tidak jelas tanpa metodologi.

Sehubungan dengan hal tersebut di atas muncul kebutuhan untuk mempelajari berbagai metodologi desain, metodologi ITSM, berbagai buku bisnis tentang topik ini, dan hanya buku-buku “pintar” dan rumit.

Mengingat popularitas PMI pada umumnya dan industri telekomunikasi asli saya pada khususnya, saya mulai belajar dengan PMBoK. Meskipun Talmud yang rumit ini tidak segera dipahami, lebih dari sekali dalam membaca bab selanjutnya saya harus memikirkan tentang apa yang membuat para penyusun buku merokok. Akibatnya, tubuh pengetahuan diuraikan menjadi atom dan diadopsi secara penuh. Omong-omong, itu bahkan tidak pernah diterapkan di sejumlah proyek dengan "semangat proletar", kesabaran dan ketangkasan (bukan PMBoK tentu saja, tetapi alat-alatnya telah diperkenalkan).

Memahami PMBoK hadir dengan pengalaman.
@ PM

Selain karya "epik" ini, metodologi lain dipelajari dan dipelajari, ada hanya penulis buku tentang manajemen proyek (meskipun kepribadian seperti T. Demarco, S. Berkun, S McConnell bukan hanya penulis, tetapi sesuatu yang lebih), tidak semua itu masuk akal, dan artikelnya bukan tentang itu.

Untuk meringkas, penulis artikel tentang subjek, mencoba untuk mengikuti tren dunia, jangan lupa klasik.

Menyelam dalam manajemen proyek perangkat lunak

Bosan di bidang telekomunikasi setelah delapan tahun bekerja, dan memutuskan untuk maju, ia bergegas ke bidang TI.

Ternyata sektor TI tidak ingin hidup dalam kerangka kerja yang jelas tentang “air terjun” klasik, GOST 34 tidak sesuai mode, kecuali tentu saja Negara diperhitungkan. sektor. Ada tren lain dalam manajemen proyek dalam manajemen proyek global.

Manifes lincah tidak bisa lewat. Setelah mempelajari sejumlah buku dan berbicara dengan beberapa rekan kerja, saya memutuskan bahwa Agile setidaknya menarik. Tetapi tidak sepenuhnya jelas bagaimana bekerja dengan ini di Rusia, filsafat tidak mencapai metodologi, dan di negara kita ada kearifan populer "apa yang tidak dilarang diperbolehkan".

Sebagai rangkuman: Saya sampai pada kesimpulan bahwa Agile tentu merupakan hal yang menarik, namun demikian, itu lebih cocok untuk buku-buku mode dan proyek-proyek kecil, tetapi bagaimana mempraktikkannya tidak jelas.

Analisis artikel tentang Habré, secara umum, mengkonfirmasi ringkasan singkat yang diberikan di atas.

Setelah beberapa iterasi belajar Agile dari buku, saya “beruntung”, saya kebetulan berpartisipasi dalam beberapa proyek Agile domestik.

Sama sekali tidak menyenangkan dari Agile yang demikian, dan RP dengan pengalaman dalam merencanakan dan mengelola proyek-proyek dari industri telekomunikasi sungguh menyedihkan. Ketika mencoba mengendalikan perkembangan spontan dari orang-orang seperti itu, semuanya hancur total, dan orang-orang berkata serempak: "Kami kreatif, kami tangkas, jangan repot-repot hidup / bekerja / berkembang." Mereka tidak ingin belajar dan berpikir, mereka hanya memiliki Agile di kepala mereka.

Namun terlepas dari skeptisisme saya, Agile berjalan keliling negeri, Agile dipromosikan secara aktif oleh G. Gref dan diakui oleh berbagai pakar industri TI Barat dan domestik.

Tetapi, seperti yang ditunjukkan oleh pengalaman pribadi, Agile menggunakan segalanya dengan caranya sendiri, dengan mentalitas kami, kami baru saja menciptakan "Agile in Russian".

Akibatnya, pertanyaan itu tumbuh dan semakin kuat, dan tidak ada yang bisa menjawabnya.

Apakah Agile ini sama saja, setumpuk ide filosofis tentang psikologi dan organisasi buruh, pemborosan akal, dan bukan keinginan untuk bekerja sesuai aturan, atau apakah itu masih menyembunyikan sesuatu yang lebih serius dari sudut pandang metodologis, sesuatu yang dapat diterapkan di sini tanah air, pada proyek-proyek serius, apa yang patut diperhatikan?

Sebelum menyelesaikan bagian ini, ada beberapa hal yang perlu diperhatikan:

1. Setelah rilis edisi 6 PMBoK pada tahun 2018, masalah Agile menjadi lebih menarik (dalam edisi ke-6, penulis memasukkan kasus menggunakan Agile).
   
2. Untuk membaca, saya membaca buku Lawrence Leach, "Tepat Waktu dan Sesuai Anggaran".
   

Lawrence Leach Book, “Tepat Waktu dan Sesuai Anggaran”
Sebuah buku yang menarik tentang manajemen proyek menggunakan metode "Rantai Kritis", penulis dapat dikaitkan dengan para ahli ideologi manajemen berat. Buku karya L. Lich menggambarkan pendekatan yang sulit, tetapi sangat menarik untuk penerapan teori E. Deming dan E. Goldratt dalam perencanaan proyek.

Mengingat pengetahuan teoritis dan praktis yang diperoleh, pemahaman tentang ketidaklengkapan dalam memahami Agile sebagai metodologi untuk implementasi yang memadai dalam proyek-proyek domestik tumbuh.

Endgame

Agile atau PMBoK adaptif yang tepat dari Mike Cohn.

Tidak sengaja, atau seperti yang mereka katakan, "tiba-tiba entah dari mana," saya menemukan buku lain tentang Agile. Ini adalah buku yang ditulis oleh Mike Cohn (Cohn Mike) tertentu yang berjudul “Agile. Evaluasi dan perencanaan proyek. "

Pada awalnya, ia menyarankan bahwa ini adalah buku bisnis lain yang menggambarkan bahwa Agile keren, modis, awet muda.

Jadi itu dan memutuskan untuk membaca kata pengantar, tetapi sudah setelah membaca bab pertama menjadi menarik siapa dia, Mike Cohn ini, dan mengapa dia menulis hal-hal yang benar.

Referensi Cepat Siapa itu Cohn Mike

Pendiri Mountain Goat Software, sebuah perusahaan konsultan proses dan manajemen proyek. Ia berspesialisasi dalam membantu perusahaan menerapkan pendekatan gesit untuk meningkatkan efisiensi. Behind Mike memiliki lebih dari 20 tahun pengalaman bekerja sebagai manajer di berbagai organisasi, dari perusahaan pemula hingga perusahaan Fortune 40. Dia adalah salah satu pendiri Agile Alliance dan merupakan anggota dewan direksi.

Saya tidak berencana untuk mendeskripsikan buku ini sepenuhnya dalam artikel ini, karena lebih baik membacanya ke orang-orang itu sendiri (mereka yang membutuhkannya), tetapi saya akan menunjukkan hal utama, buku Mike adalah PMI yang direvisi. PMI dengan mempertimbangkan filosofi manifes Agile.

Saya akan segera mencatat bahwa Mike tidak menulis set pengetahuan lain, membosankan dan tidak dapat dimengerti, dia tidak menyalin PMBoK. Sebagai gantinya, Mike Cohn membuat buku yang menarik, mudah dibaca, dan relevan:

• Menjelaskan prinsip dan aturan yang harus di Agile;
• Alat yang diuraikan untuk merencanakan dan mengevaluasi pekerjaan;
• Memberikan ide dan manajemen pengembangan yang kompeten;
• Dan masih banyak lagi.

Buku ini menggambarkan seluruh siklus hidup proyek, berfokus pada fase perencanaan proyek, menjelaskan metode dan pendekatan yang sangat menarik dan sehat untuk merencanakan dan mengevaluasi pekerjaan, dan menjelaskan pendekatan dan alat untuk tahapan proyek, pemantauan dan kontrol.

Terlepas dari kenyataan bahwa buku itu membuat saya takjub dengan fungsionalitasnya, penerapannya, dan kematangan metodologisnya, Mike juga menerapkan metode yang sangat menarik dan sulit digambarkan untuk mengurangi risiko ketidakpastian, yang dijelaskan Lawrence Leach dalam bukunya. Dengan semua hal di atas, Mike menawarkan dalam bahasa yang sederhana dan mudah dimengerti bagaimana menerapkan dan memperluas metode ini dalam praktik.

Untuk membangun proses apa pun, Anda memerlukan aturan, norma, dan prinsip, Mike menjelaskannya untuk kami.

Ringkasan

Menurut pendapat saya, kami telah dihadapkan dengan beberapa pertanyaan menarik sejak tahun 2001:

Apakah kita membutuhkan filosofi, metodologi, atau kita cukup prinsip?
Apakah kita ingin mengembangkan perangkat lunak berkualitas tinggi secara efisien dan jelas, atau akankah kita membiarkan hak prerogatif ini dipilih dan terus "menciptakan sepeda"?

Menurut saya, buku Mike mendefinisikan aturan yang ingin dihindari banyak orang, tetapi pengalaman menunjukkan bahwa aturan itu masih diperlukan.

Selain yang dijelaskan di atas, buku Mike memberikan instruksi metodologis yang jelas (meskipun seseorang mungkin tidak suka kata ini) tentang bagaimana manajemen proyek perangkat lunak Agile harus dibangun.

Bagaimanapun, semuanya akan seperti apa adanya dengan kita, tetapi satu hal yang jelas, aturan dan prinsip dibutuhkan dalam segala hal, dan mereka dalam Agile.

Prinsip-prinsip ini dijelaskan dan diperbaiki, mereka dapat dipelajari, mereka dapat digunakan.

Untuk menyelesaikan resume saya, saya akan menunjuk yang berikut:

Ageli tidak dalam krisis, Agile bukan masalah, Agile bekerja.

Satu-satunya pertanyaan adalah apakah kita ingin mempelajari peraturan dan melakukan apa yang ditentukan, atau apakah kita ingin terus bekerja seperti yang kita inginkan.

Jangan pernah kehilangan rasa ingin tahu yang suci.
Albert einstein

PS

Pembaca yang budiman, yang membaca artikel itu, saya sangat tertarik dengan pendapat dan komentar Anda, serta rekomendasi untuk buku-buku serupa, seperti buku Mike Cohn.