Saya baru-baru ini bergabung dengan proyek pengembangan dan tiba-tiba diberi pekerjaan pengembang utama. Tanggung jawab utama saya adalah memecah bagian pemrograman dari proyek menjadi tugas, memberikan tugas-tugas ini kepada pengembang lain, dan kemudian memastikan bahwa potongan-potongan itu bekerja bersama.

Masalahnya adalah saya tidak tahu bagaimana melakukan ini. Saya menghabiskan akhir pekan saya dengan pensil dan kertas untuk mencari tahu, tetapi saya terus membuat daftar tugas yang harus dikerjakan secara berurutan alih-alih secara paralel. Saya sudah memikirkan mungkin membaginya menjadi fitur-fitur tetapi kemudian Anda berakhir dengan tugas-tugas yang memerlukan pengeditan file yang sama, yang mungkin memerlukan seluruh tugas untuk sepenuhnya ditulis ulang karena seberapa awal perkembangan kami. Saya bisa meminta beberapa pengembang menunggu sampai programnya sedikit lebih lengkap dan lebih mudah untuk membuat tugas, tetapi kemudian saya akan meminta orang-orang yang tahu berapa minggu.

Saya telah berbicara dengan bos saya tentang kualifikasi saya untuk melakukan ini dan saya tidak diberi pilihan dalam masalah ini. Saya tidak tahu apa yang saya lakukan, jadi tip dan dorongan ke arah yang benar akan sangat dihargai.

Jawaban yang tepat untuk pertanyaan Anda mengisi beberapa buku . Saya akan datang dengan daftar kata-kata buzz yang muncul di pikiran saya tentang ini, Google dan buku akan melakukan sisanya untuk Anda.

1. Dasar-dasar

   • Jangan pergi sendiri . Cobalah untuk melibatkan rekan setim Anda sebanyak mungkin.
   • Perjalanan ringan .
   • Demokrasi, tetapi tidak terlalu banyak. Kadang-kadang, ini bukan tentang apa yang memuaskan jumlah terbesar orang, tetapi apa yang menyakitkan paling sedikit jumlah orang.
   • Simpan apa (perlu dilakukan) dan bagaimana (dilakukan) terpisah .
   • Pelajari tentang Scrum ("apa"), XP (Pemrograman Ekstrim, "bagaimana"), Kanban ("berapa banyak"), Lean ("apa yang tidak") dan DevOps ("dengan siapa").
   • Lean juga tentang aliran : Untuk efisiensi keseluruhan, efisiensi aliran biasanya lebih penting daripada efisiensi individu.
   • Pelajari tentang Pengerjaan Perangkat Lunak , Kode Bersih dan Pemrograman Pragmatis .
   • Arsitektur yang baik adalah tentang memaksimalkan jumlah keputusan yang tidak diambil .
   • Scrum / XP / Lean / Agile adalah tentang memaksimalkan jumlah pekerjaan yang tidak dilakukan : YAGNI .
   • The Nilai Primer Software adalah bahwa Anda dapat dengan mudah mengubah itu. Itu melakukan apa yang harus dilakukan itu penting tetapi itu hanya Nilai Sekunder.
   • Lebih suka pendekatan berulang dan bertahap , gunakan kotak waktu untuk hampir semua hal, terutama pertemuan, menjadikan Hukum Parkinson sebagai teman Anda karena Hukum Hofstadter berlaku.
   • Seimbangkan struktur tim dengan pemahaman tentang Hukum Conway dan Tahapan Pengembangan Tim Tuckman .
   • Pemrograman adalah quaternity, itu adalah sains , teknik , seni dan kerajinan semua pada saat yang sama, dan mereka harus seimbang.
   • Hanya karena Scrum / XP / XYZ baik untuk seseorang (termasuk saya) tidak berarti itu baik untuk Anda / sesuai dengan lingkungan Anda. Jangan membabi buta mengikuti hype, pahami dulu.
   • Periksa dan Adaptasi! (Scrum Mantra)
   • Hindari Duplikasi - Sekali dan Sekali Saja! (XP Mantra) aka KERING - Don't Repeat Yourself aka SPOT - Single Point of Truth

