Tahapan perkembangan tangkas. Apa itu Agile? Pada awalnya, tim mengeksplorasi realitas pengembangan aplikasi dan ruang lingkupnya. Pekerjaan lebih lanjut dibagi menjadi tiga siklus yang saling berhubungan

Agile ("gesit") adalah kata yang telah terdengar dari setiap besi akhir-akhir ini. Tapi apa itu Agile dan, yang terpenting, mengapa Agile ini dibutuhkan?

Jika terbuka kamus, misalnya, Oxford, maka Anda dapat membaca setidaknya dua definisi di sana:

1. Mampu bergerak dengan cepat dan mudah.
2. Mampu berpikir dan memahami dengan cepat.

Artinya, untuk menjadi gesit, Anda harus bisa bergerak dengan cepat dan mudah serta berpikir cepat. Tampaknya kualitas yang cukup berguna, terutama dalam bisnis. Berpikir cepat dan bereaksi cepat adalah persis apa yang diperintahkan dokter untuk zaman kita, jika tidak, Anda tidak akan bertahan: pesaing akan melahap Anda. Ada semakin sedikit industri di dunia di mana para pesaing ini tidak ada. Selain itu, kecepatan penyalinan membuat hampir tidak mungkin untuk membawa produk ke pasar dan berpuas diri. Tanpa kemampuan untuk cepat beradaptasi dengan perubahan, yang disebut sebagai "Metodologi Agile", semakin sulit untuk bertahan hidup.

Bukan kebetulan saya mengambil ungkapan “Metodologi tangkas” dalam tanda kutip, karena Anda sering mendengarnya, tetapi itu tidak sepenuhnya benar. Jika Anda tidak masuk ke detail teknis, maka Agile bukanlah metodologi, tetapi nama kolektif untuk berbagai metode dan pendekatan manajemen yang:

1. Fokuskan tim pada kebutuhan dan tujuan klien.
2. Menyederhanakan struktur dan proses organisasi.
3. Mereka menawarkan pekerjaan dalam siklus pendek.
4. Gunakan umpan balik secara aktif.
5. Ada peningkatan kekuatan karyawan.
6. Mereka didasarkan pada pendekatan humanistik.
7. Mereka bukan keadaan akhir, melainkan cara berpikir dan hidup.

Tidak ada yang supranatural, kan? Mari kita bahas poin demi poin dan melihat mengapa hal di atas penting untuk menjadi cepat dan gesit, dan bagaimana Agile mencapai tujuan ini.

Fokus pada kebutuhan dan tujuan pelanggan

Saya pikir tidak ada gunanya menjelaskan mengapa bisnis yang paling sukses adalah bisnis yang memenuhi kebutuhan kliennya lebih baik daripada pesaing. Lebih menarik untuk memahami alat apa di Agile yang membantu untuk mencapai ini.

Yang terpenting, fokus pada klien dengan pendekatan Agile muncul tidak hanya di kepala pemilik bisnis (sudah ada di sana), tetapi di setiap orang yang bekerja untuk menciptakan produk atau layanan. Setiap peserta dalam proses harus memahami siapa kliennya, apa yang dia inginkan, masalah apa yang kita selesaikan dengan produk kita, apa yang dia sukai, apa yang dia takuti, dan sebagainya. Fokus global semacam itu memungkinkan Anda membuat urutan solusi yang lebih baik. Saya telah berulang kali menemukan situasi di mana orang-orang yang sebelumnya bertanggung jawab atas beberapa pekerjaan kecil, setelah memahami tujuan klien, mulai memberikan ide-ide luar biasa, dan orang-orang yang bertanggung jawab untuk pengembangan produk mencatat dengan terkejut. Atau - bagaimana ide-ide tersebut diasah dalam sesi pengembangan produk kelompok orang yang berbeda dan saling melengkapi, dari hanya baik menjadi sangat baik. Dan, tentu saja, bagaimana mereka kemudian diimplementasikan.

“Alat kerja” dalam hal ini adalah sesi (pertemuan) singkat, tetapi intens dari semua peserta dalam pekerjaan atau mayoritas kunci, di mana berbagai ide dihasilkan dan diuji. Pertemuan yang sama ini berfungsi untuk meningkatkan pemahaman dan fokus: semua peserta dalam pertemuan keluar memahami apa yang mereka lakukan, mengapa, dan mengapa itu penting bagi klien. Dan format lokakarya yang demokratis, tidak seperti presentasi yang membosankan, menjamin inklusi dan motivasi yang lebih besar dari semua peserta.

Contoh alat tersebut adalah Lean Canvas, Pemetaan Dampak, Pemetaan Cerita Pengguna, dan metode Agile lainnya untuk menggambarkan hipotesis dan proses.

Salah satu pilar Agile adalah kesederhanaan yang ekstrem. Dan struktur organisasi organisasi, dan proses di mana orang bekerja, dan aturan harus sesederhana mungkin. Ini akan memungkinkan orang untuk fokus pada pekerjaan mereka, pada nilai yang mereka ciptakan, dan bukan pada kepatuhan terhadap peraturan dan aturan. Contoh bagus dari pendekatan ini dapat ditemukan di banyak tim yang mengerjakan Scrum, cara paling populer untuk mengatur alur kerja di Agile. Faktanya, semua kesepakatan dan aturan tim yang terdiri dari 10-11 orang, tugas saat ini selama beberapa minggu, tujuan, serta rencana strategis dapat dengan mudah dimuat di 2-3 lembar kertas A0. Di satu lembar bisa ada apa yang disebut "sprint backlog", daftar semua yang akan dilakukan tim di iterasi berikutnya. Jika Anda menggantung satu di ruangan tempat Anda bekerja, Anda dapat menyelamatkan diri dari kesulitan mengingat semua ini. Hal yang sama berlaku untuk proses. Misalnya, di Scrum, tempat dan waktu semua rapat ditetapkan secara kaku. Setiap peserta tahu pasti bahwa, misalnya, pada hari Senin pukul 10:00 iterasi berikutnya direncanakan, dan pada hari Jumat pukul 17-30 - pertemuan untuk meningkatkan proses kerja.

