Manajemen pengetahuan: dokumen apa yang dibutuhkan dan apa yang harus diperbaiki di dalamnya

Proses dokumentasi tumbuh secara evolusioner dari komentar rata-rata dalam kode ketika perusahaan tumbuh. Di suatu tempat di tengah jalan, orang biasanya muncul yang mengatakan bahwa mereka tahu bagaimana melakukannya dengan benar, dan bahwa "buku ini mengatakan bagaimana membuat dokumentasi", dan mereka membawa beberapa proses yang sulit ke perusahaan. Selanjutnya ada diskusi, perselisihan, tautan ke berbagai sumber dengan pendekatan yang saling bertentangan, dan sebagainya. Padahal, semua ini bukan kebetulan. Setiap kali kita menemukan saat-saat seperti itu, itu berarti ada perbedaan budaya. Tren berubah, dan setiap era memberikan buku pelajaran sendiri.

Di bawah potongan, bersama dengan Maxim Tsepkov kita akan memahami pelajaran apa yang dapat dipelajari dari berbagai pendekatan, bagaimana merancang dokumen proyek, apa yang akan dimasukkan ke dalam wiki, apa yang cocok untuk Google Documents, dan apa yang harus selalu ada di depan mata Anda. Bagaimanapun, mengapa kita membutuhkan semua dokumentasi ini. Pada saat yang sama, kami akan menyentuh pada topik manajemen pengetahuan.

Program Proyek Budaya

Sejarah industri TI dibagi menjadi beberapa tahap, zaman, yang masing-masing memiliki pendekatan sendiri untuk manajemen proyek: ide-idenya sendiri tentang kesuksesan, kriteria kualitas, organisasi kerja. Anthony Lauder pada 2008 menulis buku "Budaya proyek perangkat lunak" (tautan ke terjemahan asli , dan ulasan Stas Fomin ), di mana ia mengidentifikasi empat periode:

• ilmiah;
• pabrik;
• desain;
• budaya pelayanan.

Masing-masing dari mereka memengaruhi pendekatan manajemen proyek perangkat lunak. Dan tidak ada yang memikirkan konsistensi satu sama lain.



Tentang pembicara: Maxim Tsepkov, arsitek dan analis bisnis TI, navigator, dan pakar dalam dunia Agile, organisasi pirus, dan dinamika Spiral.

Saya menggunakan periodisasi yang sedikit berbeda, diperpanjang hingga saat ini. Dalam skema yang saya usulkan, hal utama yang telah berubah adalah ruang lingkup proyek. Di era R&D, penting bahwa sistem TI bekerja, di era RUP - bahwa itu dilakukan tepat waktu, di era Agile - bahwa ia melakukan apa yang dibutuhkan pelanggan, dan bukan hanya berfungsi, karena ternyata mereka sering melakukan hal yang salah.

Di zaman modern, proyek TI harus memberikan solusi untuk masalah bisnis dan memberikan kepuasan kepada para pemangku kepentingan. Tidak masalah skema pembagian budaya mana yang benar, skema mana pun dapat digunakan, karena perbedaannya hanya pada detailnya.


Tetapi penting untuk dipahami bahwa sebagian besar buku teks dokumentasi ditulis pada era RUP, di mana organisasi proses ditujukan untuk memenuhi anggaran dan tenggat waktu. Ini tidak berhasil, tetapi buku teks tetap, dan mereka tidak menulis buku teks baru .

Agile pada awal pengembangannya mengayunkan pendulum ke arah yang berlawanan, mengumumkan bahwa perangkat lunak yang bekerja jauh lebih penting daripada dokumen. Dan kemudian ada format pribadi: kisah pengguna, kasus penggunaan, praktik pribadi, pemetaan cerita, dll., Yang tercermin dalam dokumen. Tetapi mereka tidak menulis buku teks yang komprehensif tentang hal ini, karena mereka mengerti bahwa buku teks tidak berfungsi.

Sekarang kami menyadari bahwa proyeknya berbeda dan jelas tidak ada resep universal - kami perlu melakukan apa yang sesuai. Tetapi pada saat yang sama, seseorang tidak harus menciptakan dari awal, kita perlu menggunakan template dan sampel dengan cara yang sama seperti yang terjadi, misalnya, dalam desain antarmuka. Antarmuka berbeda, terutama pada perangkat seluler dengan layar kecil, Anda perlu menempatkan apa yang sekarang penting untuk tugas tersebut, tidak ada hal-hal universal yang ada. Tetapi ada panduan gaya yang memberikan pembelajaran intuitif, pola dan praktik.