2. Proses pemecahan pekerjaan "Dunia apa"

   • Kumpulkan Persyaratan sebagai Cerita Pengguna / Cerita Pekerjaan ke dalam Backlog Produk .
   • Pengguna (dari Kisah Pengguna) mirip dengan Aktor (dalam UML) mirip dengan Persona mirip dengan Peran .
   • Saring Cerita Pengguna hingga memenuhi definisi Siap dari tim Anda berdasarkan INVEST (Independen, Nego, Berharga, Diperkirakan, Kecil, Dapat Diuji). (Rapat Scrum: Penyempitan Backlog )
   • Urutkan Product Backlog menurut Nilai Bisnis .
   • Jangan mulai mengerjakan Story sebelum Ready Ready (siap sesuai dengan definisi ready).
   • Gunakan Poker Perencanaan untuk memperkirakan upaya Cerita di Story Points . Gunakan Perbandingan Triangulasi untuk memastikan konsistensi estimasi.
   • Cuaca kemarin adalah perkiraan terbaik, harap yang terburuk.
   • Pisahkan Cerita jika terlalu besar.
   • Tingkatkan budaya pengiriman dengan Definisi Selesai .
   • Jangan terima implementasi Cerita Pengguna sebelum Selesai Done (dilakukan sesuai dengan Definisi Selesai).
   • Beberapa tim pada basis kode yang sama harus menyetujui dan berbagi Definisi Selesai yang sama (terutama Standar Pengkodean ).
   • Periksa kemajuan Anda dengan Burndown Charts .
   • Secara teratur tanyakan kepada Stakeholder Anda apakah yang diberikan tim adalah yang benar-benar dibutuhkan. (Rapat Scrum: Ulasan Sprint )

3. Rincian Cerita

   • Daftar dan Jelaskan Pengguna / Persona / Aktor / Peran (Pemilik Produk)
   • Epik -> Cerita (Kisah Pengguna atau Kisah Pekerjaan) (Pemilik Produk)
   • Story -> Kriteria Penerimaan (Pemilik Produk)
   • Story -> Subtasks (Dev Team)
   • Kriteria Penerimaan -> Tes Penerimaan (Spesifikasi: Pemilik Produk, Impl: Tim Pengembang)
   • Mulailah dengan Kerangka Berjalan yang merupakan End-to- (Half-End) yang minimalis .
   • Buat MVP - Produk yang layak Minimum .
   • Perluas MVP menggunakan SMURFS - Set Fitur yang Dapat Dipasarkan, Bermanfaat, dan Dapat Dihapus Secara Khusus .

4. Realisasi "Bagaimana dunia"

   • Gunakan Kartu OOA / D , UML dan CRC , tetapi hindari desain besar di muka .
   • Menerapkan berorientasi objek , terstruktur dan fungsional pada saat yang sama sebanyak mungkin, terlepas dari bahasa pemrogramannya.
   • Gunakan Kontrol Versi (sebaiknya didistribusikan ).
   • Mulailah dengan Tes Penerimaan .
   • Terapkan TDD , membiarkan Tiga Hukum TDD mengantar Anda melalui Siklus Merah-Hijau-Reaktor , dengan Aturan-Tunggal-Tegaskan , 4 A , GWT (Diberikan Saat Lalu) dari BDD .
   • " Tes Unit adalah tes yang berjalan cepat ." - Michael Feathers
   • Terapkan prinsip SOLID dan paket untuk mengelola Kopling dan Kohesi . Contoh: S dalam SOLID adalah SRP = Prinsip Tanggung Jawab Tunggal, secara signifikan mengurangi jumlah penyuntingan. gabungkan konflik dalam tim.
   • Ketahui Hukum Demeter / Katakan, Jangan Bertanya .
   • Gunakan Integrasi Berkelanjutan , jika berlaku bahkan Pengiriman Berkelanjutan (DevOps).
   • Gunakan Kepemilikan Kode Kolektif berdasarkan Standar Pengodean bersama yang disepakati (yang harus menjadi bagian dari Definisi Selesai ).
   • Menerapkan Peningkatan Desain Kontinyu (fka Continuous Refactoring).
   • Kode Sumber adalah Desain . Tetap berpikiran di muka sangat diperlukan, dan tidak ada yang akan keberatan beberapa diagram UML klarifikasi yang baik.
   • XP tidak berarti tidak ada hari adalah hari arsitektur, itu berarti setiap hari adalah hari arsitektur. Ini fokus pada arsitektur, bukan pengaburan, dan fokusnya ada dalam kode.
   • Pertahankan Utang Teknis Anda tetap rendah, hindari keempat desain yang berbau Fragility , Rigidity , Immobility dan Viscosity .
   • Arsitektur adalah tentang logika bisnis, bukan tentang ketekunan dan mekanisme pengiriman.
   • Arsitektur adalah olahraga tim ( tidak ada 'I' dalam Arsitektur ).
   • Pola Desain , Refactoring dan Premis Prioritas Transformasi .
   • Kode Proyek adalah ATP-Trinity dengan prioritas: 1. Kode Otomatisasi , 2. Kode Uji , 3. Kode Produksi .
   • Secara teratur periksa dengan rekan tim Anda apakah cara tim dapat ditingkatkan. (Rapat Scrum: Sprint Retrospective )
   • Tes harus PERTAMA - Cepat, Independen, Diulang, Validasi Sendiri dan Tepat Waktu.

