Kapan Menggunakan mesin alur kerja?

Saya telah bekerja di masa lalu pada beberapa mesin alur kerja sebagai programmer tetapi tidak pernah memiliki kejelasan tentang mengapa kami memilih mesin alur kerja di tempat pertama. Dan sebagai programmer saya tahu bahwa setidaknya ada 100 cara untuk melakukan apa pun ketika Anda menulis kode tetapi hanya beberapa cara yang terbaik!

Saya masih tidak mengerti kasus penggunaan mana yang paling baik diselesaikan oleh mesin alur kerja (atau lebih tepatnya konsep mereka) daripada merancang aplikasi yang diaktifkan DI yang baik. Saya mencari karakteristik umum kasus penggunaan domain-netral, di mana mesin alur kerja adalah salah satu pilihan terbaik.

Jadi pertanyaan saya adalah: Apa karakteristik umum dari suatu persyaratan yang dapat diambil sebagai sinyal untuk memilih mesin alur kerja yang baik dan mengkodekannya?

Mesin alur kerja berguna ketika Anda harus beralih dari awal hingga selesai tetapi ada banyak jalur / logika / aturan yang berbeda untuk sampai ke sana.

Sebagai contoh, katakanlah saya menulis sebuah program yang menerbitkan konten. Jadi, dalam kasus saya, penerbitan melewati proses peninjauan, legal, dan kemudian persetujuan akhir. Saya menulis program yang menerapkan logika dan langkah-langkah proses saya. Sekarang ini bekerja baik untuk saya dan perusahaan saya. Jadi, saya memutuskan orang lain harus menggunakan program saya.

Sayangnya, tidak semua orang menerbitkan konten menggunakan proses yang sama, jadi alih-alih menulis proses terpisah untuk setiap kasus yang berbeda, kami akan menerapkan proses alur kerja sehingga program ini fleksibel untuk mengakomodasi semua orang. Tidak peduli berapa banyak langkah atau aturan atau logika di antara kedua poin tersebut hasilnya tetap sama.

Jadi, jika Anda memiliki proses yang variabel dari awal hingga akhir, gunakan alur kerja. Jika proses yang sama dapat digunakan oleh semua orang, maka Anda tidak perlu alur kerja.

Saya tahu Anda meminta kasus penggunaan, tetapi lebih mudah untuk membuat daftar keuntungan daripada membayangkan semua kasus penggunaan yang mungkin. Keuntungannya tentu saja tergantung pada mesin dan bahasa yang Anda bandingkan, tetapi secara umum:

1. Mempertahankan aturan sebagai data alih-alih kode berarti Anda tidak perlu mengkompilasi ulang, sehingga Anda dapat menguji perubahan dengan cepat, mengubah waktu berjalan, dll. Namun, tidak banyak keuntungan jika Anda tidak perlu melakukan kompilasi ulang sejak awal.

2. Pengguna dapat lebih diharapkan untuk mengedit aturan. Mereka berpotensi bermain-main dengan mereka secara interaktif dengan cara yang tidak layak ketika seorang programmer menulis kode untuk mereka.

3. Mematuhi peraturan karena data memungkinkan alat ditulis untuk memvisualisasikan dan mengubah data.

4. Mempertahankan aturan karena data memungkinkan meta-pemrograman lebih mudah - Anda dapat menulis kode untuk menganalisis data dan memasukkan lebih banyak dengan cara yang rumit, yang akan sangat sulit untuk kode.

