Organisasi alur kerja dalam tim pada proyek TI

Halo teman teman. Cukup sering, terutama di outsourcing, saya melihat gambaran yang sama. Kurangnya alur kerja yang jelas dalam tim di berbagai proyek.

Yang paling penting adalah programmer tidak mengerti bagaimana berkomunikasi dengan pelanggan dan satu sama lain. Bagaimana membangun proses berkelanjutan untuk mengembangkan produk yang berkualitas. Bagaimana merencanakan hari kerja dan sprint Anda.

Dan semua ini pada akhirnya menghasilkan tenggat waktu yang rusak, lembur, pertikaian terus-menerus tentang siapa yang harus disalahkan, dan ketidakpuasan pelanggan - ke mana dan bagaimana semuanya bergerak. Cukup sering, semua ini mengarah pada pergantian programmer, dan bahkan seluruh tim. Kehilangan pelanggan, penurunan reputasi dan sebagainya.

Pada suatu waktu, saya baru saja mengerjakan proyek seperti itu, di mana ada semua kesenangan ini.

Tidak ada yang mau bertanggung jawab atas proyek tersebut (pasar layanan besar), omsetnya sangat buruk, pelanggan hanya merobek dan membuang. CEO entah bagaimana mendekati saya dan mengatakan bahwa Anda memiliki pengalaman yang diperlukan, jadi Anda memiliki kartu di tangan Anda. Ambil proyek untuk diri sendiri. Jika Anda mengacau, kami akan menutup proyek dan mengeluarkan semua orang. Ini akan menjadi keren, lalu pimpin dan kembangkan sesuai keinginan Anda. Hasilnya, saya menjadi pemimpin tim dalam proyek tersebut dan semuanya berada di pundak saya.

Hal pertama yang saya lakukan adalah mendesain alur kerja dari awal yang sesuai dengan visi saya saat itu dan menulis deskripsi pekerjaan untuk tim. Menerapkannya ternyata tidak mudah. Tetapi di suatu tempat dalam sebulan semuanya beres, pengembang dan klien terbiasa, dan semuanya berjalan dengan tenang dan nyaman. Untuk menunjukkan kepada tim bahwa ini bukan hanya "badai dalam gelas", tetapi jalan keluar yang nyata dari situasi tersebut, saya mengambil tanggung jawab maksimum, menghilangkan rutinitas yang tidak menyenangkan dari tim.

Satu setengah tahun telah berlalu, dan proyek ini berkembang tanpa lembur, tanpa "perlombaan tikus" dan segala macam tekanan. Seseorang di tim lama tidak ingin bekerja seperti itu dan pergi, sebaliknya, seseorang benar-benar terlibat sehingga aturan transparan muncul. Namun sebagai hasilnya, semua orang di tim sangat termotivasi dan mengetahui proyek besar ini sepenuhnya, baik front-end maupun back-end. Termasuk basis kode dan semua logika bisnis. Bahkan sampai pada titik bahwa kami bukan hanya "pendayung", tetapi kami sendiri yang menghadirkan banyak proses bisnis dan fitur baru yang disukai bisnis.

Berkat pendekatan kami ini, pelanggan memutuskan untuk memesan pasar lain dari perusahaan kami, yang merupakan kabar baik.

Karena ini berfungsi pada proyek saya, mungkin itu juga akan membantu seseorang. Jadi, prosesnya sendiri, yang membantu kami menyelamatkan proyek:

Proses kerja tim pada proyek "Proyek favorit saya"

