¿Qué tipo de proceso de desarrollo de software debe tener un desarrollador solitario?

Question

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.

Creo 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 fabricar productos de calidad con pequeños recursos?

¿Cómo me convenzo a mí mismo y a los demás de que la empresa que ha trabajado con éxito durante décadas debe cambiar? ¿Qué sería esencial?

¿Tal vez hay alguien trabajando en una tienda similar?

Answer 1

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 de detalle o las especificaciones pueden no valer la pena. Por supuesto, si hay algunas bibliotecas compartidas por muchos, valdrá la pena.

Decidir qué invertir de antemano en función de su riesgo (probabilidad y efecto).

Además, muchas de las mejores prácticas de SW son realmente "mejores" como el control de versiones, las pruebas automáticas (para mí solo las utilicé para detectar regresiones porque no creo en TDD como fuerza motriz del desarrollo). Le sugiero que lea 'Pragmatic Programmer' que presenta muchas de esas tecnologías.

En cuanto a contestar las 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 controla el fenómeno. 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 es el equilibrio. 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ñale 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 grande son:

• Sin ningún tipo de proceso, es más difícil para los nuevos reclutados para mezclarse ya que deben aprender de la observación de otra manera de hacer frente a las cosas.

• Sin proceso, es más difícil trabajar en situaciones de 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 control de versión, será más difícil deshacerse de un error y la separación del trabajo para cada miembro del equipo será un desastre.

Just my though.

Answer 2

1. Usar el Control de fuente para todo
2. desarrollar especificaciones y obtener visto bueno antes de empezar - habrá resistencia, pero explica que es por su propio bien.
3. Pruebas unitarias! Duele porque solo quieres que se haga, pero esto te salvará a la larga.
4. Utilice el seguimiento de errores - Bugzilla o FogBugz si puede pagarlo.

Answer 3

Tienes que 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 hacer cumplir un poco de orden en su día laboral o nunca logrará nada (esos objetivos a largo plazo).

Durante el día, en trozos cuando se puede código, cuando se está trabajando en los cortes para evitar que Togther, al responder a mensajes de correo electrónico, etc.

Definitivamente configuración de un gestor de fallos. 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.

edición

Y como lod3n dijo, control de código fuente, pero se están utilizando ya la derecha ??? !!?!

Answer 4

Tiene 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.

Answer 5

He decidido I don't need unit tests because I can have automated functional/integration tests instead: porque con el desarrollo incremental no hay necesidad de probar antes de la integración.

Answer 6

En primer lugar, 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; es necesario que forme 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.

Answer 7

He 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 indicado otros, ayudan incluso si usted es un único desarrollador. Encuentro el estilo TDD valioso.

lod3n tiene toda la razón acerca de Source Control.

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.

Evite los ataques mortales. 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.

Answer 8

tan loco como esto suena Yo 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.

Answer 9

Además de las recomendaciones de otros, diría que si tiene pocos recursos pero tiene más opiniones sobre cómo se hacen las cosas, debería 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.