×Закрыть

Обратная сторона методологий и «лучших практик» разработки

С появлением множества технологий и фреймворков, которые упрощают разработчику жизнь, может сложиться впечатление, что сегодня писать программы стало проще, чем вчера. В самом деле, зачем каждый раз использовать велосипед? Используй готовые библиотеки, живи — не тужи. Но радость была бы неполной, если бы вместе с технологиями для упрощения жизни разработчика не появились и новые методологии разработки ПО. Но стало ли легче?

В начале 2000-х привычную некогда парадигму Waterfall стали даже клеймить позором. Если у человека на проекте не было новомодного Agile, то ему, краснея, приходилось выдумывать отговорки в стиле «Мы сейчас как раз на него переходим». В это же время у всех на языках завертелись неслыханные доселе словечки вроде extreme programming, scrum-master, stand-up meeting, backlog, sprint и так далее. В программирование вдохнули новую жизнь! Появились доски из пробки, в которые можно было с удовольствием вдавливать кнопки с разноцветными бумажками и стоять с умным видом, рассуждая о великом. И наконец появился долгожданный блэк-джек в виде Scrum poker. Всё это удобрялось важными графиками, глядя на которые нельзя было не чувствовать себя титаном прогресса.

Тогда наш коуч идёт к вам

Стали появляться книги по разработке ПО, в которых упор делался уже не столько на самом языке, сколько на том, с какой ноги следует встать утром, чтобы вечером вышел удачный коммит. Одна за другой начали выходить статьи о лучших практиках (aka best practices), усвоив которые, разработчик смог бы писать код покрасивше. А где статьи и книги, там и коучи (гадкое словечко), которые с удовольствием обучат вашу команду тому, чего ещё не существовало несколько лет назад и без чего вы всё это время прекрасно жили и работали.

Пропаганда методологий разработки сработала настолько удачно, что зараженные вирусом программисты сами же стали разносить эту заразу по всему миру. Новые проекты все как один начинались на Agile; в резюме стали появляться гордые строчки с упоминанием Scrum, RUP и XP, а на просьбу рассказать о своём предыдущем проекте одурманенный разработчик с гордостью рассказывал про опыт работы с Agile или Kanban, как будто это имеет какое-либо отношение к написанию кода.

Красивые слова увлекали настолько, что многие забывали, что sprint — это не газировка, а рывок, бег на короткую дистанцию — ничего приятного в этом нет. Но маховик уже раскручен, и в умах у многих укоренилась мысль о том, что без методологий разработки уже никак.

Пыль в глаза

Возникла целая индустрия нахлебников и очковтирателей, которые, пользуясь успешно проведенной промывкой мозгов (и своих в том числе), начали писать ещё больше книг, проводить конференции, встречи и другие мероприятия, посвященные чему угодно, только не самому главному — написанию рабочего кода.

Теперь обо всей этой Agile-XP-Kanban-Scrum-RUP-Waterfall феерии заставили думать ещё и разработчика, задача которого — вообще-то не по митингам шастать или пускать каждый раз скупую слезу при виде burndown chart, а работать.


Хитрое «ноухау» — рисовать график выполненных задач не вверх, а вниз, прим этом называя его пафосным «Burndown chart». Но один вопрос остается открытым — зачем разработчикам график с нисходящей линией прогресса, которая вызывает негативные ассоциации?

Нужны ли все эти графики заказчику или разработчику? Методом дробления процесса разработки ПО на мельчайшие частицы мы придём к атому — работающий код. Это единственное, что должно волновать разработчика и заказчика. Всё остальное — суета сует, тщета и ловля ветра.


RUP (Rational Unified Process) — чем сложнее для понимания, тем счастливее менеджеры и тем больше мусора в голове у разработчика.

Best practices (aka лучшие практики)

На этой теме сегодня кормятся многие IT-евангелисты (с намёком на религиозный уклон) — пишут книги, проводят семинары, поднимают капусту. Всегда ли нужно использовать эти лучшие практики?

Есть такие люди, которые верят во всё написанное. Например, в то, что TDD (Test-driven development) — это святое добро, или что каждый сайт должен обязательно проходить валидацию W3C. Если ты на глазах такого человека начнешь писать код, не написав перед этим тест, он на тебя посмотрит так, как будто ты не помолился перед едой. Забыл название какого-нибудь паттерна или фамилию автора известной книги по ООП? Гореть тебе в аду, антихрист. В пользу того, что некоторые популярные методологии больше смахивают на религии, сам за себя говорит Agile, в котором есть такие понятия как церемонии, артефакты, графики сжигания и духовный лидер (aka Scrum Master).

Один из многочисленных примеров умопомешательства на «лучших практиках» — это вопрос об идеальной длине метода:

In «Clean Code: A Handbook of Agile Software Craftsmanship», Robert Martin says:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.

and he gives an example from Java code he sees from Kent Beck:

Every function in his program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!

This sounds great, but on the other hand, in «Code Complete», Steve McConnell says something very different:

The routine should be allowed to grow organically up to 100-200 lines, decades of evidence say that routines of such length no more error prone than shorter routines.

And he gives a reference to a study that says routines 65 lines or long are cheaper to develop.

So while there are diverging opinions about the matter, is there a functional best-practice towards determining the ideal length of a method for you?

Слабые места методологий

У всех этих методик и практик есть одна общая беда — они написаны теоретиками. Людьми, которые пытаются предугадать все риски. Возьмем, к примеру, тесты. Ладно ещё, когда они пишутся после или параллельно с кодом, но писать тест ещё до того, как появился функционал — это ли не излишняя перестраховка? Всё равно что пристегнуться ремнем безопасности ещё до того, как сел в автомобиль.

Другая уязвимость этих методик заключается в том, что они пытаются объять необъятное. Почему-то считается, что если на заводах Toyota успешно применяется Kanban или Lean, то их стоит использовать и в разработке ПО. При этом многие забывают, что между производством стандартного автомобиля, где на учёте каждый болт, и программой, которая почти всегда уникальна и неповторима, даже если это шаблонный интернет-магазин, — огромная разница. Вот если бы на разработку ПО переносили методологии производства custom-made автомобилей (а ещё лучше — мотоциклов), можно было бы о чем-то говорить.

Третья проблема — перфекционизм, который на этих «лучших практиках» растёт, как на дрожжах. Если на проекте не хватает чего-нибудь из XP или нет 100% покрытия тестами, у некоторых ребят начинают трястись поджилки. Будь сейчас рядом Цукерберг, он бы явно негодовал со своим «Done is better than perfect». Ведь кому нужно всё это «вылизывание» и бесконеный рефакторинг там, где это идет в убыток компании? Разве что разработчику, фанатично преданному «лучшим практикам».

Спор приверженца и отступника (реальный лог чата одной команды)

Отступник: Я видел людей, которые вместо того, чтобы сделать проект и получить фидбек, две недели думали о том, какой им использовать подход.

Приверженец: Если посмотреть вакансии, то в 99% случаев на проектах используют Agile.

Отступник: Да пусть используют что угодно. Ты либо делаешь проект, либо споришь как его делать. Будем честны — Agile немного усложняет разработку.
Приверженец: Спорить, как его делать — это неотъемлемая часть процесса делания проекта.

Отступник: Пока ты споришь, другие косят твои деньги. Потому что они запустили прототип и получили клиентов. А у тебя готово 10% проекта, зато с прекрасной архитектурой.

Приверженец: Если ты забьешь на архитектуру, тебе потом своё же болото придется разгребать, почему тогда сразу не делать нормально?
Отступник: Зачем тратить 1 год на то, в чем ты не уверен?

Приверженец: Мое дело — в первую очередь делать свою работу качественно, а не думать об opportunities и сроках.
Отступник: Ты сильно ошибаешься. Твоя главная задача — написать код, который будет работать и приносить деньги.
Приверженец: Это и так понятно.
Отступник: А будешь ты использовать при этом #крутойподход или нет — всем абсолютно плевать.

