¿Cómo puedo superar un modelo de desarrollo de software mal estructurado?

Me uní a la compañía en la que estoy trabajando actualmente. Debido al número limitado de personas capacitadas en el desarrollo de software SIG, y como estaba entre uno de ellos, me contrataron directamente como Gerente de Proyecto.

Estaba bastante familiarizado con Java y SIG, y he realizado investigaciones auto motivadas sobre servicios basados ​​en la ubicación, pero no con la gestión de proyectos y el desarrollo de software estructurado. Fue un año después de mi graduación como especial de Geología y durante el año anterior estuve trabajando como académico en una universidad.

Gracias al interés que tenía en el trabajo, apareció una oportunidad y, finalmente, también fui responsable del departamento de Business Intelligence de la empresa. La compañía creía en mí. Yo mismo estudié el almacenamiento de datos y los conceptos de BI y también logré combinar GIS con BI.

Además, actualmente estoy trabajando con dos desarrolladores en nuestra herramienta de BI en C # WPF, donde también a veces desempeño el papel de desarrollador (lo que me gusta).

Traté extremadamente duro de adoptar buenas metodologías de desarrollo de software con gestión ágil de proyectos, pero no fue muy exitoso. Además, aunque creo en un código bien diseñado en lo que respecta a un producto, debido a la falta de conocimiento técnico que tiene mi CEO (que está directamente por encima de mí), normalmente no obtengo la cantidad de tiempo necesario para hacerlo. El tiempo que toma se ve enormemente mejorado por la falta de experiencia que tenemos en el lenguaje de codificación específico en su conjunto también (por ejemplo, WPF en oposición a Java). Tampoco hay un sistema de control de versiones en su lugar.

Estoy extremadamente harto de cómo van las cosas, ya que no está estructurado y encuentro la mayor parte de mi tiempo pensando que trabajando en cómo estructurar las cosas. Espero que ustedes, con buena experiencia profesional, puedan ayudarme a superar esta situación.

Tuvimos un problema similar (sin los detalles técnicos, por supuesto) en la empresa donde trabajo hace aproximadamente dos años.

Solo necesita hacerlo paso a paso. No intente adoptar el desarrollo de software ágil de inmediato. Hay muchas cosas que aprender y aplicar. No permita que la falta de experiencia lo deprima tampoco.

Construya lentamente (pero tan rápido como pueda: P), de manera constante y segura.

Recomendaría los siguientes pasos (para hacer esto, puede cambiar de administración al desarrollo por un tiempo, pero eso debería estar bien)

1. Aprenda un buen sistema de control de versiones y apréndalo bien. Personalmente recomendaría git o mercurial. Hay mucha documentación sobre ambos.
2. Construya un núcleo sólido sobre prácticas y patrones . Lea libros, lea blogs, mire capturas de pantalla con los miembros del equipo. Esto le dará un nuevo aire al desarrollo.
3. Aprenda TDD / BDD e intente aplicarlo en el nuevo código , así como en el antiguo código que podría tocar al hacer una nueva función.
4. Hacer pares de programación . Dos cabezas piensan mejor que una, y también 4 ojos son mejores que 2 :).
5. Encuentre las herramientas usadas más recientes y más comunes en la comunidad del lenguaje que está desarrollando actualmente. Aprenda sobre ellos e intente incluir algunos de ellos en el proyecto. Vea cómo se construyeron y aprenda.
6. Utiliza scrum . Las iteraciones, las historias, los puntos de la historia, los impedimentos son conceptos con los que debe familiarizarse. Para mí, scrum ha demostrado ser el mejor flujo de trabajo para el desarrollo y administración de software. Aplícalo y aprende de la experiencia de cada día.
7. Enseñar con el ejemplo . La mayoría de los desarrolladores principiantes están ansiosos por aprender cosas nuevas, pero también algunos de ellos son muy vagos. De todos modos, muéstrales las cosas nuevas que has estado aprendiendo y aplicando y con suerte eso les hará cosquillas en el cerebro.

Además, si es posible, contrate a un consultor para que pueda verificar el proceso y dar mejores consejos.

No te vuelvas perezoso o desanimado. Simplemente aprenda de sus errores y pruebe diferentes enfoques. ¡Este es solo el comienzo!

Editar:

Estos son algunos de los enlaces y libros que he estado leyendo / usando últimamente ...

Aprendizaje git: Pro Git

Estos son algunos de los blogs que recomendaría (la mayoría de ellos están orientados a .NET):

• Blogs de Java
• Blog de Karl Seguin y su serie Fundamentos de la programación.
• CodeBetter.com
• Código pensado
• Los Techies
• Codificador limpio
• Y también este enlace a una pregunta de desbordamiento de pila.

Para libros, puede ver la lista Buiding A Solid Programming Core en amazon. También recomendaría estos:

• Código limpio
• Desarrollo de software ágil, principios, patrones y prácticas
• Casi cualquier libro de The Pragmatic Bookshelf

Como gerente, es su trabajo obtener el tiempo requerido para completar un proyecto correctamente. Cuando se acerque al CEO, asegúrese de tener todas las cifras que lo respalden y las razones por las cuales las estimaciones son tan largas como lo son. Es su responsabilidad como gerente hacer que el CEO comprenda por qué lleva n horas / días / semanas completar una tarea determinada. Esto a veces puede ser difícil, pero no he conocido a un CEO que quiera que su compañía fracase todavía y apuesto a que si lo expresa en ese tipo de términos (si todo lo demás falla), puede cambiar su tono.

