¿Cómo ser un ingeniero de software? [duplicar]

12

Mi problema es un poco raro, así que por favor ten paciencia conmigo.

He estado trabajando en una puesta en marcha relacionada básicamente con el desarrollo móvil desde mi graduación hace 2 años. Desarrollo aplicaciones para iOS pero no es realmente relevante. La estructura de inicio es simplemente fundadores > desarrolladores, sin supervisión técnica de nivel medio ni gestión de proyectos en absoluto.

Un ciclo típico de nuestro proyecto es el siguiente: reunirse con un cliente > envíe requisitos muy vagos a un diseñador gráfico externo > cavar en el desarrollo justo después de que obtengamos el diseño, sin preguntas > luego improvisar improvisar improvisar! No es que no sepamos que existen cosas como el análisis de requisitos, UML, patrones de diseño, control de código fuente, pruebas, metodologías de desarrollo ... etc., simplemente no las usamos, y quiero decir como nunca.

El resultado suele ser un trozo de código difícil de mantener pero que funciona. A pesar de todo, estamos literalmente floreciendo con muchas aplicaciones exitosas en todas las plataformas y clientes más grandes en cada proyecto. La cuestión es que queremos que el caos se detenga y estamos buscando consejos.

¿Cómo arreglaría nuestra empresa técnicamente? Dado que no puede contratar gerentes de proyecto o líderes de equipo solo porque somos apenas 5 desarrolladores, no sería un costo justificado para los fundadores, pero las cosas únicas como cursos, libros, capacitación privada ... etc. una opción. Por último, si es relevante, estamos ubicados en Egipto.

Muchas gracias de antemano.

    
pregunta Mistrio 12.09.2012 - 00:08

6 respuestas

14

Tengo un fondo de inicio. Lo que estás experimentando es muy típico y, a pesar de lo que muchos dicen, si estás ganando suficiente dinero para sobrevivir, lo estás haciendo bien ... por ahora. Su pregunta es muy válida, muy relevante y (asumiendo que la puesta en marcha tiene aproximadamente 2-3 años, según el tiempo que lleva allí) muy oportuna.

El tiempo de falla más común para una empresa es donde se encuentra ahora: alrededor de 2 a 4 años, necesita hacer la transición a una pequeña empresa desde su inicio. Para evitar fallas en este punto, una fase que me viene a la mente es la "inversión especulativa". Lea sobre esto, entiéndalo y comprenda cuándo lo está haciendo. (Pasar más tiempo de codificación del necesario para realizar el trabajo es una inversión especulativa). No estoy diciendo que no lo haga, sino que entienda cuándo lo está haciendo y tome una decisión consciente de que es apropiado (o no) para hoy. Agregar pruebas unitarias es un muy buen ejemplo.

La transición requerirá algunos cambios, sin embargo, esos cambios no deben poner en peligro las finanzas. No tiene sentido traer un BA, un PM y un "Gerente de software" y todo tipo de procesos improductivos si lo impulsa a la quiebra. Todo lo que hagas debe hacerse en el contexto "¿Cómo podemos hacer que esto suceda hoy y que sigamos en el negocio mañana?"

Una de las empresas iniciales que trabajé para el equipo escribió software para un producto. Cuatro años después, fue descrito como una bola de barro / pila de S ..., el peor código que había visto, etc., que nunca debería haber sido lanzado por un nuevo recluta. Le señalé que los accionistas acababan de vender la compañía y depositar $ 50 millones en sus bolsillos traseros basados en ella. Le pregunté cómo pensaba ganar 50Mil en 4 años y cómo "hacerlo bien" habría ayudado. De hecho, hacerlo bien nos habría llevado 8 meses, no 8 semanas, las reservas de efectivo hubieran durado 3 meses. Los competidores se habrían lanzado al mercado y la compañía se habría retirado. Me fui y se convirtió en el líder del equipo. Reescribieron el código desde cero usando "mejores prácticas" bla bla bla, la compañía ahora tiene menos del 5% de participación de mercado, bajando aproximadamente un 75% ... los ingresos bajaron de $ 250Mil a aproximadamente $ 40mil ...

