Analisis lincah. Mitos dan Realita

Pendahuluan

Gerai harus dipindahkan! Tidak ada musim, sehingga beberapa orang tidak shandarah.
Sekarang bingung dengan toilet, lalu dengan kabin pantai ...
(x / f Fitur memancing nasional)

Akhir tahun, meringkas, mengisi kuesioner dan pernak-pernik pra-liburan IT lainnya. Untuk kesekian kalinya saya menarik perhatian dari kuesioner akhir perusahaan IT, yang dirancang untuk mengidentifikasi tren dalam pendekatan pengembangan produk. Dan setiap kali ada perasaan semacam trik ketika Anda menjawab pertanyaan seperti: "Anda masih menggunakan metode Air Terjun (model air terjun), atau Anda masih (seperti semua manusia lanjut) berlatih Agile (metodologi fleksibel)." Ketika Anda mulai mencari tahu dari penulis jajak pendapat ini, dan apa yang dia pahami oleh Agile, penjelasannya entah bagaimana tidak terlalu cocok dengan garis besar manifesto (Agile Manifesto). Dia benar-benar memikirkan banyak prinsip untuk pertama kalinya dan prinsip-prinsip ini langsung membuatnya terhenti. Tetapi setelah sedikit kebingungan, artileri berat dengan pembuktian konkrit dari posisi kami digunakan: "Kami tidak bekerja pada Air Terjun, jadi Agile."

Tesis Metodologi Fleksibel itu sendiri sangat gutta-percha dalam bunyinya sehingga banyak yang mencoba memerasnya apa saja, atau lebih tepatnya, apa yang paling bermanfaat bagi mereka. Secara bertahap, itu menjadi layar modis, yang dapat mencakup segala macam kekurangan dan bahkan kecerobohan, dalam proses pembuatan produk-produk TI, dan pada saat yang sama, seolah-olah untuk tetap berada di puncak gelombang, dalam tren. Seperti kita tidak seperti itu - tetapi teknik seperti itu.

Mari kita bersama-sama, sekali lagi "menyerang dengan analisis" pada topik metodologi Fleksibel, mencoba memilah artefak utama dan prinsip-prinsip di rak-rak dan memisahkan makna sakral yang awalnya diletakkan dalam konsep ini dari apa yang individu populis lalai mengubahnya menjadi. Kami juga membandingkan pendekatan Agile dengan metode lain untuk pemahaman yang lebih akurat tentang garis yang memisahkannya, atau sebaliknya - menggabungkannya. Pada saat yang sama, mari kita coba mencari tahu di mana penggunaan prinsip Agile paling tepat, dan di mana itu tidak sepenuhnya tepat?

II Latar belakang munculnya teknik pengembangan produk perangkat lunak

Sejarah seperti pasta daging: lebih baik tidak mengintip bagaimana dimasak.
Aldous Huxley

Demi objektivitas, mari selami sejarah dan rasakan keadaan yang membentuk landasan di mana berbagai prinsip dan metode pengembangan produk perangkat lunak, termasuk yang Fleksibel, telah matang.

1. Mitos dan kenyataan tentang Air Terjun

Seperti yang telah disebutkan dalam pendahuluan, antagonisme (persembahan korban) untuk Agile (1) dipilih teknik Waterfall, yang dalam bentuk murni relevan pada abad terakhir, pada saat kartu punch dan tape drive dan pertama kali diperkenalkan ke dunia dalam sebuah artikel oleh W.W. Royce ( WW Royce), diterbitkan pada tahun 1970.

Perbandingan seperti itu tidak diragukan membantu metodologi lain untuk terlihat segar dan inovatif dibandingkan dengannya. Beberapa pembicara, untuk keyakinan yang lebih besar, menghadirkan model Waterfall bukan sebagai iteratif, tetapi sebagai aliran monolitik satu kali, dari fase berturut-turut: analisis persyaratan, desain, implementasi, pengujian, integrasi, dan dukungan. Saya sangat tersentuh oleh ungkapan tentang metode pengembangan, yang diamati dalam artikel, sampai periode Ajail: “Sebelumnya, produk dibuat segera secara keseluruhan. Untuk melakukan ini, kami menyusuri rantai: ide → kerangka acuan → desain → pemrograman → pengujian → rilis. " Maaf, tapi Royce menggunakan model pengembangan berulang dalam pendekatannya. Menyederhanakan ide dengan cara sinis tidak lagi etis, terutama mengingat bahwa tidak ada kekosongan antara Waterfall dan Agile, tetapi rantai evolusi yang agak panjang.

Meskipun adil, saya harus mengakui bahwa sebagian besar dari apa yang dikatakan tentang Waterfall, secara umum, tidak jauh dari kebenaran. Jika tim pada tahap tertentu menyadari bahwa hasilnya tidak memenuhi harapan, maka mereka “menghabisi” produk yang kurang tepat, atau melemparkan sebagian besar pekerjaan ke keranjang, dan memulai prosesnya hampir sejak awal, benar-benar menciptakan produk baru. Mengapa, terlepas dari beberapa absurditas dengan standar pendekatan semacam ini, teknik ini telah lama tetap menjadi unggulan populer di dunia pengembangan perangkat lunak?

