¿Cómo se desarrolla el software sin criterios de aceptación?

¿Cómo se desarrolla el software en colaboración en un equipo de 4-5 desarrolladores sin criterios de aceptación, sin saber qué probarán los evaluadores y con varias (2-3) personas actuando como propietarios del producto?

Todo lo que tenemos es una 'especificación' incompleta con algunas capturas de pantalla y algunas viñetas.

Nos han dicho que será fácil, por lo que estas cosas no son necesarias.

No sé cómo proceder.

Información adicional

Nos han dado una fecha límite difícil.

El cliente es interno, tenemos un propietario del producto en teoría, pero al menos 3 personas que prueban el software podrían fallar un elemento de trabajo simplemente porque no funciona como creen que debería funcionar y hay poca o ninguna transparencia de lo que esperan o lo que realmente están probando hasta que haya fallado.

los propietarios del producto no están disponibles para responder preguntas o dar su opinión. No hay reuniones o llamadas regulares programadas con ellos y los comentarios pueden llevar días.

Puedo entender que no podemos tener una especificación perfecta, pero pensé que sería "normal" tener criterios de aceptación para las cosas en las que realmente estamos trabajando en cada sprint.

Un proceso iterativo logrará esto muy bien, sin especificaciones detalladas.

Simplemente cree un prototipo incompleto, solicite comentarios del cliente, realice cambios basados ​​en los comentarios y repita este proceso hasta que se complete la solicitud.

Si el cliente es lo suficientemente paciente como para hacerlo de esta manera es una pregunta diferente. Algunos clientes y desarrolladores en realidad prefieren este proceso; Dado que el cliente siempre es práctico, (eventualmente) obtendrá exactamente lo que quiere.

No hay que decir que no va a trabajar un contrato de costo fijo o de tiempo fijo de esta manera.

Si lo que está diciendo es cierto y la especificación no es lo suficientemente buena como para que pueda comenzar (y está siendo honesto en esta evaluación), le recomiendo este enfoque:

1. Lea los bocetos y la especificación "incompleta" que le han dado.
2. Escriba su propia especificación a un nivel que sea suficiente para que pueda codificar. Puede que tenga que hacer un montón de conjeturas.
3. Muestre sus especificaciones al cliente para su revisión. Tenga en cuenta las partes que les gustan y obtenga más información sobre las partes donde creen que se equivocaron.
4. Repita los pasos 2 y 3 hasta que usted y el cliente estén sincronizados.
5. Ahora tiene una especificación adecuada.

Si su cliente tenía razón cuando dijo "será fácil", entonces este ejercicio debería ser pan comido.

Si su cliente estaba equivocado y, de hecho, hay todo tipo de problemas y lagunas en los requisitos, su borrador de especificación ilustrará rápidamente el problema y les comunicará que estaban equivocados (sin necesidad de señalar con el dedo o discutir), ya que lo hará. estar justo en frente de ellos y obvio. Además, su especificación servirá como una gran herramienta de discusión para resolver esas ambigüedades y servirá como un registro de decisiones clave a medida que la revise con sus comentarios.

El dueño del producto le entregó un prototipo; devuélvelo mejores (hasta que hayas terminado)

Parece que se le ha proporcionado un prototipo en papel para comenzar el proyecto. Ese no es un comienzo terrible. Le sugiero que se comunique con el propietario del negocio en el mismo idioma , proporcionando prototipos con capacidad progresiva.

Sus prototipos deben comenzar con papel, pasar a maquetas digitales y luego construirse con tecnologías "reales".

Treehouse tiene una excelente guía para esto, que concluye:

Lo maravilloso de la creación de prototipos con un marco es que el prototipo a menudo simplemente se convierte en el sitio real porque la estructura y el estilo ya están en su lugar. No es necesario recrear el sitio desde cero si va a usar el mismo marco.

Es posible que también desee proporcionar una especificación formal, especialmente si sigue preocupado por la culpa de un mal resultado. Pero probablemente obtendrá más comentarios de los prototipos.

Cumpla su fecha límite

Tenga en cuenta que sus esfuerzos posteriores no serán "prototipos" clásicos como todos, ya que no serán desechables (o parte de ellos no lo serán). La última iteración más capaz que complete antes de la fecha límite se convierte en su entrega.

Su fecha límite es el requisito mejor definido que tiene. Tenga algo completo y coherente que pueda entregar a tiempo.

Colabora con tus evaluadores

Si este proceso laxo es algo nuevo para su empresa, es probable que sus evaluadores estén aún más perdidos de lo que usted está, y pueden estar buscando su orientación. Tienes que obtener algo de su tiempo al principio del proceso. Hágales saber a su jefe que está tratando de ayudarlos a proporcionar una prueba significativa sin recibir criterios formales de aceptación.

Averigüe si los evaluadores tienen algo firme que necesiten proporcionar, como documentación de prueba de prueba, en la que usted pueda "volver".

Prueba Test First Design

Dado que no tiene requisitos formales, lograr que se desarrollen casos de prueba proporcionaría cierta estructura.

