Scrum para un solo programador? [cerrado]

Me califican como el "Experto de Windows" en mi empresa muy pequeña, que consiste en mí mismo, un ingeniero mecánico que trabaja en ventas y capacitación, y el presidente de la compañía, que trabaja en una función de diseño, desarrollo y soporte.

Mi función es igual de general, pero principalmente diseño e implemento cualquier programación en nuestro producto que se debe hacer para que nuestras cosas se ejecuten en las versiones de Windows actuales.

Acabo de terminar de ver una descripción general de alto nivel del paradigma Scrum, dada en un webcast. Mi pregunta es: ¿Vale la pena mi tiempo para aprender más sobre este enfoque para el desarrollo de productos, dado que mis elementos de trabajo de desarrollo generalmente se dan a un nivel muy alto, como "internacionalizar y localizar el producto".

Si es así, ¿cómo sugeriría adaptar Scrum para el uso de un solo programador? ¿Qué herramientas, basadas en la nube o de otro tipo, serían útiles para ese fin?

Si no es así, ¿qué enfoque sugeriría para que un solo programador organice sus esfuerzos día a día? (Quizás la pregunta se reduce a esa simple pregunta).

Aprende Scrum: sí. Aunque solo sea para aprenderlo, agregarlo a tu conjunto de habilidades generales. (pero el sabor de "Scrum-ban" es probablemente lo que estás buscando ...)

Scrum es un buen marco, pero un principio básico es "Las iteraciones (Sprints) serán de duración fija" Nunca he visto este trabajo en equipos muy pequeños que están más impulsados ​​por interrupciones que no. Si realmente puede inscribirse y comprometerse a trabajar en un horario fijo (¿1 semana?), Entonces Scrum es un marco genial. Si no puede ... entonces es bueno aprender sobre Scrum porque tiene algunos buenos conceptos que se traducen bien en otras cosas ... como ...

Retraso: Scrum o no, mantenga una lista priorizada de las cosas que debe hacer. Me gusta Excel (o la hoja de cálculo de Google Doc ...) Puede que le guste algo más Mantendría una herramienta muy pequeña si eres un equipo muy pequeño. (Hoja de cálculo >> Procesador de textos porque puede ordenar fácilmente).

Separación de planificación y compromiso: planifique en una notación abstracta (puntos) y sea coherente (8 puntos es aproximadamente 2x una historia de 4 puntos y 4x una historia de 2 puntos) Cuando es hora de "hacer el trabajo", vuelva a analizar el problema y esboce En horas. No cambies los puntos.

Compromiso: sea visible para los demás cuando se comprometa y cumpla con sus compromisos

Retrospectiva: después de haber entregado, reflexione sobre lo que podría haberse hecho mejor.

etcétera etcétera.

Scrum es bastante fácil de entender que podría ser un buen punto de partida. Si te gusta, consideraría usar la variante "Scrum-ban": http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Nada más me parece "tan bien documentado" con una comunidad razonablemente activa para apoyarlo.

Me encantaría recomendar también las metodologías Crystal de Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer y http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Pequeño / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), pero implica mucho más lectura y excavación.

Cosas como XP proporcionan más detalles sobre prácticas específicas, por lo que también diría que lea el libro: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= libros & ie = UTF8 & qid = 1304359834 & sr = 1-1

Consejo de lectura final: siempre que esté de acuerdo con el manifiesto ágil y siga los principios: http://agilemanifesto.org/principles.html , debe estar en buena forma.

Recomendación personal: adoptar TDD (no negociable, en mi humilde opinión) Mantener una cartera de pedidos (según Scrum) Mantener siempre el tamaño y la clasificación por prioridad dos elementos tienen la misma prioridad. siempre.) Haga que su entorno de compilación sea capaz de construir / probar / implementar (en entornos de laboratorio) en 5-10 minutos Muestre a sus clientes (internos y externos) los resultados de terminar una historia La historia no se termina hasta Su cliente está de acuerdo. Extraiga historias de la parte superior de la pila y trabaje en ellas a medida que completa la historia actual. No mantenga abiertas más de 2 cosas a la vez. Termina una distracción antes de comenzar otra.

