Synchronize and Stabilize

By ,

Sejak pertengahan tahun 1980an, Microsoft dan perusahaan software Personal Computer (PC) lainnya secara berangsur-angsur mulai menyusun kembali cara mereka membangun produk perangkat lunak sebagai jawaban atas masalah kualitas dan lamanya pengiriman. Banyak perusaahaan saat ini mempunyai permasalahan yang sama dalam mengorganisir team mereka untuk membangun produk Software-PC. Produk tersebut sekarang terdiri dari ratusan, ribuan dan bahkan jutaan baris source code dan memerlukan ratusan orang untuk membangun dan mengetes produk tersebut dalam periode lebih dari satu tahun.

Seperti halnya pembuat-pembuat PC Software terbesar, dengan jumlah kira-kira 18.000 karyawan, 200 produk, dan pendapatan tahunan yang lebih dari $ 6 milyar, Microsoft mungkin mempekerjakan karyawan yang lebih dibandingkan perusahaan Software-PC lainnya. Beberapa produknya, seperti windows 95, dimana terdiri lebih dari 11 juta baris program dan memiliki tim pengembang yang lebih dari 200 programmer dan tester, menyaingi kompleksitas dari berbagai sistem yang dibuat untuk mainframe dan sistem telekomunikasi.

Filsafat umum Microsoft adalah mengatur sebuah root dengan fleksibilitas yang tinggi, perusahaan yang mempunyai entrepreneur dan tidak banyak mengadopsi struktur Software Engineering yang dibuat oleh suatu organisasi, seperti Software Engineering Institute (SEI) dan International Standards Organization (ISO). Selain itu Microsoft juga mencoba untuk menaikkan struktur tim kecil (beberapa menyebutkan hacker) dari pengembang produk. Sasaran yang ingin dicapai adalah dengan mengambil tim-tim kecil secara paralel (3-8 pengembang untuk masing-masing tim) atau programmer untuk bekerja sama membentuk suatu tim yang lebih besar, dalam rangka menciptakan suatu produk yang relative lebih cepat, tetapi tetap mengijinkan setiap programmer dan tim untuk terlibat dalam desain dan operasi mereka secara mandiri.

Tim paralel tersebut melibatkan seluruh fitur dan produk-produk yang ada, sementara memperkenalkan konsep dan teknologi terbaru. Pengembang bebas berinovasi terhadap yang mereka inginkan, tetapi mereka harus meng “synchronize” setiap perubahan yang terjadi sehingga semua komponen produk dapat bekerja bersama-sama

 

Frekuensi Synchronizations dan Periodik Stabilzations

Kita menamakan gaya Microsoft dalam pengembangan software dengan menggunakan pendekatan synchronize-and-stabilize. Pada dasarnya sederhana: melakukan synchronize secara terus menerus terhadap setiap individu-individu dalam suatu tim paralel, dan secara periodik melakukan proses stabilize terhadap project yang dibuat, bukan pada akhir project. Orang-orang Microsoft mengacu kepada beberapa teknik yang digunakan, seperti milestone, daily build, nightly build, atau zero–defect.

Apapun namanya, teknik tersebut banyak digunakan oleh beberapa perusahaan pengembang software. Dua atau tiga orang tidak dapat membuat suatu sistem yang baru dengan tingkat kompleksitas produk yang tinggi, mereka membutuhkan tim yang lebih besar, dimana mereka harus mengerti dan memiliki inovasi terhadap produk yang mereka kembangkan. Setiap anggota membutuhkan komponen yang berdiri sendiri, tetapi mereka sulit untuk mendefinisikan secara akurat mengenai tahapan-tahapan dalam siklus pengembangan.

Dalam situasi ini, project harus menemukan cara untuk memproses struktur dan berkoordinasi mengenai apa yang dibutuhkan oleh anggota ketika mereka memiliki fleksibilitas dan kreatifitas yang cukup dalam setiap tahapan pengembangan. Pendekatan pengembangan juga harus mengijinkan suatu mekanisme bagi pengembang-pengembang untuk mengetes suatu produk dengan customer dan melakukan perbaikan selama proses pengembangan.