Untuk memahami fenomena ini, kita akan terjun ke atmosfer Pusat Komputasi (CC) saat itu. Izinkan saya mengingatkan Anda bahwa pada saat-saat yang jauh dan jauh, jalan dari desain pengembang ke eksekusi komputernya panjang dan berduri. Dia berlari melalui perangkat persiapan data yang sudah terlupakan yang melakukan meninju mekanik kartu berlubang dan dengan sayang disebut "barmales". Operasi ini dilakukan bukan oleh pengembang sendiri, tetapi oleh orang-orang yang terlatih khusus. Setelah menerima paket berharga dari kotak kardus berlubang, sesuai urutan prioritas, dengan mempertimbangkan operabilitas komputer, kartu berlobang ini dimasukkan ke dalam perangkat khusus (sekali lagi, orang-orang yang terlatih khusus) yang membaca kode dan hanya setelah itu, ia memiliki kesempatan untuk dieksekusi oleh prosesor. Tetapi jika salah satu kartu punch di deck macet selama membaca, Anda harus mengulangi prosedur untuk membaca seluruh deck lagi. Dan Tuhan melarang, kesalahan dimanifestasikan dalam kode, perlu untuk menggunakan bantuan "barmaley" lagi, untuk mengganggu bagian dari kartu berlubang dan, tanpa membingungkan mereka dengan tempat-tempat di geladak, ulangi seluruh prosedur sekali lagi dari awal. Dengan pesona seperti itu, karya para programmer saat itu selalu bertebaran. Tentu saja, perubahan cepat dalam persyaratan untuk produk yang dikembangkan dalam pelaksanaannya, dengan pendekatan seperti itu, tidak mungkin. Persyaratan berkualitas tinggi untuk produk yang sedang dikembangkan dan proses produksinya yang diatur secara ketat adalah untuk Semua tim.

2. Bagaimana jika bukan Air Terjun?

Tetapi waktu berlalu dan segalanya berubah. Komputer pribadi secara bertahap menjadi kapsul bagi dunia digital, menggusur monster-monster besar yang berderak di halaman belakang. Jumlah operasi yang dilakukan oleh prosesor per unit waktu telah meningkat dengan beberapa urutan besarnya, dan kecepatan operasi input / output informasi tampaknya “kosmik”. Programmer mendapat akses langsung dan instan ke eksekusi kode yang baru saja diketik dari keyboard - sumber daya komputasi, tanpa meninggalkan tempat. Sekarang menjadi jauh lebih mudah untuk membuat perubahan pada perangkat lunak, dan sudah membayangkan bahwa orang lain terus bekerja sesuai dengan metode Waterfall dalam bentuk murni itu benar-benar konyol.

Seleksi alam dan perlunya adaptasi memaksa teknik untuk bermutasi. Selain itu, sebagian besar dari mereka meminjam model pengembangan berulang dari pendahulunya. Sederhananya, siklus eksekusi telah dikurangi dan ditingkatkan secara signifikan.

Tapi kemudian kemalangan lain muncul. Kesempatan yang belum pernah terjadi sebelumnya telah memungkinkan dari otomatisasi bagian produksi individu untuk pergi ke otomatisasi seluruh perusahaan dan bahkan untuk menyapu sepenuhnya pada industri. Dengan volume operasi yang demikian dan jumlah sumber daya yang terlibat, tidak mungkin untuk sekadar menyederhanakan metode pengembangan perangkat lunak. Sebaliknya, mereka menjadi lebih menyapu dan diformalkan.

Salah satu teknik yang paling terkenal menggunakan model pengembangan berulang adalah Rational Unified Process (RUP). Ini dikembangkan dan diimplementasikan pada paruh kedua 1990-an di Rational Software.

Istilah RUP menyembunyikan tidak hanya metodologi pengembangan perangkat lunak, tetapi juga seperangkat alat yang memungkinkan Anda untuk mengelola proses pengembangan. Dalam kerangka topik ini, sangat menarik untuk dicatat bahwa metodologi RUP (2) menggambarkan proses umum abstrak atas dasar di mana organisasi atau tim proyek dapat membuat proses pengembangan perangkat lunak sendiri yang unik, yang berfokus pada kebutuhan mereka sendiri. Bagaimana menurut Anda pendekatan ini tidak fleksibel?

Dengan analisis dan perbandingan lebih lanjut, dapat dicatat bahwa beberapa fitur utama RUP juga sebagian diwarisi dari teknik Waterfall.

1. Pendekatan siklus untuk produksi perangkat lunak . Siklus hidup proyek RUP dibagi menjadi 4 fase dan 9 proses kerja.
2. Proses pengembangan berulang . Proyek RUP terdiri dari urutan iterasi dengan durasi yang direkomendasikan 2 hingga 6 minggu.
3. Pengembangan persyaratan wajib . RUP menggunakan kasus penggunaan atau kasus penggunaan untuk menggambarkan persyaratan. Setiap use case adalah deskripsi dari skenario interaksi pengguna dengan sistem yang sepenuhnya melakukan tugas pengguna tertentu.
4. Pendekatan tambahan yang bertujuan meningkatkan fungsi produk secara bertahap. Unit utama perencanaan iterasi adalah use case, yang memungkinkan Anda untuk melakukan perubahan yang diperlukan untuk persyaratan, merancang keputusan, dan implementasi selama proyek.

Kami memberikan perhatian khusus pada poin terakhir. Ini menyatakan bahwa itu adalah adanya persyaratan rinci yang disusun dalam bentuk tertentu yang hanya menyediakan kemampuan untuk secara efektif membuat perubahan pada keputusan desain dan implementasi produk selama proyek. Termasuk di tahap akhir proyek.