Dan semakin besar organisasi, semakin besar manfaat dari kesederhanaan tersebut, karena kompleksitas cenderung tumbuh secara eksponensial, dan Agile adalah Cara yang baik mengalahkan kompleksitas ini, atau setidaknya menahan pertumbuhannya.

Contoh penyederhanaan (dan perataan, tetapi ini adalah topik untuk diskusi lain) di Agile adalah Scrum, Nexus, LeSS (Scrum Skala Besar, atau Scrum dalam skala besar), serta manifes Agile itu sendiri.

Di dunia Agile, bukanlah kebiasaan untuk mengunci diri di bengkel selama tiga tahun untuk mengasah sesuatu yang menarik di sana. Risikonya sangat besar, menghabiskan lautan kekuatan dan waktu untuk sesuatu yang tidak dibutuhkan atau ketinggalan zaman.

Untuk menghindari hal ini, apa yang disebut pendekatan iteratif-incremental digunakan, ketika:

• pekerjaan dilakukan dalam jangka waktu tetap yang kecil, misalnya, dalam satu, dua atau empat minggu,
• dan, yang paling penting, pada akhir setiap periode waktu, tidak hanya semacam hasil antara yang dibuat, tetapi, meskipun kecil, terpotong, sedikit, tetapi versi kerja produk, yang Anda dapat mulai menggunakan.

Sebagai contoh paling sederhana dari model kerja seperti itu, kita dapat membayangkan standar program "kalkulator" untuk semua komputer, yang pada awalnya hanya memungkinkan Anda untuk menambahkan dua angka, kemudian kami menambahkan pengurangan, perkalian, pembagian, bilangan transendental, fungsi trigonometri, dan seterusnya, dalam urutan frekuensi penggunaan. Pada awalnya, fungsionalitasnya kecil, tetapi kita sudah dapat melihat bagaimana tampilan kalkulator, betapa nyamannya menggunakannya, dan membayangkan bagaimana mengembangkannya lebih lanjut. Dan, yang paling penting, beberapa klien (katakanlah, anak sekolah sekolah dasar) sudah dapat mulai menggunakannya.

Keuntungan lain dari pendekatan ini, selain masuk lebih awal ke pasar dan membuat perubahan pada tahap awal pekerjaan, adalah kemampuan untuk mengukur kemajuan dengan lebih akurat. Kami tidak hanya "menyelesaikan 15% pekerjaan", yang cukup abstrak. Kami "membuat 15% dari fungsionalitas" yang sudah berfungsi.

Semua pendekatan proses di Agile memiliki siklus pendek, baik itu Scrum, Nexus, LeSS, SAFe atau yang disebutkan sebelumnya, ditambah kebutuhan untuk bekerja dengan siklus tersebut disebutkan dalam manifes Agile itu sendiri.

Penggunaan umpan balik yang aktif dan sistemik

Poin ini, menurut saya, adalah yang paling penting untuk proses apa pun, karena memungkinkan Anda untuk menyesuaikan pekerjaan Anda dari waktu ke waktu, berdasarkan pengalaman, menghilangkan kesalahan dan kerugian dari proses dan produk yang dibuat dan menambahkan sesuatu yang bermanfaat.

Di bidang aktivitas manusia apa pun yang terkait dengan penciptaan sesuatu yang baru, Anda akan menemukan yang serupa bekerja melalui percobaan. Peroketan, teknik pesawat, farmasi, fisika, kedokteran, konstruksi, psikologi, ekonomi - bidang aktivitas apa pun dimulai dengan eksperimen dan pemrosesan yang cermat masukan dari mereka.

Agile menawarkan penggunaan sistematis pendekatan ini di mana-mana: dalam menciptakan produk (kami merilisnya di pasar, atau menunjukkannya kepada pelanggan, atau melakukan tes dan menggunakan umpan balik untuk memperbaikinya), dalam membangun proses (secara berkala kami "berhenti" bekerja dan menganalisis proses itu sendiri, untuk memperbaikinya, menghilangkan kerugian dan masalah), bahkan dalam membangun struktur organisasi dan menyempurnakan hubungan dalam tim.

Sekali lagi, contohnya ada di mana-mana: pertemuan retrospektif di Scrum, Kanban, Nexus dan LeSS, siklus I&A di SAFe, pendekatan Design Thinking untuk menciptakan produk, dll.

Mengapa memberi lebih banyak otoritas ketika Anda dapat memberikan selembar kertas dengan instruksi? Setidaknya ada tiga alasan untuk melakukan ini.

Pertama, orang yang terlibat dalam pekerjaan mental tidak suka merasa seperti monyet (yah, atau robot), dan dengan menghilangkan kemampuan untuk membuat keputusan dari seseorang, kita mengambil pekerjaan mental darinya sendiri. Dan itu pasti demotivasi.

Kedua, dengan memberi lebih banyak wewenang, kita memberi lebih banyak tanggung jawab, dan orang-orang dipaksa untuk belajar membuat keputusan sendiri dan, yang paling penting, memikul tanggung jawab untuk itu. Ini panjang, sulit, tetapi sepadan. Pekerjaan tidak akan berhenti jika tim yang terorganisir sendiri menghadapi masalah yang tidak dikenal sebelumnya. Dan siapa yang akan berargumen bahwa di tempat kerja, orang dewasa yang matang dan bertanggung jawab lebih berguna daripada anak-anak besar yang tidak mampu berpikir sendiri?

