Metodología como constructor: instrucciones de montaje

Solo se puede ensamblar un modelo de juguete del diseñador LEGO moderno, por ejemplo, un avión. Personalizar? Puede intercambiar asientos de piloto, eso es todo personalización. Hace unos 30 años, desde el diseñador fue posible ensamblar casi todo, desde un avión hasta un camión, con la misma cantidad de piezas que en los modernos. Los creadores de las metodologías más modernas en la infancia jugaron el viejo Lego. Los que ahora usan metodologías ya han jugado en moderno. La diferencia en las prácticas de ingeniería es enorme.



Bajo el corte, Philip Delgado ( dph ) hablará sobre el enfoque de ingeniería para formar una metodología. Todos los proyectos y equipos son diferentes, y los líderes son únicos. Ajustar una metodología para todos no funcionará, simplemente no hay ninguno. Tendremos que tomar un diseñador y construir algo único a partir de él. Al descifrar uno de los mejores informes de TeamLead Conf , no habrá secretos secretos de los monjes Shaolin, solo banalidades verificadas por la experiencia. Estamos esperando un catálogo de detalles de la metodología de desarrollo, qué buscar al diseñarlo e implementarlo, y las reglas para reconstruir las metodologías. Para todas las ideas, se dan ejemplos reales de la experiencia de Philip. Durante su carrera, probó de todo, desde Visual Basic hasta SQL hardcore, desarrolló el motor de apuestas más grande de Rusia y Yandex.Money, y ahora trabaja en proyectos Java cargados. Ella regularmente da presentaciones en varias conferencias, incluyendo HighLoad ++.

Desafío

Hace unos años, una vez más llegué a un proyecto para crear un sistema de pago desde cero. Al comienzo del proyecto no había nada: sin desarrolladores, sin procesos, sin producciones. ¿Dónde comenzar a trabajar si no hay nada? Introducir algo de inmediato es extraño e incluso estúpido. Por lo tanto, el primer paso es comprender lo que realmente se necesita de la técnica.

Kent Beck, al final de su libro sobre SCRUM, escribió:

Todos los métodos se basan en el miedo. Estás tratando de desarrollar tus hábitos que te ayudarán a evitar que tus miedos se hagan realidad.

Por lo tanto, lo primero que debe hacer es averiguar en el negocio de qué tiene miedo .

Por lo general, el negocio está asustado por todo el proyecto: da miedo hacer demasiado o no hacer nada . Tecnológicamente, tiene miedo por la fiabilidad y la seguridad . En nuestro caso, estos temores están justificados: el sistema de pago es contrapartes, dinero y obligaciones serias.

Diferentes miedos conducen a diferentes metodologías. El miedo a pagar de más lleva a contratar desarrolladores baratos que son fáciles de cambiar: es SCRUM. El miedo al error conduce a GOST o RUP con un montón de documentos formalizados.

Los desarrolladores también tienen sus propios miedos: escribir sin apoyo o hacerlo mal . Desafortunadamente, casi nadie está desarrollando metodologías bajo el temor de los desarrolladores. Solo XP menciona brevemente que los desarrolladores tienen miedo de hacerlo mal, intentemos ayudarlos a hacer bien su trabajo.

Además de los temores, la empresa tiene deseos para qué fines optimizar los procesos:

• rápido
• barato
• previsiblemente
• de manera controlada;
• cualitativamente
• escalable
• HYIPOVO

Elija cualquier opción, y tal vez, quizás, algún día, probablemente, si no sucede nada y Marte converge con la Luna en Capricornio, tendrá éxito. La mayoría de los deseos de optimización también se refieren al miedo, solo en una redacción diferente: barato, sobre el miedo a pagar de más, controlado, sobre el miedo a hacer algo incorrecto, como era de esperar, sobre el miedo a que no haya tiempo.