RUP sering keliru dianggap sebagai proses kelas berat dengan tingkat formalisme yang tinggi. Tetapi ini tidak sepenuhnya benar, karena proses RUP dapat (dan harus) disesuaikan dengan spesifikasi organisasi dan proyek tertentu. Bahkan jika tim mengambil produk perangkat lunak kecil yang perlu dikembangkan lebih lanjut, ditingkatkan atau diintegrasikan dengan sistem lain, maka RUP akan memungkinkannya untuk cukup nyaman mengatasi semua tantangan yang muncul.

3. Penggulingan fondasi

Dan lebih dari itu. Setelah melewatkan periode munculnya komputer pribadi ke dunia kita, kita beralih ke tampilan semua jenis studio alat, alat visualisasi dan pemodelan, pembuat aplikasi otomatis, dll. Dalam semua variasi asisten ini, memungkinkan, misalnya, untuk menyeret elemen pada diagram dengan mouse dan secara otomatis mengubah kode aplikasi untuk produk akhir, ia mulai meremehkan peran teknik pengembangan perangkat lunak. Memiliki alat canggih seperti itu, dengan kekurangan waktu atau sumber daya, Anda dapat meninggalkan beberapa alur kerja metodologi dan pada saat yang sama benar-benar tidak kehilangan apa-apa. Setidaknya dalam jangka pendek. Kebebasan-kebebasan ini dan, pada gilirannya, impunitas, dengan profesionalisme yang tinggi dari para pemain, memimpin para pemimpin yang paling putus asa untuk memproklamasikan tren TI baru - "Metodologi pengembangan yang fleksibel."

Di sini, di tempat ini dari garis merah, saya sekali lagi menekankan tesis yang sangat penting, mungkin yang utama - "dengan profesionalisme yang pantas"! Yaitu, spesialis kelas tinggi yang memiliki puluhan proyek selesai skala besar di belakang kepala mereka, yang mampu membuat sketsa diagram kelas dari modul kecil di kepala mereka dalam 20 menit, segera memperkirakan proses mengubah negara mereka, menyarankan ketergantungan kritis, dll. memutuskan bahwa mereka dapat, dalam beberapa kasus, melakukannya tanpa pengesahan wajib dari peraturan yang diadopsi. Pada saat yang sama, proyek akan tetap dibawa ke hasil yang diharapkan dengan kualitas yang dapat diterima dalam waktu yang jauh lebih singkat. Apakah itu baik atau buruk? Pada pandangan pertama, ini luar biasa. Pada yang kedua, tidak semuanya begitu sederhana. Kami akan menganalisis pro dan kontra sedikit kemudian.

Jelas buruk di sini adalah hal lain. Muda dan berani, melihatnya dari samping, mengajukan pertanyaan: "Tapi apa, apakah itu mungkin?" Mereka tidak pernah melihat persyaratan kualitas di mata mereka, mereka tidak bisa membaca diagram, tetapi sekarang mereka tidak membutuhkannya. Itu saja! persyaratan sekarang dibatalkan! Diagram, proses pemodelan - ada di tungku. Hanya kode, kode, dan komunikasi. Sebagai bonus - mereka dapat meninggalkan komentar mereka dalam kode untuk generasi masa depan yang kurang ajar yang sama.

Pada ini, perjalanan sejarah dapat diselesaikan dan dipindahkan sehingga untuk berbicara lebih dekat ke tubuh ...

III. Analisis fenomena metodologi yang fleksibel

Setiap entitas harus dianalisis dalam hal logika sebelum menempelkannya di mulut Anda.
Woody Allen.

1. Definisi Metodologi yang Fleksibel

Karena Adjayl telah ada selama bertahun-tahun, mari manfaatkan informasi yang tersedia dan mulailah dengan meninjau definisi dan pendapat yang berada di puncak jaringan. Dan setelah menjauh dari mereka, kita akan beralih ke artifak utama - Manifesto pengembangan perangkat lunak yang fleksibel.

Hal pertama yang ditemukan di mesin pencari oleh istilah Agile:

Metodologi pengembangan fleksibel (pengembangan perangkat lunak gesit, metode gesit) adalah serangkaian pendekatan untuk pengembangan perangkat lunak yang berfokus pada penggunaan pengembangan berulang, pembentukan persyaratan yang dinamis dan memastikan implementasinya sebagai hasil dari interaksi yang konstan dalam kelompok kerja yang mengatur diri sendiri yang terdiri dari spesialis berbagai profil.

Poin-poin penting berikut dapat dibedakan dari definisi ini:

1. Menggunakan Pendekatan Iteratif . Tidak ada yang baru di sini, saya belum pernah mendengar tentang metode pengembangan perangkat lunak yang menyangkal prinsip ini;
2. Pembentukan persyaratan dilakukan secara bertahap, dalam perjalanan pengembangan produk . Ini adalah perbedaan utama dari banyak teknik lainnya. Dalam beberapa hal itu memberi keuntungan, dalam beberapa hal memperkenalkan batasan mendasar. Kami akan membahas keduanya nanti;
3. Menggunakan interaksi dekat yang konstan dari semua anggota tim , termasuk pelanggan. Sebagian besar metodologi lain, tentu saja, memperhatikan kerja tim, termasuk dengan pelanggan, tetapi memposisikan komunikasi ini sebagai sumber daya proyek tambahan yang memberikan keuntungan absolut lebih eksklusif;
4. Tim yang mengatur diri sendiri . Diasumsikan bahwa setiap iterasi berakhir dengan pembekalan dan perubahan konstruktif dalam proses, yang berkontribusi pada pengembangan tim yang berkelanjutan. Teknik serupa kemungkinan besar dipinjam dari teknik sebelumnya. Misalnya, ia menjalankan RUP.

