Fournir des estimations lorsque vous travaillez avec une technologie inconnue?

19

Récemment, on m'a présenté un nouveau problème, pour fournir une estimation pour un projet dans lequel je dois utiliser un cadre (et potentiellement des morceaux d'un autre cadre) que je ne connais pas. Il m'est beaucoup plus facile de fournir des estimations lorsque je suis libre d'utiliser ce que je connais, mais c'était comme si une paralysie paralysante par analyse s'était déclenchée lorsqu'une estimation avait été demandée pour un travail en territoire inconnu.

Rétrospectivement, ma solution était fausse. J'ai simplement commencé à travailler.

Comment est-ce que je pourrais mieux estimer des projets et des tâches quand je dois travailler avec des langages / technologies / cadres inconnus?

estimation

— Sampson
source

2

Donner une estimation sur quelque chose que vous n'avez jamais fait est, en pratique, impossible à faire avec précision. J'ai récemment donné cette analogie lorsqu'on m'a demandé combien de temps cela prendrait quand il y avait beaucoup d'inconnues: "Imaginez que vous vous promenez dans la campagne la nuit. Il fait noir. Vous devez marcher un mile par voie terrestre. Vous savez dans quelle direction vous besoin d'aller, mais vous avez seulement une lanterne qui illumine dix pieds. Vous n'avez aucune idée de ce qui vous attend: champ, rivière, montagne. Compte tenu de cela, vous pouvez faire des suppositions éclairées, mais finalement vous êtes soumis à des choses hors de votre contrôle "

— Nemi

Cela dépend également du but de l'estimation. Estimez-vous le cas le plus probable? Pire cas? Y a-t-il des échéances strictes?

— David Thornley

@David Je pense que ce serait un cas "très probable".

— Sampson

18

La réponse standard du manuel agile est d'effectuer un pic. Un pic est une tâche temporelle pour explorer l'inconnu, de sorte qu'à la fin vous avez (espérons-le) suffisamment d'informations pour fournir une estimation utile ou vous avez une meilleure idée du temps qu'il vous faudra pour arriver à ce point .

Les pointes peuvent durer de 1 heure à plusieurs jours ou même plus. Puisqu'elles sont limitées dans le temps, il n'y a aucun risque pour l'une ou l'autre des parties et les dépenses sont strictement limitées.

Idéalement, pendant la pointe, vous identifieriez quelques choses simples qui devaient être réalisées avec ce nouveau cadre et vous mettriez en place des solutions très simplistes. Au fur et à mesure que vous avancez, vous apprenez, et c'est de cela qu'il s'agit.

— Wolfgangsz
source

C'est peut-être une bonne idée d'ajouter que "spike" est la terminologie de Scrum .

— Jesper

1

Cela ressemble à une bonne approche. Dans mon cas particulier, mon "pic" consistait en le projet lui-même. Cela m'a semblé une utilisation précieuse de mon temps pour réellement utiliser la tâche comme ma passerelle vers la familiarité plutôt que vers une tâche non liée.

— Sampson

10

La manière classique de procéder est le raffinement. Lors de la première réunion de planification, vous dites:

"Je n'ai aucune idée - nous faisons essentiellement des recherches sur les logiciels ici. Cependant, j'aurai une meilleure estimation d'ici la prochaine réunion, dans quelques mois"

Ensuite, vous partez et faites la recherche. Prochaine réunion:

"Il semble que cela prendra de deux à quatre trimestres. Nous allons construire un prototype qui nous permettra d'affiner les chiffres".

Prochaine réunion:

"Le prototype était plus facile à construire que nous ne le pensions. Il semble que nous pouvons le faire en 2 trimestres, plus ou moins par mois."

etc. À chaque étape, l'entreprise a la possibilité de mettre le projet en conserve ou de le laisser continuer, obtenant ainsi de meilleures estimations de la date d'achèvement.

Ceci est très bien décrit dans le grand livre de Steve McConnell, Rapid Development , qui mérite d'être bien mieux connu. Certes, il est de loin supérieur à tous les livres sur "agile" que j'ai lus.

— Neil Butterworth
source

+1 Merci pour la perspicacité, @Neil. J'examinerai également la suggestion de livre.

— Sampson

2

Vous pouvez faire des recherches et toujours trouver de mauvaises estimations. Voir L arge Limits to Software Estimation par JP Lewis, et le document d'accompagnement Mathematical Limits to Software Estimation . Je ne dis pas que vous ne devriez pas vous soucier d'estimer ou de rechercher, mais simplement que vous ne pouvez pas faire une estimation objectivement précise, et vous devez le dire avec toute estimation à laquelle vous arrivez.

— Bruce Ediger
source

3

Les estimations sont par définition inexactes, et il semble que de nombreux managers et / ou clients ont du mal avec cette réalité.

— wolfgangsz