Debe elegir qué software necesita: escrito a tiempo o de alta calidad

Espero haber podido llamar su atención con un titular tan provocativo (y, ciertamente, exagerado). Bueno Ahora déjame reformularlo de una manera un poco más elegante y menos atractiva :

En principio, el software se puede escribir a tiempo o bien, pero no ambos al mismo tiempo *

* excepto en algunos casos en los equipos de alto rendimiento existentes

Durante varios meses, he estado pensando por qué la creación de software de alta calidad no encaja bien con las fechas estimadas y la planificación en general. Durante mi carrera, vi proyectos construidos en una variedad de modelos (cascada, verdaderamente flexible, cascada flexible), y todos tenían una cosa en común: no importa en qué proyecto estamos trabajando si se hizo " en ciencia" ( es decir, no nos permitimos trucos sucios, por lo que luego tendríamos pesadillas), siempre rompíamos los plazos.

Por otro lado, cada vez que el proyecto se entregaba "a tiempo", esto significaba que inevitablemente tenía que reducir su volumen o cortar tantos rincones que durante la implementación se acumularon montañas de deuda técnica, casi garantizando que el proyecto tendría que reescribirse poco después. lanzamiento Por lo tanto, comencé a preguntarme: ¿podemos suponer realmente que el proyecto se entregó "a tiempo" si, como resultado, tenemos una versión fea, inconveniente de soportar, llena de errores y, francamente, una versión más fea del código en comparación con lo que originalmente teníamos? intentado hacer?

Traducido a Alconost

Tuve ocasión de trabajar en proyectos sin plazos estrictos. Sí, formalmente había "plazos", pero lejos del hormigón armado. Todos entendieron que nuestros plazos son flexibles y que la calidad es más importante que la entrega oportuna del producto. Fue en estos proyectos que obtuvimos el mejor software, hubo los desarrolladores más satisfechos y, en general, estos proyectos se encontraban entre los más exitosos entre todos en los que tenía que trabajar. Pero todos sabemos que tales proyectos son muy raros, de lo contrario no habría escrito todo esto.

Entonces, ¿por qué es tan difícil planificar el trabajo y entregar un buen software, teniendo plazos fijos? Creo que esto se debe en gran parte a la creatividad , la habilidad y la imprevisibilidad .

Lado creativo de la programación

Soy de la opinión de que el desarrollo de software es, por definición, una actividad creativa . Por supuesto, hay desarrolladores que realizan las mismas tareas triviales, pero solo tienen trabajo hasta que alguien ha descubierto cómo automatizar su trabajo. No los envidiarás, y el tema de este artículo es completamente diferente.

Para mí, hay algo especial en el acto de crear algo nuevo y en la búsqueda de soluciones originales en respuesta a los desafíos; Es por eso que me siento llamado al desarrollo de software, y no creo que sea el único. De hecho, creo que la creatividad es la razón principal por la que los desarrolladores disfrutan de su trabajo. Mi experiencia sugiere que cada vez que trabajé en condiciones donde se observó un "conjunto de prácticas" estricto e inmutable (ya fuera una pila tecnológica, procesos, regulación, etc.), entonces hay menos espacio para la creatividad. Lo estaba, cuanto menos me fascinaba ese trabajo. "Al final, si ya han decidido todo por sí mismos, ¿por qué me necesitan?" - pensé Por otro lado, estaba mucho más lleno, inspirado por ese trabajo (en el que también era el más productivo), donde había relativamente pocas directivas desde arriba, había espacio para la creatividad y confiaba en mí mismo para tomar decisiones técnicas.

Es importante tener en cuenta que la libertad creativa adicional lleva al hecho de que, en el camino hacia una solución, inevitablemente habrá más pruebas y errores, y esto es normal. A algunos les parece que simplemente pueden conocer la solución perfecta a priori (por adelantado) sin escribir una sola línea de código. Por el contrario, insisto en que en el proceso creativo, el camino para descubrir una solución a una tarea (esto se aplica no solo al software) requiere jugar con : es imposible saber todo de antemano con seguridad; por el contrario, aprende en la práctica, clasificando gradualmente nuevas opciones y apegándose a las que funcionan, perfeccionando su decisión (y, posiblemente, entregándola gradualmente a los clientes si trabaja de acuerdo con una metodología "flexible") hasta que esté satisfecho con ella.