Dalam berbagai macam industri, banyak perusahaan saat ini menggunakan “prototyping”. Dalam komunitas pengembang software, sejak pertengahan tahun 1970an, para peneliti dan manajer-manajer telah membicarakan mengenai iterative enhancement, suatu ‘model spiral’ yang melakukan iterasi selama fase pengembangan software. Banyak perusahaan yang lambat dalam mengadopsi model tersebut. Meskipun begitu, gagasan dasar membagi pendekatan adalah user membutuhkan berbagai macam tipe software yang sulit untuk dipahami dan perubahan-perubahan yang terjadi begitu cepat baik hardware maupun software. Sebagai gantinya project dilakukan secara iterasi sebagaimana halnya tahap desain, implementasi dan testing dilakukan secara bersamaan untuk melengkapi suatu produk.

Iterasi seperti ini sangat jauh berbeda dengan model sekuensial atau waterfall. Dalam pendekatan waterfall, project dibuat secara bertahap, mulai dari tahap design, implementasi kemudian menyatukan semua komponen tersebut secara bersama-sama di akhir project. Pendekatan pengembangan software ini terjadi pada tahun 1970an dan 1980an. Banyak perusahaan-perusahaan menggunakan model ini. Lama kelamaan model ini mulai ditinggalkan, karena perusahaan menginginkan jika terjadi perubahaan dalam spesifikasi dan desain, mereka dapat memberikan ke customer dan melakukan kembali proses pengembangan. Sebagai hasilnya, banyak perusahaan-perusahaan dan juga Microsoft mulai menggunakan model iterasi ini dalam tahap design, implementasi dan pengembangan. Mereka juga dapat berinteraksi terhadap customer mengenai kebutuhan-kebutuhan yang perlu diperbaiki. Hal ini sangat bermanfaat untuk menjelaskan apa yang perlu dan yang tidak untuk dilakukan tanpa harus menunggu sampai suatu project selesai.

 

Strategi dan Prinsip

Beberapa peneliti pengembang software telah melakukan pengamatan selama dua setengah tahun, yang melibatkan lebih dari 38 orang penting di Microsoft dan mereview ratusan dokumen rahasia. Hasil dari penelitian ini didapatkan dua strategi dan kumpulan prinsip-prinsip yang digunakan sehingga synchronize-and-stabilize dapat bekerja.

Team Microsoft memulai suatu proses pengembangan dengan menciptakan vision statement, yang mendefinisikan tujuan dari suatu produk dan memprioritaskan beberapa aktifitas user yang membutuhkan dukungan dari fitur suatu produk. Manajer produk (spesialis pemasaran) mengambil alih tugas ini sementara mereka melakukan konsultasi dengan manajer program, yang berfokus kepada pembuatan konsep fungsi spesifikasi. Selanjutnya, manajer program berkonsultasi dengan pengembang untuk melakukan fungsi spesifikasi dan mengorganisasi jadwal serta alokasi sumber daya. Selama project, anggota tim akan melakukan revisi terhadap fitur yang seharusnya ada di dalam produk. Pengalaman Microsoft menyarankan bahwa fitur dalam spesifikasi boleh berubah sekitar 30 persen atau lebih.

Manajer proyek kemudian akan membagi produk dan project ke dalam bagian-bagian dan membagi jadwal project ke dalam tiga atau empat milestone yang mewakili keseluruhan hasil dari produk. Semua tim kemudian mengumpulkan hasil mereka ke dalam siklus pengembangan, integration test, dan perbaikan kesalahan. Kemudia dilakukan synchronize untuk membuat suatu produk dan melakukan kembali perbaikan kesalahan dalam periode harian dan mingguan. Di akhir project milestone, pengembang memperbaiki hamper semua error yang telah terdeteksi selama pembuatan produk. Hasil koreksi error tersebut dilakukan untuk men stabilize produk dan memberitahukan kepada seluruh tim bagian mana saja dari suatu produk yang telah diselesaikan.

 

Pendekatan Struktur “Hacker”

