Комментарии 51
У заказчика нет ресурсов на сбор требований. Ну скажем, нет ответственного с его стороны. Так что ваша ссылка не релевантна.
Самый логичный способ запилить, что-то и выкатить, а потом слушать, что не так и как это поправить. Я участвовал в нескольких таких проектах, и когда менеджмент понимал, ситуацию, то мы успешно использовали agile.
Кстати, переписать всё с нуля не такая уж большая проблема, если понятно, что писать и уже отработана технология.
Переписать с нуля, к примеру, систему Документооборота гос.струтктуры не очень большая проблема??? (мы же говорим о больших системах).
должны аналитики
Которые должны с кем-то общаться. Со стороны заказчика должны быть ответственные лица, которые бы отвечали на вопросы аналитиков и устраивали митинги. Взаимодействие с аналитиками со стороны заказчика — это куча денег.
Со стороны заказчика всё это надо организовать — это может быть очень и очень сложно. Аналитику должен отвечать компетентный специалист, который ещё и конкретно отвечать может не хотеть, ибо это ж ответственность. Короче, куча проблем со стороны заказчика, которые подрядчик не может толком решить.
Agile очень помогает при недостатке информации, все эти частые релизы и жёсткие сроки спринтов позволяют по частям выжимать из клиента требования. Ну и за каждый этап работ легче получать акт, ибо релиз есть, есть, стори сделаны, сделаны. Если менеджеры не круглые дураки, то компания не будет работать бесплатно, а просто остановит разработку на данном проекте до следующего спринта.
Для этого есть другие роли в проекте. Это может быть Продакт или Проджект менеджеры. Может быть высшее руководство подрядчика — исполнителя.
Задача стоит в другой плоскости — организовать процесс. Не стоит эту проблему решать препирательством исполнителей.
Если есть контракт, то в нем обычно прописывают в обязательствах заказчика пункт о своевременном предоставлении необходимой информации. Если контракт не исполняется, то руководство исполнителя направляет руководству заказчика претензию о неисполнении контракта и это в большинстве случаев действенно. Поскольку руководству заказчика нужен продукт и не нужны неустойки.
That is, while there is value in the items on the right, we value the items on the left more.
Вы же восприняли слово over / важнее как «вместо».
По пунктам примерно так:
1. Individuals and interactions over processes and tools. Это не «пренебрежение регламентами», это «если команда считает, что будет лучше работать с другим регламентом и инструментами — надо менять регламент и инструменты, а не давить на команду»
2. Working software over comprehensive documentation. Это просто утверждение, что ситуация «работающий продукт с не совсем полной документацией», лучше чем «неработающий продукт с полной документацией». Там нет утверждения, что документация не нужна.
3. Customer collaboration over contract negotiation — это не «контракт не нужен». Это «если в процессе разработки оказалось, что в контракте закреплены нереальные, противоречивые или устаревшие требования — то стоит руководствоваться реальными требованиями, поговорить с кастомером, поменять контракт. И менять контракт. И заодно „надо активно пинать кастомера на предмет изменения требований“. А не дописывать без обсуждения промежуточных результатов до самого релиза.
4. Responding to change over following a plan — это не про техническую возможность внесения изменений. И не про отсутствие плана. А про то, что если ситуация поменялась и идет вразрез с планом — то стоит учесть изменения. А не слепо следовать плану.
Сам по себе Agile Manifesto — это „манифест здравого смысла“. В нем достаточно очевидные утверждения, которые не накладывают жестких ограничений на процесс. Можно делать водопад, но при этом следовать принципам Agile. Можно делать SCRUM, но при этом не следовать Agile почти никак.
Можно читать так, а можно и ровно наоборот. Главное, чтобы Вы могли это подкрепить своим взглядом на «здравый смысл».
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.это такая же часть манифеста, как и предложения с «важнее». А не какое-то дополнительное «личное толкование». Нужно очень сильно постараться при переводе, чтобы превратить «мы не отрицаем важность согласования условий контракта» в «контракт не нужен».
Планируется добавить часть про SAF (scaled agile framework)?
Хотелось бы увидеть предложения по использованию agile в крупных интеграционных проектах более детально. Планируете?
Про SAF пока не планировал писать.
И что даже еще важнее, так это то, что в 1970-х еще не существовало средств версионирование кода, как таковых (да и в 80-х пожалуй тоже, потому что CVS появилась в 1990-м). А отсутствие в процессе разработки даже CVS влияет на него намного сильнее, чем Waterfall vs Agile.
Я с 1980 года примерно перфокарты почти не трогал. А уже в середине 80-х все машины приходили как минимум оснащенные ЕС-7066, а потом ЕС-7927. Я говорю про свою реальность (в частности это Москва — хотя наблюдал и Миасс, например, и Питер).
Хотя другую реальность я исключать конечно не могу — в конечном счете, я общался с коллегами, а это был Минобщемаш, и вряд ли он был самый бедный :)
Айтишники слишком много получают, при этом их тяжело контролировать и отчитываться верхним смотрящим о прогрессе, поэтому давайте изобретём потогонную систему, пусть они делают что-нибудь, и побольше, мы будем отчитываться о прогрессе, а если что то надо переделывать — назовём это издержками метода.
5. Как не надо использовать Agile
Не менее важный раздел, возможно ради которого и затевался весь анализ.
Много проще.
Agile эффективен тогда, когда в этом есть потребность у бизнеса.
Agile — не про ИТ. Agile — про бизнес.
Про то, как вести бизнес в условиях неопределенности и непрерывных изменений во внешней среде.
Строишь дом? Строительство относительно прогнозируемая деятельность. Никакой agile не нужен.
Продаешь свои услуги через свой сайт или свое мобильное приложение? Эта область непрерывных изменений. Без agile твой бизнес весьма вероятно проигрывает конкурентам и умирает.
Согласно идеям Александра Прохорова из книги Русская модель управления можно сказать, что «наш» человек лучше всего работает, когда «враг у ворот» и надо «сплотиться и вытаскивать проект из жо». А почему проект там оказался и почему изначально работа не делалась как следует — ну, у нас так принято, не спрашивайте.
Согласно здравому замечанию о том, что если на проекте хаос и ты постоянно принимаешь решения — ты системный архитектор, братан, ты горишь, у тебя лихорадка ожидания успеха! А если на проекте всё упорядоченно, и «просто надо всё сделать», то — ты просто унылый гребец, ты не системный и не архитектор, фу таким быть, фу.
Получаем работника, который хорошо работает только во время кризиса. А раз таких работников много, и их modus operandi идентичен, то получаем целый коллектив, который результативен только во время кризиса.
Предложим этому коллективу свободу agile. Нет документов — сами решите, нужны ли они вам. Нет тест-кейсов (бо нет требований) — ну и что, ни тест-кейсов, ни тестировщиков не будет, ведь они не нужны, ведь люди и их взаимодействие важнее общения с тестировщиками — и так далее, по кругу. Получается группа людей, которые работают в условиях постоянного кризиса, им объясняют общую задачу, их регулярно снабжают баландой и ради их же безопасности не выпускают за периметр зоны, а они в ответ ракеты в космос запускают и радеют за неведомый им «бизнес заказчика».
Только упомянутый вами аврал и спасает.
И один из них — попробуйте набирать в команду людей со схожими целями и ценностями.
Например: наберите семейных мужиков с ипотекой и детьми. По итогам квартала: мы выполнили план и заработали? Вот вам еще 2 оклада.
Удивитесь насколько разработчики могут оказаться людьми «про бизнес»)
Пожалуй только не соглашусь про
«команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. „
Иногда так бывает, что даже “проработав архитектуру» (в случаее ее неочевидности) — всё-равно с появлением новых требований может возникнуть неприятная ситуация и что-то придется переделывать, потому что теперь всё по другому — но тут уж никакая методология от неизвестности будущего не застрахует.
Субъективно для себя я утвердился во мнении, что если уберечь команду от игр в «я-у-мамы-архитектор» и от того чтобы на ранних этапах слишком всё оптимизировать — потом получается легче принимать изменения т.к. мы не завязали себя в узел + меньше привязанность к прошлым решениям т.к. на них было потрачено меньше ментальных усилий.
А в остальном: нас спасет только стремление к осознанности и здравому смыслу + общие цели и ценности.
Поэтому, когда мне заказчик говорит "… разработку ведем только по гибким методологиям" я ему вот прям сразу и отвечаю «без вопросов, дорогой, за твои деньги, да по T&M, я буду работать хоть вприсядку с подвыпертом, только плати, уважаемый».
Приблизительно 99,9 заказчиков после слов о T&M резко перестают хотеть гибкие методологии.
Спасибо, отличный пост. Мне, большому стороннику Agile разработки, очень понравилось.
Почти все по делу (про значение слова «важнее» вам уже выше написал пользователь PashaPash).
Очень важно понимать, что Agile разработка — это сложно. Сложно предугадать, какие требования могут измениться, а какие скорее всего нет. Где нужно написать документацию, а где можно обойтись. Когда можно додумать самому, а когда лучше уточнить у заказчика. Надо быть опытным профессионалом, чтобы «работать без страховки».
Надеюсь статьи, подобные вашей, помогут ит-сообществу (в последнее десятилетие изрядно пополнившемуся неофитами) подходить к выбору методологии осознанно, а не только гнаться за модой
Так и вырастают аналитики самоучки — «дичка у дороги», которые не умеют: ни общаться с заказчиком ни формировать требования.
Пытаюсь с этим бороться по мере сил. Вот тизер моих лекций по курсу подготовки системных аналитиков мой YouTube канал. 15 роликов на эту тему, лишь затрагивает основные аспекты профессии. Для качественной же подготовки специалистов, нужны тренинги и практика.
наподобие того, как у нас попадаются заказчики, когда мы пытаемся получить с них требования, а они говорят, например, «ну нарисуйте нам хоть какую-нибудь форму, мы посмотрим, тогда и скажем, что нам надо». Т.е., абстрактное мышление стремиться к нулю, хотя речь идет об их повседневной деятельности.
так же и сами разработчики. пока не запрогарммируем сами хоть что-нибудь, вообще не сможем понять, что надо-то было => работаем итерациями. а на самом деле, может надо было просто, все же суметь разобраться в предметной области (конечно, заранее все не предусмотришь, и гибкость должна быть и в методологии, но не такая, что начинаем делать чебурашку, а в итоге переделываем в слона. просто сразу не поняли, что надо слона именно делать).
Как пример, пришлось мне полгода где-то поработать в стартапе, где вот прям скрам (не знаю, на сколько именно соответствовал процесс скраму). попал туда уже, когда им через пару месяцев надо было сдавать проект, а у них вопрос стоял, что все это надо переписать. Делался до этого проект, как понял, почти год. Хотя, на самом деле, ничего там инновационного, с точки зрения функционала не было. впечатление было, что просто не было у команды опыта. Эджайл тут никак не помог.
Может я ошибаюсь
Вторая — уверенность что все можно заранее просчитать и описать в ТЗ. К сожалению, нет. Что предпочитают ваши клиенты, что им мешает, что можете вы предложить им в качестве решения — детали выясняются только в процессе непосредственного взаимодействия, как следствие, работаем над улучшением короткими итерациями.
Короткие итерации не везде применимы, соответственно agile там не используем.
youtu.be/0wRejqe6n9U часть 1
youtu.be/MgMuGvSiZuE часть 2
"Составить требования заказчика" как-то дико для меня звучит. Почти как "Изя, у мужчины должно быть своё мнение и сейчас мама твоё тебе расскажет". ) Вы, наверное, про сбор требований и ограничений? Agile предполагает работу в условиях высокой неопределенности, когда полные требования просто невозможно собрать заранее, когда они меняются по ходу дела после получения обратной связи
В зависимости от масштаба проекта в процесс могут подключаться бизнес-архитекторы с опытом автоматизации в нужной отрасли, направлении. Об этом у меня есть ролики на канале www.youtube.com/watch?v=hXNt_-j-6zo&list=PLoi3EglG5oUoAAQZ975PPRiiv9HvhRKw0&index=11
Если возможно описать требования клиента до начала работ по собственно разработке продукта, то аджайл просто не нужен. Он для тех ситуаций, когда это невозможно, когда, например, заказчик хочет создать новую отрасль или взорвать существующую вопреки мнению экспертов "это так не работает" ) Аджайл он для продуктов, в которых предполагается постоянная проверка бизнес-гипотез с постоянной готовностью к "не взлетело — выкидываем и пробуем следующую"
Я статьей хотел подчеркнуть другое: не следует строить стену между разными методиками и методологиями, отрицая эффективность использования прочих. В одном проекте могут использоваться разные подходы для производства разных элементов (подсистем), в зависимости от сложившихся условий. Границы между «Водопадом» и «Гибким подходом» размыты появившимися инструментами моделирования, проектирования, разработки и т.п.
При этом нельзя некомпетентность в области проектирования, пытаться нивелировать исключительно «гибким подходом»! За это будет переплачивать заказчик или сама команда будет нести убытки
Про то, что гибкие методы надо использовать в случае неопределенности предметной области, похоже, нигде не заострялось внимание. Всё говорилось, именно, про то, что заказчик может поменять требования. Но, нигде не заострялось внимание, что требования заказчик может поменять, потому что, сама предметная область «не изведана», а не потому что, например, «заказчик капризный».
А не получается ли тогда, что предметная область «не изведана», в случае, именно стартапов (исследовательских проектов), заказчиком которого являются сами разработчики (или, как вариант, инвестор)?
И, второй вопрос. Может, часто надо просто достаточно изследовать саму предметную область, прежде чем делать проект, и по ходу смотреть, «что там да как»? (понятно, что тут баланс скорее всего нужен)
Анализ Agile. Мифы и действительность