Comments 23
Жёсткий догматизм и сектантство уже зашкаливает и переходит все границы :/ Уверен, IT-сообщество скоро одумается и выгонит взашей всех этих «консультантов», бездельников-балаболок, тратящих время и мозговые такты миллионов людей.
Если вы не согласны с чем-то, то не могли бы вы аргументировать и развернуть свою точку зрения? Т.к. на текущий момент даже не понятно, не согласны вы с автором, или с теми, с кем автор не согласен.
Вот у меня есть ряд аргументов:
Цель всех этих методологий и работы коучей — увеличить профит в бизнесе, то есть повысить прибыль, оборот, снизить затраты. То есть коуч именно этим должен хвастаться. Но я вот зашел на сайт этого Дмитрия по ссылке — там из цифр только количество клиентов, какой-то процент и циферка из опроса. Полная ерунда. На последнем слайде написано «фокус на бизнес». При этом коуч, между тем, делает фокус на себя — получить бабло и зачитать пару лекций.
Еще меня резанула фраза из текста: «Для ваших команд автотестирование – это хорошо, плохо или непонятно? Не бывает команды, для которой это может быть плохо.» На самом деле бывает, тот же геймдев, например. Я, собственно, потому и зашел на его сайт — посмотреть опыт работы товарища, но увы, там его нет. Получается сферический коуч в вакууме.
И еще фидбек о работе не этого чувака, а конторы скрамтрек, что была в предыдущей статье. Так получилось, что они были в двух крупных компаниях, в которых я работал. Так вот, после их работы изменилось ровно ничего, что в одной компании, что в другой. Пару недель развешивали бумажки на стенах, потом забили.
Цель всех этих методологий и работы коучей — увеличить профит в бизнесе, то есть повысить прибыль, оборот, снизить затраты. То есть коуч именно этим должен хвастаться. Но я вот зашел на сайт этого Дмитрия по ссылке — там из цифр только количество клиентов, какой-то процент и циферка из опроса. Полная ерунда. На последнем слайде написано «фокус на бизнес». При этом коуч, между тем, делает фокус на себя — получить бабло и зачитать пару лекций.
Еще меня резанула фраза из текста: «Для ваших команд автотестирование – это хорошо, плохо или непонятно? Не бывает команды, для которой это может быть плохо.» На самом деле бывает, тот же геймдев, например. Я, собственно, потому и зашел на его сайт — посмотреть опыт работы товарища, но увы, там его нет. Получается сферический коуч в вакууме.
И еще фидбек о работе не этого чувака, а конторы скрамтрек, что была в предыдущей статье. Так получилось, что они были в двух крупных компаниях, в которых я работал. Так вот, после их работы изменилось ровно ничего, что в одной компании, что в другой. Пару недель развешивали бумажки на стенах, потом забили.
Да никогда не выгонит их никто. Вы может и сопротивляетесь внутри себя, но ведь любому начальнику ясно как божий день, что без этого ничего работать не будет =D, а следующее за нами поколение будет это воспринимать как что-то само собой разумеющееся, а позже все эти бездельники будут превозноситься всеми до небес, ведь они же имеют денег, а следовательно очень дофига умные, не то что какой-то там инженеришка — быдло в шортах.
UFO just landed and posted this here
А на самом деле водопад выглядел вот так вот (это оригинальная pdf, ее можно в Google скачать):
https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Для тех, кому лень искать
Герман Греф про Agile:
смотреть
смотреть
Я думаю, что практика работы с заказчиком по сбору требований не является специфической для agile и так же применима к waterfall. Это частное замечание.
А более общее. Проблема waterfall, на мой взгляд, вовсе не в методологии, а в изменении внешних условий.
Первое, и самое главное — резкое падение уровня технической подготовки IT аналитиков и менеджмента.
Если раньше, в 70-х, у менеджеров проектов и аналитиков IT компаний, обычно имелся инженерный, математический и т.п. диплом, то с какого-то времени этих специалистов начали готовить сразу, минуя инженерную ступень. Соответственно, они просто не в состоянии формализовать задачу на языке, понятном инженеру.
Частый пример из личного опыта, когда ПМ или аналитик на первом митинге с ходу заявляет: I'm not a technical person. Хочется сразу спросить, я что ты вообще делаешь тогда в IT компании? Иди вон в бургерную менеджери. Хотя, наверное, и там менеджер должен разбираться в качестве ингредиентов и уровне прожарки мяса. Но в IT это стало нормой в какой-то момент.
В результате, что-бы понять хоть что-то из требований, программистам пришлось начать разговаривать с заказчиком напрямую. А поскольку общего языка у них нет, то разговор ведется «на пальцах»: программисты что-то показывают, заказчик кивает или качает головой. Двигаться маленькими шажками. Капитан Кук и людоеды. Это и есть agile.
Это работает и все замечательно, аналитики стали не нужны. Ровно до тех пор, пока ваша предметная область тривиальна и легко описывается в общепонятных терминах. Т.е. пока Кук объясняет людоедам, что за вот эти вот бусы, он хотел бы получить вот тот вот остров и принцип мены понятен всем.
Но вот Куку понадобилось объяснить людоедам какой нибудь бином Ньютона. И что?
В переводе на современную ситуацию: это все очень замечательно, что вы нарисовали интернет банк как хотел заказчик. Сейчас и дети умеют работать с сайтами и перетаскивать что-то там мышкой и вполне могут понять и освоить сайт банка, и объяснить что им нравится, что нет. Но все это по сути лишь интерфейс.
Другое дело — внутренняя логика банковской системы. Для того чтобы понять внутренние процессы, желательно иметь профильное финансовое образование. И программисту со стороны так просто туда не сунуться — он не понимает даже терминологию. А когда дойдет до математики, у него волосы встанут дыбом от того, как финансисты издеваются над классической вышкой, к которой он привык. Там где у него ряды, выводы и пределы — у финансистов будет арифметика и магические константы. Вот тут и случаются грабли.
И в результате, мы на практике увидим, что в ядре системы у банка стоит какой нибудь мэйнфрейм который собственно и выполняет всю тяжелую логику. И написано там все на кобол или рпг в те времена, когда об agile еще не слыхивали.
Желание перенести все это на новую платформу перманентно присутствует. Но попытки часто оканчиваются печально. С наскоку, без грамотного изучения, понимания, формализации и документирования требований, многократной выверки оных, ДО начала всякого кодирования, вряд ли возможно.
Вот и стоят динозавры в банках, пыхтят и обсчитывают всякие опердни.
Так что, не в методологии дело. Дело все в людях. И не надо так уж нападать на waterfall. В ряде случаев без него не куда.
А более общее. Проблема waterfall, на мой взгляд, вовсе не в методологии, а в изменении внешних условий.
Первое, и самое главное — резкое падение уровня технической подготовки IT аналитиков и менеджмента.
Если раньше, в 70-х, у менеджеров проектов и аналитиков IT компаний, обычно имелся инженерный, математический и т.п. диплом, то с какого-то времени этих специалистов начали готовить сразу, минуя инженерную ступень. Соответственно, они просто не в состоянии формализовать задачу на языке, понятном инженеру.
Частый пример из личного опыта, когда ПМ или аналитик на первом митинге с ходу заявляет: I'm not a technical person. Хочется сразу спросить, я что ты вообще делаешь тогда в IT компании? Иди вон в бургерную менеджери. Хотя, наверное, и там менеджер должен разбираться в качестве ингредиентов и уровне прожарки мяса. Но в IT это стало нормой в какой-то момент.
В результате, что-бы понять хоть что-то из требований, программистам пришлось начать разговаривать с заказчиком напрямую. А поскольку общего языка у них нет, то разговор ведется «на пальцах»: программисты что-то показывают, заказчик кивает или качает головой. Двигаться маленькими шажками. Капитан Кук и людоеды. Это и есть agile.
Это работает и все замечательно, аналитики стали не нужны. Ровно до тех пор, пока ваша предметная область тривиальна и легко описывается в общепонятных терминах. Т.е. пока Кук объясняет людоедам, что за вот эти вот бусы, он хотел бы получить вот тот вот остров и принцип мены понятен всем.
Но вот Куку понадобилось объяснить людоедам какой нибудь бином Ньютона. И что?
В переводе на современную ситуацию: это все очень замечательно, что вы нарисовали интернет банк как хотел заказчик. Сейчас и дети умеют работать с сайтами и перетаскивать что-то там мышкой и вполне могут понять и освоить сайт банка, и объяснить что им нравится, что нет. Но все это по сути лишь интерфейс.
Другое дело — внутренняя логика банковской системы. Для того чтобы понять внутренние процессы, желательно иметь профильное финансовое образование. И программисту со стороны так просто туда не сунуться — он не понимает даже терминологию. А когда дойдет до математики, у него волосы встанут дыбом от того, как финансисты издеваются над классической вышкой, к которой он привык. Там где у него ряды, выводы и пределы — у финансистов будет арифметика и магические константы. Вот тут и случаются грабли.
И в результате, мы на практике увидим, что в ядре системы у банка стоит какой нибудь мэйнфрейм который собственно и выполняет всю тяжелую логику. И написано там все на кобол или рпг в те времена, когда об agile еще не слыхивали.
Желание перенести все это на новую платформу перманентно присутствует. Но попытки часто оканчиваются печально. С наскоку, без грамотного изучения, понимания, формализации и документирования требований, многократной выверки оных, ДО начала всякого кодирования, вряд ли возможно.
Вот и стоят динозавры в банках, пыхтят и обсчитывают всякие опердни.
Так что, не в методологии дело. Дело все в людях. И не надо так уж нападать на waterfall. В ряде случаев без него не куда.
Очень полезный взгляд, спасибо Дмитрий!
Единственное что хотелось бы добавить, частенько докапывание до реальной проблемы заказчика приводит к тому, что вы ему ничем не можете помочь, т.к. решение лежит в другой плоскости. Был у меня личный пример, хотели ребята инструмент по генерации некоторых специфических документов, примерно бюджет был опеределен, решение в общих чертах все представляли. Начали копать, общаться с сотрудниками заказчика. Пришли к тому что решение их проблемы делается в их же корпоративной 1С за пару дней их же внутренним разработчиком. Этот разработчик сделал своим боссам удивленное лицо, мол «что ж вы ко мне сразу не пошли», а каких-то непонятных чуваков со стороны притащили. Ну посмеялись, поблагодарили, но денег не заработали нисколько. «Ну спасибо вам за экспертизу, если что вдруг, сразу к вам конечно, ага, всего доброго ...»
Единственное что хотелось бы добавить, частенько докапывание до реальной проблемы заказчика приводит к тому, что вы ему ничем не можете помочь, т.к. решение лежит в другой плоскости. Был у меня личный пример, хотели ребята инструмент по генерации некоторых специфических документов, примерно бюджет был опеределен, решение в общих чертах все представляли. Начали копать, общаться с сотрудниками заказчика. Пришли к тому что решение их проблемы делается в их же корпоративной 1С за пару дней их же внутренним разработчиком. Этот разработчик сделал своим боссам удивленное лицо, мол «что ж вы ко мне сразу не пошли», а каких-то непонятных чуваков со стороны притащили. Ну посмеялись, поблагодарили, но денег не заработали нисколько. «Ну спасибо вам за экспертизу, если что вдруг, сразу к вам конечно, ага, всего доброго ...»
+1 огромный недостаток предложенного подхода «от реальной проблемы» в среде консультантов формулировался так: «толково, умно. Зря ты это -не продашь и будешь бедный».
Я вот сейчас гадость скажу, но большинство реальных задач в реальном мире не нуждаются в IT-решениях от слова совсем. И то что сейчас пытаются всё решать с помощью этих самых IT -дань моде в изрядной мере. Нет, есть задачи, где IT объективно имеют значительные преимущества по своему эффекту. Но не всегда.
На самом деле (sic!) вам не платят за решение проблем! Или надо включать стоимость исследований и business-консультаций в стоимость работ. И объяснять до подписания договора, что мы беремся за решение проблемы, базовая стоимость решения условно 1 дофигилион рублей. Решить можем организационно, а можем через IT. Окончательную цифру скажем после анализа, за анализ предоплату -в кассу. Но в России такая модель продаж нежизнеспособна, увы.
Помните байку про «Удар молотком =1 фунт. За то что знал куда бить =999 фунтов». Это байка, в жизни за это не платят. В лучшем случае платят за то что ты «очень крутой и модный коуч». Или яблокофон. Или любой другой бренд.
Я вот сейчас гадость скажу, но большинство реальных задач в реальном мире не нуждаются в IT-решениях от слова совсем. И то что сейчас пытаются всё решать с помощью этих самых IT -дань моде в изрядной мере. Нет, есть задачи, где IT объективно имеют значительные преимущества по своему эффекту. Но не всегда.
На самом деле (sic!) вам не платят за решение проблем! Или надо включать стоимость исследований и business-консультаций в стоимость работ. И объяснять до подписания договора, что мы беремся за решение проблемы, базовая стоимость решения условно 1 дофигилион рублей. Решить можем организационно, а можем через IT. Окончательную цифру скажем после анализа, за анализ предоплату -в кассу. Но в России такая модель продаж нежизнеспособна, увы.
Помните байку про «Удар молотком =1 фунт. За то что знал куда бить =999 фунтов». Это байка, в жизни за это не платят. В лучшем случае платят за то что ты «очень крутой и модный коуч». Или яблокофон. Или любой другой бренд.
По поводу выяснения потребностей полностью согласен. Ко мне постоянно приходят менеджеры и задают один и тот же вопрос «Сколько стоит это сделать?», на что я задаю встречный вопрос «Зачем это заказчику?». Они уходят спрашивать, выяснять. Таким простым вопросом удалось повысить качество аналитики задач перед тем, как они пойдут в разработку.
Легко сказать «дать заказчику то, что ему нужно, а не то, что он хочет».
Вот нанял ты бригаду для ремонта квартиры, например. Расписал им, что где сделать, как что провести и т.п. Приходишь, а сделали они по другому. Возможно так раз по принципу — то что мне нужно. И позже на практике я и пойму, что да действительно так удобнее и лучше. Но на момент приемки я этим «что ему нужно» буду как бы не очень доволен.
И получается вроде и дали заказчику то, что ему нужно, и заказчик нами не доволен.
Вот нанял ты бригаду для ремонта квартиры, например. Расписал им, что где сделать, как что провести и т.п. Приходишь, а сделали они по другому. Возможно так раз по принципу — то что мне нужно. И позже на практике я и пойму, что да действительно так удобнее и лучше. Но на момент приемки я этим «что ему нужно» буду как бы не очень доволен.
И получается вроде и дали заказчику то, что ему нужно, и заказчик нами не доволен.
При каждом появлении статьи про Agile в вакууме на хабре, у меня всплывают следующие мысли — «зачем тут это, ведь есть же geektimes? Эти темы реально востребованы и интересны?». У меня у одного такие мысли?
А чем отличаются по тематике GeekTimes и Хабр?
У меня почему то сложилось мнение, что geektimes сделали для того, чтобы вынести туда материалы, в которых нет хардкорной инженерной составляющей (быть может в этом и проблема). Ибо со временем «размазалась» аудитория хабра, и скажем так, изначальные контент стал искажаться — что не понравилось старожилам. Это как читателем журнала «Наука ...» подсунуть журнал «Новости на НТВ», но под тем же названием.
Сейчас, почему то, тематика продолжает размазываться, не смотря на то, что статьи вида «Как купить новый айфон задешево..» переехали на geektimes. Все равно все пытаются слать не технические статьи на хабр (
Начиная читать статью на хабре, я всегда ожидаю увидеть «хабра торт», который можно долго осмысливать, в котором все высказывания имеют доказательную базу и выводы, в котором все сдобрено инженерной мыслью, а не домыслами и попытками построить причинно следственные связи…
Сейчас, почему то, тематика продолжает размазываться, не смотря на то, что статьи вида «Как купить новый айфон задешево..» переехали на geektimes. Все равно все пытаются слать не технические статьи на хабр (
Начиная читать статью на хабре, я всегда ожидаю увидеть «хабра торт», который можно долго осмысливать, в котором все высказывания имеют доказательную базу и выводы, в котором все сдобрено инженерной мыслью, а не домыслами и попытками построить причинно следственные связи…
GT — в ширину, Хабр — вглубину.
Интересно сейчас — в 2018-м — натыкаться на такие комментарии.
Прочитав статья, вспомнил почему-то именно эту картинку.
Спасибо за материал.
Мне нравится как продают аджайл ) Отсуствие менджеров птыаются скомпенсировать введением инструментария процессов.
Ровно также было некоторе время назад с паттернами, когда отсутсвие навыка программирования пытаются скомпансировать паттернами и типовыми решениями.
Сравнение аджаила и водопада — худший из аргументов, но тем не менее его постоянно приводят. В то время водопад мог работать потому, что процесс написания софта был более трудоемким, а интерфейсы и бизнес-логика была сильно беднее, по этому сильно проще узнать все заранее, чем потом переписывать. Сейчас не ТАК, сейчас проще попробовать написать и поиспользовать. Порой заказчик даже сам не знает что ему надо, он может просто озвучить проблему. В этом случае надо просто начать делать.
«И увидели, что на самом деле, по какой-то причине мы делаем неважные задачи. И дальше как нам поступить?» это задача менджера/лида и т.д. это он решает, почему, да потому, что он просто умнее, он умеет слушать команду, он умеет слушать и понимать бизнес и в том числе на нем лежит эта отвественность.
На счет «думать» улыбнуло)) думать надо всегда и везде.
Из опыта заказчику вообще фиолетово на процессы и как оно там варится, ем нужен функционал. С заказчиком тоде надо уметь работать и он бывает не идеальный, сегодня надо, а завтра уже неважно. И демо в аджайле говорит лишь о том, что заказчик должен быть просто в курсе как и что делается. Если нет контакта с заказчиком, то нормальной работы не получится.
По поводу RUP — процесс отлично формализует работу, т.е. гранулярно описывает разные активности при разработке софта, его надо просто
понимать, применять не обязательно.
Самую большую команду которую я видел работающую над одним кодом была человек в 6 наверное, ПМ, Оунер, тестер. Это 9 человек.
Если такому количеству человек нужны какие-то процессы со стороны, то надо просто нанять профи.
Ровно также было некоторе время назад с паттернами, когда отсутсвие навыка программирования пытаются скомпансировать паттернами и типовыми решениями.
Сравнение аджаила и водопада — худший из аргументов, но тем не менее его постоянно приводят. В то время водопад мог работать потому, что процесс написания софта был более трудоемким, а интерфейсы и бизнес-логика была сильно беднее, по этому сильно проще узнать все заранее, чем потом переписывать. Сейчас не ТАК, сейчас проще попробовать написать и поиспользовать. Порой заказчик даже сам не знает что ему надо, он может просто озвучить проблему. В этом случае надо просто начать делать.
«И увидели, что на самом деле, по какой-то причине мы делаем неважные задачи. И дальше как нам поступить?» это задача менджера/лида и т.д. это он решает, почему, да потому, что он просто умнее, он умеет слушать команду, он умеет слушать и понимать бизнес и в том числе на нем лежит эта отвественность.
На счет «думать» улыбнуло)) думать надо всегда и везде.
Из опыта заказчику вообще фиолетово на процессы и как оно там варится, ем нужен функционал. С заказчиком тоде надо уметь работать и он бывает не идеальный, сегодня надо, а завтра уже неважно. И демо в аджайле говорит лишь о том, что заказчик должен быть просто в курсе как и что делается. Если нет контакта с заказчиком, то нормальной работы не получится.
По поводу RUP — процесс отлично формализует работу, т.е. гранулярно описывает разные активности при разработке софта, его надо просто
понимать, применять не обязательно.
Самую большую команду которую я видел работающую над одним кодом была человек в 6 наверное, ПМ, Оунер, тестер. Это 9 человек.
Если такому количеству человек нужны какие-то процессы со стороны, то надо просто нанять профи.
Интересно было бы увидеть цифры. Типа: было 2 часа, стало 5 минут. Было 5 чел, стало 10. Было 5 руб, стало 2 руб и тд.
Вообще, вот вкратце, содержание статьи:
1. На 21-м году применения equation в Альфе, там задумались об автоматизации тестирования.
2. Тестеры открыли для себя HACL
3. Тестеры открыли для себя jt400
4. Тестеры написали скрипты, но по ряду причин, им не понравилось. Прежде всего им не понравилась реализация HACL на С++ для win из пакета pcom
5. Тестеры открыли для себя, что есть нативная реализация HACL на java.
6. Счастье наступило.
1. На 21-м году применения equation в Альфе, там задумались об автоматизации тестирования.
2. Тестеры открыли для себя HACL
3. Тестеры открыли для себя jt400
4. Тестеры написали скрипты, но по ряду причин, им не понравилось. Прежде всего им не понравилась реализация HACL на С++ для win из пакета pcom
5. Тестеры открыли для себя, что есть нативная реализация HACL на java.
6. Счастье наступило.
Sign up to leave a comment.
Ключевые навыки успешной Agile-команды или как сделать так, чтобы Agile заработал?