Есть ли выгода от методологий и лучших практик

Много споров идет о том, выгоднее ли Agile, чем Waterfall, можно ли сэкономить, используя парное программирование, окупится ли в долгосрочной перспективе рефакторинг или нет. И ни у кого нет ответа, так как здесь слишком много переменных, начиная от того, что значит «выгодно» и заканчивая тем, полностью ли соответствует разработка букве методологии.

Самое время вспомнить старую школьную задачку: Что тяжелее — килограмм пуха или килограмм свинца?

Вопрос о методологиях и «лучших практиках» как раз смахивает на эту задачку. Если у вас есть 7 разработчиков, которым вы платите зарплату, то в год вы потратите X долларов. Если вы используете Agile, то за год вы потратите те же X долларов. Waterfall? — Аналогично. Ваша команда будет с утра до ночи рефакторить и регулярно деливерить, применяя парное программирование, pomodoro и дебаггинг резиновой утки? Вы всё равно потратите X долларов. Да, может быть, они смогут написать программу, которую удобнее поддерживать. Но что, если вам не нужно настолько хорошее качество кода, а достаточно уровня «тяп-ляп — и в продакшен»? Или, допустим, команда закончит проект быстрее чем за год — но ведь скорость тоже далеко не всегда значит качество или соответствие требованиям заказчика.

Вообще оценка эффективности методологии — вещь сложная и неблагодарная. Достаточно взять одно лишь парное программирование, которое вроде как на 15% дороже, но в то же время позволяет обучить новичка или дать эксперту толчок к новой идее, не говоря уже о других существенных мелочах.

С точки же зрения офисного трудяги всё куда проще: ему платят за часы в офисе. Поэтому ему абсолютно фиолетово, какой дури (18+) обкурились заказчик с менеджером и какую методологию решили внедрить. Лишь бы его поменьше трогали и позволили писать код. Грамотные менеджеры понимают это и становятся между заказчиком и разработчиком, принимая удар на себя. Ведь в конечном счете всё, что требуется от программиста — это programming, motherfucker.

Поэтому не важно, используете вы какую методологию, дебажите ли с помидором или с уткой и сколько раз в неделю у вас парное программирование. «Code wins arguments» — и этим всё сказано.

Что делать?

В противовес распиаренным методикам разработки и «лучшим практикам» всегда есть старый добрый хакерский подход, в который можно ткнуть мордочкой заблудшего разработчика или распоясавшегося менеджера. Если будут вопросы, скажете, что Цукерберг одобряет.

One Hacker Way — Erik Meijer from Reaktor on Vimeo.

LinkedIn

Лучшие комментарии пропустить

Не сказал бы, что вопрос об оптимальной длине метода это умопомешательство. Просто приходилось поддерживать код, состоящий из методов длиной от 10 до 50 экранов кода. Разбираться в этом было сущим адом.
Длина метода, именование переменных, методов и классов, расстановка отступов и скобок — это реально важно и ко всяким модным методикам не имеет отношения. По сути это азы, без соблюдения которых хороший код нельзя написать.

Если у вас есть 7 разработчиков, которым вы платите зарплату, то в год вы потратите X долларов. Если вы используете Agile, то за год вы потратите те же X долларов. Waterfall? — Аналогично.
Если Вы от точки А до В несете на себе велосипед 10 километров, или едете на нем 10 километров, то через 10 километров Вы и велосипед будут в точке В — Аналогично!

Космический бред и скорее всего просто олололо троллинг для привлечения внимания. Waterfall означает, что нужно полностью специфицировать и спроектировать весь функционал до начала кодинга, что очень не просто и практически никогда не делается. А писать «как попало» — это Code&Fix, или попросту бардак.

И еще понравилось, как рефакторинг причислили к гибким методикам разработки.

P.S. Жалко, что на ДОУ пропускают настолько желтые и провокационные статьи. Они конечно создают много активности и флуда, что наверное полезно для самого веб-сайта, для людей которые хотят почитать профессиональные статьи по делу — это только потеря времени.

коачі, тренінги, скрам мастери, і всяка інша дрочка на модні процеси і терміни — це для тих, в кого своєї голови немає і хто ніколи не може подитись критично на речі. (написано в книжці == істина)

Еджайл просто відкрив, що кількість таких людей в індустрії — овер 9000

Слишком много (или даже большинство) людей занимаются тем или говорят о том, о чем имеют весьма ограниченное представление, чаще же — вообще никакого представления или представление крайне неверное. И эта статья тому ярчайший пример.

139 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Латентное желание стать коачем часто приводит к срыву покровов. Надеюсь, это не тот самый случай.

Как все дружно набросились ) и кое о чем забыли в процессе защиты и отвергания ...

Все эти методологии изобретены для того, чтобы создать точки соприкосновения «программистов» и «бизнесменов» в процессе работы над проектом.
Утверждение «рабочий код» = «хороший код» верно для тех и других, но есть одно НО.

Частая ситуация:
1. «Бизнесмен» получает от «программистов» «рабочий код» через год от начала проекта (каскадная модель)
2. За год внутри организации-заказчика произошли изменения, влекущие необходимость изменений в проекте.
3. Как следствие — полученный через год «рабочий код» теряет свою бизнес-стоимость и/или становится бесполезным (при этом сам код идеален со всех точек зрения)
Нужен такой идеальный код «бизнесмену»? Конечно нет!

Поэтому «бизнесмены» перестраховываются, подсовывая различные методологии влияния на ход реализации проекта.
В идеале разработчик, с точки зрения бизнеса, это хрустальный шар, который угадывает желания и мгновенно предоставляет результат. При этом стоимость такого разработчика уходит на второй план (хотя и стремится к бесконечности).
Для такого разработчика действительно не нужны НИКАКИЕ методологии управления разработкой, так как результат получается мгновенно и точно соответствующий заказу.

Резюме: гибкие (aka Agile) методологии управления разработкой нужны!
Заказчикам — чтобы влиять на результат без увеличения бюджета разработки.
Исполнителям — чтобы создавать для заказчика видимость управляемости.

Только в каких-то идеальных случаях гибкие методологии позволят заказчику влиять на результат без увеличения бюджета. В общем же случаи, гибкие методологии — попытка (не всегда успешная) минимизировать увеличение бюджета от непредвиденного для разработчиков изменений требований.

Вы абсолютно правильно меня поняли.
А разработчик, пытающийся по собственной инициативе внедрить у себя скрам, аджайл или прочий кан-бан просто зря тратит средства. Так как это в первую очередь инструмент заказчика.
Не просят — незачем тратится на это. Иногда банальных поход в баню решает больше любого скрам-митинга )
Но, конечно, рассчитывать на крупную «рыбу» таким разработчикам тоже не приходится, ибо рыба «клюет» на буквосочетание «AGILE»

Із досвіду нашої невеликої команди (5 людей) можу сказати, що нам найкраще іде, якщо чергувати: кілька місяців рубаємо активно по agile/scrum, кілька місяців релаксу. Інакше за пів-року «двіжухи» гравці перегоряють.

Ну і початок проекту з нуля стараємось по продуктивних методологіях, до першої версії. А вже далі по-різному. Зазвичай довготривалі проекти нам краще йдуть окремими завданнями і релізами прив’язаними до дати, а не до кількості виконаних завдань.

Прочитав статью и комментарии остаюсь при своем мнении:
1. в чистом виде методологии зачастую вовред.
2. Компания / команда / направление для максимальной эффективности должны вырабатывать свой подход не брезгуя хорошими идеями всех известных им подходов.
3. Гнать коучеров и фанатиков подальше от вашей команды. Они не знают всей вашей специфики и только загадят мозг людям. Сами проведите треннинг для коллег и поясните доходчиво ваши стандарты.

Мой опыт показывает, что ретрограды есть везде, в т.ч. и в IT.
Их критика методологий и авторитетов зачастую происходит из незнания и лени. Реже — из болезненной склонности искать серебряные пули.
Любой инструмент можно использовать неправильно, но правильное его использование практически всегда во благо.