Pada prinsipnya, kami tidak berhasil menemukan banyak dari uraian ini, jadi mari kita beralih ke klarifikasi:

Sebagian besar metodologi yang fleksibel bertujuan untuk meminimalkan risiko dengan mengurangi pengembangan ke serangkaian siklus pendek yang disebut iterasi, yang biasanya berlangsung dua hingga tiga minggu. Setiap iterasi dengan sendirinya terlihat seperti proyek perangkat lunak dalam miniatur dan mencakup semua tugas yang diperlukan untuk menghasilkan peningkatan mini dalam fungsionalitas: perencanaan, analisis persyaratan, desain, pemrograman, pengujian dan dokumentasi.

Tapi kami sudah mempertimbangkan pendekatan yang sama dalam RUP lama yang baik. Artinya, tidak ada yang secara fundamental baru di sini.

Sebagian besar definisi yang saya temukan juga abstrak dan kabur, ada sedikit informasi yang memungkinkan Anda untuk segera mengambil dan mulai menggunakan fleksibilitas. Tetapi di sini aspek lain yang sama pentingnya dari pendekatan ini terbuka, yang memberikan kejelasan pada kedangkalan yang dilalui oleh seluruh topik yang dibahas. Berikut ini sebuah contoh:

Agile tidak termasuk praktik, tetapi mendefinisikan nilai dan prinsip yang memandu tim. Agile adalah keluarga proses pengembangan, bukan satu-satunya pendekatan untuk pengembangan perangkat lunak, dan didefinisikan oleh Agile Manifesto.

Agile adalah cara berpikir dengan sistem nilainya sendiri. Ini mirip dengan filsafat, agama atau budaya - serangkaian sikap yang sama yang seseorang yakini dan yang memengaruhi perilakunya.

Rupanya karena alasan ini, ada banyak perselisihan seputar Metodologi Fleksibel. Tidak banyak ide tentang apa yang benar-benar dapat Anda rasakan. Rupanya karena ini, Anda dapat memanggil sesuatu dari Anda sendiri (hampir semua), metodologi yang tidak konvensional - fleksibel dan tidak terjebak dalam ketidak profesionalan. Menurut pendapat saya, ini dapat diterima, jika Anda ingin berada dalam tren, sebutkan pendekatan Anda untuk pengembangan yang modis, jika hanya proses pengembangan dan produk akhir itu sendiri tidak akan menderita.

Saya ingat sebuah kasus dari praktik saya ketika sebuah perusahaan IT besar, sebelum proyek skala besar baru, memutuskan untuk meningkatkan proses teknologinya. Untuk ini (menurut rekomendasi), seorang spesialis dalam metodologi fleksibel diundang, yang di pundaknya misi yang bertanggung jawab ini dipercayakan. Setelah membaca ceramah yang sangat singkat tentang cara berpikir dan sistem nilai-nilai Agil, ia mulai mencari tahu bagaimana keadaan sebenarnya dengan produksi perangkat lunak di perusahaan. Menemukan kelemahan dan ketidakkonsistenan dalam proses yang ada, bersama dengan tim perusahaan, kami memilih cara dan metode yang paling tepat untuk menyelesaikannya. Untungnya, kekurangan ini bukanlah rahasia bagi siapa pun, dan sejumlah alasan mencegah mereka untuk mengatasinya. Misalnya: kurangnya waktu, kontradiksi antara tim yang berada di bawah vertikal manajemen yang berbeda, takut mengambil tanggung jawab, dll. Karena seluruh acara ini dilindungi oleh manajemen puncak perusahaan, dan spesialis yang diundang adalah profesional TI yang benar-benar berkelas tinggi, inovasi yang dikerjakan dilaksanakan hampir tepat waktu dan dengan efek positif yang sangat sensitif. Itu hanya untuk manifesto metodologi fleksibel yang tidak ada hubungannya. Akibatnya, sebagian besar karyawan perusahaan tetap yakin bahwa sekarang mereka telah sepenuhnya beralih ke Agile, mengabaikan yang lainnya. Ini semua sangat mirip dongeng tentang bagaimana seorang prajurit memasak bubur dari kapak, dengan licik mengeluarkan bahan-bahan yang ia butuhkan dari pemilik dan meningkatkan rasa hidangan. Itu hanya kapak tidak direbus.

Tetapi karena kita di sini untuk menganalisis secara tidak memihak fenomena Agile, maka kita akan melanjutkan penelitian kita. Mari kita beralih ke sumber asli - Manifesto Ajail:

2. Mari kita menganalisis ide-ide utama Agile Manifesto

Ide-ide kunci:

1. Orang dan interaksi lebih penting daripada proses dan alat;
2. Produk yang berfungsi lebih penting daripada dokumentasi yang komprehensif;
3. Kolaborasi dengan pelanggan lebih penting daripada kesepakatan tentang ketentuan-ketentuan kontrak;
4. Kesediaan untuk berubah lebih penting daripada mengikuti rencana awal.

Mari kita mulai dengan lalat di salep. Bagi saya pribadi, semua poin kontroversial. Mari kita mulai:

Point 1 . Menurut pendapat saya, salah satu alasan utama kemunculan Ajail, seperti yang saya tulis di atas, adalah pengembangan sistem otomasi yang cepat untuk proses pengembangan perangkat lunak, yang memungkinkan untuk mengabaikan peraturan. Artinya, hanya kerumunan dari kerja manusia yang monoton dengan proses robot yang memungkinkan kita untuk menghasilkan hasil yang lebih dapat diandalkan dan dapat diprediksi, termasuk menjaga interaksi berkualitas tinggi dari proses itu sendiri. Oleh karena itu, tentang "Orang - hal yang paling penting", menurut saya, ini hanya slogan yang membantu menghibur kesombongan manusia dari anggota tim yang paling sentimental.