Daftar di atas tentu saja tidak lengkap, dan beberapa bagian bahkan dapat diperdebatkan!

Jika semua ini membuat Anda takut - jangan khawatir, karena itu akan membuat Anda takut! Keberhasilan proyek pengembangan perangkat lunak dalam tim bukanlah tugas yang mudah, dan jarang orang yang dilatih dan dididik dengan baik dalam bidang ini. Jika ini membuat Anda takut, intuisi Anda berfungsi dengan baik, dengarkan. Anda ingin dipersiapkan. Bicaralah dengan atasan Anda, dapatkan waktu dan pelatihan.

Lihat juga

• Siapa yang menulis 'kisah pengguna' teknis dalam scrum

Bacaan lebih lanjut (online)

• Repositori Pola Portland oleh Ward Cunningham et al
• Prinsip OOD oleh Robert "Paman Bob" C. Martin
• Tip Programmer Pragmatis

Bacaan lebih lanjut (buku)

• Clean Code oleh Robert C. Martin
• Pengembangan Perangkat Lunak Agile: Prinsip, Pola, dan Praktek oleh Robert C. Martin
• The Pragmatic Programmer - Dari Journeyman ke Master oleh Andrew Hunt dan David Thomas
• Bekerja Efektif dengan Legacy Code oleh Michael Feathers
• Refactoring - Meningkatkan Desain Kode yang Ada oleh Martin Fowler
• Refactoring to Patterns oleh Joshua Kerievsky
• MBA Sepuluh Hari oleh Steven Silbiger (sic!)
• Desain Berbasis Domain oleh Eric Evans
• Kisah Pengguna Diterapkan oleh Mike Cohn
• Analisis dan Desain Berorientasi Objek dengan Aplikasi oleh Gray Booch et al
• Pola Desain oleh Geng Empat
• Pengembangan Test Driven oleh Kent Beck
• Pemrograman Ekstrim oleh Kent Beck
• [if Java] Java Efektif oleh Joshua Bloch

Dapatkan Agile

Saya akan menyarankan yang berikut ini:

Mengedit file yang sama

Pertama, gunakan Git (atau sistem versi bersamaan yang serupa). Selama Anda mengedit berbagai bagian dari file yang sama, Anda tidak akan mendapatkan konflik. Jika Anda mendapatkan konflik, konflik itu akan ditandai dengan jelas.

Mencoba mengelola proyek multi-pengembang tanpa Git seperti mencoba membuat puding tanpa mangkuk puding. Itu mungkin, tetapi akan menjadi sangat berantakan dengan cukup cepat.

Seperti yang telah ditunjukkan dalam komentar, Git bukanlah obat mujarab, tetapi dikombinasikan dengan pengujian otomatis, hal itu tentu sangat membantu.

Daftar semua fitur

Kedua, memecah proyek menjadi fitur yang terlihat pengguna. Misalnya "ketika pengguna mendaftar, mereka harus menerima email" atau "Pengguna dapat menambahkan item". Libatkan semua pemangku kepentingan di sini. Suruh semua orang di kamar, dan minta semua orang meneriakkan fitur mereka.

Ini harus menjadi fitur yang terlihat pengguna, Anda dapat berbicara tentang strategi implementasi nanti.

Tulis semua saran pada kartu indeks, bahkan yang bodoh. Cepat merasionalisasi daftar untuk menghapus duplikat, dan meletakkan semua kartu di atas meja besar, atau bahkan lantai.

