«Идеального технического задания не существует».
Не раз слышал фразы подобного рода, в ситуациях когда разработчики реализовали не «то» и не «там», при это ссылаясь на отсутствие идеального технического задания от заказчика, аргументируя: «если бы это было указано в ТЗ, тогда бы ..».
Читать полностью »
Многие из нас работают в компаниях с уже устоявшимися процессами разработки прикладного ПО, и неотъемлемой частью этих процессов являются самые разнообразные документы. Однако, есть компании, в которых нет традиций и процессов написания технической документации, а вся информация находится у людей в головах и в корпоративной электронной почте. Если вы приходите из компании первого типа в компанию второго типа, вы очень быстро обнаруживаете, что рабочая документация нужна как воздух. Почему? Давайте рассмотрим основные типы рабочей документации в разработке ПО, и попытаемся представить себе жизнь без них.
Читать полностью »
Appnestic — это хостинг платформа для быстрого запуска приложения, автоматического управления ресурсами и многого другого. В платформе довольно много возможностей. Ранее мы описывали платформу более подробно habrahabr.ru/company/appnestic/blog/216653/
Как Appnestic может быть полезен компаниям, разрабатывающим программное обеспечение и веб-студиям?
Представим веб-студию, которая начала разработку веб-сайта для клиента.
Обычно разработка ведется на серверах компании — запуск проекта и его конфигурация производится администратором или разработчиком. После завершения проекта, код и конфигурация, в большинстве случаев, вручную переносится на мощности заказчика.
Давайте подсчитаем, сколько времени тратится разработчиком нa настройку окружения, это процесс достаточно долгий и трудоемкий.
Читать полностью »
Эта статья вышла из моего пути “проб и ошибок”, и почти каждый тезис так или иначе связан с неудачей или успехом на этапе проектирования и дизайна для какого-либо стартапа.
Надеюсь, что она поможет дизайнерам избежать тех же ошибок, на которые натолкнулась в свое время я. Людям, которые решили сделать свой стартап, эта статья поможет учесть тонкости, связанные с процессом разработки и сделать более качественный продукт.
Читать полностью »
Привет, читатели.
Давно вынашивала идею поделиться идеей об интерактивном тестировании как одной из возможных форм организации процесса, но свободное время появилось только сейчас, чем и хотелось бы воспользоваться. Хотя называть сие «организацией процесса» было бы слишком громко, скорее это просто один из удачно реализованных подходов работы в команде между программистом и тестировщиком. Ниже я поделюсь не столько какими-то истинами, сколько своим (как мне кажется — позитивным) опытом.
Если кому интересно — прошу под кат.
Как в одноименном фильме Начало (Inseption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?
Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:
Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.
Я пишу эту статью для нынешних или начинающих Владельцев Продуктов — «ловцов снов» и «продавцов воздуха». Людей, идеи которых способны изменить реальность. Читать полностью »
Сегодня мы проведём экскурсию по цеху разработки Badoo, в котором создаётся новый функционал нашего сайта, расскажем о самом процессе — от постановки задачи и до момента выкладки в боевое окружение.
За время существования компании её рабочий процесс эволюционировал от стохастического к хорошо контролируемому и понятному. Ещё полтора-два года назад никто точно не мог ответить на вопрос, какие задачи попали в сегодняшнюю выкладку, а менеджер опрашивал программистов, кто и что выложил. Сейчас же процесс максимально автоматизирован, таск-трекер тесно связан с системой контроля версий, задачи проходят несколько стадий проверки. При этом сохранилась высокая скорость разработки: нормальной считается ситуация, когда задача появилась утром, а после обеда новый функционал уже доступен пользователям на сайте.
Читать полностью »
Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.
Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.
Баги — это некие виртуальные вредоносные жучки, прячущиеся внутри программ. Они обладают собственной волей. Они проникают в самые важные участки. Они портят результаты, прерывают выполнение работы и делают другие гадости.
Конечно, это бред, если смотреть правде в глаза. Но, если вывести ментальную модель из того, что делают и говорят программисты, как раз получаются виртуальные живые существа, которых ищут, ловят, выявляют и уничтожают.
Массовая глобальная нескончаемая игра, которой увлечённо предаются практически все работники отрасли, включая тестеров, менеджмент, организаторов процессов и высоколобых теоретиков.
Почему так происходит? Потому что в индустрии совершенно превратно понимают, что такое исходный код и для чего он нужен.
Если опросить специалистов, мы получим сотню разных мнений. Но в сухом остатке, если отбросить всю шелуху, код выступает плодом творческих усилий и выражением гениальности автора. В стандартной ситуации и при любом фактическом уровне профессионализма программист воспринимает себя почти святым гением, создающим почти идеальный продукт.
Если сделать программиста не идеальным, получается одна интересная штука: код перестаёт быть готовым результатом. Он даже перестаёт быть результатом. И становится отражением текущего понимания программистом условий поставленной задачи и способов её решения.
Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.
Мозги критичны. Нужны люди особой культуры, не боящиеся выглядеть дураками, каких в ИТ практически не встречается.
Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.
И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»
Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.