Tetapi dalam keadilan, saya perhatikan bahwa slogan-slogan ini, bertepuk tangan dalam retrospeksi dan sentimen lain pada karyawan muda, cukup valid dan bahkan (pada awalnya) meningkatkan semangat tim. Adalah penting bahwa tidak ada kekosongan dan kekecewaan ketika pemahaman tentang liburan hilang.

Poin 2. Pengembangan hanyalah momen singkat dalam kehidupan sistem otomatis, dan kemudian kehidupan sehari-hari yang keras dari operasinya, modernisasi dan perluasan peluang dimulai. Pernahkah Anda mencoba mempertahankan produk perangkat lunak yang baik, sama sekali tanpa dokumentasi? Apa yang terjadi di dalamnya dan mengapa tepatnya, dan yang paling penting, bagaimana hal itu dapat diperbaiki sehingga mulai bekerja sedikit berbeda? Dan jika itu berinteraksi dengan perangkat lunak lain, lalu apa yang umumnya bisa diubah di dalamnya, dan apa yang tidak bisa disentuh? Semua ini mirip berjalan di ladang ranjau.

Dan di sini kita menambahkan prinsip pengembangan bertahap. Tanpa dokumentasi, karena masih akan diperlukan untuk menentukan pada tahap pengembangan apa produk tersebut umumnya berada.

Tetapi demi objektivitas, harus dicatat bahwa ketika sebuah tim mengirimkan produk jadi kepada pelanggan, disusun dari tumpukan modul, dipasang di tumpukan berbagai peralatan, dan bahkan di bawah beban "non-anak", maka dengan tingkat probabilitas tinggi mungkin diperlukan untuk memodifikasi atau mengubah kode. Terkadang perubahan bisa sangat banyak dan mendalam. Dan di sini jelas tidak sampai formalisme, perlu untuk menyelamatkan wajah tim. Selama periode ini, Anda dapat menunda dokumentasi hingga waktu yang lebih baik dan mengedit kode dengan segera. Saya ingin mencatat bahwa jauh lebih nyaman untuk melakukan ini ketika ada dokumentasi yang layak, disusun pada tahap pengembangan, dengan deskripsi tentang bagaimana semuanya bekerja pada saat pengantar.

Poin 3 . , . ? , , , , , , ( , ..). : , .. ?

Tapi bagaimana dengan kerja sama? Hanya percakapan hangat seumur hidup tanpa kewajiban apa pun? Suka atau tidak, jika proyek tersebut bersifat komersial, semua pihak pertama-tama dan terutama perlu mencapai tujuan mereka dalam proyek tersebut. Dan syarat-syarat kontrak - perbaiki tujuan dan cara untuk mencapainya. Pada saat penjabaran dan persetujuan kontrak, kedua belah pihak mulai menyadari bahwa mereka diharapkan mendapatkan mitra dan tingkat tanggung jawab jika terjadi kegagalan untuk mencapai hasil yang disepakati. Kontrak dalam hal ini adalah motivator dan cara menyelesaikan perselisihan, untuk keduanya. Bagaimanapun, yang paling mengerikan bukanlah ekstrem, tetapi ketidakpastian.

Tanpa kontrak - tanpa tanggung jawab, tanpa pemahaman lengkap tentang apa yang harus dihasilkan dari penyelesaian proyek. Pendekatan ini cocok untuk Anda - semoga sukses.

Poin 4. Kami telah mengatakan di atas bahwa jika ada alat modern untuk merancang dan mengembangkan perangkat lunak, tidak ada kesulitan khusus untuk tim pengembang profesional untuk membuat perubahan pada implementasi produk di hampir semua tahap. Ini adalah proses normal, tergantung pada tingkat yang lebih besar pada kedalaman pemahaman tim, produk yang mereka kembangkan. Oleh karena itu, dalam hal ini, pertanyaannya bukan tentang kemauan tim untuk melakukan perubahan, tetapi tentang siapa yang akan membayar semua ekses ini. Di sinilah kontrak yang disusun secara kualitatif muncul, yang menentukan siapa dan dalam kasus apa menderita kerugian material dari reformasi. Apakah pengembang membuat kembali dengan biaya sendiri apa yang mereka salah pahami atau pelanggan yang tidak menjelaskan dengan benar apa yang ia butuhkan.

3. Diskusikan prinsip-prinsip Agile Manifesto

Karena kami ingin membuat pikiran terbuka tentang topik tersebut, mari kita setidaknya menyentuh secara singkat prinsip-prinsip yang dijelaskan oleh Agile Manifesto:

• kepuasan pelanggan karena pasokan awal dari perangkat lunak yang berharga dan tidak terputus;
• menerima perubahan persyaratan bahkan pada akhir pengembangan (ini dapat meningkatkan daya saing produk yang dihasilkan);
• seringnya pengiriman perangkat lunak yang berfungsi (setiap bulan atau minggu atau lebih sering);
• komunikasi harian yang erat dari pelanggan dengan pengembang di seluruh proyek;
• proyek dilakukan oleh individu-individu termotivasi yang diberikan dengan kondisi kerja yang diperlukan, dukungan dan kepercayaan;
• Metode pengiriman informasi yang disarankan adalah percakapan pribadi (tatap muka);
• menjalankan perangkat lunak adalah ukuran kemajuan terbaik;
• , ;
• ;
• — ;
• , ;
• . .

