×Закрыть

Agile в аутсорсинге не работает

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

Так, на недавней встрече украинских аджалистов Agile Pizza (я сам не был, но следил в соцсетях, и мне пересказывали свидетели) говорилось с аргументацией о том, что, мол, «эх, жаль, agile не работает в аутсорсинге».

Случайное фото встречи. Я не знаю, кто именно из докладчиков утверждал, что «agile не работает». Быть может и скорее всего, эта фраза вообще вырвана из контекста

Agile — странная вещь

Я еще помню 12-15 лет назад, как agile не работал совсем.
Затем 5-7 лет назад — о том, как он не работает в банках.
Потом в гейминге и гэмблинге.
Совсем недавно — о том, как в госструктурах его нет и не может быть.
Что же не так с этим аджайлом? Он всё время где-то не работает.

Может, позвонить в ЖЭК и вызвать мастера? Или вернуть по гарантии, пока не поздно?

Оказывается, agile не работает не только в аутсорсинге

На прошлой неделе один немецкий agile-коуч мне сказал (и об этом также есть скандальная статья), что agile не работает в немецкой культуре из-за любви к предсказуемости. Жаль, что ребята из Zalando, jimdo, XING, Flixbus об этом не знают.

Французы считают, что из-за своей любви к иерархии и сплетням, agile-культуре на одних круассанах не прорасти.

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

Зато все, как один, соглашаются с тем, что где-нигде, а в Скандинавии аджайл работает на ура. Там он сокультурен их плоскому менеджменту, личной ответственности и трудолюбию. Почему же мне было так тяжело стартовать Скрам в 2004 в одном датском проекте? Тогда на старт первого спринта ушло полтора года!

Здесь что-то не так. Не находите?

В аджайле не работает не более четырёх вещей одновременно

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

  1. Менеджеры давят на народ процессом, ограничивая свободу улучшений.
  2. У команд не выходит (каменный цветочек) выпускать хоть сколько-нибудь рабочий продукт, хотя бы раз в месяц.
  3. Заказчики далеко, и им на нас наплевать.
  4. Менеджеры строят планы, не выходя из home-офисов и декретов.
Что ж. Так бывает. Что из этого вызвано именно аутсорсингом? Возможно, как минимум третье. И отчасти — первое.

Продакт Оунер как часть контракта. Pourquoi pas?

Не так давно я слышал историю о том, как сиклумовские ПМы, годами оттачивая контракты, смогли наконец-то там чётко прописать роль владельца продукта со всеми сопутствующими обязательствами. И они не только прописали её в новые контракты, которые используют сейлзы, но и обновили контракты существующих аккаунтов. Пурква бы и не па?

Таких историй много. Более громких и менее громких.

То тут, то там я слышу, как заказчики распускают QA-отделы на Филиппинах и в Индии и нанимают тестировщиков-автоматизаторов в свои nearshore-ные команды. Пурква бы и не па, в конце-то концов?

А может, мы смотрим не в ту сторону бинокля?

То тут, то там практика continuous delivery становится реальностью...
Заказчики соглашаются с наймом локального командного коуча...
Кто-то на выходных настраивает первый раз за историю компании сервер сборок...
Где-то впервые за года разработчик и тестировщик вместе пишут тесты...
В офис тихо заносится первая маркерная доска...

Scrum is the art of possible

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

Нет, эти наноизменения — не финальная победа. Это маленькие инкрементально-итеративные победки, победочки и победульки.

Но разве не в этом состоит суть agile-мышления? Понемногу, где можно и когда можно, менять свою среду своими руками.

Очень давно, на моём первом тренинге для Скрам-мастеров (2007 год), тренер сказал: «Scrum is the art of possible». Это очень важная фраза. Она важнее всех фреймворков и ролей. Это — делать то, что сейчас возможно, несмотря на всё остальное, что (ещё) неподвластно.

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

Это про то, чтобы говорить «В этом году (квартале, спринте) мы чуть более agile» вместо того, чтобы сдаться, сказав: «Тут аджайл не будет работать».

C’mon guys!

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

