Что же все таки такое этот Agile, философский стэк идей по психологии и организации труда, сумасбродства разума, и не желания работать по правилам, или за этим все же скрывается что то более серьезное с методологической точки зрения, то что можно применить и у нас на родине, на серьезных проектах, что то стоящее внимания?
Одна из главных проблем в понимании Agile — это попытка сделать из этого методологию. Agile прост до безобразия в своих 4 ценностях. И уже опираясь на них можно что-то делать, но это уже будет что-то другое. Это как scrum = agile. Нет, scrum это не agile, он разделяет ценности agile. Согласитесь, это несколько иное.
Ценности agile не новы в истории. Просто умные люди сформулировали то, что витало в воздухе. Чтобы не заводить себя в тупик мыслями про agile, просто задайте себе самому вопросы про ценности agile — вы их разделяете или нет? Если да, то смотрите на бизнес, взаимоотношения с клиентами, с заказчиками, с партнерами, с сотрудниками через эту призму и будет вам счастье. Если не разделяете, то и забудьте про этот agile, как про страшный сон. Будьте проще.
Ари ван Беннекум — сходите на его тренинг "agile в бизнесе" — полезно будет. А то по вам получается, что agile в компании сам по себе, и вы там пилите и пилите продукт, а топы вам деньги только подваливают и подваливают. Мечта просто. Странный у вас какой то бизнес, не, ну если это очередное сайтостроительство, то наверное. А в энтерпрайзе люди чаще всего деньги считают. И agile там есть, только он там связан с бизнесом, а не сам по себе.
Почему проекты так сложно закончить в срок и почему Scrum в этом не поможет? На практике по классике проектного управления при использовании проектного треугольника ограничений (сроки, деньги, функциональность) обычно гонятся за необходимостью обеспечить полную функциональность, отраженную в ТЗ, конечно же по ходу проекта появляются новые требования или существующие проходят уточнения. Отсюда плывут деньги и/или сроки.
Что предлагает Scrum? По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги. И вот тут и получается, чтобы сделать проект вовремя и в бюджете приходится жертвовать функционалом. Так что опять же на практике бизнес на такое обычно не идёт. Топам нужно понимать, когда деньги вернутся от проекта. Scrum молчит на этот счет.
По проблемам: сложность продукта?
А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.
Идем далее. Можете назвать сроки после понимания эффективности команды? И Топы вам такое позволяют? Скажите, где это — мы идем к вам. Обычно же сроки всегда! ограничены. Может не называются топами, но в голове у них они есть. Так что…
А все проблемы в проектах из-за людей, из-за их неумения коммуницировать, из-за низкой коммуникативной компетенции руководителя проекта.
Нет таких технологий управления проектом как agile или водопад. Agile — это философия, ценности, мировоззрение. И если заказчик и подрядчик использует военный подход, то не думаю, что они разделяют принципы agile.
Одна из главных проблем в понимании Agile — это попытка сделать из этого методологию. Agile прост до безобразия в своих 4 ценностях. И уже опираясь на них можно что-то делать, но это уже будет что-то другое. Это как scrum = agile. Нет, scrum это не agile, он разделяет ценности agile. Согласитесь, это несколько иное.
Ценности agile не новы в истории. Просто умные люди сформулировали то, что витало в воздухе. Чтобы не заводить себя в тупик мыслями про agile, просто задайте себе самому вопросы про ценности agile — вы их разделяете или нет? Если да, то смотрите на бизнес, взаимоотношения с клиентами, с заказчиками, с партнерами, с сотрудниками через эту призму и будет вам счастье. Если не разделяете, то и забудьте про этот agile, как про страшный сон. Будьте проще.
Как говорил товарищ Сталин — у каждой проблемы есть ФИО
Ари ван Беннекум — сходите на его тренинг "agile в бизнесе" — полезно будет. А то по вам получается, что agile в компании сам по себе, и вы там пилите и пилите продукт, а топы вам деньги только подваливают и подваливают. Мечта просто. Странный у вас какой то бизнес, не, ну если это очередное сайтостроительство, то наверное. А в энтерпрайзе люди чаще всего деньги считают. И agile там есть, только он там связан с бизнесом, а не сам по себе.
Что предлагает Scrum? По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги. И вот тут и получается, чтобы сделать проект вовремя и в бюджете приходится жертвовать функционалом. Так что опять же на практике бизнес на такое обычно не идёт. Топам нужно понимать, когда деньги вернутся от проекта. Scrum молчит на этот счет.
По проблемам: сложность продукта?
А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.
Идем далее. Можете назвать сроки после понимания эффективности команды? И Топы вам такое позволяют? Скажите, где это — мы идем к вам. Обычно же сроки всегда! ограничены. Может не называются топами, но в голове у них они есть. Так что…
А все проблемы в проектах из-за людей, из-за их неумения коммуницировать, из-за низкой коммуникативной компетенции руководителя проекта.
Мне кажется, как минимум вот это:
"Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им"