ANALISIS PENGEMBANGAN PERANGKAT LUNAK AGILE DI PERUSAHAAN STARTUP (STUDI KASUS PERUSAHAAN XYZ)Arief Rakhman1), Sholiq, S.T., M.Kom., M.SA. 2)Jurusan Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS)Jl. Arief Rahman Hakim, Surabaya 60111 Indonesiae-mail: armanke13@is.its.ac.id 1), sholiq@is.its.ac.id 2)ABSTRAKStartup adalah perusahaan baru yang bertujuan untuk mencari model bisnis yang repeatable (dapat diulang) dan scalable (dapat dikembangkan menjadi besar). Objek penelitian ini adalah sebuah perusahaan startup di Surabaya, Indonesia. Penulis melakukan observasi dengan langsung mengikuti kegiatan operasionalnya. Penelitian ini bertujuan untuk mengamati secara kualitatif praktik penerapan metode pengembangan perangkat lunak di sebuah perusahaan startup lokal Indonesia, membandingkannya dengan temuan-temuan di penelitian-penelitian sebelumnya dalam jurnal internasional, dan mewawancarai praktisi perusahaan startup mengenai metode pengembangan perangkat lunak yang digunakan. Hasil yang diharapkan adalah berupa laporan analisis deskriptif kualitatif yang bermanfaat bagi perusahaan objek penelitian, juga perusahaan-perusahaan lain yang mempunyai karakteristik serupa. Penelitian ini juga diharapkan dapat berkontribusi dalam penelitian bertema startup atau metode pengembangan agile.

1Keyword: metode pengembangan agile, perusahaan startup 1. PENDAHULUANStartup adalah perusahaan baru yang bertujuan untuk mencari model bisnis yang repeatable (dapat diulang) dan scalable [1]. Ini adalah salah satu definisi dalam buku bisnis mengenai startup yang cukup populer. Sedangkan secara akademik, walaupun sudah ada beberapa penelitian yang membahas tentang startup, definisi tentang perusahaan startup secara akademik belum disepakati [2]. Dalam konteks penelitian ini, yang dimaksud startup adalah software startup.Startup dimulai oleh satu atau beberapa founder (pendiri) untuk membuat produk perangkat lunak untuk diluncurkan pada pasar yang potensial. Perusahaan-perusahaan startup mengembangkan perangkat lunak di tengah kondisi yang sangat tidak pasti, berhadapan dengan pasar yang tumbuh dengan cepat, namun beroperasi dengan sumber daya yang terbatas. Karena itu, startup memiliki karakteristik khusus yang menghadapi beberapa tantangan dalam pengembangan perangkat lunak. [2]Konteks startup ini berbeda dengan UKM (Usaha Kecil dan Menengah) atau SME (Small and Medium Enterprise) di bidang pengembangan perangkat lunak [3]. UKM pengembang perangkat lunak biasanya berbentuk software house yang menerima pekerjaan konsultasi dan pengembangan perangkat lunak dari klien dan bekerja dalam proyek-proyek. Startup lebih fokus untuk mengembangkan satu atau beberapa produk tertentu yang berhubungan dengan produk utama, kemudian menjalankan operasi untuk mengembangkan dan memasarkan produk tersebut hingga mencapai skalabilitas tertentu. Tujuan akhir perusahaan startup adalah untuk mencapai model bisnis yang dapat bertahan secara berkelanjutan, atau mencapai exit strategy, berupa diakusisinya sebuah perusahaan atau produk perangkat lunak dengan nilai properti intelektual atau bagian kepemilikan saham tertentu.Praktik pengembangan dan operasional perusahaan startup biasanya dimulai oleh founder dan tim yang kurang berpengalaman, umumnya sebagai wirausahawan baru dan pemuda yang baru lulus dari perguruan tinggi. Karena kurangnya pengalaman, mereka masih membutuhkan banyak wawasan dan panduan. Panduan ini bisa berasal dari penelitian akademik yang formal, bukan hanya dari literatur abu-abu (gray literatures) berupa berita dan artikel blog, yang seringkali berasal dari pengalaman (anekdot) dari satu founder ke founder yang lain yang startup-nya berhasil. Selain itu, penelitian yang membahas mengenai topik startup dan metode pengembangan agile masih jarang, khususnya di Indonesia. Hal ini membuka peluang topik penelitan meode pengembangan perangkat lunak dalam konteks perusahaan startup di Indonesia.2. STUDI LITERATURBeberapa teori yang berkaitan dengan penelitian ini adalah metode pengembangan agile, perusahaan startup, dan beberapa penelitan sebelumnya yang relevan.2.1 Perusahaan StartupIstilah startup berasal dari bahasa Inggris, yang dalam Kamus Bahasa Inggris Oxford berarti A newly established business. [4]. Sutton [5] mengajukan beberapan karakter startup berdasarkan tantangan yang dihadapinya: Tidak mempunyai sejarah operasional atau hampir tidak punya startup hanya memiliki pengalaman yang sedikit dalam proses pengembangan perangkat dan manajemen organisasi. Sumber daya yang terbatas startup biasanya berfokus untuk membuat produk, mempromosi-kannya dan mengembangkan aliansi strategis dengan partner. Dipengaruhi banyak hal tekanan dari investor, pelanggan, partner dan kompetitor yang berdampak pada pengambilan keputusan dalam perusahaan. Setiap stakeholder penting untuk diperhatikan, namun mungkin tidak konsisten satu sama lain. Teknologi dan pasar yang dinamis kebaruan dari perusahaan perangkat lunak seringkali butuh untuk mengembangkan atau mengoperasikan dengan teknologi disruptif untuk memasuki pasar yang berpotensi tinggi.Paternoster, dkk [2] mengumpulkan tema berulang yang muncul dalam penelitian dalam konteks startup. Disebutkan bahwa para peneliti dalam jurnal akademik menggunakan definisi yang berbeda-beda, namun ada beberapa karakteristik yang berulang dalam penelitian-penelitian tersebut:Tabel 1 Karakteristik Perusahaan StartupKarakteristikDeskripsi

Keterbatasan sumber dayaSumber daya ekonomi, manusia, dan fisik sangat terbatas

Sangat reaktif pada perubahanStartup mampu untuk beraksi dengan cepat pada perubahan pasar

InovasiKarena ekosistem yang sangat kompetitif, startup butuh untuk fokus dalam menggarap segmen market yang sangat inovatif.

KetidakpastianStartup berhadapan dengan ekosistem yang sangat tidak pasti dalam sudut pandang yang berbeda: pasar, fitur produk, kompetisi, orang, dan keuangan.

Berevolusi secara cepatStartup yang sukses bertujuan untuk tumbuh dan meningkatkan skala bisnis dengan cepat.

Tekanan waktuLingkungan seringkali memaksa startups untuk merilis produk dengan cepat dan bekerja dalam tekanan yang terus menerus.

Ketergantungan terhadap pihak ketigaDikarenakan keterbatasan sumber daya, startups sangat memanfaatkan solusi eksternal untuk mengembangkan produknya: API eksternal, perangkat lunak open source, outsourcing, dll

Tim yang kecilStartup terdiri dari tim yang kecil.

Satu produkAktivitas perusahaan berkisar di sekeliling satu produk/layanan saja

Tim yang kurang berpengalamanTim pembangun perangkat lunak banyak diisi oleh orang dengan pengalaman kurang dari 5 tahun dan seringkali lulusan baru universitas.

Perusahaan yang baru berdiriPerusahaan baru didirikan

Organisasi yang flatStartup biasanya berpusat pada founder dan setiap orang dalam perusahaan punya tanggung jawab yang besar, tanpa butuh manajemen tingkat tinggi.

Beresiko tinggi untuk gagalTingkat kegagalan startup sangat tinggi.

Belum dapat beroperasi hanya dari hasil usahaKhususnya pada tingkat awal, startup butuh pembiayaan eksternal untuk mempertahankan aktivitas mereka (Venture Capitals, Angel Investments, Personal Funds, dll)

Sejarah operasional yang sedikitPada awalnya basis dari kultur organisasional belum ada.

Dikarenakan perbedaan karakteristik ini, maka peneliti harus secara konkret mendeskripsikan definisi yang digunakan dalam penelitian berkonteks perusahaan startup.2.2 Metode Pengembangan AgileSebuah metodologi pengembangan sistem didefinisikan sebagai sebuah koleksi kebijakan (policies), proses, dan prosedur yang biasa digunakan oleh tim pengembang perangkat lunak untuk meningkatkan produktivitas personal TI dan kualitas solusi TI yang lebih berkualitas. [6]. Dalam implementasinya, sebuah metodologi pengembangan perangkat lunak disesuaikan dengan situasi proyek yang berbeda-beda. Tidak ada contoh template yang siap pakai untuk setiap keadaan. Dalam metodologi agile pun, terdapat beberapa jenis metode yang berupa kerangka kerja (framework), yang dimaksudkan untuk menyesuaikan dengan situasi dan karakteristik proyek tertentu.Istilah agile dapat ditranslasikan ke dalam bahasa Indonesia sebagai lincah. Lincah dalam Kamus Besar Bahasa Indonesia (KBBI) dapat bermakna (1) selalu bergerak; tidak dapat diam; tidak tenang; (2) tidak tetap (tempat tinggal, pikiran, dsb); (3) selalu bertukar (pekerjaan dsb) [7]. Makna tersebut dapat menggambarkan sifat umum dari metode pengembangan agile, yaitu selalu bergerak, tidak tetap, atau fleksibel. Dengan sifat adaptif tersebut, metode pengembangan agile diharapkan dapat menjadikan tingkat kesuksesan proyek pengembangan perangkat lunak lebih tinggi. Kesuksesan proyek pengembangan perangkat lunak tersebut dapat diukur dalam keberhasilan menghasilkan produk perangkat lunak dengan kualitas baik, scope tertentu, dan waktu dan biaya yang efisien. Juga lebih tepat (efektif) dalam memenuhi kebutuhan, karena lebih fleksibel dalam mengakomodasi permintaan pengguna.Pengembangan Perangkat Lunak Agile adalah metodologi yang berbeda dengan metodologi yang berbasis perencanaan (plan-based). Contoh varian dari metodologi Agile bermacam-macam, seperti metode Extreme Programming, Scrum, DSDM (Dynamic Systems Development Method), Adaptive Software Development, Crystal, Feature-Driven Development (FDD), Lean software development dan metode-metode lain yang memiliki karakter sesuai dengan prinsip-prinsip agile.Menurut Dyba dan Dingsoyr [8], metode pengembangan agile dapat dilihat sebagai reaksi dari metode tradisional yang menekankan pendekatan yang rasional, berdasar pada keteknikan (engineering-based) yang mengklaim bahwa terdapat solusi optimal dan dapat diprediksi untuk setiap permasalahan. Para tradisionalis mendorong perencanaan yang ekstensif, proses-proses yang terkodifikasi, dan penggunaan kembali metode dengan teliti untuk menjadikan proses pengembangan menjadi aktivitas yang efisien dan dapat diprediksi. Reaksi itu bisa dianggap wajar, karena banyak terjadinya kasus kegagalan proyek pengembangan perangkat lunak, salah satu sebab utamanya adalah karena sisi kebutuhan dan kepuasan pengguna terhadap sistem informasi yang kurang dapat diprediksi.Munculnya metode pengembangan agile sebagai alternatif, bukan berarti menggantikan sama sekali metode yang lama yang sudah ada. Metode ini bisa dianggap sebagai pelengkap untuk membangun modul tertentu atau bisa diterapkan dalam proyek percontohan (pilot project) sebelum diterapkan secara luas misalnya dalam sebuah perusahaan korporasi. Beberapa penelitian menyebutkan bahwa metode agile tidak sesuai untuk membangun sistem yang safety-critical seperti perangkat lunak untuk militer dan pesawat terbang. Pendapat ini juga tidak selalu berlaku karena organisasi seperti FBI (Federal Bureau of Investigation) Amerika Serikat melaporkan juga pernah menggunakan metode Agile untuk mengembangkan sistem perangkat lunak manajemen kasus Sentinel. [9].Pada manifesto agile pertama, disebutkan bahwa individu dan interaksi lebih penting daripada proses dan alat. Pernyataan ini terbukti dalam temuan empiris di berbagai pengembangan agile, seperti milik Paternoster, dkk [2] dan Fontana, dkk [10]. Dalam konteks perusahaan startup, Coleman dan OConnor [11] juga menyebutkan bahwa yang diperlukan perusahaan startup adalah peningkatan praktik (practice improvement) bukan peningkatan proses (process improvement). Perusahaan startup memang dimaksudkan sebagai perusahaan yang belum dewasa (immature), yang selalu ingin belajar (eager to learn) dari kesalahan dan kegagalan, dan cepat beradaptasi dan berevolusi menjadi lebih dewasa (mature). Untuk itu, pengembangan produk dilakukan secara iteratif melalui trial-error dengan cara yang lincah (agile).Fontana, dkk [10] dalam salah satu tahap penelitian mereka untuk mendefinisikan maturitas pengembangan agile, melakukan tinjauan literatur untuk membuat daftar praktik pengembangan agile. Literatur yang dijadikan sumber adalah jurnal IEEE, ACM, dan database Science Direct, termasuk hasil dari konferensi (proceeding). Daftar praktik agile tersebut berfungsi sebagai basis untuk membuat instrumen pengukuran, yaitu berupa kuesioner. Daftar tersebut memuat 70 praktik pengembangan perangkat lunak dari lima literatur. Kemudian setelah data kuesioner didapat, praktik-praktik tersebut dikategorikan dalam 19 cluster. Daftar praktik tersebut (setelah diterjemahkan) adalah sbb.Tabel 2 Daftar Praktik AgileKelompokDeskripsi Praktik