a) Dalam proses tim (antara pengembang)

  • Semua tugas dibuat dalam sistem Jira
  • Setiap tugas harus dijelaskan sebanyak mungkin, dan hanya melakukan satu tindakan.
  • Fitur apa pun, jika cukup rumit, dipecah menjadi banyak tugas kecil
  • Tim mengerjakan fitur sebagai tugas tunggal. Pertama, kami melakukan satu fitur bersama-sama, memberikannya untuk pengujian, lalu mengambil yang berikutnya.
  • Setiap tugas diberi label untuk backend atau frontend
  • Ada jenis tugas dan bug. Anda perlu menentukannya dengan benar.
  • Setelah tugas selesai, itu ditransfer ke status tinjauan kode (permintaan tarik dibuat untuk rekannya)
  • Orang yang menyelesaikan tugas segera melacak waktunya untuk tugas ini
  • Setelah memeriksa kode, PR disetujui dan setelah itu, orang yang melakukan tugas ini secara mandiri menggabungkannya ke cabang master, setelah itu mengubah statusnya menjadi siap untuk diterapkan ke server dev.
  • Semua tugas yang siap diterapkan ke server dev disebarkan oleh pemimpin tim (bidang tanggung jawabnya), terkadang anggota tim, jika ada sesuatu yang mendesak. Setelah penerapan, semua tugas dari siap untuk diterapkan hingga dev ditransfer ke status - siap untuk diuji di dev
  • Semua tugas diuji oleh pelanggan
  • Saat pelanggan telah menguji tugas di dev, dia mentransfernya ke status siap untuk diterapkan ke produksi.
  • Untuk penerapan ke produksi, kami memiliki cabang terpisah tempat kami menggabungkan master tepat sebelum penerapan
  • Jika selama pengujian pelanggan menemukan bug, maka dia mengembalikan tugas untuk revisi, mengatur statusnya dikembalikan untuk revisi. Beginilah cara kami memisahkan tugas baru dari tugas yang belum diuji.
  • Hasilnya, semua tugas mulai dari pembuatan hingga penyelesaian: To Do β†’ In Development β†’ Code Review β†’ Ready deploy to dev β†’ QA on dev β†’ (Return to dev) β†’ Ready deploy to prod β†’ QA on prod β†’ Done
  • Setiap pengembang menguji kodenya secara mandiri, termasuk sebagai pengguna situs. Tidak diperbolehkan menggabungkan cabang dengan yang utama, kecuali diketahui pasti bahwa kode tersebut berfungsi.
  • Setiap tugas memiliki prioritas. Prioritas ditetapkan oleh pelanggan atau pemimpin tim.
  • Pengembang melakukan tugas prioritas terlebih dahulu.
  • Pengembang dapat memberikan tugas satu sama lain jika bug yang berbeda ditemukan dalam sistem atau satu tugas terdiri dari pekerjaan beberapa spesialis.
  • Semua tugas yang dibuat pelanggan dikirim ke pemimpin tim, yang mengevaluasinya dan meminta pelanggan untuk menyelesaikannya atau menugaskannya ke salah satu anggota tim.
  • Semua tugas yang siap diterapkan ke dev atau prod juga sampai ke pemimpin tim, yang secara mandiri menentukan kapan dan bagaimana menerapkannya. Setelah setiap penerapan, pemimpin tim (atau anggota tim) harus memberi tahu pelanggan tentang hal ini. Dan juga ubah status tugas menjadi siap untuk pengujian di dev / prod.
  • Setiap hari pada waktu yang sama (kami memilikinya pukul 12.00) kami mengadakan rapat umum di antara semua anggota tim
  • Semua orang di rapat umum melaporkan, termasuk pemimpin tim, apa yang dia lakukan kemarin, apa yang dia rencanakan hari ini. Apa yang tidak berhasil dan mengapa. Dengan demikian, seluruh tim mengetahui siapa melakukan apa dan pada tahap apa proyek tersebut. Ini memberi kami kesempatan untuk memprediksi dan menyesuaikan, jika perlu, perkiraan dan tenggat waktu kami.
  • Pada pertemuan tersebut, pemimpin tim juga mengumumkan semua perubahan dalam proyek dan tingkat bug saat ini yang tidak ditemukan oleh pelanggan. Semua bug disortir dan ditugaskan ke setiap anggota tim untuk menyelesaikannya.
  • Pada rapat umum, pemimpin tim memberikan tugas untuk masing-masing, dengan mempertimbangkan beban kerja pengembang saat ini, tingkat pelatihan profesional mereka, dan juga mempertimbangkan kedekatan tugas tertentu dengan apa yang sedang dilakukan pengembang.
  • Pada pertemuan tersebut, pemimpin tim mengembangkan strategi umum untuk arsitektur dan logika bisnis. Setelah itu, seluruh tim mendiskusikan hal ini dan memutuskan apakah akan melakukan penyesuaian atau mengadopsi strategi ini.
  • Setiap pengembang menulis kode dan membangun algoritme secara mandiri dalam satu arsitektur dan logika bisnis. Setiap orang dapat mengungkapkan visi penerapannya, tetapi tidak ada yang memaksa siapa pun untuk melakukannya dengan cara ini dan bukan sebaliknya. Setiap keputusan dibenarkan. Jika ada solusi yang lebih baik, tetapi sekarang tidak ada waktu untuk itu, maka tugas dibuat dengan gemuk, untuk pemfaktoran ulang bagian kode tertentu di masa mendatang.
  • Saat pengembang mengerjakan tugas, dia memindahkannya ke status pengembangan. Semua komunikasi mengenai klarifikasi tugas dengan pelanggan berada di pundak pengembang. Pertanyaan teknis dapat ditanyakan kepada pemimpin tim atau rekan kerja.
  • Jika pengembang tidak memahami inti dari tugas tersebut, dan pelanggan tidak dapat menjelaskannya dengan bijaksana, maka dia melanjutkan ke tugas berikutnya. Dan pemimpin tim mengambil yang sekarang dan mendiskusikannya dengan pelanggan.
  • Setiap hari, pengembang harus menulis di obrolan klien tentang tugas apa yang dia kerjakan kemarin dan tugas apa yang akan dia kerjakan hari ini
  • Alur kerja didasarkan pada Scrum. Semuanya dibagi menjadi sprint. Setiap sprint berlangsung selama dua minggu.
  • Sprint dibuat, diisi, dan ditutup oleh pemimpin tim.
  • Jika proyek memiliki tenggat waktu yang ketat, maka kami mencoba memperkirakan secara kasar semua tugas. Dan kami mengumpulkan sprint dari mereka. Jika pelanggan mencoba menambahkan lebih banyak tugas ke sprint, maka kami menetapkan prioritas, dan mentransfer beberapa tugas lain ke sprint berikutnya.