.

. , . , . – , , , “”, , , . ?

Untuk alasan yang sama, tidak selalu memungkinkan untuk mengatur pengiriman yang sering. Dan proses ini dapat sangat dipengaruhi oleh sejumlah modul terintegrasi yang dikembangkan oleh tim yang berbeda, yang dapat dirakit (modul) pada satu waktu pada peralatan yang sama. Ya, dan peralatan khusus, itu terjadi bahwa disampaikan secara langsung lebih dekat dengan pengiriman. Ini juga harus diperhitungkan.

Dan ada perselisihan dalam pernyataan tentang "persyaratan teknis terbaik, desain dan arsitektur" meskipun fakta bahwa prinsip-prinsip Agile, pada prinsipnya, tidak menerima dokumentasi dan semua jazz itu. Jika Anda "menyinggung" pendekatan formal untuk dokumentasi, maka tidak mungkin menjadi yang terbaik (kearifan rakyat).

Juga, dari sudut pandang saya, itu menimbulkan keluhan - meningkatkan ke peringkat metode terbaik untuk mentransmisikan informasi - "percakapan pribadi (tatap muka)." Menurut pendapat saya, mentransmisikan informasi dalam suatu proyek jauh lebih efisien, misalnya, menggunakan pelacak tugas atau sistem wiki, tanpa, tentu saja, tidak termasuk komunikasi pribadi.

IV Penerapan metodologi lincah

Dalam inovasi, Anda harus keras kepala dan fleksibel.
Jika Anda tidak keras kepala, Anda akan menolak untuk bereksperimen terlalu cepat.
Jika Anda tidak fleksibel, Anda akan membenturkan kepala ke dinding dan Anda tidak akan melihat solusi lain untuk masalah yang Anda coba selesaikan.
Jeffrey Preston

Jika begitu banyak evaluasi kritis muncul selama tinjauan, bagaimana cara kerjanya?
Keberhasilan Agile, tampaknya berkontribusi pada efektivitas penggunaan metodologi dalam proyek-proyek kecil dan kesamaan (simultanitas) menggunakan semua item di atas.

1. Manfaat Menggunakan Agile

Melalui penggunaan Cerita Pengguna, tim pengembangan dapat mencapai tingkat pemahaman yang diperlukan dalam diskusi dengan pelanggan. Untuk pelanggan, ambang untuk memasukkan topik berkurang, lebih mudah baginya untuk beroperasi dengan konten proyek, menetapkan prioritas, mengoreksi ketidakakuratan, dll. Selain itu, bahkan manajer proyek, produk, dan tim lainnya yang sangat berpengetahuan tentang spesifikasi persyaratan berdasarkan cerita Pengguna yang sederhana mendapatkan kesempatan untuk menyulap tugas-tugas dalam proyek lebih mudah dan memahami harapan pelanggan.

Karena seringnya pasokan prototipe, dimungkinkan untuk menghindari perbedaan besar antara harapan pelanggan dan opsi yang ditawarkan oleh para pelaku solusi. Dengan setiap rilis baru, semakin banyak membawa mereka lebih dekat satu sama lain. Penarikan dalam waktu pelaksanaan dan, karenanya, kerugian finansial juga tidak besar dan tidak dapat diprediksi, mereka dapat dimasukkan langsung ke dalam rencana proyek.

Kelihatannya seperti ini: Pelanggan mengharapkan untuk menerima beberapa fungsi baru, kemampuan yang dia sendiri tidak sepenuhnya wakili. Ada "kerja sama yang erat", sebagai akibatnya kontraktor menawarkan solusi percontohan, yang pada umumnya tidak sepenuhnya memenuhi harapan pelanggan, yang diinformasikan oleh tim. Episode ini mendorong "kerja sama yang erat" baru, sebagai akibatnya kontraktor membuat penyesuaian pada prototipe dan kembali menghadirkan produk kepada pelanggan. Dan dalam lingkaran sampai fungsional tertentu benar-benar memenangkan pikiran pelanggan, atau sampai menjadi begitu "padat" dalam kerjasama sehingga tidak nyaman untuk tetap berada di dalamnya. Jika kompleksitas produk dan jumlah fungsi otomatis memungkinkan Anda melakukan 3-6 siklus seperti itu untuk kebahagiaan pelanggan yang lengkap dan tanpa syarat, maka mengapa tidak,skema yang cukup bisa diterapkan.

Satu-satunya hal yang ingin saya fokuskan adalah hal mendasar yang sering kali tidak diperhatikan - kebutuhan untuk memperbaiki dokumen (setidaknya setelah fakta), solusi teknis yang dicapai sebagai hasil dari coba-coba. Ini penting baik bagi pelanggan, yang kemudian dapat merekrut tim baru untuk menyelesaikan atau skala produk, dan untuk tim itu sendiri, yang, pertama, akan dapat mereplikasi solusi atau bagian-bagiannya, dan kedua, jika direkrut untuk meningkatkan produk, itu akan dapat lebih cepat dan lebih baik untuk bergabung dengan proses.

2. Proyek kecil - lingkungan yang nyaman untuk Agile

Untuk proyek-proyek kecil, penggunaan cerita Pengguna, alih-alih persyaratan lengkap untuk produk yang dikembangkan, memungkinkan kami untuk menyederhanakan dan membuat komunikasi yang lebih nyaman dengan pelanggan. Karena seringnya interaksi dengan klien dan kesederhanaan bentuk komunikasi, tim tidak mencuci, sehingga skating mengembangkan persyaratan yang dapat diterima untuk fungsionalitas produk. Dengan tidak adanya algoritma yang kompleks dan integrasi dengan perangkat lunak lain, ini dapat terjadi tanpa banyak kerugian. Level domain masalah - tutup Kisah pengguna, dan domain solusi - komentar dalam kode.