Ketiga, kecepatannya masih sama. Jika seseorang dapat memecahkan masalah sendiri, menggantikannya, tanpa meminta siapa pun, ini mengurangi waktu untuk membuat keputusan. Tidak ada lagi mengirim pertanyaan "naik" dan menunggu tanggapan dari manajemen. Keuntungan ini tidak begitu terlihat jika Anda memiliki 3 orang yang bekerja, tetapi jika Anda memiliki 30, atau 300, atau 3000 ... Dalam organisasi besar yang dibangun di atas pengambilan keputusan hierarkis murni, kelumpuhan kemauan bisa sangat umum.

Cara populer untuk membangun pekerjaan di Agile, terutama yang didasarkan pada kerangka Scrum, melibatkan sistem tim yang terorganisir sendiri dan mendorong kepemimpinan di semua tingkatan.

Mengapa memperlakukan orang seperti manusia? Artinya, sisi moral dari masalah ini jelas, tetapi apa manfaatnya bagi pemilik perusahaan?

Jawabannya cukup sederhana. Jika membuat apa yang Anda jual tidak memerlukan kerja mental, tapi hanya tindakan mekanis - Anda tidak bisa repot-repot. Bayar saja sesuai dengan pekerjaan yang dilakukan, dan hanya itu. Tetapi begitu otak pekerja mulai bekerja, Anda harus memperhitungkan prinsip-prinsip memotivasi kerja mental. Dan mereka mengatakan bahwa kemungkinan realisasi diri, peningkatan keterampilan mereka, membawa sesuatu yang berharga ke dunia, kemandirian dalam mengambil keputusan dan sejumlah faktor lain adalah penting bagi orang-orang. Dan orang yang termotivasi (jangan bingung dengan orang yang terstimulasi!) akan berinvestasi lebih banyak dalam pekerjaan, dan hasilnya akan lebih baik dan lebih cepat. Dan secara umum, suasana yang menyenangkan di tempat kerja menambah keinginan untuk datang dan bekerja di sana - hampir tidak ada yang bisa membantahnya.

Dan, bagusnya, jika Anda menggali Scrum yang sama, ternyata semua faktor kunci untuk memotivasi seorang pekerja mental dan / atau kerja kreatif sudah termasuk di dalamnya. Dalam setiap iterasi (“sprint”), kami menetapkan tujuan yang ingin kami capai; kita diberi kesempatan untuk memutuskan bagaimana tepatnya untuk mencapai tujuan; pada akhirnya, kita melihat seberapa banyak kita telah menjadi lebih baik (atau lebih buruk) untuk bekerja daripada sebelumnya; kami melihat orang-orang yang tertarik pada produk dan emosi mereka untuk mengenalnya. Sangat baik jika emosi ini positif.

Kesimpulannya adalah: orang yang bahagia bekerja lebih baik, dan teknologi Agile membantu membangun proses di mana orang merasa lebih bahagia. Dan poin pertama dari manifesto ini adalah tentang ini: orang-orang dan cara mereka berkomunikasi lebih penting dari apapun.

Agile bukanlah keadaan akhir, tetapi cara berpikir dan hidup

Poin ini adalah tentang bagaimana Agile secara umum adalah jalannya, bukan tujuannya. Anda tidak dapat "menerapkan" Agile dan santai. Jika Anda memilih jalan ini, Anda akan selalu memiliki hal lain untuk dilakukan dengan lebih baik, beberapa tantangan lain untuk dijawab, beberapa masalah lain untuk dipecahkan, ketinggian lain untuk ditaklukkan... Ini adalah gerakan, tanpa akhir, karena tidak ada proses atau produk yang ideal, perkembangan dan persaingan tidak pernah berhenti, sebagaimana perjuangan untuk bertahan hidup di alam tidak pernah berhenti.

Dan jika semuanya berhasil: orang-orang di perusahaan memahami dan berbagi nilai dan prinsip Agile dan bekerja sesuai dengan mereka, maka manajemen tidak perlu "menyeret" perubahan atau "menendang" karyawan agar mereka mulai melakukan sesuatu. berbeda. Perusahaan akan menjadi organisme tunggal, yang pengelolaannya akan membutuhkan lebih sedikit usaha dan membawa lebih banyak kesenangan.
Dan di mana ada lebih banyak kesenangan dari pekerjaan, dan hasilnya lebih tinggi. Ini tidak hanya berlaku untuk spesialis, tetapi juga untuk manajemen, dan bahkan lebih.

Setiap orang yang pernah berurusan dengan manajemen proyek tahu betapa sulitnya mengatur kerja tim yang terkoordinasi dengan baik, dan dalam menghadapi persyaratan yang terus berubah untuk hasil proyek, semua upaya yang dilakukan dapat menjadi sia-sia. Metode manajemen proyek tangkas sangat ideal untuk bekerja dengan proyek semacam itu.

Metode manajemen proyek Agile adalah serangkaian tahapan kerja yang ditentukan oleh tenggat waktu yang sulit - sprint, yang memungkinkan tim untuk terus mengevaluasi hasil pekerjaan yang dilakukan dan menerima umpan balik dari pelanggan dan peserta proyek lainnya. Pendekatan ini memungkinkan Anda untuk membuat perubahan instan pada produk ketika persyaratan baru tiba.

Sejarah Agile

Manajemen proyek evolusioner dan pengembangan adaptif perangkat lunak muncul pada awal 1970-an. Pada tahun 1970, Dr. Winston Royce mempresentasikan makalah berjudul "Mengelola Pengembangan Sistem Perangkat Lunak Besar" yang kritis terhadap pengembangan sekuensial. Dia berpendapat bahwa perangkat lunak tidak boleh dikembangkan seperti mobil di jalur perakitan di mana setiap bagian ditambahkan secara berurutan. Dalam fase berurutan tersebut, setiap fase proyek harus diselesaikan sebelum fase berikutnya dapat dimulai. Dr. Royce merekomendasikan penggunaan pendekatan bertahap, di mana pengembang pertama-tama mengumpulkan semua persyaratan proyek, dan kemudian menyelesaikan seluruh arsitektur dan desain mereka, kemudian menulis semua kode, dan seterusnya.