Мало правильно его применить, нужно чтобы это применение отвечало цели проекта. Молотком можно правильно забить гвоздь, но при этом этот гвоздь не принесёт пользы ремонту, а то и заставит все переделывать.

Я лично просто не люблю коучей. Сразу вспоминается замечательная песня группы Ленинград «Пора в школу».
Scrum ни хорош ни плох, пока вы не превращаете его у себя в голове в средство от всех бед.
Waterfall тоже кстати прелесть еще та, случай из недавней практики когда команда делала проект полгода по водопаду, а потом певрый раз показали заказчику и оказалось что бизнес-аналитик его не так понял, а документ подготовленный последним он подмахнул не глядя.

Не существует в природе ни одного вида инженерной деятельности, в которой бы применялся Agile , Scrum и прочие ИТ-шные «методологии», — кроме собственно ИТ. Машиностроение, энергетика, строительство (при всем присущем ему бардаке) — только Waterfall. Спроектировали — потом построили. Только так и никак иначе.

Вы забыли методики борьбы с непредвиденными обстоятельствами и Research Teams.
Космическая гонка — Agile в чистом виде, только на тот момент неформализованный.

Не забыл. Я говорю о промышленном производстве. Космос — это НИР. Большинство изделий малосерийны, а в некоторых случаях — вообще уникальны.
В какой то степени популярность Agile и т.п., как раз и объясняется претензией ИТ-шников на уникальность того чем они занимаются и ассоциированием себя с «rocket space technology». В реальности большинство вещей, которые мы делаем — более чем тривиальны.

В какой то степени популярность Agile и т.п., как раз и объясняется претензией ИТ-шников на уникальность того чем они занимаются и ассоциированием себя с «rocket space technology».
все намного прозаичнее: заказчикам так удобнее — видеть результат побыстрее и менять требования каждый день вот и все

Мотивация заказчиков понятна. Кроме нее есть отдельный уровень мотивации у ИТ-шников. Вокруг Agile, как «передовой технологии разработки» кормится неслабое количество тренеров и консультантов. А кроме того, есть немалое количество истинно-верующих со стороны разработчиков в исключительность ИТ, как отрасли производства и в особые законы природы, которые действуют при разработке веб-сайта и не действуют при производстве автомобиля или молотка. Как мне показалось, именно об этом написал автор статьи.

Вменяемые ПМ процесс строят исходя из особенностей проекта, не брезгуя никакой подходящей методологией.

Вменяемые ПМ не употребляют характеристик, которые нельзя измерить :). Метрика вменяемости — это что?

Отсутствие религиозных причин для выбора метеодологии;)

Вы всерьез беретесь доказать наличие у меня каких то религиозных причин?

Некоторая зашоренеость есть, вы в упор не видите доводов оппонента, хотя я ваши вижу.
Дискуссия в одни ворота слабоинтересна.

А кроме того, есть немалое количество истинно-верующих со стороны разработчиков в исключительность ИТ, как отрасли производства и в особые законы природы, которые действуют при разработке веб-сайта и не действуют при производстве автомобиля или молотка.
это же хорошо, когда человек может мотивироваться собственной фантазией, не нужно заморачиваться с поиском мотивации на стороне

Уникальность в
1) Объеме технологий и слишком быстром темпе развития, печатные книги устаревают на момент публикации
2) В стране реально какие-то деньги заработать либо пиля бюджет, либо в ИТ.

Вот и все истоки уникальности. Если для другой области создать подобные условия, то будет тоже самое. Вспомним популярность финансистов и юристов в 90-х, врачей в Америке, кузнецов в деревне в 18 веке (считались колдунами).

Agile предназначен для неизведанных или постоянно меняющихся областей, не подлежащих категоризации, где probe — sence — respond является более выгодной стратегией, чем долгосрочное планирование в ситуации где постоянно «на пути радиоканала ВНЕЗАПНО построили дом»

В других областях прекрасно работают Waterfall и RUP, в каких именно — предоставляю самостоятельно найти по ссылке:
en.wikipedia.org/wiki/Cynefin

У Вас смешались в кучу кони и люди, кузнецы и программисты :). Оба Ваших условиях не выполняются ни для одного из приведенных Вами примеров.
Википедию читайте сами. У меня есть мой собственный опыт работы и по Waterfall, и по RUP и даже по Agile :) Никто не даст Вам работать по Agile, если Вы делаете софт для медицины, для АЭС или вообще для любой области, когда от софта напрямую зависит жизнь человека. Если нужен гарантированный и качественный результат — будет только Waterfall.
Agile пользуется спросом не потому что гибок — какая уж там гибкость, когда Вы начинаете делать проект, не понимая до конца, что в итоге получится на выходе, лепите заплатку на заплатке, а когда код уже невозможно поддерживать и приложение вот вот рухнет — Вы произносите очередное магическое заклинание — «рефакторинг!» и начинаете переписывать приложение чуть ли не с самого начала. И так иногда несколько раз за проект :)
Agile в первую очередь дешев, а во-вторую — позволяет увеличивать объемы работ на проекте плавно для клиента, что спасает ему психику :)

У меня есть мой собственный опыт работы и по Waterfall, и по RUP и даже по Agile :)
Аналогично, шеф©
Никто не даст Вам работать по Agile, если Вы делаете софт для медицины, для АЭС или вообще для любой области, когда от софта напрямую зависит жизнь человека
Естественно, там у клиента другие критерии — четко знает чего хочет, требования не меняются, согласен платить за дополнительное качество.
Я в доме, выстроенном по Agile — жить не хочу.
когда Вы начинаете делать проект, не понимая до конца, что в итоге получится на выходе, лепите заплатку на заплатке, а когда код уже невозможно поддерживать и приложение вот вот рухнет

Участвовал и в таком, причем до и после всякого Agile.
Agile в первую очередь дешев, а во-вторую — позволяет увеличивать объемы работ на проекте плавно для клиента, что спасает ему психику :)
Отлично! Вот гонимому вам Agile и нашлось достойное применение среди всех методик даже с вашей точки зрения ;)
Я в доме, выстроенном по Agile — жить не хочу.

Огорчу: вы именно в нём и живёте. Только вы этого не видите, потому что не строитель и не архитектор, и мимо вашего сознания прошло то, что
* для вашего дома никто не разрабатывал материалы, взяли готовые
* архитектор намешал готовые шаблоны предыдущих поколений, кое-как учтя рекомендации по выбору материалов и схем
* в отличие от программирования, копирование результата дорогое
* при строительстве всё время возникали локальные казусы типа «земля просела, надо ещё 20 кубов бетона и три сваи», но жильцам этого не говорят

Что говорит о том, что ничто не ново под луной, и что Emergence практики существовали всегда. Agile их просто формализовал и сделал базисом, вместо дополнения. Вменяемые ПМ обычно выбирают что то среднее, исходя из особенностей проекта.

П.С. Как готовить Agile борщ — придумали цыгане. Ибо их рецепт звучит так:
«Сначала украдите кастрюлю...»

Камон, аргумент про медицину, АЭС и проч. надоел еще лет 5 назад, никто не спорит что гибкие методологии там применять сложно (хотя и можно). Абсолютное большинство разработчиков занимаются внутренним софтом компаний плюс какое-то количество — коробочными продуктами/сервисами.

Мало ли что кому надоело. Аргумент надоел — еще не повод считать, что он неверный.
Какое отношение к вопросу имеет то чем занимается большинство разработчиков? Кто это большинство считал и как?

Для сферичиских разработчиков в вакууме — никакого.
Авторы Agile Manifesto — практики как раз и решали конкретных команд, работающих в специфическом постоянно меняющемся окружении.

Никто не даст Вам работать по Agile, если Вы делаете софт для медицины, для АЭС или вообще для любой области, когда от софта напрямую зависит жизнь человека. Если нужен гарантированный и качественный результат — будет только Waterfall.

