Ágil (SCRUM, XP, FDD, ...), Cascada, RUP, ... ¿Por qué una pequeña empresa se molestaría en adoptar una en primer lugar. ¿Por qué no simplemente piratear cada proyecto hasta su finalización (con un tamaño de equipo habitual de 1 ~ 2)?¿Por qué adoptar un proceso de desarrollo de software?
Estoy preparando una breve presentación en contra del argumento pero me gustaría escuchar lo que todos piensan.
Ooh, mi tipo de pregunta favorita. Cada vez que surja el SDLC, la respuesta adecuada es siempre: "¡Depende!" :) Odio esa respuesta tanto como todos, así que profundicemos más.
Si sus proyectos son manejables por una sola persona y muy cortos (es decir, < 3 meses), entonces ningún proceso formal probablemente tenga sentido. Los PRINCIPIOS de algunos de los procesos son importantes, pero la mayor parte de la ceremonia se puede abandonar de manera segura. Por ejemplo, de una manera Agile-y, aún seguiría tarjetas que tenían historias técnicas (una oración más o menos), historias de usuario (una oración o dos), tareas, etc. así que no dejaría caer la pelota en nada . No haría iteraciones necesariamente, solo rolling-wave. Si sabe que tiene alguna fecha difícil para una versión beta/vista previa/lo que sea, entonces puede planificar su ola de forma acorde eligiendo la prioridad de las tarjetas en las que está trabajando semana tras semana.
Uno de los beneficios de tener ALGÚN proceso es que probablemente deje algunos artefactos de planificación/gestión (tarjetas no utilizadas, retraso acumulado, etc.) por lo que si usted u otra persona necesita reanudar el desarrollo del proyecto, puede volver a recogerlo fácilmente.
Un proyecto de 6 meses o más con 2 o más personas definitivamente debe tener algún tipo de proceso para evitar que las cosas se vuelvan demasiado caóticas y desincronizadas entre los miembros del equipo. Los stand-ups son importantes aquí, al igual que las tarjetas de tareas y la responsabilidad.
Todo esto, por cierto, es gestión/proceso de proyectos. Incluso en un equipo de 1 hombre, seguiría usando control de fuente, integración continua, TDD, etc. Esta es una necesidad para el software de calidad, independientemente del proceso que esté utilizando para la asignación de tareas.
"hackear" es ¡un proceso de desarrollo, simplemente no es fácil de rastrear o predecir!
el punto del proceso es la consistencia y previsibilidad
Verdad. Si bien los reintentos de ingeniería de software aún son en gran parte impredecibles, seguir una metodología que dice "prueba tus cosas" puede producir cosas un poco más predecibles :) –
La respuesta de @chadmyers es mucho mejor. Una lista de verificación/bag-o-tricks es mucho más flexible que una 'metodología' rígida –
consistencia es la clave. Si pasa de un proyecto a otro simplemente "pirateando", le tomará más tiempo a un compañero de trabajo (o especialmente a un nuevo empleado) acelerar el proyecto, que si existen estándares y convenciones. Realmente no importa qué estándares/metodología elijas, siempre y cuando elijas uno que funcione para tu equipo y lo uses de manera consistente.
Pero, ¿no sería un 'marco' más relevante en tal caso? – tamersalama
Si el proceso de "pirateo informático" permite a la pequeña empresa ofrecer lo que sus clientes desean y un costo con el que el cliente está satisfecho, la empresa no debería molestarse en adoptar ningún otro proceso, obviamente.
Por supuesto, el problema es que piratear, incluso en una empresa pequeña, hace que la producción de estos resultados sea más difícil. Además, si la empresa o sus aplicaciones buscan crecer, la piratería se volverá rápidamente insostenible.
Utiliza un proceso de software para administrar el tiempo y los recursos del proyecto. 'Hackear' está bien para un proyecto de una sola persona en el que no le importa si lo que produce es un presupuesto excesivo, entregado o pasado todos los plazos y no cumple con los requisitos del cliente *. Para los proyectos que realmente se preocupan por estos, se presenta un proceso de software como una capa de gestión.Los gerentes pueden entonces monitorear más efectivamente el ciclo de vida del desarrollo, enfocar el esfuerzo en las tareas identificadas como críticas, importantes, etc., proporcionar retroalimentación al cliente sobre en qué etapa se encuentran y todo lo demás que parece no tener importancia para los desarrolladores, sino los clientes aman porque muestra que en realidad estamos haciendo algo que creen que es útil :)
* No estoy sugiriendo que estas sean siempre consecuencias de piratear o que un proceso más estructurado las elimine. Se llaman mejor áreas de "mayor riesgo" del método de pirateo y, por lo tanto, un proyecto que simplemente piratea y piratea y piratea casi no importa si se producen o no :)
Supongo que la misma razón que por qué existe es un proceso para construir autos y construir casas?
La adopción de un proceso de desarrollo puede reducir la cantidad de veces que dices "Oh, debería haber pensado en eso".
Si un proyecto de "cortar lejos" no ocurre esto:
"lazy programmers, they should work harder""next time I will really do unit testing" o "we should have taken *this* tools or *that* language...""Bye everybody, I'm leaving"Y si un proyecto en ejecución "pirateando" demora, los gerentes tienden a agregar más personas al proyecto. De there es el dicho: "I need this baby in a month send me nine women!"
Lo complicado es adaptar un proceso existente para su empresa y equipo:
Aun cuando no se dan cuenta, que ya tiene un proceso de desarrollo. El punto más sobresaliente de observar el amplio mundo de los procesos es aprender que otros han encontrado formas de hacer que su trabajo sea más productivo. ¡Quizás tú también puedas!
La mejora del proceso es la base del proceso. El objetivo de adoptar un proceso es aprender a mejorar sistémicamente para que las mejoras no hagan pedazos el trabajo.
El hecho de que solo haya dos personas en el equipo no es la barrera de entrada. Utilizo los principios de Lean y Kanban incluso en proyectos que hago como equipo de un solo hombre. Puedo beneficiarme de esto porque aprendí de ellos y, a partir de ese aprendizaje, mi mente se abrió a formas de ser más productivo que no había concebido en el pasado.
Si ya sientes que no tienes nada que mejorar, entonces probablemente no necesites buscar procesos fuera de lo que ya estás haciendo. Si realmente te sientes de esa manera, trata de observar tu estado emocional en detalle cuando tienes pensamientos en tu mente de explorar procesos de desarrollo.Si tiene el más mínimo momento de estrés cuando hace esto, es posible que retroceda ante la percepción del trabajo involucrado en lugar de los beneficios de aprender del trabajo y la exploración de los demás. Ese tipo de retroceso psicológico inherente no es raro, pero rara vez es útil cuando se enfrenta con una pregunta significativa.
Supongo que todo lo que se puede automatizar debe existir incluso para equipos de 1 hombre, ya que es prácticamente gratuito y ahorra una gran cantidad de problemas. – rshimoda