Pada 1990-an, sejumlah metode pengembangan perangkat lunak tangkas dikembangkan sebagai tanggapan terhadap metode kelas berat yang berlaku. Ini termasuk: sejak 1991 - RAD (pengembangan aplikasi cepat); sejak 1994 - Metode Pengembangan Sistem Dinamis (DSDM); sejak 1995 - Scrum; Sejak tahun 1996, Crystal Clear and Extreme Programming (XP); Dan sejak 1997 - Pengembangan berbasis fitur (FDD). Meskipun mereka berasal sebelum publikasi Manifesto Pengembangan Perangkat Lunak Agile, mereka secara kolektif disebut sebagai Pengembangan Perangkat Lunak Agile.

Pada Februari 2001, tujuh belas pengembang perangkat lunak bertemu di Snowbird Resort di Utah untuk membahas teknik pengembangan ringan. Bersama-sama mereka menerbitkan Agile Manifesto.

Manifesto Agile

Manifesto Agile terdiri dari 4 ide inti dan 12 prinsip. Setiap metodologi Agile menerapkan ide-ide ini secara berbeda, tetapi mereka semua bergantung pada mereka untuk mengelola proyek seefisien mungkin.

4 Ide Agile

1. Orang dan interaksi lebih penting daripada proses dan alat.
2. Perangkat lunak yang berfungsi lebih penting daripada dokumentasi.
3. Kolaborasi dengan klien lebih penting daripada menegosiasikan ketentuan kontrak.
4. Kesediaan untuk melakukan perubahan prioritas daripada tetap berpegang pada rencana semula.

12 prinsip Agile

1. Kepuasan pelanggan melalui pengiriman perangkat lunak awal dan berkelanjutan. Pelanggan lebih bahagia ketika mereka menerima perangkat lunak yang berfungsi secara berkala.
2. Buat perubahan pada persyaratan produk selama proses pengembangan.
3. Pengiriman sering perangkat lunak yang berfungsi (setiap bulan, setiap dua minggu, mingguan, dll.).
4. Kerjasama antara pemangku kepentingan (pelanggan dan pengembang) di seluruh proyek.
5. Dukungan, kepercayaan dan motivasi dari orang-orang yang terlibat. Tim yang termotivasi lebih mungkin untuk memberikan hasil mereka karya terbaik daripada karyawan yang tidak puas dengan kondisi kerja.
6. Interaksi tatap muka. Komunikasi lebih berhasil ketika tim pengembangan dapat berkomunikasi secara langsung.
7. Perangkat lunak yang berfungsi adalah ukuran utama kemajuan. Memberikan perangkat lunak fungsional kepada klien adalah faktor utama yang mengukur kemajuan.
8. Mempertahankan kecepatan kerja yang konstan. Tim menetapkan tingkat operasi yang berulang dan berkelanjutan di mana mereka dapat memberikan perangkat lunak yang berfungsi.
9. Perhatian terhadap detail teknis dan desain. Keterampilan yang tepat dan desain yang bagus memungkinkan tim untuk mempertahankan momentum, terus meningkatkan produk, dan bekerja pada perubahan.
10. Kesederhanaan.
11. Tim yang mengatur diri sendiri mendorong arsitektur, persyaratan, dan desain yang sangat baik. Anggota tim yang berkualitas dan termotivasi yang memiliki wewenang untuk membuat keputusan secara teratur berkomunikasi dengan anggota tim lain dan bertukar ide yang akan memastikan terciptanya produk yang berkualitas.
12. Adaptasi konstan terhadap perubahan kondisi, yang akan membantu membuat produk lebih kompetitif di pasar.

Dasar dari metode Agile

Dasar dari metode manajemen proyek tangkas adalah sejumlah elemen kunci:

1. Kontrol visual. Peserta proyek menggunakan kartu dengan berbagai warna dan jenis selama mengerjakan proyek, yang menandakan elemen mana dari produk akhir yang telah dikembangkan, direncanakan, diselesaikan, dll. Dengan demikian, tim memiliki representasi visual dari keadaan saat ini. Kontrol visual memastikan visi proyek yang sama oleh masing-masing peserta.
2. Semua peserta proyek bekerja berdampingan, termasuk klien. Pendekatan ini tidak hanya mempercepat banyak proses yang terkait dengan menginformasikan anggota kelompok kerja, tetapi juga menciptakan suasana yang menguntungkan untuk kerjasama dan kerja yang efektif.
3. Manajemen yang dapat disesuaikan. Manajer proyek bukanlah orang yang memberikan instruksi, tetapi seorang pemimpin yang menentukan aturan dasar kerja dan kerjasama.
4. Kolaborasi. Tim, manajer proyek, dan klien bekerja sama, yang menghilangkan kemungkinan kehilangan informasi dan kesalahpahaman tujuan. Selain itu, transparansi semua proses memungkinkan Anda untuk segera menghilangkan masalah yang muncul dan menemukan solusi serta peningkatan yang berhasil.
5. Bekerja berdasarkan pembagian ruang lingkup total proyek menjadi bagian-bagian komponennya. Sistem kerja ini secara signifikan mengurangi kompleksitas proyek dan memungkinkan tim untuk fokus pada setiap bagian secara individual.
6. Bekerja pada kesalahan. Selama pekerjaan satu siklus, tim mempelajari keterampilan baru dan menganalisis kesalahan yang telah terjadi, yang mengecualikan kemunculannya di siklus berikutnya.
7. Sprint dan pertemuan harian. Sprint - periode waktu di mana tim menyelesaikan serangkaian tugas - memungkinkan Anda melihat dengan jelas hasil pekerjaan. Membagi waktu pengerjaan proyek menjadi sprint, kami mendapatkan, misalnya, 10 sprint, masing-masing selama dua minggu. Dan pertemuan harian selama tidak lebih dari 15 menit akan membantu setiap anggota tim menjawab tiga pertanyaan untuk diri mereka sendiri: apa yang saya lakukan kemarin, apa yang akan saya lakukan hari ini, apa yang mencegah saya melakukan pekerjaan?