Tambahkan kartu tambahan yang dibutuhkan. Katakanlah aplikasi Anda akan mengirim peringatan teks SMS. Anda mungkin tidak tahu bagaimana melakukannya, jadi Anda punya pertanyaan. Tulis "Investigasi portal SMS" pada kartu. Demikian juga untuk yang tidak diketahui besar lainnya. Anda harus membongkar ini nanti. Fitur-fitur ini mungkin tidak akan membuatnya menjadi sprint pertama Anda.

Sekarang urutkan kartu Anda ke dalam kelompok, kocok-kocok, rasakan . Ini adalah ruang lingkup proyek Anda.

Perencanaan poker

Selamat mencoba poker perencanaan. Masih bersama semua orang, berikan semua kartu pengembang yang mengatakan "1 poin", "2 poin", dll, hingga "4 poin". Juga kartu "lebih". Suatu titik kira-kira setara dengan satu jam.

Buka daftar fitur satu per satu. Saat Anda membaca fitur, setiap orang harus memainkan kartu. Jika satu orang bermain 1, dan orang lain bermain 4 ada masalah komunikasi di sana. Satu orang memahami fitur tersebut berarti sesuatu yang berbeda dari orang lain. Berdiskusi dan cari tahu apa yang sebenarnya dimaksudkan dan catat di kartu.

Jika Anda setuju bahwa suatu fitur "lebih", fitur itu terlalu besar. Anda harus memecah fitur itu. Lakukan ini dengan cara yang sama seperti sebelumnya.

Setelah Anda sepakat, tulis angka pada kartu dengan pena warna berbeda.

Poin lebih baik daripada jam

Menggunakan poin alih-alih jam menghilangkan hal macho "lihat seberapa cepat saya bisa kode" hal yang sering kita lakukan pengembang. Ini perbedaan yang halus, tapi saya telah menemukan itu berfungsi dengan baik.

Sekarang buat sprint

Sprint adalah ledakan cepat menuju sasaran. Tentukan panjang sprint, mungkin 5 atau 10 hari. Lipat gandakan jumlah hari dengan jumlah pengembang dengan jumlah poin per hari.

Asumsikan 6 poin per hari per pengembang pada awalnya. Ini adalah angka yang bisa dicapai. Jika Anda memiliki 5 orang, itu 5 * 5 * 6 = 150 poin. Sehubungan dengan semua pengembang dan manajemen, pilih fitur dari daftar, hingga 150 poin. Itu sprint kamu.

Jangan pernah tergoda untuk memeras lebih banyak daripada yang pas. Janji yang terlalu tinggi menyakiti semua orang dalam jangka panjang, termasuk Anda.

Anda harus memperhitungkan ketergantungan di sini. Misalnya, pengaturan lingkungan jelas harus dimasukkan dalam sprint pertama. Ini sebenarnya relatif mudah dilakukan ketika semua orang hadir. Anda memiliki 6 otak di dalam ruangan, semuanya mengatakan "ini tergantung pada ini", dll. Anda kemudian dapat mengocok kartu untuk menunjukkan ketergantungan.

Setelah Anda memiliki sprint Anda, tidak ada yang dapat ditambahkan ke dalamnya, itu terkunci selama 5 hari. Creep fitur akan menekankan tim, merusak moral dan memperlambat semua orang. Akhirnya, creep akan menghentikan proyek. Sebagai pemimpin tim Anda harus melindungi tim Anda dari creep fitur. Jika permintaan fitur baru masuk, itu harus ditambahkan ke sprint berikutnya. JIKA sprint berikutnya sudah penuh, sesuatu yang lain harus dikeluarkan.

Jangan pernah tergoda untuk memeras ekstra. Menjanjikan terlalu tinggi memberi Anda klien yang bahagia selama sekitar 1 hari, diikuti oleh 4 hari stres tim, dan akhirnya, kemungkinan besar, beberapa klien yang tidak bahagia ketika tim tidak dapat memenuhi tepat waktu.

Sekarang pergilah.

Bagikan kartu, tanyakan siapa yang ingin melakukan apa. Anda memiliki visibilitas penuh pada apa yang sedang dilakukan, dan Anda dapat menghitung poin dengan nol. Miliki standup pada awal setiap hari sehingga semua orang tahu siapa yang mengerjakan apa, dan apa yang telah dilakukan.

5 atau 6 pengembang termotivasi yang layak bekerja bersama sebagai unit pada tujuan yang dapat dikelola dengan jelas dapat mencapai jumlah barang yang cukup besar dalam sprint 5 hari.

