Nuestro mundo es muy extraño. Y cuanto más avanzas, más raro se vuelve. Y entenderás qué demonios.
Hay ingenieros y programadores en el mundo. A veces todo en uno. Personas que entienden qué es un algoritmo. Además, las personas que crean estos algoritmos. Son conscientes de que el algoritmo creado es adecuado para resolver un problema, pero no es adecuado para otro. Entendiendo que si el algoritmo se modifica ligeramente, podrá resolver problemas relacionados. No dude en descartar la mitad del algoritmo de otra persona para que resuelva mejor el problema actual.
Los programadores crean una solución para una tarea o para una clase de tareas. Esta es la esencia de la profesión. Siempre que sea posible, use piezas preparadas de su propio código o el de otra persona. Y todo esta bien.
Pero, tan pronto como se trata de crear algoritmos fuera de la computadora, los programadores pierden la cabeza de repente. No estoy hablando de dibujar diagramas de algoritmos en papel, como fue el caso en el examen universitario, aquí cualquiera de nosotros puede manejarlo.
Estoy hablando de "implementación de técnicas", "trabajo en el marco", "uso obligatorio de todos los artefactos". Sobre sectas, en resumen.
Un poco de idiotez
Todos saben lo que es un operador condicional. No hay vida sin él. Ningún algoritmo decente funcionará. Ni en la computadora, ni en la vida.
Ahora imagine: cierta persona apareció, por ejemplo, John, y notó que hay una declaración condicional en BASIC. Lo recogí, lo descubrí y me aseguré de que funciona, sin él de ninguna manera.
Digamos que John es tonto. Pero decidió conquistar el mundo. Fui a vender BASIC. No es el lenguaje en sí, sino algún tipo de "técnica de desarrollo de software más genial", cuyo enlace central es ... Y John no lo dirá hasta que complete el curso.
De acuerdo, hubo amantes del curso, especialmente porque el precio no es alto. Vinieron, escucharon, jadearon. El elemento principal de la mejor metodología de desarrollo de software es el Operador Condicional. Escuchamos mucho sobre la declaración condicional. Por ejemplo, cómo convertirlo en un operador de opción múltiple. Se quedaron sin aliento otra vez, qué poderoso operador condicional.
La mitad de la audiencia eran programadores. Relinchando, se fue a casa. Otro cuarto eran gerentes. Se hicieron reflexivos, plantearon preguntas, alguien decidió implementar esta técnica genial en su hogar. El último cuarto fue lo mismo que John. Persuadieron al tipo para crear una franquicia, una comunidad, una autoridad de certificación y una universidad contingente.
Los programadores del curso volvieron al trabajo, ya no recordaban al Operador Condicional. Pero una hora después, los gerentes vinieron y anunciaron que ahora el desarrollo de software se llevará a cabo de acuerdo con el método más moderno. Sí, que se trata del operador condicional. En general, es mejor escribir en básico.
Las tímidas, si no tímidas, objeciones de los programadores fueron ignoradas. Frases como "maldita sea, es un operador condicional, está en todas partes" se percibieron como intentos de alardear. La rueda giró.
Y John rápidamente se dio cuenta de que solo un operador condicional no es suficiente. También debe haber un bucle, subrutina, variable, matriz, etc. De alguna manera deberíamos llamarlo todo ... En una palabra ... ¡Oh, que sean artefactos! ¡No más ni menos!
Lo principal permaneció: agregar a la metodología una cláusula de que la mejor metodología de desarrollo de software es el conocimiento holístico, holístico. Por lo tanto, no se puede arrojar una sola pieza. Y no puede agregarle nada: dejará de funcionar. Como está escrito, que así sea.
Gracias al entusiasmo de John y sus amigos, ahora todo el mundo usa no un operador condicional, sino un operador condicional, no un ciclo, sino un ciclo, etc., según la lista. Aquellos que entendieron la idiotez de la situación se han retirado o callado por mucho tiempo. Aquellos que han venido recientemente creen firmemente que el Operador Condicional es parte de la mejor técnica de desarrollo de software creada por John. Y todos los demás operadores condicionales son una apariencia miserable, una copia desvaída y una pieza de conocimiento arrancada de contexto.
Cualquiera que se atreva a votar en Internet (o, Dios no lo quiera, dentro del equipo) será sometido a una feroz condena y enojo minúsculo: ¡usted, botas, no ve los beneficios del Operador Condicional! Y si la persona desafortunada pide explicar cuál es el significado y la diferencia del operador condicional en C ++, javascript o incluso 1C, obtendrá la respuesta "es imposible de explicar", "no comprende" o "vaya a leer la guía".
Herramientas y Algoritmos
Todos entienden qué es un operador condicional y cómo usarlo en algoritmos. Del mismo modo, todos entienden lo que, por ejemplo, es una pegatina con una tarea grabada. Las etiquetas aparecieron antes del scrum y viven fuera de él. Mire la computadora de un contador, proveedor o vendedor. Todavía no han eliminado el hábito de colgar un montón de pegatinas con tareas urgentes en el monitor. Se escribirá una contraseña en una de las pegatinas.
Cualquier técnica se puede desmontar fácilmente en herramientas, principios y relaciones. Al igual que cualquier algoritmo se desarma en figuras de diferentes formas y propósitos: el comienzo y el final del algoritmo, acción, condición, subrutina.
Cualquier técnica tiene un alcance. No todo está absolutamente allí: hay un entorno más adecuado, hay menos. Igual que los algoritmos.
Cualquier técnica puede ser modificada. Tire las piezas, agregue otras nuevas, modifique herramientas específicas. Al igual que los algoritmos.
Cualquier técnica se puede mezclar, en su totalidad o en trozos. Tome la mitad de una, una cuarta parte de la otra, otra cuarta parte, invente usted mismo. Cuando crea una aplicación o servicio, es obvio para usted.
Es cierto, la pregunta sigue siendo: ¿será la metodología una metodología, si se cambia?
Aquí se explica cómo responder a esta pregunta, por ejemplo, la conocida Guía Scrum:
“Los roles, artefactos, reglas y eventos de Scrum no están sujetos a cambios. Aunque el uso de elementos individuales de este marco es aceptable, el resultado no puede llamarse Scrum. Scrum existe solo como un marco completo, pero puede acomodar otras técnicas, metodologías y prácticas ".
Un poco como John y su operador condicional, ¿no? Parece que cambia si quieres, solo que no será un scrum. Y cuál será el resultado: el infierno lo sabe. Por si acaso, notaron que puedes intentar meter algo dentro. Pero la columna vertebral debe permanecer. De lo contrario ... Es incluso aterrador imaginarlo.
¿Es realmente aterrador? ¿Qué sucederá si algunos de los artefactos son arrojados o reemplazados? Y de todos modos, ¿cuál es el punto? ¿De dónde vinieron? ¿Por qué se cree que funcionan solo en tal combinación, como decidieron los autores?
Tratemos de descubrir las partes.
Sprint y Sprint Backlog
Gran herramienta, por cierto. Inventado, probablemente, hace mil años. Siempre se le ha llamado de manera diferente, pero el más común, probablemente, es el "Plan". Y humanamente: "hacer una cierta cantidad de trabajo durante un cierto período de tiempo".
Para mí, como 1Sniku, es mejor conocido como planificación de calendario espacial (OKP). Es ampliamente utilizado en la producción y planificación de ventas. Por ejemplo, el plan de ventas de un gerente de 1 millón de rublos por mes es un retraso y un sprint. A veces una cifra es suficiente, a veces hay un desglose por grupo de productos o restricciones en el mercado, o incluso hay una lista específica de artículos, si así lo requiere la estrategia de la compañía.
La producción es aún más fácil. Bujes - 1000 piezas, Ejes - 2000 piezas, Rotores - 500 piezas. Este es, digamos, un plan semanal. Él es la cartera de pedidos del sprint semanal del sitio de producción. Es cierto que no se puede explicar a los trabajadores que esto no es un plan, sino un sprint.
La herramienta es buena en comparación con la gestión generalizada del tiempo, cuando el grupo de tareas del programador se estima por los costos laborales, ordenados por algún criterio, y cada tarea tiene un plazo. En producción, esto se llama planificación de turnos o planificación de taller, a partir de la cual se crean tareas de producción que contienen una lista de piezas y productos semiacabados, operaciones técnicas, materiales, entradas y salidas (dónde obtener qué y dónde transferir el resultado).
Para los programadores, la planificación del taller no funciona bien, y no hay nada que discutir aquí. El tiempo de procesamiento de una pieza en un modelo de máquina específico se conoce desde hace mucho tiempo y con bastante precisión. Frecuencia de servicio también. Suficiencia de los materiales evaluados. Toma y haz. Las variaciones que interfieren con la implementación del plan en la producción en masa generalmente no tienen un efecto significativo. Y si lo hacen, existen excelentes métodos para analizarlos y eliminarlos.
Las variaciones del programador son mucho más fuertes. No es una máquina herramienta, como a algunos gerentes que acudieron a TI por ventas o producción no les gustaría. Por lo tanto, la planificación del taller (tarea + fecha límite) no es adecuada para un programador. Así que se le ocurrió a las personas sensatas: debe elevarse a un nivel más alto, no para programar el rendimiento en minutos, sino para dar volumen por un período. Solo se les ocurrió otro nombre: sprint y retraso.
Llenar el plan de producción del calendario volumétrico se basa en principios similares a la formación de una reserva de sprint. Incluso existe tal cosa: "elige un plan". Hay necesidades del mismo departamento de ventas (= gran cartera de pedidos), hay un rendimiento de producción (= capacidades del equipo en números), además hay criterios de selección claros: la cantidad de ventas, la rentabilidad de cada posición, los parámetros del cliente (por ejemplo, condiciones de pago). Calificó un plan de producción e inmediatamente vea qué resultado financiero aproximado obtiene. Este no es un "lanzamiento" efímero.
¿Hay algún inconveniente en esta herramienta? Por supuesto, como cualquier otro.
Si comprende, la acumulación de Sprint es la misma planificación del taller, solo que sin una secuencia bien organizada de resolución de problemas. Por lo tanto, todas las tareas tienen una fecha límite: el final del sprint. Una vez que las tareas tienen una fecha límite, aparece un efecto desagradable: al comienzo del sprint, la actividad puede ser significativamente menor que al final.
Así es como funciona cualquier psicología humana. Siempre desea quedarse al comienzo del período de ejecución, ya sea una tarea o una acumulación. Tómese un descanso del período anterior, especialmente, de su parte final, cuando fue necesario dar un resultado "enorme". Por supuesto, hay personas que son estables y rítmicas, que trabajan toda la semana a la misma velocidad, pero la mayoría comienza a "trabajar normalmente" en algún lugar el miércoles.
¿Es posible prescindir de Sprint y su cartera de pedidos? Fácil
Por ejemplo, aplicando la herramienta "lo antes posible". En general, esta no es una forma de Praporsky, sino una estrategia bastante normal para la planificación del mismo taller (lo antes posible, lo antes posible). Significa que los problemas se "pegarán" al comienzo del intervalo de tiempo, es decir Para el lunes, no el viernes, como con la estrategia "Lo último posible, ALAP".
La planificación como tal no es necesaria en este caso. Hay una acumulación de productos, hay prioridades, hay una regla "lo antes posible". Toma el primero y hazlo. Terminado: tomas el segundo. Y así, desde la cerca hasta la cena. Sprint, o más bien, su esencia, es decir el tiempo que puede dejar para comprender y analizar la productividad (semana a semana, mes a mes, etc.).
¿Hay alguna deficiencia en la estrategia "lo antes posible"? Por supuesto, un millón. En primer lugar, una persona puede cansarse rápidamente. En segundo lugar, se sentirá como una máquina herramienta. En tercer lugar, lo más probable es que huya, a donde se usan sprints ordinarios con un retraso. O simplemente establecen tareas y esperan el resultado. En general, donde está más tranquilo. Pero la práctica muestra que "lo antes posible" es bastante posible vivir durante años, si es de sentido común que se trata de una estrategia de planificación, y no una sudadera.
¿Es posible lanzar un sprint y su retraso? No No porque sean nociones únicas del mismo scrum, sino porque este es un método de planificación natural que todos, de una forma u otra, usan. Hay muchas variaciones, un principio: debe hacer una cierta cantidad de trabajo durante un cierto período de tiempo.
¿Es una herramienta como un sprint un elemento único y clave de una técnica? No Esto es lo mismo que decir que escribir código en el teclado es una noción única de alguna técnica. Casi todos los textos están escritos en el teclado.
Tablero de scrum
Formalmente, un tablero no es un artefacto o una regla, pero creo que vale la pena hablar de eso también, porque hay un patrón bastante obvio entre las personas: un scrum es un tablero con pegatinas.
Aquí, en general, tú mismo entiendes todo. Un tablero con pegatinas en las que se escriben las tareas no es único. Esto es, más o menos, una herramienta multiplataforma. Mi esposa en el refrigerador a veces esculpe calcomanías con listas de tareas, aunque no sabe nada sobre ningún scrum.
¿Es buena esta herramienta? Depende de qué comparar. Sí, quizás una buena.
Por ejemplo, le permite evaluar rápidamente, mirar alrededor del grupo de tareas. En una computadora, o en cualquier otro dispositivo electrónico, las tareas deben invertirse; por lo general, todo no cabe en una pantalla. Por lo tanto, en un vistazo, también.
Otra ventaja importante es la disponibilidad general para el equipo. En cualquier momento, puede venir a ver, no entrar en ningún sistema, buscar, hacer una selección, etc.
A muchas personas les gusta la naturaleza no virtual del tablero. Después de todo, todo es virtual en una computadora; no lo toca con las manos. Y aquí, por favor, al menos lamer. Algunos, en este sentido, aman las tablas de corcho. La diferencia es algo así como entre papel y libros electrónicos.
Específicamente para un tablero de scrum, se puede notar una ventaja como la separación en dos partes: se realiza en el trabajo. El manejo doméstico de las etiquetas adhesivas implica tirar las que ya están completadas, no muy buenas, porque El progreso se ve peor.
¿Hay alguna desventaja en las tablas scrum? Por supuesto Como cualquier tabla.
Para comenzar con el hogar: borradores, calcomanías de mala calidad, mala escritura, sabotaje. Como resultado, tareas perdidas y confusión en la gestión.
En el tablero, el progreso no es muy visible. En general, para el sprint, sí. Hoy, ayer, no. De ahí la necesidad de una discusión diaria.
Específicamente, el estado de las tareas no es visible en el tablero de scrum, si la vida es más complicada que "planificado" - "hecho". El tablero Kanban parece preferible.
La junta no permite el trabajo normal si el equipo está distribuido geográficamente. Por lo tanto, aparecen tableros electrónicos.
La placa electrónica, me parece, es un signo seguro de sectarismo. Perdió todos los beneficios de lo habitual, pero, por alguna razón desconocida, continúa usándola. Probablemente solo porque es una tabla. Parte de la Metodología.
En general, una herramienta es como una herramienta. En ciertas situaciones, bien. En algunos es terrible.
¿Scrum funcionará sin una tabla? Fácil Y probado por la práctica. Y parece que, dado que el tablero no es un artefacto obligatorio, será posible continuar llamando scrum - scrum.
Scrum master
¿Quién es este papel milagroso? Como es
Hay muchas opciones Por ejemplo, un scrum master es como un entrenador de deportes. Hay, por ejemplo, un club de fútbol. El propietario de los productos allí es un gerente que define los objetivos del equipo. Un entrenador es aquel que ayuda a un equipo a alcanzar estos objetivos.
En el entorno de producción habitual, no hay entrenadores: si el club de fútbol funcionara así, el jefe simplemente iría al vestuario antes del partido y diría: "ve y gana". Y cuando pierden, él estaría feliz con la estafa. Echó a alguien, amenazó a alguien, etc. Como una fábrica
Y el entrenador, como el scrum master, sirve como proveedor entre el equipo y el gerente. Por supuesto, el entrenador tiene más poder: no es un servidor líder. Pero el resultado también se requiere de él más rápido y más comprensible: nadie esperará hasta que él facilite a alguien allí. El entrenador, como el scrum master, comprende cómo debe funcionar el equipo, es decir. él simplemente establece tareas y explica cómo resolverlas. Establece conexiones, motiva, crea y mantiene una atmósfera, etc.
Otra analogía es el comandante del pelotón, algunas fuerzas especiales. Este es un entrenador de juegos. Realiza tareas junto con subordinados, resuelve misiones de combate de la misma manera. En su tiempo libre, supervisa la preparación y mejora de las habilidades, el desarrollo de nuevos equipos y el entrenamiento físico. Por supuesto, él trabaja constantemente con el equipo en términos de psicología: motiva, apoya, ayuda. Por métodos peculiares, por supuesto, a veces, pero el objetivo es uno: la máxima efectividad de combate del pelotón.
Scrum master, en comparación con estos tipos, un freeloader. Por el resultado no es particularmente responsable. La falta de autoridad formal, al parecer, se percibe como una ventaja: es un líder servidor, pero de hecho puede convertirse en irresponsabilidad. ¿Se puede facilitar sin cesar, sin ejercer ninguna influencia en el resultado? Y cuando los echen, busque otro equipo para facilitar allí.
¿Es posible cambiar o eliminar la función de un scrum master? Por supuesto Por ejemplo, combine esta función con el propietario del producto. Sé que en la Metodología está escrito que es mejor no hacer esto; esto evitará que el maestro facilite. Pero, por otro lado, agregará metas y responsabilidades claras. Cuando el objetivo es comprensible y medible, la facilitación se convierte de una basura opcional e incomprensible en un deber tangible muy específico que afecta directamente el resultado. Como un entrenador o un escuadrón.
Es cierto, entonces se pierde el significado de llamarlo un scrum master. Probablemente sea un líder de equipo. No olvide que el "líder" es el líder. Un líder no solo es una bandera en sus manos, sino que también trabaja con motivación, objetivos, la capacidad de llevar adelante, introducir nuevos métodos de trabajo, capacitar competencias, etc. El conductor del comando, en resumen. Y en el sentido del desarrollo interno, y en el sentido de lograr resultados.
Si reemplaza el maestro con timlida en scrum, ¿qué sucederá? Esto ya no se puede llamar scrum: se ha descartado uno de los roles clave. ¿Y cómo afectará el resultado? ¿Y si es que no tiene un scrum master? Si sus funciones están manchadas por comando, ¿cómo se recomendó Belbin?
Uno facilita, el otro motiva, el tercero monitorea la implementación de las reglas. Es bastante posible para ti vivir así.Total
Bueno, todo, entonces el principio es claro. Scrum, como cualquier otra técnica, es un algoritmo tejido a partir de componentes o herramientas. ¿Quién lo tejió? Bueno, digamos Jeff Sutherland y Ken Schwaber.Imagine que dos chicos, Jeff y Ken, crearon un componente que trae buenos beneficios en el desarrollo de aplicaciones web. Lo cavó en un github, lo instaló, lo probó, ¡guau, es genial! Funciona! Y la verdad es que se ha vuelto mejor.Y luego, en algún momento, algo comenzó a molestarte en este componente. Por ejemplo, llamar a sus métodos no parece lo suficientemente polimórfico. Entras en el código fuente y descubres ...¿Qué puedes encontrar allí? Si, cualquier cosa. Por ejemplo, préstamos que no le gustan. O los componentes prestados serán correctos, pero se utilizarán de forma torcida. O bien, se indica directamente una versión específica de un buen componente, pero se está desarrollando bien y se ha vuelto mucho más fría hace mucho tiempo, pero los desarrolladores no quieren adaptar un componente de nivel superior. O puede encontrar en el algoritmo una pieza de un tamaño decente que consume bien los recursos, pero que no aporta ningún beneficio particular a su proyecto.Que vas a hacer Todos responderán algo diferente, por supuesto. Alguien ni siquiera entrará. Alguien bifurcará y arreglará lo que no le gusta. Por supuesto, obtendrá algunos problemas con la actualización. Aunque no es un hecho, cosas como scrum no cambian durante años. Alguien escribirá a los desarrolladores. No sé qué responderán.Alguien simplemente toma los componentes fuente y los vuelve a ensamblar a su manera, según sea necesario en un proyecto o producto en particular.Puedes hacer lo mismo con cualquier técnica. Quería escribir "es posible y necesario", pero no impongo mi opinión: después de todo, todos deciden.Quiero terminar con una cita de Goldratt. Esta es quizás la única de las luminarias que desarrolló algunos métodos, hablando honestamente sobre la necesidad de su cambio, adaptación, diseño y, lo más importante, comprensión de los principios de funcionamiento.Hay una diferencia entre los métodos prácticos y los conceptos fundamentales en los que se basan estos métodos. Los conceptos son generales, los métodos prácticos son la adaptación de conceptos a un entorno específico. Como ya hemos visto, dicha adaptación no es simple y hace necesario desarrollar ciertos elementos de la solución. Lo que debemos recordar es que dicha solución se basa en las premisas iniciales (a veces ocultas) sobre un entorno particular. No debemos esperar que esta solución funcione en un entorno para el cual estas premisas iniciales no son ciertas. Podemos ahorrar mucho esfuerzo y evitar decepciones si formulamos cuidadosamente estas premisas iniciales.