Por lo general, una empresa quiere todo a la vez . Al reunir los requisitos, adhiérase a la presuposición "el paciente siempre miente". Cuando una empresa quiere todo, miente. Intenta entender lo que el negocio realmente quiere y trata de vendérselo. Este no es el conjunto de habilidades más estándar para un líder de equipo. Pero si no sabe cómo averiguar los requisitos reales de un negocio, entonces necesita encontrar una persona que pueda.

Además de los deseos del negocio, debe conocer las limitaciones significativas.

• Plazos ajustados . En mi caso, no había una fecha límite, por ejemplo, los Juegos Olímpicos, cuando solo hay dos opciones: llegar a tiempo o no.
• Estricto contrato . Si trabaja con una empresa estatal, entonces el contrato es algo que no debe ser violado. Todo lo demás se puede hacer como lo desee. Esto afecta mucho la técnica.
• Envío regular Debe implementar constantemente nuevas funciones, esto es importante para las empresas.
• Certificación: CB, PCI DSS . Esta es la principal limitación del diseño del sistema de pago. Los mayores riesgos y preocupaciones están relacionados con la certificación de valores, PCI DSS y otros.

Son las limitaciones esenciales las que distinguen, por ejemplo, los procesos FixPrice de los procesos Time & Material.

En nuestro proyecto del sistema de pago, resultó que era aterrador hacer demasiado tiempo y no tener miedo, miedo a la confiabilidad y seguridad, pero es recomendable hacerlo todo rápidamente. Al mismo tiempo, no hay producciones al comienzo del trabajo, no hay desarrolladores, pero hay especialistas en el área temática (por ejemplo, yo). Solo los bloques grandes y bastante independientes entre sí son claros: procesamiento, clientes, integraciones, back office y front office.

Habiendo descubierto los objetivos y las limitaciones, puede comenzar a construir una metodología para comprender cómo desarrollaremos exactamente el sistema deseado, al menos en la primera etapa.

Estamos construyendo una metodología para comenzar un proyecto

¿Pero qué es una técnica? ¿Qué queremos construir en general? La respuesta a las preguntas es una hermosa imagen de Alistair Cowber con un montón de puntos.



En primer lugar, tres cosas son importantes para nosotros a partir de esta imagen: las personas , quienes lo hacen; procesos : cómo lo hacen; y artefactos : lo que hay que hacer. Todavía no tenemos personas y procesos, así que descubriremos qué artefactos necesitamos.

Comenzar con artefactos es un buen patrón al diseñar una técnica , incluso si ya existen personas y procesos. Es aconsejable comenzar el diseño de artefactos “desde el final”, con el valor entregado, de aquellos artefactos que se expondrán en la venta o se enviarán al cliente. ¿Por qué es mejor así? Una pregunta separada para un artículo separado. Si conoce la respuesta, escriba en los comentarios.

Elegir artefactos

Tomamos miedos y entendemos qué artefactos que los temores cierran.

El miedo a "trabajar en un proyecto durante demasiado tiempo" se salva con un plan a largo plazo y un hecho importante . Del miedo a la fiabilidad: pruebas automáticas . Por miedo a "no hacer", eleve la posición de "casi combate". Le demostraremos el progreso del negocio . Para que pueda ver de inmediato qué es y qué funciona, y en caso de apuro, publicaremos al menos algún resultado.

Formamos procesos

Estamos al comienzo del desarrollo, por lo que no hay tiempo ni razón para crear procesos formales complejos. Entonces simplificamos todos los procesos y nos enfocamos en facilitar la comunicación .

Como resultado, hay exactamente dos procesos: resolver una gran tarea : pensar en una solución y verificar qué se ha completado . Estos procesos son largos, de investigación y poco conectados entre sí, lo que conduce a prácticas de desarrollo apropiadas.

Para hacerlo rápido, contratamos empleados geniales . Pero los especialistas geniales no recurren a un sistema de pago desconocido para nadie en el mercado. De alguna manera funcionó, pero la solución a este problema es una discusión separada. Por cierto, escribe en los comentarios cómo lo resolviste en casa y ¿qué decidiste?

---

Retiro: sobre la contratación