Pertahankan visibilitas

Pastikan semua orang dapat melihat status proyek. Cetak semua kartu ke dinding. Di sebelah kiri adalah kartu yang belum dikerjakan. Di sebelah kanan dilakukan kartu.

Ketika seorang pengembang mengerjakan kartu, mereka melepaskannya dari dinding dan meletakkannya di atas meja mereka. Ini menjaga visibilitas, dan mencegah orang untuk saling menginjak kaki terlalu banyak.

Ada alternatif teknologi untuk kartu indeks, tetapi tidak ada yang mengalahkan memiliki tampilan kertas besar status proyek di dinding.

Jika memungkinkan, suruh semua orang berada di ruangan yang sama selama proyek berlangsung. Ajak para pemangku kepentingan berkeliling sebanyak mungkin, idealnya setiap hari.

Burndown

Anda dapat membuat grafik poin Anda menuju nol pada grafik burndown. Jika garis paling cocok Anda melewati nol sebelum mencapai batas waktu, Anda cenderung berada di jalurnya. Jika tidak, Anda mungkin perlu memberi tahu klien Anda sekarang, sebelum Anda terlalu dekat dengan tenggat waktu.

Jika Anda akan gagal, gagal lebih awal.

Anda dapat membuat burndown menggunakan perangkat lunak, tetapi saya lebih suka hanya selembar kertas besar di dinding. Gambar dan tulis semuanya.

Pengujian otomatis

Ketika Anda memiliki banyak pengembang yang mengerjakan hal yang sama pada waktu yang bersamaan, mereka mungkin akan saling memecah kode dari waktu ke waktu. Komunikasi dan visibilitas membantu dalam hal ini, tetapi Anda mungkin ingin memperkenalkan beberapa teknologi untuk membantu menemukan masalah.

Unit testing adalah proses penulisan tes untuk setiap bagian individu dari basis kode Anda (idealnya setiap metode). Tes unit Anda harus sering dijalankan, dengan setiap penyimpanan jika memungkinkan. Ada banyak alat yang dapat membantu dengan ini, misalnya Karma atau Rspec.

Pengujian ujung ke ujung melibatkan pengujian proyek Anda secara keseluruhan, memperlakukan bagian dalam sebagai kotak hitam. Dasarkan pengujian ini pada persyaratan bisnis tingkat tinggi Anda, misalnya: "Pengguna dapat mendaftar" atau "Pengguna dapat melihat daftar item". Busur derajat adalah contoh yang bagus dari ujung ke ujung kerangka pengujian berbasis web.

Ada banyak buku yang ditulis tentang pengujian, tetapi memiliki setidaknya beberapa tes penerimaan dapat membantu memastikan tidak ada yang rusak saat Anda mengerjakan proyek Anda.

Menghindari utang teknis dan menyelesaikan pekerjaan

Utang teknis adalah konsep yang menggambarkan hal-hal yang harus dibersihkan nanti. Sumber utang yang umum adalah fitur yang ditandai sudah selesai, tetapi tidak pernah "selesai dilakukan". Fitur selesai dilakukan diperiksa untuk Git, telah disetujui oleh pemangku kepentingan, dan memiliki tes.

Jangan centang fitur Anda sampai selesai. Jangan pernah memijat grafik. Sekali lagi, ini menyakitkan semua orang dalam jangka panjang, termasuk Anda.

Ini adalah salah satu alasan mengapa kami awalnya hanya mengutip 6 poin per pengembang, per hari. Selesai dilakukan membutuhkan kerja ekstra, tetapi terasa hebat dan memberi tim dorongan.

Mengedit file yang sama tidak dengan sendirinya menjadi masalah. Ini hanya masalah jika Anda mengedit fungsi yang sama untuk melakukan dua hal berbeda.

Pada dasarnya yang akan saya lakukan adalah, membagi proyek menjadi 'fitur' yang terpisah. Satu bisa berupa sesuatu yang terkait dengan penanganan protokol jaringan dan yang lainnya ke file konfigurasi, dan yang lain untuk penanganan DB. Fitur adalah hal besar.

Selanjutnya, Anda ingin membagi fitur-fitur itu menjadi tugas (cerita). Itu seharusnya hal-hal sederhana, seperti "ketika pengguna mengklik tombol, program akan memuat file", "ketika program dimulai, itu akan memuat file konfigurasi" dll.