Menggunakan tim profesional, Anda tidak perlu repot-repot mencari solusi arsitektur dan spesifikasi kebutuhan produk. Tentunya sesuatu seperti tim atau anggotanya telah memutuskan dan mereka memiliki template yang sesuai dan praktik terbaik.

Jika produk ini satu kali dan tidak direncanakan untuk mengembangkannya, maka ini sudah cukup.

3. Bagaimana saya bisa menggunakan Agile dalam proyek berukuran sedang

Menggunakan Agile dalam proyek berukuran sedang juga bisa sangat efektif.

Dalam proyek yang lebih besar, berbagai platform otomasi dapat digunakan, dilengkapi dengan template yang sudah jadi, praktik terbaik, alat dokumentasi mandiri, dll. Ini sangat menyederhanakan proses formal, termasuk desain, pemodelan, dan dokumentasi. Solusi yang disajikan dalam kasus seperti itu paling sering digandakan, dengan sejumlah perbaikan dan perubahan.

Efek terbesar dapat diperoleh jika keputusan serupa sebelumnya didokumentasikan. Berdasarkan dasar ini, Anda dapat mencurahkan lebih banyak waktu untuk tidak merancang dan membuat model, tetapi untuk memilih, bersama dengan pelanggan, prototipe yang diinginkan. "Cobalah, pakai dan pergi. Jangan tekan? " Penting bahwa solusi baru yang diimplementasikan juga didokumentasikan dengan baik. Dalam hal ini, tim menerima serangkaian blok dan instruksi untuk merakit berbagai model dari mereka, yang dapat ditawarkan kepada pelanggan masa depan untuk dipilih.

Dalam model kerja ini, penting untuk dipahami bahwa Agile tidak menyangkal pentingnya proses dokumentasi, itu hanya memungkinkan Anda untuk menunda pembentukannya, memberikan prioritas untuk membangun produk itu sendiri (jika mungkin dalam situasi saat ini). Dokumentasi dapat dibentuk setelah menerima produk yang berkelanjutan, mengkonsolidasikan hasil yang dicapai dan, sebagaimana disebutkan di atas, membantu untuk tidak kehilangan benang memahami aturan sistem di masa depan.

4. Cara efektif menggunakan Agile dalam proyek integrasi besar

Dalam proyek besar dan kompleks, di mana dokumentasi berkualitas tinggi dipelihara, ada ide arsitektur produk dan proses produksinya, "potongan" produk dapat di-outsourcing-kan ke tim kecil. Transfer ini terjadi setelah studi rinci arsitektur umum dan persiapan persyaratan tingkat tinggi untuk subsistem baru. Dan sekarang bagian-bagian yang relatif kecil ini dapat diimplementasikan dengan cukup efektif menggunakan Agile.

Skema yang sama berlaku untuk perbaikan kecil atau pengembangan bertahap dari sistem kompleks besar, terutama jika Anda perlu melakukan beberapa pekerjaan penelitian.

Pilihan lain untuk menggunakan Agile dalam proyek-proyek besar dapat diterapkan secara efektif jika terjadi pengiriman darurat produk kepada pelanggan. Mengingat kurangnya waktu dan sumber daya untuk penyempurnaan dan koreksi, justru fleksibilitas dalam pendekatan yang dapat membantu mencegah kegagalan. Dalam situasi seperti itu, menurut saya, metodologi khusus ini optimal.

Pada bagian ini, ada baiknya menyebutkan metode yang ada berdasarkan Agile, tetapi condong ke arah pemecahan masalah skala besar.

Agile Unified Process (AUP) adalah versi sederhana dari Unified Process (UP) yang dikembangkan oleh Scott Ambler. Metodologi pengembangan perangkat lunak ini menggabungkan elemen metodologi fleksibel dan proses terpadu. Secara khusus, AUP melibatkan pengembangan melalui pengujian (TDD), penggunaan pemodelan yang fleksibel (pemodelan Agile Inggris) dan refactoring basis data, manajemen perubahan yang fleksibel.

OpenUP adalah metode pengembangan perangkat lunak yang berulang secara iteratif. Diposisikan sebagai versi RUP yang ringan dan fleksibel. OpenUP membagi siklus hidup proyek menjadi empat fase: fase awal, penyempurnaan, fase desain dan transfer. Siklus hidup proyek memastikan bahwa para pemangku kepentingan dan anggota tim diberikan poin-poin sosialisasi dan pengambilan keputusan di seluruh proyek. Ini memungkinkan Anda untuk secara efektif memantau situasi dan membuat keputusan tepat waktu pada penerimaan hasil. Rencana proyek menentukan siklus hidup, dan hasil akhirnya adalah aplikasi akhir.

5. Bagaimana tidak menggunakan Agile

Bagian yang tidak kalah pentingnya, mungkin demi kepentingan keseluruhan analisis.