1. Kolaborasi

Berkomunikasi langsung setiap hari

Saling bertanya dan saling belajar antara satu sama lain

Berkolaborasi dengan anggota tim

Menjaga pekerjaan agar tetap sederhana

Tidak kehilangan otonomi dalam tekanan kerja untuk memenuhi deadline

Membagi tanggung jawab

Mendorong budaya bekerja bersama sebagai tim daripada sendiri-sendiri

2.Kemunculan kebutuhanMembolehkan kebutuhan untuk berevolusi ketika proyek sedang berlangsung

Membolehkan munculnya kebutuhan-kebutuhan

3. Manajemen kode dan pengujianMenjalankan uji penerimaan pengguna (user acceptance test)

Mengumpulakan pengukuran-pengukuran pengujian

Mengelola konfigurasi perangkat lunak (version control)

Mengelola source code

Merencanakan perilisan

Perencanaan ketika sebelum dan selama proyek berlangsung

4. Kepedulian terhadap solusi (produk)Menggunakan standar kode

Memperhatikan tentang arsitektur database

Mendefinisikan cakupan menurut jadwal

5. Pengembangan berdasar pengujianMenjalankan unit pengujian (unit tests) terotomasi

Melakukan Pengembangan berdasar pengujian (test-driven development)

6. Organisasi-sendiri secara berkelanjutan (sustainable self-organization)Menggunakan kepemilikan kode secara kolektif

Melakukan integrasi kode secara terus menerus (continuous code integration)

Menjaga ritme kerja berkelanjutan (lembur dilakukan secara minimal)

Merespon pada tekanan dengan mengubah prioritas atau cakupan daripada bekerja lembur atau menambah orang

Mengorganiasi-sendiri (mandiri, self-organizing)

Memberikan umpan balik secara terus menerus

Mengimplementasikan infrastruktur pengembangan yang mendukung kelincahan (agility)

Mengembangkan kemampuan agility orang-orang

Memiliki pengguna yang berpartisipasi secara aktif selama proyek

Mengembangkan produk yang merespon kebutuhan bisnis

7. Keseder-hanaanculan

Menggunakan desain perangkat lunak yang sederhana

8. PertemuanMelakukan pertemuan pelacakan kemajuan secara harian

Melakukan pertemuan retrosprektif

9. IterasiMelakukan pengembangan secara iteratif dan inkremental

Merilis perangkat lunak dalam jangka waktu yang pendek-pendek

10. Mengelola kebutuhanTerus-menerus menghasilkan perangkat lunak yang dapat berjalan (working software)

Menggunakan product backlog untuk mendefinisikan kebutuha

Menggunakan cerita untuk mendefinisikan kebutuhan

11. Proses perangkat lunak tradisionalMenentukan spesifikasi arsitektur perangkat lunak

Menggunakan timebox (paket waktu kerja) dalam perencanaan

Membuat estimasi bersama orang yang akan mengerjakan

us

Mengidentifikasi penyebab permasalahan dan bertindak untuk mencegah terjadinya di masa depan

Menangani kompleksitas organisasional secara sederhana

Menangani persyaratan regulasi secara sederhana

Menangani kompleksitas domain secara sederhana

11. Proses perangkat lunak tradisionalMenangani kompleksitas organisasional secara sederhana

Menangani persyaratan regulasi secara sederhana

Menangani kompleksitas domain secara sederhana

Menangani kompleksitas teknikal secara sederhana

Menangani disiplin perusahaan secara sederhana

12. Manaje-men Proyek secara agileMenggunakan planning game

Membuat estimasi proyek secara agile

Menulis dokumentasi secara agile

13. Pemantau-an proyekMelacak dan melaporkan kemajuan iterasi

Mengintegrasikan aktivitas manajemen secara langsung ke dalam tugas-tugas pengembangan

14. Penyebaran secara fisikTersebar secara geografis(lain kota atau negara)

15. Pengkode-an secara agileTersebar secara fisik hingga merefleksikan filosofi agile

Melakukan refaktor kode (code refactoring)

Melakukan ppemrograman berpasangan (pair programming)

Fokus pada pekerjaan (prioritas tidak berubah selama iterasi)

Melakukan hal-hal ketika harus hal-hal tersebut dilakukan, bukan sebelumnya

Melakukan penjaminan kualitas secara agile

16. Kehadiran penggunaMembolehkan pengguna untuk mendorong iterasi

Pengguna berada di tempat yang sama dengan tim (collocation)

17. Memper-hatikan kodeMelakukan desain teknikal kebutuhan

Mendistribusikan keahlian pada tim dengan sesuai

Menjalankan pengujian yang ringan (lightweight) dan peninjauan

Menganalisis dan menginspeksi kode

18. Kebutuhan yang sederhana (lightweight)Mendefinisikan kebutuhan yang sederhana (lightweight)

Menggunakan metafora untuk menjelaskan kebutuhan

19. Analisis tradisionalMelaksanakan analisis sistem secara tradisional

