Comments 30
Спасибо
Если в гибких методологиях результат виден «по факту».
То при водопаде, результат виден только в конце.
Я не спорю, что нужен этап проектирования.
Но разработать «все и сразу» это дорого.
В большинстве случаев «дешевле», заставлять программистов переделывать, пока не будет достигнут приемлемый результат.
И да. Заказчики иногда путают прототип и реальное приложение.
То при водопаде, результат виден только в конце.
Я не спорю, что нужен этап проектирования.
Но разработать «все и сразу» это дорого.
В большинстве случаев «дешевле», заставлять программистов переделывать, пока не будет достигнут приемлемый результат.
И да. Заказчики иногда путают прототип и реальное приложение.
Опять же, все зависит от масштабов. Для строительства баньки на участке проект не нужен, а многоквартирный дом — другое дело. Разработать простое мобильное приложение с 5-ю экранами можно и путем проб и ошибок, но если у вас в системе нужно реализовать несколько десятков взаимосвязанных объектов и сложную логику, то методом «научного тыка» будет долго и дорого. И результат быстро будет не увидеть, как ни крути.
Так вся проблема, что «на берегу» все выглядит как «строительство баньки».
А когда заказчику намекаешь, что тут может будет «многоквартирный дом», и в начале нужно хотя бы собрать требования, начинают уверять, что тут даже не «банька», а вообще «собачья конура». Ну а потом…
А когда заказчику намекаешь, что тут может будет «многоквартирный дом», и в начале нужно хотя бы собрать требования, начинают уверять, что тут даже не «банька», а вообще «собачья конура». Ну а потом…
Вот для этого я и стараюсь сначала «продать» разработку ТЗ, а потом все уточняется. В процессе согласования ТЗ заказчик вовлекается в процесс и начинает понимать, что ему все-таки нужно и что это стоит. Это прием такой: вы типа риски снижаете, чуток платите, зато можете с ТЗ пойти куда угодно и получить оценку.
К сожалению, очень часто, «проповедуя» Agile, разработчики пытаются замаскировать свое неумение разработать проект системы (либо даже не знают, что это возможно). Они действуют самым удобным для них образом: будем допиливать и допиливать за деньги заказчика.
Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес.
И это не отменяет того факта, что без умения проектировать, ничего хорошего не получится. С или без agile.
ps
и да, agile не универсальное решение. строить (здания) по agile не очень.
Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес.
Интересная мысль, можете пояснить?
Я могу попробовать.
Главная выгода Agile для бизнеса:
- быстрый выход на рынок
- короткие фидбек циклы, что позволяет проводить быстрые эксперименты
Потому что:
- цена ошибки минимизирована, т.к. не тратится большое количество времени и денег на разработку минимального продукта, отзыв на который можно получить непосредственно от пользователя моментально
- допускается, что пользователь не знает на 100%, что он хочет, но пользователь точно знает, что он не хочет, посему работающий продукт идеален для получения отзыва, хотя прототипы и другие "оффлайн" методы могут очень помочь и сократить сроки экспериментов
В конкурентной среде (особенно такой динамичной, как в наши дни) у вотерфола почти нет шансов. Он непременно приведет к проваливанию сроков и разработке продукта, который, скорее всего, никому не нужен. Или, в лучшем случае, с огромным количеством фичей, которыми никто не пользуется.
Главная задача ИТ в динамичном бизнесе — не разработка софта, как бы странно это не звучало. Главная задача — решение бизнес проблем более эффективно. Оптимизация текущих процессов, изобретение новых. Если вы поговорите с вашим заказчиком и выясните, что он проводит огромное количество ручных вычислений, и вы дадите ему формулку для Excel, на написание которой и обучение нужных людей вам понадобится 2 дня, но это увеличит продуктивность заказчика на 90%, то вам цены не будет!
По моему мнению, цитируя Ваше сообщение — «что он проводит огромное количество ручных вычислений» — этой проблемы в waterfall не может быть в принципе, если только не задаваться целью заставить проводить огромное количество ручных вычислений)
Такая ситуация — это плата за Agile и называть это недостатком waterfall — не совсем корректно)
Такая ситуация — это плата за Agile и называть это недостатком waterfall — не совсем корректно)
По моему опыту, качественное ТЗ и техпроект экономят уйму времени, на разработку уходит в 2-3 раза меньше времени, т.к. разработчики кодят, а не гадают. И опять же, смотря что нужно. Если допилить пару фичей, то достаточно наброска, а не ТЗ. Если же у нас сотня объектов и сложная логика, то методом проб и ошибок 10 лет будешь двигаться. Да, первый результат покажешь очень быстро, а вот с конечным выйдет заминочка.
Тут собственно говоря уже развернуто обсудили, почему agile — это про бизнес, а не про ИТ.
Бизнесу грубо говоря, глубоко до лампочки — scrum, waterfall, devops, etc.
У бизнеса основная проблема — что делать в условиях неопределенности: конкуренты, законы, потребители, глобализация, и т.д. В итоге, сказать, каков будет твой бизнес через год, два, три — вряд ли кто может. Если в этих условиях кто-то предложит бизнесу, а давай ты вложись в XXX, и через годик, другой, получишь вот такой профит. То любой зрелый бизнес понимает, что через годик, другой все переиграется, и XXX может станет не нужным.
Ответ, что делать в условиях неопределенности — уменьшить горизонт детального планирования, наладить сбор и анализ обратной связи, и короткими итерациями двигаться с счастью. Понятно, что и этот подход не панацея. В итоге приходится импровизировать, что собственно и есть «agile», т.е. проявлять ловкость (многие забывают, что agile это не только гибкий, но и ловкий, а применительно к бизнесу, ловкий как-то ближе). Т.е. agile — это не просто короткие итерации и прочие атрибуты, которые обычно связывают с термином «agile», а чуть шире, в целом ловкость и быстрая адаптируемость к внешним условиям.
А правильно проектировать нужно всегда. При любом подходе.
Просто сейчас акцент проектирования смещается в более концептуальную сторону.
А где у нас узкие места по производительности? А что мы будем делать с этим когда нужно будет избавиться от этого узкого места? А что у нас с безопасностью? А что у нас простотой обслуживания? А что у нас с простотой развития? А что у нас с масштабированием? и т.д.
Насколько детально проектировать?
Настолько насколько нужно. Ответ вроде простой, но тем не менее неочевидный.
Чем больше проект и чем динамичнее, тем больше документация разъезжается с реальностью. В итоге документацией перестают пользоваться, и возникает отрицательная обратная связь. Документацией никто не пользуется, потому что она неактуальная. Документацию никто не актуализирует, потому что ей никто не пользуется.
Из этого ошибочно делают выводы, документация для проектирования не нужна вообще. (Документация нужна, необходимо только правильно выбрать уровень детализации) И документация никогда не нужна. (В других проектах, менее динамичных, документация запросто может быть детальной и актуальной).
Бизнесу грубо говоря, глубоко до лампочки — scrum, waterfall, devops, etc.
У бизнеса основная проблема — что делать в условиях неопределенности: конкуренты, законы, потребители, глобализация, и т.д. В итоге, сказать, каков будет твой бизнес через год, два, три — вряд ли кто может. Если в этих условиях кто-то предложит бизнесу, а давай ты вложись в XXX, и через годик, другой, получишь вот такой профит. То любой зрелый бизнес понимает, что через годик, другой все переиграется, и XXX может станет не нужным.
Ответ, что делать в условиях неопределенности — уменьшить горизонт детального планирования, наладить сбор и анализ обратной связи, и короткими итерациями двигаться с счастью. Понятно, что и этот подход не панацея. В итоге приходится импровизировать, что собственно и есть «agile», т.е. проявлять ловкость (многие забывают, что agile это не только гибкий, но и ловкий, а применительно к бизнесу, ловкий как-то ближе). Т.е. agile — это не просто короткие итерации и прочие атрибуты, которые обычно связывают с термином «agile», а чуть шире, в целом ловкость и быстрая адаптируемость к внешним условиям.
А правильно проектировать нужно всегда. При любом подходе.
Просто сейчас акцент проектирования смещается в более концептуальную сторону.
А где у нас узкие места по производительности? А что мы будем делать с этим когда нужно будет избавиться от этого узкого места? А что у нас с безопасностью? А что у нас простотой обслуживания? А что у нас с простотой развития? А что у нас с масштабированием? и т.д.
Насколько детально проектировать?
Настолько насколько нужно. Ответ вроде простой, но тем не менее неочевидный.
Чем больше проект и чем динамичнее, тем больше документация разъезжается с реальностью. В итоге документацией перестают пользоваться, и возникает отрицательная обратная связь. Документацией никто не пользуется, потому что она неактуальная. Документацию никто не актуализирует, потому что ей никто не пользуется.
Из этого ошибочно делают выводы, документация для проектирования не нужна вообще. (Документация нужна, необходимо только правильно выбрать уровень детализации) И документация никогда не нужна. (В других проектах, менее динамичных, документация запросто может быть детальной и актуальной).
Целиком поддерживаю! Вы читаете мои мысли, которые мне не удалось выразить в этой статье. Главное правило: не пользоваться тупо методиками, какими бы совершенными они ни были, а голову включать всегда и везде! И Один метод не исключает другого. Базовую функциональность спроектировали по вотерфолу, а замет поюзали, попробовали, поняли, что и где неудобно и чего не хватает: пошла гибкая разработка. А вот выбор, что есть базовое, с чем мы можем выйти на рынок, надо определять в каждом конкретном случае отдельно.
В общем, вам от меня респект и уважуха!
В общем, вам от меня респект и уважуха!
Как для вводной статьи — неплохо, хоть и немного рывками и местами несвязно.
Но вот холисрач Agile vs Waterfall — это вы зря:) Далее мое имхо, на основании моего опыта ИТ архитектора:
В любом проекте есть 3 взаимосвязанных параметра — сроки, деньги, результаты. Вы можете зафиксировать МАКСИМУМ два из них, оставшийся параметр всегда будет меняться. Что именно будет зафиксировано — зависит от рынка/проекта (в строительстве результат фиксированный, в разработке софта — результат часто «плавает») и заказчика (госуха — бюджет практически всегда фиксированный, да и сроки тоже). Нюанс в том, что находясь в начале проекта (если мы говорим действительно про большой проект, а не про «поход за пивом»), бывает очень сложно оценить, что именно, за сколько денег, и когда получим. И когда кто-то говорит клиенту «Я зафиксировал все три параметра» — это, мягко говоря, неправда. Обычно оказывается, что какой-то из параметров определен с зазором, позволяющим маневрировать «по ходу пьесы», но клиент этого просто не видит (нечеткое ТЗ, сроки и деньги с запасом :)).
Какую методологию выбрать — зависит именно от параметров и факторов, описанных выше:
З.Ы. Я не касаюсь сейчас недобросовестности исполнителей, часто-густо прячущих за Agile свою некомпетенцию или нежелание что-то делать (самая частая фраза которую слышу «у нас ТЗ/документации нет, мы работаем по Agile!»). Тут поможет только понимание методологии, чтобы говорить с исполнителями на одном языке и понимать, где они пытаются обмануть. Ну или умение бить, не оставляя следов:)
Но вот холисрач Agile vs Waterfall — это вы зря:) Далее мое имхо, на основании моего опыта ИТ архитектора:
В любом проекте есть 3 взаимосвязанных параметра — сроки, деньги, результаты. Вы можете зафиксировать МАКСИМУМ два из них, оставшийся параметр всегда будет меняться. Что именно будет зафиксировано — зависит от рынка/проекта (в строительстве результат фиксированный, в разработке софта — результат часто «плавает») и заказчика (госуха — бюджет практически всегда фиксированный, да и сроки тоже). Нюанс в том, что находясь в начале проекта (если мы говорим действительно про большой проект, а не про «поход за пивом»), бывает очень сложно оценить, что именно, за сколько денег, и когда получим. И когда кто-то говорит клиенту «Я зафиксировал все три параметра» — это, мягко говоря, неправда. Обычно оказывается, что какой-то из параметров определен с зазором, позволяющим маневрировать «по ходу пьесы», но клиент этого просто не видит (нечеткое ТЗ, сроки и деньги с запасом :)).
Какую методологию выбрать — зависит именно от параметров и факторов, описанных выше:
- Если требуемый результат с большой вероятностью известен (строительство нового корпуса больницы, например), то Watefall — ваше все. Результат жестко зафиксирован, ну а сроки и деньги — как получится. Из минусов — результат будет виден в конце, и если вместо больницы получилась новая элитная многоэтажка — «ну извините, не сносить же теперь?».
- Если нужно разработать что-то новое, или «сделайте мне красиво!», ну или «к сентябрю хоть что-то должно быть!» — Agile наше все. На каждой итерации клиент видит какой-то результат, и может вносить коррективы (та самая пресловутая гибкость). Но срок (или деньги, ли и то и другое) подошел к концу — и «баста, карасики, приплыли!», клиент имеет то что имеет.
З.Ы. Я не касаюсь сейчас недобросовестности исполнителей, часто-густо прячущих за Agile свою некомпетенцию или нежелание что-то делать (самая частая фраза которую слышу «у нас ТЗ/документации нет, мы работаем по Agile!»). Тут поможет только понимание методологии, чтобы говорить с исполнителями на одном языке и понимать, где они пытаются обмануть. Ну или умение бить, не оставляя следов:)
Полностью согласен. Хочу уточнить. Во-первых, в рамках статьи и невозможно описать все. Ее цель — именно быть «вводной» и заставить людей задуматься. Правда, очень мало разработчиков видя смысл в тщательном проектировании. Во-вторых, и в вотерфоле требования меняются, без этого редко обходится. Но зато есть ТЗ, в котором все зафиксировано. Хочешь больше: пожалуйста допник. Хорошее ТЗ мне всегда очень помогает. И когда мы его с заказчиком согласовываем, заказчик уже погружается в проект и начинает формулировать нормально, что он хочет. Уже тем сам процесс составления ТЗ полезен. Вовлечь заказчика — дорогого стоит.
Но зато есть ТЗ, в котором все зафиксировано
Не уверен что такие существуют в природе:) Самое большое и тщательно прописанное ТЗ (на финансовый инструмент), которое я видел, разрабатывалось и согласовывалось настолько долго, что устарело к моменту подписания (технологии и подходы к решению поменялись). Поэтому после подписания все участники концессии выдохнули, мысленно перекрестились, и больше старались про это ТЗ не вспоминать:)
Имхо, чем более творческий результат нужно получить, тем тяжелее на него написать ТЗ (особенно если не совсем понятно, что же в конце должно получиться, ну или цель уточняется по мере приближения к ней). Ну а чем тщательней прописано ТЗ, тем дольше оно согласовывается, и тем больше отрывается от реальности, умирая под горами канцелярита, который не понимают ни клиент, ни исполнитель (либо понимают каждый по-своему). Но заказчик да, вовлечен по самое не балуйся — правки, комментарии к правкам, замечания на коментарии к правкам, правки к замечаниям на коментарии к правкам…
Имхо, чем более творческий результат нужно получить, тем тяжелее на него написать ТЗ
Для творческих результатов как раз гибкие методы более пригодны, когда ты двигаешься методом проб и ошибок.
А по поводу сложности написания ТЗ, все зависит от составителя. Для средней системы я обычно пишу за 2 недели, 2-3 недели согласовываю. Но здесь главное — заказчик рассказывает идею, а как она будет реализована, определяю я и согласовываю. Для этого надо понимать сам бизнес, как это должно быть реализовано. От заказчика ждать этого нецелесообразно. В этом-то собака и порылась. Ну и бывают заказчики-формалисты, особенно в госах.
Если там всё задание пишется за 25 человекодней, то понятно, почему waterfall работает. На таких небольших объёмах будет работать всё при минимальном здравомыслии участников и каком-нибудь отлаженном процессе. WF обычно встаёт колом, если в согласовании задействовано 5+ подразделений (30-50+ более-менее активных участников) и объём самой постановки за сотню чд. Это субъективно нижняя планка, когда нельзя выехать на 1-2-3 суперэкспертах, которые могут охватить весь проект.
Ну и вообще, уже сто раз обсуждалось, что аналогия разработки ПО со строительством красивая, но не учитывает главного отличия. ПО по своей сути очень легко меняется. В разработке ПО "чертеж" — это по сути уже и есть продукт. Ну понятно, что в любой сложной системе есть некоторые нюансы, которые менять сложно/дорого/долго. Но на самом деле в ПО часто за несколько версий можно поменять самые глубокие архитектурные детали (и тут больше вопрос не к методологии управления проектом, а к культуре и профессионализму разработчиков).
Ну собсно выше ответили — 2 недели на ТЗ и один эксперт — это маленькое ТЗ:) Попробуйте поучаствовать в проекте, когда есть пяток экспертов — писателей ТЗ, и несколько согласующих сторон (часто преследущих совершенно разные цели) — и узрейте весь ад Waterfall. Про просранные сроки я даже не говорю, это практически само собой разумеющееся. Но обязательно найдется кто-то, кто подписал ТЗ не читая, а на финальной приемке скажет «все это фигня, я не это имел в виду и вообще, я хочу шесть невидимых розовых линий». Собсно, после такого и понимаешь, что Agile очень даже неплох, если им аккуратно пользоваться, а User story mapping — очень класный довесок к традиционному ТЗ. Главное — клиента не пугать модными словечками:)
Никто не обнимет необъятное. (с) К.Прутков
Чем больше проект, тем труднее написать полное качественное ТЗ сразу, до начала написания кода.
Поэтому при всем желании, надо «есть слона по частям».
Т.е. делить проект на модули, которые могут выполняться параллельно, причем даже в том случае, если для «смежных» модулей ТЗ не готово.
При этом естественно система будет «не оптимальной», т.к. как минимум нужно закладывать «гибкость».
Чем больше проект, тем труднее написать полное качественное ТЗ сразу, до начала написания кода.
Поэтому при всем желании, надо «есть слона по частям».
Т.е. делить проект на модули, которые могут выполняться параллельно, причем даже в том случае, если для «смежных» модулей ТЗ не готово.
При этом естественно система будет «не оптимальной», т.к. как минимум нужно закладывать «гибкость».
Конечно, сложные системы разбиваются на подсистемы, каждая из которых может по своей методике разрабатываться и разными командами. Куда без модульности? И даже в рамках одной небольшой системы делишь все на функциональные блоки. В этом-то и состоит задача аналитиков и проектировщиков: разгрести кучу-малу требований и разбить их на блоки, очереди разработки и т.д.
Интересно, спасибо!
Спасибо за статью!
Особенно хорошо написано про Agile)
Особенно хорошо написано про Agile)
Скажите пожалуйста, каким образом ваша схема описывает разработку информационной системы поисковика Google? А facebook? А чего-то менее масштабного, например, uber?
Есть у меня такое странное ощущение, что ваши схемы годятся только для больниц, домов престарелых и других замшелых учреждений, которым надо «внедрять ИТ». А тем, кто с помощью компьютеров деньги зарабатывает, ваши схемы, как мёртвому припарка?
Есть у меня такое странное ощущение, что ваши схемы годятся только для больниц, домов престарелых и других замшелых учреждений, которым надо «внедрять ИТ». А тем, кто с помощью компьютеров деньги зарабатывает, ваши схемы, как мёртвому припарка?
Есть у меня такое странное ощущение, что ваши схемы годятся только для больниц, домов престарелых и других замшелых учреждений, которым надо «внедрять ИТ». А тем, кто с помощью компьютеров деньги зарабатывает, ваши схемы, как мёртвому припарка?
Если говорить про бизнес, то ведь сначала готовится пилот, MVP, а потом идут доработки. Базовую разработку лучше делать проектным методом. Мелкие и даже средние доработки — это всегда гибкие технологии, без вариантов, нечего там проектировать. Добавление каких-то крупных функциональных блоков лучше делать проектом, чтобы сначала все изучить, а потом кодить, иначе все посыпаться может.
Если сравнить с разработкой «железа», то сначала самолет проектируют, затем создают один или несколько опытных образцов и по результатам их сборки, испытаний, «допиливают». Более того, бывает во время строительства корабля вносятся такие изменения, что приходится прорезать несколько палуб, чтобы заменить какой-то крупный агрегат, установленные в трюме.
В общем, один метод не отменяет другого. Надо уметь владеть и тем, и тем. К сожалению, среди «проповедников» Agile много людей, которые не владеют проектным методом, поэтому его и хают. Для освоения проектного метода требуется 10-20 лет по факту (ИМХО), надо не только изучить сам подход на 3-4 длительных проектах, но и знать несколько предметных бизнес-областей изнутри (продажи, маркетинг, производство, склад, транспорт, бухгалтерия и т.д.) Этому не научить в институте, не освоить на раз-два, это дается только опытом, на собственных многочисленных ошибках. Легче придумать, почему это не нужно (опять же ИМХО). Но гибкие методы нужны, без них никак! Только использовать их нужно по уму.
Насчет одного из подходов есть отличная шутка — В семье программиста в сказке «Три поросенка», спаслись поросята, строившие дом из г#вна и палок, быстрее, чем волк его разрушал)
Sign up to leave a comment.
Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы