> Если менеджер верит команде, то зачем иметь оценку времени?
Можно верить команде, то есть быть уверенным, что разработчики и тестеры будут работать на максимуме способностей и выполнять задачи очень-очень быстро, но как это избавляет от необходимости знать хотя бы приблизительные сроки завершения работы по конкретной задаче? Это ведь не для формального контроля нужно, а для выполнения менеджером своих прямых обязанностей: общения с заказчиками, которых мало волнуют особенности внедрённых технологических процессов; или подготовки к публичному, маркетинговому запуску новой фичи.
Спасибо за перевод! Особенно порадовали идеи из раздела «Тестирование после релиза». Поскольку я занимаюсь веб-разработкой, сразу представила себе некий плагин, устанавливаемый в браузер пользователя синхронно с обновлением версии родного портала, плагин, собирающий статистику окружения и действий пользователя и при возникновении проблем сообщающий всё это в саппорт. Ммм… Никаких тебе «у меня страница не открывается», только подробное «после запроса авторизации в браузере [билд] с [настройки сохранения кук], браузер выполнил запрос к странице [url, параметры реквеста, куки] и получил в ответ [http заголовки]».
Боюсь, оригинальностью не потрясу, но точно ли смысл высшего образования в получении знаний по конкретным языкам разработки и методикам ведения процессов в IT? Мне всегда казалось, что важно научить студентов думать, самостоятельно искать информацию, разбираться в новом. Конечно, основы рассказать нужно, но только основы. Не зря говорят, что голодному надо дать не рыбу, но удочку.
Умеет ли конкретный преподаватель обучать навыкам самообучения — открытый вопрос, конечно, но мало связанный с тем, насколько знания «дяди Васи» отстали от жизни. Поймёт ли студент, что для развития в IT ему придётся постоянно изучать что-то новое, и рано или поздно даже самые распрекрасные лекции блестящего преподавателя безнадёжно устареют по содержанию?
Чтобы не быть голословной, расскажу немного о себе. В институте нам давали паскаль, ассемблер для микропроцессоров и C++. На разных работах мне приходилось писать на .NET, perl и ASP, а закончила я, и успешно, специализацией на XSL. И что с того, что когда я училась, про XSL никто не слышал? Я вынесла с лекций и практических занятий главное — уверенность, что любой язык программирования, любая технология мне по плечу, стоит только приложить достаточное количество усилий к изучению нового. И если «старпёр» не мешает студенту развиваться, не препятствует его экспериментам с новыми технологиями (пусть даже самому этому «старпёру» незнакомыми) — не вижу проблемы.
> Мне интересно, насколько эта практика имеет смысл и пользу при разработке коммерческих программных продуктов. Нужны ли пользователям на самом деле частые релизы? Какой им интерес выступать, по сути, постоянными бета-тестерами?
Никакого. Но пользователи скорее всего заинетересованы в развитии продукта. Существует опасность, что если команда нацелена на выпуск одного большого релиза в квартал, например, то продукт будет развиваться слишком медленно. Всегда можно сказать — это пойдёт в следующий релиз, в этот уже не успевает собрать и тщательно оттестировать. Ах, релиз через пять месяцев? Ну, простите. И даже такая медлительность не спасёт пользователя от недотестированных багов. Неделя до релиза, и вдруг всплывает критичная проблема или безумно нужная заказчику новая функциональность. Всё равно в релиз что-то добавят, даже с риском продлем на продакшене. Так не лучше ли сразу работать в представлении, что релизиться надо часто?
> Мне представляется, что короткие релизы не позволяют планировать заранее большие изменения. Насколько такая практика способствует (или не способствует) сохранению идейной и архитектурной целостности продукта?
Ну почему? Практически всегда большую функциональность можно разбить на небольшие куски для сборки и выкладки.
И ещё — сложности возникают только при строго последовательной разработке, но кто мешает её распараллелить? Тогда можно часто релизить мелочёвку, и редко — что-то большое и прекрасное.
Я сама именно по такой схеме работаю (http://www.control-freak.ru/tag/packages/), и — получается ведь.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Можно верить команде, то есть быть уверенным, что разработчики и тестеры будут работать на максимуме способностей и выполнять задачи очень-очень быстро, но как это избавляет от необходимости знать хотя бы приблизительные сроки завершения работы по конкретной задаче? Это ведь не для формального контроля нужно, а для выполнения менеджером своих прямых обязанностей: общения с заказчиками, которых мало волнуют особенности внедрённых технологических процессов; или подготовки к публичному, маркетинговому запуску новой фичи.
Умеет ли конкретный преподаватель обучать навыкам самообучения — открытый вопрос, конечно, но мало связанный с тем, насколько знания «дяди Васи» отстали от жизни. Поймёт ли студент, что для развития в IT ему придётся постоянно изучать что-то новое, и рано или поздно даже самые распрекрасные лекции блестящего преподавателя безнадёжно устареют по содержанию?
Чтобы не быть голословной, расскажу немного о себе. В институте нам давали паскаль, ассемблер для микропроцессоров и C++. На разных работах мне приходилось писать на .NET, perl и ASP, а закончила я, и успешно, специализацией на XSL. И что с того, что когда я училась, про XSL никто не слышал? Я вынесла с лекций и практических занятий главное — уверенность, что любой язык программирования, любая технология мне по плечу, стоит только приложить достаточное количество усилий к изучению нового. И если «старпёр» не мешает студенту развиваться, не препятствует его экспериментам с новыми технологиями (пусть даже самому этому «старпёру» незнакомыми) — не вижу проблемы.
Никакого. Но пользователи скорее всего заинетересованы в развитии продукта. Существует опасность, что если команда нацелена на выпуск одного большого релиза в квартал, например, то продукт будет развиваться слишком медленно. Всегда можно сказать — это пойдёт в следующий релиз, в этот уже не успевает собрать и тщательно оттестировать. Ах, релиз через пять месяцев? Ну, простите. И даже такая медлительность не спасёт пользователя от недотестированных багов. Неделя до релиза, и вдруг всплывает критичная проблема или безумно нужная заказчику новая функциональность. Всё равно в релиз что-то добавят, даже с риском продлем на продакшене. Так не лучше ли сразу работать в представлении, что релизиться надо часто?
> Мне представляется, что короткие релизы не позволяют планировать заранее большие изменения. Насколько такая практика способствует (или не способствует) сохранению идейной и архитектурной целостности продукта?
Ну почему? Практически всегда большую функциональность можно разбить на небольшие куски для сборки и выкладки.
И ещё — сложности возникают только при строго последовательной разработке, но кто мешает её распараллелить? Тогда можно часто релизить мелочёвку, и редко — что-то большое и прекрасное.
Я сама именно по такой схеме работаю (http://www.control-freak.ru/tag/packages/), и — получается ведь.