Для критически важного софта принципиальным является наличие достаточного времени и средств на проработку всех аспектов и даже на простое осознание специфики задачи, и представление результатов этих осознания и проработки в зафиксированном виде (ТЗ, отчёты...) Но это нельзя путать с Waterfall, который однозначно означает проработку сверху вниз. Неважно, откуда у вас код, который удовлетворяет условиям, особенно, если эти сами условия были сформулированы на ходу в процессе этой разработки, но потом устояли в процессе анализа и критики. Сама разработка может быть трижды Agile, но потом результат подвергся формализации; и снова это не Waterfall, который предполагает, что до формулировки требований верхнего уровня внизу ещё ничего нет.

(Реально же всё принципиально новое создаётся человечеством через самый кошмарный Agile, даже если потом по отчётам там сплошное торжество иерархического разума. Только раньше его не могли адекватно сформулировать, а часто и не хотели. Построение теории творчества началось по сути не раньше конца XIX века, а крупные достижения вроде ТРИЗ это уже середина XX века.)

Agile пользуется спросом не потому что гибок — какая уж там гибкость, когда Вы начинаете делать проект, не понимая до конца, что в итоге получится на выходе, лепите заплатку на заплатке, а когда код уже невозможно поддерживать и приложение вот вот рухнет — Вы произносите очередное магическое заклинание — «рефакторинг!» и начинаете переписывать приложение чуть ли не с самого начала. И так иногда несколько раз за проект :)

Именно, что вы как раз описали ту гибкость, за которую он и ценится. Когда >90% программных разработок представляют собой сплошной R&D, иначе в принципе не получится, как составлять стройные системы костылей и подпорок, слепленные заплатками и обмотанные дырявым скотчем, чтобы вообще проверить, что идея работоспособна. И только потом её наполнять полноценной реализацией.

а во-вторую — позволяет увеличивать объемы работ на проекте плавно для клиента, что спасает ему психику :)

Вопрос не в психике как таковой, вопрос в том, что при этом заказчик ещё и реально понимает, что именно ему нужно и что это действительно нужно.

2) В стране реально какие-то деньги заработать либо пиля бюджет, либо в ИТ.
вот это жесть сравнение :) айти у нас нищее, просто на фоне трудяг, у которых зп как чаевые в приличном ресторане, кажется все клево, а попил бюджета приводит к дворцам по всему миру, кстати есть еще «третья сила», о которой ты не в курсе, оглянись вокруг какие машинки ездят — это не попил и не айти
Большинство изделий малосерийны, а в некоторых случаях — вообще уникальны.

Любой программный продукт это уникальная разработка.

Некоторые получают массовость работы на месте за счёт локальных пусконаладочных работ, включая дописку под конкретного заказчика. Это может доходить до сотен тысяч случаев (пример 1С). Основа же всё равно уникальна.

В какой то степени популярность Agile и т.п., как раз и объясняется претензией ИТ-шников на уникальность того чем они занимаются и ассоциированием себя с «rocket space technology».

Эта претензия 100% обоснованна в плане именно уникальности разработки. Не обоснованна — в плане стоимости и цены ошибки, но вменяемые на это и не претендуют.

В не-программной инженерии стоимость ошибки, переделки, «расширения функциональности» гораздо выше. Приходится всё делать правильно с первого раза.

Ровно наоборот: ВСЕ виды инженерной деятельности это Agile в практически чистом виде. Ваше заблуждение происходит из того, что Вы игнорируете, что в описанных отраслях основная финальная работа и стоимость приходятся на тиражирование, которое в случае IT стоит почти ноль. Вот видя уже отработанный технологический процесс конвейера или строительства по готовому плану, Вы отказываетесь видеть:
1. Поиск работающих технологий. Почему ДВС на бензине, а не воде или дровах?
2. Доведение этих технологий до вида, работающего хотя бы в лаборатории. Зачем нужен карбюратор или инжектор? Опыты показали, что надо закачивать сразу топливо-воздушную смесь, иначе не работает. Зачем система охлаждения? Это не было очевидно первым создателям. Какая система охлаждения годится для данной мощности? Ещё долго моторы были на воздушном охлаждении (ещё ЗАЗ-968 был на нём).
3. Создание промышленного образца. Почему нет легковых автомобилей на мазуте?
4. Доведение до серийного производства. Выбор реально доступных и по адекватной стоимости материалов, технологий. Адаптация под конкретного исполнителя.

Всё это процессы, которые происходят итеративно на основании множественного предшествующего опыта, и никто не считает, что это ненормально.

Доля повторного использования в материальной промышленности тоже колоссальна — в программировании она сильно меньше, каждый старается изобрести свой велосипед.

хорошо получается — «не читал, не использвал, но обсираю»

Не совсем так.
«Читал, использовал, говорю как есть».
Вот теперь хорошо получается.

Суть такова, что любая технология/методология не родилась на пустом месте, является всего лишь навсего инструментом и имеет:
— исходные условия
— результаты, которые планируется достигнуть
— side еффекты, или издержки
— границы область применимости

Соавтор Agile Manifesto, и , surprise, по совместительтву почитаемый многими аки бох Мартин Фаулер в своих статьях на это прямо указывает.

Видел многое в своей жизни:
— внедряемое ради красного словца кристально чистое Agile/MongoDB (нужное подчеркнуть) c катастрофическими эффектами
— нечистое, но подходящее под особенности проекта Aglile с Roadmap, Net с Node.js и прочих кадавромутантов
— довольных клиентов с Waterfall
— довольных клиентов, которым продали Scrum после Waterfall, ибо избавлено их от Analisys Paralise есть
— и т.д. и т. п.

Так что зависит от серого вещества внедряющих, вне зависимости от того, Agile это или MongoDB.
И в там "где тесно и темно«© этот ваш «Programming, Motherfucker!» ибо сугубая крайность и байтослесарство есть.

Да здравствует «Engineering, Motherfucker!», ЕВПОЧЯ, ибо ваистену;)

А от изучения методик работающих с вами в одной команде PM, QA, HR не убудет, а только прибудет, ибо понимание обстановки и языка коллег — залог спокойного педаления кода.

Надо применять «Золотую середину», чтобы и разработчикам мозги не пудрить, но чтобы и порядок был.

Практики и методологии это просто инструментарий. Если кто-то делает из еды культ, то это скорее проблема шизанутости конкретных индивидуумов. Команда в идеале должна сама решать какие практики ей использовать. Суть аджайла в гибкости (cap. Obvious), а любая догматичность ей противоречит. И уж точно ей противоречит ватерфол с написанием доки в полгода (какие там стартапы?). Кстати, саму идею стартаперства вы помешательством не считаете? Но это отдельная тема...

Насчет рефакторинга и Done/perfect. Они обязаны идти в балансе, иначе получишь такую кучу гуано что нормальные люди не захотят в ней работать, а любое изменение требований будет приводить в отчаяние и к желанию апдейтнуть резюме. А перфектное решение и хороший мастер будут всегда в цене. Есть в мире и люди, желающие пользоваться хорошими продуктами, а не недопиленными хипстерскими поделками. Каждому свое, как говорится.

Как выход — применять практики и делать выводы, оптимизировать под свой коллектив и задачи, ну и рынок диктует, конечно. Иногда имеет смысл и коллектив с задачами вывести на новый уровень, и нишу на рынке поменять.

Ну а можно, получив негативный опыт, на всех обидеться и кидаться какашками в индустрию, тоже вариант...

Космический бред и скорее всего просто олололо троллинг для привлечения внимания. Waterfall означает, что нужно полностью специфицировать и спроектировать весь функционал до начала кодинга, что очень не просто и практически никогда не делается. А писать «как попало» — это Code&Fix, или попросту бардак.

И еще понравилось, как рефакторинг причислили к гибким методикам разработки.

P.S. Жалко, что на ДОУ пропускают настолько желтые и провокационные статьи. Они конечно создают много активности и флуда, что наверное полезно для самого веб-сайта, для людей которые хотят почитать профессиональные статьи по делу — это только потеря времени.

