¿Qué tan bien definido debe estar un producto de software antes de comenzar a codificar?

13

Quería saber qué tan bien la gente define un producto de software antes de comenzar a codificar y qué tan bien ha funcionado para ellos. Me refiero a definir casos de uso, analizar riesgos, dibujar diagramas de clase, etc.

Sé que es una buena idea tener una idea suficientemente clara de cuál será el producto final para poder evitar riesgos en el futuro, pero también es importante no definir un producto tan bien que sea difícil. para adaptarse al cambio.

Otras preguntas más específicas probablemente serían:

  1. ¿Qué porcentaje del tiempo de un proyecto se gasta normalmente en las etapas de planificación antes del desarrollo?

  2. ¿Tienes ciertos criterios medibles que intentas cumplir antes de comenzar a codificar o es más que una simple cosa?

  3. ¿Diagrama todas las clases antes de comenzar a codificar, o trata principalmente de crear un diseño dinámico desde el principio esperando que las cosas cambien?

¡Cualquier experiencia que estés dispuesto a compartir sería increíble!

    
pregunta drewag 15.04.2011 - 04:27

6 respuestas

10

La respuesta literal a "qué tan bien definido?" es

Está lo suficientemente definido como para que puedas empezar.

Está lo suficientemente definido como para que pueda identificar un ámbito de trabajo inicial (para un concepto inicial). Esto es suficiente para ayudar a identificar cambios que inevitablemente sucederán.

Está lo suficientemente definido como para que puedas priorizar los sprints.

  

Me refiero a definir casos de uso,

Siempre útil. Pero no todos . Usted debe priorizar y cubrir los casos de uso importantes primero. Otros casos de uso serán cubiertos en versiones posteriores. Algunos casos de uso tendrán una prioridad tan baja que nunca se terminarán.

  

analizando el riesgo,

En general, una pérdida de tiempo.

  

dibujar diagramas de clase, etc.

Si ayuda.

  

¿Qué porcentaje del tiempo de un proyecto se gasta normalmente en las etapas de planificación antes del desarrollo?

Varía mucho. Compre un buen libro, como Software Engineering Economics para obtener números "autorizados".

  

¿Tiene ciertos criterios medibles que intenta cumplir antes de comenzar a codificar o es más una cuestión de instinto?

"medible". Eso es casi imposible de definir.

"gut". Mala política.

El problema es "¿entiendes lo que estás haciendo?"

No es una cosa visceral. Es una pregunta de sí / no.

No es "medible", ya que es solo una pregunta de sí / no.

Y, además, tienes que priorizar. No haces todo. Solo lo suficiente para manejar los primeros sprints.

  

¿Diagrama todas las clases antes de comenzar a codificar, o trata principalmente de crear un diseño dinámico desde el principio esperando que las cosas cambien?

No puedes saber todo de antemano.

No lo intentes.

    
respondido por el S.Lott 15.04.2011 - 04:56
2

Si su cliente se une activamente al proyecto como miembro del equipo del proyecto, está disponible para los desarrolladores para preguntas y para tomar decisiones rápidas sobre la funcionalidad. Entonces la especificación podría ser menos detallada.

Si su cliente está lejos y no está disponible para recibir comentarios en un largo período de tiempo, entonces su especificación debe ser muy detallada.

En nuestra empresa, creamos historias de usuarios y jugamos Planning Poker con los desarrolladores del proyecto. Eso nos da una indicación justa de las horas que se gastarán en una historia de usuario.

    
respondido por el pderaaij 15.04.2011 - 07:43
2

Qué tan bien definido debe estar el proyecto es lo suficientemente bueno para comenzar y saber hacia dónde se dirigirá durante las próximas dos semanas.

Como Scrum Master, simplemente diría que debe definir las características generales de su producto en una hoja de Excel o en cualquier otro lugar, solo para realizar un seguimiento de sus funciones. Hacerles Historias de usuarios ayuda mucho a pensar qué función necesita a continuación. Luego, priorícelas: la característica más importante o imperativa en la parte superior y la menor en la parte inferior.

Después de que haya enumerado algunas de las funciones más importantes, seleccione las funciones que cree que puede desarrollar y ponga en estado Hecho después de un período de dos semanas, o un período de un mes, si lo prefiere. Luego, explote estas características seleccionadas para que pueda comenzar a codificar algunas.

Mientras esté codificando, sin duda pensará en otros elementos que deben desarrollarse para que sus funciones seleccionadas se pongan en estado Listo. Hecho significa que no tiene nada más que hacer, es decir, las pruebas, la codificación, el ensamblaje, la documentación está hecha.

