¿Cuáles son las mejores prácticas para construir software complejo poco a poco?

Básicamente, está solicitando el curso completo de Ingeniería de Software. Déjame decirte que hay un cuerpo de conocimiento muy grande y en constante evolución.

Olvídate de las anécdotas. “Debería emparejar el programa”, “debería escribir documentación con estilo X”, “debería usar RUP”, “debería usar Agile” … Eso es más como aprender sobre nutrición al conocer la dieta Southbeach y Atkins de Oprah.

Si no sabe cómo hacerlo, contrate a alguien que sí lo haga. Es como pedir consejos sobre cómo hacer una cirugía cerebral sin tener que ir a la escuela de medicina.

Otro problema, si está preguntando esto aquí, no tiene ningún buen desarrollador de software con buenos antecedentes y trayectoria exitosa. Entonces, mi consejo es que inicialmente subcontrate el trabajo a una empresa de consultoría que lo haga. Si se encuentra en los EE. UU., Busque Pivotal Labs, Relevance, Thoughtbot y muchos otros con credibilidad y experiencia.

No intente reunir su propio equipo si no tiene suficiente experiencia trabajando con la gestión de proyectos, recursos humanos. La mejor manera de no perder el tiempo contratando freelancers con los que no sabes cómo lidiar es externalizar mientras buscas un líder de equipo lo suficientemente bueno que construya tu propio equipo interno con una buena combinación de desarrolladores senior y junior (no, tú no quiero que todos sean adultos mayores, créanme).

Entonces, la compañía de outsourcing puede ayudar a hacer la transición de su trabajo a su nuevo equipo para continuar.

Es lo mismo para los otros aspectos de su empresa: no haga contabilidad por su cuenta, contrate a una CA. No escriba contratos por su cuenta, contrate a un abogado. No haga campañas por su cuenta, contrate una agencia de publicidad. Y finalmente, no escriba software por su cuenta, contrate una consultoría o, si tiene suerte, encuentre un desarrollador muy experimentado con muchos años desarrollando software en muchas tecnologías, con habilidades de comunicación probadas, habilidades de gestión de proyectos, una red de personas lo suficientemente grande y credibilidad en el mercado.

Si tiene los recursos, ese es el mejor curso de acción. Si no lo hace y prefiere ir “más barato”, es probable que tenga que aprender cometiendo errores. Y créanme, lo más probable es que repitan cientos de los mismos errores que todos los profesionales que describí anteriormente ya saben cómo resolver.

Moraleja de la historia: no es ciencia espacial, pero si no eres un ingeniero de la NASA, no intentes ir a la luna.

Tu objetivo nunca debe ser la complejidad. Debería ser para resolver problemas . La complejidad vendrá por sí sola; No tienes que buscarlo.

Una cosa que odio en la programación es el “síndrome de la nueva herramienta”, donde un ingeniero inexperto descubre un nuevo truco (¡herencia!) Que solo es lo correcto en raras ocasiones y decide aplicarlo en todas partes .

El código debe ser sencillo y casi aburrido . La auto-modificación o la reflexión irresponsable es “divertida” e imposible de leer. La paradoja (?) Es que este código emocionante se vuelve muy desagradable (y aburrido) para los lectores en la posteridad, porque no pueden obtenerlo, mientras que el código “aburrido” directo es realmente divertido de leer porque es mucho más fácil.

Hay dos cosas a tener en cuenta al comenzar un proyecto de desarrollo de software que aborda una necesidad comercial inmediata pero que anticipa que podría escalar con el tiempo.

1. Concéntrese en crear una solución que resuelva la necesidad comercial inmediata.

Varios otros han mencionado esto, pero no agregan complejidad innecesariamente. Una trampa común de los ingenieros inexpertos es sobre-diseñar un sistema tratando de anticipar problemas que puedan surgir en el futuro, y construir soluciones para aquellos como parte del proyecto inicial. Esto puede hacer que los proyectos tarden mucho más y sean mucho más caros de lo que realmente necesitan estar fuera de la puerta.

Obtenga el producto frente a los clientes lo más rápido posible, siempre puede iterar y agregar gradualmente características de una manera impulsada por el cliente más adelante.

2. Resuelva la necesidad comercial inmediata de una manera que no genere una deuda técnica significativa o que requiera un retrabajo significativo para escalar en el futuro.

Desde el primer día, debe escribir pruebas unitarias, documentación clara e interfaces limpias para todo su código. Hacer esto temprano agrega gradualmente al alcance del proyecto, pero reduce significativamente el reproceso y los defectos de software en el futuro.

