Pola pikir Agile vs Agile

https://flic.kr/p/bkcj5q

Saya berulang kali menemukan bahwa tim perangkat lunak terlalu fokus pada mekanisme dan kehilangan prinsip dasar. Ini terutama berlaku untuk metodologi Agile. Metode seperti Scrum memiliki banyak mekanisme sehingga mereka yang baru tangkas benar-benar hilang. Saya awalnya menulis ini sebagai email ke tim saya untuk mengklarifikasi apa pandangan saya tentang Agile, tetapi saya telah mengirimkannya kepada begitu banyak orang sekarang, yang menerima nasihat Scott Hanselman, saya mengubahnya menjadi posting blog.

Saya menganggap diri saya agak memenuhi syarat untuk memberikan wawasan ini. Saya adalah seorang praktisi yang gesit dari hari-hari di mana pengembangan Agile melibatkan menggunakan obeng - untuk membongkar bilik Anda sendiri dan membuat rencana tempat duduk terbuka!

Di awal karir saya, saya bekerja dengan perusahaan perangkat lunak medis. Kami membangun perangkat lunak desktop untuk tinjauan gambar yang diinstal pada desktop Dokter di rumah sakit. Proses penyebaran melibatkan bepergian dengan CD ke kota lain dan menginstal desktop, dan server gambar. Kami tunduk pada persetujuan FDA, jadi kami harus membuat spesifikasi yang telah melalui persetujuan FDA. Ini menciptakan lingkungan yang ideal untuk metodologi air terjun top-down. Semua spesifikasi ditulis, disetujui, ditandatangani dan kami membangun hanya untuk spesifikasi itu saja. Tidak sampai tim dev mulai bepergian dengan tim instalasi, dan menonton dokter menggunakan perangkat lunak kami, kami menyadari bahwa kami dapat melakukan jauh lebih baik hanya jika kami dapat berbicara dengan pelanggan lebih awal dalam siklus tersebut. Kami mengkodekan ke spesifikasi yang tepat, namun mengirimkan sesuatu yang tidak berguna seperti seharusnya. Grafik ini menunjukkan beberapa pengalaman saya.

Bagaimana Pengembangan Perangkat Lunak dapat serba salah dari https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-swatch-a-case-for-agile-development/

Sekitar waktu ini tim saya mendengar tentang sesuatu yang disebut Agile Manifesto dan praktik yang disebut Pemrograman Ekstrim. Karena ditandatangani oleh para veteran industri yang bukunya kami baca secara aktif, orang-orang seperti Martin Fowler dan Kent Beck, meminjamkan banyak praktik keabsahan. Tim saya yang terdiri dari lima membongkar bilik kami, menarik PM kami (proxy untuk pelanggan kami) untuk duduk di sebelah kami, membuat papan dengan kartu indeks dan mulai bekerja, membentuk XP saat kami berjalan. Kami memiliki siklus perencanaan dan demo mingguan, banyak pasangan dan diskusi. Saya bekerja di berbagai iterasi dan variasi ini, di berbagai perusahaan selama sekitar 15 tahun. Satu tim tampaknya tidak mengikuti metodologi sama sekali, tetapi itu karena semua anggota tim berasal dari latar belakang yang gesit, iterasi dan kolaborasi adalah keadaan operasi standar mereka dan mereka tidak memerlukan proses yang dipaksakan.

Jadi, apakah Agile tentang rencana lantai terbuka atau banyak bicara? Jika Anda memiliki stand-up dan retros dapatkah Anda diklaim sebagai Agile? Di mana Scrum atau TDD cocok? Seringkali orang terlalu terperangkap dalam spesifik proses - Scrum atau Kanban? Sprint dua minggu atau satu minggu? Jika Anda tidak memiliki perawatan backlog, apakah Anda benar-benar Agile? Setelah tumbuh melakukan pengembangan aktif menggunakan metode Agile, dengan pengembang lain yang terlibat, mengembangkan dan mengadaptasi praktik-praktik yang sama, telah memberi saya wawasan yang baik dan posting ini adalah untuk mengidentifikasi prinsip-prinsip dasar.

Menjadi Agile mampu memenuhi kebutuhan pelanggan dengan cepat. Apakah itu berarti kita menulis kode lebih cepat? Nggak. Kita tidak dapat mengalahkan hukum fisika, dan aplikasi multi-fungsi yang solid membutuhkan waktu untuk dibangun.

Yang perlu kita lakukan adalah

  1. Identifikasi masalah bisnis penting yang ingin kita selesaikan dengan kode
  2. Memberikan solusi teoretis dengan cepat untuk menguji hipotesis
  3. Iterasi dan beradaptasi saat kebutuhan berubah, atau kita belajar lebih banyak
  4. Lakukan dalam kolaborasi, dengan pelanggan bagian yang terlibat dalam tim