Demikian perkenalan metode fleksibel Agile dimungkinkan dalam kondisi berikut:

• makna proyek ditunjukkan dengan jelas,
• klien secara aktif terlibat di seluruh proyek,
• kemungkinan implementasi langkah-demi-langkah dari total ruang lingkup proyek,
• hasil pekerjaan lebih penting daripada dokumentasi,
• kelompok kerja tidak lebih dari 7-9 orang.

pada saat ini Metodologi Agile tersebar luas di bidang IT dan mulai menguasai bidang bisnis, khususnya pemasaran, manajemen, pelatihan, dll. Metode manajemen proyek tangkas digunakan oleh banyak perusahaan dan instansi pemerintah, misalnya pemerintah Norwegia dan New Selandia menggunakan Agile. Di Rusia, Sberbank menguasai Agile untuk sektor komersial.

Sistem manajemen proyek berdasarkan Agile

Ada banyak metode berdasarkan ide Agile, yang paling populer adalah Scrum dan Kanban.

SCRUM

Scrum adalah metodologi manajemen proyek yang berfokus pada pengendalian kualitas proses kerja. Hirotaka Takeuchi dan Ikujiro Nonaka, yang pertama menggambarkan pendekatan Scrum, menjelaskannya sebagai “pendekatan rugby”, di mana scrum memperebutkan bola. Metode itu sendiri adalah proses pengembangan yang dibagi menjadi iterasi kecil - sprint, di mana pengguna menerima versi perangkat lunak yang ditingkatkan. Sprint ditetapkan secara kaku dalam waktu, dan durasinya dari 2 hingga 4 minggu. Pekerjaan dalam satu sprint terdiri dari beberapa tahap:

1. Merencanakan lingkup pekerjaan untuk satu sprint.
2. Rapat harian selama 15 menit untuk mengoreksi pekerjaan tim dan meringkas hasil antara.
3. Demonstrasi hasil kerja.
4. Sebuah retrospektif sprint meninjau keberhasilan dan kegagalan sprint terakhir.

Scrum paling sering digunakan untuk mengelola perangkat lunak yang kompleks dan pengembangan produk menggunakan metode iteratif dan inkremental.

Scrum sangat meningkatkan produktivitas dan mengurangi waktu untuk keuntungan dari proses "air terjun" klasik. Proses scrum memungkinkan organisasi untuk beradaptasi secara mulus dengan persyaratan yang berubah dengan cepat dan menciptakan produk yang memenuhi tujuan bisnis yang berubah. Scrum memungkinkan Anda untuk:

• Meningkatkan kualitas hasil;
• Lebih baik menghadapi perubahan;
• Memberikan perkiraan yang lebih akurat, menghabiskan lebih sedikit waktu untuk membuatnya;
• Lebih baik untuk mengontrol skenario proyek dan tahapan pekerjaan.

Kanban

Kanban adalah proses yang dirancang untuk membantu tim bekerja sama secara lebih efektif. Dalam bahasa Jepang, kanban berarti " papan iklan, papan nama”, dan metode itu sendiri diambil dan diadaptasi dari sistem produksi Toyota. Inti dari Kanban adalah membuat proses pengembangan setransparan mungkin dan mendistribusikan beban secara merata di antara anggota tim. Kanban mempromosikan kolaborasi berkelanjutan dan mendorong pembelajaran dan peningkatan yang aktif dan berkelanjutan.

Kanban didasarkan pada tiga prinsip:

1. Visualisasi tugas: visibilitas semua informasi tentang proyek akan membantu untuk melihat kekurangan, kesalahan, dan overlay.
2. Kontrol dan batasan WIP (work in progress): Ini membantu menyeimbangkan pendekatan threading sehingga tim tidak memulai dan melakukan terlalu banyak pekerjaan sekaligus.
3. Kontrol waktu untuk menyelesaikan tugas dan optimalkan pekerjaan untuk menghemat waktu.

Kelebihan dan kekurangan Agile

Setiap metodologi memiliki kelebihan dan kekurangan. Pertimbangkan pro dan kontra dari Agile.

Keuntungan

1. Lebih fleksibel dibandingkan dengan metodologi Waterfall.

Metodologi tradisional air terjun dengan jelas menentukan tahapan pekerjaan. Dengan metodologi Agile, jadwal dan biaya adalah penentu utama, dan ini adalah area yang berubah untuk memenuhi persyaratan pelanggan dan konsumen produk.

2. Lebih sedikit cacat pada produk akhir.

Ini adalah hasil dari pemeriksaan kualitas yang dilakukan pada setiap tahap pekerjaan. Proses berkelanjutan"mengembangkan, membangun, dan menguji" juga mengurangi cacat saat siklus iterasi berlanjut.

Kekurangan

1. Terus-menerus menerima umpan balik menyebabkan penundaan terus-menerus dari tanggal penyelesaian proyek.

Dengan umpan balik instan yang diberikan Agile, ada bahaya kerja panjang. Pengguna akhir yang melihat bahwa persyaratan ini dapat dipenuhi "dengan mudah" (mereka hanya melihat hasil, bukan upaya) akan meminta fitur tambahan. Jika manajer proyek dan pengembang tidak dapat mengelola ekspektasi, pengguna akhir akan terus meminta lebih banyak hingga seluruh tim dipenuhi dengan pekerjaan ekstra.

