La medida de la inteligencia es
La capacidad de cambiar.
Albert einstein
Prólogo
Estoy presentando "Reflexiones sobre Agile" a la comunidad de TI, o este artículo puede llamarse "Agile, ¿sigue siendo una filosofía o una metodología de diseño?"
El propósito de este artículo es discutir con la comunidad de TI el problema de Agile que tuve después de muchos años de práctica del proyecto, las conclusiones y el currículum que obtuve en base al análisis de este problema.
La pregunta en sí misma se cita de manera algo más baja, ya que para proceder a ella, tiene sentido establecer algunos argumentos y conclusiones.
Temas similares ya se han planteado sobre Habré en varios hilos de discusión, por lo que el tema es urgente y tiene su propia historia.
En mi opinión, la mayoría de los artículos no dan una respuesta inequívoca a mi pregunta, por lo que este artículo puede ser de interés para muchos.
Varios artículos sobre Habré sobre el tema:
Brevemente sobre el tema
Para dejar un poco claro dónde "sopla el viento", noto que mi experiencia en el campo de las TIC es de más de 10 años. Al comienzo de su carrera, trabajó activamente en telecomunicaciones, he estado trabajando en desarrollo de software hace relativamente poco, no más de cuatro años.
A lo largo de su carrera, participó en varios proyectos de TI y telecomunicaciones, en el rol de Gerente de Proyecto, en los últimos años también fue analista de negocios y se probó a sí mismo como programador. Como resultado de una breve pero voluminosa inmersión en el desarrollo de Java, no obtuvo una gran experiencia, pero sin embargo, experiencia en desarrollo independiente, bombeando habilidades técnicas como programador junior.
Ahora estoy trabajando activamente en el campo del desarrollo de software como Project Manager, opcionalmente como Business Analytics.
Por lo tanto, el tema de discusión de este artículo es la práctica de la gestión de proyectos para el desarrollo de productos de software, además, en relación con el desarrollo interno.
Comprendiendo la pregunta del autor
A lo largo de su experiencia en proyectos de TIC, se le ocurrió una regla clave: administrar un proyecto utilizando la metodología del proyecto es bueno, no está claro sin una metodología.
En relación con lo expresado anteriormente, surgió la necesidad de estudiar varias metodologías de diseño, metodologías ITSM, varios libros de negocios sobre el tema y simplemente libros "inteligentes" y complejos.
Dada la popularidad de PMI en general y mi industria de telecomunicaciones nativa en particular, comencé a estudiar con PMBoK. Aunque este complicado Talmud no se entendió de inmediato, más de una vez al leer el siguiente capítulo tuve que pensar en lo que fuman los mismos compiladores del libro. Como resultado, el cuerpo de conocimiento se descompuso en átomos y se adoptó por completo. Por cierto, ni una sola vez se implementa en una serie de proyectos con "celo proletario", paciencia y agilidad (no PMBoK, por supuesto, pero se introdujeron sus herramientas).
Comprender PMBoK viene con experiencia.
@PM
Además de este trabajo "épico", se estudiaron y estudiaron otras metodologías, simplemente había autores de libros sobre gestión de proyectos (aunque personalidades como T. Demarco, S. Berkun, S McConnell no son solo autores, sino algo más), no todos tiene sentido, y el artículo no trata sobre eso.
En resumen, el autor del artículo sobre el tema del tema, trata de mantenerse al día con las tendencias mundiales, no olvida los clásicos.
Profundizar en la gestión de proyectos de software.
Aburrido en las telecomunicaciones después de ocho años de trabajo, y decidiendo seguir adelante, se apresuró a TI.
Resultó que el sector de TI no quiere vivir en un marco claro de "cascadas" clásicas, GOST 34 no está de moda, a menos que, por supuesto, se tenga en cuenta al Estado. sector. Hay otras tendencias en la gestión de proyectos en la gestión global de proyectos.
El manifiesto ágil no podía pasar. Habiendo estudiado varios libros y hablado con varios colegas, decidí que Agile es, al menos, interesante. Pero no está del todo claro cómo trabajar con esto en Rusia, la filosofía no alcanza la metodología y en nuestro país existe la sabiduría popular de "lo que no está prohibido está permitido".
Como resumen: llegué a la conclusión de que Agile es ciertamente algo interesante, pero, sin embargo, es más adecuado para libros de moda y pequeños proyectos, pero no está claro cómo ponerlo en práctica.
El análisis de los artículos sobre Habré, en general, confirmó el breve resumen dado anteriormente.Después de varias iteraciones de aprender Ágil de los libros, tuve la suerte de participar en varios proyectos domésticos Ágiles.
No fue divertido en absoluto con un Ágil tan ágil, y un RP con experiencia en la planificación y gestión de proyectos de la industria de las telecomunicaciones fue simplemente triste. Cuando se trata de tomar el control del desarrollo espontáneo de tales compañeros, todo se rompe por completo y los muchachos dicen al unísono: "Somos creativos, tenemos Agile, no nos molestemos en vivir / trabajar / desarrollarnos". No quieren aprender y pensar, solo tienen a Agile en su cabeza.
Pero a pesar de mi escepticismo, Agile caminó por el país, fue promovido activamente por G. Gref y profesado por varios gurús occidentales y nacionales de la industria de TI.
Pero, como lo ha demostrado la experiencia personal, Agile usa todo a su manera, con nuestra mentalidad acabamos de crear "Agile en ruso".
Como resultado, la pregunta creció y se hizo más fuerte, y nadie pudo responderla.
¿Qué es este Agile de todos modos, una pila filosófica de ideas sobre psicología y organización laboral, extravagancia de la razón y no un deseo de trabajar de acuerdo con las reglas, o todavía está ocultando algo más serio desde un punto de vista metodológico, algo que se puede aplicar aquí? patria, en proyectos serios, ¿qué es lo que merece atención?Antes de completar esta sección, hay varios puntos que vale la pena señalar:
- Después del lanzamiento de la 6ta edición de PMBoK en 2018, el tema de Agile se volvió aún más interesante (en la 6ta edición, los autores incluyeron casos usando Agile).
- Para leer, leí el libro de Lawrence Leach, "A tiempo y dentro del presupuesto".
Libro de Lawrence Leach, "A tiempo y dentro del presupuesto"
Un libro interesante sobre gestión de proyectos que utiliza el método de "Cadena crítica", el autor puede atribuirse a los ideólogos de la gestión pesada. El libro de L. Lich describe un enfoque difícil pero extremadamente interesante para la aplicación de las teorías de E. Deming y E. Goldratt en la planificación de proyectos.Dado el conocimiento teórico y práctico adquirido, la comprensión de lo incompleto en la comprensión de Agile como metodología para su implementación adecuada en proyectos nacionales fue creciendo.
Juego final
El PMBoK ágil o adaptativo adecuado de Mike Cohn.Por casualidad, o como dicen, "de repente de la nada", me encontré con otro libro sobre Agile. Este es un libro escrito por un tal Mike Cohn (Cohn Mike) titulado “Agile. Evaluación y planificación de proyectos.
Al principio, sugirió que este es otro libro de negocios que describe que Agile es genial, moderno y juvenil.
Así fue y decidió leer el prefacio, pero ya después de leer el primer capítulo se hizo interesante quién era, este Mike Cohn, y por qué escribe cosas tan correctas.
Referencia rápida ¿Quién es Cohn Mike?
Fundador de Mountain Goat Software, una consultora de gestión de procesos y proyectos. Se especializa en ayudar a las empresas a implementar un enfoque ágil para aumentar la eficiencia. Detrás de Mike hay más de 20 años de experiencia trabajando como gerente en organizaciones de varios tamaños, desde nuevas empresas hasta compañías de Fortune 40. Es cofundador de Agile Alliance y es miembro de su junta directiva.No planeo describir el libro por completo en este artículo, ya que es mejor leerlo a los mismos (aquellos que lo necesitan), pero indicaré lo principal, el libro de Mike es un PMI PMBoK revisado teniendo en cuenta la filosofía del manifiesto Ágil.
Notaré de inmediato que Mike no escribió otro conjunto de conocimientos, aburrido e incomprensible, no copió PMBoK. En cambio, Mike Cohn creó un libro interesante, fácil de leer y relevante:
- Describió los principios y reglas que deberían estar en Ágil;
- Herramientas descritas para planificar y evaluar el trabajo;
- Dio una idea y gestión de desarrollo competente;
- Y mucho mas.
El libro describe el ciclo de vida completo del proyecto, se centra en la fase de planificación del proyecto, describe métodos y enfoques muy interesantes y sólidos para planificar y evaluar el trabajo, y describe los enfoques y las herramientas para las etapas del proyecto, el monitoreo y el control.
A pesar de que el libro me sorprendió con su funcionalidad, aplicabilidad y madurez metodológica, Mike también aplicó un método extremadamente interesante y difícil de describir para mitigar los riesgos de incertidumbre, que Lawrence Leach describe en su libro. Con todo lo anterior, Mike ofrece en un lenguaje simple y comprensible cómo implementar y extender este método en la práctica.
Para construir cualquier proceso, necesita reglas, normas y principios, Mike nos los describió.
Resumen
En mi opinión, nos hemos enfrentado a varias preguntas interesantes desde 2001:
¿Necesitamos filosofía ágil, metodología o somos suficientes principios?
¿Queremos desarrollar software de alta calidad de manera eficiente y clara, o dejaremos esta prerrogativa elegida y continuaremos "inventando una bicicleta"?
El libro de Mike, en mi opinión, define las reglas de las que muchos quieren alejarse, pero la experiencia muestra que las reglas aún son necesarias.
Además del descrito anteriormente, el libro de Mike brinda instrucciones metodológicas claras (aunque a alguien puede no gustarle esta palabra) sobre cómo se debe construir la gestión de proyectos de software ágil.
En cualquier caso, todo estará como estará con nosotros, pero una cosa está clara, las reglas y principios son necesarios en todo, y están en Ágil.
Estos principios se describen y fijan, se pueden estudiar, se pueden usar.
Para finalizar mi currículum, designaré lo siguiente:
Ageli no está en crisis, Agile no es un problema, Agile está trabajando.La única pregunta es si queremos estudiar las reglas y hacer lo que se nos prescribe, o si queremos seguir trabajando como queremos.
Nunca pierdas una santa curiosidad.
Albert einsteinPSEstimados lectores, que sin embargo leyeron el artículo, estoy muy interesado en su opinión y comentarios, así como en recomendaciones sobre libros similares, como el libro de Mike Cohn.