Segala sesuatu yang kita lakukan adalah membuat 2 dan 3 di atas tidak terlalu menyakitkan - untuk mengetahui apakah kita memenuhi kebutuhan sesegera mungkin, dan jika tidak dapat berubah dengan cepat. Jika Anda telah memutuskan untuk membangun (vs membeli), Anda menulis perangkat lunak khusus. Ini berarti memiliki persyaratan dan lingkungan khusus.

Membuat sesuatu terlihat, meskipun itu adalah bagian kecil dari fungsionalitas, di depan pelanggan sesegera mungkin memungkinkan kami untuk mendapatkan umpan balik lebih cepat. Inilah sebabnya saya selalu menganjurkan fokus pada membangun sepotong kecil fitur, ujung ke ujung, dan mendapatkan semua cara untuk produksi. Katakanlah, Anda sedang membangun halaman untuk agen pendukung Anda untuk melihat semua data tentang pelanggan. Alih-alih menghabiskan banyak waktu untuk meneliti sumber data untuk seluruh halaman dan menulis semua API terlebih dahulu, cobalah untuk mendapatkan subset data pada halaman sampai ke produksi. Anda akan dapat menggunakan mekanisme integrasi dan penyebaran Anda, Anda dapat mulai mendapatkan umpan balik tentang kerangka UI, bagaimana halaman ini cocok dengan sisa aplikasi Anda dll. Hal-hal ini lebih mudah untuk disesuaikan ketika Anda memiliki sejumlah kecil kode, sebagai lawan ketika Anda telah membangun seluruh kerangka API.

Berikut adalah beberapa mekanisme lain yang penting untuk kelincahan

Sprint: Berkembang dalam siklus kotak waktu, memungkinkan kami untuk memeriksa dan beradaptasi, dan menggabungkan data baru secara berkala untuk memastikan kami masih bekerja pada fitur yang relevan. Perangkat lunak adalah kewajiban. Kita hanya harus membangun apa yang kita butuhkan, dan dapat menambahkan apa yang dibutuhkan, ketika dibutuhkan. Oleh karena itu penting untuk secara teratur melihat apa yang telah kita bangun sejauh ini dan ke mana kita akan pergi selanjutnya. Ini mengarah pada poin kedua.

Mengingat bahwa kami berencana untuk terus mengevaluasi dan mengubah, perangkat lunak kami harus mudah diubah. Bagaimana jika, setelah pelanggan mulai menggunakan aplikasi mereka ingin beberapa data muncul berbeda dari yang dirancang sebelumnya? Bisakah kita melakukannya tanpa menyentuh yang lainnya di halaman? Atau kita perlu memanggil API lain untuk mendapatkan data - dapatkah kita melakukan perubahan itu dengan aman? Di sinilah praktik dan mekanisme pembangunan yang baik masuk

Unit Testing: Kami memiliki pengujian otomatis di berbagai tingkatan sehingga ada jaring pengaman untuk perubahan. Penting juga untuk memperhatikan tentang apa yang sebenarnya diuji oleh unit test. Tes unit harus menguji logika. Jika Anda mengambil contoh di atas, menggunakan API yang berbeda untuk mendapatkan data, idealnya, tidak memerlukan perubahan pada tes unit untuk API kami yang menyajikan data ke UI. Tes unit ada untuk memberi Anda kepercayaan diri untuk memperbaiki kode, yang pada gilirannya memberi Anda kebebasan menulis hanya apa yang Anda butuhkan sekarang, dan beristirahat nanti, bukan untuk menghasilkan beberapa 100% cakupan metrik yang Anda bisa.

CI / CD: Ini memungkinkan kami untuk memperpendek jarak antara komit dan pengiriman. Ini penting untuk kelincahan. Ketika hambatan untuk penyebaran dihapus, dan kita bisa mendorong perubahan kecil ke produksi, risiko dari perubahan sangat menurun. Jika penyebarannya membosankan, mereka lebih jarang. Penerapan yang lebih jarang mendorong banyak perubahan, menyentuh area permukaan yang besar, dan karenanya lebih berisiko. Jika Anda mempelajari lebih lanjut tentang mengapa kinerja kinerja pengiriman perangkat lunak, dan metrik apa yang digunakan untuk mengoptimalkannya, saya sangat merekomendasikan buku ini oleh Nicole Forsgren.

Pemisahan masalah: Arsitektur yang digabungkan secara longgar sangat penting untuk perangkat lunak yang mudah diubah. Ini mengurangi area permukaan perubahan. Layanan mikro dan wadah adalah beberapa mekanisme yang digunakan untuk melakukan pemisahan masalah. Penting untuk mengingat hal ini, dan pastikan untuk selalu mempertimbangkan pemisahan kekhawatiran, saat membuat API, komponen, dan aplikasi.

Ingat
Kode yang baik dapat dengan mudah diubah

Kode yang lebih baik dapat dengan mudah dihapus

Kode terbaik adalah yang tidak ditulis sama sekali

Sangat penting bahwa bit yang Anda buat memenuhi dunia nyata sesegera mungkin, sehingga Anda tahu seperti apa bentuk bit baru Anda, dan Anda tidak membuang waktu untuk membuat bit yang tidak perlu.