2. Dokumentasi

Karena sifat Agile yang fleksibel, dokumentasi harus mengikuti kondisi proyek yang berubah dengan cepat. Perubahan atau permintaan fitur dapat didiskusikan secara rinci dan disepakati dengan pengguna akhir, pengembang, dan penguji, tetapi kecuali jika tim telah diberi pengarahan, dokumen penting seperti manual pengguna, dokumen arsitektur, atau kebutuhan fungsional, akan menjadi usang.

3. Sering bertemu

Sementara Agile merekomendasikan agar pertemuan ini diadakan setiap hari untuk membuat semua orang mengetahui kemajuan masing-masing, keberlanjutan praktik ini berdampak pada kemajuan iterasi. Pengembang fokus pada apa yang mereka lakukan. Menarik mereka keluar untuk rapat yang mungkin mengalihkan perhatian mereka dari melakukan kerja nyata, bukanlah sesuatu yang akan mereka terima dengan senang hati.

Implementasi Agile

1. Pilihan metodologi. Ada berbagai metodologi fleksibel yang dikembangkan dalam kondisi tertentu. Langkah pertama dalam bekerja dengan Agile adalah menentukan tujuan tugas kerja, tenggat waktu, jumlah karyawan dan banyak lagi dan memilih metodologi manajemen proyek yang fleksibel yang akan memenuhi semua persyaratan.
2. Pelatihan. Pelatihan diperlukan agar karyawan memahami prinsip-prinsip dasar Agile dan mengetahui cara bekerja dengan mereka. Pada tahap inilah jebakan diidentifikasi yang dapat mengurangi Efisiensi tangkas. Apakah tim siap untuk berubah? Apakah proyek perusahaan cocok untuk praktik tangkas? Ini dan banyak pertanyaan lainnya biasanya dijawab oleh pelatih bisnis Agile. Antara lain, daftar pelatihan dan rencana juga akan disusun, yang menurutnya implementasi Agile di perusahaan akan dilakukan.
3. Demo gesit. Semacam test drive Agile, yang dilakukan di bawah pengawasan seorang spesialis dan menunjukkan semua tahapan pekerjaan, menjelaskan fungsi peran, interaksi dalam tim dan antar tim, dll.
4. Pembentukan tim. Selain pemilihan karyawan, pembuatan tim juga mencakup definisi tanggung jawab, pembagian tugas, pembuatan jadwal rapat, dll. Setiap metode dirancang untuk sejumlah tertentu orang dalam tim.
5. Pemilihan alat diperlukan untuk distribusi tugas, pelaporan, analitik, dan banyak lagi.
6. Proyek pertama dengan Agile. Dalam proyek pertama, akan ada kesalahan, inkonsistensi, penolakan beberapa alat dan pilihan yang lain. Teknik apa pun membutuhkan semacam adaptasi dengan karakteristik perusahaan tempat penerapannya.

Jika Anda menemukan kesalahan, sorot sepotong teks dan klik Ctrl+Enter.

Sulit untuk menemukan orang yang tidak ingin diperlakukan dengan hormat. Tapi pasti ada alasan untuk keadaan ini. Misalnya, ketika seseorang adalah spesialis yang diakui berkualifikasi tinggi di bidang pengembangan perangkat lunak. Dan untuk ini Anda perlu belajar. Dan dalam kerangka artikel ini, kami akan mempertimbangkan apa itu Agile, apa gunanya, dan bagaimana memahami teknologi ini.

informasi Umum

Pertama, mari kita berurusan dengan masalah teknis. Apa itu Agile? Terjemahan (harfiah) dari kata ini dari bahasa inggris- "langsung, seluler", "fleksibel" lebih jarang disebutkan. Dan omong-omong, itu adalah singkatan. Nama lengkap dari pendekatan ini adalah Lincah pengembangan perangkat lunak. Namun karena terlalu panjang, diputuskan untuk dipotong. Dan sekarang mereka hanya mengatakan Agile. Terjemahan sebagai "fleksibel" digunakan karena fakta bahwa itu paling cocok dengan situasi nyata.

Apa yang termasuk di sini?

Kami terus mempertimbangkan apa itu Agile. Di sini saya ingin fokus pada fakta bahwa ini adalah pendekatan yang fleksibel, yang didasarkan pada banyak XP, "Kanban", Lean yang berbeda). Untuk lebih memahami topik, mari kita menggambar paralel. Katakanlah teknologi Agile adalah proses lahirnya Alam Semesta. Produk akhir adalah dunia nyata itu sendiri. Dan big bang adalah masalah paling menyakitkan yang harus Anda hadapi - mengubah daftar persyaratan produk. Biasanya, proses pembuatan melibatkan penggunaan model air terjun. Dalam hal ini, semuanya berjalan berurutan dan bertahap. Pendekatan ini dapat diungkapkan secara singkat: Saya melihat tujuannya - saya pergi ke sana. Dan jika persyaratan untuk hasil akhir berubah, maka terkadang Anda harus mengulang hampir semuanya lagi. Yang lebih memperumit situasi ini adalah upaya untuk berpura-pura bahwa semuanya baik-baik saja dan bahwa kita perlu bergerak maju.

Dan inilah manajemennya, yang dirancang untuk menangani semua ini berkat fleksibilitasnya. Gado-gado ini meminimalkan berbagai risiko melalui penggunaan serangkaian prinsip. Semuanya tercermin dalam Agile Manifesto, dirilis pada tahun 2001. Secara singkat, mereka terdengar seperti ini:

1. Yang utama adalah orang, bukan barang.
2. Berkolaborasi, jangan membaca kontrak.
3. Dokumentasi tidak boleh mengganggu pekerjaan.
4. Berubah secepat mungkin.