Obtenga una familiaridad pasajera con Test First Design y / o desarrollo impulsado por pruebas y brinde orientación a sus evaluadores sobre el proceso según sea necesario. Para un proyecto rápido como este, no necesita convertirse en experto en el proceso. Pero el uso de una metodología probada se reflejará bien en usted y sus evaluadores.

Cumplir con los estándares, especialmente para la interfaz de usuario

No tiene requisitos de apariencia, pero sí tiene una fecha límite. Utilice el trabajo de diseño de otra persona para minimizar el trabajo que necesita hacer para crear un artefacto de aspecto profesional.

Elija una IU estándar para su sitio y no la personalice a menos que / hasta que se le indique. No sé para qué plataforma está desarrollando, pero Bootstrap o Google Material Design son dos ejemplos.

Comunícate, pero no molestes

Sugeriría enviar un correo electrónico al propietario del producto por día. Solo envíe más que eso si es una emergencia.

Si tiene preguntas, describa cómo procederá si no recibe orientación. Por ejemplo:

¿Los usuarios de esta aplicación deberán acceder a ella con dispositivos móviles? En este momento estamos asumiendo que este será un sistema de computadora de escritorio / portátil.

No se asuste

He participado en muchos proyectos para personas que no conocían el término "requisito". La mayoría tuvieron éxito. Los propietarios de productos sin manos le dan la libertad para crear soluciones excelentes.

Tenga en cuenta que algunos propietarios de proyectos en estos proyectos eran imposibles de complacer y se escondieron detrás de la excusa "Estoy demasiado ocupado para ..." por su incompetencia. Pero la mayoría estaba "encantada" con los resultados finales.

Un proyecto es el acto de reducir la incertidumbre hasta lograr la certeza :

• Siempre hay cierto grado de incertidumbre al comienzo. A veces hay una pequeña ambigüedad en los requisitos. A veces, son muy incompletos. Tendrás que ejercitarte como parte del trabajo.
• El truco consiste en reducir de forma iterativa esta incertidumbre (combinando análisis, diseño e implementación), refinando historias de usuarios e implementando su sistema.
• Pruebas de casos / escenarios, y los criterios de aceptación deberán aclararse de la misma manera. Contribuirán a reducir la incertidumbre sobre la calidad y la corrección (entre otros).
• Al final, se alcanza una certeza suficiente: el cliente obtiene un producto probado que se ajusta a sus necesidades y puede ser utilizado.

Ese es el principio de elaboración progresiva: los requisitos, criterios y resultados se elaborarán paso a paso, al igual que la comprensión del cliente de sus propias expectativas y requisitos a través de su participación en el proceso de desarrollo.

Es esto un problema ?

Cuanto más incompletos sean los requisitos iniciales, mayor será la incertidumbre y mayor será el tiempo necesario para realizar las tareas. Entonces es solo una cuestión de quién hará el trabajo adicional y quién pagará los costos.

La respuesta de estas dos preguntas debe estar en el contrato. O será objeto de una negociación. Y el cliente debe aceptar una participación adicional (el argumento principal será "basura adentro, basura afuera", aunque le aconsejo encarecidamente que lo presente de una manera más diplomática ;-))

" No hay reuniones regulares programadas ". Bueno, ¿por qué no comienzas por programar reuniones regulares entonces? El solo hecho de que tenga múltiples propietarios de productos garantiza que su proyecto NO será fácil, ya que cada una de esas personas TENDRÁ requisitos en conflicto que DEBEN discutirse en persona con todas las partes interesadas presentes.

Además, realmente, realmente, realmente recomiendo que mantenga un registro detallado de decisiones . Como mínimo, debe escribir todo lo que alguien ha decidido, con la fecha y una lista de las personas que estuvieron presentes cuando se tomó la decisión. Aún mejor si puede escribir POR QUÉ algo se decidió de la manera en que fue. No importa si es un archivo en su PC, una página en su wiki de intranet o un cuaderno en su escritorio. El registro lo protege a usted y al proyecto: cuando un probador dice que un elemento "falla", puede señalar que se decidió de esa manera con estas personas, y no es su problema sino entre ellos y los probadores. Si esto lleva a que se cambien las especificaciones, entonces está bien, pero en este punto no pueden esperar cumplir con ninguna fecha límite que tenían en mente, o deben cortar el alcance en otro lugar.

Un proyecto sin requisitos claros, liderazgo laxo, sin definición de hecho (DoD), nadie dispuesto a ser responsable de asegurarse de tener la información que necesita para hacer su trabajo de manera oportuna y cumplir con su fecha límite es una receta para el proyecto fracaso.

El desarrollo iterativo no es una mala sugerencia, pero requiere una estrecha cooperación entre los propietarios del producto y los desarrolladores. Intente poner a alguien en el gancho diciendo: "Sabemos que vamos a tener preguntas. ¿Quién puede estar disponible regularmente para asegurarse de que se respondan para que la entrega del proyecto no se demore?" Programe horarios regulares con alguien para revisar el progreso y eliminar los impedimentos. Si no se muestran, o se niegan, entonces haga un seguimiento con correspondencia escrita amable y demoras o no respuestas de los documentos. Si los propietarios del producto no pueden estar disponibles, pídales que proporcionen un representante que pueda estarlo.