Al contratar, generalmente miran las descripciones de trabajo estándar y las gradaciones habituales de los niveles de candidatos, dibujando sobre ese mapa de roles en el equipo:



Pero las descripciones estándar no nos permiten comprender la necesidad de una persona específica en un proyecto. Por lo general, trato de mantener varios mapas diferentes en mi cabeza para diferentes proyectos, destacando diferentes roles y competencias que son importantes para el proyecto. Por ejemplo, tecnológico .

Solucionador de problemas . Esta es una persona que puede sumergirse en un código heredado con algún tipo de error sin documentación y pruebas durante 2 días, y se le ocurre la frase: "En esta línea, reemplace + con - y funcionará".

Y funcionará. Las personas como el trébol de cuatro hojas son raras. Desafortunadamente, el mercado no valora a esas personas, es difícil explicarle al negocio que un solucionador de problemas es críticamente necesario y merece respeto y un gran salario. Como resultado, la mayoría de ellos van a los líderes de equipo, y este recurso está agotado. Solo resta promover la utilidad de dichos especialistas, y quizás después de algún tiempo la situación cambie.

Integrador Esta es una persona que sabe cómo crear algo integral a partir de varios componentes, bibliotecas y módulos diferentes. Ya no es un programador XML, sino uno que entiende la estructura interna. Esta es una habilidad extremadamente rara, que generalmente tiene mucha demanda en el desarrollo real.

Gurú: Marco, Seguridad, Base de datos, DevOps . Todo está claro sobre el gurú: estas son personas a las que se puede contactar con preguntas sobre temas relevantes.

Además, también hay roles "no tecnológicos", un mapa social de roles. Un generador de ideas es una persona que puede llegar a algo. Crítico : quién puede criticar constructivamente. Experimentado : una persona experimentada que puede decir: "Lo intentamos y resultó absurdo". Un perfeccionista es una persona que quiere que todo sea bueno. Este es un papel importante. Si no está allí, generalmente todo se descompone rápidamente, porque no hay nadie que te diga: "Lo tienes de nuevo, todo está mal, ¡arreglémoslo!"

Si no se cumple algún rol en el mapa de roles para su proyecto específico, entonces el equipo tendrá que cumplirlo.

Por lo tanto, piense a quién tomar y tenga en cuenta que las diferentes entrevistas son adecuadas para diferentes roles y posiciones . Con un veterano experimentado, la entrevista será rápida, solo descubra lo que estaba haciendo. Por lo general, tiene que hablar con un joven durante mucho tiempo, realizar tareas de prueba y averiguar qué puede hacer.

Cuanto más alto sea el nivel del candidato, más corta será la entrevista.

¿Qué otras personas necesitas?

Un extrovertido es aquel que quiere y puede comunicarse activamente fuera del desarrollo. No tenemos producciones exactas, por lo que necesitamos unas pocas personas que puedan entender a los usuarios finales, incluidos los internos, por ejemplo, nuestros contadores. Un extrovertido no tiene miedo de ir a hablar, descubrir las necesidades de esos "no programadores" inusuales, y hay pocas de esas personas.

Crítica : primero necesito una crítica de mí. Esta es la persona que criticará mis decisiones. Sin críticas, me temo que estoy cargando algunas tonterías. Cuando me critican, tengo que pensar seriamente en los argumentos, y resulta que esto no es completamente una tontería.

Especialista en problemas monótonos : informes, integraciones. Sabía con certeza que tendremos una gran cantidad de informes en el proyecto. Seis meses para escribir informes contables y no volverse loco: una habilidad rara. Dispersar esta función entre diferentes personas también es inconveniente, por lo que necesitaba un especialista en problemas monótonos.

No importa Esta es una persona a la que no le importa qué tareas hacer, aunque solo sea para pagar. Este papel es extremadamente importante para el proyecto, porque había diferentes tareas: monótonas, pero complejas, increíblemente interesantes o no relacionadas con nuestra experiencia previa debido al requerimiento externo.

Volvamos a nuestro proyecto. No necesitamos el Solucionador de problemas, porque el legado aún no existe. Necesitábamos un integrador y un conjunto de gurús. Security Guru en realidad se cultiva por dentro.

Database Guru ha sido subcontratado con éxito. Realmente me gusta la idea de "tomar competencia en la base de datos en algún lugar fuera": encontrar a esa persona en el personal generalmente no es realista si no tienes una gran empresa, y se requieren al menos 5 personas para apoyar una importante base de datos 24 * 7. También subcontratamos primero DevOps Guru, pero no con tanto éxito, este papel es más difícil para los artistas externos.

Los roles sociales también se cumplieron (e incluso hubo algunas críticas).

---

Practica

Entonces, descubrimos los artefactos necesarios, descubrimos qué necesitan las personas y qué requisitos del proceso. Lo que sucedió, cómo exactamente organizamos el desarrollo:

• Planeamos trazos grandes. No tenemos producciones, por lo que es imposible planificar con mayor precisión. Es necesario crear una cuenta personal en tres meses, y eso es todo. Realizamos planes en Confluence.
• Cada uno es un poco analista . No hay producciones normales y la competencia en el área temática está en manos de personas que no saben cómo escribir producciones. Nadie les enseñó, debes eliminar esta información de ellos. Pero tenemos "extrovertidos".
• No se necesita un rastreador . Solo tenemos 20 tareas principales para el proyecto: por qué iniciar un rastreador.
• Una sucursal en VCS. En la etapa inicial, no se requiere un trabajo complejo con control de versiones.
• Los procesos son aproximados . Todavía hay pocas personas, no hay comunicaciones ni problemas, y el proyecto en sí es inestable. No es necesario describir nada en detalle.

Cuando la gente habla de métodos similares, no demasiado formalizados, a menudo simplemente dicen: " Tenemos un enfoque ágil".

También obtuvimos el clásico "Tenemos Ágil". Pero entendí claramente por qué esa técnica y por qué era "ágil", y no algo más específico y complejo. Y yo (y los negocios), esta técnica fue bastante adecuada.

Un lector atento notará que al diseñar la metodología, nos olvidamos de dos temores importantes: el miedo a la seguridad y la necesidad de certificación . Tratemos de descubrir cómo lidiar con ellos.

---

Digresión: matriz de Cowburn

En 1980, Alistair Cowbern dibujó una matriz de la complejidad del proyecto .


Vertical: la criticidad del proyecto . Lo que se puede perder en caso de errores significativos: desde la pérdida de comodidad del usuario hasta la pérdida de la vida del usuario, por ejemplo, si diseñamos software para plantas nucleares. Horizontal: el tamaño del equipo . El tamaño afecta la cantidad de comunicaciones. La crítica está en el detalle de estas comunicaciones. Todo en total afecta la complejidad del proceso.

Alistair argumenta que moverse hacia la derecha o hacia arriba en cada casilla complica enormemente y aumenta el costo de desarrollo. Esto es lógico: más personas requieren más costos de comunicación. Si se necesitan relaciones más formales, entonces se requieren más costos de comunicación. Es decir cuanto más lejos, más recursos se gastan en tareas improductivas y pérdidas.
Por cierto, como tercer eje, Alistair dibuja la optimización para diferentes deseos comerciales.

Intentemos colocar nuestro sistema de pago en esta matriz. La matriz es muy conveniente como modelo para comprender la complejidad estimada de su proyecto, su sistema.

Tenemos un sistema de pago, lo que significa que en caso de apuro perderemos dinero de los usuarios. Esto, por supuesto, es desagradable, pero no conduce a un fuerte aumento de la complejidad.

Pero tenemos casi un banco, y en algunos casos, en caso de violación de los estándares o requisitos del Banco Central, se puede tomar una licencia del banco. Esto ya es una pérdida de mucho dinero, casi cerrar un negocio, muy triste.


Tenemos un equipo de aproximadamente 20 personas, así que nos metemos en la plaza E30 . Esto es malo, porque un buen ejemplo de la técnica en este cuadro será el Proceso Unificado Rational completo: procesos formales, muchos documentos, declaraciones claras. 20-30 personas no pueden hacer frente a esto. Tienes que contratar 50, y la dificultad crecerá como una bola de nieve. Sistemas similares en tales metodologías generalmente son escritos por cientos o más personas.

Que hacer Problemas No, no todo el proyecto es igualmente crítico . Tenemos solo unas pocas piezas críticas.

• Cheque de lavado de dinero, por el cual el Banco Central golpeó fuertemente en la cabeza.
• Trabajar con tarjetas bancarias, para lo cual los sistemas de pago mundiales golpean duro en la cabeza.
• Almacenamiento de datos personales: para esto, el estado golpeó duro en la cabeza.

Destaquemos los módulos críticos individuales . Escribiremos para ellos prácticas especiales para trabajar específicamente con estas partes de nuestro proyecto: una auditoría PCI DSS completa para cada confirmación , buena documentación, una doble revisión de código, un proceso de cálculo especial y mucho más. Deje que solo los desarrolladores senior escriban estas partes del proyecto.

Pero tales partes son pocas. Por lo tanto, la matriz Cowbern para el proyecto es tal.


Para diferentes partes del proyecto habrá una complejidad diferente de la metodología, un conjunto diferente de prácticas. Lo más difícil y terrible son tres personas . Lógica de pago - persona 8. Cualquier otra tarea menos importante, que es sobre todo, como un sistema de ayuda o el diseño de un sitio para el back office, en el que el error no es fundamental, es manejado sobre todo por las personas. Pero allí los procesos pueden ser los más fáciles e informales.

Un gran proyecto complejo puede usar diferentes conjuntos de prácticas para sus diversos componentes.

Esta es una de las grandes ventajas de la arquitectura de microservicios: la capacidad de prescribir una imagen en la que diferentes servicios responden no tanto a diferentes técnicas, sino a diferentes prácticas dentro de la misma técnica. Al mismo tiempo, las cosas importantes siguen siendo comunes: planificación, artefactos, un enfoque común para la interacción.

---

Para resumir

Descubrimos los requisitos para la metodología : objetivos y limitaciones. Identificó los elementos básicos : procesos, artefactos y personas. Describieron prácticas : cómo implementar procesos, requisitos para artefactos, qué tipo de personas se necesitan.

Este es un esquema de diseño de ingeniería clásico: tenemos requisitos, luego especificamos la arquitectura y luego la programamos.

Diseñar métodos es una práctica de ingeniería, un proceso de ingeniería que no es diferente de programar un módulo.

Etapa uno prácticas

Un poco de práctica para distraer de la teoría a la realidad.

Derecho a "¿Por qué?"

Esta es mi práctica favorita.

Cada empleado tiene derecho a preguntar sobre cualquier tarea: ¿por qué hacerlo, por qué hacerlo de esta manera y quién lo necesita?

La gente tiene miedo de preguntar "por qué", tal vez porque en la infancia todavía no respondían esas preguntas. Si ha escrito explícitamente y repetido "puede y debería" muchas veces, la gente lo hace. Tan pronto como empiece a preguntar "por qué" en todos los niveles, incluidos los negocios, el volumen de tareas disminuye muchas veces y la motivación también aumenta. La gente entiende el significado del trabajo y lo hace más rápido y más económico, cortando esquinas.

No generalizar a tres

, . , , .


— , , . — — , . , , .

IDE Driven Development

JetBrains — ! , IDE.

, IDE.

. , IDE , . IDE — . IDE — : , , , . : , , .

, , IDE call stack . .

IDE — .

, , . . : « ?» , . , - . , .


3–4 . .

, . , . , , , .

. — , , .

- , . .

— .

: « , , , ».

— , , . . — , , , .

. , - . .

, — , . : , ,

, : . . .

• . , , .
• . , , , , - .
• . 3 -, , , , . , .
• . , . , - — .