b) Proses bekerja dengan pelanggan

  • Setiap pengembang dapat dan harus berkomunikasi dengan pelanggan
  • Anda tidak dapat mengizinkan pelanggan untuk memaksakan aturan permainan mereka sendiri. Perlu dengan cara yang sopan dan ramah untuk menjelaskan kepada pelanggan bahwa kami adalah spesialis di bidang kami, dan hanya kami yang harus membangun proses kerja dan melibatkan pelanggan di dalamnya.
  • Idealnya, sebelum melanjutkan penerapan fungsionalitas apa pun, perlu membuat bagan alur dari seluruh proses logis untuk suatu fitur (alur kerja). Dan kirimkan ke pelanggan untuk konfirmasi. Ini hanya berlaku untuk fungsionalitas yang kompleks dan tidak jelas, misalnya, sistem pembayaran, sistem notifikasi, dll. Ini akan memungkinkan Anda untuk lebih akurat memahami apa yang sebenarnya dibutuhkan pelanggan, menyimpan dokumentasi untuk fitur tersebut, dan juga memastikan diri Anda dari fakta bahwa pelanggan dapat mengatakan di masa mendatang bahwa kami tidak melakukan apa yang dia minta.
  • Semua diagram/diagram alur/logika dll. kami menyimpan di Confluence/Fat, di mana kami meminta pelanggan di komentar untuk mengonfirmasi kebenaran penerapan di masa mendatang.
  • Kami berusaha untuk tidak membebani pelanggan dengan detail teknis. Jika kita membutuhkan pemahaman tentang apa yang diinginkan pelanggan, maka kita menggambar algoritma primitif dalam bentuk diagram alur yang dapat dipahami pelanggan dan memperbaiki / memodifikasi semuanya sendiri.
  • Jika pelanggan menemukan bug dalam proyek, kami meminta Anda untuk menjelaskannya dengan sangat rinci di Fat. Dalam keadaan apa itu terjadi, kapan, urutan tindakan apa yang dilakukan oleh pelanggan selama pengujian. Harap lampirkan tangkapan layar.
  • Kami mencoba setiap hari, maksimal setiap hari, untuk menerapkan ke server dev. Pelanggan kemudian mulai menguji fungsionalitas dan proyek tidak menganggur. Pada saat yang sama, ini adalah penanda bagi pelanggan bahwa proyek sedang dalam pengembangan penuh dan tidak ada yang menceritakan dongeng kepadanya.
  • Seringkali pelanggan tidak sepenuhnya memahami apa yang dia butuhkan. Karena dia menciptakan bisnis baru untuk dirinya sendiri, dengan proses yang belum di-debug. Oleh karena itu, situasi yang sangat umum adalah saat kita membuang seluruh potongan kode ke tempat sampah dan membentuk ulang logika aplikasi. Oleh karena itu, tidak perlu menutupi semuanya dengan tes. Masuk akal untuk hanya mencakup fungsionalitas kritis dengan pengujian, lalu dengan reservasi.
  • Ada situasi ketika tim menyadari bahwa kami tidak memenuhi tenggat waktu. Kemudian kami melakukan audit cepat atas tugas tersebut, dan segera memberi tahu pelanggan tentang hal itu. Sebagai jalan keluar dari situasi tersebut, kami menyarankan untuk meluncurkan fungsionalitas penting dan kritis tepat waktu, dan meninggalkan sisanya untuk pasca-rilis.
  • Jika pelanggan mulai memikirkan tugas yang berbeda dari kepalanya, mulai berfantasi dan menjelaskan dengan jarinya, maka kami memintanya untuk memberi kami tata letak halaman dan alur dengan logika yang harus sepenuhnya menggambarkan perilaku seluruh tata letak dan sifatnya. elemen.
  • Sebelum kita melakukan tugas apa pun, kita harus memastikan bahwa fitur ini sudah termasuk dalam ketentuan perjanjian / kontrak kita. Jika ini adalah fitur baru yang melampaui perjanjian awal kami, maka kami pasti harus memperkirakan fitur ini ((perkiraan waktu tunggu + 30%) x 2) dan menunjukkan kepada pelanggan bahwa ini akan memakan banyak waktu bagi kami, ditambah batas waktu digeser untuk perkiraan waktu dikalikan dua. Mari kita percepat tugas - bagus, semua orang hanya akan mendapat manfaat dari ini. Jika tidak, maka kami diasuransikan.

