Gestion des connaissances: quels documents sont nécessaires et que corriger en eux

Le processus de documentation découle évolutivement des commentaires moyens dans le code au fur et à mesure de la croissance d'une entreprise. Quelque part au milieu de la route, des gens apparaissent généralement qui disent qu'ils savent comment le faire correctement et que «ce livre dit comment faire de la documentation», et ils apportent un processus difficile à l'entreprise. En outre, il y a des discussions, des différends, des liens vers différentes sources avec des approches conflictuelles, etc. En fait, tout cela n'est pas accidentel. Chaque fois que nous rencontrons de tels moments, cela signifie qu'il y a des différences culturelles. Les tendances changent et chaque époque donne ses propres manuels.

Sous la coupe, avec Maxim Tsepkov, nous comprendrons quelles leçons peuvent être tirées de différentes approches, comment concevoir des documents de projet, quoi mettre dans un wiki, à quoi Google Docs convient et ce qui doit toujours être sous vos yeux. Quoi qu'il en soit, pourquoi avons-nous besoin de toute cette documentation. Dans le même temps, nous aborderons le sujet de la gestion des connaissances.

Programmes de projets culturels

L'histoire de l'industrie informatique est divisée en étapes-ères, chacune ayant sa propre approche de la gestion de projet: ses propres idées sur le succès, les critères de qualité, l'organisation du travail. Anthony Lauder a écrit en 2008 le livre "Culture of software projects" (liens vers l' original , traduction et critique de Stas Fomin ), dans lequel il a identifié quatre périodes:

• scientifique;
• usine;
• conception;
• culture de service.

Chacun d'eux a influencé les approches de la gestion des projets logiciels. Et personne n'a pensé à la cohérence entre eux.



À propos du conférencier: Maxim Tsepkov Architecte informatique et analyste d'affaires, navigateur et expert dans le monde des organisations Agile, turquoise et Dynamique spirale.

J'utilise une périodisation légèrement différente, étendue à ce jour. Dans le schéma que je propose, la principale chose qui a changé est la portée du projet. À l'ère de la R&D, il était important que le système informatique fonctionne, à l'ère RUP - qu'il soit fait à temps, à l'ère Agile - qu'il fasse ce dont le client a besoin, et pas seulement fonctionne, car il s'est avéré qu'ils faisaient souvent la mauvaise chose.

Dans les temps modernes, un projet informatique doit apporter une solution aux problèmes de l'entreprise et apporter satisfaction aux parties prenantes. Peu importe lequel des schémas de division culturelle est réellement correct, n'importe lequel peut être utilisé, car les différences ne concernent que les détails.


Mais il est important de comprendre que la plupart des manuels de documentation ont été écrits à l'ère RUP, dans laquelle l'organisation du processus visait à respecter le budget et les délais. Cela n'a pas fonctionné, mais les manuels sont restés et ils n'ont pas écrit de nouveaux manuels .

Agile au tout début de son développement a fait basculer le pendule dans la direction opposée, annonçant que le logiciel de travail est beaucoup plus important que les documents. Et puis il y avait des formats privés: user story, cas d'utilisation, pratiques privées, story-mapping, etc., qui étaient reflétés dans les documents. Mais ils n'ont pas écrit de manuels complets sur ce sujet, car ils ont compris que les manuels ne fonctionnent pas.

Maintenant, nous avons réalisé que les projets sont différents et qu'il n'y a certainement pas de recettes universelles - nous devons faire ce qui est approprié. Mais vous n'avez pas besoin d'inventer à partir de zéro, vous devez utiliser des modèles et des échantillons de la même manière que cela se produit, par exemple, dans la conception d'interfaces. Les interfaces sont différentes, en particulier sur les appareils mobiles avec un petit écran, vous devez placer ce qui est maintenant important pour la tâche, il n'existe pas de choses universelles. Mais il existe un guide de style qui fournit un apprentissage, des modèles et des pratiques intuitifs.

Lors de l'élaboration d'un guide de style, ils se concentrent sur l'expérience utilisateur. La documentation est la même - sur le guide de style Doc du projet.

J'espère que le rapport donnera des principes et des concepts sur la base desquels vous pourrez améliorer la situation et résoudre les problèmes de documents dans votre projet.

