Transparente desarrollo de

Nos dedicamos a la elaboración de productos de ti de encargo. Porque no desarrollamos sus propios proyectos, y la creamos para que los clientes, para nosotros es muy importante construir con ellos una relación de confianza. Como resultado, la relación se ve afectada por cómo está en proceso de elaboración. Nos puede trabajar con los clientes de manera productiva y crear productos de éxito. Pero normalmente a trabajar en el proyecto comienza con la suficiente baja confianza.

En cuanto a las empresas jóvenes, para ellos es en absoluto uno de los principales problemas. Quiero contarles cómo construimos transparente el proceso de desarrollo, que nos ayuda a establecer relaciones de confianza con los clientes. El tema de la relación entre el artista y el cliente en la elaboración de productos de ti, no es nuevo. La empresa “” en su artículo “herramientas de Gestión.

¿Por qué los clientes exigen loco informes?” con suficiente detalle esta cuestión, mostrando las cuatro etapas de la relación y las transiciones posibles entre ellos. Formalmente se puede representar en forma de matriz. No voy a explicar que significa cada una de las etapas de. Sólo diré que nuestra tarea es.

De un cuadrado de A, cuando la confianza del cliente y la transparencia de los procesos de bajo nivel, ir en un cuadrado de C y quedarse allí. La ruta a seguir es la siguiente. A → B → C. Para hacer esto podemos mediante el aumento de la transparencia del proceso — después de esto, el establecimiento de relaciones de confianza se convierte en una cuestión de tiempo.

¿Por qué tenemos que tratar de permanecer en la fase C. Si vamos a la fase D, nuestra posición es muy inestable, el precio de un error demasiado grande — aparece el riesgo de volver de nuevo a la baja de la confianza. Curiosamente, la transición C → D casi siempre se produce por el cliente, por lo menos a juzgar por mi práctica.

El cliente simplemente se relaja. Puede dejar de participar en y , ya que todos tan bien. Tras él se relaja el equipo de desarrolladores de. En mi práctica, ha sucedido dos veces (dimitri, hola!). El cliente en buen estado paga el dinero, pero casi no participa en operaciones de gestión del proyecto.

De verdad lo fue sólo después de un año de trabajo — después de que salvamos la vida del producto y comenzaron a producir estables de prensa. Lo que hacemos para mantener las relaciones en la fase de la C. De un vistazo. No relajamos.

No es cliente de la stand-up-mitin o retrospectiva. Esto significa que tenemos que enviar el resultado a él en correo electrónico. Le contamos acerca de todos los problemas, inquietudes o los progresos de. Para que la historia no era abstracto, voy a confiar en un proyecto real, que nos pasó a ocuparse de la relativamente reciente.

Nos pidió el cliente, se ha negado a continuar la cooperación con otro contratista. Las causas de estas situaciones, a menudo similares — especialmente su precisamos, para comprender mejor a sus clientes. El área del proyecto es la construcción, el servicio de selección de contratistas de la construcción. El modelo es similar a “el Yandex.El maestro”, sólo se hace hincapié precisamente en las obras de construcción.

El desarrollo de una contienda por el modelo en cascada (waterfall). Se estableció un conjunto de características de los conocimientos tradicionales en un cierto plazo, los chicos se iban todos es implementar y nuevamente lo que salió. Un poco de lo que el cliente y así no es particularmente sabe quiénes son ustedes, como que todavía no entiende que todo este tiempo se ocupaba de equipo, si realmente la necesitaba tanto tiempo y, en caso afirmativo, ¿por qué el producto finalmente no ha resultado como esperaba. El cliente optó por concentrarse en el negocio (y con razón), y no encargarse de trabajo de los desarrolladores.

Pero en este caso la situación era perdidosa para ambas partes y, por desgracia, . Con tal de que el cliente inicialmente más difícil de trabajar, porque es muy sospechosos y la segunda vez que quiere ver y controlar absolutamente todo. Se puede entender, y se le debe ayudar a. La iniciativa en estos casos, siempre a nuestro lado.

Qué hacer. Nos ayudan técnicas de Agile software development. No he visto ni una orden, que estrictamente siguió una metodología. Normalmente, el proceso se articula a partir de una combinación de técnicas diferentes que se adaptan a determinado proyecto o. De la misma manera que hacemos y nos.

Hemos recibido retroalimentación por parte del cliente respecto a la anterior proceso de desarrollo, entendido debilidades y eliminado, acompañada de un proceso de varios componentes importantes, directamente relacionadas con la interacción con el cliente. Cada tema se tratará principalmente desde el punto de vista de la utilidad para el cliente. Generalmente todo comienza con el hecho de que se nos pide calcular el costo y el tiempo de desarrollo del proyecto.

Así pasó con el cliente. Aquí todos se comportan diferentemente, pero ahora estamos principalmente evaluamos proyectos después de la story mapping. Explicaré por qué. La esencia story map consiste en describir el sistema desde el punto de vista del usuario y descomponer todas las secuencias de comandos de dos ejes. Tiempo y clasificación.

Que esto le da. Un ejemplo real Story Map para la primera versión del proyecto. En la construcción se ha ido dos-tres horas. Después de que se construyó la primera opción, probablemente, seguirán afinando.

Parte de la tarjeta se traduce en un formato electrónico, trabajar en ella no se detiene. Más información sobre la aplicación de esta práctica y sus beneficios antes de la habitual cc.tt. expliqué en el artículo “Story Mapping. Potente herramienta en el arsenal de los desarrolladores”.

Nuestro cliente se encontraba en la siguiente situación. Tuvo que desarrollar la primera versión del proyecto (por el volumen de cerca de 100 persona por la que tenía que demostrar a los inversores para el desarrollo continuó. Al parecer, una pequeña cantidad para un equipo de tres personas, las tareas para el equipo de la definición de lo peor que podría suceder durante este período. Pero todo no fue tan bien. En muchos casos, el comportamiento del sistema es tal y como esperaba el cliente, por diferentes razones.

El problema es que durante este período se ha lanzado un comunicado. Al final de la. Hacemos las cosas de otra manera.

Durante el mes de elaboración de nada nos impide emitir comunicados de prensa semanal (de hecho todos los días. Por lo tanto, mensuales, en promedio, cuatro de lanzamiento en lugar de uno. Que esto le da. Rápidamente nos recibimos retroalimentación del cliente y podemos de inmediato a responder.

La integración continua es una parte integral de calidad de desarrollo de. Cualquier cambio en el código automáticamente debemos caer en el desplegado de prueba de un stand donde se debe comprobar QA-gerente. En este caso, esto se debe a dos razones. La retroalimentación y el cliente.

Lo más rápido posible entender que algo no ha ido como esperaba, es muy importante. Además, cuando el cliente, en cualquier momento, el acceso a la última versión del producto (aunque no es 100% de trabajo) — sabes, esto tiene un efecto positivo en su relación con el equipo. De inmediato nos explicaron al cliente el valor de integración continua para el lanzamiento del producto, por lo tanto, después de un tiempo, el proyecto ha aparecido un servidor CI. Casi siempre utilizamos TeamCity para asegurar la integración de.

A trabajar en el proyecto, vamos a conectar QA manager, que es el responsable de la calidad del producto en general. No es simplemente un test, que “” el proyecto de la descripción de la tarea. Es un hombre que se lleva todos los escenarios de uso del sistema, comprueba las tareas realizadas, se realiza la regresión las pruebas antes de la puesta en venta. Su trabajo en gran medida determina la calidad de un proyecto es su responsabilidad.

Hemos tenido casos en que tenía que justificar la conexión del hombre que “se torpemente comprobar por vosotros su mismo trabajo”, pero esta es la excepción más. Si a tal llega, y usted lo puede ayudar demostración de los casos, cuando QA-gerente resulta útil, así como el sentido común. Ahora muchos equipos (incluso aquellos que no trabajan flexible metodologías) utilizan los llamados Agile-tablero, para todos los miembros de su equipo ante los ojos eran las tareas que, en su estado y así sucesivamente. Tenemos virtuales se utilizan tablas, y para el equipo, y el cliente ha visto la situación.

Hemos intentado trabajar con AgileZen, Trello, TFS y YouTrack. El principal problema que me tenía que ver, es incorrecta separación de roles (de la columna). Cuando la tarea va” por el tablero, no debería haber dudas respecto de su estado. Volvamos al equipo que trabajó con nuestro cliente hasta nosotros.

En su pizarra después de la condición de “Working” fue el estado “Testing”. Esto es falso, porque en ese caso no se puede determinar, si la tarea ahora es probado o simplemente el desarrollador la ha cumplido y ha sufrido en el estado de. Y ejemplos similares de peso. El tablero es un elemento importante en el proceso de.

El cliente siempre debe tener acceso a la pizarra, y se tiene que utilizar. Estamos muy sorprendidos al enterarse de que el cliente por todo el tiempo de desarrollo abría tan solo un par de veces. (Backlog) para el tablero está formado por construida Story Map en conformidad con la prioridad señalada por el cliente. Sobre el stand-up-mítines todo el mundo sabe, pero no siempre se utilizan en la práctica.

Estos mini-reuniones de no más de 15 minutos son de gran valor para el proyecto. Cada mañana, antes del almuerzo, nos ponemos en contacto telefónico en Skype con el cliente, y cada uno habla de lo que hizo ayer, ¿ algún problema, como él ha decidido o no, decidió, y se suscribe a lo que hará que el día de hoy. Diario de chat en vivo de manera positiva en la relación, es notable que con cada nueva semana.

Los desarrolladores quieren traducir la conversación demasiado en el plano de la técnica. Por ejemplo, pueden decir. “Escribí la migración, que sustituye a la relación de uno-a-uno a uno-a-muchos”, en lugar de decir,. “He implementado la posibilidad de añadir más categorías para publicar, en lugar de uno”. Estas cosas necesitan moderar.

El cliente interesado en escuchar acerca de los resultados desde el punto de vista de las empresas, y no de la ejecución técnica. Después de la finalización de cada iteración (tenemos una semana de duración) llevamos a cabo una demostración de su trabajo al cliente. Mostramos todo lo que se ha hecho o se ha arreglado. Es necesario demostrar, y no simplemente de enviar al enlace en dev-servidor, donde se puede ver todo el.

Ya lo ve, sólo después de la demostración. Durante la manifestación, tratamos de recibir retroalimentación y llevar a cabo los debates, tomar notas, anotar las observaciones en la pizarra. Demo — componente muy importante del desarrollo, agradable . Tenemos en la demo participa todo el equipo, y tiene a su o QA-gerente.

Todo lo anterior — componentes esenciales de un proceso transparente de desarrollo, que nos ayudan a establecer relaciones de confianza con los clientes. Además, es la base sobre la que en nuestra empresa se basa el proceso en general. También vale la pena señalar que para realizar la mayoría de estas técnicas y de mantener el tempo de trabajo el equipo de desarrollo debe ser lo suficientemente alto nivel.

Somos muy estrictos con este realizando.

Source: google.co.uk

Leave a Reply