SleekDB

SleekDB adalah sejenis Database NOSQL yang dibangun 100% dari PHP. Jadi, kamu bisa membuat aplikasi pure PHP “tanpa bantuan database apapun”.  SleekDB berbasis text dengan json format.

SleekDB hanya membutuhkan:

  • PHP >= 7.0
  • ext-json
  • ext-mbstring

Hebatnya SleekDB adalah, walaupun berbasis text dan hanya mengandalkan engine PHP, namun query yang digunakan sangat familier bagi programmer PHP, yaitu Query Builder.

Stuktur dokumennya kalau di MongoDB adalah Database -> Collection -> Document, kalau di SleekDB adalah Database->Store->Document.

Kelebihan SlackDB adalah simple dan mudah digunakan. Namun yang saya kurang suka adalah bahwa satu Document (row) diwakili satu file json.

Sebenarnya kalau ada developer madzab NOSQL dengan model seperti SleekDB namun teknologi penyimpanannya seperti SQLite (everywhere in single file) , maka dia akan menjadi SQLitenya kelompok database Non Relational.

MongoDB

Saya baru saja melakukan instalasi MongoDB 7.0.6, namun MongoDB saya install sebagai modul dari Laragon.

Caranya download yang versi Zip dan cukup di exstrak di bin/mongodb. Sedikit ada error saat saya start, dan bisa dibenerin dengan mengubah konfigurasi di mongod.conf. Namun saya lupa apa yg kemarin saya ubah.

Dan apabila kita membutuhkan MongDB Client maka kita bisa menggunakan MongoDBCompas

Berikut  beberapa catatan dari database NOSQL ini:

  1. Jika di Relasional Database ada istilah Database -> Table -> Rows
    maka di  MongoDB menggunakan istilah Database->Collection->Document
  2. Di MongoDB tidak diperlukan mendefiniskan row, bisa langsung memasukkan data apa saja.
  3. Jika di Relational database berbasis tabel maka di MongoDB berbasis JSON dan yang sejenis.
  4. Walaupun di MongoDB tidak diperlukan pembuatan column (rows), namun ada fasilitas untuk  memvalidasi key yang ada pada dokumen.
  5. Cara “Query” nya tidak menggunakan SQL ya bro, namun menggunakan perintah query dengan Java Script yang mirip-mirip json.
  6. Kalau menggunakan MongoDBCompas, bisa import langsung data berformat CSV ke dalam Collection.

Sebenarnya menurut saya cocok untuk LimeSurvey, sayangnya tidak ada dukungan di LimeSurvey.

BTW, saya belum akan menggunakannya untuk kebutuhan sehari-hari saya, dan ini masih sebatas mainan saja, karena memang belum ada urgensi menggunakan MongoDB saat ini. MongoDB besar instalernya aja 1/2 GB. Selain, kebutuhannya masih sebatas SQL khususnya MySQL dan SQLite 🙂

Contoh Query di MongoDB

// select * from products where tags in ("samsung",  "logitect")
db.products.find({
    tags: {
        $elemMatch: {
            $in: ["samsung", "logitech"]
        }
    }
});

// select * from products where category in ('handphone', 'laptop') and price > 5000000
db.products.find({
    category: {
        $in: ["handphone", "laptop"]
    },
    price: {
        $gt: 5000000
    }
});

Contoh perintah-perintah lainnya silahkan mengunjungi GitHubnya  Kang Eko .

Manajemen Proyek: Kanban

Alternatif manajemen proyek populer saat ini selain SCRUM adalan KANBAN.

Perbedaannya dengan SCRUM, Kanban lebih fokus pada aliran kerja yang kontinu, sementara Scrum lebih terstruktur dengan iterasi (sprint) yang terjadwal dan memiliki peran-peran yang lebih terdefinisi untuk memastikan pengiriman nilai secara konsisten.

Walaupun banyak versi aliran yang digunakan namun saya lebih memilih

Backlog – Todo – Doing – Review – Done. Sedangkan warna menunjukkan Prioritas.

Implementasi

  1. Setiap project akan dibagi menjadi beberapa modul (sub project), ada yang menyebutnya WORK.
  2. Dalam sub project dilist macam-macam pekerjaan dan dimasukkan dalam kelompok BACKLOG .
  3. Dari daftar pekerjaan pasda BACKLOG diambillah beberapa pekerjaan prioritas dan orang yg harus mengerjakan dan aliran pekerjaan masuk ke dalam kelompok TODO. Jadi TODO adalah kelompok yang siap dikerjakan.
  4. TODO yang mulai dikerjakan masuk de dalam kelompok DOING
  5. Pekerjaan yang sudah selesai dipindah dari DOING ke REVIEW untuk dilihat oleh pimpinan project.
  6. Apabila project dinyatakan selesai maka dia akan masuk ke DONE. Dan apabila masih ada yang dipernbaiki maka akan dikembalikan ke DOING.