Documents - pour communication

L'idée principale, à partir de laquelle je procède, est que les documents n'ont pas de valeur personnelle, mais fournissent une communication. Tout comme les interfaces elles-mêmes n'ont pas d'importance, elles fournissent à l'utilisateur la fonctionnalité cachée côté serveur.

La forme des documents, ainsi que des interfaces, est développée à partir des objectifs de communication.

Il est important ici que dans le cas de documents à long terme, la communication soit répartie dans le temps. Aujourd'hui, vous vous écrivez une lettre à l'avenir, quand il sera nécessaire d'apporter à nouveau des modifications à la fonctionnalité que vous faites maintenant. Revenant à elle après un an et demi, rappelez-vous, comprenez-le. Il peut s'agir d'un développeur ou d'un utilisateur complètement différent exploitant votre système.

Et si le document est nécessaire à la communication, il doit être ciblé . Avec lui, nous communiquons avec des personnes spécifiques, et non pas envoyons au monde entier. Par conséquent, nous divisons les documents par objet et par destinataire:

• pour la prise de décision;
• communication actuelle;
• préservation des connaissances dans le temps ("pour moi en six mois");
• transfert de connaissances à d'autres personnes;
• aide dans le travail en cours, etc.

Chaque destination a son propre type de description, - point de vue - sa propre méthode de description .

Critère de qualité du document

Le critère de qualité sera la manière dont le document prend en charge la communication pour laquelle il a été créé. La clarté du document pour toutes les parties à la communication est importante , ce qui limite la complexité des notations. Lorsque nous présentons des diagrammes de classes, des processus commerciaux, l'état du document pour le client, nous ne devons pas oublier qui lira les documents.

Les diagrammes de classes en UML sont une construction de notation très compliquée qui, sous une forme simple, lorsque seules les classes et les relations sont dessinées, est presque intuitive. Mais ensuite, lorsque le graphique est chargé de toutes sortes d'icônes supplémentaires, il ne devient rapidement compréhensible que pour l'auteur et les développeurs. Ils pensent qu'ils ont transmis les significations. Et le client pense que les développeurs ici ont pris des notes pour eux-mêmes, ce qui n'a aucun sens, mais ils ne peuvent pas les effacer. Dans le même temps, les régimes simplifiés devraient préserver les points clés . Il vaut la peine d'utiliser tout ce qui a été accumulé: hypertexte, liens, textes, graphiques, audio, vidéo pour être efficace.

Les schémas et modèles sont beaucoup plus efficaces que le texte , car le langage naturel est ambigu. L'expérience suggère que les schémas et les visualisations sont beaucoup moins déformés et mal interprétés que le texte. Mais les schémas doivent être accompagnés de descriptions qui, surtout, ne font pas double emploi avec le contenu, mais expliquent l'essence.

Il est nécessaire de créer un dictionnaire de concepts , un seul langage de projet, mais il est important de discuter non pas des termes, mais du contenu. Pas besoin de discuter comment utiliser le mot pour un concept. Nous devons discuter de quels concepts et objets nous avons dans ce domaine et les mettre en évidence. Sur le sujet du pluralisme terminologique et des approches pour travailler avec lui, il y a de bons fragments au cours des conférences sur la pensée de l'ingénierie des systèmes par A. Levenchuk.

Le prochain point important à retenir lors de la conception d'un système de documentation: «pourquoi» et «pourquoi» sont plus importants que «quoi» . Le cas d'utilisation décrit ce qui doit être fait dans le système, et dans la user story, il y a une partie «pourquoi»: «En tant que <> je veux < -> pour < > ». De plus, ce format de user story peut être considéré comme un modèle, c'est-à-dire toutes les pièces doivent être. Ils ne sont pas immédiatement sortis de l'expérience, mais nous savons maintenant que le «pourquoi» est très important. Le but de l'histoire de l'utilisateur, le but de toute exigence est la communication temporelle du client (utilisateur) avec le développeur et l'analyste en tant qu'intermédiaire.