Saat mengembangkan panduan gaya, mereka fokus pada UX. Dokumentasinya sama - pada panduan gaya dokumen proyek.

Saya berharap bahwa laporan ini akan memberikan prinsip dan konsep, berdasarkan di mana Anda dapat memperbaiki situasi dan menyelesaikan masalah dengan dokumen dalam proyek Anda.

Dokumen - untuk komunikasi

Gagasan utama, dari mana saya melanjutkan, adalah bahwa dokumen tidak berharga sendiri, tetapi menyediakan komunikasi. Sama seperti antarmuka itu sendiri tidak masalah, mereka menyediakan pengguna dengan fungsi yang tersembunyi di sisi server.

Bentuk dokumen, serta antarmuka, dikembangkan dari tujuan komunikasi.

Penting di sini bahwa dalam kasus dokumen jangka panjang, komunikasi didistribusikan dari waktu ke waktu. Hari ini Anda menulis surat untuk diri sendiri di masa depan, ketika akan perlu untuk membuat kembali perubahan pada fitur yang Anda lakukan sekarang. Kembali padanya setelah satu setengah tahun, ingat, cari tahu. Entah itu bisa menjadi pengembang atau pengguna yang sama sekali berbeda yang mengoperasikan sistem Anda.

Dan jika dokumen itu diperlukan untuk komunikasi, maka harus ditargetkan . Dengan itu, kami berkomunikasi dengan orang-orang tertentu, dan tidak mengirim ke seluruh dunia. Oleh karena itu, kami membagi dokumen dengan tujuan dan penerima:

• untuk pengambilan keputusan;
• komunikasi saat ini;
• pelestarian pengetahuan dari waktu ke waktu ("saya dalam enam bulan");
• transfer pengetahuan kepada orang lain;
• bantuan dalam pekerjaan saat ini, dll.

Setiap tujuan memiliki tipe deskripsi sendiri, - sudut pandang - metode deskripsinya sendiri .

Kriteria Kualitas Dokumen

Kriteria kualitas adalah bagaimana dokumen mendukung komunikasi yang dibuatnya. Kejelasan dokumen untuk semua pihak dalam komunikasi adalah penting , yang membatasi kompleksitas notasi. Ketika kami menyajikan diagram kelas, proses bisnis, status dokumen untuk pelanggan, kami tidak boleh lupa siapa yang akan membaca dokumen.

Diagram kelas di UML adalah konstruk notasi yang sangat rumit, yang dalam bentuk sederhana, ketika hanya kelas dan hubungan yang digambar, hampir intuitif. Tapi kemudian, ketika grafik dimuat dengan segala macam ikon tambahan, dengan cepat menjadi dimengerti hanya untuk penulis dan pengembang. Mereka berpikir bahwa mereka menyampaikan maknanya. Dan pelanggan berpikir bahwa pengembang di sini membuat beberapa catatan untuk mereka sendiri, yang tidak masuk akal, tetapi mereka tidak dapat menghapusnya. Pada saat yang sama, skema yang disederhanakan harus mempertahankan poin-poin penting . Perlu menggunakan segala sesuatu yang telah terakumulasi: hiperteks, tautan, teks, grafik, audio, video agar efektif.

Skema dan model jauh lebih efektif daripada teks , karena bahasa alami bersifat rancu. Pengalaman menunjukkan bahwa skema dan visualisasi jauh kurang terdistorsi dan disalahtafsirkan daripada teks. Tetapi skema harus disertai dengan deskripsi, yang, yang penting, tidak menggandakan konten, tetapi menjelaskan esensinya.

Penting untuk membuat kamus konsep , satu bahasa proyek, tetapi penting untuk membahas bukan istilah, tetapi konten. Tidak perlu berdebat bagaimana menggunakan kata untuk beberapa konsep. Kita perlu berdebat tentang konsep dan objek apa yang kita miliki dalam bidang subjek ini, dan menyoroti mereka. Pada topik pluralisme terminologis dan pendekatan untuk bekerja dengannya, ada fragmen-fragmen yang baik dalam perkuliahan tentang pemikiran rekayasa sistem oleh A. Levenchuk.