1. Pemimpin dalam anti-rating saya adalah situasi ketika mereka mencoba menggunakan Agile, atau lebih tepatnya beberapa prinsipnya, bukan untuk mencapai tujuan spesifik apa pun yang dapat mereka capai, tetapi hanya #CRAFT. Karena ini tren, ada di bibir semua orang. Misalnya, seseorang berbagi ulasan positif di pesta IT, sedikit fana dan bahkan arogan, tetapi ada desas-desus, rombongan muncul. Dan sekarang mereka telah menyebut diri mereka pengikut Agile, mereka merasa berkomunikasi dengan yang lain - milik klub elit tertentu. Semua ini berkontribusi pada kesederhanaan yang tampak dari metodologi dan garis batas yang kabur. Implementasi pada prinsip ini terjadi tanpa berpikir dan formal. Orang secara formal dan tidak berprinsip menerapkan prinsip-prinsip yang dirancang untuk mengurangi formalisme.
   
   Misalnya, salah satu kasus terbaru. Di satu perusahaan, melakukan Retrospektif, mereka dilarang oleh Timlids. Di sini ada sebuah chip. Tanpa diduga. Pikiran pertama: baik, mungkin mereka benar sehingga tidak ada tekanan dari pihak berwenang pada tim saat membahas masalah, dll. Tapi Timlids tersinggung, mereka bingung dan ingin mengetahuinya. Saya mencoba meyakinkan bahwa mereka mengatakan itu mungkin lebih baik, yang utama adalah Anda mendapatkan daftar keinginan, dengan daftar apa yang perlu diubah, apa yang perlu diperbaiki, dll. Dan di sini rahasia yang mengerikan terungkap. Dan tidak ada hasil dan keinginan untuk meningkatkan proses sebagai hasil dari pertemuan ini. Tuan-tuan IT_shniki, dan mengapa retrospektif seperti itu? Hanya saling memuji dan meningkatkan semangat tim? Kata A, say, dan B. Bagaimanapun, tujuan utama dari proses metodologi ini adalah: "Tim harus menganalisis secara sistematis cara-cara yang mungkin untuk meningkatkan efisiensi dan menyesuaikan gaya pekerjaan mereka."
2. Situasi kedua dalam peringkat saya adalah ketika tim memutuskan untuk menghemat persiapan persyaratan dalam proyek dengan algoritma perilaku atau logika yang kompleks. Yaitu, ketika cerita pengguna hanya merupakan puncak kecil dari gunung es masalah, dan bagian utamanya tidak terlihat dan membutuhkan analisis dan desain yang terperinci dan menyeluruh untuk implementasi. Apa yang terjadi dengan ini?
   
   Sebelum memulai pekerjaan, baik pelanggan maupun pengembang bahkan kurang memahami jumlah pekerjaan yang harus mereka lakukan. Dan oleh karena itu: pelanggan akan membayar, membayar dan membayar, setiap kali mereka akan menjelaskan kepadanya bahwa semuanya ternyata jauh lebih sulit dan sekarang pekerjaannya masih belum berulang. Dan bagaimanapun, akan sangat disayangkan untuk berhenti dan secara bertahap akan mulai menggerogoti pemahaman yang kuat bahwa produk "emas" ini tidak akan pernah berhasil. Entah pengembang, setelah setuju untuk menyelesaikan pekerjaan untuk jumlah / waktu tertentu, akan menyelesaikan dan membuat kembali produk (gratis) dengan biaya mereka sendiri sampai pelanggan kehabisan imajinasi, atau dia mengasihani para korban dari pendekatan yang fleksibel.
3. Tempat ketiga yang terhormat diambil oleh situasi ketika dalam proyek multi-fungsi besar (dan tiba-tiba juga satu integrasi) tim memutuskan untuk menghemat dalam mengerjakan arsitektur solusi dan mulai mengimplementasikan cerita pengguna individu dalam iterasi singkat. Dengan tingkat probabilitas yang tinggi akan terjadi bahwa setelah 3-5 iterasi, ketika mencoba membuat fungsional baru, ternyata Anda perlu mengulang seluruh yang sebelumnya, karena prinsip-prinsip dasar yang menjadi dasar fungsional ini seharusnya tidak diperhitungkan. Lebih buruk lagi, jika setelah iterasi ke-10 ditemukan bahwa teknologi yang dipilih tidak memenuhi semua kebutuhan pelanggan dan perlu untuk memulai dari awal lagi. Mungkin dengan mengubah perintah.
4. Situasi di mana stratap yang tajam dan sangat fleksibel meledak ke bentangan segmen pasar yang lesu tidak jatuh ke tiga besar. Sebagai permulaan, ini juga merupakan startup, yang tidak memiliki fondasi, ikatan, lampiran, dan pada saat yang sama stabilitas dan stabilitas. Dan sederhananya, hampir tidak ada dokumentasi, tim tidak harmonis dan sering berubah. Pasar benar-benar merobek-robek tim, menuntut semakin banyak solusi baru di bidang yang dipertaruhkan, dan semua proyek berikutnya hanya berantakan di depan mata kita. Paling sering, ini dijelaskan oleh fakta bahwa tim tidak memiliki pemahaman tentang proses produksi perangkat lunak industri , organisasi pengiriman dan dukungan produk.

Untuk meringkas

Dalam mempersiapkan artikel ini, saya mencoba membantu tim yang tertarik dengan pendekatan Agile menyoroti dan meresmikan tantangan yang harus mereka hadapi dengan satu atau lain cara, serta menemukan solusi yang mungkin untuk mengatasinya. Saya mencoba untuk mempertimbangkan topik setoleransi mungkin, baik untuk pembela untuk pengenalan satu atau lebih metodologi dari kelompok ini, dan untuk lawan yang ingin menghilangkan prasangka halo fleksibilitas dan secara wajar menolak untuk menggunakannya.

Saya berharap bahwa analisis ini akan membantu tim yang menggunakan metodologi lain untuk mengambil keuntungan dari pendekatan Agile jika perlu.