Dans cette communication temporelle, il est très important de transmettre les significations afin que le développeur prenne des décisions spécifiques. Il existe toujours des alternatives imprévues: par l'emplacement des boutons sur le formulaire, par le code, par la flexibilité, par la généralité de la solution. Si la décision est critique, le développeur, bien sûr, interrompra et clarifiera. Mais il vaut mieux qu'à ce moment-là, il puisse définir lui-même la tâche commerciale et prendre une décision - l'interruption du processus de codage coûte cher. La réponse à la question «pourquoi» dans la documentation aide beaucoup, c'est pourquoi elle est apparue.

La leçon sur «pourquoi» et «pourquoi» doit être prise en compte, même si vous utilisez d'autres formats - pour fixer les objectifs des utilisateurs et des entreprises, à partir des objectifs du projet. Et puis le contenu des objectifs du projet se résume souvent à «des affaires pour une raison quelconque sont nécessaires».

Pas besoin de faire aveuglément des choses étranges que l'entreprise ne comprend pas pourquoi elles voulaient. Habituellement, il a des motifs complètement rationnels, après avoir creusé, il s'avère que des choses complètement différentes doivent être faites.

Nous concevons des documents de projet

Comment concevoir? Comme tout autre système. La principale chose mentale que vous devez changer en vous-même est que vous n'avez pas besoin de prendre le modèle fini et de le copier, mais vous devez en concevoir un nouveau, comment vous le faites avec les interfaces. Il est nécessaire de prendre et de concevoir les interfaces de votre système, en s'appuyant sur toute la variété.

Ensuite, nous mettons en évidence les cas de communications, déterminons les documents qui les soutiendront. Si la communication est répartie dans le temps, vous avez besoin d'une personne responsable de la maintenance des documents et de leur acceptation compétente. Parce que si au bout de 3 ans on constate que les descriptions, disons, ne sont pas très intelligibles, alors ce feedback sera un peu tardif, il n'y aura personne pour le transmettre.

Plus loin dans le processus d'utilisation, nous évaluons la qualité et l'améliorons de la même manière que l'utilisabilité et l'UX.


Pour concevoir, vous avez besoin de circuits. Un schéma pratique est le modèle V , qui montre la chaîne de projet comme exemple d'abstraction, puis la livraison du résultat.


Si dans ce modèle nous plaçons les artefacts classiques d'interaction entre le client et l'équipe, alors il y aura: exigences, tâche de développement, cas de test, PMI , versions. Les artefacts auront une sorte d'arriéré responsable.

Pas le fait que vous ayez besoin de ces documents. Cela s'applique particulièrement aux exigences et aux tâches de développement.

Il existe, par exemple, une alternative - la conception pilotée par domaine, selon laquelle, au lieu d'exigences et de tâches de développement, un modèle de système est utilisé comme un artefact collectif. Le modèle reflète le système, et il est mené par des analystes d'une part et des développeurs d'autre part.


Il existe de nombreuses options et pratiques de ce type. Tous sont étroitement liés au processus de développement, car c'est dans le processus que les communications naissent. Examinez votre processus et créez des artefacts adéquats.


Le modèle V est un héritage des époques R&D et RUP. Depuis lors, les cultures ont changé et le design moderne est beaucoup plus large. Au lieu du concept, des choses comme les besoins des utilisateurs et les opportunités commerciales sont apparues. À droite, au lieu d'une maintenance unique, il y avait une livraison de la prochaine version et un support continu à temps.

Prérequis

Il y a généralement un artefact clé entre le concept et le début du projet - le concept ou la vision , qui capture la position de départ du projet. Nous établirons une corrélation avec le concept au fur et à mesure que le projet se développe, mais surtout, c'est sur la base de cette décision que l'on décide au tout début de prendre ou non le projet en charge.

La manière dont le concept ou la vision doit être élaboré en détail est déterminée fonctionnellement: le document doit être aussi court que possible, car rapidement, mais pour que les parties prenantes prennent une décision quant au début du projet. En règle générale, le concept devrait refléter:

• idée de projet - une opportunité pour les entreprises: quoi, pour qui et comment faire;
• la faisabilité et la faisabilité de l'idée;
• les intérêts et attentes des principales parties prenantes par rapport au résultat du projet;
• conception du produit et utilisation prévue;
• évaluation des ressources nécessaires au projet.