Solo piense cuántas veces se tardó en diseñar minuciosamente un componente en papel; solo entonces, para rehacer completamente el diseño, solo valió la pena comenzar la implementación. Siempre habrá incógnitas desconocidas en este negocio , y puede identificarlas y enfrentarlas solo a posteriori (de hecho), programar su solución y no perder mucho tiempo en teorizar y no pretender que podemos poseer información perfecta por adelantado. Tal improvisación no encaja bien con las fechas estimadas.

Además, como en el caso de otras actividades creativas, es útil practicar la postergación estratégica cuando se programa: este término fue propuesto por primera vez por Adam Grant, quien afirma que a menudo no puede crear a pedido, pero, por el contrario, la creatividad viene como una "notificación push " de un proceso que se ejecuta en segundo plano en tu cabeza:

“Los empleados que postergan regularmente suelen dedicar más tiempo al pensamiento divergente, y los curadores a menudo los califican como más creativos que sus colegas. La dilación no siempre alimenta la creatividad: si un empleado no tiene una motivación segura para resolver un problema importante, entonces, debido a un deslizamiento, simplemente se queda atrás. Sin embargo, si una persona es lo suficientemente apasionada por el negocio y da nuevas ideas, posponiendo la tarea, llega a soluciones más creativas ".
- Grant, Adam. "Originales: cómo los inconformistas mueven el mundo"

Una vez más, esto no complacerá a los defensores de la planificación central que buscan prever y medir cada minuto en proyectos de desarrollo de software.


Vía Láctea , Marte y meteorito

Habilidad de programación

Los mejores desarrolladores que conozco son hábiles artesanos. El dominio es un rasgo característico de un buen software: creas algo que funciona y lo creas de la mejor manera posible : es relativamente fácil crear algo que funcione, pero es muy difícil hacer algo que no solo funcione, sino que también pase la prueba del tiempo.

Como eres un maestro, la calidad de tu trabajo habla de ti . Para usted, la calidad es más importante que la cantidad, porque no desea ser reconocido como el autor de govnokod, incluso si pudiera satisfacer al gerente de producto dándole a su programa un brillo externo y llenándolo de sorpresas viles. A este enfoque lo llamo Kindersurprise Development . Sabes que dedicar suficiente tiempo a un caso y escribir un buen programa es correcto, así que resiste la presión de "hazlo más rápido", porque sabes que cuantas más muletas instales ahora, más corto será tu código y habrá más problemas. negocios


Los ojos sangran

La artesanía se preocupa por el cuidado : nos preocupamos por hacer un excelente trabajo, por aquellos que tendrán que mantener nuestro código después de nosotros, por nuestros clientes que deberían ser fáciles de usar con nuestro programa, por los compañeros de equipo, etc. Lo haces porque no eres un imbécil y porque sabes que esto es lo que debes hacer si te importa el éxito del proyecto.

En resumen, un buen ingeniero tiene una tarea difícil: cuidar la calidad, que se sentirá a la larga, en un mundo donde todo se decide hacer rápidamente.

En la práctica, esto se expresa en cosas similares:

• Encuentre la combinación correcta entre encapsulación, extensibilidad, escalabilidad, etc. - de nuevo, se requerirá un enfoque iterativo por prueba y error, porque nadie puede construir la mejor solución en el primer intento.
  
• Tómese un tiempo para refactorizar si se encuentra con un código vergonzosamente malo.
  
• Escriba buenas pruebas completas, tal vez incluso haga TDD
  
• Programa en conjunto con un colega
  

No es necesario decir que es imposible planificar todo esto con anticipación, por lo que un enfoque similar aún no lo ayudará a cumplir con los plazos.

Tus predicciones son incorrectas

