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

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

Simplemente cree un prototipo incompleto, solicite comentarios del cliente, realice cambios en función de 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 realmente prefieren este proceso; dado que el cliente siempre es práctico, (eventualmente) obtendrá exactamente lo que quiere.

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

Si lo que dice es verdad 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. Lee los bocetos y la especificación "incompleta" que te han dado.
2. Escriba su propia especificación a un nivel que sea solo suficiente para para poder codificar Puede que tenga que hacer un montón de conjeturas.
3. Muestre su especificación 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 lo ha entendido mal.
4. Repita los pasos 2 y 3 hasta que usted y el cliente estén sincronizados.
5. Ahora tienes una especificación adecuada.

Si su cliente tenía razón cuando dijo "será fácil", entonces este ejercicio debería ser un pedazo de pastel.

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 le comunicará que estaban equivocados (sin que usted tenga que señalar con el dedo o discutir) Ya que estará justo delante de ellos y obvio. Además, sus especificaciones servirán como una excelente herramienta de discusión para resolver esas ambigüedades y servirán como un registro de decisiones clave a medida que las revise con sus comentarios.

El propietario del producto te entregó un prototipo; Devuélvele mejores (hasta que termines)

Parece que te han proporcionado un prototipo de papel para comenzar el proyecto. Ese no es un comienzo terrible. Le sugiero que se comunique con el propietario de la empresa en el mismo idioma , proporcionando prototipos con capacidad progresiva.

Sus prototipos deberían comenzar con el papel, pasar a las maquetas digitales y luego construirse con tecnologías "reales".

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

  

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

Es posible que también desees proporcionar una especificación formal, especialmente si sigues preocupado por que te culpen por un mal resultado. Pero probablemente obtendrás más comentarios de los prototipos.

Cumple con 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, la 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 flexible es algo nuevo para su empresa, es probable que sus evaluadores se encuentren más perdidos que usted y que busquen orientación en usted . Tienes que conseguir algo de su tiempo al principio del proceso. Hágale saber a su jefe que está tratando de ayudarlo a proporcionar una prueba significativa sin recibir los criterios de aceptación formal.

Averigüe si los evaluadores tienen algo firme que deban proporcionar, como documentación de prueba de prueba, que pueda "volver a consultar".

Pruebe Probar primero el diseño

Dado que no tiene requisitos formales, obtener casos de prueba para desarrollarse proporcionaría cierta estructura.

Familiarícese con Test First Design y / o desarrollo impulsado por pruebas y proporciona orientación a sus evaluadores sobre el proceso según sea necesario. Para un proyecto rápido como este, no necesita convertirse en un experto en el proceso. Pero el uso de una metodología probada se reflejará bien en usted y en 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.

Comunicar, pero no molestar

Sugeriría enviar un correo electrónico al propietario del producto por día. Solo envía 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 necesitarán acceder a ella con dispositivos móviles? En este momento, estamos asumiendo que este será un sistema de escritorio / computadora portátil únicamente.

No te asustes

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

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

Un proyecto es el acto de reducir la incertidumbre hasta que se logre la certeza :

• Siempre hay cierto grado de incertidumbre al principio. A veces es un poco ambigua en los requisitos. A veces, son muy esquemáticos. Tendrás que trabajar como parte del trabajo.
• El truco es reducir iterativamente esta incertidumbre (combinando análisis, diseño e implementación), refinando las historias de usuario & implementando su sistema
• Los casos / escenarios de prueba, y los criterios de aceptación deberán ser aclarados 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 adapta a sus necesidades y puede ser utilizado.

Ese es el principio de la 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.

¿Esto es un problema?

Cuanto más incompletos son los requisitos iniciales, mayor es la incertidumbre y mayor es el tiempo necesario para realizar las tareas. Así que solo es 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á sujeto de una negociación. Y el cliente debe aceptar una participación adicional (el argumento principal será "entrada de basura, salida de basura", aunque le recomiendo encarecidamente que la presente de una manera más diplomática ;-))

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

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

Además, otra característica 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 funciona, programe un tiempo con los propietarios del producto para discutirlo y documente las respuestas. Cuando haya terminado, tendrá sus especificaciones basadas en sus decisiones, que luego puede hacer que los propietarios del producto acepten (por escrito). El propósito de una especificación es eliminar la ambigüedad y crear un DoD, que es exactamente lo que una sesión de preguntas y respuestas podría proporcionar. 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 realmente es tan simple como parece, y puedo creer esto si (y solo si ) Conozco a los propietarios del producto lo suficiente como para confiar completamente en que los requisitos realmente son tan simple como dicen que son, y las especificaciones que me han proporcionado son autoexplicativas (si no, programo una sesión de preguntas y respuestas y la documento). He estado en demasiadas situaciones en las que fácil desde el punto de vista de las operaciones es increíblemente difícil desde 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 se leyeron de forma totalmente inconsistente, y algunos tienen el tamaño de página incorrecto definido y otros necesitan que se agreguen estas tres páginas, y necesitamos que todos se muestren igual. Eso es realmente fácil de arreglar, ¿no? ".

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

" No hay reuniones programadas regulares ". Bueno, ¿por qué no comienza por programar reuniones regulares ? 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 contradictorios que DEBEN ser discutidos en persona con todos los interesados presentes.

Además, realmente, realmente, realmente recomiendo que mantenga un registro de decisiones detallado . Como mínimo, escriba todo lo que alguien haya decidido, con la fecha y una lista de las personas que estuvieron presentes cuando se tomó la decisión. Aún mejor si puedes escribir POR QUÉ se decidió algo así. No importa si se trata de 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 "falla" un elemento, puede señalar que se decidió así con estas personas, y no es su problema sino entre ellos y los evaluadores. 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 recortar el alcance en otro lugar.

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

Siéntate con el PO y completa una / algunas historia / es pequeña / s inicial. "Vamos a entregar solo esta pantalla, con solo este botón que dice 'bing!'". Establecerse en algunos CA. Entregar la historia. Demuestre la historia. Resulta que los botones deben ser rojos. Levanta un error o una nueva historia. Entregar los botones que van bong y bang. Y así.

Especifique y entregue colaborativamente pequeños segmentos verticales que se demuestran con frecuencia.

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

He pasado varios trabajos haciendo proyectos tal como lo describiste. Siempre que la OP 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 poder 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. Así que obtienes una especificación incompleta. Lo conviertes en una especificación completa (lo que significa que "esto es lo que voy a implementar a menos que alguien 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 anularla, por ejemplo, diciendo "No me gusta de esta manera". En ese momento, 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 evaluadores realizan las pruebas correspondientes. Y has hecho tu trabajo: tenías una especificación y la implementaste. Si la especificación no es lo que quiere el cliente, esa es directamente la responsabilidad del propietario del producto o del cliente que no se molestó en escribir una buena especificación.