Así que aquí están mis sugerencias

  • mantener "hackeando" bolas de barro.
  • Presente Agile / SCRUM, pero no permita que esto le detenga, haga cursos sobre esto, si no más.
  • Considere TDD y pruebas unitarias. Te ayudará a mantenerte encima de esas bolas de barro. Ten cuidado, no le dediques demasiado tiempo o no estarás en el negocio para cosechar las recompensas.
  • Realice los 6 sombreros de DeBono al final de cada proyecto.

A medida que crezcas, ten cuidado, ten mucho cuidado, a quién traes. Necesitas personas que hayan pasado por la transición antes. NO reclutar grandes tipos de empresas.

lea esto - Me gusta especialmente "Y hay otro factor involucrado, que es que puede dividir nuestra industria en dos tipos de personas: aquellos que quieren trabajar para una empresa para que tenga éxito, y aquellos que quieren trabajar para una empresa exitosa. El éxito temprano y el rápido crecimiento de Netscape hicieron que dejáramos de obtener la primera y comenzáramos a obtener la segunda. . "

    
respondido por el mattnz 12.09.2012 - 00:40
8

Cuando trabajé con compañías que tenían una metodología muy ad hoc, examinamos los dos o tres problemas principales de proceso o infraestructura que importaban "en este momento" y comenzamos a invertir tiempo en ellos junto con nuestros compromisos normales.

No creo que la "ingeniería de software" tradicional sea necesariamente el modelo adecuado para un equipo pequeño que se ocupa de los requisitos comerciales que cambian con frecuencia; La ingeniería de software es más importante para lidiar con múltiples proveedores y situaciones donde el cambio es muy costoso y requiere puertas de riesgo y calidad. Si está creando software para piezas o automóviles del transbordador espacial, el enfoque de ingeniería de software puede tener sentido.

En cambio, abogo por un enfoque de "artesanía de software" para la mayoría de las organizaciones. Pero la ingeniería de software ha creado herramientas y ha descubierto procesos que funcionan para muchos tipos de equipos, por lo que no estoy diciendo que deba ignorar esas lecciones, solo que debe trabajar desde una perspectiva diferente, que es más sobre la mejora continua, el tratamiento de la ambigüedad y el cambio. y tomar un par de horas cada mes aproximadamente para hacer retrospectivas sobre lo que funciona bien y lo que no funciona bien con sus procesos de desarrollo y de negocio.

En tus zapatos, diría que probablemente no puedas preocuparte por UML por ahora; debe centrarse en colocar un sistema de control de versiones ligero en su lugar. Simplemente comience con Git o Mercurial, e inscríbase en repositorios privados con un proveedor externo para enviar sus repositorios a (Bitbucket, Github), o configure un servidor local para empujar a.

Luego, preocupate por configurar un sistema de compilación continua (como Jenkins).

Es posible que los equipos pequeños no puedan costear los probadores a tiempo completo, pero pueden comenzar a construir una cobertura de prueba unitaria automatizada; incluso comenzar esta práctica sin adherirse religiosamente a un dogma metodológico en particular puede ayudarlo a comenzar a escribir un nuevo código en un estado más mantenible, ya que se molestará lo suficiente por cualquier fricción en las pruebas de escritura que querrá arreglar su código o dar. hasta pruebas Si tienes las otras cosas en su lugar y empiezas a obtener el más mínimo valor de las pruebas, probablemente prefieras corregir tu código en lugar de abandonar las pruebas.

Puedes hacerlo por tu cuenta invirtiendo tiempo en él. Puede valer la pena contratar a una persona para que trabaje en su infraestructura o en los problemas de proceso, pero los tres elementos anteriores son, por lo general, productos que muestran rendimientos inmediatos y requieren una inversión relativamente mínima.