"Incluso si existen requisitos claros, y parece que nunca sucede, es casi imposible calcular cuánto tiempo lleva un trabajo en particular, ya que nunca antes hemos resuelto este problema. Si decides, simplemente darte el resultado ".
- Ron Jeffries, Movimiento NoEstimates

Los proyectos de software son sistemas complejos : son creados por personas y, por lo tanto, llevan la impronta de las relaciones interpersonales, la motivación, los problemas de comunicación y la psicología humana en general; todo esto es muy difícil de modelar y cuantificar en la tabla si está interesado en mi opinión. Por lo tanto, los proyectos de software son muy difíciles de modelar (y, por lo tanto, predecir). Esto es mejor explicado por Nassim Taleb en su libro " Anti-Fragility" :

“Los sistemas complejos son altamente interdependientes (lo cual es difícil de reconocer) y las reacciones no lineales. "No lineal" significa que cuando duplica, por ejemplo, la dosis de medicamento o el número de trabajadores en la fábrica, el rendimiento no será el doble, sino mucho más o mucho menos. Esto no quiere decir que dos fines de semana en Filadelfia sean dos veces más agradables que uno. Puedo decirlo desde mi propia experiencia ... "
- Nassim Nicholas Taleb, Anti-Fragilidad

Peor aún, dado que el tiempo no puede ser un valor negativo, es probable que cualquier "sorpresa" no planificada demore la finalización del proyecto, en lugar de acercarlo, porque existe una asimetría de resultados:

“El tiempo no es un valor negativo, lo que significa que un proyecto de tres meses no se puede implementar en un período de tiempo cero o negativo. Por lo tanto, en el eje de tiempo, que se mueve de izquierda a derecha, los errores se acumulan a la derecha y no a la izquierda. Si la incertidumbre es lineal, veríamos que algunos proyectos se completan significativamente antes de lo previsto (ya que a veces llegamos a un lugar mucho antes y a veces mucho más tarde). Pero en realidad, no es así ".
- Nassim Nicholas Taleb, Anti-Fragilidad

Estas son malas noticias, porque la incertidumbre está garantizada , e incluso pequeños errores en la evaluación de tareas individuales se acumularán exponencialmente a escala de todo el proyecto. Además, aquí consideramos el mejor caso cuando los plazos son establecidos por los propios desarrolladores después de una cuidadosa evaluación del momento. Sin embargo, la realidad es mucho más absurda: en la mayoría de los casos, el "negocio" establece los plazos como le plazca, y solo entonces los ingenieros vienen a trabajar, planificando cómo satisfacer todos los requisitos para este período arbitrariamente especificado; el caso es tan atroz como comenzar una casa desde el techo, no desde los cimientos, o poner un carro frente a un caballo.


Buena pregunta

Aquí hay algunos ejemplos que demuestran la no linealidad del desarrollo de software y los bucles de retroalimentación resultantes:

• Una vez sugirió que la API que desea vincular acepta accountId , pero de hecho solo acepta memberId . Agregue al período estimado de 4 días que necesita refactorizar el código API, después de lo cual, a su vez, necesitará una revisión por separado, para lo cual agregaremos otros 2 días.
  
• La tarea que esperábamos resolver en 2 días dura una semana, porque en el proceso de revisión, uno de los colegas te obliga (y lo hace bien) a refactorizar y optimizar el repugnante código que ha estado esperando desde hace mucho tiempo.
  
• Recuerde esa tarea única cuando necesitaba implementar solo una nueva oportunidad. Pero resultó que para esto necesita actualizar la dependencia, que tomó 4 días, y esta operación provocó una reacción en cadena con la actualización de otras dependencias y un montón de dependencias durante el ensamblaje.
  

¿Estamos jodidos?

Simplemente por inercia seguimos jugando este juego con evaluaciones y planificación, solo para asegurarnos: supuestamente tenemos el control de la situación. Pero en realidad, no controlamos nada; La experiencia demuestra que los proyectos de software son impredecibles. Así que creo que es mejor centrarse en los negocios en lugar de planificar: #NoEstimates , ¿quién está conmigo? Sin embargo, por supuesto, esto no funcionará en muchas organizaciones: "No se puede tomar y dejar que los ingenieros corran el balón para que nadie los controle". ¡Debe haber responsabilidad! Lo entiendo


