methodology - tecnico - roles de un proyecto informatico
¿Qué tipo de proceso de desarrollo de software debe tener un desarrollador solitario? (9)
- Use Source Control para TODO
- Desarrolle las especificaciones y obtenga la firma antes de comenzar; habrá resistencia, pero explique que es por su propio bien.
- Pruebas unitarias! Duele porque solo quieres que se haga, pero esto te salvará a la larga.
- Utilice el seguimiento de errores - Bugzilla o FogBugz si puede pagarlo.
Trabajo como desarrollador solitario en una empresa muy pequeña. Mi trabajo es bastante caótico y estoy buscando formas de hacerlo más organizado.
Un problema es que mis proyectos prácticamente no tienen administración. Rara vez alguien me pregunta qué estoy haciendo o si tengo algún problema. En algún momento se habló de reuniones semanales de estado, pero eso fue hace algún tiempo. Parece que si quisiera algo así, tendría que organizarlos yo mismo. A veces estoy un poco perdido en lo que debería hacer a continuación porque no tengo tareas o un cronograma definido.
De libros y artículos, he encontrado muchas cosas que pueden ser útiles. Como tener un buen estándar de codificación (existe solo una guía de estilo aproximada que en mi opinión es anticuada), inspecciones de código, TDD, pruebas de unidades, base de datos de errores ... Pero en una empresa pequeña parece que no hay recursos ni tiempo para cualquier cosa que no sea esencial. El hecho de que trabajo en el dominio incrustado parece complicar las cosas.
Siento que también existe la costumbre de cortar esquinas y hacer cortes rápidos con poca antelación. Esto conduce a productos y errores no terminados y no profesionales que esperan emerger en una fecha posterior. Me imagino que también son un dolor para mantener. Por lo tanto, estoy a punto de heredar una base de código desafiante, hacer un nuevo desarrollo que requiere aprender muchas cosas nuevas y supongo que intentar construir un proceso para todo al mismo tiempo. Puede ser gratificante al final, pero como no tengo demasiada experiencia, no estoy seguro si puedo lograrlo.
En una tienda pequeña como esta el entorno está lejos de ser óptimo para la programación. Hay muchas otras cosas que se deben hacer ocasionalmente, como atención al cliente, contestar el teléfono, firmar parcelas, pruebas de hardware, ensamblaje y cualquier tarea miscelánea que pueda aparecer. Entonces entiendes la idea de los recursos. No todo es malo (a veces resulta esclarecedor resolver algunos problemas de los clientes) y creo que se puede mejorar, pero estoy realmente preocupado por las otras cosas.
¿Es posible tener un proceso de desarrollo en un lugar como este?
¿Ayudaría tener algún tipo de gestión? ¿Que tipo de?
¿Es posible hacer productos de calidad con pequeños recursos?
¿Cómo me convenzo a mí mismo y a los demás de que la compañía que ha trabajado con éxito durante décadas necesita cambiar? ¿Qué sería esencial?
Tal vez hay alguien trabajando en una tienda similar?
Además de las recomendaciones de otros, diría que si tienes pocos recursos pero tienes más información sobre cómo se hacen las cosas, deberías hacer un buen uso de los productos y bibliotecas de código abierto. Esto aprovecha los esfuerzos de otros, ahorrándole tiempo, asegura que su código base no se vuelva demasiado esotérico y lo amplíe a sus habilidades para que no termine siendo un experto en algo que es inútil en todos lados.
Estado allí, hecho eso.
El libro Planning Extreme Programming ayudó mucho. Usé tarjetas 3x5 pegadas en una pared. Esto mantuvo a mi jefe informado de mi progreso, me ayudó con las estimaciones y la planificación, y me mantuvo en el buen camino. El juego de planificación da buena munición si las expectativas de su jefe no son realistas.
Las pruebas unitarias, como han dicho otros, ayudan incluso si usted es un único desarrollador. Encuentro el estilo TDD valioso.
lod3n tiene toda la razón sobre el control de fuente.
He ido con iteraciones de estilo XP antes; Es posible que desee establecer una acumulación de elementos (incluso algo simple como una hoja de cálculo o tarjetas 3x5) también.
Evita los Death Marches Quédese con 40 horas en el sentido de no trabajar horas extra 2 semanas seguidas. Pase tiempo extra fuera del trabajo aprendiendo nuevas habilidades, no solo tecnologías, sino principios y mejores prácticas.
He decidido que no necesito pruebas unitarias porque puedo haber automatizado pruebas funcionales / de integración en su lugar : porque con el desarrollo incremental no hay necesidad de probar antes de la integración.
Mi consejo es no ser extremo. Desde mi experiencia, puramente ágil o tradicional pura no funcionará. Antes de usar cualquier proceso, sepa lo que significa resolver.
Yo personalmente uso una variación de Agile RUP . Hago algunos esfuerzos iniciales, como investigar las necesidades reales, hacer un diseño de alto nivel con una posible extensión. Y solicite al cliente que firme algunos requisitos importantes de alto nivel.
Si trabajas en un grupo pequeño, el diseño detallado o las especificaciones pueden no valer. Por supuesto, si hay algunas bibliotecas compartidas por muchos, valdrá la pena.
Decidir qué invertir en adelantado según su riesgo (probabilidad y efecto).
Además, muchas de las mejores prácticas de SW son realmente ''las mejores'' como el control de versiones, las pruebas automáticas (para mí, solo las utilicé para detectar la regresión de manera temprana, ya que no creo en TDD como la fuerza impulsora del desarrollo). Le sugiero que lea '' Programador Pragmático '' que presenta muchas de esas tecnologías.
Como para responderte preguntas:
(1) ¿Es posible tener un proceso de desarrollo en un lugar como este?
Sí, pero como digo, tráigalo para que se ajuste a su organización.
(2) ¿Ayudaría tener algún tipo de gestión? ¿Que tipo de?
La administración ayuda, pero no el control freak. Planifique qué hacer cuando: integre, resuelva el conflicto, línea muerta de una piedra de milla. Y más o menos mantenerlos dentro del cronograma (particularmente me gusta el sprint de Scrum).
(3) ¿Es posible hacer productos de calidad con pequeños recursos?
Definitivamente tan pronto como el tamaño del trabajo, el tiempo para desarrollarse y el tamaño del equipo sea equilibrado. Si tu definición de calidad es lo mismo conmigo. Para mí, Calidad significa: resolver el problema que se planteó de manera eficiente y confiable.
(4) ¿Cómo me convenzo a mí mismo y a los demás de que la compañía que ha trabajado con éxito durante décadas necesita cambiar? ¿Qué sería esencial?
Señala los problemas. Si no hay ninguno, ¿por qué cambiar? Si desea cambiar, debe poder identificar el problema O los problemas potenciales. Señala el problema.
Algunos grandes son:
Sin ningún proceso, es más difícil para los nuevos reclutados mezclarse ya que deben aprender de observar cómo lidiar con otras cosas.
Sin proceso, es más difícil trabajar en estrés.
Sin programación, es difícil determinar el progreso.
Sin pruebas automáticas, llevará más tiempo identificar los problemas y la regresión.
Sin el control de la versión, será más difícil deshacer el error y la separación del trabajo para cada miembro del equipo será un desastre.
Sólo pienso.
Necesita trabajar con el propietario y establecer metas a corto y mediano y largo plazo. Querrá dejarles saber el progreso aunque solo sea por correo electrónico.
Tendrá que imponer algún orden en su día laboral o nunca logrará hacer nada (esos objetivos a largo plazo).
Divida su día en trozos cuando puede codificar, cuando está trabajando en hacks para mantenerse separado, al responder correos electrónicos, etc.
Definitivamente configura un rastreador de errores. Esto puede ayudar a mantener su correo electrónico limpio. Incluso puede configurar una dirección de correo electrónico para reenviar errores que se categorizarán más adelante. Esto es bueno porque los reporteros de fallos eventualmente se cansarán del rastreador de errores y de todos modos querrán enviarte los errores por correo electrónico.
editar
Y como dijo lod3n, el control de la fuente, pero ¿estás usando eso ya? ?? !!?!
Primero, hagamos una distinción entre un proceso de desarrollo y las mejores prácticas. Las mejores prácticas como el control de origen, el seguimiento de defectos, las pruebas unitarias, etc. son un hecho.
Luego están los procesos de desarrollo reales. Siempre recomendaría tener un proceso, sin importar si el equipo es pequeño o grande. El truco es encontrar el proceso correcto. Ahora tiene un proceso: es solo un proceso ad-hoc que no parece funcionar demasiado bien para usted. Rara vez puede tomar un proceso de desarrollo de libros de texto y aplicarlo directamente. Lo que debe hacer es adaptar el proceso a las necesidades y cultura de su empresa. Mire tantos paradigmas de desarrollo como pueda y trate de encontrar algo que se ajuste bien y empiece a moldearlo según sus necesidades. Puede que tenga que intentar y fallar con una cantidad de procesos diferentes. Tal vez el proceso de software personal será un buen proceso de inicio, tal vez un proceso ágil, una variante de RUP. Tienes muchas opciones, comienza a probarlas.
También tendrá que trabajar con el resto de su organización: deben ser parte del proceso. Puede ser el desarrollador solitario, pero un proceso de desarrollo implica más que el desarrollador, involucra a cualquier persona que tenga voz o impacto en el producto.
Puede que esta no sea una respuesta específica, pero mi punto es que necesitarás algún tipo de proceso. Así que comience a investigarlos y probarlos y moldearlos según sus necesidades hasta que tenga algo que funcione.
Tan loco como esto suena, uso scrum solo porque me gustan los conceptos de sprints y atrasos. Hace que sea más fácil establecer objetivos realistas. Por supuesto, la idea de scrum master y el equipo es todo tuyo, pero si trabajas en proyectos externos en los que es posible que puedas elegir a un miembro adicional del equipo con tus atrasos, será fácil distribuir el trabajo. Quizás solo me gustan los atrasos. Con scrum, necesitará que alguien sea el gerente de producto para hablar sobre las características del producto. El control de la versión es una necesidad que probablemente debería implementarse, incluso preocupándose por un proceso de desarrollo de software. He trabajado en una empresa que comenzó con 2 desarrolladores y llegó a 12 en un año. Comenzamos sin estándares de control de versiones y bajo nivel de codificación. Los cambios que deberá realizar serán graduales, por lo que no debe preocuparse por apresurarse a hacer un 180. Establezca un objetivo para cambiar algo por mes y encuentre partidarios de los cambios para que las cosas funcionen sin problemas.
Tener un sistema de seguimiento de errores, tanto para defectos como para nuevas características. No confíes en tu memoria.
La integración continua y una compilación automatizada pueden ayudar incluso a un único desarrollador.
No puedo enfatizar lo suficiente la recomendación de control de fuente.