Selanjutnya, penulis menggunakan daftar praktik agile ini sebagai salah satu instrumen panduan dalam pengumpulan data. 2.2.1 Daftar Istilah dalam Metode Pengembnngan AgileDalam rangka menambah pemahaman terhadap prinsip, karakteristik, dan teknik-teknik yang digunakan dalam Pengembangan Agile, dibutuhkan daftar istilah yang dapat menjadi referensi. Alzoabi [12] dalam bab berjudul Agile Software: Body of Knowledge, telah menjelaskan tentang metodologi agile, karakteristik umumnya, dan penjelasan singkat dari metode-metode agile yang terkenal di industri dan penelitian. Dari artikel tersebut, diambil (diterjemahkan) sebagai referensi istilah-istilah dalam metode pengembangan agile berikut.Agile Software Development Methods: Sebuah kumpulan proses perangkat lunak yang bersifat kreatif, fleksibel, adaptif, responsif, dan berpusat pada orang. Metode ini berfokus pada komunikasi antara tim pengembang dan pengguna, dokumentasi yang sedikit, dan menerima perubahan.Iteratif: Kata iteratif berarti mengembangkan perangkat lunak melalui perulangan-perulangan. Metodologi agile berusaha untuk memecahkan masalah perangkatlunak dengan menemukan secara suksesif mendekati sebuah solusi mulai dari kumpulan kebutuhan inti minimal. Hal ini berarti tim agile merancang sebuah inti sistem dan kemudian mengubah fungsionalitas dari tiap subsistem seiring dengan perilisan baru ketika kebutuhan diperbarui setiap kali. Karena itu, metode ini tidak seperti metode pengembangan perangkat lunak tradisional yang mencoba merancang solusi menyeluruh dengan sekali coba. Para praktisi metodologi agile memahami kesulitan yang dihadapi pengguna untuk menyatakan kebutuhan mereka dengan cara yang benar dan justru mulai dengan beberapa fungsi inti dari sistem dan kemudian mengubah siste setelah mendapatkan pemahaman mendalam terhadap kebutuhan dan keinginan pengguna melali kolaborasi yang ekstensif dengan para pemegang kepentingan dalam proyek.Incremental: Sebagai sebuah hasil dari pendekatan iteratif dari metode agile, setiap subsistem dikembangkan dengan cara yang membolehkan kebutuhan untuk muncul dan digunakan untuk mengembangkan subsistem lain berdasarkan iterasi yang sebelumnya. Pendekatan ini adalah untuk memidularisasi sistem ke dalam subsistem yang lebih kecil mengacu pada spesifikasi fungsionalitas dan menambah fugsionalitas baru dengan setiap rilis baru. Setiap rilis harus dapat diuji dan berupa subsistem yang dapat digunakan. Ketika pengembangan berlanjut, increments (tahapan-tahapan) baru ditambahkan hingga sistem selesai dikembangkan. [13]Simplicity: Prinsip KISS (Keep It Simple, Stupid) adalah sentral dalam metode pengembangan agile. Kode, desain, pengujian, dan dokumentasi yang sederhana akan membantu dalam melakukan berbagai hal dengan cepat dan menyesuaikannya jika dibutuhkan. [14]Interaction with customers : Prinsip ini juga sentral dalam metode agile karena menfokuskan pada konsep seperti on-site customers (pengguna terlibat di tempat) untuk mendapatkan umpan balik dengan segera mengenai fungsionalitas yang dibutuhkan saat munculnya, menjadikan lebih akurat dan memuaskan pengguna.Self-organizing: Istilah ini mengenalkan sebuah pendekatan yang radikal pada manajemen. Di sini metode agile mengasumsikan pengembang yang terampil dan memiliki kualifikasi tinggi yang seharusnya punya kebebasan untuk merencanakan, mengorganisasi, mengkoordinasi dan mengontrol proyek perangkat lunak tanpa benar-benar dibimbing [14]. Dalam situasi pengembangan agile, konsep self-organizing (pengeloaan mandiri) memberikan tim otonomi untuk mengorganisasi diri mereka sendiri dalam menyelesaikan tugas-tugas kerja. Ini berarti bagaimana pendekatan pengembangan sistem, pemilihan teknologi, komunikasi dengan pengguna, dll diserahkan seluruhnya pada tim untuk meneukan solusi terbaik. Pendekatan ini berbeda sama sekali dengan cara tradisional di mana manajer proyek harus mengontrol pekerjaan.Activity: Aktivitas yang dimaksud dalam konteks pengembangan agile ini adalah pengerjaan penulisan kode, bukan berbagai perencanaan yang terkadang menghabiskan kebanyakan waktu dalam pembangunan perangkat lunak. Hal ini ditekankan melalio kode yang terdokumentasi sebagai aktivitas dokumentasi yang utama.Lightweight (ringan): Hal ini berarti meminimalkan segala hal yang terlihat tidak perludalam proses pengembangan seperti dokumentasi yang eksesif (berlebihan), perencanaan yang ekstensif, dll untuk meningkatkan kecepatan dan efisiensi dalam pengembangan. Sebagai gantinya, metode agile mengganti dokumentasi yang besar dengan diskusi yang seru dengan on-site customers (pelanggan yang terlibat di tempat) [14] Refactoring: Teknik ini mengizinkan para pengembang untuk mencapai fungsionalitas terlebih dahulu baru kemudian melihat lebih dekat pada kode. Yang berarti bahwa setelah fungsionalitas didapat, perubahan-perubahan kecil kapada kode dilakukan hingga pemakaiannya tidakvterpengaruh, kode yang dihasilkan menjadi lebih berkualitas. [15] Test-Driven Development: Teknik ini berarti bahwa tes terotomasi dirancang sebelum coding dimulai. Rancang tes-nya, tulis kode-nya, jalankan tes-nya, ubah hingga tes dapat dilewati. [15]Acceptance Testing: Pengujian terakhir yang dilakukan pada sistem yang sudah selesai dikembangakan, biasanya melibatkan pengguna, sponsor proyek, customer, dll. [16]Continuous Integration:: Kode diintegrasikan dan diujji setelah beberapa jam maksimal dalam sehari kegiatan pengembangans [14]. Ini mengizinkan untuk deteksi error secara dini.Pair Programming: Dua pengembang bekerja samaa secara bergantian pada satu PC. Bug diidentifikasi ketika muncul, karenanya produk menjadi berkualitas tinggi [16] Keduanya bekerja sebagai tim kecil, satu berpikir secara strategis dan yang lain berpikir secara taktis. Keduanya bisa saling berganti peran. [14]On-Site Customers: Seorang pengguna, yang merupakan anggota dari tim pengembang, akan bertanggung jawab untuk mengklarifikasikan kebutuhan dan akan memberikan umpan balik dengan segera kepada tiim pengembang. [16]Backlog: Kebutuhan fungsionalitas produk yang belum dipenuhi oleh rilis produk yang sekarang. Bug, kerusakan, peningkatan yang diminta pengguna, dll adalah item di dalam backlog.Product Owner: Orang yang bertanggung jawab untuk membuat dan mengatur prioritas Product Backlog contohnya kebutuhan-kebutuhan. Berdasarkan tingkat kepentingan yang dirasakan, product owner memilih apa yang dimasukkan dalam setiap iterasi/sprint , dan meninjau sistem di akhir sprint untuk mengontrol kualitas.Scrum Master: Dia adalah ahli dalam Scrum dan memahami siapa yang emngetahui dan mendorong iterasi produk, tujuan, dan nilai-nilai dan praktik Scrum, me-nyelenggarakan pertemuaan harian (the Scrum Meeting) dan demonstari iterasi (the Sprint Review), mendengarkan kemajuan, menghilangan penghalang (blocks), dan menye-diakan sumber daya. Scrum Master adalah juga seorang pengembang dan berpartisipasi dalam pengembangan produk (bukan hanya manajemen)Development Sprints (release): Pengembangan rilis fungsionalitas baru, dengan menghargai variabell waktu, kebutuhan, kualitas, biaya, dan kompetisi. Interaksi dengan variabel-variabel ini mendefinisikan akhir dari fase. Terdapat beberapa, sprints pengembangan iteratif, atau cycles (siklus), yang digunaan untuk mengevolusi sistem.Developing by Feature: Setiap fungsi yang implemen-tasinya akan memakan waktu lebih dari dua minggu, dipecah menjadi fungsi-fungsi yang lebih kecil, hingga fungsi yang dihasilkan dapat diimplementasikan dalam dua minggu. Dalam sistem bisnis, sebuah fitur mewakili sebuah langkah dalan beberapa aktivitas dalam sebuah proses bisnis. Sebuah fitur adalah fungsi yang kecil, bernilai yang dapat diimplementasikan dalam dua minggu. Penamaan fitur adalah : the Configuration Management: Ini membantu dalam mengindentifikasi versi terakhir dari berkas source code dan menyediakan pelacakan historis dari semua artifak dalam proyek.Domain Experts:Ini adalah orang bisnis yang mana memiliki masalah. Ini dapat berupa user, customer, analis bisnis, atau campuran di antaranya. Mereka menyediakan pengetahuan yang dibutuhkan oleh pengembang untuk memahami sistem dan mengembangkannya. Pengetahuan dan partisipasi mereka sangat signifikan dalam kesuksesan hasil sistem.Time-Boxed: Menentukan deadline yang fixed (tetap) akan memaksa para pengembang untuk berkompromi di awal proyek dan akan mengantarkan pada pengekatan yang lebih realistik dalam pengembangan.

2.3 Penelitian-Penelitian LainAbrahamsson, dkk [17] menyebutkan dalam editorial jurnal keluaran khusus (special issue) European Journal of Information System, bahwa masih dibutuhkan penelitian untuk memahami lebih dalam bagaimana metode agile digunakan dalam praktik. Untuk konteks Indonesia yang secara kultural dan kemajuan inovasi berbeda dengan negara maju, penelitian semacam ini juga masih dibutuhkan.Salleh, dkk menginvestigasi adopsi Metode Agile oleh 21 pengembang perangkat lunak di Indonesia menggunakan survey [18]. Survey ini menyebutkan bahwa tantangan utama adopsi metode agile di Indonesia berkisar pada masalah orang, organisasional dan pengguna.Asri, dkk [19] melakukan peninjauan terhadap metode Scrum, XP (Extreme Programming) dan Crystal sebagai varian dari Metode Agile. Dalam penelitian ini ditinjau persamaan dan perbedaan masing-masing metode, proses, lingkup penggunaan, adopsi, dll. Pada akhirnya dibuat komparasi antara ketiga metode agile tersebut.Dyba dan Dingsoyr [8] meninjau apa yang telah diketahui dari 36 penelitian empiris mengenai manfaat, keterbatasan, dan kekuatan dari metode agile.Dengan menggunakan pendekatan grounded theory, Coleman dan OConnor [11] menjelaskan bagaimana pembentukan proses (process formation) di perusahaan startup. Data penelitian mereka berasal dari survey terharap perusahaan startup di Irlandia.Steve Blank [20] menulis sebuah rekomendasi solusi di Harvard Business Review untuk perusahaan startup berupa teknik Lean Startup yang muncul dari Lean Startup Movement gagasan Eric Ries [21]. Komponen utama dari Lean Startup adalah siklus build-measure-learn yang mengikuti evolusi produk. Dalam Lean Startup, rencana bisnis dibuat satu halaman berupa business model canvas. Untuk menguji hipotesis solusi dengan keluar ruangan meminta orang untuk mencoba produk yang masih berupa minimum viable product. Dan umpan balik (feedback) dari orang-orang dijadikan sebagai data untuk memperbarui ide dan produk. Siklus tersebut terus berulang sambil mengikuti empat langkah costumer development : customer discovery customer validation custemer validation company building.2.4 Model Startup C2CPerusahaan startup tidak hanya berkutat dengan pengembangan produk dan jasa, tapi juga harus memperhatikan sisi bisnis. Model bisnis menjadi bagian tak terpisahkan dan juga sangat mempengaruhi proses pengembangan produk dan jasa pada perusahaan startup. Yahya [22] dalam disertasinya membahas tentang peluang ekonomi industri kreatif di Indonesia dan mengajukan sebuah model bisnis startup C2C (Creativity to Commerce), setelah membahas tiga model startup yang telah ada sebelumnya, yaitu: The Four Steps of Epiphany oleh Steve Blank, model Lean Startup oleh Eric Ries, model Running Lean oleh Ash Maurya. Ketiga model startup tersebut kebanyakan berasal dari hasil pengalaman dan pengamatan para praktisi terhadap perusahaan-perusahaan startup Silicon Valley.Model Startup C2C berusaha untuk menyesuaikan model startup yang sudah ada dengan karakteristik perusahaan digital company Indonesia dan juga untuk diterapkan dalam inkubator bisnis.Dalam penelitian ini, model startup C2C dijadikan panduan untuk membuat pertanyaan terbuka (open questions) dalam wawancara. Model startup C2C dianggap cocok dengan objek studi kasus. Pertanyaan-pertanyaan wawancara disusun untuk mengetahui lingkungan bisnis, baik internal maupun eksternal perusahaan startup, yang mempengaruhi pengembangan produk perangkat lunak.3. METODE PENELITIANDalam melakukan penelitian, perlu disesuaikan antara sifat masalah dan objek penelitian dengan metodologi penelitian yang digunakan. Ketidaksesuaian metodologi penelitian dapat mengakibatkan kesalahan rancangan penelitian (research design error).Dalam penelitian ini, masalah yang ingin diteliti bersifat relatif baru untuk tema penelitian sejenis di Indonesia, objek penelitian didapatkan dengan sampel purposif (bukan sampel acak) yang telah ditentukan sejak awal penelitian, dan banyak fenomena yang akan digali berbentuk tacit knowledge (pengetahuan tidak terucapkan, tidak terdokumentasi dengan baik). Observasi awal berupa pengalaman penulis di perusahaan juga pertimbangan pemilihan topik dan masalah penelitian. Selain itu, preferensi penulis yang lebih cenderung pada penelitian kualitatif karena ingin menggali banyak informasi dari perusahaan studi kasus.Untuk meneliti masalah dan objek penelitian dengan karakteristik seperti disebut di atas, maka lebih tepat digunakan metodologi penelitian kualitatif.Langkah-langkah dalam penelitian metodologi kualitatif tidak selalu mengikuti alur satu arah. Di tengah jalannya penelitian dimungkinkan ada perubahan tertentu sebagai adaptasi terhadap temuan di lapangan.3.1 Instrumen Penelitian dan SamplingInstrumen penelitian dalan penelitian kualitatif adalah pewawancara itu sendiri. Hal ini berbeda dengan penelitian kuantitatif yang biasanya menggunakan instrumen berupa kuesioner yang dirancang sedemikian sehingga valid dan reliabel. Dalam wawancara untuk menggali data tentang bagaimana perusahaan startup mengembangkan produk software-nya, diperlukan instrumen berupa pewawancara yang mengetahui hal-hal terkait dengan startup. Dalam konteks penelitian ini, instrumen yang dimaksud adalah penulis sendiri sebagai peneliti dalam studi kasus. Untuk itu, penulis mempersiapkan salah satunya diri dengan mempelajari istilah-istilah yang sering digunakan perusahaan startup, istilah-istilah dalam pengembangan agile. Startup mempunyai banyak istilah teknologi atau buzzwords yang tidak umum diketahui masyarakat, seperti MVP (Minimum Viable Product), monetization, Test Driven Development, dsb. Informasi dan pengetahuan tentang istilah-istilah tersebut penting untuk membangun hubungan wawancara yang jujur dan terbuka dari pihak pewawancara dan informan/responden.Untuk keperluan sampel penelitian, digunakan purposive sampling, bukan random sampling yang sering digunakan dalam penelitian kuantitatif. Purposive sampling ini dilakukan dengan memilih sampel yang sesuai dengan deskripsi umum teori pengembangan agile dalam penelitian, juga dimasukkan dalam konteks penelitian ini sebagai studi kasus perusahaan startup.Perusahaan-perusahaan startup, menurut pengamatan dan pengalaman penulis, biasanya mempunyai sebuah wadah komunitas tertentu. Sebelumnya terdapat beberapa kandidat perusahaan startup yang akan dijadikan sampel dalam studi kasus, namun akhirnya dipilih hanya satu yang aksesnya lebih mudah (convenience sampling). Perusahaan tersebut sebuah perusahaan startup yang didirikan oleh teman seangkatan penulis. Perusahaan startup ini sudah berdiri sejak tahun 2013. Dalam perusahaan startup ini ada empat anggota tetap tim. Yang dipilih sebagai responden/informan adalah dua pendiri (founder) perusahaan tersebut.Sebelumnya penulis sempat mempertimbangkan untuk menggabungkan metode kualitatif dengan kuantitatif. Penggabungan metode (mixed methods) sebenarnya lebih tepat jika tujuan penelitian adalah untuk menghasilkan hasil yang dapat lebih digeneralisasi. Namun mengingat keterbatasan sumber daya dan waktu, juga risiko tinggi kegagalan penelitian akibat pengembalian respon kuisioner yang rendah, maka dibatasi untuk metode kualitatif saja. Untuk penelitian lebih lanjut mungkin bisa menggunakan hasil penelitian ini dalam penelitian kualitatif dengan jumlah sampel yang lebih banyak (studi multi kasus) atau penelitian kuantitatif.Pewawancara dalam penelitian kualitatif bertindak sebagai instrumen penelitian. Berbeda dengan penelitian kuantitatif yang biasanya menggunakan instrumen berupa kuesioner yang dirancang agar valid dan reliabel. Dalam wawancara untuk menggali data tentang bagaimana perusahaan startup mengembangkan produk software-nya, diperlukan instrumen berupa pewawancara yang mengetahui hal-hal terkait dengan startup.Perusahaan-perusahaan startup, menurut pengamatan dan pengalaman penulis biasanya mempunyai sebuah wadah komunitas tertentu. Startup juga punya banyak istilah teknologi atau buzzwords yang tidak umum diketahui masyarakat, seperti MVP (Minimum Viable Product), monetization, Test Driven Development, dsb. Informasi dan pengetahuan tersebut penting untuk membangun hubungan wawancara yang jujur dan terbuka dari pihak pewawancara dan informan.Dalam melakukan wawancara, diharapkan akan didapatkan data berupa situasi (konteks), pengalaman dan tindakan, objek konkret maupun abstrak, peristiwa (event), ruang (space) dan waktu,pengetahuan, pendapat (opini), persepsi dan perasaan dari yang diwawancarai, yang semuanya berfokus pada topik yang sedang diteliti. Data-data tersebut sangat sulit didapatkan jika menggunakan penelitian kuantitatif.Selain hal di atas, pewawancara juga diharapkan dapat menjaga perspektif penelitian untuk meminimalkan bias yang dapat merusak validitas data.Metode pengerjaan penelitian ini dibuat agar pengerjaan penelitian ini dapat dilakukan secara sistematis dan memenuhi kaidah-kaidah penelitian ilmiah. Metode pengerjaan penelitian ini secara ringkas dapat dijelaskan dalam gambar.