Poin penting berikutnya yang perlu diingat ketika merancang sistem dokumentasi: "mengapa" dan "mengapa" lebih penting daripada "apa" . Use case menggambarkan apa yang perlu dilakukan dalam sistem, dan dalam kisah pengguna ada bagian "mengapa": "Sebagai <> Saya ingin < -> untuk < > ". Selain itu, format kisah pengguna ini dapat dianggap sebagai templat, mis. semua bagian harus. Mereka tidak segera muncul dari pengalaman, tetapi sekarang kita tahu bahwa "mengapa" sangat penting. Tujuan dari kisah pengguna, tujuan dari segala persyaratan adalah komunikasi yang didistribusikan oleh pelanggan (pengguna) dengan pengembang dan analis sebagai perantara.

Dalam komunikasi yang didistribusikan waktu ini, sangat penting untuk menyampaikan artinya sehingga pengembang membuat keputusan tertentu. Selalu ada alternatif yang tidak terduga: dengan lokasi tombol pada formulir, dengan kode, oleh fleksibilitas, oleh generalisasi solusi. Jika keputusan itu penting, pengembang, tentu saja, akan menyela dan mengklarifikasi. Tetapi lebih baik dia pada saat itu dapat mengatur tugas bisnis sendiri dan membuat keputusan - gangguan dalam proses pengkodean mahal. Jawaban atas pertanyaan "mengapa" dalam dokumentasi sangat membantu, itu sebabnya ia muncul.

Pelajaran tentang "mengapa" dan "mengapa" harus diperhitungkan, bahkan jika Anda menggunakan format lain - untuk memperbaiki tujuan pengguna dan bisnis, mulai dari tujuan proyek. Dan kemudian isi tujuan proyek sering kali turun ke "bisnis karena alasan tertentu diperlukan."

Tidak perlu membabi buta melakukan hal-hal aneh yang bisnis tidak mengerti mengapa mereka inginkan. Biasanya ia memiliki alasan yang sepenuhnya rasional, setelah menggali yang ternyata hal-hal yang benar-benar berbeda perlu dilakukan.

Kami merancang dokumen proyek

Bagaimana mendesain? Seperti sistem lainnya. Hal mental utama yang perlu Anda ubah dalam diri Anda adalah Anda tidak perlu mengambil templat yang sudah jadi dan menyalinnya, tetapi Anda perlu merancang yang baru, bagaimana Anda melakukannya dengan antarmuka. Anda perlu mengambil dan mendesain antarmuka sistem Anda, dengan mengandalkan semua variasi.

Selanjutnya, kami menyoroti kasus-kasus komunikasi, menentukan dokumen yang akan mendukungnya. Jika komunikasi didistribusikan dari waktu ke waktu, maka Anda memerlukan orang yang bertanggung jawab untuk memelihara dokumen dan penerimaan dokumen yang kompeten. Karena, jika setelah 3 tahun kami menemukan bahwa deskripsi, katakanlah, tidak terlalu dapat dipahami, maka umpan balik ini akan sedikit terlambat, tidak akan ada orang yang mengirimkannya.

Lebih lanjut dalam proses penggunaan, kami mengevaluasi kualitas, dan memperbaikinya dengan cara yang sama seperti Kegunaan dan UX.


Untuk mendesain, Anda perlu sirkuit. Skema yang mudah digunakan adalah model-V , yang menunjukkan rantai proyek sebagai contoh abstraksi, dan kemudian pengiriman hasilnya.


Jika dalam model ini kita menempatkan artefak klasik interaksi antara pelanggan dan tim, maka akan ada: persyaratan, tugas pengembangan, kasus uji, PMI , versi. Artefak akan memiliki semacam tumpukan, bertanggung jawab.

Bukan fakta bahwa Anda membutuhkan dokumen-dokumen ini. Ini berlaku terutama untuk persyaratan dan tugas pengembangan.

Ada, misalnya, alternatif - Desain Berbasis Domain, yang menurutnya, alih-alih persyaratan dan tugas pengembangan, model sistem digunakan sebagai artefak kolektif. Model ini mencerminkan sistem, dan dilakukan oleh analis di satu sisi dan pengembang di sisi lain.