c) Apa yang tidak kami terima dalam tim:

  • Inkonsistensi, inkoherensi, kelupaan
  • "Makan Sarapan". Jika Anda tidak dapat menyelesaikan tugas, Anda tidak tahu caranya, maka Anda harus segera memberi tahu pemimpin tim tentang hal ini, dan tidak menunggu sampai yang terakhir.
  • Brovada dan bualan dari seseorang yang belum membuktikan kemampuan dan profesionalismenya dengan perbuatan. Jika terbukti, maka dimungkinkan, dalam batas kesopanan πŸ™‚
  • Penipuan dalam segala manifestasinya. Jika tugas belum selesai, sebaiknya jangan ubah statusnya menjadi selesai dan tulis di obrolan klien bahwa sudah siap. Komputer macet, sistem macet, anjing mengunyah laptop - semua ini tidak dapat diterima. Jika terjadi force majeure yang nyata, maka pemimpin tim harus segera diberi tahu.
  • Ketika seorang spesialis sedang offline sepanjang waktu dan sulit untuk menghubunginya selama jam kerja.
  • Toksisitas dalam tim tidak diperbolehkan! Jika seseorang tidak setuju dengan sesuatu, maka semua orang berkumpul untuk rapat umum dan berdiskusi serta memutuskan.