Metode penelitian ini mengikuti panduan metode studi kasus. Metode studi kasus dilakukan dengan menganalisis secara lebih mendalam praktik penerapan pengembangan perangkat lunak di sebuah perusahaan startup.Untuk melakukan studi kasus, penulis mengumpulkan data berupa wawancara mendalam, pengumpulan dokumen digital dan non digital, ikut terlibat langsung dalam mengalami proses operasional sehari-hari, dan menuliskan hasil observasi dalam catatan.

3.2 Identifikasi MasalahPenerapan metode pengembangan perangkat lunak tidak selalu sesuai dengan teori. Proses dan metodologi formal hampir selalu mengalami modifikasi tertentu agar sesuai dengan kebutuhan proyek. Begitu pula dengan penerapan metode pengembangan perangkat lunak dalam konteks perusahaan startup.Strategi identifikasi masalah dilakukan untuk menjelas-kan pengalaman-pengalaman tim perusahaan startup dalam menerapkan metode pengembangan perangkat lunak. Pada tahap ini peneliti menggali isu-isu dengan segala komplek-sitasnya dan berfokus pada pemahamannya terhadap kejadian-kejadian dari sudut pandang subjek sendiri yang dijadikan sebagai acuan dengan penekanan pada proses [23].Pengidentifikasian masalah dilakukan dengan menggunakan pendekatan studi kasus. Hal ini berkaitan dengan tujuan penelitian ini, yaitu menghasilkan pengamatan dan analisis secara kualitatif terhadap praktik penerapan metode pengembangan agile dalam studi kasus sebuah perusahaan startup. Dari studi kasus diharapkan akan dapat diamati hal-hal yang dapat dijadikan tambahan penguat temuan dan teori yang sedang dikembangkan dalam berbagai penelitian [24].3.3 Studi LiteraturStudi literatur dilakukan dengan menelusuri buku teks, jurnal dan tulisan para ahli dalam bidang metode pengembangan perangkat lunak, dan juga tulisan para praktisi dan pengusaha perusahaan startup yang mempraktikkan metode pengembangan agile. Studi literatur ini dilakukan untuk membangun dasar teori dan mengumpulkan temuan dari penelitian sebelumnya dan praktik penerapan teori oleh para praktisi dalam konteks perusahaan startup. Penelusuran literatur utamanya dilakukan melalui portal sciencedirect.com, Google Scholar, dan portal Perpustakaan Nasional (pnri.go.ig). Kata kunci yang dipa-kai berkisar antara startup dan agile software development.Literatur utama yang ditemukan dan dijadikan referensi dalam penelitian ini adalah:1. Paternoster, dkk. (2014). Software development in startup companies: A systematic mapping study. Information and Software Technology. [2] Dalam makalah ini Paternoster, dkk melakukan studi pemetaan sistematis dengan menelusuri dan mengumpulkan berbagai literatur akademik bertema startup, mencoba menggali apa yang telah diketahui tentang pembangunan perangkat lunak di perusahaan startup, dan potensi implikasi penerapannya dalam praktik. Dari makalah ini penulis mengambil daftar karakteristik perusahaan startup.2. Dyba, T., & Dingsyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 833-859. [8] Dalam makalah ini dibahas tentang apa yang telah diketahui tentang kelebihan dan kekurangan metode pengembangan agile, disertai bukti empirisnya yang ditemukan dalam berbagai literatur hingga tahun 2008.3. 3. R. M. Fontana, I. M. Fontana, P. A. d. R. Garbuio, S. Reinehr dan A. Malucelli, Processes versus people: How should agile software development maturity be defined?, The Journal of Systems and Software, no. 97, pp. 140-155, 2014. [10] Dalam makalah ini dibahas tentang maturitas pengembangan perangkat lunak agile. Dalam manifesto agile, metode pengembangan agile disebut memiliki prinsip lebih mengutamakan individu dan interaksi daripada proses dan alat dalam pengembangan perangkat lunak. Hal ini menjadikan berbagai perspektif pengukuran maturitas yang berfokus pada proses pengembangan perangkat lunak kurang sesuai. Lebih jauh, makalah ini mengajukan definisi maturitas pengembangan perangkat lunak agile Dari makalah ini penulis mengmbil rujukan daftar praktik agile (agile practices) yang diidentifikasi dari berbagai literatur akademik.3.4 Pengumpulan DataPengumpulan data merupakan serangkaian aktivitas yang bertujuan untuk mengumpulkan informasi yang menandai dalam rangka menjawab masalah penelitian. Cresswell (2009) memberikan penjelasan tentang aktivitas dalam penelitian kualitatif. Data yang akan dikumpulkan melalui penelitian penelitian ini adalah data yang sesuai dengan fokus penelitian yaitu tentang metode pengembangan agile di perusahaan startup.Jenis data yang digali adalah dalam bentuk kata-kata atau ucapan lisan (verbal) dan perilaku dari subjek (tim dalam perusahaan startup) berkaitan dengan metode pengembangan agile.Mengumpulkan data dari perusahaan startup cukup sulit. Hal ini dikarenakan karakteristik dari perusahaan yang memang tidak banyak melakukan dokumentasi. Jadi teknik pengumpulan data yang digunakan adalah wawancara secara mendalam.Wawancara dilakukan dengan dialog langsung (tatap muka) dengan anggota tim pengembang perusahaan startup dan anggota tim lainnya yang berperan dalam pengembangan. Selain wawancara yang terjadwal, pewawancara juga dapat melengkapi data dengan percakapan tambahan melalui media komunikasi online.3.4.1 Observasi AwalPerusahaan yang dijadikan studi kasus ini merupakan perusahaan startup tempat penulis melakukan Kerja Praktek pada bulan Agustus hingga Oktober 2013. Pada saat itu produk yang sedang dikembangkan perusahaan adalah layanan direktori dan pencarian kampus yang dapat diakses melalui kampus.co.id. Penulis berpartisipasi secara moderat dalam menambah dan memperbarui konten dalam layanan tersebut.Setelah mendapatkan beberapa pengalaman dalam Kerja Praktek tersebut, timbul niat penulis untuk meneliti lebih lanjut tentang bagaimana seharusnya perusahaan startup dijalankan. Hal ini dikarenakan penulis merasa banyak hal yang dilakukan dalam perusahaan terlalu sering berubah-ubah, tim tidak memiliki panduan yang cukup atau terlalu variatif karena diambil dari berbagai sumber dari internet. Selain itu, panduan berupa berbagai artikel online tersebut dirasakan kurang sesuai dengan konteks kultural sifat perusahaan startup di Indonesia dan target pasarnya.Pada bulan November hingga tahun berikutnya sekitar bulan April 2014, penulis melanjutkan membantu pekerjaan operasional dalam perusahaan sebagai intern. Pada bulan Januari 2014 perusahaan melakukan perubahan besar berupa pivot produknya menjadi layanan sertifikasi online di domain internet cert.kampus.co.id. Penulis mengamati proses pengembangan produk yang sering diistilahkan sebagai pemrograman koboi, yaitu desain awal seminimal mungkin dengan kebutuhan fitur didapat dari investor dan asumsi-asumsi tim, lalu segera membuat prototype desain user interface (UI), melakukan aktivitas coding, dan terus melakukan perbaruan secara iteratif. Sampai di sini penulis merasakan banyak hal yang berbeda dari teori proses pembangunan perangkat lunak yang didapatkan oleh penulis sebelumnya dalam kuliah. Hal ini menyebabkan timbul keinginan penulis untuk menelusuri literatur akademik mengenai metode pengembangan perangkat lunak yang sedang menjadi tren dan populer menggantikan metode pengembangan perangkat lunak lama. Seiring dengan itu, penulis juga mulai memikirkan hipotesis sementara (working hypothesis) untuk mengidentifikasi dan merumuskan masalah dan rancangan penelitian (research design) yang sesuai.3.4.2 Strategi WawancaraMasalah yang mungkin muncul dalam pelaksanaan penelitian adalah keterbatasan akses, kesalahpahaman terhadap tujuan, topik dan bidang penelitian antara peneliti dengan informan/responden, ketidakterbukaan (atau kekurang-terbukaan) responden terhadap pertanyaan yang diajukan yang mempengaruhi data, dsb.Untuk membangun akses, peneliti mengontak responden beberapa minggu sebelumnya untuk menjelaskan tujuan penelitian, meminta kesediaan wawancara (disertai tanda tangan surat keterangan kesediaan jika perlu), menjadwalkan kegiatan wawancara.Untuk menghindari kesalahpahaman, peneliti menunjukkan proposal penelitian disertai draft pedoman wawancara yang nantinya akan digunakan. Hal ini dimaksudkan juga agar responden dapat mempersiapkan diri sebelum wawancara diakukan. Selain itu, peneliti juga menunjukkan iktikad baik dalam pelaksanaan penelitian yang diusahakan dapat bermanfaat juga bagi responden, tidak terbatas hanya untuk peneliti atau kalangan sendiri.Masalah ketidakterbukaan responden terhadap pertanyaan semi-terbuka perlu disiasati dengan pemilihan setting dan situasi yang nyaman bagi responden. Peneliti bisa memilih tempat selain tempat kerja yang formal, seperti cafe, masjid, atau kampus. Untuk jadwal wawancara juga menyesuaikan dengan agenda responden. Peneliti sebaiknya tidak mengiterupsi jam kerja efektif, jadi bisa dipilih waktu istirahat siang hari, sore, atau malam hari.Wawancara dilakukan dengan dialog langsung (tatap muka) dengan anggota tim pengembang perusahaan startup dan anggota tim lainnya yang berperan dalam pengembangan. Selain wawancara yang terjadwal, pewawancara juga dapat melengkapi data dengan percakapan tambahan melalui media komunikasi online.Wawancara yang dilakukan sebaiknya tidak lebih dari 30 menit. Pedoman wawancara dibuat dalam bagian-bagian. Jika di tengah wawancara ada suatu hal yang menyebabkan terhendi, maka bisa dilanjutkan bagian yang belum ditanyakan, tidak perlu mengulangi lagi dari awal. Bagian pertama berisi pertanyaan untuk menggali informasi latar belakang dari responden, bagian kedua tentang pertanyaan inti topik penelitian, bagian ketiga berisi informasi dan masukan tambahan yang berguna bagi penelitian dan pewawancara. Responden/informan sebagai subjek wawancara berhak untuk menolak memberikan jawaban pada pertanyaan tertentu.Setelah wawancara dilakukan, rekaman hasil wawancara didengarkan berulang-ulang, ditranskripsikan, dikodifikasi, kemudian dilihat pola respon terhadap pertanyaan, membandingkannya dengan respon responden lain (tria-ngulasi), mencatat poin-poin yang penting dan mempersiap-kannya untuk analisis.Selain hal di atas, saat mewawancarai dan mende-ngarkan rekaman, pewawancaran sebagai peneliti juga diha-rapkan tetap dapat menjaga perspektif penelitian untuk meminimalkan bias yang dapat merusak validitas data.3.4.3 Pedoman WawancaraDalam melakukan wawancara, diharapkan akan didapatkan data berupa situasi (konteks), pengalaman dan tindakan, objek konkret maupun abstrak, peristiwa (event), ruang (space) dan waktu, pengetahuan tidak eksplisit (tacit knowledge), pendapat (opini), persepsi dan perasaan dari yang diwawancarai, yang berbagai hal lainnya terkait dengan topik yang sedang diteliti. Data-data tersebut sangat sulit didapatkan jika menggunakan penelitian kuantitatif.Pertanyaan pedoman wawancara dibuat berdasarkan temuan literatur. Pertanyaan-pertanyaan ini merupakan hasil perincian dari rumusan masalah penelitian yang utama. Sebagaimana telah dituliskan pada Pendahuluan, rumusan masalah penelitian ini adalah: Sebagai studi kasus, bagaimana sebuah perusahaan startup menerapkan Metode Pengembangan Perangkat Lunak Agile?Lebih lanjut, rumusan masalah tersebut dapat didetailkan sbb.2. Apa saja karakteristik perusahaan startup dalam studi kasus?3. Apa saja praktik pengembangan perangkat lunak yang diterapkan di perusahaan startup? Apakah termasuk agile?4. Bagaimana praktik kerja di perusahaan startup dalam studi kasus?Untuk memandu pelaksanaan wawancara, dibuat pedoman wawancara. Pedoman wawancara diambil dari rincian rumusan masalah yang telah ditentukan dalam proses identifikasi masalah dan studi literatur, yaitu:1.Apa saja karakteristik perusahaan startup dalam studi kasus?Pedoman wawancara untuk pertanyaan ini diambil dari tabel karakteristik perusahaan startup.(Error! Reference source not found.)2.Apa saja praktik pengembangan perangkat lunak yang diterapkan di perusahaan startup? Apakah termasuk agile?Pedoman wawancara untuk pertanyaan ini diambil dari tabel Daftar Praktik Agile (Agile Practices) (Error! Reference source not found.)3.Bagaimana praktik kerja di perusahaan startup dalam studi kasus?Pedoman wawancara untuk pertanyaan ini diambil dari bagian kesimpulan makalah rujukan utama dari Paternoster, dkk [2].3.5. Uji Keabsahan DataSetelah data terkumpul dari obser vasi dan wawancara, uji keabsahan data dilakukan dengan cara tirangulasi dan member checking. 3.5.1 TriangulasiTriangulasi merupakan proses pengumpulan data yang bersifat menggabungkan berbagai sumber dan teknik pengumpulan data yang sudah ada. Teknik triangulasi dalam penelitian kualitatif bertujuan bukan untuk mencari kebenaran tentang fenomena tetapi lebih pada peningkatan pemahaman peneliti terhadap apa yang telah ditemukan. Kebenaran data dimaksud valid atau tidak dalam konteks ini adalah perbandingan satu set data dari satu sumber dengan set data lain yang diperoleh dari sumber lain.Penulis sebagai instrumen penelitian kualitatif telah melakukan pengamatan, pencermatan, pengenalan dan pemahaman terhadap penerapan metode pengembangan agile dalam perusahaan startup studi kasus, seperti telah dijelaskan sebelumnya, yaitu pada saat observasi awal. Selain itu, wawancara dengan pedoman yang sama dilakukan pada dua orang anggota tim yang berbeda peran dalam perusahaan startup. Hal ini bisa memenuhi syarat triangulasi sumber.3.5.2 Member CheckingMember checking sebagai validasi data dalam penelitian kualitatif bertujuan untuk mengetahui akurasi hasil penelitian. Proses ini dilakukan dengan menyimpulkan deskripsi-deskripsi ke hadapan informan untuk mengecek apakah hasil wawancara atau data/informasi sudah akurat. Menurut Sugiyono [24] member checking adalah proses pengecekan data yang diperoleh peneliti kepada pemberi data. Proses ini bertujuan untuk mengetahui seberapa jauh data yang diperoleh sesuai dengan apa yang sampaikan oleh informan. Proses ini bisa dianggap terwakili pada saat wawancara pengambilan data, yaitu posisi pewawancara dan responden bersama-sama melihat dan mengisi isian dan catatan wawancara. Pada saat wawancara responden selalu diminta mengkonfirmasi jawabannya, menanyakan pertanyaannya jika kurang jelas, dan diminta menjelaskan jawabannya lebih jauh dengan pancingan-pancingan jika diperlukan.4. HASIL DAN PEMBAHASAN 4.1 Observasi AwalPerusahaan studi kasus merupakan perusahaan startup tempat penulis melakukan Kerja Praktek pada bulan Agustus hingga Oktober 2013. Pada saat itu produk yang sedang dikembangkan perusahaan adalah layanan direktori dan pencarian kampus yang dapat diakses melalui kampus.co.id. Penulis berpartisipasi secara moderat dalam menambah dan memperbarui konten dalam layanan tersebut.Setelah mendapatkan beberapa pengalaman dalam Kerja Praktek tersebut, timbul niat penulis untuk meneliti lebih lanjut tentang bagaimana seharusnya perusahaan startup dijalankan. Hal ini dikarenakan penulis merasa banyak hal yang dilakukan dalam perusahaan terlalu sering berubah-ubah, tim tidak memiliki panduan yang cukup atau terlalu variatif karena diambil dari berbagai sumber dari internet. Selain itu, panduan berupa berbagai artikel online tersebut dirasakan kurang sesuai dengan konteks kultural sifat perusahaan startup di Indonesia dan target pasarnya.Pada bulan November hingga tahun berikutnya sekitar bulan April 2014, penulis melanjutkan membantu pekerjaan operasional dalam perusahaan sebagai intern. Pada bulan Januari 2014 perusahaan melakukan perubahan besar berupa pivot produknya menjadi layanan sertifikasi online di domain internet cert.kampus.co.id. Penulis mengamati proses pengembangan produk yang sering diistilahkan sebagai pemrograman koboi, yaitu desain awal seminimal mungkin dengan kebutuhan fitur didapat dari investor dan asumsi-asumsi tim, lalu segera membuat prototype desain UI, melakukan aktivitas coding, dan terus melakukan perbaruan secara iteratif. Sampai di sini penulis merasakan banyak hal yang berbeda dari teori proses pembangunan perangkat lunak yang didapatkan oleh penulis sebelumnya dalam kuliah. Hal ini menyebabkan timbul keinginan penulis untuk menelusuri literatur akademik mengenai metode pengembangan perangkat lunak yang sedang menjadi tren dan populer menggantikan metode pengembangan perangkat lunak lama. Seiring dengan itu, penulis juga mulai memikirkan hipotesis sementara (working hypothesis) untuk mengidentifikasi dan merumuskan masalah dan rancangan penelitian (research design) yang sesuai. 4.2 Identifikasi MasalahIsu besar dalam perusahaan startup adalah pengembangan produknya, yaitu berupa perangkat lunak. Berbagai hal dalam perusahaan startup berkisar pada aktivitas pengembangan perangkat lunak, seperti pembentukan tim, alur pekerjaan, penjadwalan rilis produk, dsb. Dalam berbagai sumber literatur non-akademik yang menyebutkan metode pengembangan yang mendekati gaya kerja perusahaan startup adalah metode agile. Oleh karena itu, diambil asumsi bahwa pengembangan perangkat lunak agile adalah metode yang dipakai oleh perusahaan startup.Selain isu tersebut, walaupun sudah ada berbagai literatur yang membahas tentang perusahaan startup, masih belum ada definisi perusahaan startup yang disepakati. Hal ini akan menyulitkan untuk menelusuri literatur akademik. Untuk itu, perlu dikumpulkan daftar karakteristik perusahaan startup dalam literatur akademik. Kamudian, karakteristik tersebut perlu dicocokkan dengan konteks perusahaan startup dalam studi kasus untuk keperluan konfirmatori.Isu lain yang diidentifikasi adalah praktik kerja (work practices) yang membahas tentang aktivitas perusahaan startup selain pengembangan perangkat lunak.4.3 Penelusuran LiteraturPenelusuran literatur utamanya dilakukan melalui portal sciencedirect.com, Google Scholar, dan portal Perpustakaan Nasional. Kata kunci yang dipakai berkisar antara startup dan agile software development.Literatur utama yang ditemukan dan dijadikan referensi dalam penelitian ini adalah:1. Paternoster, dkk. (2014). Software development in startup companies: A systematic mapping study. Information and Software Technology. Dalam makalah ini Paternoster, dkk melakukan studi pemetaan sistematis dengan menelusuri dan mengumpulkan berbagai literatur akademik bertema startup, mencoba menggali apa yang telah diketahui tentang pembangunan perangkat lunak di perusahaan startup, dan potensi implikasi penerapannya dalam praktik. Dari makalah ini penulis mengambil daftar karakteristik perusahaan startup.2. Dyba, T., & Dingsyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 833-859. Dalam makalah ini dibahas tentang apa yang telah diketahui tentang kelebihan dan kekurangan metode pengembangan agile, disertai bukti empirisnya yang ditemukan dalam berbagai literatur hingga tahun 2008.3. Fontana, R., Fontana, I., Garbuio, P. d., Reinehr, S., & Malucelli, A. (2014). Processes versus people: How should agile software development maturity be defined? The Journal of Systems and Software(97), 140-155. Dalam makalah ini dibahas tentang maturitas pengembangan perangkat lunak agile. Dalam manifesto agile, metode pengembangan agile disebut memiliki prinsip lebih mengutamakan individu dan interaksi daripada proses dan alat dalam pengembangan perangkat lunak. Hal ini menjadikan berbagai perspektif pengukuran maturitas yang berfokus pada proses pengembangan perangkat lunak kurang sesuai. Lebih jauh, makalah ini mengajukan definisi maturitas pengembangan perangkat lunak agile Dari makalah ini penulis mengmbil rujukan daftar praktik agile (agile practices) yang diidentifikasi dari berbagai literatur akademik.Selain makalah di atas, ditemukan juga berbagai makalah lain untuk menjelaskan hal-hal lain tentang pengembangan agile dan perushaan startup. Dalam penelitian ini, hasil studi literatur telah dimasukkan ke dalam Bagian 2 Studi Literatur makalah ini.4.4 Pengumpulan DataPengumpulan data dilakukan dengan wawancara mendalam. Untuk memandu pelaksanaan wawancara, dibuat pedoman wawancara. Pedoman wawancara diambil dari rincian rumusan masalah yang telah ditentukan dalam proses identifikasi masalah dan studi literatur, yaitu:

1.Apa saja karakteristik perusahaan startup dalam studi kasus?

Pedoman wawancara untuk pertanyaan ini diambil dari tabel karakteristik perusahaan startup.

2.Apa saja praktik pengembangan perangkat lunak yang diterapkan di perusahaan startup? Apakah termasuk agile?

Pedoman wawancara untuk pertanyaan ini diambil dari tabel Daftar Praktik Agile (Agile Practices)

3.Bagaimana praktik kerja di perusahaan startup dalam studi kasus?

Pedoman wawancara untuk pertanyaan ini diambil dari tabel bagian kesimpulan makalah utama pertama.4.5 Analisis DataUntuk melakukan analisis data kualitatif, dilakukan transkripsi data rekaman wawancara, kodifikasi, kemudian menginterpretasikan pola-pola respon wawancara.

4.5.1 Latar Belakang Studi KasusPerusahaan studi kasus adalah sebuah perusahaan startup yang berdiri sejak tahun 2013. Perusahaan ini didirikan oleh dua orang alumni Sistem Informasi ITS, yaitu Ardiaz Ajia Aryandika dan Glend Maatita. Beberapa produk sudah dicoba luncurkan ke pasar oleh perusahaan startup ini, salah satunya adalah search engine / direktori kampus.co.id. Kemudian pada Februari 2014, dengan menggunakan domain yang sama, kampus.co.id di-pivot dengan produk utamanya menjadi cert.kampus.co.id yang menyediakan layanan sertifikasi berbagai keterampilan secara online. Hingga wawancara terakhir, jumlah pengguna sudah mencapai sekitar 13.000 pengguna. Untuk menjalankan kegiatan operasionalnya, perusahaan startup dibiayai dari seed investment.4.5.2 Karakteristik Perusahaan StartupBerdasarkan hasil wawancara dan observasi yang dilakukan peneliti, diketahui bahwa perusahaan studi kasus memiliki karakteristik-karakteristik perusahaan startup. Hal ini mengkonfirmasi bahwa tema penelitian ini berpeluang untuk berkontribusi dalam topik penelitian perusahaan startup. Deskripsi perusahaan studi kasus sesuai dengan karakteristik perusahaan startup dalam berbagai penelitian. Penelitian ini juga menambah kontribusi definisi dalam karakterisasi perusahaan startup yang diharapkan akan berguna bagi penelitian-penelitian tentang startup selanjutnya.Satu karakteristik yang tidak sesuai adalah perusahaan startup dalam studi kasus ini disebutkan hanya fokus membangun satu produk. Perusahaan dalam studi kasus tidak hanya membangun satu produk namun fokusnya lebih luas ke satu bidang, yaitu menyasar ke produk dan layanan pendidikan tinggi. Perusahaan startup studi kasus ingin membangun berbagai produk dan layanan yang inline dengan fokus pendidikan tinggi, dan masing-masing produk dan layanan diharapkan dapat saling terkait dan saling mendukung dalam operasionalnya.Kalau kita bilangnya bukan satu produk tapi mungkin lebih ke satu bidang ya. Jadi ada benang merahnya. jadi kalo kita misalnya bidangnya pendidikan tinggi, misalnya perguruan tinggi dan sebagainya. Jadi mungkin tidak satu produk. Tapi mungkin beberapa produk tapi masih inline dan bisa saling mendukung. (Wcr.R1.18, merespon pertanyaan karakteristik perusahaan startup: membuat satu produk).. nggak selalu satu produk. Ada startup yang misalkan startup di industri game misalnya. Dia bisa menelurkan paling tidak dua game dalam setahun. Jadi dia nggak cuma berkutat dalam satu produk. (Wcr.R2.16, merespon pertanyaan karakteristik perusahaan startup: membuat satu produk)

4.5.3 Praktik Pengembangan Perangkat Lunak Agile di Perusahaan Startup Studi KasusPerusahaan startup studi kasus mengkonfirmasi tidak adanya kumpulan praktik terstandar yang dipakai dalam mengembangkan perangkat lunak. Namun setelah dilakukan wawancara dengan menggunakan pedoman daftar praktik agile, terdapat banyak praktik yang ternyata dilakukan di perusahaan. Hal ini mengkonfirmasi temuan Paternoster, dkk [2] bahwa perusahaan startup mengambil praktik-praktik agile secara oportunistik, disesuaikan dengan kebutuhan dan kemampuan untuk menerapkannya.Dalam perusahaan startup studi kasus, praktik pengembangan perangkat lunak yang dipilih adalah praktik-praktik agile. Praktik-praktik itu tidak diterapkan secara kaku, namun pelaksanaannya membutuhkan disiplin diri dan disiplin tim, sambil terus berusaha mematuhi prinsip-prinsip agile. Praktik-praktik tersebut tidak diterapkan semuanya secara sekaligus, namun dipilih-pilih lagi berdasarkan situasi dan kondisi startup sepanjang siklus hidupnya.Dalam hal kolaborasi, perusahaan startup studi kasus mempraktikkan saling bertanya dan saling belajar antara satu sama lain, berkolaborasi dengan anggota tim, menjaga pekerjaan agar tetap sederhana, membagi tanggung jawab, dan mendorong budaya bekerja bersama sebagai tim daripada sendiri-sendiri.Dalam hal kemunculan kebutuhan (emerging require-ment), perusahaan startup studi kasus membolehkan munculnya kebutuhan-kebutuhan, dan memungkinkannya untuk berevolusi ketika proyek sedang berlangsung. Hal ini diperkuat dengan pernyataan penjelas responden pertamadan kedua berikut.Jadi requirement, misalkan kita sudah state bahwa kalo ada penambahan pada tahap development itu memungkinkan sebenarnya. Dan biasanya seperti itu, ada penambahan yang harus dilakukan. jadi ya mungkin itu agak sedikit salah ya, tapi mau nggak mau harus dilakukan karena ya itu kan dinamis.. terlalu dinamis malah startup. (Wcr.R1.27, saat menjelaskan pertanyaan penerapan evolutionary requirement)

Nah habis wireframing ini, kita kasih ke desainer, jadi yang menginterpretasikan wireframe yang kita buat itu desainer. Tentu desainer juga terus kita kasih feedback sampe ketemu bentuk prototype-nya. Baru setelah prototype itu jadi baru kita bikin fungsi-fungsi aplikasinya.. backend.. dan segala macem dari prototype itu.

Setelah prototype itu baru aplikasi itu jadi. 'Jadi' itu pun belum tentu semua fturnya akan kepake, bisa ditambah bisa dikurangi, tergantung nanti kondisi ke depan. Kita ada wawancara dengan calon user. Kita konsultasi dengan beberapa mentor, dsb.. ya intinya, akan terus berubah. Asal ide besarnya untuk aplikasinya masih tetep sama. (Wcr.R2.22, saat menjelaskan tahap-tahap pengembangan secara garis besar)

Evolutionary requirement.. bener [ini dilakukan], jadi requirement akan terus berubah selama project berlangsung. (Wcr.R2.24, merespon pertanyaan tentang evolutionary requirement)Dalam manajemen kode dan pengujian, perusahaan startup studi kasus menjalankan user acceptance test, mengumpulkan test metrics, mengelola konfigurasi perangkat lunak (version control), mengelola source code, merencanakan perilisan, dan perencanaan saat sebelum dan selama proyek berlangsung. Kode adalah aset intelektual yang perlu dikelola sedemikian sehingga dapat digunakan, dikembangkan, dan di-deliver kepada pengguna. Praktik agile bukan praktik yang tidak mengindahkan manajemen seperti yang mungkin dipikirkan oleh sebagian orang. Justru manajemen kode dilakukan terintegrasi dalam proses pengembangan, dan mengumpulkannya bersama aktivitas pengujian. Pengujian yang dilakukan berfokus kepada pengguna, maka pengujian dilakukan utamanya melalui uji penerimaan kepada pengguna. Pengujian tidak dilakukan khusus oleh tester atau hanya bisa melalui prosedur penjaminan kualitas (quality assurance) formal yang bisa memakan lebih banyak waktu.Untuk manajemen kode, perusahaan startup studi kasus menggunakan berbagai alat yang tersedia di internet bagi para pengembang modern, seperti Git version control, platform repositori source code Github dan Bitbucket.Jadi untuk tools, kita bagi jadi dua aja ya; jadi ada tools untuk software development, sama tools untuk management software development. ... Kalau untuk software development sendiri, tools and technology-nya hampir semua sih open source. ... terus untuk version control kita pake Git, open source juga. Kalau untuk repository-nya kita pakai BitBucket. Trus untuk tools pengembangannya kita pakai IDE/text editor Sublime [Sublime Text]. Ya kebanyakan open source, dan ya kalaupun nggak open source kita masih cari yang free, kecuali terpaksa ... ya kita bayar. (Wcr.R2.32, menjawab tentang Tools and Technologies yang dipakai oleh perusahaan startup)

(kalau untuk development-nya? apakah pake tools tertentu?) pake-nya github ya.. (Wcr.R1.66, menjawab tentang Tools and Technologies yang dipakai oleh perusahaan startup)

