Рубрика «разработка программного обеспечения»

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.

Готовим читателей к знакомству со спецификациями

Итак, с чего может начинаться знакомство команды разработки, с представленными требованиями? Непременно с презентации аналитиком своего творения, будущим исполнителям. Для обоих сторон очень важно, насколько успешно будет установлен первый контакт и преодолен барьер вхождения в новый процесс. Но часто, по ряду причин очно это сделать невозможно или проблематично. Поэтому хорошим тоном будет включение в начало документа раздела, с кратким обзором его структуры и представления информации, а также разъяснением, как правильно и эффективно ее использовать.

Пример обзора документа:
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2 - 1

Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

А посему давайте взглянем на качество требований глазами команды исполнителей: разработчиков, специалистов управления качеством, менеджеров проекта. Ведь именно эти люди и являются основными потребителями работы аналитика. И от того насколько точно созданные спецификации подходят конкретной команде для переработки их в готовый программный продукт, зависит качество и конечная себестоимость этого продукта.
Читать полностью »

Due date как компонента ответственности в процессе разработки - 1

В продуктовой разработке постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?

На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?

И здорово, если люди могут сформулировать потребности, которые они хотят удовлетворить с помощью того или иного процесса. Но часто бывает так, что без раздумий просто внедряется модный подход, что в итоге приводит к недовольству участников либо к неэффективности для бизнеса – в современном мире с его высокими темпами, со стартапами и высокой конкуренцией результат подобной неосмотрительности может быть плачевным.

Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.

Читать полностью »

Как workflow разработки влияет на декомпозицию задач - 1

Одним из самых важных факторов, влияющих на скорость разработки и успех запуска проекта, является правильная декомпозиция идеи продакт-менеджера в задачи для непосредственно программирования. Как правильно это делать? Взять сценарий работы новой фичи от продакта и сразу начать кодить? Сначала написать приёмочные тесты, а потом – код, который будет обеспечивать их прохождение? А, может, переложить всё на плечи разработчиков – и пусть они в ходе скрам-покера сами решают?

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Читать полностью »

Моя первая работа в области разработки ПО заключалась в программировании на С++ для компании J.D. Edwards, которая сейчас является частью Oracle. Я проработал там с 1996 по 2000 год. Она настолько отличается от любой работы, на которой я был с того времени, с настолько разных сторон, что я всегда отношу ее к короткой “доинтернетной” фазе моей карьеры. Но есть такой момент – команда, в которой я работал, была самой разнообразной из тех, в которых я работал. А может даже из тех, с которыми лишь приходилось иметь дело, в рамках всей нашей отрасли.

Почему? Думаю, у меня есть ответ.

Культура J.D. Edwards и стандарты рабочего пространства были заимствованы напрямую из IBM. Пиджак и галстук обязательны для мужчин. Каждый день. Можно было оставить пиджак на спинке стула в кубикле всю неделю, уезжать домой и приезжать обратно в рубашке, но если ты не забрал пиджак домой на выходные и не менял его каждую неделю, тебе бы указали на это. Если ты начал появляться на работе в 9 вместо 8:30, на это обязательно бы указали. Ништяки? Бесплатная газировка. Пятницы в стиле кэжуал неохотно вводились лишь под давлением интернет бума, потому что иначе становилось труднее нанимать людей. Я любил мою работу и ненавидел дресс-код и режим.
Читать полностью »

Каждый разработчик совершает ошибки, никто от них не застрахован.

Большинство программистов учатся методом проб и ошибок. Это часть пути от Junior C# Developer до Senior C# Developer. Тем не менее, не обязательно совершать самому все эти ошибки, чтобы пройти этот путь.

Ниже приведены типичные ошибки, с которыми можно встретиться программируя на C#, и пути их обхода.
Читать полностью »

Привет! Пока наши разработчики трудятся над созданием хардкорных статей, прекрасная QA-инженер Ксюша Севридова sevridova_ksenia написала статью о том, как техническому специалисту готовиться и проводить первые собеседования, оценивать кандидатов и принимать решение о найме.

Далее пойдет текст от лица Ксюши.
Как найти того самого тестировщика - 1

В этой статье я расскажу о том, как в компании Devim проводится собеседование на должность QA-инженера, а также поделюсь некоторыми общими мыслями о данном процессе в целом. Для лучшего понимания постараюсь привести достаточно примеров. Речь пойдет о поиске именно ручного тестировщика.

Данная статья не претендует на какую-либо научную точность и истину в последней инстанции. Я делюсь своим опытом проведения собеседований и изучении некоторого количества источников по этой теме. Ну что ж, поехали!
Читать полностью »

Сегодня, в день смеха, рада поделиться с вами гороскопом для разработчиков. Отнеситесь к нему с юмором и чаще улыбайтесь!
Если по счастливому совпадению вы нашли что-то общее с персонажами, напишите в комментариях.
Авторские иллюстрации подготовлены Антоном , за что ему огромное спасибо!
Читать полностью »

Этой статьей начинается цикл интервью с нашими соотечественниками, добившихся значительных результатов на поприще инженерной мысли в современной России.
Несколько лет назад, увлекшись 3Д принтерами, а затем робототехникой и в некоторой степени, радиотехникой, волею судьбы получил возможность общаться с интересными людьми. Эти люди, чем-то напоминают «поколение шестидесятых». Современные инженеры, конечно, не такие романтические безсеребренники, какими были их деды.
Жизнь сегодня другая. Современный инженерный человек, как правило, с виду лыс, злобен и равнодушен. Но за этой защитной маской, вынужденно носимой в жестоком мире развивающегося капитализма, проявляется замечательный ум, предприимчивость и поистине железная устойчивость к невзгодам.Читать полностью »

После формального окончания проекта — работа не заканчивается, а только начинается. Необходимо реализовать функционал который не вошёл в основное содержание проекта, исправить некритичные ошибки которые не препятствовали запуску, и обслуживать поток изменений и инцидентов, сопутствующих процессу эксплуатации. При этом, необходимо организовать процесс таким образом, чтобы учитывать приоритеты запросов, технические зависимости, оставлять время на анализ требуемых изменений.

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

В данной статье кратко раскрываются следующие темы:

  • применимость процесса — когда имеет смысл его внедрять
  • основные этапы процесса, активности, вовлеченные ресурсы и результаты
  • планирование релизов: календарь, объем, параллельное выполнение
  • некоторые проблемы доставки в релизах

Читать полностью »