И еще понравилось, как рефакторинг причислили к гибким методикам разработки
Что вы выдумываете. Не было такого (или давайте пруф-цитату). Рефакторинг относится к «лучшим практикам».
А писать «как попало» — это Code&Fix, или попросту бардак.
А ещё это то, с чего начинался Facebook и масса других стартапов.

Рефакторинг это просто улучшение кода без изменения фунционала. Практика или методика — это когда и в каких объемах его проводить.

Угу, большинство стартапов начинается с бардака. Но уж никак не с Waterfall ;) Кстати Agile всегда был отличной отмазкой, почему нормальных требований нет. У меня манагер как то даже придумал термин — «Супер-agile», то есть тот же бардак :)

BTW, Юрий, простите уж за любопытство, но у вас есть профиль в линкедине или подобных штуках? Интересно было бы сопоставить статьи с вашим опытом работы.

Да, профиль конечно есть. Его здесь на ДОУ уже кто-то когда-то публиковал.

Можете скинуть ссылочку, а по всем статьям долго будет ходить.

Увы, я предпочитаю не сорить ссылками на свой Linkedin без крайней необходимости.

А чего ж так? Страна должна знать своих героев в лицо и профиль линкед ин ;)

Очень быстро гуглиться по имени

Можно было уже и кинуть... Нагуглил, в skills первое место по endorse Agile Methodologies :)

Все верно. Если нет over 10 years kanban/xp agile methodology и звание scrum-master’a, то нечего тут статьи писать.

Жалко, что на ДОУ пропускают настолько желтые и провокационные статьи. Они конечно создают много активности и флуда, что наверное полезно для самого веб-сайта, для людей которые хотят почитать профессиональные статьи по делу — это только потеря времени.

В точку. Помнится довольно уже давно поднимался вопрос (руководством сайта), как сделать из ДОУ «качественный» ресурс и т.д. и т.п. Забавно получается. Вместо того, чтоб модерировать ненормативную лексику и эмоциональные высказывания, может лучше не пропускать материалы, которые вызывают желание эти приемы использовать? Ресурс формирует (воспитывает) аудиторию, или аудитория ресурс? За кем какая роль? Если вы бульварное издание — то ваша роль, безусловно, рейтинги и спрос любой ценой. А если вы претендуете на малейшую просветительскую функцию, то придется потрудиться над тем, чтоб политика эту просвет.функцию поддерживала. Будь-то университет, проф.сообщество, журнал или политическая партия.

Кто-то скажет что это оффтоп и я ушел в дебри, но посудите сами: деятельности у нас в стране очень много, а толку — увы, очень мало.

может лучше не пропускать материалы, которые вызывают желание эти приемы использовать
Значит, задел за живое.
посудите сами: деятельности у нас в стране очень много, а толку — увы, очень мало.
Это же про методологии разработки!
Значит, задел за живое.
Ну разумеется!
Это же про методологии разработки!
Юрий, а скажите, что лучше: пулемет или танк?
пулемет или танк
Я не военный, не знаю. Но, подозреваю, что зависит от задач.
Лихо вы сравнили процессы и принципы (методологии и «лучшие практики») с материальными объектами (пулеметы и танки). Это разные вещи.
Если уж на то пошло, то пулемет — это компьютер, за которым разработчик пишет программу.
Вопрос методологии и «лучших практик» — это вопрос о том, стрелять стоя или лежа, очередями или одиночными, с крыши или из окна и так далее.

Я взял первое попавшееся сравнение, чтобы в нем ярче была видна его абсурдность.
Вы конечно не слышали о фигурах речи. Ну да ладно.

Поясню буквально. Я не методологии и мат.объекты сравнил. Я лишь попытался вам сказать, что ваши утверждения в стиле «методологии — плохо» идентичны вопросу «что лучше: пулемет или танк?» Вы абстрактные концепты (методологии) смешали в кучу с конкретными сущностями (применение методологий конкретными людьми в конкретных случаях).

Давайте еще так попробую: если танчик стоит в Музее Славы и детки по нему ползают-играются — хорошо; если танк расстреливает мирные дома — плохо. Но сам танк (как понятие) это просто танк. Это ни хорошо, ни плохо.

(Сам не понимаю, зачем я все это разжевываю. Сразу скажу, отвечать дальше не буду, просто времени больше на это нет.)

Вы абстрактные концепты (методологии) смешали в кучу с конкретными сущностями (применение методологий конкретными людьми в конкретных случаях).

Методология «молиться и каяться» не поможет написанию софта для 99.99% разработчиков. Так что сравнение возможно:)

Это есть оффтоп и ересь. ДОУ просто следует уже упомянутой высшей истине — super-agile.

А поговорить? (тм)
Если статья не очень, то комментарии весьма познавательны.

Бред. Просто бред.

Я просто процитирую сам себя
-----------------
SCRUM для постсовка не катит потому что

1. Все привыкли компенсировать свои личные психологические расстройства,
создавая довольно замысловатые коммуникационные барьеры и рабочие ритуалы с обрядами посвящения.
Эти барьеры приводят к ситуации «обсуждать, а не анализировать; полагать, а не принимать обоснованное решение».

2. Руководство и разработчики чаще всего ригидны и не обладают возможностью видения перспективы,
даже банальный анализ существующих подходов и интрументариев является непосильной задачей.
Привет, Golden Hammer. Сайонара, долгосрочная поддержка.

3. Зачем разделять разработчиков на тестеров и программистов — высшую и низшую касту племенного сообщества.
У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты...
Вы все же там такие Agile-ные экстремалы с RAD’ом...

4. Желание компенсироваться — «быть самым главны и/или самым умным» и подсознательно разделять всех на тех кто нравится, и тех, кто не нравится, порождая грибной менеджмент и поверхностную выработку требований.
Привет, «Грибной менеджмент» и «Охота на ведьм».

5. И наконец у вас должен быть готовый продукт в конце каждой итерации,
с последующим эволюционным рефакторингом и добавлением нового функционала...
Если так не получается — вы делаете что-то не так.

На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
В таком случае V-model легко адаптировать под простой kanban.

V-model это разработка по спецификациям, и документация ставится выше живых людей. Пока не отработан V-model, и не адаптирован под тот же lean или kanban — смысла в Scrum двигать нет. Люди просто не сработаются и не поймут чего от них хотят, а что вообще реально можно предложить клиентам.

Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.

Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum’a.
-----------------

Автор рассуждает как «второсортный» студент без опыта долгосрочной поддержки и контроля качества. Конечно, можно написать «раз и что бы работало, и вообще зачем вся эта новомодная ерунда ?», но вот на практике это приводит к звонкам в 4 часа утра с фразами «Юра, спасай ! Оно накрылось! Вася заболел, а Вика в отпуске — едь в офис быстрее!», ну или святое «одно поправили — другое отвалилось», ну или «препарируем по живому продакшену, на радость всем пользователям сервиса!».

Да, я согласен по поводу нездорового перфекционизма — выходят такие книжки как «Балдеющие от адреналина и зомбированные шаблонами» но нужно понимать что это всего лишь личностные компенсаторные задачи, которые непосредственно к разработке ПО не имеют отношения. Вот скажи кому что весь MVC в RESTful сервисах можно уместить в 6 CRUD контроллеров для любого количества представлений и табличек БД — скажут «еретик», ведь ! Хотя на самом деле это всего лишь очередное подтверждение того, что люди хоть и читают книги, а на практике ничего толком применить не могут — только компенсируются.

QA и QC часто подразумевают контроль эффективности существующих методологий, и очень часто эта эффективность зависит от здоровья самого коллектива: пытаться внедрить личностный подход, он же «Agile», в среде где друг на друге только компенсируются и пытаются самоутверждаться, — довольно ущербно. Часто приходиться водить с собой психоаналитиков и проводить индивидуальные консультации, но это уже под NDA и тема для отдельной статьи.

Я так и не смог понять вашу цельную позицию, поэтому предположу, что «процитирую сам себя» это согласие с цитированным. Тогда:

Все привыкли компенсировать свои личные психологические расстройства, создавая довольно замысловатые коммуникационные барьеры и рабочие ритуалы с обрядами посвящения.

Постсовок очень разный. Если мы говорим про Украину (а для dou это контекст по умолчанию), то тут как раз противоположная ситуация — жесточайшее циничное и демонстративное неверие в ритуалы и обряды именно со стороны исполнителей. Хотя всякие HR, наоборот, стараются их навязывать по максимуму.

Зачем разделять разработчиков на тестеров и программистов — высшую и низшую касту племенного сообщества.

Простите, а кто из них высший по-вашему? :)

У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты...

А вы осознаёте, что программист и тестер (QA, QC) это вообще разный стиль мышления, и нужны оба? И что правильного тестера не заменит никакой программист? Кстати, религия TDD как раз обычно идёт вместе с Agile как религией, так что упрекать именно автора в этом бессмысленно.

Автор рассуждает как «второсортный» студент без опыта долгосрочной поддержки и контроля качества.

По-моему, у него таки критика чрезмерного раздувания важности даже не Agile, а отдельных шумных поднаправлений в нём. При чём тут QA и долгосрочная поддержка?

QA и QC часто подразумевают контроль эффективности существующих методологий, и очень часто эта эффективность зависит от здоровья самого коллектива: пытаться внедрить личностный подход, он же «Agile», в среде где друг на друге только компенсируются и пытаются самоутверждаться, — довольно ущербно.

А почему это вдруг Agile это личностный подход?

1. Речь идёт о больных коллективах и психологической компенсации, а HR’ы здесь вообще не причём. Как часто вы сталкивались с позицией «я хочу быть самым главным/умным» ? Речь идёт о психологическом ритуале — есть такое психологическое понятие, как HR может его навязывать, если оно касается непосредственно «одобрения» больным коллективом «свежей крови» которую можно использовать в своих компенсаторных задачах ? Ознакомьтесь с основами трансактного анализа прежде чем пытаться понять о чём тут речь.
2. В большей части известных мне коллективов задачи тестеров ставятся на второй план и воспринимаются как второсортные, потому что за различными метриками (цикломатической сложностью, покрытием кода etc), статическим анализом обычно приходится следить и самим программистам, впрочем как и писать тесты, и обычно объём задач касательно контроля качества со временем у программистов становится даже больше чем у тестеров, правда на это, обычно, никто не обращает внимания. Ну и соответственно это предвзятое мнение большей части известных мне руководств, касательно: «А зачем вообще нужны эти тестеры и чем они там занимаются ? А что наши программисты этого делать не умеют ?».
3. Программист и тестер обычно взаимозаменяемы — нет хороших программистов которые не могли бы решать задачи тестеров. Другое дело что программисты частенько очень посредственные и проявляется эта самая «разность стилей мышления». «Религия TDD» связана с особенностями внедрения нового функционала и ортогональностью существующих решений — на практике, в небольших проектах, в случае с функциональными тестами, может заменяться даже простым REPL’ом. Другое дело что приёмочное и интеграционное тестирование обычно сложно заменить чем-либо, особенно весело в каком-то реактивном SOA...
4. Потому что человек не представляет что нужно для этой самой долгосрочной поддержки и как на неё влияет эта самая «религия TDD», контроль рисков, и прочие издержки Agile’ов.
5. Процитирую первый пункт Agile manifecto: «Люди и взаимодействие важнее процессов и инструментов», потому он и личностный — нужно учитывать личностные особенности взаимодействия различных индивидов, а тут уже «привет психология».

Я вообще о том что у нас социум очень больной, и это очень сильно влияет на попытки внедрения различных методологий в существующих, плохо сформированных, коллективах.

Юрий, а сами-то вы работали с использованием любых из перечисленных методологий? Если да — а получалось ли хоть раз нормально настроить процессы, следуя идеологии одной из..?
Уж очень интересно на чем основана статья.

Да, Андрей, я работал на нескольких Agile-проектах; также руководил несколькими проектами, на которых велась разработка с помощью Agile. Комфортнее всего было на тех проектах, где был минимум «артефактов» Agile.

Ладно ещё, когда они пишутся после или параллельно с кодом, но писать тест ещё до того, как появился функционал — это ли не излишняя перестраховка? Всё равно что пристегнуться ремнем безопасности ещё до того, как сел в автомобиль.
Ладно ещё, когда ремень застегивается прямо перед аварией или просто на ходу, но застегивать ремень ещё до того как тронулся — это ли не излишняя перестраховка? Всё равно что написать тест ещё до того, как написал код, который этот тест будет проверять.
Но маховик уже раскручен, и в умах у многих укоренилась мысль о том, что без методологий разработки уже никак.
Без методологий может и не никак, но очень сложно. Лучше пуская плохая, но хоть как-то упорядочивающая процесс разработки, чем полное отсутствие хоть какой-нибудь, когда разработчик занимается чем ему (или его начальству :) хочется. Исключения — пет-проекты, стартапы и прочие проекты, где разработчик не является просто наёмным сотрудником.

Разбери любой автомат — и ты увидишь внутри маленький «Калашников». Разбери любую методологию разработки ПО — и ты увидишь внутри маленький водопад.

Да, чтобы набрать идентификатор, надо поставить цель и разложить её в цепочку подзадач по нажатию отдельных символов.

Набор идентификаторов часто процесс итеративный, с коррекцией в процессе набора и даже с исправлениями при поступлении фидбэка.

читал когда-то, что все новые методологии никогда не изменят одну старую — создание хорошей архитектуры и хорошего кода. И тут не так важно наверное сколько менеджеров или мастеров-тренеров в проекте и в каком порядке ходят стикеры на доске заданий.. )

почему-то прочитал «на доске страданий»... :)

в этом есть доля правды )

Так-то оно так, но проблема в том, что никто не знает, какая архитектура хорошая.

Важно сколько времени уйдёт на разработку при том или ином количестве менеджеров, использующих тот или иной подход.

Слишком много (или даже большинство) людей занимаются тем или говорят о том, о чем имеют весьма ограниченное представление, чаще же — вообще никакого представления или представление крайне неверное. И эта статья тому ярчайший пример.

Вангую, что автор попал на злого ПМа.

коачі, тренінги, скрам мастери, і всяка інша дрочка на модні процеси і терміни — це для тих, в кого своєї голови немає і хто ніколи не може подитись критично на речі. (написано в книжці == істина)

Еджайл просто відкрив, що кількість таких людей в індустрії — овер 9000

А что в используете вашей команде в Microsoft?

Статья не объективна. Как в лужу перднул.

Считаю что без хорошей методологии и контроля ответственности и сроков, которые они предоставляют иметь более эффективную работу — невозможно.

Если у вас есть 7 разработчиков, которым вы платите зарплату, то в год вы потратите X долларов. Если вы используете Agile, то за год вы потратите те же X долларов. Waterfall? — Аналогично.
Если Вы от точки А до В несете на себе велосипед 10 километров, или едете на нем 10 километров, то через 10 километров Вы и велосипед будут в точке В — Аналогично!

