¿En qué punto de un proyecto los desarrolladores deberían comenzar a "comer su propia comida para perros"?

Question

Tenemos un proyecto que viene donde el PM insiste en que el equipo debe "comer su propia comida para perros"?

¿En qué punto es realista hacer esto?

p. Ej. supongamos que tenemos que escribir un editor. No podemos utilizar este editor al principio para realmente codificar porque no existe. Tenemos que usar otro editor.

Durante un tiempo durante el proyecto, usar un editor de errores va a ralentizar el proyecto y será contraproducente.

Entonces, ¿en qué punto cambiamos?

Actualización: Después de alguna discusión dentro del equipo, los puntos vamos a estrés durante el desarrollo son:

• Implementar subconjunto más pequeño posible para empezar con
• Identificar las características críticas antes posible
• Sólo cambiar algunos de los desarrolladores utilizar el nuevo producto para minimizar el riesgo

Answer 1

Algunos de los que usted debe utilizar como tan pronto como sea posible La primera versión debe ser despojada, con solo las características más esenciales que necesita para usarla como (en este caso) editor. Una vez que empiece a usarlo, sabrá de prisa qué funciones son importantes.

Answer 2

No tiene que pasar al uso exclusivo del editor de desarrollo. Comience a usarlo hasta que tenga un impacto en su producción, haga una lista de las cosas que son problemáticas, corríjalas, repita hasta que pueda usar productivamente la mayoría de las veces.

Answer 3

Dependiendo de cómo se realice el desarrollo, puede cambiarlo antes o después. Si está utilizando una metodología TDD o si encuentra y soluciona errores en la lista, comenzaría cada vez que tenga suficientes características que considere útiles para su vida cotidiana. Esto podría ser muy temprano en el desarrollo si ha priorizado sus funciones de manera efectiva.

De lo contrario, esperaría hasta llegar a algunas de las etapas posteriores, pre alfa o pre beta. Esto significa que no siente demasiado dolor al principio del desarrollo.

Como lo menciona otro, si puede cambiar sus esfuerzos de desarrollo para intentar que el producto se pueda utilizar antes, ¡hágalo! Recomendaría que las personas comiencen a utilizar el producto en serio lo más temprano posible para ayudar a evaluar las diversas funciones y lograr que sus usuarios iniciales se apeguen emocionalmente al producto. Un desarrollador que se preocupe a menudo hará un esfuerzo extra para que el proyecto sea mucho mejor.

Answer 4

Se trata de encontrar cuál es su "masa crítica" de características. Si solo se trata de errores y no funciones, cambia ahora. Arregla tus errores Si va a necesitar hacer un desarrollo de características antes de que su herramienta sea útil, termine esas características críticas y luego cambie.

¡Y espero sinceramente que no esté escribiendo un editor! ;-)

Answer 5

Supongo que la respuesta correcta es tan pronto como sea posible. Por supuesto, usar una versión con errores va a ralentizarlo al principio, pero luego realizará el control de calidad a medida que se desarrolla, a la larga le ahorrará tiempo. Sugeriré que algunos miembros de su equipo cambien y no todo el equipo para evitar una gran retención si hay un bloqueador en la aplicación.

Answer 6

Por un tiempo durante el proyecto, utilizando un editor de cochecito va a retrasar el proyecto abajo y será contraproducente productiva.

Parece que tiene su respuesta. El momento de cambiar es cuando su proyecto no va a impedir la productividad.

Answer 7

<diatriba>

no producen alimentos para perros, entonces usted no tiene que comer comida para perros.

¿Cuál es el origen de esta frase enferma y estúpida de todos modos? los perros no producen su propia comida (con una excepción vulgar) ...

</diatriba >

piden al PM lo que es más importante: el uso del producto en fase de desarrollo para hacer el desarrollo, la producción o la calidad del código ¿a tiempo? si hay un conflicto, ¿qué es más importante?

la respuesta de sentido común es: use lo que está construyendo cuando es mejor que las herramientas que tiene.

Answer 8

Esta es una de esas preguntas "depende". Alguna guía:

• ¿Cuáles son los riesgos de utilizar el proyecto antes de que esté completamente cocido? ¿Son aceptables?
• ¿El proyecto progresará más rápido o más lento, y es esto un problema?
• ¿Mejorará la calidad del producto final desde el punto de vista comercial?
• ¿Terminará con características que hacen que los programadores sean más productivos pero que no son útiles para los clientes?
• Por el contrario, ¿las características críticas se aplazarán porque los desarrolladores no están "interesados" en ellas?
• ¿El "sabor de la comida para perros" motivará a sus desarrolladores?

Tal vez la guía más útil es lo que llamo "la regla de Headrick," después de que el compañero de trabajo que explica en primer lugar a mí:

Si usted necesita a alguien para lograr algo, que sea doloroso para él no para lograrlo!

La otra cara, por supuesto, es hacer que sea placentero hacer el proyecto lo más rápido y mejor posible. Personalmente, me gusta construir y usar herramientas, así que serviría la comida para perros tan rápido como lo permita la prudencia. Pero mi compañero de trabajo era un sádico y habría respondido: "¡tan pronto como compila!"

¡Buena suerte con su proyecto!

Answer 9

Cuando la comida para perros se vuelve apetecible Y tan pronto como sea posible. Supongo que esta es otra forma de decir que debes entregar valor temprano y con frecuencia.Y, dicho sea de paso, nunca entregan software conocido con errores. Menos características sin errores es mejor que más características con errores.

Answer 10

todo acerca del tamaño, la escalabilidad y el alcance. Si el producto proporcionaría un éxito valioso desde el enfoque de "comida para perros", ASAP sería la respuesta correcta. La experiencia del usuario final dicta el resultado final del uso del producto.

Answer 11

No empiece a usarlo hasta que llegue a una etapa "Alpha". Debe tener todas las características principales completas y sin errores críticos conocidos. Entonces puedes comenzar a usarlo.

También es importante que los usuarios objetivo lo prueben, no solo los desarrolladores (a menos que sea una herramienta de desarrollador).

Quiere tener suficiente tiempo de desarrollo para encajar en tantos "¿No sería genial si hiciera esto?" características como sea posible.

Answer 12

La pregunta no tiene sentido cuando se aplica al software que el equipo de desarrollo no utilizará, por lo que los desarrolladores deben usarlo tan pronto como sea posible. "Factible" significa que funcionará razonablemente bien y no romperá demasiado las cosas.

Al desarrollar un editor de texto, los desarrolladores deben usarlo temprano, ya que los errores no serán cruciales. Al desarrollar un sistema de control de versiones, los desarrolladores deberían usarlo solo una vez que se haya demostrado que es sólido. Fue algo muy importante cuando el equipo de Subversion se alejó de sus servidores CVS.

Una idea sería tener adoptantes anteriores y posteriores en el equipo, ya que los adoptantes posteriores probablemente detectarán cosas que los anteriores se han vuelto ciegos.