design - software - Le digo a mi gerente que tener un plan es importante

project planning pdf (9)

2 palabras: arquitectura de Bloc de notas

No puede cambiar la forma de pensar de los patrones, a menos que se convierta en el jefe, en la mayoría de los casos.

Usted dice que no hay "tiempo" para diseñar, y pensar en los proyectos que se le asignan, en reuniones de diseño en profundidad y revisiones de códigos, etc ... Estoy de acuerdo.

El primer paso que debe hacer es conseguir que sus "clientes potenciales" sean más accesibles. La mayor parte de ser líder es ser un líder, lo que significa que deben ser confiables y respetados para liderar con éxito cualquier cosa.

El siguiente paso es comenzar a obtener el jr. desarrolladores pensando antes de actuar. Es bastante común para la mayoría de los desarrolladores solo querer sumergirse en el código, pero tomar unos pocos minutos, incluso más, puede significar un éxito en lugar de un error. Asumiría que obtienes "algo" ya sea verbal o escrito sobre qué trabajo hacer, con esa suposición, prueba lo siguiente.

En el Bloc de notas:

Escriba la tarea que necesita hacerse (programa, función, lo que sea).

Escriba qué cosas se deben hacer para lograr esta tarea en un nivel de componente.

"Agregar nuevos campos a la tabla"
"actualizar objetos existentes con un nuevo campo"
"Agregar una nueva llamada de servicio para obtener queso del rallador"

Después de que hayan terminado de señalar lo que creen que será necesario hacer, pídales que seleccionen uno de los clientes potenciales y le pregunten qué piensan, que el líder luego tomará unos minutos y, o bien estarán de acuerdo con sus notas o sugerirán diferentes formas de manejo. cosas y verifique si algo puede faltar al preguntarle al jr. el desarrollador pregunta sobre el dominio en el que está trabajando, no mirando y haciéndolo por él.

Ahora tiene una lista de tareas del proyecto semi detallada así como un diseño básico para el sistema.

A continuación, haga que los candidatos se tomen un descanso para tomar café por el tiempo para ir por la mañana y preguntarle al jr cómo va el proyecto y mostrarle algo del diseño. Si el diseño puede usar alguna mejora, tómese 5-10 minutos adicionales para explicar la mejor manera y sugiera una implementación de la misma, no lo haga por ellos, guíelos para que sean exitosos.

Entonces, en conclusión, si sus clientes potenciales pueden tomar un extra, digamos 20 minutos al día, y su jr. los desarrolladores tardan 30 minutos más antes de sumergirse, debe ahorrar toneladas al final en mantenimiento de pesadilla y ciclos de control de calidad.

La pregunta:
Mi gerente actualmente cree que el diseño es importante, pero no crucial para todos, sino para los proyectos más ambiciosos. En mi opinión, él piensa que es importante diseñar, pero no es necesario, y que la gran bola de barro puede "hacer el trabajo".

¿Cuáles son algunos métodos para discutir (temas, ejemplos, etc.) la importancia de la planificación y el diseño? Estoy buscando cosas que hacer, decir o cambiar que están en mi poder como ''código peón'', por lo que las respuestas como, contratar a alguien más, despedir miembros débiles, etc. no son muy útiles para mí.

Alternativamente, ¿tiene razón y yo soy el que debería reconsiderar mi enfoque del desarrollo?

Algunos antecedentes:
Esencialmente, nuestro equipo consta de tres desarrolladores fuertes, algunos desarrolladores débiles y algunas personas que, en mi opinión, ni siquiera deberían estar en el campo.

No tenemos un arquitecto dedicado, por lo que los tres desarrolladores más fuertes que actúan como líderes no oficiales del equipo son considerados para diseñar todos menos los proyectos más triviales, a menos que el gerente decida que la "bola de barro" es lo suficientemente buena. También son responsables de sus propios proyectos (algunas veces múltiples) mientras asesoran y ayudan a otros. Esto lleva a una carga de trabajo aceptable, pero completa de semana a semana en estas personas.