пример не очень удачный, велосипед это средство для достижения цели — а именно, добраться от А до Б в принципе, желательно максимально быстро, потратить минимум сил (денег). Как-то так, НО.... путь (//варианты) от А до Б может быть разный и дорога и расстояние тоже, например если 3 метра от А до Б по прямой но плохой дороге, нет никаких преград, все хорошо видно и т.д., то не нужен никакой велосипед и сделать 5 шагов самый простой, быстрый и дешевый вариант. Но есть другой путь, отличная дорога, природа и велосипед рядом но 10 км, это тоже работает ну хуже, даже если здоровье улучшится и т.п. рассказав заказчику какой был длинный путь и как хорошо вы его проехали на велосипеде.
А если например путь 10 км лежит через лабиринты, или нет лучше, через непроходимые джунгли то велосипед вам будет только доп. нагрузкой... Но суть вопроса и статьи в том что еще не зная какой путь предстоит, уже начинают сразу говорить что нужен велосипед, потому что многие его выбирают, полезно для здоровья, не нужен бензин и все такое....вот это и есть проблема о которой говорит автор.

Не бывает удачных или неудачных примеров, бывают лишь применимые или не применимые примеры. В статье говориться, что без разницы какой SDLC используется на проекте — Вы команде заплатите одинаковое количество денег, вот только опускается какой объем работы и какого качества они сделают за этот период. Поэтому абсурдный пример — достойный ответ на статью, которая тролит надеюсь, что автор просто притворствует, а не в серьез так считает инструменты разработки программного обеспечения

надеюсь, что автор просто притворствует, а не в серьез так считает
При чем здесь автор? Я лишь высказал коллективное мнение незашоренной части разработчиков, как это сделал, например, Эрик Мейер: vimeo.com/110554082

Столько комментов, а по существу никто из защитников Agile методологий так и не объяснил зачем они нужны разработчикам, или в чем цимес того же burndown chart’а (перевернули график — какая инновация!).
Неужели кто-то здесь и правда считает, что нельзя налепить на стену доску для задач без того, чтобы не внедрить на проект Agile или Kanban?

никто из защитников Agile методологий так и не объяснил зачем они нужны разработчикам
Это как раз просто. Любая методология нужна, с т.з. дева, чтобы ему мазги трахали не просто так, а методологично, систематично и по науке :8)
в чем цимес того же burndown chart’а (перевернули график — какая инновация!).
Вот этого наезда я серьёзно не понимаю. Смысл любого графика — в наглядности. В данном случае деву (в частности) наглядно виден, пардон, конец у работы, т.е. светлое пятно, когда можно расслабиЦЦа и попить пЫва.
Что касаеЦЦо ПМ-а, давайте не забывать основную его задачу (ОК, основную по книге :) ), цитирую DOU: «довести идею заказчика до реализации в установленный срок, используя существующие ресурсы», т.е. бабло, время и human-ов :8) (тут про качество забыли, но это не я :) ). Вы планировали когда-либо семейный бюджет? в условиях выплаты кредита на квартиру банку и задолжамши за мебель родакам жены? Вас сильно гребет сколько бабла было у вас в кошельке когда-то там две недели взад? Нет, Вам важно сколько там останецца на момент выплаты. И залезать «за» линии ограничения внизу и справа, т.е. брать новые долги, очевидно немона и ненуна, ибо и так уже попа в мыле. Т.е. как на меня, эта перевернутость — психиатрический трюк, чтобы PM наглядно видел сколько у команды времени осталось. Но уверен, что он работает, как работают и перемещающиеся по доске фишки, как работает толщина Вашего кошелька, когда Вы берете его в руку ... пардон, что считаю Ваши деньги :8)
Смысл любого графика — в наглядности.
То есть можно было и не переворачивать график, который по сути является еще одной лишней сущностью с пафосным называнием. Чем плохи обычные, проверенные временем графики?
В данном случае деву (в частности) наглядно виден, пардон, конец у работы
График вида «burndown chart» прививает разработчику негативное отношение к работе: «нет задач — хорошо, есть задачи — плохо». Я уж молчу про нисходящее направление графика, которое вызывает негативные ассоциации.
То есть можно было и не переворачивать график ...
Теоретически можно и на потолке сидеть, конечно. Я постарался обЪяснить, почему удобнее «перевернуть»... ну, не нравиЦЦа, считаете что пол и потолок поменяли местами — переверните еще раз и работайте с восходящими затратами, а не с остатком. Но не критикуйте burndown chart перед тимом! см. далее.
График вида «burndown chart» прививает разработчику негативное отношение к работе: «нет задач — хорошо, есть задачи — плохо».
Юра, поверьте пожалуйста: больше чего бы то ни было, негативное отношение к работе прививают разработчику ПМ-ы, которые постоянно рассказывают, что график плохой, клиент задолбал, начальник — мудак, эта долбаная задача никак сама разрешиЦЦа не хочет и пр. в таком духе. Если Вы как ПМ донесете до девелоперов позитив, т.е. то, что график представляет всего лишь наглядную демонстрацию того, где мы есть и где должны быть по плану (и как хорошо что погрешность всего 3%, а дальше конечно будут новые спринты и проекты), то и у них будет позитивное отношение к этим ньюансам.
Но не критикуйте burndown chart перед тимом! см. далее.

Я поддерживаю Юрия. Его надо перевернуть, после этого данный повод для критики уйдёт сам собой, и не нужно будет дальнейшего обсуждения:)

путь будет применимые и нет, суть не в этом же, а статья не тролит, и тем более не

инструменты разработки программного обеспечения
, о них как раз почти ни слова... просто по разному можно смотреть, например на методологию как на инструмент, статья многим будет полезна, особенно слишком увлекающимися новомодными «штуками» чтобы задумались..., а стоит ли «пушкой, да по воробьям», также как например, применимо ли везде ООП, шаблоны проектирования, какие языки, библиотеки использовать и т.п. это спорные вопросы всегда были и будут, ничего плохого тут нет.

Не сказал бы, что вопрос об оптимальной длине метода это умопомешательство. Просто приходилось поддерживать код, состоящий из методов длиной от 10 до 50 экранов кода. Разбираться в этом было сущим адом.
Длина метода, именование переменных, методов и классов, расстановка отступов и скобок — это реально важно и ко всяким модным методикам не имеет отношения. По сути это азы, без соблюдения которых хороший код нельзя написать.

Есть еще хуже, когда есть God Object на 10к строк.

Это тоже решаемо, но требует немалых усилий и попаболи.

Все в мире софта решаемо, но не все целесообразно.

Ну это да. Хотя вот такой класс в одной из библиотек внутри андроида фиксили (боюсь ошибиться, но...) начиная с 4.2 вплоть до 5.0, и только там пофиксили. Так что иногда может и целесообразно.

Если речь идет об оптимальной (а не must have) длинне метода то да,

Я имею ввиду, если оптимальная длинна метода 20 сктрок, но вот написал ты ф-цию на 28 строк, которая содержит законченный ф-ционал, ну и пусть и х*рен с ним.

Я видел альтернативный подход, когда вот только 20 строк и никак....
И получалось 2 метода на 20 и 8 строк и второй метод с назнанием что то типа — void secondPartOfSmthMethod(...)
... ну звиняйте, это уже лютый пи*дец.

Я думаю шо в кожного в житті колись був Legacy Code. Правда? І навряд багато хто був дуже щасливий з підтримки того коду. А стандарти придумані для того шоб всі розробники розуміли всіх. Ця стаття написана програмістом, якому реально в дупі шо там використовується. Але з точки зору менеджерів, їм треба знати шо відбувається в проекті і дивитись далі ніж відстань до монітору. Вони відповідальні за то, шо буде з проектом через місяць, пів року і тд. Кому потрібен найкрутіший програміст, якшо ніхто не знає шо він робить і шо казати тому хто платить гроші?

Все-таки надо понимать, что есть разные заинтересованные стороны. Для программистов все эти методики ни чего не дают, только мешают. Но для менеджеров позволяют сделать выполнение проекта предсказуемым, а управление более формальным.

Все зависит от людей, которые эти методики используют. Есть Agile и есть люди, которые ищут причины медленной работы в нем.

Отличная статья! Полностью поддерживаю каждое слово, кроме

У всех этих методик и практик есть одна общая беда — они написаны теоретиками.
Авторов аджайл манифеста уж точно нельзя теоретиками назвать. Бек, Мартин, Фаулер, Канингем это все опытные программисты, которые очень много сделали для нашей индустрии.

Кроме того, спешу заметить что методологии придумали девелоперы для девелоперов, а не длля менеджеров. То что этим чаще всего маются менеджеры это очень досадный факт.

Кстати, самая большая глупость которую можно придумать это сертификат скрам мастера, Кен Швабер придумал брать деньги за обучение скраму и туда в основном ходили менеджеры, я считаю что это банальный развод лохов на деньги.