Semua hal ini dimungkinkan untuk dilakukan secara langsung dengan kode (misalnya - tulis parser C # untuk menemukan semua aturan dari jenis tertentu dan menghasilkan kode untuk lebih banyak aturan, masukkan secara dinamis ke dalam perakitan dengan cara yang memungkinkan bongkar muat perakitan, alat tulis untuk pengguna untuk dapat melakukan ini juga menggunakan visualizer dan editor Anda) tetapi mungkin jauh lebih sulit tergantung pada bahasa Anda (programmer menggunakan Lisp mungkin merujuk ke item 1-4 sebagai "pemrograman").

IMHO kasus HANYA di mana Anda harus menggunakan hal semacam ini adalah ketika itu dapat dikonfigurasi oleh pengguna yang kurang berharga. Jika Anda dapat memecahkan masalah Anda dengan memberi mereka alat lalu kembali mengerjakan sesuatu yang lebih penting maka gunakan satu.

Jika Anda masih perlu mengaturnya untuk mereka maka saya akan membayangkan Anda bisa memikirkan 10 cara berbeda untuk mendapatkan hasil yang sama dengan alat yang Anda kenal dan itu akan jauh lebih mudah untuk mendukung dan menyesuaikan.

Ini terlihat seperti pertanyaan lama, tetapi muncul berkali-kali di alam liar. Saya setuju dengan jawaban Jon . Saya telah menemukan mesin alur kerja menjadi sangat produktif dalam skenario berikut:

1. Ada proses bisnis mendasar yang Anda coba wakili / laksanakan melalui perangkat lunak Anda.
2. Ada satu entitas bisnis (mungkin gabungan) yang dikerjakan dalam semua atau beberapa tahapan dalam proses. Dalam contoh yang diberikan Jon, entitas ini atau Item Alur Kerja adalah konten, atau artikel. Pertimbangkan pelacakan bug sebagai contoh lain dari alur kerja, transisi Bug antara berbagai kondisi, berdasarkan tindakan yang dilakukan pengguna.
3. Gunakan Alur kerja untuk memodelkan proses Anda, hanya jika Anda mengharapkan proses bisnis berubah, maksud saya adalah urutan atau tindakan yang dilakukan sebagai hasil dari tindakan atau transisi pengguna.

Berhati-hatilah dan kritis untuk melihat apakah domain / persyaratan masalah Anda memiliki proses bisnis, jangan mencoba "menyesuaikannya" dengan alur kerja.

Saya memiliki beberapa panduan yang saya gunakan untuk menyarankan mesin alur kerja.

1) Ketika analis bisnis tidak memiliki latar belakang pengkodean tetapi dapat menggambar diagram.

Mesin alur kerja modern menggunakan notasi pemodelan proses bisnis, atau versi yang kurang mampu tersedia di SharePoint dan sistem serupa. Ini memungkinkan anggota tim yang kompeten secara teknis namun berkode untuk merancang dan mengembangkan banyak alur kerja.

2) Ketika Anda perlu memantau kemajuan pekerjaan, lakukan peningkatan, bolak-balik antara proses yang dikendalikan komputer dan proses yang dikendalikan manusia.

Pemantauan dan referensi-diri adalah keunggulan dari mesin alur kerja modern.

Dari perspektif bisnis SDM, mesin alur kerja sangat penting.

1. Mereka menyediakan proses terstruktur, bahkan jika itu sama setiap saat.

2. Mereka memberikan transparansi

   • Siapa yang meminta perubahan,
   • Kapan diminta,
   • Siapa yang disetujui, dll.

   Transparansi ini membantu mendorong proses dan mempromosikan kepemilikan.

Dengan asumsi bentuk terintegrasi dan cerdas, mendukung logika bisnis, ia juga memiliki efek dramatis pada timeline, efisiensi pemrosesan, dan kualitas data. Keamanan juga menjadi pertimbangan dan mengandung informasi sensitif dalam sistem yang aman jauh lebih disukai daripada memiliki formulir kertas menunggu untuk ditandatangani. Ini juga jauh lebih mobile. Setelah implementasi baru-baru ini, seorang manajer mengatakan kepada saya bahwa itu menyelamatkannya dari banyak kerumitan mendapatkan hal-hal yang diposting kepadanya untuk ditandatangani saat ia sering bepergian.

Atas nama SDM: Alur kerja yang panjang !!!