Trabajo para una pequeña empresa basada en productos. Estamos a punto de reescribir nuestro producto existente desde cero. Estamos planeando adoptar una metodología ágil para nuestro desarrollo. Ahora mi pregunta es, ya que tenemos todos los requisitos incluso antes del inicio del proyecto (ya que estamos reescribiendo el producto existente), ¿vale la pena sumergirse en el mundo Ágil? ¿Agile no es más útil cuando no tienes todos los requisitos por adelantado y los obtienes por fases?

En segundo lugar, digamos que si saltamos a Agile, ¿cuál es la mejor práctica para diseñar una base de datos? Digamos que en nuestra primera iteración simplemente creamos un sistema de inicio de sesión (el usuario puede iniciar sesión, cerrar sesión, etc.). ¿Solo necesitamos crear una tabla de usuarios sin preocuparnos por otras tablas? ¿Y otras tablas evolucionarían a medida que nuestro producto progresara?

¿Vale la pena sumergirse en el mundo ágil?

Si.

¿No es más ágil más útil cuando no tienes todos los requisitos por adelantado y los obtienes por fases?

Falso.

Cuando no tiene todos los requisitos, es la única forma de progresar. Cualquier otra cosa requiere suposiciones imaginarias que eventualmente se demostrarán falsas. Agile simplemente hace menos suposiciones imaginarias.

Cuando tenga todos los requisitos, debe todavía seguir todos los principios ágiles.

Lea esto antes de continuar: http://agilemanifesto.org/

Todos estos puntos son verdaderos, no importa cuánto sepa de los requisitos.

Aún se beneficia al usar un método ágil como Scrum, porque tendrá expectativas más realistas.

¿Cuál es la mejor práctica para diseñar una base de datos? Digamos que en nuestra primera iteración simplemente creamos un sistema de inicio de sesión (el usuario puede iniciar sesión, cerrar sesión, etc.).

Qué terrible primera iteración.

¿Solo necesitamos crear una tabla de usuarios sin preocuparnos por otras tablas? ¿Y otras tablas evolucionarían a medida que nuestro producto progresara?

Si. Crea la base de datos de forma incremental.

Haces todo de forma incremental.

Prioriza según lo que crea el mayor valor para los usuarios . Consideraciones técnicas no fantasiosas (y tontas).

Ahora mi pregunta es, ya que tenemos todos los requisitos incluso antes del inicio del proyecto (ya que estamos reescribiendo el producto existente), ¿vale la pena sumergirse en el mundo Ágil?

Sí, aunque me imagino que es probable que haya más de unos pocos cambios posibles en la forma en que la aplicación está diseñada actualmente, ya que este sería el momento de limpiar varias deudas técnicas para tener un diseño más limpio dada la información conocida ahora.

¿No es más ágil más útil cuando no tienes todos los requisitos por adelantado y los obtienes por fases?

¿Qué tan seguro está de que esos requisitos no cambiarán cuando vuelva a compilar la aplicación? ¿Estás seguro de que el diseño que se está tomando nunca será refactorizado?

En segundo lugar, digamos que si saltamos a Agile, ¿cuál es la mejor práctica para diseñar una base de datos? Digamos que en nuestra primera iteración simplemente creamos un sistema de inicio de sesión (el usuario puede iniciar sesión, cerrar sesión, etc.). ¿Solo necesitamos crear una tabla de usuarios sin preocuparnos por otras tablas? ¿Y otras tablas evolucionarían a medida que nuestro producto progresara?

Hay muchas opciones diferentes aquí. Haz lo suficiente para que funcione. Si la tabla de usuarios es todo lo que se necesita, genial. Si hay algunas otras tablas que alguien quiere tener para que la base de datos esté en una forma más normalizada, eso puede hacer que sea mejor hacerlo. No será perfecto la primera vez y Agile se trata de una metodología de prueba y arreglo, ya que una vez que muestre lo que tiene, el usuario a menudo tendrá comentarios que es lo que mantiene a Agile yendo y viniendo ... (También donde está el nuevo los requisitos vendrán ya que la gente puede comenzar a pedir cosas también)