Beberapa tugas harus diselesaikan secara berurutan ("program akan mem-parsing semua bidang dalam file konfigurasi" harus muncul setelah "program akan memuat file konfigurasi"). Lainnya tidak akan (Anda dapat bekerja pada DB dan jaringan pada saat yang sama).

Tetapi kemungkinan besar, Anda akan melakukan kesalahan, dan di situlah pengalaman terjadi. Anda akan gagal sedikit saja (atau banyak), salah estimasi waktu dan proyek Anda akan memakan waktu lebih lama dari yang seharusnya. Lain kali kamu akan lebih baik.

Saya juga menyarankan membaca "Pemrograman Ekstrim" oleh Kent Beck. Buku bagus yang membantu saya ketika saya akan menjadi manajer proyek.

Apa yang terjadi adalah bahwa Anda harus memecah aplikasi Anda menjadi modul fungsional dan kemudian memperkenalkan kontrak (antarmuka dan kontrak data) antara modul yang berbeda. Setiap modul kemudian dapat dibagikan kepada pengembang yang berbeda. Ketika Anda mengumpulkan semuanya kembali, kontrak akan memastikan bahwa modul-modul ini berkomunikasi satu sama lain dengan benar.

Pastikan Anda menerapkan TDD pada pengembang, untuk memastikan bahwa semua modul bekerja secara individual.

Untuk memberi Anda contoh tentang apa yang saya maksud:

Katakanlah Anda ingin salah satu pengembang Anda membuat logger SQL.

Anda mendefinisikan antarmuka dan meminta salah satu pengembang Anda ( atau membuat cerita jika Anda menggunakan Agile ) bahwa Anda ingin logger khusus SQL sesuai dengan spesifikasi berikut:

interface ILogger
{
    void Log(string message, int level);
}

Apa yang saya harapkan dari pengembang adalah sebagai berikut:

1. Implementasi spesifik SQL untuk logger

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. Kode dependen apa pun, seperti implementasi untuk SqlLogRepository

3. Tes unit atau tiruan tergantung dari apa yang diminta. Tes tiruan dalam kasus di atas (di mana kita memiliki dependensi eksternal lainnya), atau jika itu misalnya fungsi utilitas sederhana seperti String.ReverseCharacters(string input), maka saya hanya ingin melihat unit test yang menguji beberapa skenario yang berbeda.

Ini berarti:

Anda dan tim Anda sekarang dapat melanjutkan pengembangan menggunakan antarmuka ini. misalnya

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

dan jika Anda perlu menjalankan kode sebelum SqlLoggerada, Anda dapat dengan mudah membuat NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Dan ini adalah bagaimana Anda bisa mengujinya sementara itu (saya sarankan melihat ICO untuk injeksi ketergantungan)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Ringkasan

Saya tidak tahu ukuran proyek Anda, tetapi ini bisa menjadi tugas yang menakutkan dan jika Anda belum pernah melakukan pengembangan sebelumnya, saya akan menyarankan Anda mengambil tugas ini dengan sangat serius dan menghabiskan beberapa minggu ke depan membaca sebanyak yang Anda bisa. bisa pada desain perangkat lunak dan arsitektur. Dan sangat transparan tentang pekerjaan Anda ( kualitas perangkat lunak dll ) jika tidak, Anda akan dengan cepat menemukan diri Anda dalam kekacauan yang mendalam sehingga Anda tidak tahu bagaimana cara keluar.

Saya juga sangat menyarankan agar Anda membaca tentang desain dan paradigma berorientasi objek. Anda akan sangat bergantung pada OOP untuk proyek ini.

Jawaban lain telah berbicara tentang aspek pemrograman, tetapi saya hanya ingin menyebutkan aspek manajemen program. Saya akan mulai dengan penafian: Saya bukan manajer program. Saya telah mengambil satu program studi di tingkat pascasarjana untuk manajemen program dan pengalaman kerja saya melibatkan jam penawaran untuk proyek-proyek kecil yang biasanya di bawah 500 jam dan tidak pernah lebih dari 1000 jam.

