соответствие культуре компании — вполне профессиональное требование :)
там же не только код писать, но и с людьми взаимодействовать приходится. вводить нового человека — это и так стресс для коллектива, а если он еще и совсем чужероден среде — будет большая беда)
далеко не всегда
у проекта часто есть время жизни
если время жизни проекта 2 года, а выращивать его до результата 4 — то мы просто продолбаем 2 года и выкинем результат.
По-моему, здесь нет противоречия :)
Просто тратить время тестировщиков на написание юнит-тестов — чаще всего не выгодно, дешевле это повесить на разработчиков :)
Скрам стоит использовать, когда не очень понятно, что будет дальше и долгосрочное планирование не работает.
Ватерфол наоборот — хорошо работает, когда план уже понятен. Такое вполне бывает.
У меня знакомые собираются выпускать приложение, но сами проргаммировать не умеют, будут заказывать.
При этом они 3 месяца валидируют идею, собирают прототипы на моках, делают дизайн, тестируют на пользователях.
В итоге — при самой разработке там скрам нафик не нужен, просто за 2 недели оживить прототип, все остальное готово. Есть ТЗ, бери и делай по нему, ничего меняться уже не будет, все давно проверено.
потому что делать Scrum и быть Agile — это разные вещи :)
Если команда заявляет, что «мы не пишим документацию, потому что мы Agile» — это плохой признак.
Если команда заявляет, что «мы не можем поменять таски в итерации, потому что у нас Scrum» — это тоже плохой признак.
Если при проблемах с клиентом люди начинают тыкать в договор — это очень плохой признак.
И если вместо решения проблем начинают заявлять «у нас процесс такой» — все очень печально :)
чтобы продать это время другому клиенту — надо еще этого клиента найти :) он должен уже быть готов к работе, а готовят его как раз эти люди.
то есть — чтобы раньше начать с ним работать — надо иметь ресурс этих людей. но мы не можем знать, когда ресурс освободится, а долго держать клиента и не работать с ним — опасно, есть риск что он передумает.
если я правильо понял — поэтому и делают банк времени менеджеров, чтобы можно было пустить чуть больше клиентов, но не рисковать, что они успеют остыть :)
Судя по всему, у вас там Scrum с XP. И после статьи первая мысль — куда смотрим ваш Скрам-мастер? У него явно много работы :)
Меняющиеся требования и отменённые фичи — эти пункту в минусах намекают, что программисты еще не восприняли Agile как образ мышления. Над этим важно работать :)
Проблемы с дизайнерами — это намекает, что что-то не так с планированием и взаимодействием между людьми. Надо общаться с дизайнерами и планировать вместе, слушая друг друга :)
Потеря времени во время стендапов — меняйте формат стендапов, чтобы вовлекать всех в обсуждение, а не просто отчитываться :)
Личная жизнь — если это происходит часто, то опять же, у вас серьезные проблемы с планированием :)
Плохой код, TDD и парная разработка — это все нужно, чтобы проргаммист чаще проверял свой код. Если этого не делать — тестировщики будут перегружены лишней работой, а их часто в команде меньше. Поэтому тратить их время на то, что может сделать и проверить сам программист — не выгодно :)
В целом: манифест — это не громкие слова, а способ избежать кучи проблем :)
Проблема в том, что в таких конторах часто получается формальный кастомизированный Scrum, а Agile там и не пахнет :(
Можо сделать гибкий waterfall — и он будет работать гораздо круче таких подходов.
А можно внедрить Scrum, но толку не будет никакого. Но зато всем можно рассказывать, что «у нас Agile» :)
Вообще — в скраме эти выступления задуманы, чтобы обсуждать не закрытые вчера таски, а проблемы, которые возникли :)
Разработчики очень неохотно рассказывают, что где-то у них случился затык и решение не придумывается.
Но, если я обещал вчера таск сделать, но возникли проблемы — на общем собрании я об этом расскажу и команда мне поможет.
А так — мог бы до дедлайна возиться.
Но, к сожалению — часто стендапы делают формальными, как и вообще методологию.
А зачем каждому своя отдельная доска?
Этим вы снижаете пользу как от стендапов, так и от канбана.
Там как раз смысл в том, чтобы визуализировать весь поток работы команды в одном месте, на стендапе увидеть проблему и дружно ее решить. А если у каждого свой угол — общая картина размывается.
судя по бумстартеру — он пытался стать продажником.
и, похоже, осознал, что именно надо продавать :)
это же крутой пиар :) там в одной из акций он продает «экспериментальную услугу — биографию следующей жизни». с такой промо-кампанией у него будет куча клиентов. пофиг на мнение научного сообщества, он на этом хорошо заработает :)
вот как раз из-за того, что люди боятся упреков за работу — такие инструменты и делают.
если бы каждый сотрудник был готов сразу придти к менеджеру и честно сказать «у меня проблема, вот тут можем зфакапить. надо решать, но у меня не полчается» — стендапы были бы не нужны :)
если эти сходи просто формальность — тогда да, они унылы.
если же их подстраивать под задачи команды — это замечательный интсрумент.
хороший вариант старта — как раз тикеты и их статус, а не фромально отвечать на вопросы.
в стиле «хм, ты же хотел вчера этот тикет закрыть, в чем проблема?»
надеяться, что без таких сходок кто-то будет ходить и смотреть статусы чужих задач — очень наивно :)
затем же, зачем при разработке используется ide, сниппеты, библиотеки, и прочее.
бизнес хочет зарабатывать деньги, желательно вкладывая меньше ресурсов.
при этом у бизнеса уже есть опыт, который фиксируют в методологиях.
в зависимости от типа проекта подбирают те практики, которые ему подходят и позволяют сэкономить ценный ресурс.
по-моему, вся проблема от того, что люди валят в кучу Agile манифест и Agile методологии :)
Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)
Люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Просто не надо отгораживаться от людей процессом и быть открытым к общению :)
Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)
Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)
Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)
Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)
там же не только код писать, но и с людьми взаимодействовать приходится. вводить нового человека — это и так стресс для коллектива, а если он еще и совсем чужероден среде — будет большая беда)
у проекта часто есть время жизни
если время жизни проекта 2 года, а выращивать его до результата 4 — то мы просто продолбаем 2 года и выкинем результат.
Просто тратить время тестировщиков на написание юнит-тестов — чаще всего не выгодно, дешевле это повесить на разработчиков :)
Ватерфол наоборот — хорошо работает, когда план уже понятен. Такое вполне бывает.
У меня знакомые собираются выпускать приложение, но сами проргаммировать не умеют, будут заказывать.
При этом они 3 месяца валидируют идею, собирают прототипы на моках, делают дизайн, тестируют на пользователях.
В итоге — при самой разработке там скрам нафик не нужен, просто за 2 недели оживить прототип, все остальное готово. Есть ТЗ, бери и делай по нему, ничего меняться уже не будет, все давно проверено.
Если команда заявляет, что «мы не пишим документацию, потому что мы Agile» — это плохой признак.
Если команда заявляет, что «мы не можем поменять таски в итерации, потому что у нас Scrum» — это тоже плохой признак.
Если при проблемах с клиентом люди начинают тыкать в договор — это очень плохой признак.
И если вместо решения проблем начинают заявлять «у нас процесс такой» — все очень печально :)
то есть — чтобы раньше начать с ним работать — надо иметь ресурс этих людей. но мы не можем знать, когда ресурс освободится, а долго держать клиента и не работать с ним — опасно, есть риск что он передумает.
если я правильо понял — поэтому и делают банк времени менеджеров, чтобы можно было пустить чуть больше клиентов, но не рисковать, что они успеют остыть :)
Меняющиеся требования и отменённые фичи — эти пункту в минусах намекают, что программисты еще не восприняли Agile как образ мышления. Над этим важно работать :)
Проблемы с дизайнерами — это намекает, что что-то не так с планированием и взаимодействием между людьми. Надо общаться с дизайнерами и планировать вместе, слушая друг друга :)
Потеря времени во время стендапов — меняйте формат стендапов, чтобы вовлекать всех в обсуждение, а не просто отчитываться :)
Личная жизнь — если это происходит часто, то опять же, у вас серьезные проблемы с планированием :)
Плохой код, TDD и парная разработка — это все нужно, чтобы проргаммист чаще проверял свой код. Если этого не делать — тестировщики будут перегружены лишней работой, а их часто в команде меньше. Поэтому тратить их время на то, что может сделать и проверить сам программист — не выгодно :)
В целом: манифест — это не громкие слова, а способ избежать кучи проблем :)
Можо сделать гибкий waterfall — и он будет работать гораздо круче таких подходов.
А можно внедрить Scrum, но толку не будет никакого. Но зато всем можно рассказывать, что «у нас Agile» :)
Разработчики очень неохотно рассказывают, что где-то у них случился затык и решение не придумывается.
Но, если я обещал вчера таск сделать, но возникли проблемы — на общем собрании я об этом расскажу и команда мне поможет.
А так — мог бы до дедлайна возиться.
Но, к сожалению — часто стендапы делают формальными, как и вообще методологию.
Этим вы снижаете пользу как от стендапов, так и от канбана.
Там как раз смысл в том, чтобы визуализировать весь поток работы команды в одном месте, на стендапе увидеть проблему и дружно ее решить. А если у каждого свой угол — общая картина размывается.
и, похоже, осознал, что именно надо продавать :)
это же крутой пиар :) там в одной из акций он продает «экспериментальную услугу — биографию следующей жизни». с такой промо-кампанией у него будет куча клиентов. пофиг на мнение научного сообщества, он на этом хорошо заработает :)
если бы каждый сотрудник был готов сразу придти к менеджеру и честно сказать «у меня проблема, вот тут можем зфакапить. надо решать, но у меня не полчается» — стендапы были бы не нужны :)
если же их подстраивать под задачи команды — это замечательный интсрумент.
хороший вариант старта — как раз тикеты и их статус, а не фромально отвечать на вопросы.
в стиле «хм, ты же хотел вчера этот тикет закрыть, в чем проблема?»
надеяться, что без таких сходок кто-то будет ходить и смотреть статусы чужих задач — очень наивно :)
бизнес хочет зарабатывать деньги, желательно вкладывая меньше ресурсов.
при этом у бизнеса уже есть опыт, который фиксируют в методологиях.
в зависимости от типа проекта подбирают те практики, которые ему подходят и позволяют сэкономить ценный ресурс.
Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)
Люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Просто не надо отгораживаться от людей процессом и быть открытым к общению :)
Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)
Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)
Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)
Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)