De plus, les intérêts et les attentes peuvent changer, et si cela se produit, il est important de les corriger à temps.


Dans le processus de travail sur les exigences, une chose telle que la limite externe du projet est importante. Avec le changement de culture, les idées à ce sujet sont passées de fonctionnalités faisant partie de la conception du système (à l'ère de la R&D) à des fonctionnalités en fonction d'un système qui fait quelque chose en lui-même, et maintenant la fonctionnalité est une valeur pour les utilisateurs. Il s'agit de différents niveaux d'artefacts; différentes spécialisations en sont responsables: architecte, analyste de systèmes, analyste commercial. Mais c'est une approche fonctionnelle du système.

Si nous parlons de la satisfaction des utilisateurs, une gamme de spécialisations est également apparue: un concepteur d'interface utilisateur qui est responsable de la satisfaction des utilisateurs avec l'apparence, la convivialité - à propos de l'utilisation et un spécialiste UX qui travaille sur la maîtrise intuitive de l'interface. Cette frontière se déplace également. Dans votre projet spécifique, cela peut être différent, car le développement d'entreprise est une chose, pour laquelle il existe un système de formation, et l'utilisateur n'ira nulle part comme un comptable 1C, car c'est son lieu de travail. Et tout autre chose, par exemple, le développement mobile. Si le roulement du personnel du magasin est tel que le vendeur ou le commerçant travaille en moyenne pendant 3 à 6 mois, alors la question de développer une application mobile pour travailler en 2 jours, et non 2 semaines de formation, est pertinente.


Le maintien des exigences doit être cohérent avec l'approche de test et vice versa. Si vous avez les exigences classiques d'exigences et d'architecture, alors la conception pilotée par les tests est possible et la conception pilotée par les comportements est peu probable. Parce que BDD est conçu pour garantir que vous formulez un scénario pour les utilisateurs, c'est-à-dire à un niveau d'abstraction plus élevé. S'il n'y a pas de scénario dans les exigences, il n'y a aucun endroit où le prendre. Ces relations doivent être prises en compte et le coût de la maintenance et de la vérification des cas de test doit également être contrôlé .

Objets de mise au point personnalisés

Une classe distincte d'artefacts conçus pour une concentration individuelle quotidienne. Ce sont, par exemple, ces circuits qui sont imprimés et suspendus devant la salle des développeurs . Une des leçons d'Agile: un tableau des tâches et un tableau de gravure , suspendus physiquement dans une pièce ou configurés avec des touches de raccourci au format électronique, sont très utiles. Un regard distrait dans la pensée, s'accroche accidentellement, et l'information est constamment rafraîchie. De même, avec des schémas architecturaux, des principes importants.

Certes, il s'avère que si vous accrochez tout ce qui est recommandé aux murs, ils deviendront tellement accrochés que le sens de se concentrer sur le document avant que vos yeux se perdent, dans la masse, ils sont perçus comme du papier peint. En ce sens, la question "quoi accrocher aux murs, quels objets seront toujours devant vos yeux?" Est également un problème de conception qui doit être résolu. De toute évidence, exactement ce qui est important devrait se bloquer.

Les diagrammes ER, un diagramme en couches de l'application ou les principaux composants sont dans la documentation. Mais rester allongé dans la documentation ou accroché au mur tout le temps est une grande différence. Quand un développeur pense: "Mais ne creusez pas un trou dans l'API au-dessus du modèle en couches obliquement?", Parce que cela réduira vraiment le temps de développement d'une fonctionnalité spécifique (mais vient ensuite avec accompagnement), et en attendant, le schéma se bloque sous vos yeux, alors il verra très probablement qu'il verra que ce sera un trou. Si le diagramme se trouve quelque part dans le document, vous pouvez l'oublier temporairement et écrire rapidement du code qui viole l'architecture.

Connaissance du mouvement de projet

Dans le processus Scrum, il existe des points particuliers pour générer des connaissances sur le mouvement du projet:

• Démo - présentation de l'état du projet à ceux qui utilisent les résultats de votre travail et aux autres personnes intéressées.
• Le rétro est une auto-évaluation: si nous travaillons correctement et ce qui peut être amélioré.
• Réunion quotidienne - synchronisation des idées de l'équipe sur le mouvement du projet.
• Planification - synchronisation des intentions.

Il est important que ces réunions de communication soient espacées et centrées chacune sur son propre objectif. De plus, des formats sont développés pour eux. Il existe des livres entiers sur la façon de mener des rétrospectives et les artefacts qu'elles doivent accompagner. De plus, certains artefacts, comme avec le code, sont de bout en bout, car les tâches qui doivent être planifiées ensemble viennent du rétro. Par conséquent, les rétrospectives de la tâche s'ajoutent à l'arriéré, mais sont marquées, par exemple, de couleur. Nous travaillons avec l'un ou l'autre - c'est normal.

Descriptions à long terme

Lors de la création de descriptions à long terme, la question principale est de déterminer quels cas la description prendra en charge . Les options peuvent être complètement différentes:

• Apprenez à un nouvel utilisateur à travailler avec le système.
• Fournissez des informations de référence sur les fonctions rares du système.
• Présentez la conception conceptuelle du système à un nouveau développeur.
• Pour aider à rappeler le fragment de périphérique du système à l'auteur pour des améliorations.
• Décrire le système de modules de périphérique pour le développement par un nouveau développeur.
• Fournissez des informations sur le périphérique système à l'ingénieur de support.

En ce sens, vous formulez d'abord la tâche que vous devez prendre en charge, puis vous créez des documents avec le niveau de détail nécessaire, etc.

La description universelle est détaillée, coûteuse, non pertinente et également inutile, car vous ne pouvez pas y trouver les informations nécessaires en raison de ses détails.

Il est nécessaire de fixer le but , d'évaluer la conformité, de se souvenir: plus le document est détaillé, plus cher.

Une question typique: les procès-verbaux de petites réunions régulières avec le client devraient-ils être clairs et ne rappeler le contenu de la discussion qu'à ceux qui ont participé à la réunion, ou être tels qu'ils puissent être envoyés à tous ceux qui n'ont pas participé à la réunion, et ils pourraient également le comprendre? C'est un problème important.

De toute évidence, des protocoles plus détaillés sont beaucoup plus chers . Cela doit être géré et des compromis peuvent être applicables. Par exemple, entrez un bref résumé dans le protocole et reportez-vous à la vidéo ou à l'audio enregistré pour plus de détails. Cela peut vraiment être utile, beaucoup reviennent aux enregistrements vidéo.

En même temps, revenant au «pourquoi et pour quoi», nous n'oublions pas de fixer la logique des décisions dans le résumé, et pas seulement «quoi faire». Brièvement, mais c'est important.


Avec les documents normativement nécessaires conformément à GOST, vous devez comprendre s'ils sont nécessaires pour la livraison du projet ou pour autre chose. En règle générale, les documents normatifs assurent la communication du client avec ses inspecteurs et doivent être rédigés dans le volume dans lequel cela est nécessaire, et en tenant compte de l'utilisation par le client. Parfois, ce sont des documents en écriture seule. Par exemple, nous avons des clients pour lesquels la documentation de travail et la documentation pour les inspecteurs sont produites séparément. Mais il y a ceux qui veulent que les documents à examiner fonctionnent, de base. En fonction de cela, le processus de documentation est différent, mais dès que nous comprenons son objectif, tout va bien.

La communication véhicule des significations

Écartons-nous un peu et discutons que la communication donne du sens.


Tout commence avec l'hypothèse de l'ère RUP, qui a donné naissance à l'approche orientée objet (POO). Si nous décomposons le monde en objets et connexions , nous obtenons une image du monde interprétée sans ambiguïté.


Le client peut voir le monde comme une collection d'agents en interaction dans le modèle Haskell qui échangent des messages. Les agents sont les mêmes et les mots sont clairs, mais l'image est complètement différente. Le schéma, contrairement au texte, reflète cette différence. Par conséquent, nous utilisons le schéma.

Une autre façon de penser est la norme . Modèles hiérarchiques, les taxonomies sont passées du développement scientifique du monde, dans lequel tout est réduit à une forme stricte et «disposé sur les étagères». Maintenant, avec le développement d'Internet, la pensée du monde est populaire comme un nuage de tags avec des connexions, il y a même un mot spécial - "folksonomy" . Une telle réflexion est efficace et utilisable. Marketing, les médias sont construits sur ce point. Et le monde des ingénieurs informatiques, plus proches de l'image scientifique du monde, y est de plus en plus confronté.


En ce sens, vous devez connaître et corriger la différence de pensée . Sinon, vous ferez un système carré et le client lui préparera un trou rond. Ensuite, le processus de combinaison commencera et vous devrez vous contenter d'un crocodile en forme de larme, car un coin de votre motif carré ne peut pas être coupé - il est en métal architectural solide.

Que faire est compréhensible. Dessinez les diagrammes . Nous devons prendre des sources toutes faites et bien connues, par exemple UML. Mais gardez à l'esprit que les notations formelles ne sont pas bien comprises par tout le monde, et beaucoup perçoivent les schémas informels sommaires exclusivement comme des images.

La source orthogonale des schémas en dehors de l'informatique est la méthodologie SMD (voir le rapport «Communication avec une structure de pensée différente - taxonomie versus folksonomie» ).

Principes de gestion des documents

1. Le document n'a pas d'auteur.

Il vit plus longtemps que le premier auteur, nous travaillons donc collectivement, et ne transmettons pas en lettres , nous utilisons des systèmes wiki. Vous pouvez également Google Docs, mais il existe des documents distincts, ce qui n'est pas toujours pratique. Pour les productions de courte durée, Google Docs est génial.

Une conséquence importante découle du principe qu'un document n'a pas d'auteur et d'expérience dans les systèmes wiki: j'ai vu ce qu'il fallait améliorer, faites-le tout de suite, la coordination n'est nécessaire que par désaccord.

Il semble que tout le monde comprenne qu'il n'y a pas d'auteur, mais peu corrigent le document de quelqu'un d'autre. L'orthographe est toujours bonne, mais si quelque chose est plus compliqué, alors l'auteur doit aller écrire. Non, vous devez le prendre et le réparer . Tous les systèmes wiki ont des notifications. Si l'auteur s'intéresse au document, il verra un avis, examinera l'historique des changements, expliquera si vous vous trompez. Mais dans la plupart des cas, il ne le remarquera pas ou décidera ce qui est fixé normalement. Le succès de Wikipédia n'est que cela.

2. Le document est créé progressivement.

Un grand document devient obsolète avant d'être écrit. Il suffit de résumer les concepts et de les détailler si nécessaire. Nous faisons la partie du document qui se rapporte à la tâche actuelle.

Les formats qu'Agile a apportés: user story, use case, story mapping, contrairement aux précédentes productions monolithiques, n'apparaissent pas immédiatement. Ils se concentrent précisément sur la création incrémentale de documents, l'élaboration incrémentale. Ils ne sont pas partout, mais dès que nous décidons de soumettre et de détailler progressivement les documents, cela impose les mêmes restrictions sur la structure des artefacts que sur le code. Dès que nous écrivons le système de manière incrémentielle et que nous ne le déboguons pas complètement, nous devons organiser le code en conséquence: architecture des composants, architecture des microservices - il existe de nombreuses options, mais pas un monolithe.

3. Le contenu est plus important que la forme.

Les exigences relatives aux documents officiels ne fonctionnent pas. On peut les prendre pour gagner du temps au départ, mais ce n'est pas un critère de qualité. Les critères d'adéquation des documents d'utilisation des parties prenantes fonctionnent: listes de contrôle et évaluation par des experts.

À ce stade, la réglementation ne fonctionne pas - c'est une leçon sur le développement de l'industrie informatique et non de l'industrie informatique. Tout le monde peut éditer dans les systèmes Wiki, il n'y a pas de long processus d'approbation, etc. La même chose avec les politiques de validation dans de nombreux projets OpenSource. Bien sûr, il y a approuver, etc., mais c'est une expérience matérialisée qui doit être utilisée.

4. Nous laissons des traces.

Cet autre principe important concerne les procès-verbaux des réunions, les résumés des conversations. Autrement dit, nous avons parlé en direct, en discutant et en écrivant un résumé de 1-2 phrases dans Task Tracker. , , -, , .

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

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

:

• 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 . , .