, SCRUM , SCRUM . , , , .

. 20 . SCRUM , , , - . .

.


- — , 3 .

- .

- : PCI DSS , ( ., ), - .


. « , », . , 1 — , - . , . shit happens , — , . , , , , .

, , , — , , .

— . . . - , , — .

— . , «» , - bus factor — , .

. , , .

. , . , , . , , , . Style guides code review , - , .

, - . ?

Planning poker . « » — . , , . Planning poker , .

. :

• ;
• product owner ;
• ;
• .

, , , — ? , 2 10% . ?

, Planning poker — , , ? , — . . planning poker , , .

: , , . Agile — , . , .

, Agile, SCRUM XP .

, , , , , , . , - , — ? ?

. : , , , . , ?

, Planning poker , , Planning poker :

— , , !

Planning poker . . .

:

• ;
• ;
• .

.

: , , .

Jira , « » ? - -? ?


, , . , junior product manager — , , , .

, — . . , . — !


Revisar antes del código. Regularmente escucho cómo se le dio a una persona la responsabilidad de una gran característica, pero lo hizo mal y necesita ser rehecho. Revisemos el código antes de escribirlo . Antes de escribir el código, un empleado de Jira describe un plan para resolver un problema en dos líneas o dos párrafos de texto. Revisar estos dos párrafos es rápido y fácil, pero los errores globales se detectan desde el principio, especialmente si tiene un líder de equipo o un arquitecto.

Además, esta práctica le permite al líder del equipo o al arquitecto conocer todos los cambios en un proyecto grande. No lee un código torcido, sino dos párrafos sobre lo que generalmente sucede en el sistema, y ​​rápidamente atrapa a las personas de la mano. Esto es especialmente cierto para las partes críticas de un producto, como la lógica de pago.

Cómo cambiar la metodología y no matar el proyecto

Entonces, en 9 meses cambiamos 3 métodos: "Tenemos Ágil", SCRUM de un día y Kanban. ¿Cómo asegurarse de no perder recursos? ¿Cómo cambiar la metodología y no matar el proyecto al mismo tiempo?

Logramos cambiar los métodos para que algunos desarrolladores no noten los cambios en absoluto. Nadie les contó sobre esto, trabajan, ¡y la metodología es diferente!

Lo principal es entender cuándo cambiar.

Si entiendes por qué. A menudo se cambian los métodos, porque ha venido un nuevo director técnico que quiere rehacer todo. Esta es una mala razón. Mejor tome el viejo y cámbiele el nombre: todo, la técnica es diferente, es mejor. Si no puede responder la pregunta por qué, es mejor no cambiar. Generalmente me gusta preguntar por qué.

Si pensabas "cómo". Si comprende cómo pasará del punto A al punto B, cambie. Hasta que se te ocurra, no es necesario.

Si está satisfecho "cuánto". Cambiar una técnica es casi siempre un procedimiento costoso . Si lo hace bien, el reemplazo costará varios meses-hombre de los costos de los líderes de equipo, personalización, personalizadores de Jira. Si es malo, unos pocos meses de trabajo de toda la empresa. A menudo vi la transición de Kanban a SCRUM, luego de regreso, cada uno de los cuales costó un mes de trabajo durante todo el desarrollo. Si no está listo para tales costos, no comience.

Preparación

Comenzamos de antemano. Para un equipo pequeño, la preparación comienza un mes antes del turno.

Dibujamos historias de usuarios. El mismo enfoque que en el diseño de aplicaciones. ¿Usas Historias de usuario al describir los requisitos, espero?

Por ejemplo:

• Historia de usuario : como desarrollador, quiero encontrar mi próxima tarea y proceder con su implementación.
• Criterios de aceptación : como desarrollador, puedo ver todas mis tareas actuales y evaluar la urgencia y prioridad de las tareas.
• Excepciones: si no hay tareas, el desarrollador sabe a quién preguntar.
• Enlaces: escenarios para preparar un plan a corto plazo, que muestra dónde obtener la siguiente tarea.