Saya kira alur ini adalag alur yang paling simpel dalam manajemen project. Paling cocok untuk project-project kecil, karena fleksibilitasnya.

Jika diwujudkan dalam bentuk software, mungkin perlu  penambahan properti target waktu, pelaksana, dan catatan-catatan dalam setiap item pekerjaan.

 

SCRUM Board: Perbedaan Backlog dan Stories

Apakah stories harus ada dalam Scrum? Secara umum, stories adalah salah satu alat yang digunakan dalam Scrum untuk mengelola dan mengkomunikasikan kebutuhan pengguna. Namun, tidak selalu harus menggunakan stories secara eksklusif. Ada juga format lain seperti task, bug, atau epic yang dapat digunakan tergantung pada kebutuhan proyek dan preferensi tim. Yang penting adalah untuk memiliki cara yang jelas dan efektif untuk menggambarkan kebutuhan, mengukur pekerjaan, dan mengorganisir backlog sehingga tim dapat bekerja secara terstruktur dan produktif.

Stories memiliki beberapa fungsi utama dalam metodologi Scrum:

  1. Menggambarkan Kebutuhan Pengguna: Stories adalah cara untuk menggambarkan kebutuhan atau cerita pengguna dari sudut pandang pengguna. Ini membantu tim pengembangan memahami apa yang sebenarnya diinginkan oleh pengguna akhir dan fokus pada pengembangan solusi yang memenuhi kebutuhan tersebut.
  2. Mengukur Pekerjaan: Stories biasanya memiliki estimasi poin (story points) yang mengindikasikan kompleksitas atau ukuran pekerjaan yang diharapkan. Ini membantu tim dalam merencanakan dan mengelola kapasitas kerja mereka dalam setiap Sprint.
  3. Mengorganisir Backlog: Stories membantu mengorganisir Product Backlog dengan menyederhanakan kebutuhan pengguna menjadi tugas-tugas yang lebih mudah dipahami dan diukur. Dengan demikian, mempermudah tim dalam menentukan urutan prioritas pekerjaan.
  4. Membantu dalam Penyusunan Sprint Backlog: Stories dari Product Backlog dipilih untuk dimasukkan ke dalam Sprint Backlog selama Sprint Planning. Ini membantu tim dalam merencanakan pekerjaan yang akan dilakukan selama Sprint tersebut.
  5. Mendorong Keterlibatan Tim: Stories memberikan fokus dan tujuan yang jelas kepada tim pengembangan. Dengan memiliki cerita pengguna yang jelas, tim lebih terlibat dalam memahami konteks pengguna, menemukan solusi yang sesuai, dan menghasilkan produk yang lebih bernilai.
  6. Menghasilkan Deliverables yang Bernilai: Dengan memfokuskan pada cerita pengguna, tim dapat menghasilkan inkrement produk yang lebih bernilai dan sesuai dengan harapan pengguna akhir.

Perbedaan antara backlog dan stories adalah sebagai berikut:

  1. Backlog:
    • Backlog adalah daftar semua pekerjaan yang harus dilakukan dalam proyek, baik itu fitur, perbaikan, pemeliharaan, atau tugas lainnya.
    • Backlog mencakup semua jenis pekerjaan yang perlu diselesaikan untuk menghasilkan produk atau layanan.
    • Backlog dapat dibagi menjadi beberapa jenis, seperti Product Backlog (untuk semua pekerjaan terkait produk) dan Sprint Backlog (untuk pekerjaan yang akan diselesaikan dalam satu sprint).
    • Backlog berfungsi sebagai kumpulan tugas yang perlu dikerjakan, yang kemudian dipecah menjadi stories atau item pekerjaan lainnya.
  2. Stories:
    • Stories adalah elemen individu dalam backlog yang menggambarkan kebutuhan atau cerita pengguna.
    • Stories biasanya ditulis dalam format naratif yang menjelaskan kebutuhan pengguna atau pengalaman pengguna yang diinginkan.
    • Stories adalah cara untuk mengkomunikasikan kebutuhan pengguna kepada tim pengembang dengan cara yang dapat dipahami dan dapat diukur.
    • Setiap story dapat memiliki poin estimasi (story points) untuk mengindikasikan kompleksitas atau ukuran pekerjaan yang diharapkan.

Contoh Perbedaan dengan Studi Kasus:

Backlog:

  • Product Backlog:
    • Fitur Login
    • Fitur Tambah Proyek
    • Fitur Tambah Tugas
    • Fitur Tampilkan Daftar Proyek
    • Fitur Tampilkan Detail Proyek
    • Fitur Tampilkan Daftar Tugas
    • Perbaikan Bug pada Fitur Notifikasi

