Meilleures pratiques en matière de développement logiciel – Partie 1

Jetons un coup d'œil aux meilleures pratiques employées par Progress tout au long de l'ingénierie, de la gestion des produits et du support: ce qui guide notre travail, pourquoi ces processus sont-ils importants pour nous et comment pouvez-vous apprendre de nos propres meilleures pratiques internes.

Bonjour ! Je suis Mandy Mowers. Je travaille avec Progress depuis quelques années maintenant, en collaboration avec des rédacteurs externes pour créer du contenu de blog qui peut servir nos utilisateurs et d'autres acteurs de l'industrie de la technologie. Je n'ai pas eu beaucoup de chance de regarder à l'intérieur de cette entreprise, alors quand l'occasion s'est présentée de parler avec neuf des personnes responsables de nos produits, j'ai sauté dessus.

Je suis ravi de partager ce que je J'ai appris les pratiques et les processus qui guident le progrès.

Contexte du progrès et de Telerik

Pour fournir un peu de contexte, je voulais partager un peu l'histoire et la structure de l'entreprise.

Telerik a été fondée en 2002 à Sofia , Bulgarie. Telerik s'est bâti une réputation en créant des outils logiciels destinés aux développeurs pour le développement d'applications Web, mobiles et de bureau. Progress, une société de logiciels américaine fondée en 1981, a acquis Telerik en 2014.

Parce que «Telerik» était déjà synonyme de «produits de développement de qualité», Telerik.com est devenu l'hôte de tous nos DevTools, y compris les produits Telerik .NET et les produits JavaScript de l'interface utilisateur Kendo.

Les personnes que vous entendrez dans cette série travaillent toutes sur ce côté DevTools / Telerik / Kendo UI de Progress, impliquées dans la création de produits destinés à d'autres développeurs.

Écoutons ce qu'ils ont à dire!

Comprenez d'abord le problème

Un thème très important que j'ai entendu était de vous assurer que vous en appreniez pleinement sur le problème avant de vous plonger dans une solution.

Savoir Votre public: le nôtre est celui des autres développeurs

La première étape pour comprendre un problème consiste à comprendre qui est confronté au problème que vous essayez de résoudre. Dans notre cas, ce sont d’autres développeurs. Comme vous le verrez, écouter ces clients représente pour nous une part importante du cycle de travail.

Genady Sergeev — Directeur, Génie logiciel; Développement de produits d'outillage pour développeurs

Nous devons nous adapter et créer nos composants et logiciels en suivant les mêmes pratiques, processus et outils que les développeurs auxquels nous essayons de vendre. Sinon, le résultat final ne les intéressera probablement pas. Lorsque vous y pensez, lorsque nous créons des démos et ou même la façon dont nous produisons du code, nous devrions utiliser les mêmes outils que ces développeurs. sinon nous arrivons avec quelque chose de différent de ce qu'ils recherchent. [19659003] Maria Veledinova – Chef de produit; Outils de développement PM & PMK

De plus, nous écoutons toujours les commentaires des clients. Et puis nous Les douleurs sont-elles toujours les mêmes? Les besoins sont-ils toujours les mêmes? Faut-il changer quelque chose?

Todor Mitev — Software Engineer, Principal; Unite UX

Nous ne sommes pas le type de société de logiciels qui construit un type de produit logiciel et qui se vend juste pour le vendre. Nous avons vraiment une orientation client. Notre code doit résoudre la douleur des clients et leur faciliter la vie. Nous sommes tous des développeurs. Nous adorons écrire du code. Mais si ce morceau de code ne résout pas les vrais problèmes, qui l'utilisera? Personne.

Tsvetomir Tsonev – Ingénieur émérite; Composants et outils Web

Et je pense que c'est un peu différent de la plupart des projets logiciels. Vous avez généralement un objectif très spécifique ou de nouvelles parties prenantes qui dictent ce qui va se passer. les voix des clients sont ce que nous suivons.

Définissez vos objectifs en établissant un résultat souhaité (pas un résultat souhaité)

Avec votre connaissance de votre public et de sa douleur, commencez à définir vos objectifs pour le projet.

] Vesko Kolev — Vice-président, Produit; BU Outillage développeur