Para resumir:

Concéntrese en resolver el problema de hoy de manera rápida y eficiente, y hacerlo de una manera que utilice las mejores prácticas de ingeniería y no cree grandes dolores de cabeza para escalar el producto en el futuro.

Suelte temprano y con frecuencia.

Puede pensar en el desarrollo de software como un algoritmo de escalada que explora un paisaje de valor entregado a los usuarios. Encuentre una forma muy pequeña de resolver los problemas de su usuario. Libéralo a ellos. A ver si ayuda. Luego repita el ciclo una y otra vez. Básicamente es este bucle:

Algunos libros que te dirán mucho más:

  • The Lean Startup: cómo los emprendedores de hoy usan la innovación continua para crear negocios radicalmente exitosos – Eric Ries
  • El Manual del propietario de inicio – Steve Blank
  • Programación extrema explicada – Kent Beck
  • Desarrollo de software Lean: un kit de herramientas ágil – Mary Poppendieck
  • Diseño basado en el dominio: abordar la complejidad en el corazón del software – Eric Evans

Hay compañías que lanzan hoy muchas veces al día. Etsy y Wealthfront son dos con excelentes blogs:

  • Código como artesanía
  • Ingeniería de riqueza

Personalmente, recomiendo contra equipos distribuidos para empresas que desean crear productos innovadores. El ancho de banda de comunicación reducido y el aumento de la latencia son un obstáculo importante para el tiempo de ciclo.

Si está lanzando temprano y con frecuencia, ha contratado bien y capacita al equipo para mejorar continuamente su proceso, descubrirá conjuntamente las mejores formas de construir su complejo software poco a poco.

Si estás trabajando en un prototipo durante una década, estás haciendo algo mal. 🙂

No creo que haya fórmulas secretas ni balas de plata. He trabajado en proyectos en los que he mirado hacia atrás y he dicho “caramba, desearía haber agregado una capa de abstracción anteriormente” y en ocasiones he mirado hacia atrás y dije “caramba, ojalá no hubiéramos desperdiciado todo ese tiempo en esta capa de abstracción inútil “. Tomarás algunas decisiones que salgan bien, y algunas que no.

Una cosa que he encontrado útil es tener ciclos cortos de retroalimentación. Eso es algo que me gusta de las metodologías “ágiles”. Cree características y prototipos que sean lo más simples posible, para que pueda ver cómo funcionan. Escriba pruebas unitarias que le permitirán saber que ha insertado un error lo más rápido posible. Es mucho más fácil que las cosas se salgan de control cuando tienes planes de proyecto de 6 meses o un año. Obviamente, si eres Boeing y trabajas en un nuevo avión, no puedes evitar proyectos de varios años. Pero es probable que no seas Boeing.

Suponga que las cosas cambiarán. Los requisitos cambiarán, el mercado cambiará, la tecnología cambiará. Póngase cómodo con eso lo mejor que pueda.

Con respecto al software de gestión de proyectos, necesita algo que pueda hacer un seguimiento de los elementos de trabajo (características, errores, refactorización), saber en qué están trabajando las personas y qué debe hacer para alcanzar el próximo hito. Para equipos pequeños, a veces es suficiente un muro con notas adhesivas. Probablemente querrás algún tipo de software de seguimiento de problemas, pero nunca he encontrado uno con el que estoy totalmente encantado. Juega un poco, mira lo que te gusta.

Oh, definitivamente use el control de versiones. Eso es obvio.

¡Buena suerte!

Creo que eres un ganador al hacer las preguntas correctas al principio. La gestión de proyectos, especialmente hacer que el software se haga correctamente ha sido mi área de fascinación e investigación a lo largo de los años. Podría ser parcial pero tengo dos consejos para su:

1. Ágil: ponte cómodo con tu equipo SCRUM o Kanban (sugiere SCRUM al principio). identifique los componentes / incrementos que se pueden enviar (algo que puede liberar a los usuarios, ya sea para usarlos o probarlos) no demasiado grandes y sacarlo cada mes o 2.
2. use una buena herramienta de gestión de procesos y colaboración, que también capture la colaboración y las discusiones entre el equipo. Desarrollamos productos para nuestros clientes en todo el mundo durante los últimos 12 años en BlastAsia, con un equipo de aproximadamente 100 miembros, y para ayudarnos con nuestras propias necesidades y varias otras como nosotros, desarrollamos Xamun, puede que les resulte útil (www.xamun.com )