Perusahaan startup sangat mempedulikan produk yang sedang mereka bangun, sebagai solusi berharga yang mereka percayai dapat menyelesaikan masalah orang-orang. Karena itu, mereka juga memperhatikan sarana pendukung agar produk tersebut memenuhi standar, dapat memenuhi kebutuhan skalabilitas dan berusaha men-deliver-nya sesegera mungkin kepada pasar. Demikian juga, karena hal-hal tersebut perusahaan startup studi kasus menggunakan standar kode, memperhatikan tentang arsitektur database, dan men-definisikan cakupan menurut jadwal (tidak berdasarkan anggaran). Standar kode yang digunakan oleh perusahaan startup studi kasus mengikuti standar kerangka kerja (framework) PHP Laravel. Teknologi database yang dipilih adalah MySQL yang memiliki dukungan komunitas open source yang kuat, sesuai dengan kemampuan sumber daya perusahaan startup dan kebutuhan membangun produk di atasnya dan mencukupi kemungkinan untuk menmpung skalabilitas. Arsitektur database dipilih yang berbasis teknologi cloud computing untuk menghemat biaya dan memitigasikan risiko kegagalan skalabilitas kepada penyedia layanan database server dan application server. Perusahaan startup juga mendefinisikan cakupan (scope) berdasarkan jadwal, karena waktu adalah sumber daya yang sangat terbatas, yaitu mereka harus menghasilkan sesuatu sebelum sumber daya finansial untuk operasional habis digunakan [18].Coding standards.. iya, soalnya kita pake framework, kecuali kalau kita bikin sendiri kan nggak standard. (Pakai framework apa itu kalau boleh saya tahu..) Pake Laravel.. PHP Laravel, ini udah ada coding standardnya sendiri, kita bangun aplikasi di atasnya sudah pasti ngikuti coding standard. (Wcr.R2.28, menjawab pertanyaan tentang coding standards)Khusus untuk pengujian, dalam perusahaan startup studi kasus dipraktikkan unit test walaupun belum terotomasi, dan mem-praktikkan TDD atau Test-Driven Development. (lihat jawaban wawancara Wcr.R1.46 dan Wcr.R2.30)

Bekerja pada peruusahaan startup menuntut anggota tim di dalamnya untuk serba mandiri, tidak pasif menunggu perintah atau keputusan, namun proaktif dan mengorganisasi sendiri secara berkelanjutan (sustainable self-organization). Praktik-praktik yang termasuk cluster ini adalah:

Berusaha mengorganiasi-sendiri (mandiri, self-organizing) Menggunakan kepemilikan kode secara kolektif Melakukan integrasi kode secara terus menerus (continuous code integration) Menjaga ritme kerja berkelanjutan (lembur dilakukan secara minimal) Merespon pada tekanan dengan mengubah prioritas atau cakupan daripada bekerja lembur atau menambah orang Memberikan umpan balik secara terus menerus Mengimplementasikan infrastruktur pengembangan yang mendukung kelincahan (agility) Mengembangkan kemampuan agility orang-orang Memiliki pengguna yang berpartisipasi secara aktif selama proyek Mengembangkan produk yang merespon kebutuhan bisnisIndikator praktik ini dilakukan pada perusahaan startup studi kasus dikonfirmasi dalam wawancara seperti kutipan berikutSelf-organizing.. iya, jadi harusnya setiap anggota startup ini cerdas. maksudnya dia bisa tau mana yang perlu dilakukan mana yang nggak. Dan karena di startup ini nggak ada birokrasi, maka mereka melakukan yang bener, ini untuk mereka. (Wcr.R2.24, menjawab tentang poin self-organizing).. Doing continuous integration.. iya, jadi kita pake istilahnya [alat/tool-nya] 'Travis'... Collective code ownership.. iya, ini hasil dari pair programming, jadi setiap orang itu punya pengetahuan yang sama terhadap kode, kalau di startup seharusnya memang gitu, jadi seorang programmer harus bia baca, bisa ngerti coding-an programmer lain, nggak ada 'blindspot', (Wcr.R2.30, merespon tentang continuous code integration dan colective code ownnership)

Perusahaan startup studi kasus mengutamakan keseder-hanaan. Dokumentasi tidak dibuat jika tidak benar-benar dibutuhkan. Pengumpulan kebutuhan bisa melalui komunikasi lisan secara sederhana saja. Selain itu perangkat lunak didesain juga dengan sederhana, yaitu asal kebutuhan terpenuhi, tidak harus dengan tampilan yang mewah atau teknologi terkini.Dalam mendefinisikan kebutuhan, perusahaan startup studi kasus juga melakukannya dengan sederhana (lightweight), yaitu dipecah hingga ukuran fitur kecil seperti fungsi kode. Namun perusahaan startup studi kasus tidak menggunakan metafora untuk memperjelas kebutuhan.Lightweight requirement.. iya, jadi setiap requirement dipecah kecil-kecil, nggak terlalu besar, (Wcr.R2.28, merespon tentang lightweight requirement)

Kesederhanaan juga tampak pada perusahaan startup studi kasus pada pertemuan/meeting yang dilakukan. Meeting tidak perlu dilakukan setiap hari, walaupun beberapa praktisi agile menyebutkan itu diperlukan. Meeting harian diperlukan jika startup dalam fase awal idea conception dalam aktivitas brainstorming, wireframing, dan prototyping, namun jika sudah berumur dua-tiga tahun seperti perusahaan startup studi kasus, meeting bisa dilakukan secara mingguan, atau bahkan bulanan karena yang menjadi target adalah pertumbuhan skalabilitas, beralih dari fokus awal pada pembangunan produk. Dan juga, pekerjaan yang tidak membutuhkan saling bertemu bisa dilakukan dari jarak jauh (remote).Untuk di Beenary Lab, kita cenderung ke Scrum sebenarnya. Jadi Scrum itu ciri khas utamanya ada ... standup meeting. Jadi standup meeting itu kita sebelum kerja kita meeting singkat.. ya nggak harus standup.. jadi yang pasti kita tentukan apa aja target hari ini. (Wcr.R2.23)Manajemen proyek dalam perusahaan startup studi kasus dilakukan sekedarnya, tanpa dokumentasi dan tanpa menerapkan planning game seperti dalam eXtreme Programming (XP). Yang dilakukan adalah membuat estimasi proyek secara agile.

Nah, documentation itu kita nggak ada.. sama sekali nggak ada ... Making agile project estimation.. iya, tapi mungkin nggak sesuai formatnya.. aku nggak tahu formatnya [yang terstandar]. kayak yang pernah kita buat itu.. termasuk cost nggak sih? Yang pertama timeline, rilis per fitur, user acquisition.. nggak tau itu termasuk agile (agile project estimation) nggak.. (Wcr.R1.33, karakteristik estimasi yang tidak fixed, bisa berubah-ubah seiring dengan perkembangan proyek menunjukkan bahwa estimasi secara agile sedang dilakukan)

Pengembangan perangkat lunak pada perusahaan startup studi kasus dilakukan secara iteratif, juga dalam hal pemantauan proyeknya.

Delivering software continuously.. iya. (jadi kalo ada fitur baru.. langsung di-push, gitu) iya, jadi langsung di-test ke user. (Wcr.R1.30, merespon tentang praktik delivering software conti-nuously)

Tracking dan reporting ini kita pake Basecamp sebenernya, sama Time Doctor. (Wcr.R1.37, merespon poin Tracking and reporting iteration progress)

Sayangnya, praktik pengintegrasian aktivitas manaje-men secara langsung ke dalam development tasks masih belum dilakukan. Ke depannya hal ini direncanakan oleh CEO untuk dicoba terapkan pada perusahaan startup studi kasus.management activities.. iya harusnya. (untuk pertanyaan ini sebenarnya untuk keadaan as-is.. bukan 'seharusnya'.. jadi as-is aja, bukan akan rencananya dilakukan) iya, ini dilakukan. (harusnya akan dilakukan, jadi to-be ya?) iya, harusnya.. akan dilakukan. (Wcr.R1.38, merespon poin project monitoring: Integrating management activities directly into development tasks)Dalam pengelolaan kebutuhan, perusahaan startup studiu kasus menggunakan product backlog untuk mendefinisikan kebutuhan, dan sekali-sekali (seringnya tidak) menggunakan bantuan cerita. Setiap kebutuhan dikelola dalam bentuk paket-paket pekerjaan yang terbatas pada timebox, misalnya mingguan atau harian, yaitu semacam penghitungan estimasi waktu orang-hari yang dibutuhkan dalam proyek konvensional. Namun untuk mengantisipasi terjadinya masalah terkait kesalahan kebutuhan di masa depan masih belum dilakukan oleh perusahaan startup studi kasus.Selain itu, kebutuhan dikelola bersama dalam tim secara multidisipliner, agar berbagai perspektif bisa diselaraskan, misalnya untuk pemngembangan produk kampus.co.id yang membutuhkan perspektif edukasisecara akademis, training dan sertifikasi dari profesional, sisi bisnis untuk keperluan monetisasi, sisi teknis dari pengembang, kebutuhan desain produk untuk rancangan UI dan UX, dsb. Mengenai penyebaran secara fisik, perusahaan startup studi kasus pernah memiliki anggota tim yang bekerja dari jarak jauh (secara remote), yaitu dari Bandung.Jadi itu juga kenapa kita sukanya [hire] freelance/outsource. Mungkin kita bisa hire yang dari Bandung, Jakarta, dan itu sebenarnya juga menekan biaya sebenarnya [bisa bekerja remote], tanpa harus terikat.. tanpa harus (menyediakan) biaya operasional yang lebih tinggi kalau misalnya harus ngantor dan lain sebagainya. (Wcr.R1.04, menjelaskan jawaban pertanyaan mengenai karakte-ristik keterbatasan sumber daya)pernah [ada yang bekerja secara remote], iya, kalau sekarang nggak kayaknya.. (Wcr.R2.26, meralat jawaban pertanyaan Being geographically distributed)4.5.3 Praktik Kerja di Perusahaan Startup Studi KasusPerusahaan startup studi kasus mengkonfirmasi bahwa dalam kegiatannya menjalankan beberapa praktik kerja startup yang ditemukan dalam literatur. Pelaksanaannya tidak mengikuti proses tertentu secara kaku, namun dilakukan secara adaptif dan dengan penyesuaian-penyesuaian (tailored). Hal ini bisa diketahui dari wawancara. Jadi kita.. cara mengembangkannya sebenernya kayak gini.. dari awal kita punya ide, trus kita tuangkan ide itu dalam bentuk sebuah aplikasi. Nah untuk membuat aplikasi itu awalnya kita.. istilahnya wireframing, bikin sketsa. Jadi ide itu kita tuangkan dalam bentuk aplikasi, nah [wireframe itu membantu menjelaskan] aplikasi itu seperti apa... Hampir setiap hari brainstorming sama wireframing. Jadi wireframing itu diikuti dengan brainstorming.

Wireframing itu bikin sketsa. Nah setelah sketsa itu jadi.. ini sketsa sangat kasar, di aplikasi itu kira-kira ada fitur apa saja.. terus bentuk setiap fitur itu kayak apa aja. Ini masih kasar belum.. hampir pasti akan sangat berbeda ketika aplikasi sudah jadi.

Nah habis wireframing ini, kita kasih ke desainer, jadi yang menginterpretasikan wireframe yang kita buat itu desainer. Tentu desainer juga terus kita kasih feedback sampe ketemu bentuk prototype-nya. Baru setelah prototype itu jadi baru kita bikin fungsi-fungsi aplikasinya.. backend.. dan segala macem dari prototype itu.

Setelah prototype itu baru aplikasi itu jadi. 'Jadi' itu pun belum tentu semua fturnya akan kepake, bisa ditambah bisa dikurangi, tergantung nanti kondisi ke depan. Kita ada wawancara dengan calon user. Kita konsultasi dengan beberapa mentor, dsb.. ya intinya, akan terus berubah. Asal ide besarnya untuk aplikasinya masih tetep sama.

