Комментарии 32
Обучение можно и нужно закладывать при планировании. Если этого не происходит, вы работаете не совсем по Agile.
В SAFe, например, каждый пятый спринт рекомендуют полностью посвящать "инновациям и планированию". Обучение явно указано как один из видов деятельности в этот спринт.
Кроме того, для изучения новых областей и технологий, необходимых для проекта, можно заводить задачи типа Spike.
Аджаил только менеджерам нравится обилием умных слов и ничем не подтверждённых концепций. Простому разработчику он только мешает.
Замените в статье внедрение на отказ от аджаил и тот же самый эффект будет
Постоянно читаю, что такое Agile, почему это круто и тп. Все больше похоже просто на рекламу. Но ни как не могу понять в чем цимус Аджайла? Где те самые точки которые делают Agile лидером? При этом есть обратная связь от разработчиков, кто получил удовольствие работать по Аджайлу. Положительных отзывов нет. Наоборот все утверждают, что это выматывающая практика, и что только хорошие деньги какое-то время держат, что бешенная текучка кадров: люди устают и морально выгорают.
Какое-то время назад наш топ менеджемент решил перейти на Аджайл, основные требования: увеличение количество релизов с меньшим объемом изменений, уменьшение времени дотавки изменений клиентам, более быстрая обратная связь от клиентов. Результат: выпуск продукта с фичами которые не нужны ни одному киенту, время на выпуск релиза еще больше (релиз не проходил формальный QA), негативные отзывы заказчиков с проблемами стабильности и качества продукта, и угроза банкротства компании.
Да я понимаю: не так намазывали, но как его намазывать?
ЗЫ. Я не работал по Аджайлу (я так думаю)
ЗЫЫ. Эта статья не дает ответа на мой вопрос :(
в чем цимус Аджайла? Где те самые точки которые делают Agile лидером?
Эта статья не дает ответа на мой вопрос :(
Она и не задумывалась дать его. Речь здесь только об определении.
выматывающая практика, текучка кадров
Это точно не про Agile. Об этом сказано в 8-м принципе Манифеста. И мой критерий номер 1 это подчеркивает.
увеличение количество релизов с меньшим объемом изменений, уменьшение времени дотавки изменений клиентам, более быстрая обратная связь от клиентов
Это про Agile. По сути, мой четвертый критерий.
время на выпуск релиза еще больше
Хотели сделать одно, а получилось другое. Не думаю, что это имеет отношение к Agile. Скорее говорит о том, что не получилось с первого раза.
(релиз не проходил формальный QA)
негативные отзывы заказчиков с проблемами стабильности и качества продукта
выпуск продукта с фичами которые не нужны
Очевидно нарушено требование Agile фокусироваться на ценности для клиента (критерий 3).
Но зато обратная связь работает (критерий 4). Может раньше проблем не было, потому что о них никто не знал (не выполнялся критерий 2)?
Это точно не про Agile. Об этом сказано в 8-м принципе Манифеста. И мой критерий номер 1 это подчеркивает.
Просто в описании работы было написано, что они работают по Agile. Я прекрасно понимаю разницу между заявлением и реальностью. Поэтому и возникают вопросы и конфликты в восприятии: поскольку люди работают таким образом уже несколько лет и заявляют что это Аджайл.
Но зато обратная связь работает (критерий 4). Может раньше проблем не было, потому что о них никто не знал (не выполнялся критерий 2)?
увеличение количество релизов с меньшим объемом изменений, уменьшение времени дотавки изменений клиентам, более быстрая обратная связь от клиентов
Это была основная претензия заказчиков. Очень долгий срок внеения изменений.
Вроде проблем с обратной связью особых не видно, после релиза мы достаточно быстро получаем обратно информацию от клиентов. Причем все запросы логгируются и классифицируются.
Вот вам то, от чего я получал удовлетворение от Скрама в качестве разработчика:
- есть планирование, но горизонт планирования короткий (2 недели по дефолту). На 2 недели вперёд чётко знаешь чем будешь заниматься, а потом только в общих чертах и это хорошо, по сравнению когда задачи на годы вперёд расписаны, а потом никому не нужны или когда плана вообще нет и решают чем тебе заняться когда задачу сделал
- релиз перестает быть событием, или просто планово в общем цикле, или вообще CD
- ежедневные стендапы помогают быть в курсе того, что делает вся команда
- выделяемое время на рефакторинг by design
- возможность влиять на продукт by design
Не нравилось там, где на словах был скрам, а на деле менеджер спускал список задач, часто назначал кто какую делать и т. п.
Один аджайл был очень хорош, но там заслуга менеджера, который сам тянул и как результат всё случалось, вне зависимости от методологии.
Также нравятся короткий горизонт планирования. Нравилась концепция харденинг спринтов. Правильная система управления задачами.
Не нравились стендапы, если команда человек 6-8, то толку почти нету. Либо это вырождается в обсуждение деталей специфичных проблем конкретного человека, либо трешовый, никому не нужный формализм без ценности для участников. Позволяет менеджеру не работать с джирой и иметь иллюзию контроля. Для команды 2-3 человека выглядит как профанация и так все всё знают.
Не нравились ретроспективы, первые пару раз прикольно, потом ощущение дня сурка.
Покеры планирования и нравились и нет. С одной стороны некоторый отдых от рутины, с другой дикая трата времени, хотя полезно для тех кто не очень тянет.
В целом, если ты даже чуть-чуть лучше коллег, то аджайл тебе позволяет показать себя во всей красе (за их счёт).
Но как методология, _лично мне_ видится, что это попытка управления проектами с неудовлетворительным и некомпетентным менеджментом. Ну и психологическая методика, выдоить программистов посуше.
Хоть какой-то план конечно же лучше никакого. Вот только разве это преимущество гибкой методологии? Это недостаток бардака. Или так — если вы не видели хорошего «водопада», это не значит, что их не бывает.
Ну а по сути, на каждый ваш пункт практически можно высказать возражение:
— ежедневные стендапы помогают быть в курсе того, что делает вся команда
Далеко не всегда команде это нужно и интересно. Скажем, тимлиду и так все ясно, без стендапов, если организована работа в jira, и видны коммиты. А QA вовсе не нужно знать, чем вчера занимались аналитики. Итого — это зависит от типа команды и проекта. Иногда общаться раз в неделю в другом формате более чем достаточно.
— выделяемое время на рефакторинг by design
Совершенно не свойство Agile. Не надо присваивать чужие достижения.
— возможность влиять на продукт by design
Я как разработчик, всегда мог приходить к аналитику, который фактически играл роль владельца продукта, и высказать свое мнение. И влиять. Без проблем. Совершенно не свойство Agile.
В общем, все что вы перечисляете — это свойства просто хорошо организованного процесса разработки.
>а на деле менеджер спускал список задач, часто назначал кто какую делать и т. п.
А знаете, бывают команды, где разница в квалификации лида и рядовых членов достаточно велика. И такой способ в этой ситуации гораздо эффективнее, чем коллективное планирование всеми членами команды — потому что планирует самый опытный, и у него это получается лучше. Да, свои недостатки у этого способа тоже есть, но и достоинства вполне очевидны.
не свойство Agile. Не надо присваивать чужие достижения
У Agile нет и не может быть достижений. Он практически ничего не изобрел, да и цели такой не было. Группа (небезызвестных) разработчиков ПО собралась и сформулировала Манифест – свод ценностей, которых они сами придерживаются и считают важными.
Рефакторинг был популяризован в рамках eXtreme Programming (XP) за несколько лет до публикации Манифеста, а изобретен еще раньше. Да и вообще, изобретать тут особо нечего, просто здравый смысл. Тем не менее, это – Agile-практика. Не потому что только Agile сделал её возможной, а потому что она соответствует его ценностям. Весь eXtreme Programming был признан Agile методологией, хотя и существовал намного раньше.
все что вы перечисляете — это свойства просто хорошо организованного процесса разработки
Так и есть. И если Вы согласны с тем, что эти свойства хороши, значит Вы тоже разделяете ценности, описанные в Agile Манифесте. Хоть, возможно, узнали об этих свойствах и без помощи Agile.
В общем, за этим словом на сегодня стоит столько всякой шумихи, бездельников и т.п… поэтому я бы предпочел его не слышать, и не употреблять.
Далеко не всегда команде это нужно и интересно
По моим наблюдениям это основная причина провалов (не всегда зафиксированных) внедрения аджайл практик. Кто-то решил внедрить, остальные не против, но им это не интересно, просто пассивно играют свою роль в ритуалах. А может даже просто присутствуют и отвечают на прямые простые вопросы., не более.
Вариант 1. Работали несколько лет, маленькая команда из трех человек, выпускали релизы раз в две недели, почти как часы, в контакте с потребителем. Потом аналитик проекта решила что перспектив дальше не видно, и ушла в другое место. На проект наняли двух новых людей, для которых у меня и эпитетов не найдется приличных. Они практически на первой же встрече заявили — а давайте работать по аджайлу. При этом квалификация обоих оказалась весьма так себе, поэтому лажали на каждом шагу. Итог: двое оставшихся программистов, сделавших весь проект почти на 100%, ушли в разные другие места, в эту команду наняли или перевели помогать из других проектов, следующий релиз они всемером сделали примерно через полгода.
Вариант 2. Большой коллектив со сложившимися процессами. Работа над разными проектами, при этом обмен опытом между командами, архитектура, технологии. По команде сверху начинает внедряться Agile. Все команды реструктурируют, разбивают по бизнес направлениям, меняют фактически всю структуру. Нужно, не нужно — все равно все по Agile. Благо, тут все шло более-менее постепенно, поэтому результаты нельзя назвать плачевными. Но недовольство вполне налицо.
В обоих случаях, что характерно, налицо был «дурак с инициативой», который, как известно, хуже обычного.
Вопрос — как вообще в такой ситуации это может быть команде нужно? Зачем это команде нужно? Можно ли вообще внедрять что-либо сверху под такими лозунгами, которые предполагают самоорганизацию, например?
Ну вот первая команда, похоже, и так работала по аджайл, близко к скраму.
А вот насчёт сверху очень хороший вопрос. По команде такие практики внедрять, по-моему, нельзя. Может подтолкнуть к решению типа "вот у нас есть такие-то проблемы, вот есть такие процессы, которые ее решают, как думаете, может попробуем?", и если команда проблемы признает и согласна попробовать, то можно попробовать внедрить. Из под палки аджайл точно не получится, мотивированная команда обязательное условие.
Не-а. Просто самоорганизация. Три человека с половиной всегда могут договориться, и в любой момент сделать с релизом все что угодно — выкинуть ненужное, добавить то, что удалось доделать и проверить… на скрам это не очень похоже, я бы сказал.
>вот у нас есть такие-то проблемы
Во-во. У нас нет никаких проблем, которые можно было бы решать через agile. При централизованном внедрении проводится и такое же обучение, и там инструктор честно говорит — на сегодня мы намеряли некоторое солидное ускорение внедрения (типа 30%), при похожем росте стоимости. Ну т.е. стало быстрее, и дороже, что вполне согласуется с ожиданиями.
Но вот проблема в чем — у конкретного проекта может вообще не быть цели ускорять внедрение. У него есть потребители, и эти потребители не заинтересованы в нововведениях — им скорее нужна стабильность, а не какая-то «гибкость», модность и молодежность. Ну нет в этом месте, у этого бизнеса (части бизнеса) потребности быстро меняться.
Как по мне, то довольно похоже. Мы так же решаем каждые две недели, что готово к релизу, а что пока придержим. Хотя может у них не было планирования того, что в следующий релиз через две недели войдёт, а просто что сделали из списка на полгода вперёд, то и релизим. Но не суть.
Самое большое, скажем так, недоумение я испытал когда на годовой проект с чётким ТЗ, сетевыми графиками и т. п. "под ключ" без особых резервов по времени, решили внедрить скрам. Это был эпик фейл.
Вообще я задумывал эту статью не как рекламу Agile. Не для того, чтобы сказать, что он хорош, а для того чтобы разобраться, что же такое Agile. Пока мы не сошлись в определении, бессмысленно говорить, хорошо это или плохо.
В комментариях вижу недовольство Agile, но о каком Agile вы пишете? О том, который определен в Манифесте, или о том, который описан в моей статье, или о том, каким вы его себе представляете?
Давайте поговорим именно об определении, и как вы его трактуете. Я описал свою трактовку. Опишите вашу.
Но в известной мне реализации из того проекта, в котором я работал, и из многочисленных отзывов на хабре, я видел именно то, чего тут многие опасаются.
В обычном проекте релиз — это событие. Выпустили — можно отпраздновать, расслабиться, разойтись по отпускам или заняться решением накопившихся мелочей. Отдохнув, причесав документацию и разобравшись со всем, что может помешать (чтобы потом не пришёл песец с приветом от Мерфи), приступают к следующему этапу. В аджайле сразу начинается следующий спринт. Поначалу (первые месяцы) это действительно немного ускоряет работу. Аджайл-гуру говорит «я же говорил» и уходит в сиянии славы превращать в свою секту следующий отдел.
Однако нерешённые мелочи перерастают в большие проблемы, люди устают, а начальство, обрадованное первыми месяцами, впадает в бешенство. Вместо нужных (но сложных) фич реализуются в первую очередь рюшечки и кружавчики. За качеством становится некогда следить. Разработчики выматываются. Ответственные работают за десятерых, остальные весь день выдумывают, как объяснить, почему ничего не сделано. Сложные баги не решаются, а сдерживаются системой наспех сколоченных костылей. Когда есть два решения — быстрое и правильное, выбирается всегда быстрое. Начальство забывает про пункт один («люди важнее»), но упирает в пункт два («нахрен документацию, некогда»). В результате из пристойного проекта всё за год превращается в плохо документированную и непонятно как работающую скрамоту.
Вот о таком аджайле я и пишу.
Впрочем, я знаю места, где аджайл-технологии применялись ещё до того, как это стало модно. Редакции еженедельных газет и журналов в эпоху глянца. Производственный цикл — неделя. От результатов предыдущей работы ничего не зависит. Журналист точно знает, с какой скоростью он пишет, и если в какой статье будет что не так, это не повлияет на остальные. Дизайнер и верстальщик в курсе, о чём будет номер, чтобы впихнуть контекстную рекламу в нужные места, а остальное заполнить сиськами и котиками. Люди важнее, документации нет, воля заказчика (рекламодателя или владельца издания) — закон, переписать статью — да пожалуйста! Идеальный аджайл. Но в программировании, где всё взаимосвязано, это не работает.
И ещё. В статье Как объяснить бабушке, что такое аджайл есть хорошая картинка. Назовём её «ожидание».
В «реальности» стрелочка обратной связи разорвана: все запросы от заинтересованных лиц идут в корзину, а разработчикам выдаётся только «vision» от владельца продукта.
Это свойство человека.
Скажем, классная практика «следование шаблонам GoF».
Вполне можно пользовать шаблоны, но неправильно. И результат будет печальным.
А можно ничего не знать про шаблоны, и прийти к успешным шаблонам самостоятельно. И результат будет классным.
Означает ли это, что шаблоны не работают?
Или это конкретный(-ые) человек(-и) берет и в конкретном месте косячит(-ят)?
Что значит быть Agile?