Ini mungkin tampak terlalu kabur dan tidak akurat, tapi mari kita perinci.

Proses desain

Mempertimbangkan apa itu Agile, mari kita beralih ke salah satu metodologi paling populer yang dikenal sebagai "Scrum" (Scrum). Apa yang dia tawarkan? Untuk memulai, Anda perlu:

1. Pilih pemilik produk. Peran ini cocok untuk orang yang melihat tujuan apa yang harus Anda tuju, dan apa yang akan terjadi pada akhirnya.
2. Tentukan tim. Ini membutuhkan sekelompok tiga sampai sepuluh orang yang memiliki keterampilan untuk mendapatkan hasil.
3. Pilih orang yang bertanggung jawab. Ini adalah orang yang akan memantau perkembangan proyek dan membantu tim mengatasi kesulitan.
4. Hadapi kesulitan. Semua persyaratan produk yang ada harus dikumpulkan di satu tempat dan diprioritaskan. Pemilik produk harus mengumpulkan semua keinginannya di sini. Kemudian tim mengevaluasi mereka dan memahami apakah itu dapat diterapkan, dan berapa banyak waktu yang dibutuhkan untuk ini.
5. Anda harus membagi seluruh lingkup pekerjaan ke dalam periode waktu, satu atau dua minggu, di mana tim akan melakukan serangkaian tugas tertentu.
6. Rapat harus diadakan setiap hari, tidak lebih dari lima belas menit. Agendanya harus membahas apa yang sudah dilakukan kemarin, apa rencana hari ini, dan kendala yang menghalangi kita untuk naik ke atas.
7. Buat review di akhir minggu (dua), di mana tim berbicara tentang apa yang telah dilakukan. Pada saat yang sama, perlu untuk menunjukkan kinerja bagian-bagian produk.
8. Setelah setiap periode waktu, masalah harus didiskusikan dan solusi dicari. Apalagi semua pembangunan harus segera dilaksanakan.

Bagaimana cara mengenali Agile?

Metodologi manajemen, terlepas dari arah yang dipilih, selalu memiliki fitur berikut:

1. Minimalkan risiko. dia tujuan utamanya bahwa setiap pendekatan fleksibel mengejar.
2. Pengembangan berulang. Dalam hal ini, bekerja dalam siklus kecil tersirat.
3. Yang paling penting adalah orang-orang dan komunikasi di antara mereka.

Mari kita bayangkan sebuah sungai. Di satu sisi pelanggan. Yang kedua adalah tim. Dalam hal ini, metodologi pengembangan tangkas memiliki keuntungan untuk semua orang:

1. Pelanggan menginginkan produk yang layak minimum. Pada saat yang sama, kondisi dapat berubah selama pembuatannya.
2. Berguna bagi tim untuk berkomunikasi dengan kolega dan pelanggan. Dalam hal ini, risiko kesalahpahaman diminimalkan, transparansi proses meningkat, masalah cepat diselesaikan, dan kemungkinan kejutan saat membuat produk berkurang.

faktor sosial

Ketika membicarakan apa itu Agile, biasanya mereka hanya membicarakan hal-hal yang positif. Memang, komunikasi dalam tim membaik. Semua orang fokus pada satu ide, jangan membuat rahasia di antara mereka sendiri, buat komitmen. Hasilnya, tim bekerja dalam kondisi yang nyaman dan dalam tempo yang cepat. Pendekatan ini memungkinkan Anda untuk merampingkan kekacauan.

Sejak pembentukannya, telah mampu menemukan pengakuan di industri teknologi. Saat ini banyak digunakan untuk mendesain baru produk perangkat lunak. Namun dalam praktik bisnis secara umum, pendekatan ini masih sedikit diketahui. Karena itu, mereka yang belum pernah bertemu Agile sebelumnya berhati-hati tentang hal itu. Juga harus dipahami bahwa itu harus digunakan hanya dalam kasus-kasus di mana orang dihadapkan dengan tugas kerja intelektual.

Contoh kecil

Mari kita lihat bagaimana metodologi pengembangan perangkat lunak ini bekerja. Katakanlah kita memiliki Peter, pemilik produk. Dia tidak tahu detail teknisnya, tetapi dia memiliki visi gambaran besar. Dia tahu mengapa produk itu dibutuhkan, masalah apa yang akan dipecahkannya, dan siapa yang akan memuaskannya. Ada juga pihak yang berkepentingan. Mereka dapat menggunakan produk, mendukung pembuatannya, atau terlibat dalam pembuatannya. Anda juga dapat menambahkan cerita pengguna yang mengungkapkan keinginan pihak yang berkepentingan. Misalnya: sistem pemesanan tiket bus reguler Moskow-St. Petersburg harus memiliki pencarian penerbangan. Petrus akan membantu orang-orang yang berminat. Ini akan mengambil kendali implementasi dari ide cerita pengguna. Ada juga tim pengembang. Inilah orang-orang yang akan membangun sistem kerja.

Karena metodologi pengembangannya gesit, cerita pengguna tidak diakumulasikan hingga rilis besar, tetapi dirilis segera setelah selesai dan sesering mungkin. Jumlah permintaan yang diproses adalah throughput mingguan tim. Agar tidak kehilangan momentum dan terjebak dalam pengujian manual, tim harus bekerja pada integrasi otomatis. Apa itu? Tes otomatis ditulis untuk setiap momen kerja. Jika terlalu banyak cerita, maka bisa terjadi terburu-buru, kehilangan motivasi, kehilangan produktivitas dan kualitas. Untuk kasus seperti itu, metode "cuaca kemarin" disediakan. Itu terletak pada kenyataan bahwa Anda perlu menetapkan batasan ketat pada jumlah pekerjaan dan dengan hati-hati memilih apa yang sebenarnya akan diterapkan. "Kanban" yang disebutkan sebelumnya menyarankan pengaturan batas tugas.