Ada banyak opsi dan praktik semacam itu. Semuanya terkait erat dengan proses pengembangan, karena dalam proses itulah komunikasi muncul. Lihatlah proses Anda dan buat artefak yang memadai untuk itu.


Model-V adalah warisan era R&D dan RUP. Sejak itu, budaya telah berubah, dan desain modern jauh lebih luas. Alih-alih konsep, hal-hal seperti kebutuhan pengguna dan peluang bisnis muncul. Di sebelah kanan, alih-alih pemeliharaan satu kali, ada pengiriman rilis berikutnya dan dukungan berkelanjutan dalam waktu.

Persyaratan

Biasanya ada artefak utama antara konsep dan awal proyek - konsep atau Visi , yang menangkap posisi awal proyek. Kami akan berkorelasi dengan konsep seiring proyek berkembang, tetapi yang paling penting, adalah atas dasar bahwa keputusan dibuat di awal apakah akan mengambil proyek atau tidak.

Seberapa banyak konsep atau visi harus dikerjakan secara terperinci ditentukan secara fungsional: dokumen harus dibuat sesingkat mungkin, karena cepat, tetapi agar para pemangku kepentingan membuat keputusan tentang dimulainya proyek. Biasanya, konsep tersebut harus mencerminkan:

• ide proyek - peluang untuk bisnis: apa, untuk siapa dan bagaimana melakukannya;
• kelayakan dan kelayakan ide;
• minat dan harapan para pemangku kepentingan utama dari hasil proyek;
• desain produk dan tujuan penggunaan;
• penilaian sumber daya yang dibutuhkan untuk proyek.

Selanjutnya, minat dan harapan dapat berubah, dan jika ini terjadi, penting untuk memperbaikinya pada waktunya.


Dalam proses mengerjakan persyaratan, hal seperti batas eksternal proyek itu penting. Dengan perubahan budaya, ide tentangnya berubah dari fitur sebagai bagian dari desain sistem (di era R&D) menjadi fitur sebagai fungsi dari sistem yang melakukan sesuatu di dalam dirinya, dan sekarang fitur adalah nilai bagi pengguna. Ini adalah tingkat artefak yang berbeda, spesialisasi yang berbeda bertanggung jawab untuk mereka: arsitek, analis sistem, analis bisnis. Tapi ini adalah pendekatan fungsional ke sistem.

Jika kita berbicara tentang kepuasan pengguna, maka sederet spesialisasi juga muncul di sana: seorang desainer UI yang bertanggung jawab atas kepuasan pengguna dengan penampilan, Kegunaan - tentang penggunaan dan spesialis UX yang bekerja pada kemampuan antarmuka yang intuitif. Perbatasan ini juga bergeser. Dalam proyek spesifik Anda, ini bisa berbeda, karena pengembangan perusahaan adalah satu hal, yang di dalamnya ada sistem pelatihan, dan pengguna tidak akan pergi ke mana pun, seperti akuntan 1C, karena ini adalah tempat kerjanya. Dan masalah lain, misalnya, pengembangan ponsel. Jika pergantian staf toko sedemikian rupa sehingga penjual atau penjaga toko bekerja rata-rata selama 3-6 bulan, maka pertanyaan tentang mengembangkan aplikasi seluler untuk bekerja dalam 2 hari, dan bukan 2 minggu pelatihan, relevan.


Mempertahankan persyaratan harus konsisten dengan pendekatan pengujian dan sebaliknya. Jika Anda memiliki persyaratan klasik tentang Persyaratan dan Arsitektur, maka Desain Didorong Uji adalah mungkin, dan Desain Berbasis Perilaku tidak mungkin. Karena BDD dirancang untuk memastikan bahwa Anda merumuskan skenario untuk pengguna, yaitu ke tingkat abstraksi yang lebih tinggi. Jika tidak ada skenario dalam persyaratan, maka tidak ada tempat untuk mengambilnya. Hubungan seperti itu harus diperhitungkan, dan biaya pemeliharaan dan pengecekan kasus uji juga harus dikontrol .

Artefak Fokus Kustom