espero que esto ayude

Puede usar algunas prácticas utilizadas en Scrum, como la acumulación de productos, la priorización, la estimación relativa, la entrega incremental, pero usar Scrum completo como un proceso para administrar el desarrollo del producto por un equipo de miembros multifuncionales autoorganizados probablemente no sea la mejor opción para una exposición individual .

La pregunta es si puede dividir sus elementos de trabajo en piezas pequeñas que se pueden entregar de forma incremental. Si no usa la mayoría de las prácticas no tiene sentido. También Scrum se trata de una alta cooperación con el propietario / cliente del producto. No debería ser como: "Aquí tienes una tarea y regresa una vez que está hecha".

Si bien no diré nada a favor o en contra de Srum de 1 hombre, diré que un sistema de extracción Kanban de 1 hombre funciona muy bien. Kanban, combinado con Unit-Testing automatizado, me ha hecho mucho más productivo y "documentado". Aunque tampoco son realmente metodologías, pero más herramientas (y muy diferentes en eso), ambas me obligan a dividir grandes proyectos en solitario en pedazos pequeños, y también me dan una especie de ritual para alentarme a hacer más cosas cada uno día. No hay nada tan satisfactorio como hacer clic en "ejecutar todas las pruebas" y ver que cada elemento se vuelve verde ... nada excepto tomar una tarjeta de la columna "En progreso" en mi tablero Kanban a "En prueba" (o fuera del tablero por completo) .

Creo que el verdadero problema con el trabajo en solitario es que tiene que elegir entre múltiples metodologías, que realmente están destinadas a grupos de desarrolladores, y adaptarlas para que se adapten mejor a usted. El objetivo final es realmente mantenerlo responsable, productivo y feliz. Quién sabe cómo hacerlo mejor que tú (con un poco de aquí y otro de allá).

Intenté esto cuando estaba trabajando solo en un punto. Las cosas que funcionaron bien fueron:

1. Tener todos los elementos de trabajo en una pizarra. Pude ver muy rápidamente qué trabajo sobresaliente había allí; donde estaban las dependencias y bloqueos. Además, mucha gente se detenía en mi pizarra y la leía, y teníamos una conversación al respecto. Creo que les ayudó a entender lo que "el geek" estaba haciendo todo el día ;-)
2. El cuadro de quemado también fue genial. Acabo de usar Excel para esto. Me permitió mejorar en hacer estimaciones en ese entorno. Me dio una gran visión general de hacia dónde me dirigía con la iteración. A mi gerente, que no era una persona técnica, también le encantó esto, ya que podía ver todas las diferentes cosas involucradas en una función y dónde estaban.
3. Stand up diarios. Bueno lo mejor que pude. Cada mañana, actualizaba todos los elementos de trabajo y el cuadro de quemado e hice una nota de todos los impedimentos que debían resolverse.
4. Las pruebas automatizadas y la integración continua (MSTest / TFS), preferiblemente TDD, ayudarán a cualquier equipo de desarrollo, utilizando cualquier metodología, pero vale la pena mencionarlo aquí.
5. Las iteraciones cortas (1 semana) realmente me ayudaron a concentrarme en entregar algo.
6. Mantener un trabajo atrasado fue excelente, ya que cuando me dieron un nuevo trabajo pude ubicarlo en el contexto de todo el otro trabajo y lograr que el propietario del producto vuelva a priorizar.

Lo que no funcionó fue:

1. Trabajando solo, nunca obtienes ese impulso de colaborar con personas de ideas afines; o ese sentido de competencia y enfoque que proviene de un equipo con una moral y cultura realmente grandiosas. No hay otros cerebros para elegir cuando te quedas atascado, por lo que los bloqueos como ese no pueden ser eliminados por un maestro de scrum en el stand up diario.
2. No hay scrum master, por lo que no hay nadie para detener las interrupciones. Tuve muchos problemas con la gente que constantemente hacía preguntas sobre otras cosas y rompía mi flujo. Bajo un buen scrum master, cosas como esas se interceptan y puedes seguir adelante. Nunca quise ser grosero con la gente (tal vez soy blando), así que fue un problema. Además, sin un scrum master puedes desviarte del proceso fácilmente.