¿No dices eso?

¿Qué hacer entonces? Creo que esto se reduce a reducir la brecha entre el mundo de las mesas y el mundo de IDE para proporcionar a los ingenieros la máxima creatividad, flexibilidad y libertad para mostrar dominio, sin embargo, al mismo tiempo, cumplir de manera responsable con la promesa y cumplir con las expectativas de los interesados ​​en el proyecto. Gerente Técnico (Gerente de Ingeniería): el mejor especialista en la construcción de tales puentes, que también puede absorber la brecha entre los dos mundos. Este trabajo no es fácil, pero sí necesario. Así de bien habla Aaron Longwell sobre ella en su artículo:

“Dado que los gerentes técnicos viven en la frontera entre las empresas y los técnicos, son ellos quienes tienen que resolver las contradicciones entre las expectativas y la realidad. Son como una suspensión de palanca, que se tira en diferentes direcciones: puede romperse en ambos lados. Si el negocio gana, entonces los desarrolladores son conducidos a la muerte. Si las consideraciones de ingeniería superan a las de negocios, entonces adiós al presupuesto y los plazos. En cualquier caso, un fracaso. Un gerente de proyecto de software exitoso encuentra formas de actuar con flexibilidad; ceder, no romperse, y resolver gradualmente la fricción. El enfoque de liderazgo como servicio puede ayudarlo a ser más flexible ”.
- Aaron Longwell, por qué el desarrollo de software requiere líderes de servicio

También es muy importante establecer una fuerte relación de confianza entre Producción e Ingenieros. Si hay confianza, puede negociar honesta y concienzudamente los plazos. Si ya ha demostrado que su equipo hace un buen software, entonces debe tener una reputación bastante buena, y las partes interesadas deben confiar en usted, entendiendo que si está fuera de horario, entonces por buenas razones y por el bien común.

Otro "truco" que utilicé personalmente como gerente fue no nombrar fechas específicas, ya que inevitablemente se convierten en plazos difíciles. Es mejor dar fechas difusas, por ejemplo, "tres a cinco semanas". En este caso, cuando se acerca a una fecha límite tan inestable, agrega: "en abril o mayo", que se interpreta fácilmente como "Entre el 15 de abril y el 3 de mayo" a principios de abril, alrededor del 10 de abril puede convertirse en "Para el 20 Abril ", etc. En este caso, no disimula, se comunica con colegas y el equipo proporciona la flexibilidad de los términos que se necesitarán para resolver los inevitables problemas imprevistos que surgen.

Finalmente, recuerde que es el desarrollador quien debe ser responsable de la calidad técnica del producto emitido, y no otras partes interesadas. Es bastante natural que haya fricciones entre las organizaciones, que, a primera vista, están guiadas por diferentes incentivos. En este caso, es muy importante tener en cuenta que todos ustedes (presumiblemente) están unidos por un objetivo común: proporcionar al cliente software de alta calidad en el menor tiempo posible. Aparentemente, solo los buenos desarrolladores pueden pensar con este espíritu y comprender que es importante evitar el engañoso enfoque "uno, dos y listo", que a la larga es el más lento.

En conclusión, diré que este es un problema solucionable, aunque complejo (y común). Diría que si, en su opinión, su gerente o su organización no están dispuestos a escribir un buen software, entonces necesita hablar sobre ello e intentar cambiarlo; Si esto falla, encuentre otro trabajo.

Sobre el traductor

El artículo fue traducido por Alconost.

Alconost localiza juegos , aplicaciones y sitios en 70 idiomas. Traductores en lengua nativa, pruebas lingüísticas, plataforma en la nube con API, localización continua, gestores de proyectos 24/7, cualquier formato de recursos de cadena.

También hacemos videos de publicidad y capacitación , para sitios que venden, imágenes, publicidad, capacitación, teasers, expliner, trailers de Google Play y App Store.

Más detalles