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

Quería saber qué tan bien las personas generalmente definen un producto de software antes de comenzar a codificar y qué tan bien les ha funcionado. Me refiero a definir casos de uso, analizar riesgos, dibujar diagramas de clases, etc.

Sé que es una buena idea tener una idea lo suficientemente buena 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 adaptarse cambio.

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

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

2. ¿Tiene ciertos criterios mensurables que intenta cumplir antes de comenzar a codificar o es algo más instintivo?

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é dispuesto a compartir sería increíble!

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

Bien definido lo suficiente como para que pueda comenzar.

Lo suficientemente bien definido como para identificar un alcance inicial de trabajo (para un concepto inicial). Esto es suficiente para ayudar a identificar los cambios que inevitablemente sucederán.

Bien definido lo suficiente como para que puedas priorizar los sprints.

Me refiero a la definición de casos de uso,

Siempre servicial Pero no todos . Primero debe priorizar y cubrir los casos de uso importantes. Otros casos de uso serán cubiertos en versiones posteriores. Algunos casos de uso tendrán una prioridad tan baja que nunca se realizarán.

analizar el riesgo,

Generalmente una pérdida de tiempo.

dibujar diagramas de clases, etc.

Si eso ayuda.

¿Qué porcentaje del tiempo de un proyecto se pasa 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 mensurables que intenta cumplir antes de comenzar a codificar o es algo más instintivo?

"mensurable". Eso es casi imposible de definir.

"intestino". Mala política

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

No es una tripa. 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 se puede saber todo de antemano.

No lo intentes

Si su cliente se une activamente al proyecto como miembro del equipo del proyecto, quién está disponible para los desarrolladores para preguntas y 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 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 a Planning Poker con los desarrolladores del proyecto. Eso nos da una indicación justa de las horas que se gastan en una historia de usuario.

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

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

Después de haber enumerado algunas de las características más importantes, seleccione las características que cree que puede desarrollar para llevarlas al estado de Listo 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 en algunas.

Mientras codifica, seguramente pensará en otros elementos necesarios para desarrollar sus características seleccionadas en un estado Listo. Hecho significa que no tiene nada más que hacer, es decir, pruebas, codificación, 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 camaradas y vea si lo que está escrito tiene sentido para cumplir con los requisitos del producto exigidos. Si es así, ¡entonces estás dentro! Para que quede claro, elegiré 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 hacer la máxima prioridad (S / N)? Esto dependerá de los requisitos que tenga que cumplir. Digamos que la gestión de clientes es lo más importante aquí. Por lo tanto, en el próximo Sprint, necesitamos 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, ¡quizás un desarrollador que se sienta cómodo con los diagramas de clase pueda diseñar la clase Cliente y sus propiedades y métodos! Pero en lo que a mí respecta, con estos pocos que he escrito, tendría suficiente para comenzar. Algunas características se pueden agregar o cambiar a lo largo del camino. Lo importante es concentrarse en lo que dijo que iba a hacer. En nuestro ejemplo, es lo de la Gestión de Clientes. No necesitamos 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! =)

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

Para poder comenzar a trabajar, necesito saber para qué estoy trabajando. No me funciona 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 comenzar.

Por otro lado, he renunciado a dibujar exactamente cómo desarrollaré el código. Tal vez esta sea una peor práctica, 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.

¿Qué idioma 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 en "Thinking Forth") dio dos consejos sobre cuándo comenzar a codificar: antes de que se sienta cómodo en Forth, más tarde de lo que desea en otro idioma.

La metodología de la cascada (particularmente cuando el diseño inicial es entregable) requerirá más trabajo inicial que ágil (aunque tampoco querrá 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 sobrevivir con menos trabajo inicial.

Además, depende de las personas y su familiaridad con el tipo de software que se creará. En un momento, al hacer principalmente aplicaciones CRUD, podría escribir un programa completo comenzando con algunas especificaciones y una hoja de papel en blanco de 3 "x5". No puedo escribir las cosas que escribo ahora así.

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

Libere su producto tan pronto como sea viable, luego continúe mejorando gradualmente.