Beberapa orang berpendapat bahwa kunci praktis pengembangan software yang dilakukan Microsoft, synchronize produk dalam pengembangan sistem, stabilize project milestone secara periodik dan testing berkesinambungan, tidak lain adalah suatu proses dan teknk “perbaikan” untuk sebuah organisasi software “hacker” dalam membuat sistem yang besar. Hal itu tidak sepenuhnya benar, Microsft mempunyai ide yang mendalam mengenai bagaimana suatu struktur dapat dikombinasikan dengan fleksibilitas dalam suatu pengembangan produk. Ini memberikan catatan bahwa kondisi “hacker” tidak jelek dalam dunia industri Software-PC. Ini kembali lagi kepada awal dari pemrograman komputer, dimana para “hacker” duduk di depan komputer tanpa memiliki perencanaan, desain dan proses, dan langsung melakukan hack away terhadap suatu coding.

Tidak ada perusahaan yang mengambil keuntungan dari permintaan software-pc yang meningkat saat itu. Tidak ada perusahaan software-pc yang benar-benar menjaga stabilitas dari sebuah software yang dihasilkan. Ini berlanjut menjadi sebuah tantangan bagi Microsoft untuk membuat suatu produk yang lebih reliable, dan yang lebih mudah dipahami oleh user.

Microsoft masih mendorong beberapa tim untuk mengadakan percobaan dan membuat beberapa perubahan tanpa merubah rencana awal. Secara umum, project masih tetap diawasi dan diatur karena bagaimanapun juga tim dari programmer dan tester harus melakukan synchronize and stabilize setiap perubahan yang diinginkan.

Sejak tahun 1980an, Microsoft telah melakukan pengembangan dari pendekatan synchronize and stabilize untuk membuat Publisher, Works, Excel, Word, Office, Windows NT, Windows 95 dan beberapa produk lainnya. Tentu saja, proses synchronize and stabilize tidak memberikan garansi tepat waktu dan bebasnya produk dari bugs.

Hasil pengamatan mencatat bahwa Microsoft menjadi perusahaan yang menggunakan pengembangan produk secara iterasi dan berkesinambungan. Budaya Microsoft memberikan pengalaman tersendiri bagi para programmer yang yang tidak menyukai banyak peraturan, struktur dan perencanaan. Ini merupakan strategi yang kompetitif dalam mengidentifikasi pasar secara cepat.

 

Tim Synchronize–and-Stabilize

Ide dibalik model synchronize and stabilize cukup sederhana: secara berkesinambungan melakukan synchronize terhadap pekerjaan yang dilakukan oleh tim secara paralel, dan secara periodik melakukan stabilize terhadap produk sampai produk itu selesai. Microsoft menggunakan pendekatan dalam pengembangan software dan organisasi tim sejak akhir tahun 1980an terhadap produk-produknya, termasuk Office, Publisher, Windows 95/98, Windows NT dan menuai sukses terhadap hasil produknya.

Secara umum gambaran tim yang dibuat dapat dilihat pada gambar di bawah. Sejak produk-produk Microsoft diluncurkan ke pasar (dalam hal tertentu ke client tertentu), masing-masing produk terdiri atas Manager Produk yang terfokus ke satu produk dimana mempunyai suatu vision statement untuk setiap produk. Vision Statement dikembangkan menggunakan customer feedback, tujuan dari produk dan prioritas terhadap suatu fitur-fitur yang harus diselesaikan untuk membangun sebuah software. Vision Statement digunakan sebagai informasi untuk mendefinisikan fungsi spesifikasi, arsitektur dan interpendensi komponen. Seteleh fungsi spesifikasi didefinisikan, Program Manager berkoordinasi untuk mengatur jadwal terhadap Tim Fitur, dimana untuk masing-masing tim terdiri dari 1 program manager, 3-8 programmer dan 3-8 tester yang bekerja secara paralel 1:1 dengan programmer.

synchronize_stabilize

Organisasi tim Synchronize and Stabilize dan pendekatan pengambilan keputusan.

