J'ai rejoint l'entreprise actuellement sur laquelle je travaille en tant que fraîcheur. En raison du nombre limité de personnes qualifiées dans le développement de logiciels SIG, et comme je faisais partie de l'un d'eux, j'ai été directement recruté en tant que chef de projet.
J'étais assez familier avec Java et SIG, et j'ai fait des recherches motivées sur les services basés sur la localisation, mais pas avec la gestion de projet et le développement de logiciels structurés. C'était un an après mon diplôme de spécialisation en géologie et l'année précédente, je travaillais comme universitaire dans une université.
Grâce à l'intérêt que je portais au travail, une opportunité s'est présentée et j'ai finalement été nommé responsable du département Business Intelligence de l'entreprise. L'entreprise a cru en moi. J'ai moi-même étudié les concepts d'entreposage de données et de BI et j'ai réussi à combiner le SIG avec la BI également.
De plus, je travaille actuellement avec deux développeurs sur notre outil de BI dans C # WPF, où je joue également le rôle de développeur à certains moments (ce que j'aime).
J'ai essayé très fort d'adopter de bonnes méthodologies de développement logiciel avec une gestion de projet agile, mais cela n'a pas été très réussi. De plus, même si je crois en un code bien conçu en ce qui concerne un produit, en raison du manque de connaissances techniques de mon PDG (qui est directement au-dessus de moi), je n'ai généralement pas le temps nécessaire pour le faire. Le temps pris est considérablement amélioré par le manque d'expertise que nous avons dans le langage de codage spécifique dans son ensemble (par exemple WPF opposé à Java). Il n'y a pas non plus de système de contrôle de version en place.
Je suis extrêmement fatigué de la façon dont les choses se déroulent car elles ne sont pas structurées et je trouve la plupart de mon temps à penser à travailler à la façon de structurer les choses. J'espère que vous, les gars possédant une bonne expérience professionnelle, pourrez m'aider à surmonter cette situation.
Réponses:
Nous avons eu un problème similaire (sans les détails techniques, bien sûr) dans l'entreprise dans laquelle je travaille il y a environ deux ans.
Vous avez juste besoin de le faire une étape à la fois. N'essayez pas d'adopter le développement logiciel agile à la hâte. Il y a beaucoup de choses à apprendre et à appliquer. Ne laissez pas le manque d'expertise vous abattre non plus.
Construisez lentement (mais aussi vite que possible: P), régulièrement et sûrement.
Je recommanderais les prochaines étapes (pour ce faire, vous pouvez passer de la gestion au développement pendant un certain temps, mais ça devrait aller)
Aussi, si possible, engagez un consultant juste pour qu'il puisse vérifier le processus et donner de meilleurs conseils.
Ne soyez pas paresseux ou découragé. Apprenez simplement de vos erreurs et essayez différentes approches. Ce n'est que le début!
Éditer:
Voici quelques-uns des liens et des livres que j'ai lus / utilisés récemment ...
Git d' apprentissage: Pro Git
Voici quelques-uns des blogs que je recommanderais (la plupart d'entre eux sont orientés .NET):
Pour les livres, vous pouvez voir la liste Construire un noyau de programmation solide sur Amazon. Je recommanderais également ces derniers:
la source
En tant que gestionnaire, c'est votre travail pour obtenir le temps nécessaire pour terminer un projet correctement. Lorsque vous vous approchez du PDG, assurez -vous d'avoir tous les chiffres à l'appui et les raisons pour lesquelles les estimations sont aussi longues qu'elles le sont. Il est de votre responsabilité en tant que manager de faire comprendre au PDG pourquoi il faut n heures / jours / semaines pour accomplir une tâche donnée. Cela peut parfois être difficile, mais je n'ai pas encore rencontré de PDG qui souhaite que son entreprise échoue et je parie que si vous l'exprimez dans ce genre de conditions (si tout le reste échoue), il peut changer son air.
Si le PDG ne veut pas vous accorder le temps nécessaire pour terminer les tâches, alors à mon humble avis, soyez prêt à passer à un autre travail ou à vous préparer à des marches de la mort continuelles. En dernier recours, expliquez au PDG l'épuisement professionnel qui proviendra sans doute d'attentes irréalistes.
Cela dit, vous devez également vous assurer que vos développeurs vous fournissent des estimations précises (extrêmement difficile, presque impossible sans conceptions techniques appropriées , qui devraient également être là quelque part).
Agile n'est pas bon dans tous les domaines de développement. Fonctionne pour certains types de projets, échoue lamentablement dans d'autres. Vous devrez peut-être essayer quelques méthodologies différentes avant d'en trouver une qui fonctionne bien .
Obtenez le contrôle de version configuré . Vraiment, il faut 5 à 10 minutes pour configurer Git, quelques minutes de plus pour arrêter les opérations de base et un jour ou deux pour lire les concepts les plus avancés.
la source
Hmm, je ne sais pas si je vous ai rencontré lors d'un événement Agile / XP à Toronto - cela semble familier
Il semble que vous ayez besoin d'une pause. Prenez un long week-end, buz si vous le souhaitez et oubliez le travail pendant quelques jours.
Détendez-vous. L'auto-apprentissage est bon, et ce n'est pas parce que la méthodologie ne fonctionne pas avec les personnalités impliquées que vous vous trompez et que ce n'est pas un échec personnel.
Il existe un site (beta) pm.stackexchange.com, destiné à la gestion de projet, vous pouvez très bien y obtenir des conseils / assistance utiles - mais par tous les moyens, gardez la question ici aussi.
Passons à la technologie:
Mettez-en un comme votre priorité absolue. Je préfère les systèmes centralisés comme SVN (Subversion) à git / mercurial, car un ordinateur portable volé n'aura pas autant d'historique localement. Particulièrement important si quelque chose de super secret (comme les mots de passe et les clés ssh) a été enregistré par erreur. Mais c'est une question de goût. Rien ne perd plus de temps que les bogues du «contrôle de version manuel» - par exemple, remettre le code à ce que vous pensez qu'il était.
Bonne chance
la source
Il semble que vous ayez plusieurs problèmes: 1. Communiquer avec la haute direction non technique afin qu'elle soutienne votre programme d'amélioration; et 2. Piloter le programme d'amélioration pour réussir.
La partie la plus difficile du numéro 1 est simplement de se rappeler que la haute direction ne sera souvent pas intéressée par les détails de ce sur quoi vous travaillez. (S'ils l'étaient, ils le feraient eux-mêmes plutôt que de vous le remettre!) Il semble que le grand obstacle soit «pourquoi» et vous voudrez peut-être consulter CMM 1.1 pour une description des avantages commerciaux d'une amélioration des processus programme. Que vous utilisiez CMM ou autre chose pour réellement améliorer votre processus n'aura pas d'importance pour cette discussion, seules les données de l'étude Carnegie-Mellon qui montre que des organisations plus matures livrent des projets plus rapidement avec moins de variation dans le délai de livraison.
Il y a beaucoup de chemins vers le succès dans l'amélioration des processus, tous ont tendance à être très longs. L'expérience avec CMM montre qu'il peut falloir de 8 à 10 ans pour passer du niveau 1 à 5. L'expérience avec 6 sigma montre que chaque itération apporte une certaine amélioration mais nécessite plusieurs itérations pour éliminer la plupart des problèmes potentiels et, au moment où vous y arrivez 6 sigmas de qualité, le travail se fait complètement différemment sans avoir à prendre le risque d'essayer de tout remplacer à la fois.
S'il existe une approche d'amélioration de la qualité couramment utilisée dans votre secteur, prenez le temps d'essayer de voir comment elle s'applique aux logiciels et de l'utiliser afin que le reste de l'entreprise entende parler de quelque chose qu'ils connaissent et soutiennent déjà. Nous pouvons parler pendant des heures d'outils et de pratiques logicielles spécifiques, mais les PDG non logiciels les élimineront rapidement. Parlez des pratiques standard de l'industrie et il se redressera parce que vous parlez sa langue. Parlez des logiciels dans les termes courants de l'industrie et il commencera à poser des questions pertinentes pour mieux comprendre vos défis et vos plans pour améliorer les résultats des entreprises.
Vous ne gagnerez pas chaque demande de soutien de cette façon, vous obtiendrez probablement beaucoup moins de regards vides et plus de victoires!
Bonne chance monsieur!
la source
Toutes vos suggestions sont en effet sensées et sont la voie à suivre dans de nombreuses entreprises. Mais ils ne sont pas universels, surtout avec des équipes qui ne sont pas si expérimentées. La raison pour laquelle ils ne le sont pas est qu'ils nécessitent une certaine quantité de travail pour configurer et maintenir - même le contrôle de version - que beaucoup supposeraient être des enjeux de table pour tout projet logiciel. Parce qu'ils ont besoin d'un peu de travail, ils doivent aussi fournir des avantages. Et il se peut que dans votre situation particulière, ce ne soit pas le cas! Ou du moins les personnes chargées de prendre les décisions ne voient pas l'avantage!
Comme d'autres l'ont souligné, vous devez:
la source