Si el CEO no está dispuesto a otorgarle el tiempo necesario para completar las tareas, en mi humilde opinión, esté listo para pasar a otro trabajo o prepararse para marchas de muerte continua. Como último recurso, explique al CEO el agotamiento que sin duda vendrá de expectativas poco realistas.

Una vez dicho esto, usted también necesita asegurarse de que sus desarrolladores se le proporciona estimaciones precisas (tremendamente difícil, casi imposible sin adecuados diseños técnicos realizados, que también debe estar en alguna parte).

Ágil no es bueno en todos los dominios de desarrollo. Funciona para algunos tipos de proyectos, falla miserablemente en otros. Es posible que deba probar algunas metodologías diferentes antes de encontrar una que funcione bien .

Obtenga la configuración del control de versiones . Realmente, lleva 5-10 minutos configurar Git, unos minutos más para obtener las operaciones básicas y uno o dos días de lectura para obtener los conceptos más avanzados.

Hmm, no estoy seguro si te conocí en un evento Agile / XP en Toronto - esto suena familiar

Parece que necesitas un descanso. Tómate un fin de semana largo, emborrachate si quieres y olvídate del trabajo por unos días.

Tranquilízate contigo mismo. La autoaprendizaje es buena, y solo porque una metodología no funcione con las personalidades involucradas, no significa que lo esté haciendo mal, y no es un fracaso personal.

Hay un sitio (beta) pm.stackexchange.com, dirigido a Project Management, es muy posible que obtenga algunos consejos útiles / soporte allí, pero por supuesto, mantenga la pregunta aquí también.

Pasando a las cosas tecnológicas:

no hay un sistema de control de versiones en su lugar

Ponga uno como su máxima prioridad. Prefiero sistemas centralizados como SVN (Subversion) sobre git / mercurial, porque una computadora portátil robada no tendrá tanta historia localmente. Especialmente importante si algo súper secreto (como contraseñas y ssh-keys) se registró por error. Pero, es cuestión de gustos. Nada desperdicia más tiempo que los errores del 'control de versión manual', por ejemplo, devolver el código a lo que cree que era.

Buena suerte

Parece que tiene varios problemas: 1. Comunicarse con la alta gerencia no técnica para que apoyen su programa de mejora; y 2. Impulsar el programa de mejora para el éxito.

La parte más difícil del número 1 es simplemente recordar que la alta gerencia a menudo no estará interesada en los detalles de lo que está trabajando. (¡Si lo fueran, lo harían ellos mismos en lugar de entregárselo!) Parece que el gran obstáculo es 'por qué' y es posible que desee ver CMM 1.1 para obtener una descripción de los beneficios comerciales de una mejora de procesos programa. Ya sea que use CMM o alguna otra cosa para mejorar realmente su proceso, no será importante para esta discusión, solo los datos del estudio Carnegie-Mellon, que muestra que organizaciones más maduras entregan proyectos más rápido con menos variación en el tiempo de entrega.

Hay muchos caminos hacia el éxito en la mejora de procesos, todos tienden a ser muy largos. La experiencia con CMM muestra que puede llevar de 8 a 10 años pasar del nivel 1 al 5. La experiencia con 6 sigma muestra que cada iteración proporciona alguna mejora, pero necesita múltiples iteraciones para eliminar la mayoría de los problemas potenciales y, para cuando llegue el momento Con 6 sigmas de calidad, el trabajo se realiza de manera completamente diferente sin tener que correr el riesgo de intentar reemplazar todo a la vez.

Si hay un enfoque de mejora de la calidad comúnmente utilizado en su industria, tómese el tiempo para intentar ver cómo se aplica al software y úselo para que el resto de la compañía escuche sobre algo con lo que ya están familiarizados y que apoyan. Podemos hablar durante horas sobre herramientas y prácticas de software específicas, pero los CEOs que no son de software lo ignorarán rápidamente. Hable acerca de las prácticas estándar de la industria y él se animará porque está hablando su idioma. Hable sobre el software en los términos comunes de la industria y él comenzará a hacer preguntas relevantes para comprender mejor sus desafíos y sus planes para mejorar los resultados de las empresas.

No ganará todas las solicitudes de soporte de esta manera, ¡probablemente obtendrá muchas menos miradas en blanco y más victorias!

Buena suerte señor!

Todas sus sugerencias son realmente sensatas y son el camino a seguir en muchas empresas. Pero no son universales, especialmente con equipos que no tienen tanta experiencia. La razón por la que no lo son es que requieren cierta cantidad de trabajo para configurar y mantener, incluso el control de versiones, lo que muchos supondrían que es una apuesta de mesa para cualquier proyecto de software. Debido a que requieren algo de trabajo, también deben proporcionar algún beneficio. ¡Y podría ser el caso de que en su situación particular no lo hagan! ¡O al menos las personas encargadas de tomar las decisiones no ven el beneficio!

Como otros han señalado, necesita:

• Intenta adoptar las prácticas a su vez. No los pruebes todos a la vez porque abrumará a las personas.
• Necesitas encontrar un buen orden para esto. Comenzaría con el control de versiones. Ve con los más fáciles también. Una vez que las personas comienzan a confiar en que usted toma buenas decisiones y ven los beneficios, es más probable que adopten cambios más riesgosos.
• Cree un caso sólido de por qué algo debe implementarse. Con 2-3 desarrolladores que constantemente hacen visible el progreso a los usuarios finales, es difícil justificar la adopción de una metodología de desarrollo más elaborada, por ejemplo. Será visto como un proceso centrado en lugar de resultados centrados
• Tenga en cuenta a quién necesita convencer. Los desarrolladores? ¿El CEO?