En cualquier momento, su lista de características seleccionadas puede expandirse, siempre que cumpla con el objetivo, es decir, puede desarrollar todo lo que dijo durante el período dado.

En resumen, nada tiene que ser perfecto. Agregue algunas ideas, comparta con sus compañeros y vea si lo que está escrito tiene sentido para cumplir con los requisitos del producto exigido. Si es así, entonces estás en! Para que quede claro, iré con un producto simple de Gestión de Clientes. ¿Qué se necesita?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

¡Tu primer borrador podría ser tan simple como eso! Entonces, podemos ver que la seguridad es una parte importante en nuestro sistema, ¿es lo suficientemente importante como para tener la máxima prioridad (S / N)? Esto dependerá de los requisitos que tengas que cumplir. Digamos que la gestión de clientes es lo más importante aquí. Por lo tanto, en el próximo Sprint, debemos poder administrar a los clientes de una manera básica pero aceptable. ¿Qué es la gestión de clientes?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Esto ya ilustra suficientes funcionalidades para poder comenzar a desarrollar la aplicación. Si sus programadores necesitan más instrucciones, ¡tal vez un desarrollador que se sienta cómodo con los diagramas de clase pueda diseñar la clase de Cliente y sus propiedades y métodos! Pero en lo que a mí respecta, con estos pocos que he escrito, tendría suficiente para empezar. Algunas características se pueden agregar o cambiar en el camino. Lo importante es centrarse en lo que usted dijo que se iba a hacer. En nuestro ejemplo, es la cosa de la Gestión de Clientes. No tenemos que preocuparnos por la autenticación del usuario a partir de ahora. Esto vendrá más adelante en el próximo Sprint.

Espero que esto ayude! =)

    
respondido por el Will Marcouiller 15.04.2011 - 08:14
1

Bueno, lo que me funciona muy bien es tener la funcionalidad "bastante bien" especificada y la arquitectura del software muy poco especificada.

Para que comience a trabajar, necesito saber para qué estoy trabajando. No funciona para mí cuando simplemente entiendo las necesidades del cliente. Incluso si estoy escribiendo una herramienta para mi propio uso, dibujo las pantallas, describo la funcionalidad, lo que hace cada botón, todo. De lo contrario, encuentro que no puedo empezar.

Por otra parte, me he dado por vencido en dibujar exactamente cómo desarrollaré el código. Tal vez esto sea una práctica peor, pero funciona para mí. Podría definir un conjunto de tablas de base de datos que crearé, pero no qué columnas hay en cada una. Podría pensar qué objetos y clases necesito, pero definitivamente no dibujo diagramas.

Demonios, a veces ni siquiera sé cómo hacerlo bien hasta después de haberlo hecho mal. Lo construyo una vez, lo derribo y lo vuelvo a hacer, ahora que sé cómo. En este punto, puedo dibujar una hoja de ruta bastante detallada y reiniciar.

    
respondido por el Brad 15.04.2011 - 07:30
1

¿Qué lenguaje y metodología estás usando?

Algunos lenguajes, como Java y C ++, requieren más estructura inicial que lenguajes como Common Lisp o Python (C ++ más que Java, porque la refactorización es más fácil en Java). Leo Brodie (creo que en "Thinking Forth") dio dos consejos sobre cuándo comenzar a programar: antes de que te sientas cómodo en Forth, más tarde de lo que quieras en otro idioma.

La metodología de cascada (especialmente cuando el diseño temprano es un entregable) requerirá más trabajo por adelantado que ágil (aunque tampoco se debe descuidar la planificación temprana en métodos ágiles). Tener un buen conjunto de pruebas automatizadas hace que sea más seguro cambiar cosas más grandes y, por lo tanto, le permite trabajar con menos trabajo inicial.

Además, depende de los individuos y su familiaridad con el tipo de software que se creará. En un momento dado, al hacer aplicaciones principalmente de CRUD, podía escribir un programa completo comenzando con unas pocas especificaciones y un trozo de papel para notas de 3 "x5". No puedo escribir las cosas que escribo así.

    
respondido por el David Thornley 15.04.2011 - 16:54
1

Dos términos útiles aquí son MVP (Producto Mínimo Viable) y MMF (Característica Mínima de Comercialización). Un MMF es la versión más pequeña de una característica que ofrece valor comercial. Un MVP es el menor número de MMF que es viable como producto. Al iniciar un proyecto, lo mejor que puede hacer es identificar los FMM y el MVP y comenzar desde allí.

Libere su producto tan pronto como sea viable, luego continúe mejorándolo.

    
respondido por el Rein Henrichs 15.04.2011 - 17:48