Mi punto de describir el fondo es triple para este equipo:

Hay poco tiempo para el programa de pares, dar sesiones de capacitación y las revisiones de códigos se han salido del mapa. En otras palabras, los débiles deben aprender por sí mismos.
Cuando a los miembros más débiles se les da un proyecto y se les permite simplemente comenzar a codificar sin pensarlo, el desarrollo lleva más tiempo, pasa más tiempo en control de calidad y es un dolor de cabeza de mantenimiento más tarde, los tres tienen miedo incluso de tocarlo.
Los miembros débiles del equipo generalmente tienen la actitud pero no la aptitud, o viceversa, pero ninguno de ellos parece tener ambos.

Para resumir:
El gerente es un hombre inteligente, aunque testarudo, que escuchará la razón, pero debes convencerlo completamente del ''por qué''.
No hay tiempo suficiente actualmente para inyectar ningún método de capacitación que elimine los deberes diarios del desarrollo y es probable que nadie sea contratado pronto para aliviar una carga.
El único método actual para crear un mejor código con las personas que están disponibles en el equipo es diseñando sus proyectos para ellos y guiándolos a través del proceso de implementación, por lo tanto, tenemos esta pregunta.

Editar

Quería consolidar lo que he tomado de las respuestas hasta ahora; Algunos de estos son intuitivos, pero no son algo sobre lo que la mayoría piense día a día (imo):

A los gerentes les gustan las métricas. Es cierto, pero como M. Fowler cree (y estoy de acuerdo) la productividad y la calidad son inconmensurables. Además, no tengo los medios para acumular las métricas como ''peón''. (gracias Novelocrat y duffymo).

Siempre habrá una combinación de talentos, debe presentar un entorno de aprendizaje. Apoyamos esta actitud, pero creo que se necesitan otras herramientas para crear este entorno. (gracias duffymo).

Involucrar a los débiles, aliviar la carga de trabajo de los fuertes Además (como resultado de?) Presentar el entorno de aprendizaje, involucrar a los desarrolladores más débiles en el fortalecimiento de sus habilidades de diseño, dándoles pequeñas partes atómicas del proyecto para diseñar (con aprobación) sí mismos. Esto elimina la responsabilidad de los desarrolladores más fuertes, enseña a los más débiles y puede ser una solución aceptable para el gerente, ya que no le toma tiempo a sus empleados mejor pagados. (gracias duffymo y Tom Anderson)

El trabajo de un gerente es asegurar que el trabajo se realice de la manera más efectiva posible, a menudo sin embargo la política, la ignorancia y el ego se interponen en el camino de nublar el pensamiento. El enfoque más efectivo es demostrar el cambio presentándolo usted mismo ... tome solo un tema / área problemática (¿diseño?) Y demuestre muy visualmente y vocalmente lo que cree que debería tener lugar al implementarlo, incluso si es solo y para usted tú mismo. Cuando los demás vean lo que estás haciendo y se den cuenta / sean testigos de las ventajas de hacerlo, lo seguirán. Una vez que tenga un proceso en su lugar, firme, introduzca otro. Tenga en cuenta que no todo lo que introduzca será efectivo o se afianzará, la idea es que debe seguir presentando nuevos procesos, probándolos y ayudando a otros a entenderlos. Nadie (bueno, casi nadie) quiere trabajar más duro de lo necesario y nadie (casi) quiere sacar un crap code ... predicar con el ejemplo en este caso y si el gerente vale algo, él / ella entenderá y comienza a apoyarte

Es importante tener en cuenta que hay contraejemplos. Linus Torvalds ha declarado que Linux se desarrolló sin un plan o diseño general. Pero luego tuvo la ventaja de un control / supervisión constante durante toda la vida del proyecto.

Esta es una situación muy difícil.

Siempre tendrás una distribución normal de programador; habrá un "mejor" y "peor" en tu equipo. Lo único que puedes hacer es arrastrar toda la curva de la campana hacia la derecha tanto como puedas para que la "izquierda", los desarrolladores más débiles sigan siendo lo suficientemente buenos en comparación con la población en general.

