Amigos, buenas tardes!
Continuamos una serie de publicaciones "sin cortes" sobre proyectos relacionados con el desarrollo, a menudo con el prefijo "web". Hoy hablaremos sobre cómo evaluar de manera más adecuada y rápida el trabajo y planificar las versiones del sistema de software. Lo más probable es que los gerentes novatos y los desarrolladores enérgicos y egoístas se sorprendan con las recomendaciones, pero, créanme, el objetivo es uno y único: ayudarlos y convertirlos en un verdadero Jedi, lo que brinda el beneficio de la compañía, mueve proyectos y desarrolla personas al mismo tiempo. Como un Jedi que sinceramente no merece ser descubierto como una momia en la oscura sala de servidores entre los bastidores con servidores web y las bases de datos de un proyecto web que vuela hacia el futuro sin un código documentado, TK solo está usando energía pura "HZ". ¡Entonces vamos!
Rendimiento y análogos cercanos
Es importante, extremadamente importante, especialmente para el poder clave del proyecto: desarrolladores, excelentes especialistas, que cambian sus habilidades diariamente en IDE modernos, para comprender que la falta de sentido común en la evaluación del trabajo comienza incluso antes del deseo de "concebir una idea". Esto sucede especialmente a menudo en el desarrollo web, donde durante la licitación es necesario tomar y pretender que el problema politizado del pollo y los huevos tiene una "solución estricta":
- El cliente aún no sabe lo que quiere, o lo sabe de manera muy vaga y contradictoria (es decir, no lo sabe, ¡pero realmente lo quiere y, lo más importante, a tiempo!)
- El cliente quiere que los ingenieros calculen el costo "Todavía no sé qué" y se ofende si realmente no entran en esta evaluación
- El cliente quiere que los ingenieros se ajusten a los plazos y lancen "No sé qué", digamos, el 1 de septiembre, y que, por supuesto, "Todavía no sé qué" no tuvo errores
- El cliente a menudo delega la aclaración de los detalles "No sé qué" debajo de la jerarquía a los empleados que, sorprendentemente, comienzan a jugar "a las escondidas", se ríen, barajan una pierna, cierran la puerta y tiran de la goma.
Será un poco más fácil si encuentra analogías cercanas del extraño rendimiento descrito anteriormente en el entorno:
- hermoso cortejo masculino de una mujer antes ... enfrentamiento doméstico en la cocina
- comprar papas en el mercado
- adivinación, astrología, numerología
- Sacrificios a Cthulhu, etc.
Está claro que aún no se ha vuelto más fácil, especialmente si recuerdas que la actuación a menudo es atendida por "psicólogos certificados" en ambos lados, que saben cómo verse convincentes, decisivos, diciendo "¡sí, por supuesto que lo haremos!" y no entiendo los principios básicos del desarrollo de software. Y si recuerda que a veces "parecer confiado" en ambos extremos del proyecto cruza la línea del frente, se fraterniza, se une y comienza a indignarse sinceramente por exigir algo concreto de los ingenieros, sin proporcionar respuestas claras y formalizadas a preguntas claramente planteadas ... - Realmente quiero ir a vacaciones académicas en la Antártida y olvídate, abrazando a los pingüinos y al agua fría, pero no menos hermoso de esto, sirenas :-)
Empuje de amor
Es bastante doloroso para los ingenieros percibir de manera sobria y analítica el desempeño descrito anteriormente, hasta que sangran de los ojos, por lo que toman varios pasos psicológicos bien conocidos que acercan el trabajo concreto y real:
- Necesito sonreír el uno al otro
- Debo decir que sí, incluso si NO hay confianza
- Necesito prometer ayudarnos unos a otros
- ¡Necesitas tocar tu pecho (como KinKong) y demostrar confianza!
Tengo que jurar amor a la tumba
Pero hablando en serio, en esta etapa, todos los miembros del equipo del proyecto deben ser muy claros acerca de:
- que todavía tenemos que descubrir los detalles y un montón de pop-ups interesantes e inesperados, pero como ya se han sonreído, todo saldrá bien
- si se le asigna un plazo, entonces debe desentrañar el desorden emocional lo antes posible, descubrir y comenzar a hacer las cosas más importantes de manera negativa y siempre no se hará algo, y eso es correcto
- cuanto más desorden emocional y político al principio, más tiempo se debe asignar a la fase de análisis y diseño
En total, al final de la presentación, debe haber un empuje seguro hacia el futuro desconocido, y de buen humor, vigoroso y deseo mutuo de escucharse y escucharse mutuamente.
Proyectos nacidos muertos
Desafortunadamente, a veces, literalmente, de inmediato hay un entendimiento de que el proyecto que se está lanzando ... nadie lo necesita, se contrae, se congela y será arrojado al archivo:
- El proyecto no tiene un objetivo claro y carismático. Solo necesita hacer algo, porque no está claro qué hacer más importante. Por lo tanto, debe hacer al menos ALGO, luego pagar un salario; debe haber una razón :-)
- Se están haciendo intentos para no encontrar los "motores" del equipo del proyecto, personas enérgicas que se inspiran a sí mismas y a los demás y creen en la consecución de la meta, pero buscan a los responsables (de quienes se puede culpar a todo, en caso de problemas). Siente la diferencia.
Tipos de rendimiento efectivo
Es gratificante, pero a menudo, se encuentran los inicios correctos de los proyectos, que se pueden distinguir por los siguientes signos. Apéguese a esta lista e intente ingresar a dichos equipos por las buenas o por las malas:
- Hay una o más personas que están quemando ideas y creen sinceramente en lograr el objetivo. El carisma y la calidez que emanan de ellos permitirán al equipo del proyecto ser flexible y suavizar los malentendidos emergentes y las evaluaciones escasas.
- El cliente tiene una conciencia adecuada de la incertidumbre de sus propios deseos, riesgos y el deseo de conocer a los ingenieros. Se da cuenta de que tiene que esforzarse mucho para pensar y pensar, incluso si usted, como cliente, ya ha pagado por todo.
- Del lado del cliente, hay o ... HAY una comprensión de la necesidad de atraer una masa crítica de "materia gris" en forma de analista (s) adecuado (s) y expertos en la materia que puedan, sin "er ... s ... wow ..." explicar a los ingenieros las sutilezas de la lógica comercial de la próxima proyecto
- Por parte del cliente, existe el deseo de alcanzar los objetivos comerciales lo más rápido y lo más rápido posible. Recuerdo un proyecto en el que un cliente quería y pasaba mucho tiempo en un "panel de administración de proyectos web hermoso y sofisticado" para empleados y extrañaba seriamente las tareas comerciales que yacían en la superficie.
Pero tenga en cuenta: una reunión con un cliente tan capacitado significará para el equipo de ingeniería el descenso del prometido cielo de TI, sudor, trabajo y sangre. Te sorprenderá todo el conocimiento de los patrones de diseño, te enseñarán a escribir código simple inmediatamente sin errores, y en lugar de usar un script en PHP de 20 líneas, rechazarás la fábrica de clases como una tentación demoníaca. Por la mañana, después de servir café, se sorprenderá al descubrir que el cliente, después (¡después!) Su departamento de pruebas, encontró y registró otros 30-40 errores en el rastreador de errores y le recomienda que (¡usted!) Escriba cuidadosamente las pruebas unitarias y cambie el cerebro de los probadores. ... Pero por otro lado, es bueno para bombear :-)
Entonces, ¿cómo evalúa un proyecto de software?
Hablaré directamente Gente razonable, incluyendo los ingenieros entienden que es imposible evaluar lo que aún no se ha inventado ... Uno solo puede mentir con confianza. Pero, como saben, la lógica matemática formal no funciona para todos, por lo que a veces, sin embargo, se encontrarán con interlocutores que afirman que 1 + 1 = 11, y es tan convincente que incluso las lágrimas pueden aparecer en sus ojos.
Pero hay una salida: una analogía. No es por nada que en el enfoque ágil moderno, es la analogía que se utiliza como el ladrillo fundamental de la evaluación. Ejemplos de trabajo de analogías en el desarrollo web:
- Necesitas hacer una tienda en línea típica. Y ya hicimos un par de ellos. Proporcionamos una evaluación ajustada a la adecuación del cliente / experiencia del equipo en forma de un número de Fibonacci.
- Evaluamos la característica en puntos de historia y no en horas hombre. Y tomamos 1 punto de tienda por la complejidad de crear, por ejemplo, un bloque de información con una lista de noticias .
- En ocasiones, puede determinar aproximadamente el tipo de proyecto web por la cantidad de módulos estándar que contiene y el porcentaje de personalización. Si hubo tipos similares de proyectos con conjuntos de módulos similares o cercanos y personalización, puede usar la analogía de forma segura.
- A veces dan una estimación aproximada midiendo el grosor del TS en milímetros. Estoy completamente en serio: vi y, sorprendentemente, funciona.
Es importante utilizar un enfoque con analogía a las calificaciones del equipo:
- Los cuatro arruinaron el formulario de búsqueda durante una semana y luego arreglaron los errores durante 2 semanas. Multiplica el puntaje por 10.
- Este desarrollador puede integrar el sitio con el diseño en una semana. Agregue otros 3 días en la parte superior para un buen comportamiento.
Algo asi. Sí, puede discutir, pero ¿qué pasa con PMBoK, diagrama de Gantt,
Velicity , tarjetas
Kanban , gruesos libros de estimación ágil, aceleración de equipo, métricas, petrikas?
Hablando francamente, no funciona y haré una analogía con el "aprendizaje automático".
Aprendizaje automático y evaluación
Se le enseñarán 50 tipos de matemáticas en la universidad durante 5 años, luego otros seis meses en cursos costosos sobre DataScience y MachineLearning, y luego, en la práctica, de repente descubre que ... no hay un enfoque científico en esta área, debe pasar por todas las opciones para hiperparámetros, solo necesita tiempo nadie dará (días y meses) y queda una búsqueda divina al azar y, lo más importante, la INTUICIÓN. Y no queda nada más que ... volver y comenzar a leer teoría en los cursos. Entonces, con la evaluación del trabajo en proyectos de software, hay muchas teorías, pero solo algunos conocimientos que están involucrados en una intuición profunda y, que es una misma experiencia, el trabajo en la práctica.
Para aprender realmente cómo evaluar la complejidad de la programación, debe salir de las ciudades, vivir con los nativos, comer carne cruda, beber una sangre tibia y pulsante, para estar más cerca de la naturaleza = código, errores, producción de revolcadores, administradores barbudos, dormir un par de noches en la sala de servidores y ... aprender a hacer plátano en lugar de papel higiénico. El minimalismo y el deseo de hacerlo de manera simple y clara, permitirán al equipo obtener calificaciones con mucha más frecuencia y al cliente, volar más rápido. De hecho, debe mencionar e implementar esta cultura de ahorro en el proyecto lo antes posible.
Abusos conocidos
Es gracioso, pero a veces surgen tales abusos de calificaciones que hacen que los ingenieros experimentados solo sonrían:
- Se está escribiendo un enorme TK de 1000 páginas, que comienza a quedar obsoleto y no huele al día siguiente. Nadie lo ha leído hasta el final, pero a menudo se hace referencia a él. Es contradictorio, acuoso, político y no erótico. Pero lo apreciaron, cortaron la iteración, también los evaluaron, y ahora todos están tratando de encajar en este infierno lógico.
- Se crea un gran diagrama de Gantt. Porque los requisitos se discuten y cambian constantemente, el departamento para el movimiento de rayas en el diagrama de Gantt se destaca: se sientan y se mueven todo el día
- Las características se evalúan y almacenan en el buzón. Nadie, excepto el gerente, vio todas las características y calificaciones. El gerente de repente toma puntajes con la vida y el proyecto ... se cierra.
- Hay pizarras y marcadores disponibles, pero los rotuladores son largos o permanentes y escriben algo obsceno en la pizarra durante una comunicación y evaluación ostentosas, resulta imposible borrarlo :-)
Prácticas de evaluación útiles y de trabajo en proyectos de software.
Si lees la publicación hasta este punto, entonces, obviamente, ya no perteneces a la categoría "cuanto más papel, más limpio", "haces la pregunta equivocada", "planteaste el problema no matemáticamente", pero realmente quieres hacerlo proyecto de software en tiempo adecuado y a un precio razonable. Arreglamos las siguientes prácticas realmente funcionales:
- "Simple, medio, difícil". Sí, consultamos con un desarrollador o equipo experto y ponemos una calificación de 3 posibles en cada función en ProductBacklog. Es recomendable pasar por todas las características conocidas del proyecto y dar al menos dicha evaluación. Es posible y necesario, teniendo solo esto en mente, planificar los lanzamientos ya.
- "Planificación de póker". Hay mucha información sobre este tema, pero si garantiza una atmósfera saludable y positiva de comunicación y confianza entre usted, los miembros del equipo y el cliente durante la evaluación, funciona bien.
- "Llama a un amigo". Si tiene una empresa / equipo o, además, un desarrollador experto familiar, hable con él. Desafortunadamente, a veces los equipos conspiran e intentan alargar el tiempo; un experto puede evaluar adecuadamente la implementación.
- Las características y las comunicaciones se visualizan al máximo. Se destacan los tableros de corcho separados, los folletos con características cuelgan de ellos, las personas se acercan, discuten, dibujan en otros tableros que, atención, no son flashes secos y una lavadora que funciona. Aquí hay un gran recurso sobre este tema.
Las herramientas y las buenas prácticas suelen ser más importantes que los planes y los plazos.
Espero que haya quedado claro y obvio que incluso si los requisitos para un proyecto de software son muy claros y formalizados (esto sucede, aunque rara vez), puede haber, como el ingeniero o analista sin experiencia, tantas sorpresas inesperadas que ... solo la intuición y el método de analogía funcionan bien. Examinemos ejemplos de sorpresas: necesita conocer al enemigo en persona:
- Incluso si las leyes creadas por los órganos legislativos de todo el mundo a menudo pueden contener agua y contradicciones lógicas que causan dolor físico en el cerebro, entonces, ¿qué pasa con los conocimientos tradicionales? Naturalmente, cuando se detecta una contradicción, es urgente realizar cambios en el código. El cambio se realiza rápidamente, y el sistema se descompone después de eso, de modo que se restauran los N días y es imposible predecir N científicamente.
- Se detecta un conflicto de la biblioteca de software y debe deshabilitar uno de ellos o un gladiolo. No puedes predecir una simple.
- Incluso durante una carga pequeña, se detecta la insuficiencia de los algoritmos seleccionados (se subestimó el costo algorítmico de los escenarios de uso), razón por la cual el sistema comienza a disminuir. Puede encontrar y solucionar el problema en horas y meses. Es imposible de predecir. Experiencia, solo experiencia o soluciones en caja .
- El desarrollador principal lo exageró antes del lanzamiento y comenzó, bajo la influencia de las emociones crecientes, a orinar en la sala de servidores en un estante con equilibradores web. Hierro en cortocircuito. Tiempo de inactividad repentino: 2 días.
Dados los riesgos inevitables anteriores, es costumbre actuar de manera diferente, por el método de guerra de búnker sistémico (recuerde StarCraft) y tácticas: use prácticas y herramientas de ingeniería comprobadas y crea que al cumplir con esta táctica, lograremos objetivos estratégicos. Simplemente diré lo mismo: si haces flexiones, corres, presionas el expansor y haces la barra por las noches, entonces la probabilidad de llegar a tu casa por la noche es mucho mayor. Si planea protegerse contra los hooligans en el diagrama de Gantt, calculando la probabilidad de golpear a 2 o 3 personas dependiendo del camino a casa y la época del año, entonces será más difícil y mucho más largo y cualquier cambio en las probabilidades deberá tenerse en cuenta todos los días :-) , en general, entendido.
- Pizarras, marcadores, wikis: para las comunicaciones más abiertas entre ellos y con los clientes.
- Redondeando el proyecto. En lugar de matar la comunicación e introducir flujos de información distorsionada y teléfonos de la jerarquía lentamente corrompidos, el proyecto se redondea para que todos los miembros del equipo y representantes del cliente estén accesibles a una distancia
- Los conocimientos tradicionales no están en algún lugar, pero cuelgan de los tableros, las paredes y la mayor cantidad de gente posible puede "leerlos" y discutir
- Herramientas de evaluación disponibles por analogía, archivo de calificaciones anteriores disponible para todos los interesados
- Los desarrolladores escriben pruebas automatizadas de unidad, unidad e integración para el código. Aproximadamente las pruebas deben ser tanto como el código
- Por lo general, en cualquier proyecto de software, hay varios lugares cubiertos de niebla y se encuentran demonios en sus remolinos. Es necesario levantar prototipos que reflejen estos lugares lo más rápido posible y realizar pruebas de carga y otras y obtener una estimación. Esta evaluación es muy útil en las etapas posteriores del proyecto.
Después de haber rodeado el proyecto con las herramientas adecuadas para las comunicaciones del equipo y adoptar un sistema simple pero correcto de valores tácticos y transmitirlos, en la medida de lo posible, a su cliente, las posibilidades de adaptarse a las clasificaciones y lanzamientos aumentan considerablemente. Y nadie nos dará más garantías: esta es la verdad de la vida.
Total
Para resumir. En resumen, vimos desde diferentes ángulos que los métodos politizados de forma inteligente para evaluar proyectos de software en un reloj de loro conejito funcionan solo con datos de prueba en condiciones ideales, pero no en la práctica. La situación repite los enfoques y los resultados en el aprendizaje automático: puede estudiar mucho y comprender durante mucho tiempo que solo funciona la intuición / experiencia / analogía. Es extremadamente costoso desmontar todo por adelantado en cubos formales y, por regla general, no hay tiempo para esto. En condiciones reales, para la evaluación, es mejor confiar en el método de analogía, listas simples de funciones priorizadas, sin jerarquías e interdependencias. Desarrolladores: hagan que el código se documente automáticamente, no confíen en el TK que se descompone inmediatamente y escriban autocomprobaciones para el código. Implementando y siguiendo los valores de las comunicaciones máximamente abiertas, visualizando los requisitos de un proyecto de software, una atmósfera cálida e inspirada, las evaluaciones categóricas simples harán mucho más para alcanzar la fecha de lanzamiento que los interminables cambios de palos abstractos en los diagramas de Gantt y otros. En este y solo este caso, existe la posibilidad de ver al equipo del proyecto con champán en sus manos, con sonrisas, marcando el lanzamiento completo, coincidiendo con el Año Nuevo. Y sobre la momia del gerente en la sala de servidores, simplemente te pareció :-)
¡Felices vacaciones a todos y buen humor!