(Wcr.R2.22, merespon permintaan agar proses pengembangan dijelaskan secaara garis besar)

Ya kalau agile itu sebenarnya ada banyak kayak Scrum, FDD.. itu sebenarnya cuma kerangka aja. Ya nanti akan diadopsi, secara adaptif akan diimplementasikan di masing-masing perusahaan. Jadi di setiap startup, di setiap perusahaan, hampir pasti berbeda implementasinya.

Untuk di Beenary Lab, kita cenderung ke Scrum sebenarnya. Jadi Scrum itu ciri khas utamanya ada product backlog, sama yang paling penting itu standup meeting. Jadi standup meeting itu kita sebelum kerja kita meeting singkat.. ya nggak harus standup.. jadi yang pasti kita tentukan apa aja target hari ini. kita lebih condong ke Scrum. Walaupun tidak menutup kemungkinan kita sering pair programming juga.. sering pakai metodologinya TDD..

(Wcr.R2.23, merespon pertanyaan apakah ada praktik agile tertentu yang mengikuti kerangka kerja, seperti Scrum, FDD, atau lainnya)5. PENUTUPBerikut akan disampaikan secara singkat hal-hal yang dapat disimpulkan dari pembahasan. Selain itu juga dikumpulkan berbagai saran untuk para pembaca dari kalangan praktisi atau akademisi.5.1 KesimpulanBeberapa hal yang dapat disimpulkan dari penelitian Tugas Akhir ini adalah :1. Perusahaan startup memliki karakteristik tertentu yag membedakannya dengan tipe perusahaan lain, seperti UKM atau korporasi besar. Hal ini mengakibatkan metode pengembangan perangkat lunak yang diterapkan di perusahaan startup juga sebaiknya mengikuti karakteristik tersebut.2. Perusahaan startup seharusnya memilih metode pengembangan perangkat lunak yang disesuaikan dengan kebutuhan dan kemampuan untuk menerapkannya. Beberapa praktik agile bisa dipilih sebagai panduan dalam pengembangan produk perangkat lunak.3. Praktik kerja dalam perusahaan startup sebaiknya dijalankan secara adaptif dan mengutamakan kesederhanaan dalam praktik, juga menjadikan prinsip-prinsip agile sebagai panduan.5.2 Saran Ada beberapa hal yang dapat disarankan sebagai penelitian lebih lanjut atau penerapan dalam praktik kerja dan pengembangan perangkat lunak pada perusahaan startup:1. Perlu diadakan penelitian lebih lanjut untuk meningkatkan cakupan generalisasi penelitian ini. Penelitian ini hanya melibatkan saru perusahaan sebagai studi kasus. Selanjutnya lebih baik dipilih studi multi-kasus atau dengan penelitian kuantitatif yang mengumpulkan perusahaan-perusahaan startup sebagai responden.2. Kesuksesan pengembangan perangkat lunak dalam startup perlu diukur pada kasus-kasus startup yang berhasil hingga menemukan model bisnis yang repeatable dan scalable.3. Penelitian ini memiliki kekurangan dalam hal data observasi yang sudah agak lama, berasal dari pengalaman penulis sekitar satu tahunan yang lalu. Untuk penelitian selanjutnya sebaiknya menggunakan data observasi yang lebih baru.4. Kekurangan lain dalam penelitian Tugas Akhir ini adalah pada proses pengumpulan data yang masih sederhana. Hal ini dikarenakan batasan sumber daya waktu penelitian yang tersedia untuk penulis, juga keterbatasan penulis sendiri sebagai peneliti yang masih pemula, apalagi dalam jenis penelitian kualitatif yang jarang dilakukan di lingkungan akademik institut teknik. Idealnya, wawancara dalam penelitian kualitatif dilakukan berulang-ulang hingga inkuiri mencapai titik jenuh, yaitu terjawabnya pertanyaan penelitian disertai habis-nya temuan informasi baru dari jawaban pertanyaan wawancara.5. Analisis data kualitatif yang dilakukan masih kurang. Jika ada penelitian lanjutan dari Tugas Akhir ini, sebaiknya ada analisis susunan kronologis praktik pengembangan perangkat lunak dalam sebuah perusahaan startup. Untuk objek penelitiannya bisa mengobservasi pengembangan perangkat lunak di beberapa inkubator bisnis startup. Beberapa inkubator bisnis ada yang menyelenggarakan program mentoring startup tiga bulanan atau enam bulanan.6. Berdasarkan saran yang didapat dari wawancara kepada responden kedua, ditemukan bahwa dalam daftar praktik agile dalam Tabel 2.2 ada beberapa poin yang duplikat. Hal ini seharusnya dieliminasi sebelum dijadikan pertanyaan wawancara.7. Berdasarkan saran yang didapat dari wawancara kepada responden pertama, ditemukan bahwa pertanyaan-pertanyaan yang diajukan masih terlalu general Sebaiknya untuk penelitian selanjutnya pertanyaan dibuat lebih teknis lagi. Mungkin dari dartar praktik agile yang sama, namun dengan deskripsi yang lebih banyak menyertakan contoh-contoh ketimbang istilah-istilah.8. Dalam meakukan wawancara sebaiknya jangan menempatkan pertanyaan yang membutuhkan jawaban panjang lebar pada akhir sesi, karena bisa saja pewawancara dan responden sudah kelelahan untuk menjawab pertanyaan-pertanyaan sebe-lumnya.9. Dalam penerapan praktik pengembangan perangkat lunak, perusahaan-perusahaan startup maupun selainnya sebaiknya mencoba metode pengembangan agile. Hal ini dilakukan untuk meningkatkan tingkat kesuksesan pengem-bangan perangkat lunak.DAFTAR PUSTAKA

[1] S. Blank and B. Dorf, The Startup Owner's Manual, Pescadero, California: K&S Ranch Press, 2012. [2] N. Paternoster, C. Giardino, M. Unterkalmsteiner, T. Gorschek and P. Abrahamsson, "Software development in startup companies: A systematic mapping study," Information and Software Technology, 2014. http://www.sciencedirect.com/science/article/pii/S0950584914000950, http://dx.doi.org/10.1016/j.infsof.2014.04.014 [3] C. Giardino, M. Unterkalmsteiner, T. Gorschek and P. Abrahamsson, "What Do We Know about Software Development in Startups?," IEEE Software, vol. 31, no. 5, pp. 28-32, Sept-Oct 2014. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6898758&isnumber=6898682, http://dx.doi.org/10.1109/MS.2014.129 [4] Oxford University Press, [Online]. Available: http://www.oxforddictionaries.com/definition/english/start-up?q=startup. [Accessed December 2014].[5] S. Sutton, "The role of process in software start-up," IEEE Software, vol. 17, no. 4, p. 3339, 2000. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=854066&isnumber=18557, http://dx.doi.org/10.1109/52.854066[6] F. K. Y. Chan and J. Y. L. Thong, "Acceptance of agile methodologies: A critical review and conceptual framework," Decision Support Systems, vol. 14, no. 4, pp. 803-8014, 2009. www.sciencedirect.com/science/article/pii/S0167923608002133, http://dx.doi.org/10.1016/j.dss.2008.11.009 [7] Badan Pengembangan dan Pembinaan Bahasa Kemdikbud, "Kamus Besar Bahasa Indonesia dalam jaringan," 2008. [Online]. Available: http://badanbahasa.kemdikbud.go.id/kbbi/index.php. [Accessed December 2014].[8] T. Dyba and T. Dingsyr, "Empirical studies of agile software development: A systematic review," Information and Software Technology, vol. 50, no. 9-10, pp. 833-859, 2008. www.sciencedirect.com/science/article/pii/S0950584908000256, http://dx.doi.org/10.1016/j.infsof.2008.01.006[9] C. Fulgham, J. Johnson, M. Crandall and L. Jackson, "The FBI Gets Agile," IT Professional, pp. 57-59, Septembe-October 2011. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6028561&isnumber=6028548, http://dx.doi.org/10.1109/MITP.2011.88 [10] R. M. Fontana, I. M. Fontana, P. A. d. R. Garbuio, S. Reinehr and A. Malucelli, "Processes versus people: How should agile software development maturity be defined?," The Journal of Systems and Software, no. 97, pp. 140-155, 2014. http://www.sciencedirect.com/science/article/pii/S0164121214001587, http://dx.doi.org/10.1016/j.jss.2014.07.030[11] G. Coleman and R. V. O'Connor, "An Investigation into Software Development Process Formation in Software Start-ups," Journal of Systems and Software, vol. 81, no. 5, pp. 772-784, 2008. http://doras.dcu.ie/18659/1/ColemanandOConnor.pdf[12] Z. Alzoaobi, "Agile Software: Body of Knowledge," in Business Intelligence and Agile Methodologies for Knowledge-Based Organizations: Cross-Disciplinary Applications, A. A. Rahman and M. Alnoukari, Eds., Hershey, Pennsylvania: Business Science Reference, 2012, pp. 14-34. http://dx.doi.org/10.4018/978-1-61350-050-7.ch002[13] E. Mnkandla and B. Dwolatzky, "Balancing the human and the engineering factors in software development," in AFRICON, 2004. 7th AFRICON Conference in Africa, Gaborone, Bostwana, 2004. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1406881&isnumber=30508, http://dx.doi.org/10.1109/AFRICON.2004.1406881[14] K. Beck, Extreme programming explained: Enbrace Change, Boston: Addison-Wesley, 2000. [15] S. Ambler, "Quality in an agile world," Software Quality Professional, vol. 7, no. 4, pp. 34-40, 2005. http://www.oamk.fi/~palo/English_2/AgileQuality.pdf[16] Huo, et al., "Software quality and agile methods," in MA Computer Software and Applications Conference (COMPSAC) Proceedings of the 28th Annual International, 2004. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1342889&isnumber=29570[17] P. Abrahamsson, K. Conboy and X. Wang, "'Lots done, more to do': the current state of agile systems development research," European Journal of Information Systems, pp. 281-284, 2009. http://ulir.ul.ie/handle/10344/2293 [18] N. Salleh, E. Al-Kautsar, R. Hoda and A. l. Asmawi, "A Window into the Emergence of Agile Software Development Landscape in Indonesia," SCRG Publication, 2014. home.ijasca.com/data/documents/PiD_648_IJASCA_salleh_2014.pdf[19] S. A. Asri and F. Baskoro, "An Analysis of Agile Methods: XP, Scrum and Crystal Methods," International Conference Information & Communication Technology and System, pp. 529-534, 2008. http://icts.if.its.ac.id/openaccess/2008/files/icts_2008_088.pdf [20] S. Blank, "Why the Lean Start-Up Changes Everything," Harvard Business Review, May 2013. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything [21] E. Ries, The Lean Startup, New York: Crown Business, 2011. [22] A. Yahya, Creativity to Commerce, Jakarta: Gramedia Pustaka Utama, 2014. [23] J. Cresswell, Reseach Design : Qualitative and Quantitative Approach (Third Edition), London: Sage Publication, 2009. [24] Sugiyono, Metode Penelitian Kuantitatif, Kualitatif, Bandung: Alfabeta, 2008. [25] S. Faisal, Penelitian Kualitatif: Dasar-Dasar dan Aplikasi, Malang: YA3, 1990. [26] R. Yin, Case Study Research, Design and Methods, 3rd Edition ed., Beverly Hills, CA: Sage Publication, 2003. [27] K. Eisenhardt, "Building Theory from case study research," Academic Management, pp. 532-550, 1989. http://www.jstor.org/stable/258557