Setelah fase perencanaan selesai (dimana biasanya memakan waktu antara 3 sampai 12 bulan tergantung dari besarnya dan kompleksitas dari suatu produk), project akan berlanjut ke dalam fase pengembangan. Dalam hal ini, project dibagi menjadi 3 atau 4 subproject, dimana masing-masing team melakukan siklus pengembangan (integrasi, testing dan debugging). Selama siklus tersebut, programmer bebas untuk mengembangkan komponen-komponen dan fitur-fitur secara mandiri. Rasio 1:1 programmer/tester memberikan synchronization harian untuk memastikan hasil yang sempurna dalam siklus pengembangan. Bagaimanapun, kadang-kadang terjadi error yang tidak diinginkan.

Proses tim Synchronize-and-Stabilize dapat dirangkum sebagai berikut:

  • Berorientasi kepada fitur
  • Synchronize (pengembangan harian) and Stabilize (perbaikan kesalahan di setiap milestone)
  • Product Managers mengembangkan vision statement dan fitur yang sesuai dengan keinginan customer.
  • Program Managers mengembangkan fungsional spesifikasi berdasarkan vision statement.
  • Program Managers membuat jadwal dan tim fitur paralel antara 3-8 pengembang dan penguji berdasarkan fungsional spesifikasi.
  • Anggota tim dapat bekerja secara mandiri, sehingga dapat menghasilkan kreativitas dan kebebasan di dalam sebuah project.
  • Fase perencanaan (3-12 bulan, tergantung besarnya suatu project)
    • vision statement
    • specification
    • schedule and feature team formation
  • Fase Pengembangan (6-12 bulan)
    • subproject I: krusial 1/3 fitur, milestone release I
    • subproject II: 1/3 fitur, milestone release II
    • subproject III: final 1/3 fitur, milestone release III — code complete
  • Fase Stabilization (3-8 bulan)
  • Internal testing
  • External testing di bagian “beta tester”
  • Siap untuk diluncurkan, dimana terdapat “golden master” dan dokumentasi.

 

Keuntungan Dari Synchronize-And-Stabilize

Walaupun prinsip-prinsip dibalik synchronize and stabilize memberikan persamaan dalam hal cepatnya pengembangan sistem, disana tidak terdapat suatu tahap yang dapat memecahkam masalah besar dengan dengan solusi yang singkat. Melainkan, terdapat pendekatan yang spesifik, tool dan teknik, beberapa aturan yang kaku dan tingginya kemampuan orang-orang yang menggunakan pendekatan ini. Beberapa elemen membedakan synchronize and stabilize dengan beberapa pengembangan yang lebih lama.

Pendekatan synchronize and stabilize mempunyai beberapa keuntungan bagi para manajer dan engineer dalam mengembangkan suatu produk.

  • Membagi produk yang besar ke dalam bagian-bagian yang lebih kecil (prioritas dari fitur produk yang memiliki tim fitur kecil dapat dibuat dalam beberapa bulan)
  • Membuat project bekerja secara sistematis meskipun mereka tidak dapat menggambarkan dan menyelesaikan suatu produk di awal project.
  • Mengijinkan tim besar bekerja menjadi tim yang lebih kecil dengan membagi sebuah tim menjadi beberapa bagian, bekerja secara paralel tetapi tetap dapat berkesinambungan dalam men synchronizing setiap perubahan, stabilizing produk dan menemukan serta memperbaiki kesalahan.
  • Memfasilitasi masukkan dari customer, fitur produk dan waktu pengembangan yang pendek, yang didukung oleh mekanisme masukkan customer, prioritas, menyelesaikan dahulu bagian yang sangat penting dan melakukan perubahan tanpa harus mengurangi fitur yang diperlukan.

Mengijinkan suatu tim produk menjadi lebih responsive dalam penempatan produk di pasar dengan “selalu” mempunyai produk yang siap untuk dijual, mempunyai keakuratan fitur yang komplit dan fleksibilitas produk yang tinggi.

Related posts:

  1. Metodologi Pengembangan Sistem
  2. Rapid Application Development (RAD)
  3. Apa Itu Manajemen Proyek
  4. Joint Application Development (JAD)

5 Responses to “Synchronize and Stabilize”

Leave a Reply

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

four × 3 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.