Por diversas razones, la organización va a adoptar métodos ágiles. Algunas organizaciones desean aumentar la productividad y el tiempo de acortar al mercado, y algunas organizaciones quieren ser capaces de obtener productos de mayor éxito, hay algunas organizaciones desean mejorar la colaboración entre los desarrolladores y empresarios, con el fin de mejorar la calidad o aumentar la satisfacción en el trabajo de los miembros del equipo .
Por supuesto, hay muchas organizaciones adoptan ágil es la esperanza de conseguir simultáneamente una combinación de estos beneficios.
Sin embargo, con el fin de beneficio ágil tanto como sea posible, la organización parece que hay un montón de malentendidos. En este artículo, quiero hablar de seis ideas falsas sobre el desarrollo de productos ágil.
Mito 1: desarrollo ágil de software no es sólo para usted?
Este malentendido es muy interesante, porque como la más antigua Agile, Scrum se originó en el desarrollo de productos físicos. La copiadora inicial del proyecto Scrum, Honda y cámaras.
Hoy en día, la agilidad ha sido ampliamente utilizado en diversas formas de desarrollo de productos, desde productos físicos para el software basado en la nube como servicio (SaaS).
Pero además de desarrollo de productos (incluyendo hardware y software), la agilidad se ha aplicado con éxito a:
● equipo de marketing para llevar a cabo las actividades planificadas y ejecutadas
● abogado para manejar la carga de trabajo y los casos
● Transformación Organizacional (especialmente la transformación ágil) de gestión de transacciones
● equipo de dirección para gestionar su organización
● familiar utilizado para mejorar el tiempo de convivencia
● parejas que planean una boda
, por supuesto, hay más. Cualquier asunto más singulares (diez veces nunca se ha hecho antes) y complejos son muy adecuadas para ágil. Si te molesta debido al manifiesto ágil usamos el término "software", sólo tiene que utilizar "productos" en lugar de la palabra puede ser. Por ejemplo, el "Software disponible" se puede cambiar a "producto disponible", y luego volver a leer: [Abogamos] "producto utilizable" es mejor que "bien documentado". Muy adecuado. ¿Por qué? Debido a la agilidad puede ser utilizado para todo tipo de productos - el software es sólo uno de ellos.
Mito # 2: ¿En serio función de administrador no existe en Agile hacer?
Creo que todavía existe este concepto erróneo, porque muchos gerentes pasan mucho tiempo para hacer cosas que no deben hacer, o no ágil y la indiferencia.
Por ejemplo, los gerentes a menudo trabajan para romper el nivel de tarea individual. Cuando supo que este no es su trabajo de una manera ágil, se sentirán sus puestos de trabajo son privados.
No es así, no cancela completamente el trabajo.
En primer lugar, asignar tareas tales como curiosidades y similares, no se han convertido en parte del trabajo.
Los gerentes deben concentrarse en la creación de un equipo de florecer en el medio ambiente y la cultura. No debe consumir su tiempo en tareas tales como quién debe hacer lo que las tareas domésticas.
• Peter Drucker (Peter Drucker) es tal vez la gestión de los principales teóricos del siglo 20. El acrónimo Ideas meta SMART-gestión y los objetivos establecidos para la primera letra creada (objetivo debe ser específicos, medibles, alcanzables, relevantes y de duración determinada) es conocida. Drucker dijo, hay cinco gestores de trabajar:
los objetivos establecidos ●
organización y el trabajo ●
● motivación y la comunicación
● medida de
las personas ● tren
, por supuesto, en algunas organizaciones, algunas de las cuales pueden debilitar la responsabilidad. Sin embargo, algunas otras responsabilidades - tales como la formación de personas que se vuelven más importantes.
En estos años he ágil y de cooperación con las organizaciones ágiles, nadie va a decidir cerrar todos los gerentes. Sí, aunque algunos gestores se han convertido en un trabajo más centrado papel Scrum Master o propietario del producto, pero todavía existe la función de administrador de ágil.
Mito 3: Las partes interesadas no están listos para iniciar los cambios?
Como era de esperar, el error más común de creer que (los interesados pueden iniciar el cambio en cualquier momento) las personas son actores mismos.
los miembros del equipo de desarrollo se entienden para introducir cambios en el momento equivocado es toma el precio.
Imagínese una comida en la escena del restaurante. Usted le dice al camarero que le gustaría tener pollo, seguido inmediatamente dijo: "No, el cambio de salmón."
Este cambio es sin costo alguno.
Sin embargo, si posteriormente cambia de opinión, se paga el precio. Si el inicio en la cocina para cocinar el pollo, el camarero le dirá sus comidas cambia de salmón de pollo, habrá costes de los residuos de alimentos (restaurante podría cobrar).
Si es lo primero decir al camarero que desea cambiar el salmón, que tiene un pollo a medio comer, y que el costo será más evidente.
Las partes interesadas para cambiar a la iteración, al igual que los que comen el pollo en la misma salmón. Si los cambios se realizan en el momento adecuado, ni siquiera el costo puede ser pequeño. Cuando se introduce en el momento equivocado, es un precio a pagar.
Ágil no elimina el coste de todas las partes interesadas para introducir cambios. Sin embargo, independientemente de la hora de introducir cambios, el equipo sobresaliente agilidad puede reducir el coste del cambio. métodos comúnmente utilizados son:
● cortos iteraciones
● producto sea a corto plazo hacer
● minimizar el número de trabajo regular en paralelo, con el fin de completar lo más rápidamente posible para cada elemento del producto a-do
no significa que el equipo no debe acoger los cambios apropiados. Algunas partes interesadas pueden tener que cambiar es muy importante. Sin embargo, el coste del cambio no es siempre cero, para cada cambio debe ser controlado para cambiar su evaluación del costo de las prestaciones.
Mito 4: No es ágil equipo de cada uno debe ser generalistas hacen?
Por alguna razón, hay una idea equivocada acerca de ágil es, es decir, las necesidades de cada miembro del equipo muy populares que hacer todo el trabajo.
Este medio de idea errónea de que si usted contrató mejor administrador de base de datos Oracle del mundo, también quieren que el administrador de la base es también el nombre de un buen desarrollador de JavaScript. Y, si no es mucha el trabajo de desarrollo en JavaScript iteración, entonces usted excepcionales desarrolladores de JavaScript también debe ser plenamente versado en las pruebas de seguridad.
Esto es completamente erróneo.
Los equipos ágiles necesitan no todo el mundo posee todas las habilidades, sino prestar atención a cualquier empresa con una variedad de habilidades profesionales de los miembros del equipo.
Para entender mal con este malentendido, imaginen que hay un restaurantes de alta gama bien administradas. Desde el aspecto del programa de cocina, me enteré de que este restaurante puede tener repostería. Confitero bueno para hacer pasteles, postres, panes y otros productos horneados.
Esto suena como una función especializada, pero especializada. Otra función especial de la cocina es probablemente salsas división, fue responsable de la preparación de salsas, guisos y otros alimentos similares.
En esta cocina que funcione bien, pasteleros pueden ayudar si la división de salsa, por ejemplo, en el caso de una repentina escasez de cebolla ayuda cortar algunas cebollas, ha sido muy buena. Pero no importa pastelería o salsas división, no puede esperar que su completo para el trabajo del otro.
En el complejo mundo actual de la tecnología, esperamos que todos los miembros del equipo para versados plenamente en las habilidades del equipo no es realista. En su lugar, los equipos ágiles pendientes para aprender a prestar atención a captar los miembros del equipo con múltiples habilidades.
Tiene varios miembros del equipo con habilidades múltiples, contribuirá a la gestión del tipo de equilibrio. Por ejemplo, a veces el equipo necesita más pruebas de puestos de trabajo, si hay uno o dos miembros del equipo pueden dar vuelta para hacer el trabajo de prueba, puede ser de gran ayuda.
Sin embargo, la mayoría del equipo a pesar de que hay algunos miembros del equipo son los verdaderos expertos y sólo es bueno en una disciplina, sino también para hacerlo (es decir, tiene varios miembros del equipo con habilidades múltiples).
Mito 5: He oído que los equipos ágiles planean hacer
equipo más ágil va a hacer un plan excelente. Sin embargo, en comparación con los elementos tradicionales, tales planes son por lo general menos obvio, porque los equipos ágiles no planean una etapa temprana.
En su lugar, los equipos ágiles en circulación se han previsto como una serie de pequeñas actividades repetitivas implementadas para asegurar que los planes siempre refleja la situación actual.
De este modo, mediante la revisión continua y el ajuste, el equipo será capaz de desarrollar una manera de hacer plan de producto.
Para cualquier equipo ágil, su alcance debe limitarse a los planes requieren decisiones importantes, y no demasiado lejos en el futuro. Sin embargo, la mayoría de las organizaciones tendrán un equipo y un plan en cierta medida lo que se estima que esté terminado el próximo y cuándo.
De hecho, a pesar de este malentendido, ya que la velocidad de su penetración en el desarrollo de software tan pronto como sea posible, los equipos ágiles puede desarrollar más fácilmente un plan creíble.
Imagine un equipo de análisis tradicional, diseño, codificación y pruebas de fases. Si tienes la suerte, el equipo puede ser capaz de presentar un plan pospuesto hasta el final de la fase de diseño. Pero incluso entonces, el equipo todavía no los conocemos en la codificación y prueba de lo rápido - no se ha llevado a cabo cualquiera de estas actividades.
Por el contrario, los equipos ágiles cada iteración del funcionamiento de todo el proceso de desarrollo. Cada iteración incluirá algunos de los análisis, diseño, codificación y actividades de prueba. Esto permite penetración en equipos ágiles posible tan pronto como sea posible, que es capaz de lo rápido que las ideas en nuevas características.
Mito 6: ágil desarrollo de productos marco de planificación del equipo no es cierto?
Por último momento de deshacerse de los últimos de un malentendido - sobre equipos ágiles no hacen arquitectura y diseño de producto malentendido.
Los equipos ágiles sin duda el diseño de sus productos. Los equipos ágiles de la misma manera, de forma incremental planificación, arquitectura y diseño. Esto les permite seguir para revisar y ajustar su arquitectura y diseño, por lo que es la mejor solución.
Esto significa que no hay ninguna etapa previa a la decisión de todas las arquitecturas. En cambio, la arquitectura del producto surgirá con el tiempo.
los miembros del equipo técnico se centrarán en primer lugar en cualquier aspecto del producto que creen que hay riesgo. Por ejemplo, si el producto a entregar en los desafíos requeridos rendimiento, el equipo y el dueño del producto elegirán para estudiar la forma de lograr la meta en los primeros días, con el fin de reducir el riesgo.
Del mismo modo, el diseño emergente arquitectura de producto ágil también deliberar. La arquitectura no es un día para aparecer. Es bajo la dirección deliberada del equipo técnico que emerge gradualmente.
Esto significa que el producto tiene una gran infraestructura ágil. Sin embargo, es necesario tomar decisiones sobre la arquitectura durante el proyecto hecho, en lugar de al principio del proyecto se realiza por completo.
(Fuente: Scrum china Autor neta: Mike Cohn Traductor: Li Jie)
