Комментарии 51
Может быть всё-таки Agile?
Вот вы написали 4 случая, когда agile не работает. А что сработает?
Там есть ссылочки в этих пунктах. По ним можно перейти и ознакомиться, с тем, что на мой взгляд в этих случаях сработает.
Ну вот у вас 2 пункт.
У заказчика нет ресурсов на сбор требований. Ну скажем, нет ответственного с его стороны. Так что ваша ссылка не релевантна.
Самый логичный способ запилить, что-то и выкатить, а потом слушать, что не так и как это поправить. Я участвовал в нескольких таких проектах, и когда менеджмент понимал, ситуацию, то мы успешно использовали agile.
Кстати, переписать всё с нуля не такая уж большая проблема, если понятно, что писать и уже отработана технология.
У заказчика нет ресурсов на сбор требований. Ну скажем, нет ответственного с его стороны. Так что ваша ссылка не релевантна.
Самый логичный способ запилить, что-то и выкатить, а потом слушать, что не так и как это поправить. Я участвовал в нескольких таких проектах, и когда менеджмент понимал, ситуацию, то мы успешно использовали agile.
Кстати, переписать всё с нуля не такая уж большая проблема, если понятно, что писать и уже отработана технология.
Заказчик не должен собирать требования, поскольку у него нет соответствующих навыков и знаний. Качественно собирать и формализовать требования в больших и сложных проектах должны аналитики. Они обладают навыками и приемами, позволяющими вытянуть из заказчика потребности, даже если тот не очень желает делиться своими знаниями о предметной области.
Переписать с нуля, к примеру, систему Документооборота гос.струтктуры не очень большая проблема??? (мы же говорим о больших системах).
Переписать с нуля, к примеру, систему Документооборота гос.струтктуры не очень большая проблема??? (мы же говорим о больших системах).
должны аналитики
Которые должны с кем-то общаться. Со стороны заказчика должны быть ответственные лица, которые бы отвечали на вопросы аналитиков и устраивали митинги. Взаимодействие с аналитиками со стороны заказчика — это куча денег.
Я Вам больше скажу, использование программистов для взаимодействия с заказчиком — это еще дороже, поскольку и стоят программисты в среднем дороже и выхлоп будет меньше, потому как аналитики, все таки для это роли более приспособлены.
Речь не об аналитиках а о людях со стороны заказчика. Вы понимаете, что для того, чтобы аналитик работал его письма не должны сразу оптавляться в спам человеком, у которого и так куча работы, кроме как с подрядчиком общаться.
Со стороны заказчика всё это надо организовать — это может быть очень и очень сложно. Аналитику должен отвечать компетентный специалист, который ещё и конкретно отвечать может не хотеть, ибо это ж ответственность. Короче, куча проблем со стороны заказчика, которые подрядчик не может толком решить.
Agile очень помогает при недостатке информации, все эти частые релизы и жёсткие сроки спринтов позволяют по частям выжимать из клиента требования. Ну и за каждый этап работ легче получать акт, ибо релиз есть, есть, стори сделаны, сделаны. Если менеджеры не круглые дураки, то компания не будет работать бесплатно, а просто остановит разработку на данном проекте до следующего спринта.
Со стороны заказчика всё это надо организовать — это может быть очень и очень сложно. Аналитику должен отвечать компетентный специалист, который ещё и конкретно отвечать может не хотеть, ибо это ж ответственность. Короче, куча проблем со стороны заказчика, которые подрядчик не может толком решить.
Agile очень помогает при недостатке информации, все эти частые релизы и жёсткие сроки спринтов позволяют по частям выжимать из клиента требования. Ну и за каждый этап работ легче получать акт, ибо релиз есть, есть, стори сделаны, сделаны. Если менеджеры не круглые дураки, то компания не будет работать бесплатно, а просто остановит разработку на данном проекте до следующего спринта.
Тут надо отделять мух от котлет.
Для этого есть другие роли в проекте. Это может быть Продакт или Проджект менеджеры. Может быть высшее руководство подрядчика — исполнителя.
Задача стоит в другой плоскости — организовать процесс. Не стоит эту проблему решать препирательством исполнителей.
Если есть контракт, то в нем обычно прописывают в обязательствах заказчика пункт о своевременном предоставлении необходимой информации. Если контракт не исполняется, то руководство исполнителя направляет руководству заказчика претензию о неисполнении контракта и это в большинстве случаев действенно. Поскольку руководству заказчика нужен продукт и не нужны неустойки.
Для этого есть другие роли в проекте. Это может быть Продакт или Проджект менеджеры. Может быть высшее руководство подрядчика — исполнителя.
Задача стоит в другой плоскости — организовать процесс. Не стоит эту проблему решать препирательством исполнителей.
Если есть контракт, то в нем обычно прописывают в обязательствах заказчика пункт о своевременном предоставлении необходимой информации. Если контракт не исполняется, то руководство исполнителя направляет руководству заказчика претензию о неисполнении контракта и это в большинстве случаев действенно. Поскольку руководству заказчика нужен продукт и не нужны неустойки.
Вся проблема в том, что вы считаете что в манифесте правая часть противопоставляется левой. Это просто проблема перевода / восприятия слова «важнее». Прямо в манифесте, 5-й строчкой написано
Вы же восприняли слово 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 почти никак.
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 почти никак.
Эта статья посвящена русскоязычной аудитории. Если посмотреть практически любой перевод на русский язык, то приведенный мной перевод далеко не самый радикальный. Можно найти и такое трактование: «Мы больше не заставляем расписываться заказчика кровью, ограничивая его жесткими и неудобными условиями договоров». Даже в Вашем переводе много личного, разъясняющего, как это надо трактовать (вариант от Вас). Об этом в общем то и речь в статье.
Можно читать так, а можно и ровно наоборот. Главное, чтобы Вы могли это подкрепить своим взглядом на «здравый смысл».
Можно читать так, а можно и ровно наоборот. Главное, чтобы Вы могли это подкрепить своим взглядом на «здравый смысл».
У вас в статье — официальный перевод с agilemanifesto.org/iso/ru/manifesto.html. Agile manifesto — это весь текст манифеста, а только процитированные в статье четыре пункта.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.это такая же часть манифеста, как и предложения с «важнее». А не какое-то дополнительное «личное толкование». Нужно очень сильно постараться при переводе, чтобы превратить «мы не отрицаем важность согласования условий контракта» в «контракт не нужен».
Интересная статья, спасибо.
Планируется добавить часть про SAF (scaled agile framework)?
Хотелось бы увидеть предложения по использованию agile в крупных интеграционных проектах более детально. Планируете?
Планируется добавить часть про SAF (scaled agile framework)?
Хотелось бы увидеть предложения по использованию agile в крупных интеграционных проектах более детально. Планируете?
В статье есть ссылка, на описание моего видения процесса производства ПО, для больших проектов процесс промышленного производства ПО Об использовании agile, там есть упоминания.
Про SAF пока не планировал писать.
Про SAF пока не планировал писать.
Ну вот не стоило тут про перфокарты-то. Допустим, в 1970 они и имели место, но уже в 1980 в лично моей реальности их не существовало, а лет на 5 позже ими уже пользовались лишь самые закостенелые.
И что даже еще важнее, так это то, что в 1970-х еще не существовало средств версионирование кода, как таковых (да и в 80-х пожалуй тоже, потому что CVS появилась в 1990-м). А отсутствие в процессе разработки даже CVS влияет на него намного сильнее, чем Waterfall vs Agile.
И что даже еще важнее, так это то, что в 1970-х еще не существовало средств версионирование кода, как таковых (да и в 80-х пожалуй тоже, потому что CVS появилась в 1990-м). А отсутствие в процессе разработки даже CVS влияет на него намного сильнее, чем Waterfall vs Agile.
В конце 80-ых, абсолютно точно, и с большой долей вероятности в начале 90-ых большая часть гос.статов. СССР работала на ЕС 1035, 1045. В том числе с перфокартами.
Видите ли, я программирую с 1975, поэтому эти все ЕС наблюдал лично. И очень многие, смею вас заверить (включая те 4 своих, которые обслуживал как системщик).
Я с 1980 года примерно перфокарты почти не трогал. А уже в середине 80-х все машины приходили как минимум оснащенные ЕС-7066, а потом ЕС-7927. Я говорю про свою реальность (в частности это Москва — хотя наблюдал и Миасс, например, и Питер).
Хотя другую реальность я исключать конечно не могу — в конечном счете, я общался с коллегами, а это был Минобщемаш, и вряд ли он был самый бедный :)
Я с 1980 года примерно перфокарты почти не трогал. А уже в середине 80-х все машины приходили как минимум оснащенные ЕС-7066, а потом ЕС-7927. Я говорю про свою реальность (в частности это Москва — хотя наблюдал и Миасс, например, и Питер).
Хотя другую реальность я исключать конечно не могу — в конечном счете, я общался с коллегами, а это был Минобщемаш, и вряд ли он был самый бедный :)
НЛО прилетело и опубликовало эту надпись здесь
Поменяйте галеру (аутсорс, работу на госструктуры) на нормальную продуктовую контору. Будет и нормальная зп, и возможность принимать решения не только в коде, и свобода от корпоративного духа. Аджайл тут как бы вообще ни при чем. При старом добром водопаде гребсти ничуть не легче.
Айтишники слишком много получают, при этом их тяжело контролировать и отчитываться верхним смотрящим о прогрессе, поэтому давайте изобретём потогонную систему, пусть они делают что-нибудь, и побольше, мы будем отчитываться о прогрессе, а если что то надо переделывать — назовём это издержками метода.
НЛО прилетело и опубликовало эту надпись здесь
Все не так уж однозначно. С одной стороны, бизнес это детище — почти «живой организм» и отношение к нему у организаторов (не владельцев, а именно организаторов) бизнеса, соответствующее. И команда в нем тоже часть «живого организма» (наиболее живая и интересная), позволяющего ему функционировать и развиваться. Вот если часть этого организма мешает ему развиваться или функционировать, тут может быть включен механизм самосохранения, выбранный организатором (владельцем) бизнеса. Это могут быть репрессии, избавления от балласта, нянченье и заигрывание, замена человеческого труда автоматизацией и т.д.
НЛО прилетело и опубликовало эту надпись здесь
Что значит «за ту же зарплату»? Как правило, людям способным к самоорганизации платят больше там, где эта способность востребована. Собственно как и за любые востребованные способности
AZaz1, А Вы были когда нибудь владельцем конторы, чтобы объективно рассуждать об этом? Я таковым являюсь. Чтобы долго не разглагольствовать приведу в пример анекдот, очень хорошо отражающий суть проблемы: «Надоело работать на дядю, открыл свое дело. Теперь работаю на 10 дядь».
5. Как не надо использовать Agile
Не менее важный раздел, возможно ради которого и затевался весь анализ.
Много проще.
Agile эффективен тогда, когда в этом есть потребность у бизнеса.
Agile — не про ИТ. Agile — про бизнес.
Про то, как вести бизнес в условиях неопределенности и непрерывных изменений во внешней среде.
Строишь дом? Строительство относительно прогнозируемая деятельность. Никакой agile не нужен.
Продаешь свои услуги через свой сайт или свое мобильное приложение? Эта область непрерывных изменений. Без agile твой бизнес весьма вероятно проигрывает конкурентам и умирает.
Аврал.
Согласно идеям Александра Прохорова из книги Русская модель управления можно сказать, что «наш» человек лучше всего работает, когда «враг у ворот» и надо «сплотиться и вытаскивать проект из жо». А почему проект там оказался и почему изначально работа не делалась как следует — ну, у нас так принято, не спрашивайте.
Согласно здравому замечанию о том, что если на проекте хаос и ты постоянно принимаешь решения — ты системный архитектор, братан, ты горишь, у тебя лихорадка ожидания успеха! А если на проекте всё упорядоченно, и «просто надо всё сделать», то — ты просто унылый гребец, ты не системный и не архитектор, фу таким быть, фу.
Получаем работника, который хорошо работает только во время кризиса. А раз таких работников много, и их modus operandi идентичен, то получаем целый коллектив, который результативен только во время кризиса.
Предложим этому коллективу свободу agile. Нет документов — сами решите, нужны ли они вам. Нет тест-кейсов (бо нет требований) — ну и что, ни тест-кейсов, ни тестировщиков не будет, ведь они не нужны, ведь люди и их взаимодействие важнее общения с тестировщиками — и так далее, по кругу. Получается группа людей, которые работают в условиях постоянного кризиса, им объясняют общую задачу, их регулярно снабжают баландой и ради их же безопасности не выпускают за периметр зоны, а они в ответ ракеты в космос запускают и радеют за неведомый им «бизнес заказчика».
Только упомянутый вами аврал и спасает.
Согласно идеям Александра Прохорова из книги Русская модель управления можно сказать, что «наш» человек лучше всего работает, когда «враг у ворот» и надо «сплотиться и вытаскивать проект из жо». А почему проект там оказался и почему изначально работа не делалась как следует — ну, у нас так принято, не спрашивайте.
Согласно здравому замечанию о том, что если на проекте хаос и ты постоянно принимаешь решения — ты системный архитектор, братан, ты горишь, у тебя лихорадка ожидания успеха! А если на проекте всё упорядоченно, и «просто надо всё сделать», то — ты просто унылый гребец, ты не системный и не архитектор, фу таким быть, фу.
Получаем работника, который хорошо работает только во время кризиса. А раз таких работников много, и их modus operandi идентичен, то получаем целый коллектив, который результативен только во время кризиса.
Предложим этому коллективу свободу agile. Нет документов — сами решите, нужны ли они вам. Нет тест-кейсов (бо нет требований) — ну и что, ни тест-кейсов, ни тестировщиков не будет, ведь они не нужны, ведь люди и их взаимодействие важнее общения с тестировщиками — и так далее, по кругу. Получается группа людей, которые работают в условиях постоянного кризиса, им объясняют общую задачу, их регулярно снабжают баландой и ради их же безопасности не выпускают за периметр зоны, а они в ответ ракеты в космос запускают и радеют за неведомый им «бизнес заказчика».
Только упомянутый вами аврал и спасает.
Есть разные взгляды на этот вопрос)
И один из них — попробуйте набирать в команду людей со схожими целями и ценностями.
Например: наберите семейных мужиков с ипотекой и детьми. По итогам квартала: мы выполнили план и заработали? Вот вам еще 2 оклада.
Удивитесь насколько разработчики могут оказаться людьми «про бизнес»)
И один из них — попробуйте набирать в команду людей со схожими целями и ценностями.
Например: наберите семейных мужиков с ипотекой и детьми. По итогам квартала: мы выполнили план и заработали? Вот вам еще 2 оклада.
Удивитесь насколько разработчики могут оказаться людьми «про бизнес»)
Удивлен, что кто-то еще придерживается тех же взглядов на «agile-rup-водопад» что и я.
Пожалуй только не соглашусь про
«команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. „
Иногда так бывает, что даже “проработав архитектуру» (в случаее ее неочевидности) — всё-равно с появлением новых требований может возникнуть неприятная ситуация и что-то придется переделывать, потому что теперь всё по другому — но тут уж никакая методология от неизвестности будущего не застрахует.
Субъективно для себя я утвердился во мнении, что если уберечь команду от игр в «я-у-мамы-архитектор» и от того чтобы на ранних этапах слишком всё оптимизировать — потом получается легче принимать изменения т.к. мы не завязали себя в узел + меньше привязанность к прошлым решениям т.к. на них было потрачено меньше ментальных усилий.
А в остальном: нас спасет только стремление к осознанности и здравому смыслу + общие цели и ценности.
Пожалуй только не соглашусь про
«команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. „
Иногда так бывает, что даже “проработав архитектуру» (в случаее ее неочевидности) — всё-равно с появлением новых требований может возникнуть неприятная ситуация и что-то придется переделывать, потому что теперь всё по другому — но тут уж никакая методология от неизвестности будущего не застрахует.
Субъективно для себя я утвердился во мнении, что если уберечь команду от игр в «я-у-мамы-архитектор» и от того чтобы на ранних этапах слишком всё оптимизировать — потом получается легче принимать изменения т.к. мы не завязали себя в узел + меньше привязанность к прошлым решениям т.к. на них было потрачено меньше ментальных усилий.
А в остальном: нас спасет только стремление к осознанности и здравому смыслу + общие цели и ценности.
Я олдскульщик и вообще старая школа (тот самый RUP когда-то от зубов отскакивал; а уж как я любил автогенерацию Vision на основе заполненных UseCases это вообще не передать), но при этом — я очень гибкий товарищ.
Поэтому, когда мне заказчик говорит "… разработку ведем только по гибким методологиям" я ему вот прям сразу и отвечаю «без вопросов, дорогой, за твои деньги, да по T&M, я буду работать хоть вприсядку с подвыпертом, только плати, уважаемый».
Приблизительно 99,9 заказчиков после слов о T&M резко перестают хотеть гибкие методологии.
Поэтому, когда мне заказчик говорит "… разработку ведем только по гибким методологиям" я ему вот прям сразу и отвечаю «без вопросов, дорогой, за твои деньги, да по T&M, я буду работать хоть вприсядку с подвыпертом, только плати, уважаемый».
Приблизительно 99,9 заказчиков после слов о T&M резко перестают хотеть гибкие методологии.
Спасибо, отличный пост. Мне, большому стороннику Agile разработки, очень понравилось.
Почти все по делу (про значение слова «важнее» вам уже выше написал пользователь PashaPash).
Очень важно понимать, что Agile разработка — это сложно. Сложно предугадать, какие требования могут измениться, а какие скорее всего нет. Где нужно написать документацию, а где можно обойтись. Когда можно додумать самому, а когда лучше уточнить у заказчика. Надо быть опытным профессионалом, чтобы «работать без страховки».
Надеюсь статьи, подобные вашей, помогут ит-сообществу (в последнее десятилетие изрядно пополнившемуся неофитами) подходить к выбору методологии осознанно, а не только гнаться за модой
А не может ли быть такая ситуация, что «требования могут поменяться», лишь потому, что аналитики не могут грамотно составить требования заказчика и не разбираются в предметной области?
Насколько я понимаю, обратной связи в таком случае просто нет. Т.е. если аналитики ошибаются, это ни исправить, ни даже уверенно установить программисту не удастся.
Конечно может. Разработка требований — это сложный процесс, требующий серьезной подготовки в области системного анализа и опыта его применения. К сожалению, у нас не много высших учебных заведений готовят системных аналитиков в общем и качественных в частности. Это проблема!
Так и вырастают аналитики самоучки — «дичка у дороги», которые не умеют: ни общаться с заказчиком ни формировать требования.
Пытаюсь с этим бороться по мере сил. Вот тизер моих лекций по курсу подготовки системных аналитиков мой YouTube канал. 15 роликов на эту тему, лишь затрагивает основные аспекты профессии. Для качественной же подготовки специалистов, нужны тренинги и практика.
Так и вырастают аналитики самоучки — «дичка у дороги», которые не умеют: ни общаться с заказчиком ни формировать требования.
Пытаюсь с этим бороться по мере сил. Вот тизер моих лекций по курсу подготовки системных аналитиков мой YouTube канал. 15 роликов на эту тему, лишь затрагивает основные аспекты профессии. Для качественной же подготовки специалистов, нужны тренинги и практика.
я больше про то, что раз «не раскурили предметную область» и «не смогли в требованиях», то давайте придумывать эджайлы всякие.
наподобие того, как у нас попадаются заказчики, когда мы пытаемся получить с них требования, а они говорят, например, «ну нарисуйте нам хоть какую-нибудь форму, мы посмотрим, тогда и скажем, что нам надо». Т.е., абстрактное мышление стремиться к нулю, хотя речь идет об их повседневной деятельности.
так же и сами разработчики. пока не запрогарммируем сами хоть что-нибудь, вообще не сможем понять, что надо-то было => работаем итерациями. а на самом деле, может надо было просто, все же суметь разобраться в предметной области (конечно, заранее все не предусмотришь, и гибкость должна быть и в методологии, но не такая, что начинаем делать чебурашку, а в итоге переделываем в слона. просто сразу не поняли, что надо слона именно делать).
Как пример, пришлось мне полгода где-то поработать в стартапе, где вот прям скрам (не знаю, на сколько именно соответствовал процесс скраму). попал туда уже, когда им через пару месяцев надо было сдавать проект, а у них вопрос стоял, что все это надо переписать. Делался до этого проект, как понял, почти год. Хотя, на самом деле, ничего там инновационного, с точки зрения функционала не было. впечатление было, что просто не было у команды опыта. Эджайл тут никак не помог.
Может я ошибаюсь
наподобие того, как у нас попадаются заказчики, когда мы пытаемся получить с них требования, а они говорят, например, «ну нарисуйте нам хоть какую-нибудь форму, мы посмотрим, тогда и скажем, что нам надо». Т.е., абстрактное мышление стремиться к нулю, хотя речь идет об их повседневной деятельности.
так же и сами разработчики. пока не запрогарммируем сами хоть что-нибудь, вообще не сможем понять, что надо-то было => работаем итерациями. а на самом деле, может надо было просто, все же суметь разобраться в предметной области (конечно, заранее все не предусмотришь, и гибкость должна быть и в методологии, но не такая, что начинаем делать чебурашку, а в итоге переделываем в слона. просто сразу не поняли, что надо слона именно делать).
Как пример, пришлось мне полгода где-то поработать в стартапе, где вот прям скрам (не знаю, на сколько именно соответствовал процесс скраму). попал туда уже, когда им через пару месяцев надо было сдавать проект, а у них вопрос стоял, что все это надо переписать. Делался до этого проект, как понял, почти год. Хотя, на самом деле, ничего там инновационного, с точки зрения функционала не было. впечатление было, что просто не было у команды опыта. Эджайл тут никак не помог.
Может я ошибаюсь
Есть две крайности. Одну вы описали.
Вторая — уверенность что все можно заранее просчитать и описать в ТЗ. К сожалению, нет. Что предпочитают ваши клиенты, что им мешает, что можете вы предложить им в качестве решения — детали выясняются только в процессе непосредственного взаимодействия, как следствие, работаем над улучшением короткими итерациями.
Короткие итерации не везде применимы, соответственно agile там не используем.
Вторая — уверенность что все можно заранее просчитать и описать в ТЗ. К сожалению, нет. Что предпочитают ваши клиенты, что им мешает, что можете вы предложить им в качестве решения — детали выясняются только в процессе непосредственного взаимодействия, как следствие, работаем над улучшением короткими итерациями.
Короткие итерации не везде применимы, соответственно agile там не используем.
вот тут мы размышляли на кухне нашей фирмы об Ajile, для молодых специалистов: просто о сложном.
youtu.be/0wRejqe6n9U часть 1
youtu.be/MgMuGvSiZuE часть 2
youtu.be/0wRejqe6n9U часть 1
youtu.be/MgMuGvSiZuE часть 2
"Составить требования заказчика" как-то дико для меня звучит. Почти как "Изя, у мужчины должно быть своё мнение и сейчас мама твоё тебе расскажет". ) Вы, наверное, про сбор требований и ограничений? Agile предполагает работу в условиях высокой неопределенности, когда полные требования просто невозможно собрать заранее, когда они меняются по ходу дела после получения обратной связи
В том то и дело, что просто сбор информации от заказчика, чаще всего мало эффективен. Заказчик, в большинстве случаев не совсем понимает, что он хочет, для чего именно это ему нужно, какие есть варианты подобных решений, какие показатели оценки и т.п… Поэтому если системный аналитик (специалист по работе с заказчиком) владеет приемами общения (манипуляции) с людьми + он понимает что такое система, а любая автоматизация — это система и любой бизнес без автоматизации — это тоже система, то пройти путь от понимания реальной потребности заказчика ко внедрению эффективной ИТ системы, можно гораздо быстрее и с меньшими затратами.
В зависимости от масштаба проекта в процесс могут подключаться бизнес-архитекторы с опытом автоматизации в нужной отрасли, направлении. Об этом у меня есть ролики на канале www.youtube.com/watch?v=hXNt_-j-6zo&list=PLoi3EglG5oUoAAQZ975PPRiiv9HvhRKw0&index=11
В зависимости от масштаба проекта в процесс могут подключаться бизнес-архитекторы с опытом автоматизации в нужной отрасли, направлении. Об этом у меня есть ролики на канале www.youtube.com/watch?v=hXNt_-j-6zo&list=PLoi3EglG5oUoAAQZ975PPRiiv9HvhRKw0&index=11
Если возможно описать требования клиента до начала работ по собственно разработке продукта, то аджайл просто не нужен. Он для тех ситуаций, когда это невозможно, когда, например, заказчик хочет создать новую отрасль или взорвать существующую вопреки мнению экспертов "это так не работает" ) Аджайл он для продуктов, в которых предполагается постоянная проверка бизнес-гипотез с постоянной готовностью к "не взлетело — выкидываем и пробуем следующую"
В таком случае, без всяких эджайл манифестов, понятно, что надо сначала попробовать. Потом посмотреть, получается или нет. Если возникли какие-то проблемы и/или стало понятно куда двигаться/сворачивать, то делать это. Опять, же маленькими шагами. Что тут, тогда, эджайл нового привнес?
Agile, как раз и предлагает практику, следуя которой можно эффективно «маленькими шагами», при отсутствии формализованных требованиях, организовать процесс производства ПО, путем выдачи прототипов продукта с ограниченным функционалом, тем самым минимизировать возможность создания «ненужного» функционала.
Я статьей хотел подчеркнуть другое: не следует строить стену между разными методиками и методологиями, отрицая эффективность использования прочих. В одном проекте могут использоваться разные подходы для производства разных элементов (подсистем), в зависимости от сложившихся условий. Границы между «Водопадом» и «Гибким подходом» размыты появившимися инструментами моделирования, проектирования, разработки и т.п.
При этом нельзя некомпетентность в области проектирования, пытаться нивелировать исключительно «гибким подходом»! За это будет переплачивать заказчик или сама команда будет нести убытки
Я статьей хотел подчеркнуть другое: не следует строить стену между разными методиками и методологиями, отрицая эффективность использования прочих. В одном проекте могут использоваться разные подходы для производства разных элементов (подсистем), в зависимости от сложившихся условий. Границы между «Водопадом» и «Гибким подходом» размыты появившимися инструментами моделирования, проектирования, разработки и т.п.
При этом нельзя некомпетентность в области проектирования, пытаться нивелировать исключительно «гибким подходом»! За это будет переплачивать заказчик или сама команда будет нести убытки
С этим, особенно, с последним предложением согласен.
Про то, что гибкие методы надо использовать в случае неопределенности предметной области, похоже, нигде не заострялось внимание. Всё говорилось, именно, про то, что заказчик может поменять требования. Но, нигде не заострялось внимание, что требования заказчик может поменять, потому что, сама предметная область «не изведана», а не потому что, например, «заказчик капризный».
А не получается ли тогда, что предметная область «не изведана», в случае, именно стартапов (исследовательских проектов), заказчиком которого являются сами разработчики (или, как вариант, инвестор)?
И, второй вопрос. Может, часто надо просто достаточно изследовать саму предметную область, прежде чем делать проект, и по ходу смотреть, «что там да как»? (понятно, что тут баланс скорее всего нужен)
Про то, что гибкие методы надо использовать в случае неопределенности предметной области, похоже, нигде не заострялось внимание. Всё говорилось, именно, про то, что заказчик может поменять требования. Но, нигде не заострялось внимание, что требования заказчик может поменять, потому что, сама предметная область «не изведана», а не потому что, например, «заказчик капризный».
А не получается ли тогда, что предметная область «не изведана», в случае, именно стартапов (исследовательских проектов), заказчиком которого являются сами разработчики (или, как вариант, инвестор)?
И, второй вопрос. Может, часто надо просто достаточно изследовать саму предметную область, прежде чем делать проект, и по ходу смотреть, «что там да как»? (понятно, что тут баланс скорее всего нужен)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализ Agile. Мифы и действительность