Kelas artefak terpisah yang dirancang untuk fokus individu sehari-hari. Ini, misalnya, sirkuit yang dicetak dan digantung di depan ruang pengembang . Salah satu pelajaran Agile: papan tugas dan bagan Bakar , tergantung secara fisik di ruangan atau dikonfigurasikan dengan hot key dalam format elektronik, sangat membantu. Pandangan yang kacau dalam pikiran, secara tidak sengaja melekat, dan informasinya terus diperbarui. Begitu pula dengan skema arsitektur, prinsip penting.

Benar, ternyata jika Anda menggantungkan semua yang direkomendasikan di dinding, mereka akan menjadi sangat terpaku sehingga makna fokus pada dokumen sebelum mata Anda hilang, dalam massa mereka dianggap sebagai wallpaper. Dalam hal ini, pertanyaan "apa yang akan menggantung di dinding, artefak apa yang akan selalu ada di depan mata Anda?" Juga merupakan masalah desain yang perlu ditangani. Jelas, apa yang penting harus digantung.

Diagram ER, diagram aplikasi yang berlapis atau komponen utama ada dalam dokumentasi. Tetapi berbaring di dokumentasi atau tergantung di dinding sepanjang waktu adalah perbedaan besar. Ketika pengembang berpikir: "Tapi jangan menggali lubang di API di atas model berlapis secara miring?", Karena itu benar-benar akan mengurangi waktu pengembangan fitur tertentu (tetapi kemudian datang dengan iringan), dan sementara itu skema menggantung di depan mata Anda, maka kemungkinan besar dia akan melihat bahwa itu akan menjadi lubang. Jika diagram ada di suatu tempat dalam dokumen, maka Anda dapat melupakannya untuk sementara, dan dengan cepat menulis kode yang melanggar arsitektur.

Pengetahuan Gerak Proyek

Dalam proses Scrum ada poin-poin khusus untuk menghasilkan pengetahuan tentang pergerakan proyek:

• Demo - presentasi keadaan proyek kepada mereka yang menggunakan hasil pekerjaan Anda, dan orang lain yang tertarik.
• Retro adalah penilaian diri: apakah kita bekerja dengan benar dan apa yang bisa diperbaiki.
• Pertemuan harian - sinkronisasi gagasan tim tentang pergerakan proyek.
• Perencanaan - sinkronisasi niat.

Adalah penting bahwa pertemuan komunikasi ini ditempatkan dan difokuskan masing-masing pada tujuannya sendiri. Selain itu, format dikembangkan untuk mereka. Ada banyak buku tentang bagaimana melakukan retrospektif, dan artefak apa yang harus mereka sertai. Selain itu, beberapa artefak, seperti dengan kode, bersifat end-to-end, karena tugas yang perlu direncanakan bersama-sama berasal dari retro. Dengan demikian, retrospektif tugas menambah backlog, tetapi ditandai, misalnya, dengan warna. Kami bekerja dengan satu atau yang lain - ini normal.

Deskripsi jangka panjang

Saat membuat deskripsi jangka panjang, pertanyaan utama adalah menentukan kasus mana yang didukung deskripsi . Opsi bisa sangat berbeda:

• Ajari pengguna baru untuk bekerja dengan sistem.
• Berikan informasi referensi tentang fungsi langka dari sistem.
• Memperkenalkan desain konseptual sistem ke pengembang baru.
• Untuk membantu mengingat fragmen perangkat sistem kepada penulis untuk perbaikan.
• Jelaskan sistem modul perangkat untuk pengembangan oleh pengembang baru.
• Berikan informasi tentang perangkat sistem kepada teknisi pendukung.

Dalam hal ini, pertama-tama Anda merumuskan tugas apa yang perlu Anda dukung, kemudian Anda membuat dokumen dengan tingkat perincian yang diperlukan dan seterusnya.

Deskripsi universal terperinci, mahal, tidak relevan dan juga tidak perlu, karena Anda tidak dapat menemukan informasi yang diperlukan di dalamnya karena detailnya.

Hal ini diperlukan untuk memperbaiki tujuan , mengevaluasi kepatuhan, mengingat: semakin detail dokumen, semakin mahal.