En cuanto a los libros, lea el Programador Pragmático, la Artesanía en Software: The New Imperative, y cualquiera de los libros disponibles sobre control de versiones distribuido e integración continua. Debes evaluar Programación Extrema, Scrum y Kanban para ver qué crees que funcionará mejor para tu equipo. Para mejorar en el proceso, asista a reuniones o eventos locales con otras pequeñas tiendas de software y hable sobre lo que funciona y lo que no funciona para usted, y obtenga mejores ideas de sus pares sobre cómo hacer frente a la alta velocidad con equipos pequeños. La ingeniería de software no se trata realmente de mantener la velocidad, se trata de mantener el control de las cosas que interactúan con su producto.

Sin embargo, una vez que tenga un equipo de 5 personas, algún tipo de ayuda de gestión de procesos tiene sentido financiero para la mayoría de las organizaciones. Contratar a un administrador de programas o a ScrumMaster o algo por el estilo tendrá algún valor para sus fundadores si le ayudará a entregar el trabajo de manera más consistente y predecible.

    
respondido por el JasonTrue 12.09.2012 - 00:45
4
  

El resultado suele ser un trozo de código difícil de mantener pero que funciona.

La correlación no implica causalidad. Tiene un código torpe y difícil de mantener porque escribe un código torpe y difícil de mantener. Creo que la mejor herramienta para mejorar esto son las revisiones de código. Un gerente de proyecto no te ayudará a escribir mejor código. La contratación de un desarrollador con más experiencia puede ayudar, pero en realidad todo el mundo puede impulsar la mejora.

  

A pesar de todo, estamos literalmente floreciendo con muchos éxitos   Aplicaciones en todas las plataformas y clientes más grandes en cada proyecto.

Entonces debes estar haciendo algo bien. Hagas lo que hagas, asegúrate de seguir haciendo las partes correctas. Proceda con precaución y asegúrese de que los cambios de proceso que adopte estén dirigidos a solucionar algunos problemas específicos que identifique.

  

No es que no sepamos que cosas como el análisis de requisitos,   UML, patrones de diseño, control de código fuente, pruebas, desarrollo.   Existen metodologías ... etc., simplemente no las usamos, y quiero decir   como nunca.

Estoy de acuerdo con @JasonTrue en que el control de versión de origen debe ser su primera prioridad. En esta época es inexcusable no utilizar el control de código fuente. Las herramientas están disponibles gratuitamente (git, mercurial, subversion), son fáciles de instalar y usar, y el retorno de la inversión es prácticamente inmediato. Yo sugeriría comenzar a hacer algunas revisiones de código y algunas revisiones de diseño, no más de unas pocas horas cada semana. Simplemente tomarse un tiempo para ver lo que está haciendo, compartir sus experiencias y considerar mejores maneras de hacerlo puede ser una gran ayuda. Los practicantes ágiles llamarán a esto una retrospectiva.

Una vez más, estoy de acuerdo con @JasonTrue en que la automatización de la compilación y la automatización de prueba son los siguientes pasos naturales.

Una vez que tenga control de versión, compilaciones automatizadas, estará haciendo algunas revisiones de código y retrospectivas, y las pruebas básicas y automatizadas simples se verán mucho mejor. Solo agrega la cantidad deseada de caos además de eso :-)

Oh, y definitivamente lee libros: enlace

    
respondido por el Guy Sirton 12.09.2012 - 06:11
2

Mi consejo más importante: ¡No trates de arreglar todo de una vez, o cambies demasiado de una vez!

Exactamente cómo procederá a partir de aquí dependerá de algunas cosas: cuán ocupado está su equipo, qué tan a bordo están todos con la idea de que incluso es necesario mejorar las cosas, etc.