Trabajo para una pequeña empresa basada en productos. Estamos a punto de reescribir nuestro producto existente desde cero. Estamos planeando adoptar una metodología ágil para nuestro desarrollo. Ahora mi pregunta es, ya que tenemos todos los requisitos incluso antes del inicio del proyecto (ya que estamos reescribiendo el producto existente), ¿vale la pena sumergirse en el mundo Ágil?

Una pequeña empresa (administración) que está planeando usar prácticas ágiles está en una excelente posición de partida, ya que sus desarrolladores suelen impulsar la adopción. Le recomendaría que identifique líderes dispuestos a continuar impulsando la adopción a nivel de equipo (capacitación, institucionalización, etc.)

Con los requisitos en la mano, pregunte a sus usuarios qué les gustaría ver en una iteración. Luego, entrégalo. Hazlo de nuevo la próxima iteración y otra vez. Los usuarios que puedan tocar su trabajo temprano ayudarán a refinar los requisitos a medida que avanza. Si no cuenta con procesos automatizados en este momento o si el equipo no comprende el desarrollo continuo, programe el tiempo para asegurarse de que lo hagan.

Agile es aplicable para cualquier proyecto de desarrollo, y no específicamente para proyectos greenfield completos que aún no tienen ningún requisito especificado. La gestión ágil de proyectos hace que su proyecto sea ​​de autoaprendizaje y de superación personal al dar pequeños pasos, revisar sus pasos con frecuencia y mejorar sus próximos pasos. Hay muchos blogs en Agile. Google es tu amigo ...

Con respecto a su pregunta específica sobre el desarrollo de bases de datos ágiles, está en el camino correcto. Puede desarrollar la gestión de usuarios sin preocuparse por el resto al principio. Eso probablemente terminará en algunos cambios cuando avance en el proyecto, pero eso puede considerarse un costo de hacer una pequeña iteración enfocada. Algunos enfoques intermedios investigarían su modelo de base de datos un poco más por adelantado y realizarían un diseño que pudiera funcionar unos pocos sprints más adelante. De esa manera, tendrá menos retrabajo.

En segundo lugar, digamos que si saltamos a Agile, ¿cuál es la mejor práctica para diseñar una base de datos? Digamos que en nuestra primera iteración simplemente creamos un sistema de inicio de sesión (el usuario puede iniciar sesión, cerrar sesión, etc.). ¿Solo necesitamos crear una tabla de usuarios sin preocuparnos por otras tablas? ¿Y otras tablas evolucionarían a medida que nuestro producto progresara?

Tenga cuidado al exagerar este enfoque. Puede ser como construir una casa y tratar de terminar un baño por completo mientras la base aún se está asentando. Lo más probable es que tenga que rehacer completamente partes significativas de su trabajo si la base de su aplicación, la base de datos y el modelo de objeto subyacente no son lo suficientemente maduros o estables como para soportar la estructura.

Además, recuerde que decir que está usando Agile / Scrum no lo exime de usar buenas prácticas de ingeniería de software, como pruebas de unidades adecuadas y bases de datos sólidas y diseño de objetos. Cuando Agile se aplica incorrectamente, puede caer fácilmente en un código y arreglar un proyecto de espiral de muerte que puede ser muy doloroso o incluso imposible de recuperar.

Agile tiene que ver con una mayor productividad y flexibilidad . ¿Por qué estás reescribiendo tus aplicaciones? Las razones pueden ser:

1. Cambiar la plataforma (de Windows a Linux, por ejemplo)
2. Cambiar el idioma (por ejemplo, de ASP.NET a PHP)
3. La cantidad de refactorización es tan alta que hace que la reescritura sea una opción de ahorro
4. El negocio ha cambiado mucho, por lo tanto, en realidad estás creando una nueva aplicación (una nueva canción, basada en el mismo tema, si lo deseas)