Все верно. Многие действительно забывают что

«Done is better than perfect»

Все очень индивидуально. Представьте себе что по такому принципу делали например ЯП Java.

Плюсую. ... Я два дня хожу, думаю, как подружить nvm c githooks, а мне такие все модные: сторипойнтс, рядовой! Выходит больше 5? Разбей! Подружи n c g, потом v c i, ...
И эти «коучи»... Предел мечтаний любого ПМ: рассказываешь, как надо, ни за что не отвечая.
То-ли до них не доходит, то-ли они не будут принципиально (не для тебя ягодку растила), то-ли по каким иным причинам... Ты коуч? Несешь себя в проект(!), сидишь с командой и менеджером и разбираешься и улучшаешь. Только так. Сферический agile в зале на 200 (а лучше — на 1000, по разнарядке) — это круто для коуча, но это тупо вредительство для большинства проектов, которые оплачивает заказчик, а не выделяет финансы вице президент, ждущий годового бонуса.

Перша стаття від Юрія, яку прочитав повністю =))

Так же есть одна великолепная категория мошенников. Мошенники-"опровергатели". Одна другую кормит.

Если учитель указывает ученику на ошибку, является ли он мошенником? Тем более, что он кормится на незнании ученика.

Не нужно выдавать личный травматичный опыт за чужие ошибки. Если не знаешь, с какого конца браться за методологию, проблема не в методологии.

Не нужно выдавать личный травматичный опыт за чужие ошибки.

Правильно, в данном случае он показывает не чужие ошибки, а чужие враждебные намерения. В первую очередь тех, кто как «сертифицированный скрам-мастер» и т.п. хочет на этом поднять денег, независимо от необходимости его услуг для конкретного исполнителя.

Если не знаешь, с какого конца браться за методологию, проблема не в методологии.

100%, проблема в людях, которые её «внедряют».

Меня фейспалмит это «правило» брать ряд Фибоначчи для оценивания задачи. А что если я уверен, что задачи стоит ровно 4 сторипоинта? И самое ж интересное — никто обьяснить не может, ни один менеджер. Просто бездумно используют, потому что «так принято, это отжайл». В результате спринт или недоэстимейчен либо переэстимейчен.

Прикол estimation блэк-джека ещё и в том, что задачу оценивает вся команда, выдавая среднее количество часов. Тогда как выполнять эту задачу все равно будет один человек, чья скорость работы будет отличаться от среднего значения.

Прикол в том, что это не часы в estimation poker-е.

Значит запамятовал, последний раз сталкивался с этим poker’ом лет 6-7 назад.

Да и не удивительно. Вы ж пишете, мол, аджайл говно, потому что

Нужны ли все эти графики заказчику или разработчику? Методом дробления процесса разработки ПО на мельчайшие частицы мы придём к атому — работающий код. Это единственное, что должно волновать разработчика и заказчика. Всё остальное — суета сует, тщета и ловля ветра.
А в agile manifesto, тем временем —
Individuals and interactions over processes and tools
Working software over comprehensive documentation
А в agile principles, тем временем —
Working software is the primary measure of progress.

Сейчас вы перечитаете их, и окажется, что аджайл это как раз то, что нам надо, и то, чем только и стоит заниматься, а все остальное — суета.

Говорить и делать — это не одно и то же.
Манифест Agile сам по себе может и неплохой (как и речи Путина), но на практике он не соблюдается. Может, виной тому лишние сущности. Например, Scrum-master, stand-up миты или тот же TDD. Знавал я одну геймдев-контору, так они там по несколько часов в день стояли у доски и обсуждали как делать игру. В итоге проект конечно накрылся. А вот не было бы такого понятия, как stand-up meeting — может и не стояли бы у доски так долго.

А, ну то есть не методология, все-таки, виновата, да? Все-таки «один проект», а не индустрия?

Это как с туфлями.
Плохие туфли позволяют хорошему танцору танцевать, но удобными они от этого не становятся.

Знавал я одного человека, который писал статьи в том,в чем не разбирается.

Ни один менеджер объяснить не может, вот так тайна! Гуглить не пробовали? www.yakyma.com/...timation-scale-is-so.html

Согласна.
Кроме того, «ряд Фибоначи» берется для того, что бы если выпали задачи с одинаковыми оценками, было куда их «рассовывать» в зависимости от приоритетов. Странные у автора коммента ПМ, если не могут дать ответ на вопрос.

если выпали задачи с одинаковыми оценками

Так вы искусственно создаете ситуацию, когда есть одинаковые оценки. Единственная реальная оценка, это та, которую интуитивно чувствует тот, кто будет делать эту задачу. И я даже за то, чтобы давать дробные оценки, типа 8.25. И посмотрим как часто будут одинаковые оценки в этом случае.
Опять же все сходится к тому, что это нужно менеджерам, а разработчикам лишь мешает.

Давать точную оценку при серьезном недостатке информации — это самообман.

Да, если при этом нет двойных стандартов со стороны менеджмента — когда эстимейтим в меньшую сторону — это ок, а в большую — видим круглые глаза и стоны «почему так много»

В меньшую сторону от чего?

Не, в меньшую сторону к ближайшему числу из ряда Фибоначчи. Т.е. если я считаю что задача на 6 поинтов. Куда ее округлять? К 5 или к 8?

Смысл в ряди Фибоначчи в том, что при оценке есть только варианты 5 и 8. Ваше «6» — это и есть использование другой шкалы.

Так гуглить надо до того как принимать решение, а не только после того, как кто-то спросит «а зачем?»

Ну у вас был вопрос — вы бы и прогуглили.

У меня был вопрос не с целью узнать, а с целью понять понимает ли менеджмент зачем это нужно или же бездумно следует за «авторитетами»

Недалеко вы от него ушли. Один делает карго-культ, второй — антикарго-культ. А если б хоть один хотел разобраться — все было бы по-другому.

Но, кстати, лучше уж бездумно следовать авторитетам, чем бездумно им противоречить.

Всегда найдутся два авторитета, которые противоречат друг другу и можно следовать за любым бездумно, чтобы противоречить другому :)

Не связывайте story points с эстимацией в часах. Задачи оцениваются субъективно легче / сложнее в отношении уже оценённых ранее задач. ИМХО можно даже разделить на легко/нормально/сложно/очень сложно. Суть сохранится.

округляй в большую сторону, ты ж не виноват что фибоначчи такие, раз в них время приходится оценивать, то только так

Менеджер часто делает круглые глаза, когда округляю в большую сторону. Хотя мне иногда кажется, что в этом и суть этой шкалы) Чтоб пушить разработчиков округлять в меньшую сторону)

в меньшую сторону пусть глаза округлит, ты же не успеешь за меньше чем надо, округлять в меньшую сторону нельзя, если для тебя это почему-то не приемлимо, дроби задачу чтобы она всегда влазила, либо дроби до упора, чтобы влазила с минимальное число сторипоинтов, вообще если есть эстимейты со сторипоинтами, то это скрам, а теперь вопрос откуда менеджер? уволить нафиг, он ломает идеологию скрама

Меня фейспалмит это «правило» брать ряд Фибоначчи для оценивания задачи.

Может, кому-то непривычно. На самом деле я ещё со школы убедился, что ряд Фибоначчи как раз крайне удобен для психологического оценивания значения практически любого количественного параметра. Мы тогда даже развлекались шутками типа: берёшь приближение к какому-то значению числом из обычного ряда Фибоначчи, и переназываешь его:
3 -> k-2
5 -> k-1
8 -> k
13 -> m
21 -> n
34 -> n+1
55 -> n+2
родилось это из двух шуток «да это объявление тут уже N+1 год висит!» и «возьмём K самолётов... нет, K мало, лучше N».

Разумеется, пользоваться числами типа 34, 55, 89... неудобно, на практике они начинают превращаться в 30, 50, 90. Но это уже другой вопрос — а общая шкала в целом пригодна.

Подписаться на комментарии