Моя прошлая статья Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы вызвала временами бурное обсуждение в комментариях. Поэтому я решил изложить ряд тезисов по мотивам данного обсуждения.
Очень часто при обсуждении методов проектирования и осуществления проекта информационных систем слышишь критику этих методов со стороны разработчиков (программистов). Иногда разработчики просто не видят, что кроме написания кода у проекта имеется серьезная организационная составляющая, что выявить, сформулировать и согласовать требования — сложнейшая задача, что обучить пользователей и провести перестройку всех процессов — задача не на один день.
Уважаемые программисты, для того, чтобы выяснить, ЧТО должна делать система, нужно знать вовсе не C# или JAVA, а владеть предметной областью. Для проектирования логистической системы, надо быть логистом: иметь опыт работы в этой сфере или в нескольких смежных, похожих сферах. Поэтому и существуют бизнес-аналитики, задача которых как раз определить функциональный облик системы.
Заказчик в лучшем случае выдаст 30-50% нужной информации, остальное следует додумать самостоятельно. Причем додумать крайне критически. Вначале заказчик не знает, чего хочет! Как правило, происходит совместная разработка бизнес-модели, и только потом составляется список функций.
Для этого и требуется знание предметной области. Надо понимать заказчика с полуслова: он еще рассказывает идею, а ты уже знаешь зачем ему это надо и главное, как это организовывается, как должен работать такой бизнес, а не только ПО.
Обсуждение темы Agile vs. Проектная технология (каскад, водопад, waterfall) больше похоже на спор религиозных фанатиков! Статья вообще была не про Agile, но все комментарии — именно про «гибких». Ребята! Ну неужели нельзя взглянуть шире и увидеть, что для обоих методик есть место под солнцем?!
По-моему, резкое неприятие Agile является реакцией на крайне агрессивное «пропихивание» этой технологии. Послушав «проповедников» гибких технологий, создается впечатление, что до Agile мир не существовал, многолетнего опыта разработки ПО не было, ну и вообще, все кто работал до нас — дураки и страшные грешники, так как Agile-ом были не просвещены. Наивные! Такое мировоззрение характерно для подростков, но мы-то…
Давайте снизим градус и попытаемся трезво оценивать различные подходы для каждого проекта.
Как написал один из прокомментировавших, «Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес». Действительно, иногда нужно получить очень быстрый результат, выйти на рынок хоть с чем-то, чтобы застолбить место и найти инвесторов. Или идет отработка новых технологий, требования по которым составить проблематично. Это однозначно ниша Agile.
С другой стороны, а где вы найдете достаточно заказчиков, согласных работать по гибким технологиям? 70-80% заказов на рынке — это госструктуры, где используется стандартная проектная технология. Более того, по ГОСТ 34. И за это неплохо платят.
Кроме того, эти методы можно сочетать в одной разработке: ядро создается по проектной технологии, а некоторые части — методом проб и ошибок (Agile). Ну не все возможно продумать заранее. Кроме того, и в проектной технологии есть гибкость: имеется такое понятие, как опытная эксплуатация, в процессе которой многое может меняться.
Не могу ручаться за всех, но создается впечатление, что программисты думают «гибко», Agile отвечает структуре их мышления! Ведь программирование — это постоянный поиск наилучших решений. Вы садитесь за задачу, еще не знаете, как она должна быть решена. Вам не спрогнозировать заранее ни результат, ни сроки (да-да, сроки разработчиков умножаешь в 6-10 раз и только так получаешь реальную картину, ведь про тестирование и доработки они забыли). Это мышление многих программистов, ведь они — творческие личности. Так вот и не надо творческих личностей заставлять заниматься проектной скукотой. Для этого есть аналитики, руководители проекта.
Мы поняли, что Agile — это суть мышления разработчиков. Но заказчик-то думает иначе! И заказчику хочется понять, за что он платит, «пощупать» будущий результат, до начала разработки. А то получается игра в одни ворота: разработчикам удобно, а заказчик по ночам не спи, думай, получится или нет, а если получится, то что получится, когда получится, и сколько это будет стоить. Зато программисту лафа — спокойно работаю, что сделаю, то и сделаю, когда закончу, тогда и закончу, сколько запрошу, столько и заплатят. Не так что ли?
Но иногда заказчику так и следует сказать: мы делаем новое, поэтому спрогнозировать ни сроки, ни стоимость, ни результат не готовы. Согласны? Тогда делаем. Это хотя бы по-честному.
Разработка ПО отличается от других областей тем, что все время чему-то учишься. Каждый проект — как новый мир. Каждый проект предъявляет свои требования. Поэтому голову надо всегда держать включенной. Не зацикливаться на какой-то одной методике, одном подходе. Приходится импровизировать, почти всегда.
Когда критикуют либо проектную технологию, либо Agile, критики редко знают предмет своего возмущения. Очень мало тех, кто реально изучал (в том числе и стандарты: ГОСТ, ISO, IEEE) и пытался серьезно применять проектную технологию. Но критиков ее хватает. Очень мало команд, которые реально успешно (так, чтобы клиент был доволен!) применяет Agile, но «проповедников» хватает.
И опять же, не надо путать Agile и хаос. Если вы не умеете проектировать и поэтому выбираете гибкие методы, значит у вас будет бардак.
Успешное применение Agile, может, требует еще больших усилий, чем проектная технология. Более высокой слаженности команды, квалификации ее членов, умения находить общий язык с заказчиком.
Читайте другие статьи автора:
Проектирование не для программистов
Очень часто при обсуждении методов проектирования и осуществления проекта информационных систем слышишь критику этих методов со стороны разработчиков (программистов). Иногда разработчики просто не видят, что кроме написания кода у проекта имеется серьезная организационная составляющая, что выявить, сформулировать и согласовать требования — сложнейшая задача, что обучить пользователей и провести перестройку всех процессов — задача не на один день.
Уважаемые программисты, для того, чтобы выяснить, ЧТО должна делать система, нужно знать вовсе не C# или JAVA, а владеть предметной областью. Для проектирования логистической системы, надо быть логистом: иметь опыт работы в этой сфере или в нескольких смежных, похожих сферах. Поэтому и существуют бизнес-аналитики, задача которых как раз определить функциональный облик системы.
Заказчик в лучшем случае выдаст 30-50% нужной информации, остальное следует додумать самостоятельно. Причем додумать крайне критически. Вначале заказчик не знает, чего хочет! Как правило, происходит совместная разработка бизнес-модели, и только потом составляется список функций.
Для этого и требуется знание предметной области. Надо понимать заказчика с полуслова: он еще рассказывает идею, а ты уже знаешь зачем ему это надо и главное, как это организовывается, как должен работать такой бизнес, а не только ПО.
Заметки по Agile
Agile — это новая религия?
Обсуждение темы Agile vs. Проектная технология (каскад, водопад, waterfall) больше похоже на спор религиозных фанатиков! Статья вообще была не про Agile, но все комментарии — именно про «гибких». Ребята! Ну неужели нельзя взглянуть шире и увидеть, что для обоих методик есть место под солнцем?!
По-моему, резкое неприятие Agile является реакцией на крайне агрессивное «пропихивание» этой технологии. Послушав «проповедников» гибких технологий, создается впечатление, что до Agile мир не существовал, многолетнего опыта разработки ПО не было, ну и вообще, все кто работал до нас — дураки и страшные грешники, так как Agile-ом были не просвещены. Наивные! Такое мировоззрение характерно для подростков, но мы-то…
Давайте снизим градус и попытаемся трезво оценивать различные подходы для каждого проекта.
Agile годится не всюду, как и проектная технология
Как написал один из прокомментировавших, «Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес». Действительно, иногда нужно получить очень быстрый результат, выйти на рынок хоть с чем-то, чтобы застолбить место и найти инвесторов. Или идет отработка новых технологий, требования по которым составить проблематично. Это однозначно ниша Agile.
С другой стороны, а где вы найдете достаточно заказчиков, согласных работать по гибким технологиям? 70-80% заказов на рынке — это госструктуры, где используется стандартная проектная технология. Более того, по ГОСТ 34. И за это неплохо платят.
Кроме того, эти методы можно сочетать в одной разработке: ядро создается по проектной технологии, а некоторые части — методом проб и ошибок (Agile). Ну не все возможно продумать заранее. Кроме того, и в проектной технологии есть гибкость: имеется такое понятие, как опытная эксплуатация, в процессе которой многое может меняться.
Agile — это как мыслят разработчики
Не могу ручаться за всех, но создается впечатление, что программисты думают «гибко», Agile отвечает структуре их мышления! Ведь программирование — это постоянный поиск наилучших решений. Вы садитесь за задачу, еще не знаете, как она должна быть решена. Вам не спрогнозировать заранее ни результат, ни сроки (да-да, сроки разработчиков умножаешь в 6-10 раз и только так получаешь реальную картину, ведь про тестирование и доработки они забыли). Это мышление многих программистов, ведь они — творческие личности. Так вот и не надо творческих личностей заставлять заниматься проектной скукотой. Для этого есть аналитики, руководители проекта.
Мы поняли, что Agile — это суть мышления разработчиков. Но заказчик-то думает иначе! И заказчику хочется понять, за что он платит, «пощупать» будущий результат, до начала разработки. А то получается игра в одни ворота: разработчикам удобно, а заказчик по ночам не спи, думай, получится или нет, а если получится, то что получится, когда получится, и сколько это будет стоить. Зато программисту лафа — спокойно работаю, что сделаю, то и сделаю, когда закончу, тогда и закончу, сколько запрошу, столько и заплатят. Не так что ли?
Но иногда заказчику так и следует сказать: мы делаем новое, поэтому спрогнозировать ни сроки, ни стоимость, ни результат не готовы. Согласны? Тогда делаем. Это хотя бы по-честному.
Голову надо включать всегда
Разработка ПО отличается от других областей тем, что все время чему-то учишься. Каждый проект — как новый мир. Каждый проект предъявляет свои требования. Поэтому голову надо всегда держать включенной. Не зацикливаться на какой-то одной методике, одном подходе. Приходится импровизировать, почти всегда.
Чтобы что-то критиковать, надо это изучить
Когда критикуют либо проектную технологию, либо Agile, критики редко знают предмет своего возмущения. Очень мало тех, кто реально изучал (в том числе и стандарты: ГОСТ, ISO, IEEE) и пытался серьезно применять проектную технологию. Но критиков ее хватает. Очень мало команд, которые реально успешно (так, чтобы клиент был доволен!) применяет Agile, но «проповедников» хватает.
И опять же, не надо путать Agile и хаос. Если вы не умеете проектировать и поэтому выбираете гибкие методы, значит у вас будет бардак.
Успешное применение Agile, может, требует еще больших усилий, чем проектная технология. Более высокой слаженности команды, квалификации ее членов, умения находить общий язык с заказчиком.
Читайте другие статьи автора:
