Комментарии 90
В течение спринта можно менять ТЗ? :)
Можно!
Но изменения переносятся на следующие спринты. <:o)
Но изменения переносятся на следующие спринты. <:o)
НЛО прилетело и опубликовало эту надпись здесь
Либо закладывать в спринте время для решения незапланированных задач. Например срочная починка багов на проде или прочая текучка, которая может вылезти в спринте. Примерно через 3-4 спринта (у нас были короткие по неделе) уже известно на что и сколько в уходит времени. ИМХО не на всех производствах ПО agile будет эффективен. Так же не везде его реально внедрить по «политическим» мотивам.
НЛО прилетело и опубликовало эту надпись здесь
есть даже более сложный вопрос: а где была описана и реально применялась «каскадная» модель? =) поищите, удивитесь
Может больше не знают ничего?(
RUP — сложна
RUP — сложна
Более того, то, что сейчас называется waterfall (на самом деле автор этой методологии мамой клянется, что имел ввиду итеративность), отнюдь себя не изжило, т.к. реализовать средства защиты информации или спец.софт для авиации, космоса и медицины по аджайлу не получится
НЛО прилетело и опубликовало эту надпись здесь
то, что софт можно обновлять — это не значит, что идет работа по аджайлу. Разница в том, что в водопаде сначала аналитики до мельчайших подробностей прорабатывают требования и фиксируют их, после этого разработчики пишут код, а когда написание кода закончено, то никаких изменений, кроме багфиксов, быть в принципе не может. После этого куа куачат, а девелоперы фиксят и только потом в продакшн.
Здесь нет гибкого скоупа итерации, изменений требований, деплоя каждой рабочей сборки в продакшн и тому подобных практик из аджайла.
Здесь нет гибкого скоупа итерации, изменений требований, деплоя каждой рабочей сборки в продакшн и тому подобных практик из аджайла.
Изучая ООП, с этими всякими наследованиями, могу предположить, что каскадная модель живет до первого изменения базовой структуры (требований) :)
НЛО прилетело и опубликовало эту надпись здесь
Говорю, что каскадная модель не уживается потому, что требования заказчика меняются быстрее чем заканчивается цикл разработки :-)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Agile это даже не подход к разработке, это просто набор принципов и ценностей :)
Действительно, 15 лет назад Agile был набором принципов, однако сегодня он объединяет многие дисциплины производства. Даже такие компании как Zara и Ikea работают по Agile, и речь не идет об их отделе разработки ПО. Прошу прощения за ссылку на английском: http://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/#2d5433b4b926
… написанном десятки лет назад на языках программирования: ..., GO и пр.
Ему еще нет десятка )
Традиционно целью Agile был первый этап разработки – написание кода.
Нонсенс.
Целью Agile никогда не было написание кода, целью Agile является удовлетворение клиента, а для этого, Agile-фреймворки (тот же Scrum) работают над тем, чтобы НЕ разделять те три этапа разработки, про которые пишет автор.
Основой Scrum-a является тот факт, что ВЕСЬ продукт с учетом тестирования, выкладки на продакшн, делает Scrum-команда, в течении спринта. А в команду эту входят ВСЕ необходимые для этого специалисты.
Кроме того, сами авторы Scrum настоятельно рекомендуют использовать техники XP и DevOps для обеспечения быстрой выкладки результатов на прод в надлежащем качестве.
P.S.
Это уже вторая статья от автора и я снова убеждаюсь, что присутствует явное непонимание, что Agile это не только Scrum.
Во-первых, Agile – это всего лишь манифест из ценностей и принципов.
Во-вторых, если говорить про техники под зонтиком Agile, то есть XP, DevOps и другие, которые как раз заточены, под выпуск КАЧЕСТВЕННОГО ПО. Их всего-лишь надо с умом применять. А говорить, что проблема Agile в качестве – как минимум не корректно. Проблема сегодняшнего внедрения Agile во многих компаниях, в том что его внедряют не разобравшись в сути.
Спасибо! Я рад что вы мой постоянный читатель! Речь действительно о «зонтике» Agile, который развернулся намного шире и покрывает не только отделы разработок, а уже всей компании. Проблема именно в том, что результат действительно зависит от того как внедряют Agile. Необходимо новое дополнение к «зонтику», которое будет сопровождать внедрение Agile, и позволит четко определить, что сделано не по правилам и как это исправить. Именно этим и занимаются сегодня разработчики Agile.
Итак, одной из ключевых проблем в работе Agile сегодня является проблема качества. И ее решение – дело уже совсем ближайшего будущего.
В будущем вообще все будет хорошо, но так-то аргумент слабый и даже немного комичный.
НЛО прилетело и опубликовало эту надпись здесь
Количество параллельных веток кода, с которыми одновременно работает один разработчик: починка багов, нынешняя версия, новая версия, версия для определенного заказчика, экспериментальная версия и т.д.
НЛО прилетело и опубликовало эту надпись здесь
Как минимум 1 к 1, и даже иногда, на каждую ветку необходимо 3-4 среды: поверхностные проверки, разные вариации данных, разные вариации поддерживающих сервисных приложений и т.д. Допустим ТЗ добавить оплату картой покупки книги. Необходимо проверить новый код на стабильность, безопасность и функциональность. Таким образом уже три среды на одно ТЗ, каждая со своими инструментами, заточенными на тип проверки.
НЛО прилетело и опубликовало эту надпись здесь
Это то, что происходит обычно:
dev
stage
prod
несколько сред для тестеров, а у разработчиков только одна, да и та хромает.
Это я говорю про то, как работает сегодня.
А вот представьте себе вариант, когда Вы открываете eclipse или другой IDE, и, нажимая на кнопку, получаете новую среду. Ваш новый код туда закачан, есть все данные для тестов, которые QA, Ops и анналисты согласовали и подготовили, более того, даже acceptance тест можете запускать нажатием кнопки и можно подключаться с дебагером.
В таком случае в течении дня у Вас будет как минимум одна “локальная” среда для каждого набора тестовых данных или может даже для каждого теста. Такая имплементация на уровне виртуализации слишком дорогая, а вот контейнеры более подходят для этого.
dev
stage
prod
несколько сред для тестеров, а у разработчиков только одна, да и та хромает.
Это я говорю про то, как работает сегодня.
А вот представьте себе вариант, когда Вы открываете eclipse или другой IDE, и, нажимая на кнопку, получаете новую среду. Ваш новый код туда закачан, есть все данные для тестов, которые QA, Ops и анналисты согласовали и подготовили, более того, даже acceptance тест можете запускать нажатием кнопки и можно подключаться с дебагером.
В таком случае в течении дня у Вас будет как минимум одна “локальная” среда для каждого набора тестовых данных или может даже для каждого теста. Такая имплементация на уровне виртуализации слишком дорогая, а вот контейнеры более подходят для этого.
НЛО прилетело и опубликовало эту надпись здесь
На каждую ветку, с которой работает программист есть как минимум одно изменение. Желательно каждое изменение проверить перед выкладыванием кода в ветку и лучше, конечно, с как можно большим разнообразием тестовых данных. Полагаю, это не только мое мнение. Единственное препятствие для такого подхода — время и усилия, затраченные на поднятие сред, закачку тестовых данных и запуск тестов. Это как раз та область, которая будет развиваться в следующие 5-10 лет под “зонтиком” Agile.
Дополнительно к инструментам типа Docker, Cucumber & Service Virtualization будут появляться новые, цель которых будет ускорить, упростить и удешевить подъем сред, закачку данных и запуск тестов приема.
Дополнительно к инструментам типа Docker, Cucumber & Service Virtualization будут появляться новые, цель которых будет ускорить, упростить и удешевить подъем сред, закачку данных и запуск тестов приема.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Если работает один человек, то можно и на билд сервер загружать. Правда тесты, наверняка, тесты компоненты, а не тесты приема. А вот если 200 человек работает, то билд будет падать раз за разом. Это и есть эффект турбулентности, когда проводная способность билда меньше, чем поток изменений проходящий через него.
Вот статистика с настоящего, не самого перегруженного сервера:
120 модулей в проекте
450 разработчиков
приблизительно 100 изменений в день (как вы видите еще не все работают с одной веткой)
12 билдов в день
в среднем, каждый билд длится 30 минут
в среднем, каждый билд строит 8 новых изменений
обычно 2 билда успешные, первый и последний (в конце дня все работают над стабильностью)
Сегодня, основная сложность — построить среду быстро (меньше минуты) и создать набор правильных тестов, которые проверяют работу бизнес процессов в целом, в дополнение к тестированию отдельных компонент.
Проверка на билд сервере это первый этап так называемого «сдвига влево», т.е. подальше от prod. На сложных проектах этого тоже не достаточно.
Вот статистика с настоящего, не самого перегруженного сервера:
120 модулей в проекте
450 разработчиков
приблизительно 100 изменений в день (как вы видите еще не все работают с одной веткой)
12 билдов в день
в среднем, каждый билд длится 30 минут
в среднем, каждый билд строит 8 новых изменений
обычно 2 билда успешные, первый и последний (в конце дня все работают над стабильностью)
Сегодня, основная сложность — построить среду быстро (меньше минуты) и создать набор правильных тестов, которые проверяют работу бизнес процессов в целом, в дополнение к тестированию отдельных компонент.
Проверка на билд сервере это первый этап так называемого «сдвига влево», т.е. подальше от prod. На сложных проектах этого тоже не достаточно.
----по принципам Agile сейчас работают две трети IT-компаний.
Давайте будем честными, никто из первой десятки, и мало кто из сотни, Agile не использует.
Давайте будем честными, никто из первой десятки, и мало кто из сотни, Agile не использует.
Кто по-вашему «первая десятка» и «первая сотня»?
Не заметил этого утверждения.
Я бы сказал, что те, кто и работает, на самом деле «работает».
Достаточно поискать прошлые топики об Agile, которыми хабр завален, и описанием проблем.
Ощущение, что пытаются впихнуть свой Agile куда только можно.
Я бы сказал, что те, кто и работает, на самом деле «работает».
Достаточно поискать прошлые топики об Agile, которыми хабр завален, и описанием проблем.
Ощущение, что пытаются впихнуть свой Agile куда только можно.
Давайте будем честными и не будем измерять «компаниями». Потому что в рамках одной компании каждый проект сам для себя решает что использовать. Это может быть Скрам, Канбан или обычный водопад. Не видел ни одной компании, которая бы запрещала использовать Agile. (Ведь даже документацию и ТЗ можно писать по Agile). Я очень сильно сомневаюсь, что ни одна команда в Microsoft, Apple или Google не использует Agile методологии.
Парадокс именно в том что в первом десятке находятся корпорации, для которых изменение может обойтись слишком дорого. Пионерами Agile были компании, которые не были включены в лидеры рынка.
Хорошая статья, но мне как-то маловато примеров.
Автор не прав и НЕ рубит фишку. Главная проблема внедрения agile не качество, а недоверие и нежеление людей меняться в целом. Новое любит 10% населения, остальные любят старое и привычное. Проблема качества в agile проектах стоит ничуть не более остро, чем во всех остальных проектах. Автоматизация используется во всех типах проектов и нормально помогает.
Хватит уже поминать agile. У нас уже post-agile тут на острие. Scrum и иже с ними выходят из моды и завоевывают non-software deveopment команды. Сейчас модно говорить о трансформации всей компании, холократия там, плоские структуры, доверие, вот это вот все.
Хватит уже поминать agile. У нас уже post-agile тут на острие. Scrum и иже с ними выходят из моды и завоевывают non-software deveopment команды. Сейчас модно говорить о трансформации всей компании, холократия там, плоские структуры, доверие, вот это вот все.
Статья именно об этом. Agile уже давно перерос из набора принципов для команд разработчиков в собирательное понятие:… Тогда же, в середине первого десятилетия 2000-х, понятие Agile было расширено и стало собирательным, в отличие от первоначального значения, ориентированного только на первый этап разработки.…
Сейчас у меня закончился проект и меря переводят на проект с полноценным Agile. То есть моим начальником становится скрум мастер и product owner, первая недавна работала официонткой, второй тоже какой то управленец-гуманитарий.
То есть они меня будут микроменеджерить и любой технический вопрос надо будет согласовывать с ними. Так по идее не должно быть в аджайле, но так устроена психология человека, если человек- мелкий начальник, то есть он может распределять задания и планировать сприн, он с 99,99% будет лезть в технические вопросы и микроменеджерить. Производительность в аджайле снижается минимум в 5 раз, а работы с выпучинными глазами и огромной усталостью от бесконечных 15 минуток, которые растягиваются минимум на 40 мин, прибавляется в разы.
Предыдущий проект был с Jira и вроде как был спринт, но все, за исключением утренних 15 минуток (на 40 минут), было очень неформально. Смогла переписать большую часть легаси (1998г.) приложения, как франт энд так и бэк энд. Приложение сейчас выглядить конфеткой.
Сейчас начнется аджайл, поэтому главная установка у меня — не напрягаться, главное — быть максимально активным на митингах и отчетах о своих результатах.
Это о рациональном подходе к аджайл с точки зрения опытного разработчика с опытом работы с аджайл на 8 разных проектах.
То есть они меня будут микроменеджерить и любой технический вопрос надо будет согласовывать с ними. Так по идее не должно быть в аджайле, но так устроена психология человека, если человек- мелкий начальник, то есть он может распределять задания и планировать сприн, он с 99,99% будет лезть в технические вопросы и микроменеджерить. Производительность в аджайле снижается минимум в 5 раз, а работы с выпучинными глазами и огромной усталостью от бесконечных 15 минуток, которые растягиваются минимум на 40 мин, прибавляется в разы.
Предыдущий проект был с Jira и вроде как был спринт, но все, за исключением утренних 15 минуток (на 40 минут), было очень неформально. Смогла переписать большую часть легаси (1998г.) приложения, как франт энд так и бэк энд. Приложение сейчас выглядить конфеткой.
Сейчас начнется аджайл, поэтому главная установка у меня — не напрягаться, главное — быть максимально активным на митингах и отчетах о своих результатах.
Это о рациональном подходе к аджайл с точки зрения опытного разработчика с опытом работы с аджайл на 8 разных проектах.
Все намного проще: Итак, одной из ключевых проблем в работе Agile сегодня является проблема качества.
Естественно.
Вся статья про то, что Agile заточен под команды из слабых разрабов, и про то, как при назначении качеству нулевого приоритета, абсолютный приоритет отдается быстрой поспринтовой разработке прототипов, а далее в статье описывается, что — внезапно! — прототипы в продакшене не работают.
И далее описываются попытки доработать методологию, чтобы на выходе выдавался и качественный код, и работающий в продакшене продукт.
Но тогда это что-то другое, а не аджайл в общепринятом и рекламируемом виде.
Представляется, что если придать водопаду человеческое лицо, и доработать аджайл, то они встретятся в одной точке.
ИМХО проблема всех, кто «внедряет» Agile отдать ответственность за качество кода и время проекта в одни руки — программиста.
А это в свою очередь дает программисту полную безответственность.
Т.к. обычно время берется в займы у качества кода.
Потом за это придется платить, но всегда можно «уйти» от ответственности. И платить будет кто-нибудь другой.
Грубо говоря:
Мы тут быстро наговнокодили, т.к. нам спринт закрыть надо. А потом кто-нибудь когда-нибудь наш говнокод, наверное, отрефакторит.
<:o)
А это в свою очередь дает программисту полную безответственность.
Т.к. обычно время берется в займы у качества кода.
Потом за это придется платить, но всегда можно «уйти» от ответственности. И платить будет кто-нибудь другой.
Грубо говоря:
Мы тут быстро наговнокодили, т.к. нам спринт закрыть надо. А потом кто-нибудь когда-нибудь наш говнокод, наверное, отрефакторит.
<:o)
То чувство, когда мысли, хорошо выражаемые через схемы и графики, оформелны в виде стены текста с типовыми фоографиями и превращаются просто в нечитаемую портянку без разбивки…
Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным.
Действительно? :)
Пересели на agile, чтобы увеличить скорость разработки, в ущерб качеству, теперь удивляемся куда делось качество. Ну-ну.
НЛО прилетело и опубликовало эту надпись здесь
Риск во многом зависит от качества, если убрать конечно элемент везения! Я с вами согласен, качество это способ уменьшения риска. А инструменты для предсказания степени удовлетворения — https://cucumber.io и https://www-01.ibm.com/software/rational/servicevirtualization/
НЛО прилетело и опубликовало эту надпись здесь
Именно так!
Как повысить качество? Это и есть следующий этап развития Agile
Правильно построенные тесты в Cucumber позволяют однозначно определить соответствие критериям приема. Ну а последнее позволяет запустить сложную систему до того как все куски кода написаны. Например, в приложении для покупки книг, правило написанный тест позволит проверить, насколько система отвечает требованиям, если книга не найдена а виртуализация сервисных приложений сократит время до проверок и демонстрации — можно будет запускать приложение до того, как база данных готова.
Как повысить качество? Это и есть следующий этап развития Agile
Правильно построенные тесты в Cucumber позволяют однозначно определить соответствие критериям приема. Ну а последнее позволяет запустить сложную систему до того как все куски кода написаны. Например, в приложении для покупки книг, правило написанный тест позволит проверить, насколько система отвечает требованиям, если книга не найдена а виртуализация сервисных приложений сократит время до проверок и демонстрации — можно будет запускать приложение до того, как база данных готова.
Пробовали ли вы когда-нибудь DSDM Atern?
Спасибо за очень хороший вопрос! Естественно, однако я не видел что бы DSDM действительно работал на практике, тем более на больших проектах — он слишком общий. В жизни все значительно сложнее. Например, один из принципов — согласие о критерии сдачи проекта до начала разработки. На практике бизнес не согласится принять что-то, до того как видел как оно работает в деле.
Мы в нашем компании работаем по DSDM, экономим деньги, свои и заказчика.
По факту получается достаточно хорошо использовать условие работы по этому процессу, как воронку для фильтрации «наших» клиентов. Те кто согласны — эволюционным путем двигаться к продукту — остаются с нами, с ними мы и продолжаем успешно работать. И должен признаться dsdm очень хорошо помогает как presale сделать так и дальше спокойным быть account'у.
Относительно вашего point'a относительно критерия сдачи — в DSDM 4 этапа, и заказчик в праве отказаться от продолжения работы на любом из этапов.
Вы работаете по предоплате? Что входит в предоплату? Проектирование?
Если научиться продавать DSDM тогда у вас вероятнее всего не будет fix price на весь проект, у вас будет возможность варьировать бюджет в виду обратной связи бизнеса.
Вопрос качества как правило связан либо с проектированием либо с обработкой Change request'ов… Как вы работаете с change request'aми?
По факту получается достаточно хорошо использовать условие работы по этому процессу, как воронку для фильтрации «наших» клиентов. Те кто согласны — эволюционным путем двигаться к продукту — остаются с нами, с ними мы и продолжаем успешно работать. И должен признаться dsdm очень хорошо помогает как presale сделать так и дальше спокойным быть account'у.
Относительно вашего point'a относительно критерия сдачи — в DSDM 4 этапа, и заказчик в праве отказаться от продолжения работы на любом из этапов.
Вы работаете по предоплате? Что входит в предоплату? Проектирование?
Если научиться продавать DSDM тогда у вас вероятнее всего не будет fix price на весь проект, у вас будет возможность варьировать бюджет в виду обратной связи бизнеса.
Вопрос качества как правило связан либо с проектированием либо с обработкой Change request'ов… Как вы работаете с change request'aми?
Именно так, качество связано с определением критериев сдачи, в данном случае проектированием на начальном этапе или обработкой CR.
Самая распространенная модель работы с CR — через backlog. Недостаток заключается в возможном несоответствии критериев сдачи с имплементацией ТЗ. Этот недостаток должен быть устранен за счет показа результата заказчику. Это не сложно для простых проектов. Однако для более сложных вопрос среды и тестов приема критичен. В идеале все тесты приема работают и заказчик доволен работой после ручных проверок. Это работает, когда CR не очень много или они могут быть проверены одновременно. На деле все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
Самая распространенная модель работы с CR — через backlog. Недостаток заключается в возможном несоответствии критериев сдачи с имплементацией ТЗ. Этот недостаток должен быть устранен за счет показа результата заказчику. Это не сложно для простых проектов. Однако для более сложных вопрос среды и тестов приема критичен. В идеале все тесты приема работают и заказчик доволен работой после ручных проверок. Это работает, когда CR не очень много или они могут быть проверены одновременно. На деле все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
Коллеги, можете посоветовать толковую книгу по Agile? Желательно на русском.
вот бы ещё придумать способ работать с ПО которые и сами не знают что им надо или тех кто генерит идеи и не думает как они повлияют на всё остальное, а то аджайл как-то не особо помогает, а с толковыми ПО почему-то и без аджайла всё отлично работает
Это точно! С толковыми ПО и без аджайла всё отлично работает :-)
Один из способов — дать попользоваться результатом на ранних этапах, задолго до того, как он окончательно готов. Опять же все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
Один из способов — дать попользоваться результатом на ранних этапах, задолго до того, как он окончательно готов. Опять же все упирается в недостаток сред проверок и автоматических тестов, которые проверяют критерии приема. Именно здесь и пригодятся контейнеры, виртуализация сервисов и автоматизация проверок приема.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Agile умер, да здравствует… Agile