Fue un ejercicio interesante, pero dejé de hacerlo después de un rato. Creo que los beneficios de Scrum deberían verse en contraste con los equipos de cascada tradicionales. Pero ambos son un poco discutibles cuando estás solo. No hay problemas de comunicación ni de colaboración: solo debe trabajar en el trabajo que se establece y listo.

Creo que todos deberían mantener un registro de respaldo y hacer TDD sin embargo.

Elementos de Agile / Scrum / Kanban que creo que tienen sentido en un solo mundo de desarrolladores:

1. Tenga un tablero en el que organice sus historias de usuario / artículos activos pendientes, en fichas, como kanban.

2. Obtenga la aceptación de los no desarrolladores sobre el valor de estos principios:

   • Dame tiempo para trabajar sin cambiar mis prioridades sobre mí o micromanaging (el punto de los sprints). Dame tiempo e intentaré averiguar de antemano exactamente cuánto puedo hacer, y haré todo lo posible para hacerlo.

   • Si necesito algo (me bloquean), y vengo a ti, y no puedes arreglarlo por mí, entonces el sprint podría tener que cancelarse de manera anormal. (Eso solo significa que necesitamos un nuevo plan).

   • Nadie cambia nada en medio del sprint. O, si lo hacemos, simplemente cancelamos el sprint y creamos uno nuevo. Si esto sucede mucho, la productividad cae.

   • La comunicación entre las personas que son partes interesadas puede realizarse en reuniones periódicas de stand-up diarias, que comunican la mayoría de las mismas cosas que sería un scrum regular, incluidos los logros de su desarrollador por el día. Esencialmente, puede informar cosas que tomaron más tiempo de lo que pensaba, o que salieron bien, y cualquier ajuste que esté haciendo a sus planes de implementación. (Encontré cuatro errores nuevos y los registré, creo que son más importantes que esta característica opcional, por lo que creo que pasaré el tiempo y los solucionaré y eliminaré esta característica opcional).

He trabajado mucho como desarrollador único, y puedo decir con certeza que la confianza entre el desarrollador único y sus supervisores / jefes no desarrolladores, y la buena comunicación son las claves, no una metodología. Pero siempre puedes ser más efectivo si sigues buenos principios.

He leído un blog sobre esto y creo que puede ayudarte con tu pregunta.

Primera parte: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Segunda parte: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Puede encontrar más información en este blog.

De ninguna manera estoy conectado; solo algo que tenía en mis favoritos. Espero que te pueda ayudar.

Sí. Y tenga en cuenta que el Scrum no tiene que incluir herramientas sofisticadas, puede ser una simple reunión de 15 minutos en la que todos hablan sobre en qué están trabajando. La ventaja de Scrum es que todos saben lo que está sucediendo, y eso hace que sea más fácil resolver problemas antes de que surjan y anticipar problemas en el futuro.

A muchas de estas respuestas les falta un punto importante.

Un equipo scrum no necesita estar compuesto únicamente por programadores.

Uno de sus colegas hace 'diseño' / 'desarrollo' y uno hace 'ventas'.

Quizás su colega de 'ventas' pueda ser dueño de un producto (proxy). ¿Cuáles son las expectativas del cliente?

El diseño y desarrollo de su otro colega realmente me suenan como disciplinas del equipo scrum. El desarrollo de Scrum no es gradual sino vertical (requisitos de planchado, diseño e implementación en un sprint).

Podrían hacer el proceso de scrum con ustedes tres.

¿Qué se necesita para hacer 'esto'? Las reuniones de planificación de sprint de Scrum se acercan a la pregunta de qué es 'esto'. ¿Qué espera ver el propietario del producto para que se considere hecho?

Durante una reunión de planificación de sprint, puede brindarles a sus colegas un contexto sobre por qué 'internacionalizar y localizar el producto' podría ser técnicamente difícil de implementar.

Toneladas de razones para usar scrum imho.

Sugeriría probar Kanban y comenzar con los conceptos básicos: visualización y limitación del trabajo en progreso (WIP).

