Блог компании NetCat → Agile в заказной веб-разработке
Если мы (веб-студия или частный разработчик) делаем веб-проект для себя, мы сами вольны выбирать метод разработки: гибкий (Agile) или каскадный («водопад»). Как правило, чем сложнее проект, тем меньше шансов у водопада. Но когда мы делаем сайт для заказчика, метод всегда один: каскадный. Эта статья о том, как (и зачем) убедить заказчика попробовать гибкую модель для сложных веб-проектов.
Управление проектами → Два протокола управления проектами
Доброго времени суток.
Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.
Это был большой и сложный проект. Мы работали как удаленная офшорная группа в постоянной атмосфере прессинга со стороны менеджмента. Оценки задач спускались сверху, и чтобы хоть как-то справиться с задачами, приходилось работать до позднего вечера и по выходным.
Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.
Следующие несколько лет я искал *супер фреймворк* для управления проектами. Но только недавно понял, что его нет и быть не может. Проблема заключается в том, что в разработке ПО одновременно используются 2 конфликтующих протокола общения между участниками Процесса.
Сейчас я расскажу о моем текущем видении проблемы, а также опишу одну из возможных стратегий совместного использования этих двух протоколов.
Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.
Это был большой и сложный проект. Мы работали как удаленная офшорная группа в постоянной атмосфере прессинга со стороны менеджмента. Оценки задач спускались сверху, и чтобы хоть как-то справиться с задачами, приходилось работать до позднего вечера и по выходным.
Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.
Следующие несколько лет я искал *супер фреймворк* для управления проектами. Но только недавно понял, что его нет и быть не может. Проблема заключается в том, что в разработке ПО одновременно используются 2 конфликтующих протокола общения между участниками Процесса.
Сейчас я расскажу о моем текущем видении проблемы, а также опишу одну из возможных стратегий совместного использования этих двух протоколов.
Персональные блоги → The Rise And Fall Of Waterfall
Идея создать «это» пришла ко мне около года назад. По большому счету, именно задача создания подобного мультика заставила меня взять карандаш в руки, и наложила свой отпечаток на все мои последующие презентации…
Сейчас я уже не слышу споров на тему, что круче «Водопад» или гибкие методологии. Создается впечатление, что каскадная модель разработки ПО канула в лету.
Практически всю свою сознательную жизнь я был противником этой методологии, однако просто нелюбить ее мало. Я начал изучать вопрос ее происхождения и довольно быстро наткнулся на тот факт, что ее вообще никто не изобретал, а родилась и получила широкое распространение эта модель лишь благодаря серии досадных недоразумений.
Детали смотрите в мультике. Обязательно обратите внимание на саундтрек, подобранный с особой любовью.
Update: Кросс-посты и ссылки только приветствуются. Есть спортивный интерес, воспользовавшись силой социальных сетей, донести это до самого Уалкера Ройса, почтив тем самым светлую память его отца.
Сейчас я уже не слышу споров на тему, что круче «Водопад» или гибкие методологии. Создается впечатление, что каскадная модель разработки ПО канула в лету.
Практически всю свою сознательную жизнь я был противником этой методологии, однако просто нелюбить ее мало. Я начал изучать вопрос ее происхождения и довольно быстро наткнулся на тот факт, что ее вообще никто не изобретал, а родилась и получила широкое распространение эта модель лишь благодаря серии досадных недоразумений.
Детали смотрите в мультике. Обязательно обратите внимание на саундтрек, подобранный с особой любовью.
Update: Кросс-посты и ссылки только приветствуются. Есть спортивный интерес, воспользовавшись силой социальных сетей, донести это до самого Уалкера Ройса, почтив тем самым светлую память его отца.
на удаление → Модели разработки программного обеспечения
Тема статьи может показаться вам немного странной (признаться, сначала я и сам думал, что различные модели разбработки ПО никому не нужны). Но на практике оказалось, что следование описанным моделям значительно упрощает работу над приложением.