Tetapi saya harus membantu menentukan penugasan untuk laboratorium tempat saya harus membuat 2-3 orang sibuk selama 2-4 bulan (paruh waktu dan penuh waktu). Satu hal yang sangat membantu saya adalah menggunakan perangkat lunak manajemen proyek seperti Microsoft Project (saya tidak yakin apakah ada versi freeware di luar sana, tetapi majikan Anda mungkin memiliki sesuatu seperti itu ... tanyakan kepada penyelia Anda jenis perangkat lunak manajemen program apa yang digunakan di perusahaan Anda). Secara khusus, saya menggunakan grafik Gantt sedikit, yang merupakan tampilan default di Microsoft Project. Dengan mendefinisikan semua tugas dan berapa lama Anda pikir itu akan berlangsung, Anda bisa mendapatkan visualisasi untuk dimainkan.

Grafik Gantt sangat membantu saya karena visualisasinya. Melihat tugas di atas kertas tidak banyak membantu saya, tetapi melihat gambar-gambar cantik dan bagan tentu saja membantu. Microsoft Project juga memungkinkan Anda untuk mengatur pendahulu dan tanggal mulai, dengan gagasan utama adalah "Temukan jumlah minimal tugas yang harus diselesaikan untuk tugas X untuk memulai". Setidaknya dalam proyek kecil saya, jumlah pendahulu 'nyata' cukup kecil. Bahkan, pada satu proyek saya punya masalah bahwa hampir semuanya bisa dilakukan bersamaan, dan harus mensintesiskan dua jalur bersamaan yang agak kohesif. Misalnya saya mencoba memastikan bahwa jika pengembang A pernah menyentuh GUI, mereka mengerjakan tugas yang dekat dengan GUI juga.

Kedengarannya seperti Anda sudah melakukan banyak ini sejauh pena dan kertas, tapi saya selalu merasa sangat membantu untuk benar-benar melihat grafik Gantt. Melihat tugas-tugas yang berurutan benar-benar membuat saya berpikir, "Tunggu, apakah tugas X benar-benar harus dilakukan sebelum tugas Y? (Dalam pengalaman saya sejauh ini, saya terkejut betapa seringnya jawabannya sebenarnya 'tidak')"

Sepertinya Anda telah lulus dari pengembang menjadi insinyur perangkat lunak. Sadarilah bahwa mengelola pekerjaan bukanlah latihan desain, tetapi keduanya berjalan seiring. Anda perlu mengelola pekerjaan yang sedang dilakukan, dan itu tergantung pada bagaimana perusahaan Anda melakukan pengembangan. Jika Anda punya waktu dan sumber daya, lihat mengadopsi metodologi yang gesit - ada banyak sekali materi tertulis di internet. Temukan yang cocok untuk Anda, tetapi perlu diketahui bahwa, seperti yang lainnya, itu tidak gratis. Adopsi teknik apa pun melibatkan pelatihan, pembelajaran, dan kegagalan sebelum Anda berhasil. Jika Anda tidak memiliki bandwidth untuk menangani mengadopsi teknik yang lebih komprehensif, maka melakukan perencanaan tonggak mungkin menjadi jawaban untuk Anda. Jika Anda memiliki daftar tugas berurutan, mungkin Anda belum menemukan urutan yang bisa dilakukandiparalelkan. Mungkin juga Anda ingin membagi pengembangan Anda menjadi tugas-tugas yang lebih umum seperti pengujian, dan implementasi. Itu, dengan sendirinya tidak menyelesaikan masalah pelaporan, tetapi Anda mengelola kualitas. Kemajuan Anda mungkin daftar berurutan, tetapi peran Anda paralel. Hanya sebuah saran. Desain yang memetakan ke dalam pekerjaan yang dilakukan oleh orang-orang disebut struktur rincian pekerjaan.

Ada banyak saran bagus yang ditawarkan orang lain, tetapi ingat Anda mengelola pekerjaan. Terkadang Anda dapat memetakan konsep kerja ke dalam desain / arsitektur, terkadang Anda tidak dapat melakukannya dengan mudah. Selalu ada cara untuk menyusun pekerjaan agar dapat dilacak. Saya sarankan kembali ke manajer Anda dan tanyakan padanya apa yang penting baginya ketika berkomunikasi dengan keadaan proyek. Itu akan mulai memberi tahu Anda bagaimana mendekati apa yang Anda lakukan. Jika sesuai jadwal, maka Anda ingin fokus pada pelaporan kemajuan. Jika kualitas, maka Anda ingin melaporkan serangkaian metrik yang harus Anda buat. Jika biayanya, maka Anda mungkin ingin melihat usaha. Semua hal itu juga dapat memetakan ke dalam atau keluar dari tugas.