Incluso si lo interrumpe más tarde, será más ágil en el proceso. Y aunque Kanban es bueno para el desarrollo de software "normal", Kanban + un proceso basado en el flujo (a diferencia de las iteraciones) eclipsa a otras herramientas de proceso cuando tiene una situación con el desarrollo de nuevas características y mantenimiento.

Respaldo la recomendación del libro Kanban de David Anderson, y también puedes echar un vistazo a mis diapositivas de una reunión local sobre por qué y cómo comenzar con Kanban simple , o crisp.se/kanban para una breve introducción.

Para su contexto, tengo algunas ideas:

• la visibilidad es la clave, así que mejor use una pizarra blanca física que una herramienta digital si no puede mostrarla en una pantalla (grande) permanentemente (si está ubicado)
• Comience con su proceso actual
• comience solo con su esfera de influencia, incluidas las fases de transferencia aguas arriba y aguas abajo (convirtiéndose en cola para usted, por ejemplo, características diseñadas listas para el desarrollador, o en cola de usted, por ejemplo, características terminadas, listas para la venta)
• Si sus colegas están interesados ​​en ampliar la visualización ascendente o descendente, mucho mejor. Tal vez termine visualizando todo el flujo de valor (o red) para su empresa, es decir, cómo fluye el valor del concepto al efectivo
• minimizar la multitarea (!) limitando WIP. Si el flujo de trabajo es visible para sus colegas, deben entender por qué y ver fácilmente qué hay en su plato.
• quizás sea útil separar el trabajo en 3 o 4 tipos de trabajo (clases de servicio), que tienen diferentes demandas sobre ellos: f.ex. errores, problemas críticos, trabajo con plazos estrictos, trabajo sin plazos
• observe cómo fluye su trabajo, por ejemplo, si tiene cuellos de botella en algún lugar, o si el trabajo está bloqueado o si está "muerto de hambre" por trabajar en patrones algo predecibles. Esto es más fácil a largo plazo si usa una herramienta digital, consulte algunas de mis últimas diapositivas.
• mejorar el flujo de trabajo paso a paso

Si quieres probar algo ahora mismo, hoy, mientras tomas tu decisión, te recomiendo probar un kanban personal en la pared o ventana o armario a tu lado, como hice la semana pasada ...

Después de leer todas las otras respuestas aquí, creo que la respuesta pragmática simple es:

Use procesos o técnicas o métodos que están en uso para APRENDER algo que lo ayudará a hacer mejor su trabajo.

Ahora, esto podría significar priorizar sus tareas, todos los días, religiosamente.

Puede significar resolver el trabajo atrasado.

Puede significar informar el progreso a su jefe (incluso si no le importa ... hacerlo es algo bueno para permitirle mentalmente hacer un balance de dónde se encuentra).

Puede utilizar todo tipo de métodos o técnicas porque, en última instancia, le permiten trabajar mejor, lo que = dormir mejor por la noche.

Haz cosas que funcionen (para ti, en tus circunstancias actuales), descarta cosas que no funcionen.

A menos que tenga lo siguiente en su lugar

• Medios para organizar y priorizar los requisitos entrantes.

• Para estimar con precisión el esfuerzo que se tomará para que sepa lo que puede comprometer en una iteración

• Iteraciones y mejora continua: el concepto de iteraciones en el que uno está continuamente inspeccionando y adaptándose es invaluable. Esta práctica fomenta la experimentación y se basa en el aprendizaje continuo. Scrum en la Iglesia, página 4

• Bueno, no puedes hacer una reunión diaria de scrum, pero al menos puedes recordarte la tarea que comprometerás hoy. La reunión de scrum diaria se utiliza para que los equipos puedan sincronizarse entre sí sobre lo que están haciendo.

• Reflexión después de un sprint: en scrum se llama Sprint Retrospectiva, al final de cada iteración, puede reflexionar sobre lo que sucedió después de la iteración y pensar qué salió mal y cómo puede mejorarlo, cuáles son las mejores prácticas para mantenerlos obra

Sugeriría que adopte un enfoque minimalista y, mediante una mejora continua, puede tener un scrum que se ajuste bien a sus necesidades.

Scrum no es scrum si no puede ajustarlo a sus necesidades y adaptarse a su situación actual.