Si la gente necesita convencer, para empezar, probablemente tengas que hacer un montón de trabajo de base. Identifique algunas de las áreas clave que necesita mejorar, elabore una buena 'solución fácil' para cada una (siempre puede mejorar nuevamente desde allí), reúna algunas estimaciones sobre cuánto tardaría cada una, y luego lleve esta información a sus colegas. para ver si puede obtener algo de impulso.

Si todo el mundo ya está a bordo pero no sabe por dónde empezar, colabore con ellos para identificar las áreas clave y algunas soluciones potenciales, y las estimaciones para hacerlas. Probablemente ayude a pensar en esto desde una perspectiva de qué problemas estamos experimentando en lugar de una perspectiva de qué debemos hacer para pensar. Encontrará que es más fácil identificar soluciones a problemas conocidos que identificar acciones específicas de una lista de deseos vaga.

Una vez que tenga su lista, priorícela sin embargo tiene más sentido para su grupo. Ya que parece que las cosas son un poco caóticas en lugar de totalmente disfuncionales, sugeriría ir con un enfoque de "menos agitación primero". Opte por la fruta de bajo rendimiento para comenzar a eliminar cosas de la lista, permitirá que todos se acostumbren a los cambios que suceden y refinará su estrategia para manejar los cambios más grandes.

El control de versión es probablemente el cambio que te dará el mayor impacto por tu dinero. Hágase un repo de prueba para practicar un poco, familiarícese con el flujo de trabajo, luego muéstrelo a sus colegas y consiga un uso operativo completo.

Las buenas pruebas reducirán tu caos significativamente al reducir sorpresas desagradables. Mis sugerencias serían:

  • Cuando arregles un error, escribe una prueba que puedas usar para verificar las regresiones en versiones futuras.
  • Reúna un conjunto de pruebas de funcionalidad básica que se ejecutarán para cada compilación y configure los informes si alguno de ellos falla para que se pueda solucionar lo antes posible.
  • Cree y mantenga una asignación de qué pruebas cubren qué requisitos / funcionalidad / errores

En términos del código en sí, intente ir para una mejora incremental. Siempre que usted (el equipo) actualice un método, verifique que esté debidamente comentado. Configurar revisiones de código para cambios grandes / importantes. Rara vez es una buena idea intentar cambiar el diseño del código existente, pero para los nuevos proyectos, realice una revisión del diseño desde el principio del ciclo de vida en el que considere lo fácil que sería el diseño actualizar, adaptar, extender o reutilizar (¿es suficiente? ¿Modular? ¿Está acoplado estrechamente?)

Por encima de todo, ¡sigue saltando! Si vas lentamente porque estás ocupado, no te preocupes demasiado. Simplemente regrese a la lista cuando tenga tiempo.

    
respondido por el jam 12.09.2012 - 17:21
2

En realidad estás en la dirección correcta para ver all the shortcomings of the software development process que se sigue en tu empresa. Reparar este software y volverse más confiable, comprobable y mantenible NO sucederá de la noche a la mañana. Puedes lograrlo gradualmente, paso a paso.

Puede comenzar a discutir esto con las universidades about what can be improved a través de la introducción de proper SDLC y el ways how to gradually achieve it . Por supuesto, tomará tiempo y hará que esto suceda. Sin embargo, antes empiezas mejor por ti mismo :)

    
respondido por el EL Yusubov 12.09.2012 - 01:33
0

No creo que tu problema sea raro. Es muy común y es una de las muchas causas de fallas de hasta el 95% de las empresas de nueva creación (y también muchas de las que no lo son). Mencionó que se graduó hace dos años pero no identificó el título. Si fuera informática, algunas personas ya dirían que eres un ingeniero de software.

El Instituto de Ingeniería de Software (SEI), con fondos del Departamento de Defensa de EE. UU., creó una escala y baterías de evaluaciones llamada Modelo de Madurez de Capacidad (CMM) para medir el nivel de preparación para tener éxito en los contratos de desarrollo de software del gobierno y otros. . Caracterizan la madurez por nivel, donde el nivel 1 se llama Inicial o Caótico porque el desarrollo de software es indocumentado, ad-hoc, no controlado y reactivo. La habilidad básica de alguien involucrado en el proyecto es lo principal para mantener unidas las cosas para crear un producto para el cliente. La mayoría de nosotros hemos estado en muchos proyectos de nivel 1 donde el trabajo duro y las personas inteligentes salvaron (o casi salvaron) el día.

CMM original recomendó avanzar los niveles en secuencia. El nivel 2, denominado repetible, tenía que ver con los procesos relacionados con la administración. El nivel 3, denominado definido, se refería a las prácticas de equipo definidas por la administración para desarrolladores. Hubo cinco capas (4 está administrada, 5 está optimizando) y se distribuyeron entre las capas donde había muchas Áreas de Proceso Clave (KPA) que se esperaba que las organizaciones aprendieran y practicaran.

Un modelo revisado, CMMi (integración CMM), identifica capas similares y analiza áreas de procesos centrales. Tiene el mismo tipo de progresión orientada al nivel llamada puesta en escena, y una progresión orientada a la hoja de ruta llamada continua. Con el proceso continuo, es posible seleccionar los procesos centrales que son más valiosos para la organización y enfatizarlos con la exclusión de otros procesos.

La certificación para CMMi es un negocio costoso, y la documentación es enorme y desalentadora. Comprender algunos de sus conceptos puede ser valioso, pero principalmente para responder a su pregunta "¿Cómo ser un ingeniero de software?"

Su otra pregunta sobre cómo arreglar la empresa técnicamente está relacionada, pero necesita sugerencias más concretas.

  • Comprenda los conceptos detrás de los modelos de ciclo de vida del software (cascada, espiral, características y, lo que es más importante, iterativo / incremental). En algún lugar durante el desarrollo, no solo debe codificar, sino también analizar, diseñar y probar. Para agile, esto puede ser crear tarjetas de historias o casos de uso con flujos alternativos, crear pruebas unitarias y escribir códigos, a menudo una característica a la vez.
  • Asegúrese de que cada proyecto tenga un alcance de tamaño razonable para su equipo (gestión de requisitos).
  • Cree planes y haga un seguimiento del progreso con una herramienta flexible como Atlassian Jira o algo similar que creará una base de datos de tareas entre el equipo (planificación y seguimiento integrados).
  • Tenga una estrategia de control de calidad que se ejecute durante toda la duración del proyecto. El desarrollo dirigido por pruebas (TDD, por sus siglas en inglés) puede proporcionar gran parte de este requisito, pero también debe leer sobre el V-Model.
  • El código que escriba debe seguir algunas reglas, por lo que debe crear o adoptar estándares de codificación adecuados para su lenguaje de desarrollo. Tener estas reglas mejorará la calidad del código y proporcionará una guía para la revisión por pares del código.
  • Utilice algún tipo de revisión por pares en la que los miembros del equipo miren a los demás trabajando por defectos y recomienden correcciones y mejoras. Esta es una oportunidad clave de enseñanza y aprendizaje, así que no la descarte por ser demasiado cara.
  • Los activos de código y documentación del proyecto deben estar controlados por la fuente, numerados de la versión y descritos por los registros de cambios y las notas de la versión.

Esta es ciertamente una lista parcial, y otros sugerirán otras adiciones muy útiles. Todos los miembros del equipo deben estar bien capacitados para comprender y utilizar cada uno de estos, pero es posible que vea los beneficios a medida que avanza. La mayoría de las herramientas de código abierto están disponibles, por lo que si la primera opción en una categoría es demasiado costosa, mire a su alrededor y busque opciones que se ajusten mejor a usted.

    
respondido por el DeveloperDon 02.10.2012 - 03:03

Lea otras preguntas en las etiquetas