En cualquiera de estos motivos, no entregará su producto de la noche a la mañana y, por supuesto, llevará tiempo.

Tener una acumulación de productos es solo uno de los elementos que recomienda ágilmente. Lo que dice acerca de conocer todo el negocio significa que ya tiene muchos PBI en la cartera de pedidos de su producto.

¿Pero no es mejor que entregue partes de su nuevo producto al final de cada sprint? ¿No te hará más ágil y receptivo a los cambios? Por ejemplo, imagine que está tratando de hacer que la nueva aplicación sea hermosa. ¿No es malo saber después de 10 meses que su nuevo diseño no es aceptable? ¿No sería una buena práctica si se lo informan después de 2-3 semanas al respecto?

Mi respuesta a tu pregunta es:

El desarrollo ágil definitivamente tiene muchas cosas que ofrecer, incluso para aplicaciones reescritas.

¿Vale la pena sumergirse en el mundo ágil?

Tal vez. Probar algo nuevo puede ser arriesgado, especialmente si es nuevo para todos. Personalmente, encuentro que Agile es útil cuando se hace bien .

¿No es más ágil más útil cuando no tienes todos los requisitos por adelantado y los obtienes por fases?

Puede ser útil para ayudar a impulsar los requisitos si aún no los tiene. Sin embargo, eso no significa que su utilidad se limite solo a los requisitos de manejo.

¿Cuál es la mejor práctica para diseñar una base de datos?

Iterativamente Usar migraciones de bases de datos.

Sugerencias

• Si quieres hacer Agile, eso es genial. Trataría de conseguir a alguien que lo haya hecho antes para que te ayude en el proceso.

• Las personas a menudo ignoran el paso de refactorización cuando prueban Agile por primera vez. No haga. Matará el proyecto.

• Piense en sectores verticales (entidades) en lugar de capas. Implemente cortes verticales para que tenga un sistema en funcionamiento después de que se realice la primera tarjeta de características. Una vez que esté funcionando, manténgalo funcionando y solo agregue con cada tarjeta de función.

Hemos estado usando Agile en un proyecto que implica pasar de una aplicación anterior a un nuevo conjunto de aplicaciones y una nueva arquitectura. Nuestra situación es un poco diferente en el sentido de que estamos tratando no solo de rehacer la aplicación existente (utilizada internamente por nuestros departamentos de ventas, finanzas, abastecimiento y almacén), sino que estamos tratando de mejorar la experiencia de cada departamento en el camino. Un desafío que hemos visto usando Agile es que el valor comercial para mover partes de la funcionalidad para una unidad comercial dada es alto, pero otras partes son bajas. Por lo tanto, nos encontramos creando nuevas aplicaciones y manteniendo la antigua aplicación ejecutándose mientras hacemos la transición. Estamos teniendo problemas para que la empresa vea el valor de concentrarse en trasladar a un "cliente" a una aplicación completamente nueva. Sin embargo, estamos recibiendo muchas historias de alto valor en nuestros sprints. Creo que pronto vamos a llegar a una pinta pronto, cuando tengamos que convencer al negocio de que debemos centrarnos en una unidad a la vez.

Entonces, para responder la pregunta original, sí, ágil es un buen camino a seguir. Esté preparado para que surjan algunas dependencias y guíe algunas de las decisiones de los equipos en el camino.

Lo más importante es que el proceso de scrum te será útil. Quiero decir, si tu trabajo será mejor, solo tómalo. Pero nunca lo sabrás a menos que lo pruebes.

Otro punto es que no hay necesidad de tomar el proceso scrum por el libro. Solo toma cosas que te funcionen. Nuestro equipo, por ejemplo, no tiene una tabla scrum. Porque no lo necesitamos.

En cuanto al diseño, debe intentar diseñar de tal manera que los cambios futuros no requieran mucho tiempo. Su sistema debe ser robusto.