Bueno todo el dia. Fue el turno de hablar sobre el diseño de proyectos. Según mi propia experiencia, sé que a veces es más difícil crear un proyecto desde cero que ordenar lo que ya está allí. Esto se debe en gran medida al legado que usted o usted deja atrás. En este artículo trataré de decirle a qué vale la pena prestar especial atención y sugerir un breve plan para seguir.
Comprensión del proyecto.
Antes de planificar algo, debe comprender qué proyecto debe implementar. Para mí, he identificado varias categorías de proyectos, tales como:
- Una embarcación única es un proyecto destinado a crear algún tipo de concepto gráfico y su posterior venta a los inversores. Las características distintivas de este tipo de proyecto son:
- Documentación insana. La idea básica es clara, pero los casos de negocios están en completo caos, y no hay agujeros lógicos que considerar.
- Plazos Hasta 3 meses desde la redacción de la documentación hasta el prototipo.
- No hay planes de desarrollo y no se planea más apoyo.
- Pequeño equipo Por lo general, hasta 5 personas, incluidos los diseñadores.
- Falta de procesos de negocio. Toda interacción es caótica, basada en la comunicación interpersonal, la aclaración de puntos clave y / o inventar sobre la marcha.
- Los roles son borrosos. No existe una división clara de poderes y áreas de responsabilidad.
- No hay datos reales. Todos los datos se generan para "belleza" y se adaptan para la mejor visualización.
- Para acelerar el desarrollo, las dependencias externas se utilizan en su totalidad.
- Un inicio es un proyecto que está configurado para implementar una idea específica, con desarrollo posterior. Por lo general, estos proyectos se desarrollan de acuerdo con un modelo en espiral y, por esta razón, tienen casi las mismas características distintivas que el primer tipo (embarcación de una sola vez):
- Desglose claro en etapas. Mínimo: términos y una lista de funcionalidades que deben implementarse en un período de tiempo determinado.
- Documentación relativamente sana. Análisis realizados, puntos de referencia para las etapas de finalización establecidas, los refinamientos a menudo llegan durante el sprint. La mayoría de las veces usa cascada, a pesar del hecho de que Agile afirmó.
- Plazos medios para la funcionalidad principal. En promedio, de 6 a 12 meses.
- En las etapas iniciales, se utilizan dependencias externas, que eventualmente cambian a su propia implementación.
- Pequeño equipo Por lo general, hasta 7-10 personas.
- Hay una separación de roles, pero la responsabilidad es borrosa.
- Un proyecto puede mutar. En una etapa, el concepto o enfoque de implementación puede cambiar. Por lo general, esto se debe a los requisitos de los inversores, una idea inicialmente fallida o errores en la arquitectura.
- Condicionalmente datos en vivo. Ejecutar en grupos focales o analizar datos en vivo de recursos de terceros. Es cierto que esto no siempre sucede ...
- Un sistema de información es un proyecto que implementa una idea con planes de integración en servicios de terceros.
- Hay un plan de desarrollo.
- Documentación claramente escrita. Mínimo: descripción de la API documentada.
- Es posible que deba integrarse con servicios de terceros, instalar muletas o reconstruir partes del sistema.
- Hay versiones intermedias, correcciones urgentes.
- Equipo mediano Por lo general, de 10 a 20-30 personas.
- Clara separación de responsabilidades.
- Requisitos de seguridad: después del análisis, se crean casos que pueden conducir al colapso del sistema.
- Se dedica tiempo a las pruebas.
- Utilizado por Agile.
- Casi siempre hay un atraso.
- Solo se utilizan dependencias externas que son costosas de implementar por sí mismas. Se practica a la par de los propietarios.
- Un sistema cerrado es un proyecto voluminoso diseñado para satisfacer las necesidades específicas del Cliente, con un mayor refinamiento.
- Cliente específico
- Hay un plan de desarrollo.
- Documentación de diseño para desarrollo. Para ayudar a los usuarios, se ha escrito documentación separada a pedido del Cliente.
- Diferenciación de derechos de usuario.
- Casi siempre hay un atraso.
- El tamaño del equipo suele ser mayor que el promedio. Como regla general, de 10 personas a una pérdida de frecuencia cardíaca.
- Utilizado por Agile. De vez en cuando, llegan tareas adicionales que deben implementarse a toda costa.
- Demostraciones inesperadas. Las demandas tienen lugar a petición de la alta dirección, por lo que un circuito de prueba viable nunca será redundante.
- La solución Saas es un proyecto voluminoso con una configuración flexible y una mayor personalización para un cliente específico.
- Sistema multimodular. El sistema está dividido en varias partes. Que se puede usar individualmente, incluso fuera del alcance de un proyecto específico.
- Planificación clara Mínimo: los costos laborales se estiman para la implementación de características. El tiempo está establecido para la modernización y refactorización.
- Documentación volumétrica. Casi todo se describe, por regla general, incluidos los casos de prueba.
- Como regla general, no hay dependencias externas y se escriben sus propias implementaciones de las partes del sistema. Incluso si hay implementaciones de terceros.
- Varios equipos de desarrollo. Todos son responsables de su parte del desarrollo, ya sea de respaldo o de frente.
- Prueba de cobertura de todo y de todo. Se utilizan pruebas de auto, unidad, regresión e integración.
Todas las gradaciones son condicionales y los tipos fluidos se encuentran con mayor frecuencia. Quiero señalar que todos los tipos pueden mutar entre sí, el único matiz está en el costo de la modernización. Por ejemplo, el proyecto fue originalmente una "embarcación de una sola vez", y luego se convirtió en un "sistema cerrado". Por lo general, esto lleva a una reescritura completa o casi completa del sistema o su refactorización. Como saben, esto no es económicamente factible. Por la misma razón, es aconsejable comprender qué tipo de proyecto necesita crear desde cero y tratar de determinar su destino futuro.
Para determinar el tipo de proyecto, a continuación he formulado preguntas, después de haber recibido una respuesta a la que le quedará claro lo que quieren de usted:
- ¿El propósito del proyecto?
- ¿Una lista completa de lo que debe implementarse?
- ¿Hay alguna documentación?
- ¿Cuáles son los plazos? Fechas precisas son deseables.
- ¿Se planea la interacción externa con sistemas de terceros o el proyecto tendrá una API externa?
- ¿Hay algún desarrollo?
- Tamaño del equipo?
- ¿Quién es responsable de qué? Quién establece tareas, quién acepta, quién tiene derechos de veto.
- ¿Hay planes de desarrollo y cuáles son?
- Quien es el cliente?
- ¿Existe un presupuesto para la compra de soluciones llave en mano?
- ¿En qué metodología planeas trabajar?
- ¿Hay análogos?
Como puede ver, la lista no es tan grande. Sin embargo, por alguna razón desconocida, pocas personas hacen esas preguntas antes de comenzar a hacer nada. Me preguntas por qué debería entender el tipo de proyecto. ¿Siempre tienes que hacer que el proyecto viva para siempre? En general, tienes razón, pero hay matices, como en una broma hirviente. Estos matices son recursos y líneas de tiempo. No olvide que trabajamos por el bien de los negocios y llevamos a cabo las tareas. Cuando conoces el tipo de proyecto, puedes sacrificar algo sin una punzada de conciencia para lograr tus objetivos.
Selección de tecnología
En la elección, es mejor cumplir con la regla: la tecnología no debe ser una supernova, sino también obsoleta. Si la tecnología o el marco es nuevo, esto puede ocasionar problemas como:
- Busque personal calificado
- Perspectivas para el desarrollo: en las primeras etapas, el desarrollo puede morir o, por el contrario, si la tecnología es antigua, entonces los errores deberán ser curados por nosotros mismos.
- Falta de soluciones llave en mano para las nuevas y falta de actualizaciones para las antiguas.
Esta lista de problemas es relevante no solo con respecto a la tecnología, sino también a las dependencias de terceros. Todo lo anterior puede enterrar el proyecto de raíz.
Antes de elegir algo específico, piense algunas veces. Cree una tabla notoria de beneficios con factores de importancia para el proyecto.
Este ejemplo es para un proyecto ficticio:
El nombre de la funcionalidad del proyecto.
| Ratio de Importancia del Proyecto
|
|---|
Trabajar con formularios
| 3
|
Enrutamiento
| 1
|
Facilidad de escribir animación
| 0,3
|
Como se puede ver en la tabla, los criterios importantes para la selección son "trabajar con formularios" y "enrutamiento". La simplicidad de crear animación para este proyecto no es significativa. A continuación, actualizaremos la tabla agregando nuevas columnas tecnológicas. En nuestro caso, habrá dos.
El nombre de la funcionalidad del proyecto.
| Ratio de Importancia del Proyecto
| Tecnología 1
| Tecnología 2
|
|---|
Trabajar con formularios
| 3
| +
| ±
|
Enrutamiento
| 1
| +
| ±
|
Facilidad de escribir animación
| 0,3
| +
| -
|
Según los datos de la tabla, entendemos que el trabajo de "Tecnología 2" con formularios y enrutamiento es poco convincente, y crear una animación es como llamar a Satanás. Como resultado, el peso específico de esta tecnología es 2. Usted pregunta por qué 2? ¡Todo es simple! Si configura ±, entonces en esta tecnología implementaremos un funcional específico, pero con algún tipo de "muletas", o más laborioso. En nuestra comparación, "Tecnología 1" será más rentable, con un total de 4.3. Creo que la explicación sobre la formación de las cantidades es innecesaria. Esta tabla funciona no solo con tecnología, sino con todo lo que requiere comparación y selección de la lista. Lo principal es no olvidar que cuanto más criterios escriba, más fácil será elegir.
Arquitectura
Actualmente, es posible elegir entre una variedad de servicios diferentes que proporcionan herramientas para el diseño arquitectónico. Es cierto que cualquiera de ellos tiene inconvenientes, para algunos son críticos, pero para alguien no. Como soy "oldfag", prefiero un trozo de papel y un bolígrafo o una pizarra y un marcador.
Para entender qué tomar en primer lugar, debe delinear las partes principales del sistema y luego elegir la forma de construir la arquitectura. Como regla, en la práctica, solo se usan tres:
Descendente : los desarrolladores empujan desde los nodos grandes del sistema y van a los más pequeños. El significado de la arquitectura es que los componentes prioritarios son nodos grandes que contienen otros más pequeños.
Ascendente : los desarrolladores empujan desde piezas pequeñas y van a piezas más grandes. El significado de la arquitectura es que al principio se crean muchos componentes pequeños, y los más grandes ya se ensamblan a partir de ellos.
El monolito es una arquitectura indivisible, a menudo denominada "legado". De hecho, esta es una estructura rígida, cuyo cambio requiere soluciones sin "muletas". Esta es la peor opción, pero, como todo en nuestro mundo, tiene derecho a existir. El monolito se usa para implementar funcionalidades específicas y no planea mantenerlo en el futuro. En comparación con otros, la velocidad de este enfoque es muchas veces más rápida. Bueno, solo porque puedes cerrar mucho los ojos.
La elección de la arquitectura depende de los objetivos del proyecto y la velocidad de desarrollo. Por lo general, el primer método se usa cuando los plazos no se están agotando y la cantidad de módulos grandes es pequeña. Su característica es que es posible representar con precisión la relación entre módulos específicos. De los inconvenientes, puedo notar un largo tiempo de desarrollo asociado con una secuencia de acciones.
Se prefiere el segundo método cuando se requiere una alta velocidad de desarrollo y no se comprende la arquitectura de nivel superior. Una característica son los muchos componentes pequeños que a veces se usan en diferentes unidades grandes. Vale la pena señalar que casi todo el desarrollo se puede realizar en paralelo, sin tener en cuenta otras tareas. Las desventajas de este enfoque serán los componentes que no cumplan los requisitos de la arquitectura de nivel superior y, en consecuencia, deberán reescribirse o crear la posibilidad de personalización.
Como muestra la práctica, todas las técnicas de desarrollo se reducen a un enfoque espiral, caracterizado por una acumulación gradual de funcionalidad. No considero apropiado considerarlo dentro del marco de este artículo.
Planificacion
El llamado "Mapa de Ruta" lo ayudará a hacer su trabajo de manera más eficiente. De hecho, este es un cronograma, con fechas límites condicionales para la entrega de un funcional en particular. Las fechas pueden posponerse, pero, como lo demuestra la práctica, con la implementación adecuada de los puntos anteriores, la enmienda será de hasta el 30%. En la práctica, esto suele ser del 10-15%. La planificación le permitirá realizar un seguimiento del progreso del proyecto, ver la flacidez, realizar ajustes en forma de recursos o un cambio en los plazos, etc.
Por lo que luego te lo agradecerán
Cualquier proyecto comienza con documentación, y cuanto más sea, ¡mejor! Así que no seas perezoso: documentamos TODO. Sí, llevará algún tiempo, pero posteriormente puede salvarte de la ira de los líderes si algo sale mal, no es tu culpa. Además, no olvide que después de aparecer en el proyecto, las personas tendrán que entender lo que ha creado. Y sin documentos, esto no será fácil.
Conclusiones
Este artículo describe cómo actuar y qué buscar al comenzar un proyecto. Estas etapas son universales para el frente, la espalda, las pruebas o todas juntas. Deliberadamente evité los detalles de la tecnología, para no ser engañoso.
Cuando tiene la opción de elegir qué pila de tecnología usar, arquitectura y necesita determinar el marco de tiempo para el proyecto, la siguiente tabla puede ayudarlo:
Tipo de proyecto / características
| Embarcaciones desechables
| Inicio
| Sistemas de información
| Sistemas cerrados
| Soluciones Saas
| Algunos otros proyectos
|
|---|
No. de personas menores de 5 años
| | X
| X
| X
| X
| |
Número de personas de 7 a 10
| | | | | | |
Número de personas de 10 a 30
| X
| | | | | |
Cantidad superior a 30
| X
| X
| | | | |
Fecha de finalización hasta 3 meses.
| | X
| X
| X
| X
| |
Plazo de entrega de 6 a 12 meses.
| | | | | | |
Período de más de 12 meses.
| X
| | | | | |
La documentación
| | | | | | |
Requisitos de integración con otros sistemas.
| | | | | | |
Cliente específico conocido
| | | | | | |
Apoyo adicional planeado
| | | | | | |
Planificacion
| | | | | | |
Los roles están claramente delineados
| | | | | | |
Dependencias externas permitidas
| | | | | | |
Hay datos en vivo para pruebas y análisis.
| | | | | | |
Requisitos de seguridad
| | | | | | |
Prueba requerida
| | | | | | |
Requiere documentación del producto o instrucciones
| | | | | | |
Implementación modular requerida
| | | | | | |
Varios equipos de desarrollo.
| | | | | | |
Total
| | | | | | |
Cómo usar la tabla, creo que todos ya lo han adivinado, pero por si acaso, exactamente lo mismo que con la anterior, solo con una pequeña adición en forma de celdas rellenas. Significa que el valor no se puede usar para este proyecto. Además, tenga en cuenta que la tabla puede estar incompleta, agregue las filas que considere necesarias.