Comme l'équipe, je suis sur les œuvres de formaliser et d'établir davantage de pratiques de développement, je trouve que la communication semble échouer aux points suivants:
Au cours d'une conversation informelle sur un projet, un moment d'étincelles cérébrales devient une nouvelle fonctionnalité / exigence. Ces "add-ons" semblent échouer à travers les fissures ou le détail deviennent flous après un certain temps est passé.
lors des réunions où des objectifs ou des tâches ne sont pas clairement délégués, les membres impliqués dans la réunion ont des comptes différents de ce qui a été réellement discuté.
En tant qu'équipe, nous sommes constamment mis au défi (plus maintenant que nous aspirons réellement à les écrire) pour générer des spécifications de qualité et des documents techniques qui détaillent exactement quelles caractéristiques doivent être dans des projets.
Merci pour votre aide!
9 Réponses :
Pourquoi pas seulement avoir des notes conservées lors de ces réunions, dans un wiki, de sorte que d'autres puissent la voir, et les gens peuvent la modifier pour clarifier les ambiguïtés, puis vous rappelez ce qui a été convenu.
Vous pouvez ensuite prendre les fonctionnalités et les mettre dans votre logiciel de suivi de bogues, de sorte que vous ne perdez pas la trace du fait qu'il existe des fonctionnalités qui attendent d'être implémentées.
C'était ma première pensée, mais en général, personne ne veut prendre le temps d'écrire et de maintenir la documentation. Capturer les informations dans un format très visible est ce que je cherche un moyen intelligent de faire ...
Notre équipe a essayé ceci: le problème est que de nombreux programmeurs ne feront aucun effort pour documenter des idées et des réunions et préfèrent simplement écrire le code ... maintenant quoi?
Demandez à quelqu'un de faire du bénévolat pour vous aider à mettre les informations dans un wiki ou, lorsque vous avez terminé, prenez des photos du tableau blanc et avez-vous démarrez comme une capture de données dans le wiki. Vous pouvez écrire sur le wiki pendant la réunion et, plus tard, les gens peuvent le nettoyer. Si les programmeurs ne se soucient pas de bien communiquer, c'est un problème culturel dont vous aurez besoin de résoudre.
Les gens feront généralement ce qu'ils sont récompensés et s'abstiennent de ce qu'ils sont punis. Institut Documentation Avis.
Il est temps de grandir si personne ne veut prendre des notes. Garder de bonnes notes de rencontre, wiki, etc. fait partie de la programmation professionnelle. C'est l'un de nos outils et une de ces choses que vous devez faire. Écrire une spécification Tech de 30 pages est quelque chose à éviter, mais il est essentiel de garder un wiki à jour de connaissances tribales.
Coller à l'ordre du jour. Reste sur la cible. Lorsque les choses commencent à virer de bien sûr, planifiez une autre réunion ou prenez-la à courriel après la réunion.
fin de chaque réunion avec des articles d'action - une liste écrite de qui va faire quoi et quand on s'y attendait. Oui, cela signifie que quelqu'un doit écrire / taper quelque chose pendant la réunion.
Si la documentation devient importante et nécessaire, alors je vous suggère fortement de proposer des normes simples, puis de les coller.
wiki. Wiki. Wiki. Toutes les informations «connaissances tribales» utiles pour l'équipe doivent entrer dans un wiki. Comment configurer des environnements de développement, des conseils de débogage communs, etc., etc.
Avant de fermer une réunion, la personne qui dirige qu'il devrait indiquer les actions et bien sûr, qui vont les exécuter et obtenir un accord de la personne assignée ou des personnes. Quelqu'un devrait être affecté à créer des notes de réunion et de les poster. Vous pouvez essayer de se tourner sur les notes afin que tout le monde doive le faire parfois. Vous pouvez essayer un maître Scrum (si vous faites Scrum).
Essayez un wiki pour les notes. Les notes de la réunion devraient inclure les actions d'action. Tous les articles d'action doivent avoir une date associée à eux.
Si vous ne pouvez demander à personne de reconnaître qu'un enregistrement de ce que vous faites est important, vous avez un problème sérieux avec vos développeurs. Bien sûr, vous pouvez prendre une photo du tableau blanc et ses notes, mais cela n'aidera pas les problèmes de lecture et d'entretien.
De nombreux programmeurs (moi-même inclus) comme la documentation écrit beaucoup.
Tant que # 1: Que diriez-vous d'une nouvelle carte post-iT? Créez une zone très visible dans l'environnement de travail. Comme les idées sont discutées de la gifle une note de rappel sur un collant et mis sur le tableau. Gardez le tableau partitionné en catégories (UI, amélioration des performances, etc.). Un membre responsable peut prendre en charge de les transcrire à un wiki complet, lorsque le détail doit ajouter ou que l'idée est suffisamment bonne qu'elle mérite un effort réel passé dans la conception.
Tant que # 2: Si votre équipe a du mal à rester sur la cible, l'organisateur MTG doit donc prendre le temps de préparer un programme de préparation d'un ordre du jour et à statuer sur des conversations restez sur le sujet et insistez sur cette réunion à temps. Laissez la réunion sachant qui doit faire quoi.
Comme pour le n ° 3: Quelqu'un doit diriger la charge, trouver des exemples de la documentation et des spécifications que vous aimez voir et à planifier quelque temps avec l'équipe pour examiner et discuter.
Je trouve qu'il est important d'enregistrer la raison d'une décision sur un wiki ou une carte postale. Sans cela, sur des éléments critiques où deux options peuvent être implémentées, vous verrez un développeur inversant un certain code d'un autre développeur. Les deux peuvent avoir des raisons valables, mais c'est une indication claire du manque de communication.
Pour éviter les problèmes, les décisions clés des réunions doivent être répétées, même jusqu'à un mois après.
Document tout, et pas dans l'email!
Utilisez quelque chose avec une histoire. J'ai été tenté d'utiliser Google Wave pour suivre le "développement" d'un projet (en changeant les exigences, interprétations, etc.). Un wiki travaillera aussi mais a une barrière supérieure à la modification et peut être mise à jour par moins de personnes. Le feu de camp est également une bonne méthodologie.
Les nouvelles méthodologies (feu de camp / vague) sont essentiellement enregistrées des journaux de discussion que vous laissez ouverte tout le temps. Le feu de camp n'a aucun moyen de "promouvoir" les décisions importantes, je pense qu'ils se perdaient dans la conversation générale - mais avec Google Wave et Wikis, vous pouvez réduire continuellement les informations non pertinentes ou anciennes. Wikis vous donnera plus de capacité à reformater le nouveau.
En fait, une combinaison de vagues / wiki pourrait être meilleure. Il suffit d'utiliser la vague pour la conversation quotidienne de type im et tirez des discussions / décisions importantes sur le wiki.
Certaines des pratiques de XP (Agile) aident également ici. Si vous êtes plein sur XP (pas simplement appeler vos réunions quotidiennes "Scrums"), vous trouverez une aide importante, telle que les exigences de suivi des cartes constamment mises à jour ou ayant un client sur place pour répondre à des questions importantes. Toute l'idée de XP / agile repose sur le fait que les exigences changent et que ces changements doivent être suivis et qu'ils affectent le calendrier de publication.
La tick est pour "pas dans l'email"
Je pense qu'un wiki ou un blog interne pourrait être excellent pour documenter des procédures utiles pour tous les membres de l'équipe.
Mais un autre point intéressant est la communication entre les programmeurs lorsque certains programmeurs ont un doute sur la mise en œuvre. Par exemple: un programmeur ne sait pas comment mettre en œuvre certaines fonctionnalités. Donc, cela pourrait poster votre doute dans une "application de messages courts", comme un Twitter (mais avec plus de 140 caractères). Ensuite, un développeur qui sait résoudre son doute pourrait poster la solution. Tous les messages seront stockés jusqu'à ce que la solution ait été trouvée. Ainsi, tous les autres membres de l'équipe se tourneront vers cette solution à l'avenir.
Je pense que ce schéma est agréable, car parfois le développeur n'aime pas "perdre beaucoup de temps" écrire un article sur blog ou quelque chose sur wiki.
J'utilise Basecamp pour gérer mes projets. Les réunions deviennent amusantes sessions de brainstorming, le travail est ensuite délégué sur le site.
Si nous parlons de rester en contact d'une manière qui remplace la voix et le texte, consultez http://circlehubb.com . Non seulement vous pouvez avoir une discussion entre membres du même groupe, mais vous pouvez partager des documents PDF et mot, des photos et des vidéos. Vous pouvez également rendre votre groupe privé ou public. Leur application est censée sortir bientôt.
Voter pour fermer ... Ce n'est pas une question liée à la programmation, la gestion de l'équipe est liée et la même question pourrait s'appliquer à presque toutes les entreprises.
Pas sûr si je suis d'accord. Les programmeurs, en particulier les mecs plus jeunes sont notoires pour ne pas vouloir documenter quoi que ce soit, plus de mon expérience que d'autres professionnels.
Très programmation lié! Très peu d'entreprises ont les mêmes problèmes de conception que les programmeurs ont, et même s'il s'agissait de toutes les entreprises, il s'agit d'un problème que chaque programmeur doit éventuellement traiter.
@Andy e: "Connexion de la programmation" n'est pas la même chose que "Programmation spécifique"
@Javier: Dites-le à tous les utilisateurs qui ont leurs questions relatives au carrière de programmation fermées. C'est essentiellement la même chose.
Je préférerais dire ça à ceux qui ferment ces questions
Je vois aussi comme un endroit où je peux avoir des conversations avec un grand public de personnes dans mon domaine avec plus d'expérience. Il en va de même comme être dans les couloirs d'une grande conférence où de bonnes idées et d'énergie sont projetées.
Je vote pour fermer cette question comme off-sujet, car cela vous demande conseils sur le lieu de travail, qui conviennent mieux à Workplace.stackexchange.com