Pertanyaan yang khas: haruskah risalah rapat kecil reguler dengan pelanggan menjadi jelas dan mengingatkan pada isi diskusi hanya kepada mereka yang berpartisipasi dalam rapat, atau sedemikian rupa sehingga mereka dapat dikirim ke semua orang yang tidak berpartisipasi dalam pertemuan, dan mereka juga bisa mengetahuinya? Ini adalah masalah penting.

Jelas, protokol yang lebih rinci jauh lebih mahal . Ini harus dikelola, dan pengorbanan mungkin berlaku. Misalnya, masukkan ringkasan singkat ke dalam protokol, dan lihat video atau audio yang direkam untuk detailnya. Ini bisa sangat berguna, banyak yang kembali ke rekaman video.

Pada saat yang sama, kembali ke "mengapa dan untuk apa", kita tidak lupa untuk memperbaiki logika keputusan dalam ringkasan, dan bukan hanya "apa yang harus dilakukan." Secara singkat, tetapi ini penting.


Dengan dokumen yang diperlukan secara normatif sesuai dengan GOST, Anda perlu memahami apakah dokumen tersebut diperlukan untuk penyerahan proyek atau untuk hal lain. Sebagai aturan, dokumen normatif memastikan komunikasi pelanggan dengan inspekturnya dan harus ditulis dalam volume yang diperlukan, dan dengan mempertimbangkan penggunaan oleh pelanggan. Terkadang ini hanya dokumen tulis. Sebagai contoh, kami memiliki pelanggan untuk siapa dokumentasi dan dokumentasi kerja untuk inspektur diproduksi secara terpisah. Tetapi ada orang yang ingin dokumennya diperiksa agar berfungsi, dasar. Bergantung pada ini, proses dokumentasi berbeda, tetapi begitu kami memahami tujuannya, semuanya baik-baik saja.

Komunikasi menyampaikan makna

Mari kita sedikit menyimpang dan membahas bahwa komunikasi menyampaikan makna.


Semuanya dimulai dengan asumsi era RUP, yang menelurkan Pendekatan Berorientasi Objek (OOP). Jika kita menguraikan dunia menjadi objek dan koneksi , kita mendapatkan gambaran dunia yang ditafsirkan secara jelas.


Pelanggan dapat melihat dunia sebagai kumpulan agen yang berinteraksi dalam model Haskell yang bertukar pesan. Agennya sama dan kata-katanya jelas, tetapi gambarnya sangat berbeda. Skema, tidak seperti teks, mencerminkan perbedaan ini. Karena itu, kami menggunakan skema.

Cara berpikir yang berbeda adalah norma . Model hierarkis, taksonomi berawal dari perkembangan ilmiah dunia, di mana semuanya direduksi menjadi bentuk yang ketat dan "diletakkan di rak-rak." Sekarang, dengan perkembangan Internet, pemikiran dunia populer sebagai cloud tag dengan koneksi, bahkan ada kata khusus - “peopleonomy” . Pemikiran seperti itu efisien dan dapat dioperasikan. Pemasaran, media dibangun di atas ini. Dan dunia insinyur TI, yang lebih dekat dengan gambaran ilmiah dunia, semakin dihadapkan dengan ini.


Dalam hal ini, Anda perlu tahu dan memperbaiki perbedaan dalam berpikir . Jika tidak, Anda akan membuat sistem persegi, dan pelanggan akan menyiapkan lubang bundar untuk itu. Maka proses penggabungan akan dimulai dan Anda harus puas dengan buaya berbentuk tetesan air mata, karena salah satu sudut pola persegi Anda tidak dapat ditebang - terbuat dari logam arsitektur yang solid.

Apa yang harus dilakukan bisa dimengerti. Gambarkan diagram . Kita harus mengambil sumber yang sudah jadi dan terkenal, misalnya, UML. Tetapi perlu diingat bahwa notasi formal tidak dipahami dengan baik oleh semua orang, dan banyak yang menganggap skema informal yang samar hanya sebagai gambar.

Sumber skema ortogonal di luar TI adalah metodologi SMD (lihat laporan "Komunikasi dengan struktur pemikiran yang berbeda - taksonomi versus rakyat" ).

Prinsip manajemen dokumen

1. Dokumen tidak memiliki penulis.

Dia hidup lebih lama dari penulis pertama, jadi kami bekerja secara kolektif, dan tidak meneruskan surat , kami menggunakan sistem wiki. Anda juga dapat Google Documents, tetapi ada dokumen terpisah, yang tidak selalu nyaman. Untuk produksi yang berumur pendek, Google Documents hebat.