Аgile/Scrum коучи это секта какая-то как по мне, люди собрали несколько хороших практик которые существовали всегда и назвали это отдельным словом. При этом они говорят что только это хорошо и что это подойдет абсолютно всем. Большинство адекватных и опытных ПМов и лидов и так применяют такие подходы в определенных ситуациях и называется это у них не agile, а здравый смысл. Все эти коучи, скрам мастеры и тренеры — это просто монетизация человеческих страхов и фальшивая возможность потом отгородиться от проблем.

В дополнение хороший тред на тему почему в гугле понятия agile не существует: www.quora.com/...​evelopment-to-be-nonsense

Не в обиду автору, но это пожалуй худшая статья из прочитанных мной в 2017 году. Не по смыслу написанного (не имею большого опыта чтобы говорить о том работает аджайл или нет), а по структуре и подаче. Подзаголовки на три коротеньких абзаца/пять предложений, какие-то смехуечки и «сарказм» первые 80% статьи и концовка ни о чем. Имхо скрам-мастер 80-го левела должен быть более красноречив.

«Scrum is the art of possible». Это очень важная фраза

Сорри, но это буллшит. Скрам — это набор практик, не больше и не меньше.
Подобные общие фразы, дескать, он вездесущ и всемогущ, звучат от теоретиков и «евангелистов» по вполне понятным причинам. Не нужно приписывать ему то, что существовало и применялось раньше. То же самое касается Agile вообще, XP, DevOps и прочих полезных в целом практик.

Время универсального ДОУ-комментария.

Аджайл — это, конечно, чтобы меньше платить. Это чтобы не казалось, что там обычная галера а типо все модно и современно. Это чтобы сэкономить. Это хипстерские понты для приезжих, падких на яркие лозунги. Это вместо повышения, так же дешевле — теперь у нас аджайл. Болтуны бесполезные, а наняты за деньги, которые могли выплатить девелоперам. Делать надо не так, это все неудобно. Это только для придурков/инфантилов/студентов. Работать надо нормально, тогда никакой аджайл не нужен будет. У адекватных людей и так все нормально, аджайл не нужен. Гроб гроб кладбище пидор.

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

ЗЫ:
И нормально Agile работает в аутсорсинге ;)

81 комментарий

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

Методология работает с 50х годов. Её применяют 100 из 100 успешных компаний в ежедневной практике. Эджайл... это красиво звучит, но без методологии — не работает. Внезапно.

Аффтар, ты не компетентен.

Почему? Вроде как agile-coach

Почему? Вроде как agile-coach

Вот хотя бы потому что «agile-coach»

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

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

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

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

Походу у Альоши кризис заказов на курсы. Алексей ты на этом рынке уже не первый год идолжен был понять что тут не заработать коучингом. Мож вернёшься на галеры? Твоё весло ещё тёплое.

Это про то, чтобы говорить «В этом году (квартале, спринте) мы чуть более agile» вместо того, чтобы сдаться, сказав: «Тут аджайл не будет работать».
Хм, вааще-то я за аджайл всеми конечностями... но именно за его подходы, а не конкретный СкРАМ, например. Вот ... дык есть хорошая английска поговорка: «Луччее — враг хорошего». Это про то, чтобы понять какая у нас цель: сделать продукт или таки внедрить аджайл :)
Заказчики соглашаются с наймом локального командного коуча...
Какой прелест :) Ой хачу такого заказчика, сам локальным буду :))

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

Однако в прошлой своей статье (dou.ua/...​les/agile-in-outsourcing ) Вы говорили, что

«В следующей статье я расскажу о том, как просто и красиво визуализировать рост продукта и таяние бюджета в Excel. Таким образом, чтобы на регулярных ревью вы не только смотрели на продукт для его адаптации, но и поднимали смертельно важные вопросы пересмотра рамок проекта: скоупа, времени и бюджета.
И всё это внутри всё тех же fixed-price продуктов.»

Надеюсь, у Вас еще найдется время и желание вернуться к этой теме.

А ведь каких-то лет 5 назад такая б статья легко набрала бы 1000+ комментов......