Apa yang harus dilakukan dengan antrian?

Oke, jadi tim memutuskan bahwa mereka dapat memproses empat cerita seminggu. Tapi bagaimana menavigasi dalam segala hal itu? Katakanlah pengguna mengunggah sepuluh cerita seminggu. Empat sedang diproses. Dengan demikian, antrian akan terus bertambah. Dalam hal ini, hanya ada satu metode yang efektif- kata "tidak". Bagi pemilik produk, ini sangat penting. Mengatakan "ya" tidak sulit. Jauh lebih sulit dan lebih penting untuk memutuskan apa yang tidak boleh dilakukan. Selain itu, perlu juga memikul tanggung jawab untuk ini. Karena itu, perlu diputuskan apa yang harus diperhatikan sekarang, dan apa yang harus ditunda. Untuk melakukannya dengan benar, pemilik produk perlu memahami nilai dan ruang lingkup setiap cerita.

Kami membuat keputusan

Beberapa cerita sangat diperlukan. Yang lain hanyalah bonus yang bagus. Beberapa cerita akan memakan waktu beberapa jam untuk berkembang. Lainnya akan membutuhkan waktu berbulan-bulan untuk menyelesaikannya. Banyak yang sering menarik korelasi antara ukuran sebuah cerita dan nilainya. Tapi ini tidak selalu benar. Lebih banyak tidak sama dengan lebih baik. Kompleksitas dan nilai tugas yang ada membantu Peter untuk memprioritaskan dengan benar. Bagaimana karakteristik ini dapat diukur? Tidak mungkin. Ini adalah permainan tebak-tebakan yang sebenarnya. Dan untuk efektivitas yang lebih besar, perlu melibatkan banyak orang di dalamnya. Ini adalah tim pengembang, yang akan menginformasikan tentang ruang lingkup pekerjaan, dan pihak yang berkepentingan. Tetapi perlu dipahami bahwa semua data yang diperoleh dengan cara ini adalah tebakan perkiraan. Tidak ada angka pasti di sini. Awalnya, akan ada rindu. Tetapi saat Anda mendapatkan pengalaman, jumlah dan skala mereka akan berkurang.

Risiko yang mungkin terjadi

Untuk menghindari masalah, perlu untuk memberikan jawaban yang jujur ​​​​untuk sejumlah pertanyaan. Dia:

1. Apakah kita melakukan hal yang benar? Ini adalah risiko bisnis.
2. Bisakah kita menerapkan apa yang kita butuhkan?
3. Apakah proyek akan bekerja pada platform ini. Ini adalah risiko teknis.
4. Apakah ada cukup uang, dan apakah kita punya waktu? Ini adalah risiko dari segi implementasi dan biaya.

Dalam hal ini diperlukan pengetahuan. Mereka dapat dilihat sebagai kebalikan dari risiko. Ketika tingkat ketidakpastian yang signifikan diperbaiki, maka kami memperoleh pengetahuan - misalnya, kami membuat prototipe antarmuka atau eksperimen teknis. Dan sudah memilikinya, kami membuat keputusan tentang arah di mana kami harus bergerak.

Bagaimana cara belajar?

Industri TI berkembang sangat pesat, dan agar tidak kalah pada akhirnya, perlu terus belajar, meningkatkan keterampilan, dan efisiensi kerja. Oleh karena itu, masalah pelatihan dan implementasi menjadi lebih relevan dari sebelumnya. Di mana untuk memulai? Paling pilihan terbaik- ini adalah kerjasama dengan perusahaan dimana Agile sudah diterapkan. Pelatihan dalam hal ini akan dilakukan oleh orang-orang yang tidak tahu dengan desas-desus apa itu pengembangan tangkas. Tapi, sayangnya, ini tidak selalu memungkinkan. Paling sering, spesialis pihak ketiga terlibat yang tahu apa itu Agile. Pelaksanaan pendekatan ini dilakukan di bawah pengawasannya. Benar, layanan spesialis semacam itu membutuhkan biaya. Tetapi jika Anda mendapatkan orang yang benar-benar berpengetahuan, maka semua biaya akan terbayar dengan mahal. Lagipula, di dunia modern Kinerja karyawan memegang peranan penting.

Apa yang ada untuk masa depan?

Metodologi pengembangan perangkat lunak terus berkembang. Mencari cara dan peluang baru untuk meningkatkan efisiensi kegiatan dan pekerjaan. Agak bermasalah untuk mengatakan apa yang akan terjadi di masa depan bagi kita. Mungkin, sistem pengembangan yang fleksibel akan diintegrasikan dengan alat otomatisasi proses produksi. Misalnya, akan mungkin untuk memecahkan masalah bahkan saat berada jauh dari lokasi perusahaan. Dalam banyak hal, masa depan ditentukan oleh hal baru Teknologi Informasi. Lagi pula, ketika mereka muncul, Anda perlu menguasai metode baru untuk bekerja dengan mereka. Dan dalam hal ini ada perkembangan yang tertutup dalam suatu siklus.

Akhirnya

Jadi perjalanan ke yang fleksibel berakhir.Tetapi harus diingat bahwa teori adalah satu hal, dan praktik adalah hal lain. Teknologi informasi baru yang terus bermunculan menantang komunitas pengembang besar. Bagaimana Anda bisa membuat tim Anda lebih efisien? Setiap orang menemukan jawaban untuk pertanyaan ini sendiri. Informasi yang disajikan di sini dapat digunakan untuk membentuk tulang punggung. Namun dalam praktiknya, Anda harus bekerja dengan model yang ada dan membawa keadaan ke keadaan sesuai dengan tantangan yang ada. Kemudian tim akan dapat secara efektif memenuhi tujuannya.