De esta manera, repase todas sus actividades principales que surjan dentro de su metodología y escriba Historias de usuarios.

¿Cómo puede el gerente ver la efectividad del plan? ¿Cómo entiende un alto directivo que todo está bien? Escriba Historias de usuarios, luego agregue detalles: haga un tablero para los usuarios y para los gerentes superiores: los Criterios de aceptación pasan, todo está bien.

Cuando ya tiene Historias de usuarios, puede comenzar a convertirlas en prácticas.

Reemplace todos los roles con personas reales . Una persona real siempre sabe más que un rol. Entonces inmediatamente encontrará el cuello de botella. Por ejemplo, todas sus Historias de usuarios usan una persona específica, aunque él simplemente está en diferentes sombreros, en diferentes roles. Esto es malo: descubra cómo descargarlo.

Reduce artefactos y comunicaciones . Si hay demasiados, cada Historia de usuario sugiere sus propios artefactos y comunicaciones, hay que hacer algo con esto.

Busca cuellos de botella . Cuando existe tal mapa de historia, puede comenzar a hacer algo con él.

Elegir herramientas

La herramienta identifica características . Existe una opinión popular de que las herramientas no son importantes, o que cualquier herramienta es adecuada; esto no tiene sentido.

Si la herramienta es incómoda de usar, no se utilizarán.

Además, los vendedores siempre mienten. Si dicen que su herramienta puede hacer "1, 2 y 3", lo más probable es que no puedan hacer "1", "2" a veces y "3" lo hace, pero es muy malo. Asegúrese de revisar todo.

Estamos discutiendo activamente

Sin una discusión activa de la técnica, puede olvidarse de algunas funcionalidades importantes, Historias de usuarios importantes y ofender a alguien. La persona ofendida saboteará la implementación de la metodología : inicialmente se sintió ofendido, olvidado, nadie le habló de lo que necesitaba.

En esta etapa, las personas pueden mostrar experiencias previas negativas de la introducción de otras técnicas.

- ¡Ah, tonterías! Ya teníamos esto y nada salió de eso.

Para evitar esto, recoge los dolores de las personas, pregunta qué está mal. Grabe y demuestre con precisión lo que grabó, para que la persona entienda que lo escuchó.

No repitas experiencias negativas . Retrospectiva no fue? Ahora este es un "pastel de viernes". Standups a las 7 am no fue? Ahora esto es "carga". Dar nombres diferentes a las mismas prácticas para que las personas no asocien sus experiencias negativas pasadas con ellas a menudo ayuda.

Lamentablemente, no hay soluciones universales. Construye sobre tu situación.

Implementación

El principal valor en la gestión de TI es el respeto.

Ahorramos el tiempo de otra persona . Si necesita transferir tareas de un sistema de seguimiento a otro: escriba un script, contrate a Mechanical Turk para que lo haga por usted. Resuelva este problema para que el desarrollador no transfiera todas sus tareas de un sistema a otro durante una semana; esto es una manifestación de respeto.

Ayudamos con la transición . Si presentamos una nueva práctica, nos sentamos al lado de una persona y lo ayudamos a comprender el nuevo sistema. Preparamos instrucciones por adelantado.

Describimos acciones específicas. Hacemos documentación muy específica, de acuerdo con nuestras Historias de usuarios: “Necesitamos asumir una nueva tarea. Cómo hacer esto está escrito en la documentación: abres tal o cual página en la wiki, en ella lees algo así ”.
Introducimos gradualmente, no todas las prácticas a la vez . Nuestros desarrolladores no notaron un cambio en los métodos, porque no implementamos todas las prácticas al mismo tiempo. Cuando queríamos cambiar sin problemas de un SCRUM de un día a otra cosa, no hacía retrospectivas todos los días, las tareas aparecían un poco más, las reuniones matutinas diarias migraban silenciosamente a un stand-stand más estándar. A la gente le parecía que todo estaba sucediendo gradualmente. Entonces, la práctica cambió bastante significativamente. Sobre algunas cosas, por supuesto, les dije: "Ahora cambiaremos ligeramente el proceso de trabajar con Jira, ahora será así".

Los caminos se pisotean solos . No prescriba un flujo de trabajo duro de inmediato: permita que las personas encuentren los caminos ellos mismos. Les conviene transferir la tarea en el rastreador de un estado a otro, incluso si la transfieren, y luego la solucionarán. Inmediatamente es difícil predecir lo que será conveniente, y prohibir la transición solicitada es fácil. Pero luego tienes que sufrir durante mucho tiempo para recuperar todo.

BESO Hazlo simple, al menos al principio. No complicarse demasiado.

Apoyo

Reservamos recursos por adelantado para el proceso de transición, porque es costoso . La transición de una técnica a otra es mucho dinero. Reserve su tiempo y tiempo para las personas que editarán errores en su rastreador, en su flujo de trabajo, en los procedimientos de cálculo. Si no hay recursos, y al mismo tiempo algún tipo de apuro, todo saldrá mal.
Solucionamos los errores lo más rápido posible .

Conclusión

Los proyectos son diferentes, las personas también: ¡todos necesitan técnicas completamente diferentes ! Todas las familias felices son igualmente felices, todas infelices, a su manera. Lo mismo con los proyectos: no hay dos idénticos.

Crear una técnica es una tarea de ingeniería. Exactamente lo mismo que programar y diseñar módulos de sistema. Así es como lo enfocas. Usted sabe cómo resolver bien los problemas de ingeniería, así que use todos sus conocimientos en esta nueva práctica.

El cambio de metodología es un proyecto SMART clásico . Use todo lo que sabe sobre la gestión de proyectos: defina criterios de éxito, verifique al final el cumplimiento de las tareas establecidas, recuerde el tiempo limitado, etc.

Mi manifiesto personal

Las personas son más importantes que los procesos , porque los procesos tienen que hacerse para las personas. Si la compañía tiene una edad promedio de 50 años y provienen del ejército, y usted está tratando de implementar rápidamente Kanban de inmediato, lo más probable es que no despegue. La gente simplemente está acostumbrada a otra cosa.

La principal ventaja de un programador es su pereza. Cree procesos para que las personas pasen incluso menos tiempo en ellos, y los desarrolladores sean los primeros en ejecutarlos para implementarlos. Si las personas no buscan implementar procesos, entonces no entienden por qué.

Sucede que algunas prácticas son difíciles de implementar, ya que son difíciles de entender. A veces es más fácil cambiar la práctica, tal vez no corresponde a sus tareas ni a su gente. Como último recurso, cambie a las personas, pero es más costoso que cambiar la práctica.

El resultado es más importante que los hábitos . El hábito más terrible es el hábito de escuchar acerca de una nueva herramienta, traerla a casa e inmediatamente usarla. El culto a la carga es un hábito terrible contra el que luchar. Pero el miedo a cambiar algún tipo de práctica porque "siempre lo hicimos", incluso si ya no es efectivo, también es perjudicial.

Y a veces, en general, las tareas son tan diversas que los hábitos se vuelven peligrosos. Por ejemplo, cuando se comunica con personas vivas.

La persuasión es más efectiva que las órdenes . La mejor motivación es comprender el significado de su trabajo y compartirlo. A los desarrolladores les gusta facilitar la vida de los usuarios, ahorrar dinero a las empresas y simplificar sus vidas, así que cuénteles sobre los objetivos de sus acciones. Aprende a convencer.

Los tres principios son mi imagen personal del mundo. Si tiene otras presuposiciones, probablemente necesite una metodología diferente para construir técnicas.

En el comité del programa TeamLead Conf , también estamos más familiarizados con el antiguo Lego, por lo que seleccionamos cubos en el programa desde el cual usted mismo puede construir los procesos que más le convengan. Para la conferencia de otoño en San Petersburgo, ya se ha reunido un conjunto de 15 partes , pero aún estamos aceptando solicitudes para informes, escriba .