Dan beberapa pertanyaan / tesis yang terkadang saya tanyakan kepada pelanggan saya untuk menghapus semua kesalahpahaman:

  1. Apa kriteria kualitas Anda?
  2. Bagaimana Anda menentukan apakah suatu proyek memiliki masalah atau tidak?
  3. Melanggar semua rekomendasi dan saran kami untuk mengubah/meningkatkan sistem, hanya Anda yang menanggung semua risikonya
  4. Setiap perubahan proyek besar (misalnya, semua jenis aliran tambahan) akan mengarah pada kemungkinan munculnya bug (yang tentu saja akan kami perbaiki)
  5. Tidak mungkin untuk memahami dalam beberapa menit masalah apa yang terjadi pada proyek, dan terlebih lagi untuk memperbaikinya di sana
  6. Kami mengerjakan alur produk tertentu (Tugas di Zhira - Pengembangan - Pengujian - Penerapan). Artinya, kami tidak dapat menanggapi seluruh aliran permintaan dan keluhan dalam obrolan.
  7. Pemrogram hanyalah pemrogram, bukan penguji profesional, dan tidak dapat memastikan kualitas pengujian proyek yang tepat
  8. Tanggung jawab untuk pengujian akhir dan penerimaan tugas penjualan sepenuhnya berada di tangan Anda
  9. Jika kita telah mengambil tugas, maka kita tidak dapat langsung beralih ke tugas lain sampai kita menyelesaikan tugas saat ini (jika tidak, ini akan menyebabkan lebih banyak bug dan peningkatan waktu pengembangan)
  10. Ada lebih sedikit orang dalam tim (karena liburan atau sakit), dan ada lebih banyak pekerjaan dan kami secara fisik tidak punya waktu untuk menanggapi semua yang Anda inginkan
  11. Meminta Anda menerapkan ke produksi tanpa tugas yang diuji di dev hanyalah risiko Anda, bukan risiko pengembang
  12. Saat Anda menetapkan tugas yang tidak jelas, tanpa alur yang benar, tanpa tata letak desain, ini membutuhkan lebih banyak upaya dan waktu implementasi dari kami, karena kami harus melakukan lebih banyak pekerjaan daripada Anda
  13. Setiap tugas pada bug, tanpa penjelasan mendetail tentang kejadian dan tangkapan layarnya, tidak memberi kami kesempatan untuk memahami apa yang salah dan bagaimana kami dapat mengeluarkan bug ini
  14. Proyek ini membutuhkan penyempurnaan dan perbaikan terus-menerus untuk meningkatkan kinerja dan keselamatan. Oleh karena itu, tim menghabiskan sebagian waktunya untuk peningkatan ini.
  15. Karena kami memiliki jam lembur (perbaikan mendesak), kami harus menggantinya di hari lain

Biasanya, pelanggan segera memahami bahwa dalam pengembangan perangkat lunak semuanya tidak sesederhana itu, dan keinginan saja jelas tidak cukup.

Secara umum, ini saja. Di belakang layar, saya meninggalkan banyak negosiasi dan debugging awal dari semua proses, tetapi sebagai hasilnya, semuanya berhasil. Saya dapat mengatakan bahwa proses ini telah menjadi semacam "Peluru Perak" bagi kami. Orang-orang baru yang datang ke proyek sudah dapat langsung bekerja sejak hari pertama, karena semua proses dijelaskan, dan dokumentasi serta arsitektur dalam bentuk diagram segera memberikan gambaran tentang apa yang kita semua lakukan Di Sini.

PS Saya ingin mengklarifikasi bahwa tidak ada manajer proyek di pihak kami. Itu ada di sisi klien. Bukan teknisi sama sekali. proyek Eropa. Semua komunikasi hanya dalam bahasa Inggris.

Semoga sukses untuk semua orang di proyek Anda. Jangan kehabisan tenaga dan coba tingkatkan proses Anda.

sumber di saya posting blog.

Sumber: www.habr.com