research - methodology types
Desarrollando por su cuenta (17)
En mi compañía, cada desarrollador recibe un proyecto para trabajar por su cuenta, por lo que casi no hay trabajo en equipo. He estado construyendo un software como este, sin la disciplina de una buena metodología de desarrollo, durante un año. Los resultados fueron buenos, pero me gustaría cambiar y comenzar a utilizar un enfoque de desarrollo más serio para mis próximos proyectos.
¿Cuáles considera que serían las mejores prácticas para desarrollar software por su cuenta? ¿Qué metodologías podría usar para evitar trampas comunes en el desarrollo de software? ¿Qué modelos de desarrollo de software (cascada, estoy bromeando, extremo, ágil, etc.) son los más adecuados para mí?
Estaría muy feliz si me apunta a algunos recursos o tutoriales donde podría aprender a ser un mejor desarrollador :)
Gracias.
¡No caiga en la trampa de no documentar su código! Creo que es uno de los consejos que se olvida fácilmente, porque, oye, tú escribiste el podría por lo que debes saber lo que hace, ¿verdad? ... ¡mal! solo retome uno de sus proyectos de antaño y descubra cómo funcionaban las cosas sin utilizar ningún tipo de documentación, es como leer el código de otra persona (mala).
Siempre me animo a usar un estilo de documentación estándar , como javadoc para Java o el equivalente para .NET en el código, pero realmente cualquier tipo de documentación es mejor que ninguna ...
@Kyle
El viejo se lo explica a ti mismo a través de notas en un archivo rouse eh? Para mi horror, vi este comentario en la parte superior de mi código anterior el otro día:
/*
bloody hell - where to start...
*/
@reefnet_alex
Tienes toda la razón: el proceso de articular, incluso si es para ti o para un muñeco de peluche, es maravilloso para pensarlo bien. Personalmente, escribo un monólogo tipo blog en un archivo cuando trato de resolver algo. Esto tiene la ventaja adicional de poder consultarlo cuando sea necesario.
En cuanto a otras estrategias, creo que lo mejor es mantener una lista de TODO. Si me quedo atascado en una cosa, simplemente paso a otra cosa en la lista de tareas pendientes.
Creo que la mayoría de las metodologías de desarrollo "completas" como xp y similares se centran en canalizar y agilizar la comunicación entre los miembros del equipo.
Si se desarrolla en un equipo de "una sola persona", no hay ningún beneficio en las reuniones diarias de scrum y en uno mismo ;-) Por lo tanto, debería ser suficiente si se atiene a algunas de las mejores prácticas como "use control de versiones". "etc. Los libros" Programador pragmático "y" ¡Enviarlo! " podría darle una buena visión general de algunas prácticas que vale la pena seguir, ya sea que trabaje en equipo o solo. Al menos lo hizo por mí.
Para que quede claro, necesitará algún tipo de estructura o plan para su proyecto ANTES de comenzar a codificar, pero algo como una simple lista de tareas y un bosquejo sin procesar del diseño de software planeado servirá.
Cuando eres el único que trabaja en un proyecto / problema, la comunicación debe ser buena, por lo que las formalidades no son realmente necesarias para eso. Sin embargo, como se menciona en otras publicaciones, las buenas prácticas como el control de versiones aún se aplican. Rebotar ideas de alguien también ha sido crítico para mí.
Aunque la comunicación no es un problema cuando se trabaja solo, me ha resultado útil en algunos casos utilizar post-it y crear una tabla de scrum personal. Recientemente, me mudé de una empresa orientada al equipo a una que está lejos de serlo, y es una transición difícil.
Solo otro pensamiento en la línea de cómo llegar a la solución ... el libro Conceptual Blockbusting tiene algunas buenas observaciones sobre cómo resolver mejor los problemas.
Cuando trabajé como desarrollador de préstamos, uso XP, junto con Joel haciendo las cosas cuando solo se trata de un artículo gruñón para mantenerme en el buen camino.
Lo traté como un ejercicio de aprendizaje que podría integrar en el equipo si pudiera demostrar que la aplicación de ''mejores prácticas'' tuvo un buen retorno de la inversión. que, si bien se otorga a buenos desarrolladores, es algo que aún debe probarse; bueno al menos en mi experiencia.
Más tarde utilicé un proceso ágil personalizado que encajaba mejor con la política de la empresa para la que trabajaba.
Echa un vistazo a The Joel Test . Implementar estas prácticas como desarrollador independiente ha sido un desafío gratificante.
Es muy difícil desarrollar software por su cuenta, tener otro ser humano para intercambiar ideas hace que las cosas sean mucho más fáciles / más satisfactorias. Pero, aquí está el truco: esa otra persona realmente no tiene que estar tan al tanto de lo que estás haciendo. Simplemente explicarle cosas a otra persona a menudo te da una idea de lo que estás haciendo.
Solía trabajar con alguien que recomendaba "hablar con Teddy", es decir, elegir tu peluche favorito (Mr Binky), explicar los pormenores de la nueva API RESTful en la que estás trabajando para Mr Binky. Da una palmada en la cabeza cuando un cegador destello de inspiración te golpea: "¡Caramba, sabía que necesitaba otro recurso allí, gracias Binkster!".
Eso sí, no estoy seguro de la cordura de tus colegas ...
Para un enfoque más razonado, ¿no podría formar una alianza suelta con otro desarrollador en el que rebote sus proyectos el uno del otro, incluso si luego vuelve a trabajar en forma aislada?
He estado trabajando por mi cuenta durante años. Primero como parte de un grupo de ingenieros mecánicos. Ahora en mis propios proyectos. Estoy de acuerdo con las respuestas anteriores:
Habla con alguien (cualquiera) sobre lo que estás trabajando. Los ojos de mi esposa se vuelven vidriosos rápidamente, pero ella intenta hacer preguntas aclaratorias. Normalmente las preguntas no tienen sentido, pero finjo que ella es mi jefe y las respondo de todos modos. Encuentro todo tipo de soluciones de esa manera.
Las metodologías de desarrollo son en su mayoría exageradas para un equipo de 1 persona. Aunque adopté un par de prácticas ágiles. Primero, calcule todo en pequeños trozos de tiempo, no más de medio día. Segundo, divida su trabajo en pequeños "sprints" de tres o cuatro semanas. Utilizo FogBugz para todas mis estimaciones y programación (hay una versión alojada gratuita para grupos de 1 a 2 personas).
No olvide los elementos esenciales de la documentación del código, control de fuente y prueba de unidad. Yo uso Doxygen, Subversion / TortoiseSVN, y NUnit respectivamente.
Si sientes que la práctica no es óptima, y hay otros que piensan lo mismo, ¿por qué no comenzar a cooperar un poco? Si su empresa es particularmente rara y no quiere que los desarrolladores aprendan unos de otros, creo que debería considerar seriamente un empleo alternativo: probablemente no sea lo mejor que podría ser en un entorno como este.
Ahora que he sugerido que estás haciendo la pregunta incorrecta;) hay un buen punto de partida para la agilidad del desarrollador en solitario en el C2 Wiki
Sugeriría que además de usar SCM, use un rastreador de problemas. Aunque puede terminar gastando un poco más de tiempo agregando cosas que deben hacerse, proporciona un registro concreto de su progreso, en un formato más fácil de seguir que los registros de cambios de su control de revisión.
También te da tibios borrosos cuando tachas cosas de tu lista. Lo veo como una extensión de una lista de TODO.
Una gran parte de la mayoría de las metodologías está definiendo cómo puedes trabajar en equipo. Una gran parte de la programación ágil / extrema, etc. se trata de comunicación, configuración de su entorno de equipo y más de esas cosas. Si trabajas solo algunas cosas son más fáciles y algunas cosas (programación de pares, por ejemplo) son más difíciles.
Intente leer un par de metodologías y elija las prácticas que cree que necesita. Si eres un equipo de un solo hombre, tienes el lujo de ser muy flexible. Así que trate de no dejar eso solo para seguir una metodología que pretende hacer que los equipos grandes trabajen juntos. Así que solo elija las prácticas que realmente necesita. Los adelgazamientos como TDD y el trabajo en iteraciones son la fruta más fácil de colgar. Solo sigue evaluando lo que haces y sigue mejorando.
Utilice el control de versiones, siempre deje el día con el código compilado como mínimo y siempre realice el check-in. Trabajé durante muchos años en relativo aislamiento en una organización más grande, naturalmente apliqué lo que comúnmente se denomina prácticas de desarrollo Agile. Consigue algo que funcione, no importa cuán duro sea, el refactor, y repite.
Mantener un estado estable ayuda mucho, significa que cuando puedes interactuar con alguien, tienes algo que demostrar en lugar de una colección de ideas y conceptos abstractos.
Estoy de acuerdo con que "programador pragmático" es una gran lectura.
Parece que tienes la parte del código bajo control, pero solo porque eres el único desarrollador, necesitas administrar cómo trabajas con usuarios, administración, administradores de red, etc. Soy el único programador de nuestra firma, pero constantemente interactuar con otros en proyectos determinados. Probablemente estén más interesados en la documentación, la recopilación de requisitos, las pruebas y la depuración.
He hecho una pregunta similar antes , puede encontrar algunas buenas respuestas allí.
Muchas gracias por tus consejos:
Intento documentar mi código tanto como puedo, usando estándares comunes. Intento pensar en el pobre tipo que tal vez algún día vendrá y tendrá que mantener mi código (quién sabe, ¡tal vez ese tipo podría ser yo!).
Yo uso control de fuente Eso es imprescindible para mí y simplemente no puedo trabajar sin eso.
Pruebas unitarias (¿no es esta la tercera pilar?) ... Bueno ... no hago ninguna prueba unitaria :(, y esa es una de las cosas que me gustaría cambiar para proyectos futuros.
Cuando diseño intento tomar notas de todos mis pensamientos internos (es más o menos como hablar con tu peluche, ¿no?).
También tengo una lista TODO. Me pregunto si hay alguna aplicación (o aplicación web) para supervisar mejor todas estas tareas.
Echaré un vistazo a algunas de las metodologías modernas e intentaré incorporar algunas técnicas a mi propia metodología. Esto parece realmente interesante.
Ahora también estoy pensando en instalar Cruise Control en mi máquina, pero ¿realmente valdría la pena para mí?