Konsekuensi penting mengikuti dari prinsip bahwa sebuah dokumen tidak memiliki penulis dan pengalaman dalam sistem-wiki: Saya melihat apa yang harus diperbaiki, lakukan segera, koordinasi hanya diperlukan melalui pertentangan.

Tampaknya semua orang mengerti bahwa tidak ada penulis, tetapi hanya sedikit yang memperbaiki dokumen orang lain. Ejaan masih baik-baik saja, tetapi jika ada sesuatu yang lebih rumit, maka penulis perlu pergi dan menulis. Tidak, Anda harus mengambil dan memperbaikinya . Semua sistem wiki memiliki pemberitahuan. Jika penulis tertarik pada dokumen tersebut, ia akan melihat pemberitahuan, lihat sejarah perubahan, jelaskan jika Anda salah. Tetapi dalam kebanyakan kasus, ia tidak akan memperhatikan, atau memutuskan apa yang diperbaiki secara normal. Keberhasilan Wikipedia hanyalah itu.

2. Dokumen dibuat secara bertahap.

Sebuah dokumen besar menjadi usang sebelum ditulis. Cukuplah untuk meringkas konsep, dan merinci seperlunya. Kami melakukan bagian dari dokumen yang berkaitan dengan tugas saat ini.

Format yang dibawa Agile: kisah pengguna, kasus penggunaan, pemetaan cerita, tidak seperti produksi monolitik sebelumnya, tidak segera muncul. Mereka fokus tepatnya pada pembuatan dokumen secara bertahap, penjabaran tambahan. Mereka tidak ada di mana-mana, tetapi segera setelah kami memutuskan untuk menyerahkan dan merinci dokumen secara bertahap, ini memberlakukan batasan yang sama pada struktur artefak seperti pada kode. Segera setelah kita menulis sistem secara bertahap, dan tidak sepenuhnya men-debug-nya, kita harus mengatur kodenya: arsitektur komponen, arsitektur layanan mikro - ada banyak opsi, tetapi bukan monolit.

3. Konten lebih penting daripada bentuk.

Persyaratan dokumen formal tidak berfungsi. Mereka dapat diambil untuk menghemat waktu di awal, tetapi ini bukan kriteria kualitas. Kriteria untuk kesesuaian dokumen penggunaan pemangku kepentingan bekerja: daftar periksa dan evaluasi ahli.

Pada titik ini, peraturan tidak berfungsi - ini adalah pelajaran dalam pengembangan industri TI, dan bukan industri TI. Siapa pun dapat mengedit dalam sistem Wiki, tidak ada proses persetujuan yang panjang, dll. Sama dengan komit kebijakan di banyak proyek OpenSource. Tentu saja, ada yang menyetujui, dll., Tetapi itu adalah pengalaman terwujud yang harus digunakan.

4. Kami meninggalkan jejak.

Prinsip penting lainnya ini menyangkut risalah rapat, ringkasan pembicaraan. Artinya, kami berbicara langsung, mengobrol, dan menulis ringkasan 1-2 kalimat di Pelacak Tugas. , , -, , .

. , , , . . , , . - , . , .

— , , .. , - , -, , , , . : , .

:

• Archimate.
• Archimate.
• - , Domain Driven Design.
• OMG Essence.
• viewpoint' ISO 42010.

. , , .

, , . , , , , , , , , : , .

, Wiki — , , , , , .. , - . CUSTIS MediaWiki. , Jira Confluence, OpenSource http://4intra.net. , , wiki- , .

— . Slack, Task Tracker Google Docs, .

. , wiki. wiki git, - wiki- , .

— , .

, , .

, « » . , : « , ?» , . , , « » , British Petroleum. , , , .


. . , .

, , 5–7 , . .

, , , C# , . .

— . — , wiki — , . . , , , . , , .

— , . BBC , , , . , , . , , .

IBM: — .

IBM : , - , . , . IBM , . , , , , , , , « , , ». . — , , .

• .
• .
• , .
• , .
• — .

mtsepkov.org (, , wiki) , agile , .

— . , : , , , , Knowledge Conf .

25 TeamLead Conf . , .