Stories:

  1. Story untuk Fitur Login: “Sebagai pengguna, saya ingin dapat login ke aplikasi menggunakan nama pengguna dan kata sandi saya.”
  2. Story untuk Fitur Tambah Proyek: “Sebagai pengguna, saya ingin dapat menambahkan proyek baru dengan memberikan nama proyek dan deskripsi singkat.”
  3. Story untuk Fitur Tambah Tugas: “Sebagai pengguna, saya ingin dapat menambahkan tugas dalam proyek dengan menentukan judul, deskripsi, dan tenggat waktu.”
  4. Story untuk Fitur Tampilkan Daftar Proyek: “Sebagai pengguna, saya ingin melihat daftar semua proyek yang saya miliki beserta detailnya seperti nama, deskripsi, dan status.”
  5. Story untuk Fitur Tampilkan Detail Proyek: “Sebagai pengguna, saya ingin melihat detail lengkap dari suatu proyek termasuk daftar tugas yang terkait dengan proyek tersebut.”
  6. Story untuk Fitur Tampilkan Daftar Tugas: “Sebagai pengguna, saya ingin melihat daftar semua tugas dalam suatu proyek beserta status dan informasi terkait.”
  7. Story untuk Perbaikan Bug pada Fitur Notifikasi: “Sebagai pengguna, saya ingin bug pada fitur notifikasi diperbaiki agar saya dapat menerima notifikasi dengan benar.”

Dalam contoh di atas, backlog adalah kumpulan fitur-fitur dan pekerjaan yang perlu diselesaikan, sementara stories adalah representasi dari kebutuhan pengguna atau tugas-tugas spesifik yang harus dilakukan untuk setiap fitur dalam backlog. Stories membantu dalam menguraikan kebutuhan pengguna menjadi tugas-tugas yang dapat dikerjakan dan diukur oleh tim pengembang.

SCRUM Board

Scrum board adalah alat visual yang digunakan dalam metodologi Scrum untuk melacak dan mengorganisir pekerjaan yang harus dilakukan oleh tim pengembangan. Ini membantu tim dalam memahami status pekerjaan, memantau kemajuan, dan berkolaborasi secara efektif. Scrum board biasanya terbagi menjadi kolom-kolom yang mewakili tahapan-tahapan proses pengembangan, seperti “To Do”, “In Progress”, dan “Done”.

Berikut adalah contoh praktis penggunaan Scrum board untuk pengembangan aplikasi sederhana:

Scrum Board untuk Pengembangan Aplikasi To-Do List

Kolom Scrum Board:

  1. Backlog: Daftar semua item pekerjaan yang harus dilakukan, termasuk stories dari Product Backlog.
  2. To Do: Item pekerjaan yang siap untuk dikerjakan pada Sprint ini.
  3. In Progress: Item pekerjaan yang sedang dalam proses pengembangan atau pengujian.
  4. Testing: Item pekerjaan yang sedang diuji.
  5. Review: Item pekerjaan yang selesai dan sedang menunggu review.
  6. Done: Item pekerjaan yang sudah selesai dan siap untuk diserahkan.

Contoh Praktis:

  1. Sprint Planning (Hari 1):
    • Tim melakukan Sprint Planning Meeting.
    • Item-item dipilih dari Product Backlog dan ditempatkan dalam kolom “To Do” di Scrum board untuk Sprint ini.
  2. Daily Stand-up Meeting (Hari 2-9):
    • Setiap hari, tim melakukan pertemuan stand-up.
    • Item-item dipindahkan di Scrum board sesuai dengan kemajuan pekerjaan.
    • Contoh:
      • Story “Tambah Tugas” dipindahkan dari “To Do” ke “In Progress” setelah dikerjakan.
      • Story “Edit Tugas” dipindahkan dari “In Progress” ke “Testing” setelah pengembangan selesai.
  3. Sprint Review dan Retrospective (Hari 10):
    • Tim melakukan Sprint Review Meeting untuk memeriksa hasil pekerjaan.
    • Item-item yang selesai dipindahkan ke kolom “Review” untuk proses review.
    • Sprint Retrospective dilakukan untuk mengevaluasi proses sprint ini.
  4. Sprint Baru (Hari 11):
    • Item-item baru dipilih untuk Sprint berikutnya.
    • Kolom “To Do” di Scrum board diisi dengan item-item baru yang akan dikerjakan.

Dengan menggunakan Scrum board, tim dapat dengan jelas melihat status pekerjaan, mengidentifikasi hambatan, dan memastikan bahwa pekerjaan berjalan sesuai rencana. Ini juga memfasilitasi komunikasi dan kolaborasi antar anggota tim, serta memungkinkan transparansi dalam pengelolaan proyek.