Не в обиду автору, но это пожалуй худшая статья из прочитанных мной в 2017 году. Не по смыслу написанного (не имею большого опыта чтобы говорить о том работает аджайл или нет), а по структуре и подаче. Подзаголовки на три коротеньких абзаца/пять предложений, какие-то смехуечки и «сарказм» первые 80% статьи и концовка ни о чем. Имхо скрам-мастер 80-го левела должен быть более красноречив.

Це кроссопост з блогу Кривицького — www.krivitsky.com/...​-аутсорсинге-не-работает
Там є і більш змістовні статті.

В чем-то согласен. Мысли скомканы, текст сумбурно написан. Думаю, что статью стоит переработать.

Статья была бы актуальна лет 10-15 назад, когда надо было «с боем» внедрять аджайл практики (не абстарктный «аджайл», а именно практики улучшающие процесс разработки).
Но вот в 2017-м году — это очередная ПРная статья очередного «коуча», который все еще хочет кушать.
И вот вам сюрприз: Иногда аджайл (в большинстве его проявлений) не работает. И внедрять его не надо, потому что ... wait for it ... в некоторых случаях лучше работают другие подходы, а иногда другие подходы работают достаточно хорошо, чтобы ни у кого не возникало желания их менять.
.

эх, жаль, agile не работает в аутсорсинге

У срам коучей есть такая мантра «дефинишн оф дан». Вот вы перед написанием статьи поинтересовались тем что вложил автор этих слов в понятие «работает»? Судя по тексту («Выходит, что в ней может не работать не так уж много частей»), ответ дует «нет».

А зачем тестировщику и разработчику вместе писать тесты?

Секта Свідків Аджайлу

Автор предлагает внедрять аджайл через боль и страдания, что-ли? Аджайл ради аджайла?

аджайл ради боли и страданий

Ради коача.

Agile — это 4 очень общих фразы, говорить, что они работают или нет — чаще всего лить из пустого в порожнее.

Хотя одна из фраз Customer collaboration over contract negotiation действительно меньше применима к Аутсорсингу. Потому что аутсорсинговая разработка это не всегда WIN-WIN.

..зараз тільки поскрамлюсь швиденько і потім відпишусь..

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

Время универсального ДОУ-комментария.

Аджайл — это, конечно, чтобы меньше платить. Это чтобы не казалось, что там обычная галера а типо все модно и современно. Это чтобы сэкономить. Это хипстерские понты для приезжих, падких на яркие лозунги. Это вместо повышения, так же дешевле — теперь у нас аджайл. Болтуны бесполезные, а наняты за деньги, которые могли выплатить девелоперам. Делать надо не так, это все неудобно. Это только для придурков/инфантилов/студентов. Работать надо нормально, тогда никакой аджайл не нужен будет. У адекватных людей и так все нормально, аджайл не нужен. Гроб гроб кладбище пидор.

А теперь попробуйте доказать, что это всё неправда.

Той же аудитории, которой был направлен ваш предыдущий комментарий.

ничего не понял, но поддержал из-за последнего предложения

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

Та шо ж не надо, когда это первая строчка аджайл манифеста?

Стоять на стендапе тоже не всем удобно. Но церемонию тщательно соблюдают

Скажите, вы таки из тех, кто не отличает скрам и аджайл?

Как можно не отличать элемент множества от собственно множества?
И как это связано с тенденцией механически повторять ритуалы?

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

Типа да, но на практике менеджмент любит ритуалы и аджайл вырождается в набор правил, а не «как удобно»

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

Насчет того, что получается «на практике» — я не устаю этому поражаться. Ну я понимаю можно жаловаться на теорию, она к вам, некоторым образом, внешняя. Но практика — это дело ВАШИХ рук. Жаловаться на практику — это жаловаться на себя. Это уже не кто-то там что-то напридумывал, на кого жаловаться?

Это как люди, жалующиеся на фейсбук — мол, ну что там интересного, только тупые шутки, картинки с котиками, лежалые шутки и ярмарка тщеславия в виде фотогалерей из отпуска. Но родные мои, вы же понимаете, что фейсбук показывает вам то, что постят ВАШИ друзья? И что вы САМИ собираете себе ленту и решаете, что смотреть? Как можно пенять на зеркало насчет того, что рожа крива?

Остапа/Евангелиста понесло

Никого никуда не понесло. Алексей 100% прав. Проблема не в теории, а в практике.

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

вы факты-то выкладывайте, а то сейчас выяснится, что Рабинович напел

Люди vs процессы, первый принцип, а затык уже здесь в 95% случаев. Приветствовать изменения даже когда разработка далеко продвинулась — это вообще влажные мечты продажников. Это принимается как неизбежное зло, но уж никак не приветствуется.

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

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

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

Алекс, это пустой разговор. Вы не видели аджайла, но мнение имеете. Фактов я тоже не слышу, только «в любой конторе» да «я не встречал». Еще и манифест собрались дополнять. Большая мушка очень, Алекс, спилить бы...

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

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

Никого никуда не понесло. Алексей 100% прав. Проблема не в теории, а в практике.

Что, правда? Очевидно, что есть 1000 и 1 возможность сделать неправильный agile. 1000 и 1 способ заставить его неправильно работать.
И это все будет отлично согласоватся с теорией. Просто из-за пробелов в теории, которые подразумевают, что все будут делать вещи так, как их предпологал автор.

Проблема то именно в теории. Она слишком пуста.

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

Точно так же можно говорить об архитектуре, код стайле, выборе фреймворка, составе команды и характерах разработчиков.
Из «маємо те, що маємо» нужно сделать продукт.

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

может я не до конца понимаю аджайл

Сомнения — золото! Читайте манифест, сверьте принципы, предлагайте изменения, берите процесс в свои руки! People over process не работает, если people не хочет ничего менять сам.


Сейчас, я тебе расскажу как сделать охуенный аджайл.

1. Слушай меня. Для начала отодвинь от себя макбуки—хуюки, отбрось айфон, выключи телевизор. Пойди на сайт и освежи манифет и принципы. Сними с себя джинсы дикваред, модный джемпер и очки без диоптрий. Трусы сними нахуй. Поболтай хером, почувствуй вкус свободы, ветра и солнца. Замути скрамборд, хуй с ним для первого раза сойдет стенка и стикеры, но потом, ты слышишь, заведи себе нормальный, блядь, аккаунт в Трелло. Набросай первый беклог. Передвинь пару стикеров, те, что поважнее — наверх. Ага, чувствуешь как начало действовать?! АГАГА БЛЯДЬ! Ты же по аджайлу разрабатываешь!! Не вотерфолл, ебать его в сраку, не скрам, будь он неладен! Аджайл!111

Ебашь его так, как говорит тебе душа, как просит тело! Короткий спринт — это такой как нужен тебе, задач бери столько — сколько хочется!! Оценки не имеют значения! Аджайл, он как секс — ты решаешь каким ему быть!

вот какойто такой «охуенный» аджайл я и видел

В идеале-да, но чаще всего все подстраивается под клиента. Если подход — «Какие юзер стори? Я вам в скайпе все расскажу» навязывается клиентом, то очень сложно убедить его двигаться по какой-то конкретно методологии.

«Scrum is the art of possible». Это очень важная фраза

Сорри, но это буллшит. Скрам — это набор практик, не больше и не меньше.
Подобные общие фразы, дескать, он вездесущ и всемогущ, звучат от теоретиков и «евангелистов» по вполне понятным причинам. Не нужно приписывать ему то, что существовало и применялось раньше. То же самое касается Agile вообще, XP, DevOps и прочих полезных в целом практик.

Вас могут выгнать из церкви за такое

и «двушечку» (к) (тм)

«Случайное фото встречи. Я не знаю, кто именно из докладчиков утверждал, что „agile не работает“. Быть может и скорее всего, эта фраза вообще вырвана из контекста» — Смысла написания статьи не понял. Много пафоса и ни о чем. Точно тут написали — секта какая-то...

Иди себе работай, так нет сам процесс работы назовут каким-то западным словом, устроят курсы, напишут книги и проведут конференции. Раздадут по кругу сертификаты друг другу и вот это вот все.

Нельзя так просто взять и начать работать. :)

не раздадут, а продадут)

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

ЗЫ:
И нормально Agile работает в аутсорсинге ;)

Присутствуют евангелисты

Еваджилисты :)

— Команде пофиг на проект, да и вообще пофиг!
А вот это уже следствие четырех первых пунктов.

TLDR
Скрам уж точно не работает в аутсорсе. Про КанБан, FDD и Crystal я бы еще поспорил.

Dave Thomas states (www.youtube.com/watch?v=a-BOSpxYJ9M) that Agile is Dead and I agree with him. Furthermore, Erik Meijer argues (www.youtube.com/watch?v=2u0sNRO-QKQ) that Agile is a cancer that we, professional software engineers, should eliminate from the industry.

Thanks for these links, but I suggest to publish a text version link first, because most programmers prize their time, and text is much faster to be read.
Dave Thomas, Erik Meijer, respectively.

Clickbait. Громкие заголовки, а внутри пшик. Первый выбирал конченых консультантов. Второй просто перепутал agile и waterfall.

Знатный может получится срачь, сбегаю-ка я за попкорном!

Аgile/Scrum коучи это секта какая-то как по мне, люди собрали несколько хороших практик которые существовали всегда и назвали это отдельным словом. При этом они говорят что только это хорошо и что это подойдет абсолютно всем. Большинство адекватных и опытных ПМов и лидов и так применяют такие подходы в определенных ситуациях и называется это у них не agile, а здравый смысл. Все эти коучи, скрам мастеры и тренеры — это просто монетизация человеческих страхов и фальшивая возможность потом отгородиться от проблем.

В дополнение хороший тред на тему почему в гугле понятия agile не существует: www.quora.com/...​evelopment-to-be-nonsense

В дополнение хороший тред на тему почему в гугле понятия agile не существует

Насколько я понял этот тред, они согласны со многими принципами в основе, но не согласны с Agile Manifesto. Причём несогласие во многом формальное — на акцентах или отдельных понятиях. Потому что вот этот пассаж:

> Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to «customers», so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to the customer.

говорит только о том, что они не производят «ремап» понятия customer в этом случае (а кастомером такого сложного внутри продукта должен выступать внутренний заказчик, а не клиент поисковика; более того, этот клиент вообще не может сформулировать user story и поэтому не является клиентом для разработки). То есть это вообще ни о чём, согласовать видение они и не пытались.

Большинство адекватных и опытных ПМов и лидов и так применяют такие подходы в определенных ситуациях и называется это у них не agile, а здравый смысл.

Вообще-то формализация здравого смысла — на уровне образцов и пожеланий, конечно — является безусловно положительной практикой. Некоторые организации просто выпускают документы с заголовками «best current practice». Они неправы?

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

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

Некоторые организации просто выпускают документы с заголовками «best current practice». Они неправы?

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

А кто называет себя единственными носителями правды и утверждают, что изобрели все практики?

Секта скрама и аджайла

И что, и ссылка/цитата найдется?

говорит только о том, что они не производят «ремап» понятия customer в этом случае (а кастомером такого сложного внутри продукта должен выступать внутренний заказчик, а не клиент поисковика; более того, этот клиент вообще не может сформулировать user story и поэтому не является клиентом для разработки)

Есть куски кода (например, написать с нуля wifi driver), которые не запустятся ни в каком виде несколько месяцев с начала работы над ними. Такое ну никак не является deliverable в процессе написания, и команде, это пишущей, нечего и некому деливерить в процессе. Соответственно, идея микроциклов неприменима.

Есть куски кода (например, написать с нуля wifi driver), которые не запустятся ни в каком виде несколько месяцев с начала работы над ними.

Хм... предположим, мы о клиентском драйвере. Тогда можно последовательно реализовывать:
1. Опознание адаптера, определение его версии, свойств.
2. Первичное конфигурирование адаптера.
3. Включение выслушивания сигнала, получение (пусть и в нескорректированном виде). Тут уже потребуется (как и для всех последующих шагов) какое-то удалённое устройство, с которым можно общаться, заведомо зная, что оно рабочее.
4. Написание поддержки фрейминга WiFi, сборки и разборки пакетов целевой нагрузки (этот пункт можно даже независимо от остальных делать и тестировать, если устаканены интерфейсы).
5. Выслушивание анонсов SSID, отдача принятых клиентской стороне.
6. Подключение IP слоя (хотя бы самым простым способом, без очередей, с дропами по любому поводу). (Подключается результат пункта 4.)
7. Подключение переповторов и подтверждений.
8. Шлифовка логики очередей.
9. Подключение других протоколов...

У меня нет опыта с WiFi драйверами, но есть с другими коммуникационными, так что, думаю, сильно не напортачил в общей канве. Но она вполне соответствует логике, что по завершению каждого шага получаем нечто, что можно запустить и увидеть, что оно работает в пределах предполагаемой функциональности. Местами слои можно тестировать отдельно от остального (как фрейминг).
Я где-то тут крупно ошибся, и это в таком виде не работает? Если да, то где именно?

Пункты 2-4, по сути, не тестируемые. Как узнать, что адаптер корректно сконфигурирован, если ты не умеешь обмениваться с ним данными? Как узнать, что пакет данных получен корректно, если невозможно связаться с другим устройством, так как мы еще не поддерживаем стандарт.
Ну и еще надо закладывать время на разработку архитектуры в самом начале, потому что без этого будет грустно. А если у нас разработка архитектуры (и интерфейсов, исходя из нее) предшествует остальному — пахнет водопадом.

Пункты 2-4, по сути, не тестируемые.

Ну, это IMHO чересчур радикально. Пункт 4 вообще может быть проверен по каким-то образцам, или по контрольной реализации другим исполнителем (обычно разные люди делают разные баги).

Про это:

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

Предположим идеальную чистоту радио (для WiFi это критично) — например, реализуется направленными антеннами.
Тогда разработчику драйвера не обойтись без генератора эталонного сигнала и/или приёмника, который умеет расшифровывать и показывать полученное. Потому что иначе можно и в завершённом, вроде бы, коде искать тупейшие баги годами. А с таким эталоном это превращается уже во вполне подъёмное действие. И оно же решает пункты 3 и 5.

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

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

Да, надо. Но в случае такого драйвера его внутренняя часть, по идее, достаточно прямолинейно архитектурируема. Хотя вот участки логики типа «у нас тут какая-то слишком зашумлённая фигня принялась, лечим эмпирически» могут подпортить картину — но только в пределах своего слоя.
А внешняя часть зависит от ОС, а не от устройства, и сводится в основном к тому, какие структуры описывают пакеты и пинки сторон друг друга на тему «забери же наконец эту очередь».

А если у нас разработка архитектуры (и интерфейсов, исходя из нее) предшествует остальному — пахнет водопадом.

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

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

Увы. Если мы говорим о нескольких месяцах, то в современном мире, для большинства устройств в разработке:
1. Раз 5 сменится прошивка адаптера и раза 2 — какие-то существенные мелочи с новыми аппаратными ревизиями. Каждое изменение будет предполагать, что что-то надо иначе настраивать. Есть особенно любимые железячниками ходы типа «мы перешли на другого поставщика травы PLL, надо изменить методы заполнения регистров для него» (а вшивать это в прошивку они не захотят — зачем, если это легче сделать драйвером? а то, что некоторые комбинации частот могут просто его сжечь — их не пугает).
2. Пункт 1 был по собственным внутренним причинам, но к нему регулярно добавляются ситуации типа «ребята, вы чем думали, если хотите, чтобы мы записали 21 в четырёхбитное поле» и судорожное от железячников «ойблин, такида... сейчас будем что-то думать» и потом срочные меры типа «мы этот лишний бит перенесли в регистр 23» (и начинается срочная правка — вместо прямой записи в регистр 23 переходим на чтение-модификация-запись). Или вдруг оказывается, что в каких-то режимах надо вставлять намеренные задержки, потому что оно тормозит...

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

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

А поводу

продукт непродаваем и бесполезен до завершения

тут, конечно, личное, но я предпочитаю, чтобы результат хотя бы каждой недели был ощупываем хотя бы в виде «о да, он теперь начал моргать по-новому — значит, работали не зря». И таких разработчиков реально много. Это ещё одно, на что бьёт Agile — когда видишь результат сразу, просто легче думать о происходящем — во всех смыслах (оценивать, планировать...)

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