Комментарии 58
Радоваться
Проблема в том, что time-to-market и прочие гибкости на хлеб не намажут ни топы, ни разработчики. Поэтому вопрос про портфель — ключевой, и agile-подходы на него не отвечают. Где-то в среднем менеджменте (а точнее даже в проектном офисе) должен происходить переход от проектных действий к оценке денег: ближайших и дальнейших.
Особенно понравилось «одна agile-команда работает над одним проектом» (с которого не переключить). Это вообще антипортфель какой-то: выход превратить компанию в пучок изолированных стартапов остается, но опять получаем же портфель! Причем с которыми остается работа только по stage-gate, без возможности скринить проекты как portfolio review!
Вобщем «что хотел сказать автор» — туман догадок и противоречий.
P.S. Оригинал напоминает стандартный bullshit от HBR.
6. Руководство считает, что все эти agile и «эффективные scrum-манагеры» — профанация и развод.
Есть замечательный доклад на эту тему:
У agile самая большая проблема в том, что "хороший agile — это тот, который работает" и никто не может дать универсальный рецепт для него. Они слишком привязан к текущим кадрам и командам.
И манифест в некоторых пунктах выглядит как будто его писали оторванные от реальности теоретики и там не хватает тысячи и одной сноски.
Например:
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
А архитектурные изменения тоже? Невозможно в рамках agile реализовать такую архитекруту, которая бы была безумно гибкой и учитывала бы все возможные изменения.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Джунов куда девать?:
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
И значит документацию писать не надо, да?
Работающий продукт — основной показатель прогресса.
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
А кто будет выделять на это ресурсы, если оно уже и так работает?
Ну и куча других причин. Agile стал таким себе "хренак-хренак и в продакшн" в голове у большинства заказчиков, менеджеров и даже программистов, по сравнению с водопадом и переубедить их довольно сложно. У скольких проектов в беклоге лежит несколько десятков задач на "документирование", "покрытие тестами" и прочую муть?
и никто не может дать универсальный рецепт для него.
Потому что его нет. Вся идея построена на той же идее что и водопадная модель, но преследует цель уменьшения цикла обратной связи. Во многих командах этого цикла обратной связи между этапами вообще нет, или он слишком длинный.
В целом насколько все должно быть "гибким" и "адаптивным" надо решать с позиции того, какой профит вам нужен. Если у вас простая задача и дофига денег — нет смысла что-то выдумывать. Если денег совсем нет а идея не обкатанная, то имеет смысл строить процесс так что бы получать фидбэк о идее максимально быстро. Далее как вы правильно заметили все упирается в команду, людей, цели т.д. Часто же "agile" это недо-скрам внедренный потому что "ну тип мы хотим быть модными но менять структуру компании не планируем".
Невозможно в рамках agile реализовать такую архитекруту, которая бы была безумно гибкой и учитывала бы все возможные изменения.
Ну для начала, такие вещи как information hiding и прочие прелести декомпозиции в контексте структурного программирования придумали еще в далеком 72-ом. С тех пор ничего кардинально не поменялось. И идеи те же — что лучший способ защититься от изменений это дождаться этих изменений, рефакторинг и тд. "Адаптировать" код под новые требования. Если же у вас всплыло требование которое текущее решение к хренам ломает — значит вы плохо понимали проблему которую решали. Значит недостаточно работали над уменьшением цикла обратной связи.
Джунов куда девать?:
парное программирование, обучение, тренинги, менторинг.
А кто будет выделять на это ресурсы, если оно уже и так работает?
Допустим у нас есть проект который работает и даже приносит прибыль. И мы можем увеличить прибыль внеся правки с учетом фидбэка от конечных потребителей. Чуть-чуть инвестировали, чуть-чуть увеличили прибыль.
У скольких проектов в беклоге лежит несколько десятков задач на "документирование", "покрытие тестами" и прочую муть?
а причем тут собственно agile? Давайте рассуждать. Для начала больная для меня тема — почему тесты не пишут. Тут могу высказать свои наблюдения:
- Не пишут потому что не умеют писать тестируемый код. В итоге на тесты тратится много времени. Многие свой код только интеграционными тестами могут покрыть, а они не дают того фидбэка как юнит тесты. В итоге имеем перевернутую пирамиду тестов которая ничем не помогает. В итоге приходит менеджмент и говорит что "ваши тесты это дорого" и они правы. Хотя при нормальных условиях тесты занимают где-то до 20% времени разработки и начинают окупаться уже через месяц (если не учитывать процесс приобретения знаний разработчиком о том как писать эти тесты и тестируемый код, тут в любом случае в краткосрочной перспективе будет замедление, но опять же парное программирование и т.д. должны с этим помочь).
То есть сами по себе тесты должны быть инструментом дизайна (если мы про изолированные тесты от которых есть прок), они нас должны ограничивать. Это вынуждает больше думать. Больше думать никто не хочет. Это к слову в целом о проблемах с любыми вещами можно сказать.
Многие воспринимают тесты и разработку через тесты как инструменты для "очень опытных разработчиков". Я много разработчиков видел которые начинали свой путь в юнит тесты уже имея лет 5 неплохого опыта. И наличие опыта, который уже позволяет хоть сколько нибудь адекватный код писать, уже сильно смазывает факт наличия ограничений в виде тестов. Аля "ну а зачем я эту штуку буду тестами покрывать, я в голове прекрасно представляю как оно работает". В итоге тесты не пишутся вовсе или совсем мало.
- Если проект достаточно простой и понятный, если у вас есть четкие и понятные требования, тесты там в целом не особо помогут. Говорить что они нужны всегда и везде глупо. Хотя я не особо верю в такие проекты.
документирование
Есть разное документирование. Год назад у меня был проект, который начинался в духе "так ребят у нас есть 4 недели, надо сделать MVP, если все будет ок — будут инвестиции и будем дальше пилить". В таком варианте нет смысла заморачиваться ни о какой документации. Однако даже в той ситуации тупо для координации действий документация на самые критически важные для взаимодействие людей вещи заводилась. Через пол года когда ситуация стала намного более предсказуемой, просто завели отдельного человека который сидит периодически с членами команды и описывает документацию. Я считаю это более чем нормальной практикой. Есть конечно методики которые позволяют все это чуть эффективнее делать и получать профит от документации в виде сокращения цикла обратной связи (BDD например или specification by example), но...
парное программирование, обучение, тренинги, менторинг.
Ну то есть работать над проектом они не могут, их нужно нанимать и обучать где-то год и только потом они будут готовы, как-то так?
Допустим у нас есть проект который работает и даже приносит прибыль. И мы можем увеличить прибыль внеся правки с учетом фидбэка от конечных потребителей. Чуть-чуть инвестировали, чуть-чуть увеличили прибыль.
Проблема в том, что конечному заказчику профит не виден. Если мы говорим про аутсорс (привет, страны СНГ), то довольно сложно выбить бюджет на эти вещи.
а причем тут собственно agile? Давайте рассуждать. Для начала больная для меня тема — почему тесты не пишут. Тут могу высказать свои наблюдения:
Потому что гибкость, которая выглядит так. Приходит заказчик и такой: "О, у вас тут есть задачи на тесты? А давайте мы их заменим этой фичей, а тесты вы как-то потом напишите". И как объяснить заказчику, что agile то конечно, гибкий, но в некоторых местах нет.
Аналогично с документацией.
работать над проектом они не могут
Почему? Они как раз таки работая над проектом учатся. А что бы это было не так опасно и происходило быстрее — парное программирование с более опытными членами команды.
Правда все это в идеале… Ну и еще маленькие моменты, чтобы совсем превратить мои рассуждения в мечты. "джуниор" в моем понимании это не человек без опыта, какой-то опыт ему должна дать система образования, которая мягко скажем сейчас не эффективна. До джуниора есть еще "стажер".
В целом при достаточно большом размере команды в этом всем есть экономический профит. Для маленьких компаний профита в этом нет.
Если мы говорим про аутсорс (привет, страны СНГ), то довольно сложно выбить бюджет на эти вещи.
Еще раз, на какие вещи?
"О, у вас тут есть задачи на тесты? А давайте мы их заменим этой фичей, а тесты вы как-то потом напишите"
Лайф хак — не заводите "задачи на тесты". Вы же не заводите таски на "надо смерджить ветку". Это часть вашего процесса разработки, его не надо продавать. Вместо этого вы должны работать в сторону оптимизации всех аспектов разработки, в том числе "если тесты писать, или рефакторинг на постоянной основе выходит дорого, что можно сделать что бы снизить издержки и повысить эффективность". По сути даже по другому. Тесты и рефакторинг, или DbC или другие практики внедряются с целью увеличить эффективность. Если этого не происходит, возможно мы выбрали неправильный подход, или в целом что-то еще является причиной проблем. Существуют масса техник и подходов для решения подобных проблем, но из моего личного опыта проблема больше в том что никто не анализирует узкие места процесса разработки.
И как объяснить заказчику, что agile то конечно, гибкий, но в некоторых местах нет.
В каких местах "нет"? agile просто неудачное название, лучше было бы если бы выбрали adaptive. То есть идея в том чтобы адаптировать процесс по ситуации. Но это не значит что процесс отсутствует или что не надо документацию писать, которая может быть частью вашего процесса. Бизнесу эта штука не особо интересна, для них это лишь непонятная часть вашего процесса. Но если мы не будем этого делать, в средне и долгосрочной перспективе у нас будут очень большие проседания по скорости деливери и оверхэды по стоимости при таких вещах как изменения в команде или изменения в требованиях. То есть надо искать баланс.
Тесты те же нужны для того что бы лучше проектировать систему, она должна выйти гибкой. Если у вас выходит не так — возможно стоит обратить внимание на связанность компонентов системы, или же на качество тестов или кода. Если вы поменяли реализацию и у вас упала половина тестов — вы явно что-то сделали не так.
С другой стороны если тесты у нас есть, мы можем взять штуки вроде CI/CD и доставлять функционал клиенту чаще. Так же мы как разработчики можем более часто вносить изменения в код с целью того, что бы изменения лучше ложились на код.
Как никак единственный вариант при котором постоянный рефакторинг не спасет от резких изменений в архитектуре и т.д. это резкая смена стратегии бизнеса. Типа "так ребят, я знаю что мы писали внутреннюю CRM но с завтрашнего дня мы пишем соц сеть". Такие ситуации случаются, и их предсказать мягко скажем даже смысла нет.
Что до документации — опять же, если делать это втупую — то да, это не эффективно. Можно делать лучше.
Мое мнение о том почему все так плохо в разработки: все это сложна и надо думать, нам это не нужно. Для большинства же agile это "сделать больше и дешевле", хотя по факту все намного сложнее. Я там выше видео скидывал, там намного лучше меня объясняется разница с точки зрения бизнеса.
Почему? Они как раз таки работая над проектом учатся. А что бы это было не так опасно и происходило быстрее — парное программирование с более опытными членами команды.
Потому что так написано в agile манифесте. Над проектом должны работать профессионалы. Назвать джуна профессионалом довольно сложно, а значит более опытный член команды должен внушительное количество времени потратить на парное программирование. От 3 до 12 месяцев. Я не прав?
Еще раз, на какие вещи?
На "внимание к техническому совершенству и качеству проектировани". В реальности эти задачи сделать во время сприта в другой задаче чаще всего не получается. А значит, для них нужны другие задачи, которые нужно билить заказчику. И вот тут все печально.
Лайф хак — не заводите "задачи на тесты". Вы же не заводите таски на "надо смерджить ветку". Это часть вашего процесса разработки, его не надо продавать
Это слишком сильно зависит от проекта. В некоторых проектах вам нужно было отдать задачу и тесты подождут, некоторые задачи сразу планируются без тестов, а потом это вылазит боком и так дальше.
Даже в обычных проектах, задачи можно создавать, что бы писать тесты в то же время, пока пишется задача.
В каких местах "нет"? agile просто неудачное название, лучше было бы если бы выбрали adaptive. То есть идея в том чтобы адаптировать процесс по ситуации.
Нельзя адаптировать все. У вас должны быть тесты, у вас должен быть code review, deploy flow, у вас должна быть документация и все это должно работать в одном спринте.
Если у вас чего-то из этого нет, а только стандартные практики типа стандапа и прочего (что довольно типично), то как бы и будет все так. В этом и состоит грязный секрет agile, что на самом деле он не дает гибкости, он дает работу спринтами (итерациями). Что бы сохранять гибкость в одном аспекте (фунционал), вам нужно проявлять твердость в другом. Но проблема в том, что такого не написано в манифесте, оно скрыто под расплывчатыми формулировками, в то время как гибкость для бизнеса написана прямо.
tl;dr; Гибкость в головах, а думать что agile это спринты и scrum — это вообще не гибко.
Потому что так написано в agile манифесте.
Приведите цитату которая описывает то что вы говорите.
а значит более опытный член команды должен внушительное количество времени потратить на парное программирование.
Да, часик-два в день, а еще код ревью и прочие радости жизни. Это не нон-стоп 3-12 месяцев, не надо так сильно упрощать. Да и опять же, сложность задач на одном проекте может сильно варьироваться.
В реальности эти задачи сделать во время сприта в другой задаче чаще всего не получается.
Может тогда вам следует убрать спринты? Попробуйте FDD и подобные техники. Или просто включите тесты в definition of done задач. Вы же не будете отрицать что "запустить да потестить" входит в цикл выполнения задачи и клиенту за это отдельно не билят.
В некоторых проектах вам нужно было отдать задачу и тесты подождут
Если это подразумевает что это прототип который вы удалите — то да. Если вы планируете что код который вы реализовали останется в проекте — увы не соглашусь с вами. Просто покрытие можно сделать чуть меньше, но какой-либо способ автоматической верификации должен присутствовать.
Даже в обычных проектах, задачи можно создавать, что бы писать тесты в то же время, пока пишется задача.
зачем? Это больше похоже на какую-то бесполезную бюрократию. Лучше решите проблему почему у вас возникает подобная необходимость, ибо как правило если расходы на тесты настолько велики что надо разделять задачу на этапы, то явно что-то идет не так.
У вас должны быть тесты, у вас должен быть code review, deploy flow, у вас должна быть документация
тесты могут быть разными, покрытие может быть разное, code review может быть организован абсолютно по разному, deploy flow как вы догадались так же. Вот это и адаптируйте.Чуть-чуть документации которая позволяет просто важные решения как-то записать это не так много времени, и это все еще документация. Так же и по всем остальным пунктам.
и все это должно работать в одном спринте.
вот тут опять же, вы говорите о спринтах так как будто бы они атомарны и все что после спринта на текущий спринт не влияет. Складывается впечатление что вы как-то странно их трактуете.
Для начала напомню что существует бэклог. Затем напомню что спринт != дэдлайн, это лишь способ организации задач для команды таким образом, чтобы она не сильно отвлекалась. Задачи в спринт добавляются тогда, когда по ним нет вопросов мешающих начать разработку, например по задаче должен быть готов дизайн. Но если делать все в одном спринте то мы ничерта не успеем.
С другой стороны в течении спринта проводятся всякие бэклог рефайменты, груминги и прочие вещи которые позволяют вам держать задачи в бэклоге в том состоянии, в котором их можно будет позже закинуть в новый спринт. Или например, что бы принять какое-то решение о том как мы чего делать будем надо вообще ресерч начинать паралельно, в этом случае мы можем просто на неделю посадить человека ресерчить, а по прошествии недели смотреть что получилось и уже строить выводы что делать дальше.
То есть все намнооого сложнее чем тупо "спринты". Вся соль в цикле обратной связи. И все. Все остальное — это способы оптимизации этого цикла. И их больше чем один.
В этом и состоит грязный секрет agile, что на самом деле он не дает гибкости, он дает работу спринтами (итерациями).
вы говорите agile а имеете ввиду scrum. Типичная ошибка. Что до "дает гибкости" — он не должен "давать гибкости". Это принципы которыми надо руководствоваться выстраивая свой процесс. Свой под проект. Agile Software Development Manifesto, а не просто Agile Manifesto.
Основная идея в том что "у вас никогда не будет универсального процесса а потому не нужно пытаться его выдумывать, лучше взять какой-нибудь из десятков имеющихся и адаптировать под проект". Например берем скрам как самый распространенный фреймворк для построения процессов. Потом берем теорию ограничений, находим в процессе узкие места и чиним их. Если на проекте 50 человек, возможно вместо scrum надо применить fdd или похожие подходы.
Приведите цитату которая описывает то что вы говорите.
В принципах, тут я затупил:
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Отсюда: http://agilemanifesto.org/iso/ru/principles.html
Если это подразумевает что это прототип который вы удалите — то да. Если вы планируете что код который вы реализовали останется в проекте — увы не соглашусь с вами. Просто покрытие можно сделать чуть меньше, но какой-либо способ автоматической верификации должен присутствовать.
А это есть в agile манифесте?)
Может тогда вам следует убрать спринты? Попробуйте FDD и подобные техники. Или просто включите тесты в definition of done задач. Вы же не будете отрицать что "запустить да потестить" входит в цикл выполнения задачи и клиенту за это отдельно не билят.
Да, это бы отлично работало, если заказчик не клал на это все большой болт. Когда задача нужна на вчера, то все это идет лесом, потому что же "agile значит гибкий".
зачем? Это больше похоже на какую-то бесполезную бюрократию. Лучше решите проблему почему у вас возникает подобная необходимость, ибо как правило если расходы на тесты настолько велики что надо разделять задачу на этапы, то явно что-то идет не так.
Это что бы здать задачу как можно раньше и таки покрыть ее тестами.
спринт != дэдлайн
Это довольно спорный момент, так как для большинства людей так и есть. И спринт — это дэдлайн. Если вы постоянно не укладываетесь в него — это как постоянно не укладыватся в дэдлайн, очень странно и мало кто будет с вами работать.
Основная идея в том что "у вас никогда не будет универсального процесса а потому не нужно пытаться его выдумывать, лучше взять какой-нибудь из десятков имеющихся и адаптировать под проект". Например берем скрам как самый распространенный фреймворк для построения процессов. Потом берем теорию ограничений, находим в процессе узкие места и чиним их. Если на проекте 50 человек, возможно вместо scrum надо применить fdd или похожие подходы.
Но проблема в том, что там написано совсем другое. Там так и написано, что хренак-хренак и в продашк для нас важнее, чем правильные процессы на проекте. Ну и отдельная благодарность, например, вот этому "сотрудничество с заказчиком важнее согласования условий контракт", из-за которого потом вас заказчик ставит раком, если вы зря ему доверились.
В манифесте вроде как написаны умные штуки, но которые могут работать только в 1 случае из 100 из-за особенностей проекта. Где-то с заказчиком нужно подписывать конкракт вполть до того, что нужно будет указывать, когда и как доступны разработчики, где-то на проекте обратная связь не нужна, потому что она превращается в час нытья ну и так далее и только грамотные процессы спасут все ну и так далее.
Или 4 принципа тоже можно нарушать? Как-то не очень логично.
если заказчик не клал на это все большой болт.
так нахрена продавать ему то что ему не нужно? Просто скажите "мы сделаем это за столько-то времени" и все. У меня есть опыт работы в командах где в среднем все было относительно быстро, то есть дешево с точки зрения dev часов, и в целом относительно эффективно. Вот только когда фича на реализацию которой ушло часов 16 попадает на продакшен через 6 недель после того как клиент озвучил хотелку — это как бы и приводит к безумным срокам и т.д.
Это что бы здать задачу как можно раньше и таки покрыть ее тестами.
попробуйте TDD, не знаю. Вы таск на деплоймент каждой отдельной фичи тоже создаете?
что там написано совсем другое. Там так и написано, что хренак-хренак и в продашк для нас важнее, чем правильные процессы на проекте.
Это сугубо ваша интерпретация, люди всегда хотят видеть то что хотят.
Там написано что "взаимодействие между людьми важнее чем формализованный процесс", то есть если упрощенно, не важно какой у вас сейчас процесс, если он мешает нормально взаимодействовать людям или у вас люди вовлеченные в процесс никак на него не влияют — это проблема и вам надо что-то с этим процессом делать. Это не значит что "процесса быть не должно" — он так и так будет. Просто если вообще ничего не давать как основу то что-то путное будет только в командах с оооочень высоким уровнем личной ответственности, а с этим у многих плохо.
Работающий продукт важнее исчерпывающей документации. Не документации вообще, а именно подход при котором перед разработкой продукта пишется детальная спека. Таких процессов много. Идея тут тоже простая — доку можно и потом написать, а нам важно показать прототип побыстрее и получить фидбэк "правильно ли мы сделали и будет ли это работать для бизнеса".
- Взаимодействие с клиентом важнее переговоров по контракту — тут опять же, идея не в том что бы просто с клиентом взаимодействовать, а что бы делать это эффективно. И под клиентом тут подразумеваются все люди которые заинтересованы в разработке, включая конечных пользователей. Как никак именно их мнение важно. Необходимость этого пункта связана с тем как человеки формулируют требования, и что порой проще быстро показать немного не то что бы узнать чем то что сейчас отличается от того что нужно.
Что до контрактов — обычно берут time and material + variable scope. Если клиент на это пойти не может — знаю удачные примеры где просто контракты были итерационные — по 2 недели. И да, это сложнее продавать людям которые не в теме, им надо объяснять механику. И опять же, если проект довольно простой и требования понятны, то есть разночтений не будет, и работаете вы по fixed price, то водопадная модель не так плоха.
- Быстрая реакция на изменения важнее следования фиксированному плану — в бизнесе это называется управление рисками. То есть смотрите, допустим у вас есть бизнес и есть какие-то риски. Порой нивелировать риски слишком дорого, и потому упор надо делать на снижение стоимости неудачи. И в этом основная идея. Упрощенно — может быть ошибка на этапе интерпретации требований, и вместо того чтобы больше думать над требованиями часто проще максимально быстро (в течении пары дней) показать то как мы интерпретируем, это намного дешевле потенциальной ошибки которая вылавливается через месяц например.
Или 4 принципа тоже можно нарушать? Как-то не очень логично.
еще раз. Там стоит слово "важнее", то есть вы должны выстраивать то что слева с позиции того что справа. Все это очень сильно зависит от проекта, от клиента, от команды. Нарушить эти принципы невозможно потому что речь идет о балансе. Вы просто будете либо ближе к одной точке либо к другой. Но до крайностей вы врядли дойдете.
Там написано что "взаимодействие между людьми важнее чем формализованный процесс", то есть если упрощенно, не важно какой у вас сейчас процесс, если он мешает нормально взаимодействовать людям или у вас люди вовлеченные в процесс никак на него не влияют — это проблема и вам надо что-то с этим процессом делать. Это не значит что "процесса быть не должно" — он так и так будет. Просто если вообще ничего не давать как основу то что-то путное будет только в командах с оооочень высоким уровнем личной ответственности, а с этим у многих плохо.
Проблема в том, что процесс всегда будет мешать. Он будет мешать новичкам, которые привыкли к тому процессу, который был у них раньше, он будет ставить палки в колеса, когда нужно делать "хренак-хренак". И в этих случаях нужно, что бы процесс стоял стеной, а не прогинался.
Идея тут тоже простая — доку можно и потом написать, а нам важно показать прототип побыстрее и получить фидбэк "правильно ли мы сделали и будет ли это работать для бизнеса".
И это отвратительная идея, потому что это "потом" наступает очень не скоро. Обычно когда без доки все совсем плохо.
еще раз. Там стоит слово "важнее", то есть вы должны выстраивать то что слева с позиции того что справа. Все это очень сильно зависит от проекта, от клиента, от команды. Нарушить эти принципы невозможно потому что речь идет о балансе. Вы просто будете либо ближе к одной точке либо к другой. Но до крайностей вы врядли дойдете.
Какой баланс? Там прямо так и написано, важнее. Ни о каком балансе там речи и не идет, вы начинаете уже по своему интерпретировать. Я же говорю, что в некоторых случаях как раз наоборот, и жесткая формализация важнее, чем люди. И это нормально, и так и должно быть.
Проблема в том, что процесс всегда будет мешать.
если процесс мешает — меняйте процесс. Вот и вся идея. Вот только...
Он будет мешать новичкам, которые привыкли к тому процессу, который был у них раньше
Это не "процесс мешает", это просто накладные расходы на введение новых людей в команду. Я недавно вводил нового разработчика в проект, для него не только процесс новый, но и фреймворк например. В итоге просто посадил на неделю делать маленький проектик да разбираться с фреймворком, 2 сессии парного программирования на 2 часа и в целом он уже готов работать с фреймворком. Что до процессов — 1 час объяснений что к чему + ссылочка на небольшой док с гайдлайнами. Дальше просто по мере возникновения вопросов и т.д. решается все.
он будет ставить палки в колеса, когда нужно делать "хренак-хренак"
Вот когда вы мне предоставите значение которое вы вкладываете в "хренак-хренак" тогда и поговорим. Если вы про "сделать абы работало и плевать как оно работает" — то нет. Так просто не надо делать. Другой вопрос что мы можем чуть-чуть пожертвовать качеством в угоду скорости деливери, но это вот вообще не хренак-хренак.
И это отвратительная идея, потому что это "потом" наступает очень не скоро.
ну так запланируйте сразу как только доделаете то что требует документирования. Это не сильно долго и не сильно сложно.
К примеру приведу чуть-чуть другой пример. Допустим мы делаем простенькую web-приложеньку, и там есть некая табличка отображающая какую-то статистику. Тут приходит стэкхолдер и говорит что мол "все зашибись, но нам очень не хватает колонки с такими-то процентами". И у нас есть дизайн, который так же как и документация, всегда должен быть актуальным. И у вас есть выбор порадовать клиента тем что уже через час на проде будет новая колонка, или же ждать пока придет дизайнер, актуализирует оный, создадут таск на девелопера и все такое прочее. То есть вместо часа например рабочий день.
И ладно колонка, допустим нас попросили 10 лэйблочек в разных местах поправить. Как быть? Может быть проще будет все же сделать и выкатить и сразу сделать таск на дизайнера чтобы тот свой дизайн актуализировал? Так же и с документацией.
А если вам не разрешают так делать и т.д. не вопрос, просто дождитесь факапов на этой почве и посчитайте сколько это бизнесу обошлось и во сколько бы обошлось делать нормально. Только так что-то можно поменять.
Там прямо так и написано, важнее. Ни о каком балансе там речи и не идет,
С каких пор слово "важнее" в русском языке приобрело смысл "вместо"? Что до "моей интерпретации" — да, это моя интерпретация. Она подтверждается десятками книг, докладов тех же дядек которые этот манифест составляли и личным опытом. Если вы не согласны — дело ваше, я лишь хочу что бы вы чуть более критически мыслили, не столь категорично.
Я же говорю, что в некоторых случаях как раз наоборот, и жесткая формализация важнее, чем люди.
Если люди не обладают достаточным уровнем личной ответственности и самоорганизацией — да, вполне себе вариант. Но это опять же крайности. А истина она где-то посередине.
Вот тут даже написано:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Но сильно не хватает сносок в духе (но какая-то документация и процессы все равно очень нужны).
Опять же распространенная ошибка интерпретации. "важнее" != "не нужны". "исчерпывающей документации" != "любой документации".
То есть идея в том что нет смысла писать полную документацию по проекту если есть шанс что проекта не будет или наши представления о проекте могут поменяться. Это банально здравый смысл. Но просто документация, не исчерпывающая, вполне себе нужна всегда.
не хватает сносок в духе
она же есть.
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.
А помимо тех 6-ти строчек манифеста, принципы вы читали? http://agilemanifesto.org/principles.html
А помимо тех 6-ти строчек манифеста, принципы вы читали? http://agilemanifesto.org/principles.html
Да, и я даже оттуда цитаты вытягиваю.
Опять же распространенная ошибка интерпретации. "важнее" != "не нужны". "исчерпывающей документации" != "любой документации".
Добро пожаловать в компании, где у вас выбор или/или )
То есть идея в том что нет смысла писать полную документацию по проекту если есть шанс что проекта не будет или наши представления о проекте могут поменяться. Это банально здравый смысл. Но просто документация, не исчерпывающая, вполне себе нужна всегда.
Но ведь работающий продукт важнее? Если у вас будет выбор между этими двумя пунктами (документацией и продуктом), то выбирается продукт. К чему это приводит, думаю понятно.
Добро пожаловать в компании, где у вас выбор или/или )
Что бы я делал:
- Попробовал бы поговорить с менеджментом
- Тренинги которые показывают проблемы в очень короткий срок (минут 15-30)
- если это все не помогло — увольняться, потому что либо там простые проекты которые можно делать, либо заведомо мертвые продукты делать будем. Мне такое не интересно.
Но ведь работающий продукт важнее?
Важнее "всеобъемлющей" документации а не "любой" документации. Например у нас есть команда из 50ти человек. В команде можно выделить отделы, или же дробить по функционалу. В итоге у нас должен быть документ регламентирующий правила разделения. На написание и поддержание оного уходит не много времени, и он быстро окупается. А полная спецификация по проекту до разработки несет в себе слишком много рисков. Хотя важные моменты можно и закрепить. Или более тесно интегрировать процесс документирования в процесс разработки (BDD).
Если у вас будет выбор между этими двумя пунктами (документацией и продуктом), то выбирается продукт.
еще раз — речь идет не между выбором из двух пунктов, а нахождением той точки между "нет документации" и "документация самое важное" при котором вы получаете от документации больше профита чем расходов на ее поддержание.
В целом авторы agile манифеста не раз говорили что хреновая была идея публиковать это без детальных пояснений. Можете глянуть доклад Дэйва Томаса Agile is dead.
еще раз — речь идет не между выбором из двух пунктов, а нахождением той точки между "нет документации" и "документация самое важное" при котором вы получаете от документации больше профита чем расходов на ее поддержание.
Например у нас есть команда из 50ти человек.
Из 7. И поэтому по факту стоит выбор между докой и фичами. Вот и выбираются фичи.
Но только если мы полностью откажемся от док, то спустя какое-то время, это выльется в то что количество "фич" которое мы сможем производить сильно упадет. И это не рокет саенс. Какой-то минимум документации все равно необходим. Другой вопрос как это делать эффективно, что бы документации было ровно столько сколько нужно. А для этого должна быть поставлена четкая задача стоящая перед документацией.
Я сталкивался с людьми которые кричали "нужны доки" и просто описывали все подряд. В итоге эти доки никто не читает потому что там уж слишком много ненужной информации. И с такими доками как правило случается то, что они уже через месяц теряют актуальность.
Даже вот такой вопрос:
У вас есть заказчик, который хочет что-то близкое в хренак-хренак и в продакш, то есть за максимально зжатые сроки получать фичи и не пачкой, а типо по готовности.
И денег он вам готов платить только за хренак-хренак и продакш, тестировщика только на 0.5 ставки, 0.2 менеджера и остальные программисты.
Agile в этом случае спокойно превращается в "хренак-хренак и продакш", нормально ли это?
Ну и что бы это не получилось канбаном, заказчик хочет еще перекидывать задачи из беклога в любой момент, у него 80% URGENT, MAKE IT NOW OR DIE и он даже не хочет слышать что у вас там какие-то ограничения, спринт закрыт или в колонку больше нельзя добавить ничего.
Agile в этом случае спокойно превращается в "хренак-хренак и продакш", нормально ли это?
это не agile, это хренак хренак в продакшен. А вот если вашу постановк задачи почистить:
У вас есть заказчик, который хочет
за максимально зжатые сроки получать фичи и не пачкой, а типо по готовности.
Типичный continuous delivery, распространенная практика, ничего не имеющая общего с "херак херак в продакшен". Требует наличия автоматической верификации (решает проблему того что у вас QA только на пол ставки), 0.2 менеджера можно вообще убрать, либо расскажите зачем он вам на этом проекте.
В херак херак в продакшен это превращают команды которые не умеют так работать.
Ну и что бы это не получилось канбаном
вы неверно трактуете канбан. Канбан построен на теории ограничений, то есть у вас всегда есть ограничения по ресурсам, по времени и т.д. и вы при помощи канбана выстраиваете свой процесс так, что бы он максимально эффективно распоряжался ресурсами. Многие же не особо следят за ограничениями и для них канбан это и есть "херак херак в продакшен", хотя это вообще не так работает.
заказчик хочет еще перекидывать задачи из беклога в любой момент
делаем короче спринты, например 3 дня. Даже в условиях когда у заказчика много урджентов, стабилизировать скоуп хотя бы на 3 дня вы вполне себе можете, а что бы снизить вероятность вот этих урджентов их стоит проанализировать (есть же причина по которой надо столько делать вне очереди), и попробовать пофиксить.
Например причина для урджент задач — у нас проблемы с приоритезацией. И чаще всего эта проблема вызвана плохим пониманием проблем бизнеса. То есть когда к вам приходит клиент и говорю "сделайте мне так", не надо сразу кидаться и делать. Следует понять какую проблему эта хотелка решает для бизнеса. Я попадал в ситуации когда мы делали все что хочет клиент, тупо и бездумно, а потом оказывалось что у бизнеса есть определенная проблему которую они хотелками хотели закрыть, и если бы мы потратили день на то что бы просто обсудить с клиентом эти вопросы, мы бы вместо реализации 10-ти сложных фич могли бы им просто за день проблему пофиксить.
вы неверно трактуете канбан. Канбан построен на теории ограничений, то есть у вас всегда есть ограничения по ресурсам, по времени и т.д. и вы при помощи канбана выстраиваете свой процесс так, что бы он максимально эффективно распоряжался ресурсами. Многие же не особо следят за ограничениями и для них канбан это и есть "херак херак в продакшен", хотя это вообще не так работает.
Я собственно поэтому добавил вот это "он даже не хочет слышать что у вас там какие-то ограничения, спринт закрыт или в колонку больше нельзя добавить ничего.", а то у меня отложилось в голове, что в канбане главное — это лимит на колонки.
В херак херак в продакшен это превращают команды которые не умеют так работать.
Ну, собственно, из-за зависимости от людей. Понятное дело, что любая модель в каком-то случае взлетит.
а то у меня отложилось в голове, что в канбане главное — это лимит на колонки.
из этого следует чуть больше.
лимитов должно быть столько, сколько физически могут выполнять люди в одно и то же время. Например у нас на проекте 4 разработчика и 1 QA. И все все они делают в данный момент — in progress. Так как наблюдается небольшой перевес в сторону разработчиков, разрешим QA выполнять больше одной задачи за раз, например 3. Все цифры с потолка, когда будет больше инфы можно будет их подправить.
Итого у нас лимит — 7 задач могут быть одновременно в работе. Это значит, что если у QA из-за багов в тестировании висит 3 задачи, которые он не может закрыть, остальные разработчики заблокированы и не могут взять новую. То есть весь процесс просто останавливается.
То есть QA может взять и 4-ю и 5-ую задачу в тестирование, но тогда у двух разработчиков не будет возможности взять задачи. Потому они могут сфокусироваться на том что бы разгрузить QA. Например помогут ему с тестированием, или баги наконец пофиксят. Если ситуация частая — то есть много багов например и часто — возможно стоит посмотреть в сторону автоматизации тестирования.
Или еще пример — есть 4 задачи в бэклоге но ими может заниматься только один человек в команде. Все 4 — с высоким приоритетом, но остальные разработчики вынуждены брать задачи с более низким приоритетом ибо "хз как там чего делать". Если возникают подобные ситуации — можно взять парное программирование из XP и таким образом шарить знания, что бы над задачами уже 2 человека по итогу могли работать а не 1, а потом еще увеличим количество.
Ну то есть канбан — это такой хороший инструмент поиска узких мест процесса. Вы можете взять абсолютно любой процесс к которому привыкли разработчики, наложить сверху ограничения, и за счет них искать почему что-то медленно.
Мне в этом плане очень нравится тренинг кабнан-пицерии. Его прикольно проводить с командой и они по другому обычно начинают думать о этих всех штуках.
Или по поводу водопадной модели. Хотите почитать первоисточник?
https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
документ опубликован в 1970-ом году, и именно там впервые описана классическая картинка с каскадом. А потом 5 страниц почему это работает не очень и что между каждым из этапов надо добавить обратную связь иначе дико увеличиваются риски. 47 лет а воз и ныне там.
Сегодня вместо водопадов мы практикуем скрамы, все еще забывая о циклах обратной связи и без анализа каждого из этапов разработки и анализа его эффективности.
Доверие к командам это прекрасно, но у руководства возникают вопросы, на которые нет ответов. Например: «Когда мы можем открыть новый проект? На что направить маркетинговый бюджет и когда? Сколько заложить в бюджет, чтобы сделать следующую штуку?»
Жызненно. Вполне типичный диалог между бизнесом и эджайл фанбоями:
Б: Ну, так что, когда все готово-то будет?
ЭФ: Ну, вы понимаете, у нас нет такого понятия как «все готово». Мы хотели бы работать по time&material и постоянно улучшать продукт, пока вы нам платите. Предполагается, что вы даже из не совсем готового продукта на некоторой итерации должны извлечь материальную пользу
Б: Эээ, так ведь чтобы начать зарабатывать нам нужно сначала запустить большую маркетинговую кампанию, а для этого нужны конкретные сроки
ЭФ: Нуууу, пусть маркетинг тоже будет эджайл
Б: #$#$#%**&@# ??????
Дык, в этом весь смысл аджайла — гибкость приобретается ценой предсказуемости :)
Хотите предсказуемости — фиксируйте требования и получите более-менее точные сроки.
Хотите гибкости — миритесь с туманными сроками :)
гибкость приобретается ценой предсказуемости :)
Относительно. Вы работали с водопадной моделью? К примеру к нам приходит клиент и говорит "ребят я хочу автоматизировать часть своего бизнеса дабы снизить издержки в долгосрочной перспективе". Сначала мы фиксируем требования и тратим на это месяца 2-3, потом месяца 3-4 разработки + тестирование и багфикс В итоге если вендор и клиент все еще любят друг друга через 9 месяцев появляется проект, который переходит в фазу "внедрение".
Давайте дальше рассуждать на тему "предсказуемости". Вы же делали оценки для бизнеса сколько займет времени реализовать весь требуемый функционал? Типа "так вот эта штука займет столько-то времени а эта штука, мы ее никогда не пилили потому от этого числа до думаю этого числа и на всякий тут умножу на три"… ну то есть это по сути рандом, просто с иллюзией схемы. Точную оценку вы можете дать если уже реализовывали ровно такую же систему. Далее растет погрешность.
Бизнесу же это преподносят как это затребует 9 месяцев разработки, и будет стоить $N. Для бизнеса это означает что он потратит на разработку это $N + еще 9 месяцев бизнес не будет автоматизирован что выльется еще в $M + внедрение и переобучение займет еще сколько-то времени и денег.
Предсказуемо, так? А теперь давайте представим что у бизнеса проблема — он теряет деньги от отсутствия автоматизации этой части бизнеса. То есть теперь вопрос стоит "а будет ли через 9 месяцев смысл от внедрения, вдруг мы уже обанкротиться успеем или просто закроем эту часть бизнеса".
В этом случае что бизнесу дают agile подходы. Мы можем выделить какие-то итерации по 2 недели. Поскольку мы не имеем возможности потратить даже месяц на фиксирование требований, мы будем выкатывать вещи по мере готовности, хоть каждый день, постоянно собирая фидбэк от стэкхолдеров. Это позволит избежать ситуации при которой 2 недели разработки были по неверно интерпритированным требованиям. Не говоря о том что мы могли применить всякие там BDD для того что бы еще уменьшить цикл обратной связи.
С точки зрения предсказуемости, клиент знает что за 2-3 месяца наш бизнес не схлопнется. Его не интересует 100% автоматизация бизнеса на данный момент, если через 2 месяца разработки мы уже сможем внедрить систему которая позволит нам автоматизировать 50% бизнеса, это уже даст возможность сократить издержки и выделить средства для продолжения разработки. Так мы можем постоянно уменьшать издержки и перенаправлять средства с целью повышения эффективности. И т.д.
Что до "туманных сроков". Представьте себе что к вам пришел клиент который даже не знает что ему нужно. Есть только идея и примерное представление о проблемах пользователей которые надо решить. Еще веселее — клиент не является представителем таргет аудитории а потому он не сможет никогда оценить эффективность решения. О какой предсказуемости мы тут можем говорить?
Когда то не было такой штуки. Но польза и отдача осознаются просто мгновенно.
Когда пытаются внедрить нечто, что вроде бы должно работать и помочь, но при этом требует коучей, палок, обучений и все равно, почему то не работает как надо, это означает, что скорее всего это нечто не очень правильное и не очень нужное. Потому, что без этого, оказывается работается лучше.
И как оно у вас работает? Я видел случаи, когда система контроля версий вроде как взлетела, а вроде как и нет. И из-за того, что никто не учил ей пользоватся, более опытные пользователи такой системы выгребают за остальных. Кто-то наломал дров, кого-то нельзя отучить нажимать "одну кнопочку", кто-то привык ручками вносить правки на сервере и игнорирует систему контроля версий.
Более того, внедрить vcs это одна задача, а внедрить правильный flow ее использования абсолютно другая, и тоже довольно сложная. Вот есть правильный flow, а вот есть желания заказчика, которые ему не сооствествуют и нужно или его прогнуть, или страдать.
Любое внедрение какой-то полезной штуки будет идти через пень-колоду, потому что "непривычно".
А без Agile, сможете.
Правда? По факту практически никто уже не работает через waterfall, все так или иначе работают через agile. Как вы себе в текущем мире представляете разработку проекта, у которого релиз будет только тогда, когда он будет полностью готов? А все что от этого отходит, можно назвать немного Agile.
Проблема в том, что Agile — это по факту buzzword и ничего, кроме набора рекомендаций, которые, внезапно, далеко не всегда и не всегда обязаны к соблюдению, за собой не несет. Поэтому если у вас итеративная разработка, то уже вполне себе и можно назвать Agile.
Почему нет?
Тут, скорее, надо подходить с точки зрения проблем, которые вы хотите решить.
Хотите супер-пупер гибкость — Agile.
Снижение производственных издержек — Lean.
Ну, а если хотите кошерно расписанный план работ и пристальный контроль за процессом — берите водопад и не заморачивайтесь.
Про то, что если фича не правильная и люди будут работать в ее обход — это неправильное утверждение.
Люди работают в обход vcs, что бы фиксить баги прямо на сервере, потому что так быстрее.
Люди отключают тесты, что работать в обход юнит-тестирования.
Люди будут деплоить сами и мерджить не через интерфейс, что бы обойти проверки системы CI, в виде качества кода и прочего.
Проблемы не в процессах, проблемы в людях.
Agile не здоров по другой причине. В основном потому, что это не процесс, а просто набор советов.
Дело не в скорости.
Вот у вас баг на проде. И что бы его поправить у вас есть два варианта: или соблюсти долгий протокол, или же быстро все поправить. И если заказчику не получится объяснить, что нарушил протокол один раз, будешь нарушать и дальше, то все.
Вполне вероятна ситуация, когда польза от процессов видна только в том случае, если они команду обратно вытащили из какой-то попы. И когда они уже вытащили, кажется, что дальше они не нужны, хотя именно их отстутствие завело команду в эту попу.
Возможно, я вас не понимаю, но проблема тут в людях.
Вот есть процесс. Он не может быть удобным всегда, он накладывает определенные ограничения, что бы в среднем случае у вас все было хорошо. И когда у вас все хорошо — вы им следуете. А как только происходит какая-то горячка, то процесс в краткосрочной перспективе начинает вам мешать, и из-за недооценки его преимуществ в долгосрочной перспективе люди его отбрасывают.
Причем тут процесс?
И если заказчику не получится объяснить, что нарушил протокол один раз, будешь нарушать и дальше, то все.
если у вас такие проблемы — ваш "протокол" надо менять. Вот и все. А если из-за вашего "протокола" бизнес теряет деньги, то можно и клиента так потерять. Но это не значит что "импровизируем каждый раз", это значит что мы должны постоянно видоизменять процесс так что бы он максимально эффективно выполнял поставленную задачу.
максимально эффективно выполнял поставленную задачу.
В среднем случае же? Или каждый раз под новую задачу будет его видоизменять?
Или каждый раз под новую задачу будет его видоизменять?
мне кажется мы по разному тут слово "задача" интерпритируем. Я не про тикеты в джирках.
То есть мы например собираем команды и выстраиваем процесс. Мы от процесса хотим конкретных характеристик, типа "так нам надо что бы команда могла работать и не отвлекаться". берем спринты, "нам надо паралельно чистить и приводить бэклог в порядок", вводим грумминги обязательные 2 раза в неделю. Ну и т.д. Если у нас слишком часто начали меняться требования — значит надо чуть больше сил на груминги кидать, а когда стабилизируемся с пониманием проблем бизнеса — можно уже меньше.
ну то есть мы постоянно видоизменяем процесс потому что в разные этапы проекта нам могут требоваться чуть-чуть разные характеристики. А еще бывает так что у нас команда мидлов с отсутствием мотивации или недостатком личной ответственности — тут можно чуть больше бюрократии потому что никто не будет своей головой думать.
Что хотелось сказать этой историей, так это то, что каждая организация должна развиваться согласно ее потребностям и производствам! И нужно засовывать такие процессы подальше и поглубже пока компания сама не доросла до этого. А если и доросла, то руководство само сможет понять, что им нужно больше!
И такого рода статьи может и нужны, но во-первых их уйма, во-вторых ничего нового нет.
Если компания смогла дорасти до какого-то предела, то там не индюки сидят и естественно когда руководство видит, что выполнение проектов не может вписаться в те дедлайны, которые установлены, то тогда ищутся манифесты как аджайл.
ПыСы: я не говорю о том, что аджайл-плохо! я говорю о том, что это не должно отторгаться как инородное тело. И должно внедряться сверху, а никак не снизу. Потому что это затрагивает не только разработчиков, но и все процессы компании. Масштаб процессов зачастую недоступен разработчикам.
Да даже дедлайны могут не нарушаться, руководство может просто не видеть проблем, считая, что это норма в разработке. Разработчики могут закладывать в оценки принятые де-факто процессы, например, что задачу, которую можно было сделать за один присест за 8 часов с перекурами, чаями и хабрами, придётся делать условно 20 часов в течение 1,5-2 месяцев, по полчаса в день, из которых 15-20 минут будет тратиться на восстановление контекста. Если разработчик не заявит: "дайте скоуп задач на две недели и не дергайте по маленьким не срочным задачам (критические баг-фиксы — отдельный разговор) и за месяц мы будем закрывать в два раза больше задач", то руководство может долго находиться в заблуждении, что быстро и качественно работают только очень-очень дорогие спецы, а не просто дорогие :)
А я не говорю о том, что команда разработки должна внедрять аджайл или ещё что в явочном порядке. Но практика показывает, что дорасти должна не только компания (читай — вертикаль руководства разработкой), но и команда разработки.
Весь этот ваш [fr]agile ненужен. Управлять людьми по книжке нельзя.
так вся суть "agile" как раз таки в том что по книжке нельзя) А то что хорошую идею как всегда превратили в невесть что потому что ее так легко трактовать как захочешь — это уже совсем другая проблема. Посмотрите что с ООП произошло. Просто неудачное название, парочка стечений обстоятельств и вот мы имеем что имеем.
немного истории. где-то в 90-х были разные ребята которые практиковали свои идеи. XP, Crystal Clear, ASD и много других прикольных штук. По всем этим штукам были вполне конкретные книжки так как это были более чем конкретные идеи.
Вобщем вся эта толпа взяла и решила встретиться да обсудить общие для всего этого идеи, результатом стал agile манифест который был составлен и заброшен.
лет через 5 когда подходы эти стали набирать популярность и у некоторых это взлетело, пошел хайп, бесконечные тренинги, сертификация, и прочие штуки на котором можно стричь нехило так денег. Так происходит практически с любой неплохой идеей. Особенно хорошо зарабатывали дядьки которые решили отождествлять agile со скрамом. Если что — скрам лет на 15 старше аджайл манифестов всяких.
По этой же причине сейчас чаще можно слышать lean processes нежели agile processes, потому что последнее утратило свое значение а lean еще хоть как-то похоже на то что надо. Это как SOA и микросервисы, если хотите. Последнее — то что изначально подразумевалось под SOA но размылось со временем.
Если хотите чего-нибудь почитать — http://wiki.c2.com/?AgileProcesses — тут неплохо.
В дополнение дам видео где некоторые из авторов манифеста рассказывают как это все происходило:
Почему руководство не принимает agile и что вы можете с этим сделать