¿Cuál es la mentalidad de los desarrolladores "más débiles" que siempre necesitan ayuda? ¿Lo ven de esa manera? ¿Qué tan aceptables son de su instrucción? ¿Toman la corrección personalmente o quieren aprender?

¿Hay una cultura de aprendizaje en tu equipo? ¿Los miembros siempre se esfuerzan por mejorar sus habilidades, aprender cosas nuevas?

Creo que la falta en esa área es tu problema real. Si su equipo operara de esa manera, el gerente no importaría tanto.

¿Has intentado hablar con tus compañeros de equipo? ¿Es el retraso debido a la falta de planificación lo suficientemente notable donde otros podrían estar de acuerdo?

No sé cómo escribir un argumento ganador aquí. A los gerentes les gustan las métricas. Tal vez puedas comenzar a guardar algo que compruebe tu punto. El problema allí es elegir los más significativos.

Tenga cuidado: no todos ven las "mejores prácticas" de la misma manera. Lo que es evidente para usted podría ser anatema para los demás. Primero, háblalo con tu equipo antes de dirigirte al gerente. No quieres alienarlos. Te ayudará tu argumento si tienes un consenso.

Hay un artículo sobre Deuda técnica que creo que podría ayudarlo a presentar el problema a su jefe, y lo ayudaría a entender por qué mantiene su posición sobre este asunto.

No es una respuesta completa a tu pregunta, solo un pensamiento.

Tener un plan es importante. Tener un plan demasiado detallado es limitativo. Debes poder improvisar. Planifique el panorama general, actúe según los detalles de acuerdo con el objetivo del plan. Y prepárate para cambiar el plan si hay una necesidad imperiosa. Adoptar, adaptar y mejorar

Quizás podrías comprarle un buen libro.

Por ejemplo , la Guía de supervivencia del proyecto de software que comencé a leer. Tiene algunas listas de verificación agradables que pueden ser convincentes, por ejemplo, califíquese con esta lista de verificación si su proyecto tiene los elementos esenciales para el éxito.

Pruebe buscar en Google las "mejores prácticas de proyectos de software" y vea lo que obtiene. Por ejemplo, "Mejores prácticas para proyectos de desarrollo de software" . Invariablemente apoyarán tu objetivo.

Un par de pensamientos:

Si puede cuantificar su declaración a su gerente de que los proyectos de los miembros del equipo más débil le cuestan dinero debido al tiempo perdido en las prácticas de codificación no organizadas y los largos ciclos de control de calidad, podría escuchar.

Si se toma el tiempo para diseñar el código para sus miembros junior, y los guía a lo largo del proceso sin explicar sus decisiones, no tendrán la oportunidad de convertirse en un puesto de mayor rango.

Si se deshace de (o promueve) a algunos de los que no pertenecen a la profesión, puede abrir el recuento de la cabeza de una persona productiva, cuyos esfuerzos superarían por mucho a los de los que no lo son.

y bienvenidos a ,

Esta pregunta es muy difícil de responder en mi humilde opinión. Pero parece que necesitarías algo como SCRUM. (Ver http://en.wikipedia.org/wiki/SCRUM )

Esto ayudaría a sus superiores a obtener una visión general de los proyectos y las tareas en las que se encuentran los desarrolladores y los problemas se detectan temprano.

Pero sinceramente, no puedo darle una respuesta correcta o incorrecta, no hay: cambie esto y esto, y funcionará.

Lea acerca de las metodologías de desarrollo de software ( http://en.wikipedia.org/wiki/Software_development_methodologies ) y encuentre un método que se adapte a sus necesidades (o las de su empresa). A menudo, esta será una variante ágil (como SCRUM) o rápida.

Pero ten en cuenta que el impelente flujo de trabajo no es una tarea fácil, necesitarás mucha calma para ponerlo en marcha.