Además, otro sello distintivo del desarrollo iterativo es que un cambio en los requisitos requiere un cambio en la línea de tiempo. No puede comprometerse a cumplir una fecha límite si no puede desarrollar una línea de tiempo, y no puede desarrollar una línea de tiempo si no tiene una buena idea de lo que debe hacerse. En lugar de pedir dogmáticamente una especificación, revise la especificación actual, documente cualquier pregunta que usted o el equipo tengan sobre cómo se supone que debe funcionar, programe un tiempo con los propietarios del producto para discutirla y documente las respuestas. Cuando haya terminado, tendrá sus especificaciones basadas en sus decisiones, que luego puede hacer que los propietarios de los productos acepten (por escrito). El propósito de una especificación es eliminar la ambigüedad y crear un DoD, que es exactamente lo que podría proporcionar una sesión de preguntas y respuestas. Si hay oposición a una especificación, no la llame especificación.

No le creas a nadie cuando te digan que será fácil . A veces es realmente tan simple como parece, y podría creer esto si (y solo si ) conozco a los propietarios de los productos lo suficientemente bien como para confiar plenamente en que los requisitos realmente son tan simples como dicen, y las especificaciones que he tenido siempre que se expliquen por sí mismos (si no, programo una sesión de preguntas y respuestas y la documento). He estado en muchas situaciones donde es fácil desde el punto de vista de las operaciones increíblemente difícildesde el punto de vista del desarrollo, o crees que estás totalmente acabado y escuchas las palabras de desesperación ("Oh, por cierto, nos olvidamos de ..."). Ejemplo ... "Todo lo que tiene que hacer es leer estos archivos PDF de un repositorio de documentos", que, durante las pruebas de aceptación, se convierte en "Oh, olvidamos que algunos de estos fueron leídos de lado de una manera completamente inconsistente, y algunos tienen el tamaño de página incorrecto definido, y otros necesitan que se agreguen estas tres páginas, y nosotros necesitamos que todas muestren lo mismo. Eso es realmente fácil de arreglar, ¿verdad? ".

El punto es que podría ser realmente fácil, y una reunión rápida podría confirmarlo, permitiéndole documentar todos los supuestos y obtener la confirmación de que son precisos y correctos. Recomiendo ponerse de pie para eliminar los impedimentos que tiene que escribir un código de trabajo que cumpla con sus expectativas, ya que independientemente de si pisa los pies, alguien probablemente estará infeliz al final de todos modos. Si persiste en obtener respuestas a las preguntas e irrita a alguien, se olvidarán de eso cuando entregue un excelente producto a tiempo que cumpla con los requisitos. Si no obtiene una aclaración y no entrega, nadie recordará que le dijeron que no los molestara.

Sin una especificación, tienes trabajo en equipo. Ve ágil

Siéntese con el PO y desarrolle una pequeña historia de inicio. "Vamos a entregar solo esta pantalla, con solo este botón que dice 'bing!'". Decídase por algunos AC. Entregar la historia. Demuestra la historia. Resulta que los botones deben ser rojos. Levanta un error o una nueva historia. Entregue los botones que van bong y bang. Y así.

En colaboración, especifique y entregue pequeños cortes verticales que se demuestran con frecuencia.

Si el cliente no trabajará con usted de esta manera, busque una salida.

He pasado varios trabajos haciendo proyectos tal como lo describiste. Mientras el PO sepa qué decisiones de diseño está tomando y por qué tiene que tomarlas, debería estar bien. Si, por otro lado, no entienden las decisiones de diseño, debe presionarlas para obtener al menos un documento de prueba de aceptación del usuario por escrito.

Necesita una especificación detallada y verificable antes de comenzar a escribir código. Eso es un hecho, y no hay forma de evitarlo.

Si nadie más está dispuesto a escribir esa especificación, entonces los desarrolladores tienen que escribirla. Entonces obtienes una especificación incompleta. Lo convierte en una especificación completa (que significa "esto es lo que voy a implementar a menos que alguien más me diga que no lo haga"). Usted entrega esa especificación a las partes interesadas y les da la oportunidad de modificar la especificación. Solo una oportunidad para modificar la especificación, sin anular su especificación, por ejemplo, diciendo "No me gusta de esta manera". En ese punto, es su especificación, o pueden proporcionar una especificación diferente, pero no eliminar la especificación.

Puede ser una buena idea obtener una revisión rápida de sus colegas que podrían mejorar la especificación. Pero de todos modos, tiene una especificación, escribe el código en consecuencia, los probadores prueban en consecuencia. Y ha hecho su trabajo: tenía una especificación y la implementó. Si la especificación no es lo que el cliente quiere, es responsabilidad directa del propietario del producto o del cliente que no se molestó en escribir una buena especificación.