Je pense que la plus grande différence entre nous et les autres éditeurs de logiciels ne se verra pas dans le processus réel si vous nous comparez aux autres – ce sera l'utilisation de le processus en premier lieu. Tout doit commencer par définir quel est le résultat que vous souhaitez atteindre. Et puis quelles sont les étapes que vous devez suivre pour y parvenir, et ensuite comment mesurez-vous les progrès? Et puis, quelles sont les personnes / organisations dont vous avez besoin pour vous assurer que le processus est bien exécuté? Et puis que pouvez-vous faire d'un point de vue logiciel qui permette d'automatiser ce processus? Dans cet ordre. La différence est de savoir si vous comprenez le but du processus.

Et l'autre chose est d'avoir des objectifs clairs, d'avoir des KPI qui mesurent les progrès, et aussi d'avoir un processus qui assure une amélioration continue. Beaucoup de gens pensent qu'ils déploieront quelque chose et que cela fonctionnera. La réalité est que cela pourrait fonctionner, mais à moins d'avoir une preuve, cela ne signifie pas nécessairement qu'il offre la mesure nécessaire du point de vue de l'efficience et de l'efficacité.

Passez du temps à planifier

Et enfin, passez même ] plus de temps pour réfléchir à votre approche. Ayez une image claire de qui utilisera votre solution, du résultat que vous visez et de la voie que vous allez emprunter avant d'écrire un peu de code.

Todor Mitev – Ingénieur logiciel, Principal; Unite UX

Faites toujours vos devoirs. Il y a cette phrase célèbre, quelque chose comme: «Deux heures de planification peuvent économiser deux semaines de codage.»

Donc en effet, la recherche, l'exploration, le désir de voir la situation dans son ensemble et de voir le vrai problème et comment le résoudre est très, très, très important. Et lorsque vous atteignez votre objectif, cela vous procure un tel plaisir et une telle satisfaction que je ne peux pas l'exprimer. C'est l'une des choses que j'aime le plus dans mon travail.

Genady Sergeev — Directeur, Génie logiciel; Développeur Tooling Product Development

L'une des choses que j'essaie de dire est que nous devrions davantage réfléchir aux problèmes que d'essayer de les résoudre mécaniquement. Parfois, cinq minutes de réflexion ciblée peuvent économiser trois jours de travail mis dans la mauvaise direction. Dans notre travail, la productivité n'est pas linéaire.

Vesko Kolev — VP, Product; Developer Tooling BU

Disons que nous commençons un nouveau projet. Le codage ne devrait pas être la première chose que nous faisons. Par exemple, en ce moment, nous travaillons sur un produit qui webelieve est potentiellement une innovation disruptive. Nous y travaillons depuis quatre ou cinq mois et nous n’avons écrit que quelques lignes de code. Nous faisons des prototypes. Nous faisons des interviews.

La seule chose que je crois très importante et que j'instille chaque jour dans l'équipe est la suivante: nous ne devrions pas travailler en silos. Je pense que les équipes produit (ingénieurs, développeurs, support, chefs de produit, spécialistes du marketing, etc.) devraient, en particulier lorsqu'elles construisent de nouvelles choses, travailler en tant que startup, où tout le monde connaît le contexte et est suffisamment confiant pour comprendre le contexte complet. À ce stade, ils comprendront pourquoi il est important d'arrêter le désir interne de commencer à coder Day Zero.

Vous devez comprendre: quel est le problème, puis le résultat que vous voulez atteindre. Quel est le processus? Et réfléchissez ensuite à la manière dont vous pouvez l'automatiser. Plutôt que l'inverse.

L'autre chose qui pourrait être mentionnée ici est la façon dont nous raisonnons, et nous sommes de grands adeptes de la pensée fondée sur les principes, c'est-à-dire que le processus implique un raisonnement basé sur des principes que vous détenez des vérités.

Les grandes innovations surviennent lorsque les gens ne comprennent pas la différence entre difficile et impossible. Si vous considérez très vite que quelque chose est impossible, combien de choses contre-intuitives n'auraient jamais été découvertes? La réflexion sur les principes d'abord est l'autre chose. Nous essayons de raisonner et de prouver avec des expériences tout ce que nous pensons être factuel. Cela nous aide à être plus ouverts d'esprit et, espérons-le, à trouver des choses qui ne sont pas si évidentes mais qui sont potentiellement très précieuses. essayer de résoudre avant de le résoudre. Assurez-vous de savoir qui utilisera votre produit et parlez-en avec eux. Pensez au problème, élaborez une stratégie pour le contourner avant de coder une solution.

La prochaine fois, nous parlerons encore plus de l'écoute de vos utilisateurs.