Руководство группой программистов

Управление командой/группой/отделом

Добрый день коллеги, хочу поделиться с вами своим опытом в области руководства группой разработчиков и проблемами, с которыми я встретился. Делаю я это чтобы каждый из вас как итог оставил в комментариях свое мнение, поделился своим опытом. Опишу проблемы и возникающие вопросы. Это очень важно как для личностного роста, так и для получения нового опыта от других команд (как от руководителей, так и от исполнителей).

Начало. Часть команды

Начал я свой путь, как и большинство из вас — разработчиком. Был частью команды из 3 человек. Мне это нравилось. Единственное, руководитель был иностранцем и были проблемы из-за отличия менталитетов и подходов. Но все же в такой небольшой команде мы быстро находили общий язык. Далее, почти всегда (до становления руководителем) я работал практически один в компании/отделе как разработчик. Без коллег разработчиков — был просто разработчиком в единственном числе, который делает все. Для меня это не было проблемой, так как опыт позволял мне в одиночку справится с любыми задачами. Параллельно я постоянно занимался развитием, проходил курсы, не пропускал ни одного митапа в Москве связанный с разработкой.

Да, я помню этот митап, где microsoft презентовал .net webforms, где зал охал, когда увидел первый postback, когда страница перезагрузилась частично. Я был на митапе, на котором показывали рождение windows phone. К сожалению, закат этой технологии тоже увидел (и других тоже) … и т.д.

Руководство. Команда от 2 до 5 человек

Для меня ничего нового не изменилось, просто из-за большого кол-ва задач мне в команду были добавлены еще 2 человека. Так образовалась команда и я стал лидером, но все еще не ощущал этого. Мне очень нравится наставничество, поэтому никаких проблем с адаптацией новых людей в команде у нас не было. Все члены команды мыслили в одном направлении, все дружно решали одни задачи. Смена места работы никак не влияла на работу и взаимоотношения с коллегами/подчиненными. Со всем коллегами на «ты», все члены команды вовлечены в процесс и полностью в курсе любых изменений и т.д.

Руководство. Команда от 6 до 10 человек

В такой большой команде появились первые проблемы, а именно «бытовые». Банальные опоздания на ежедневные собрания приводили к проблемам, недопониманиям при анализе задач и отрицательным результатам. Так же замечал, что уже не получается сгладить все взаимоотношения между людьми, просто не успеваю. Люди все очень разные, и это отчетливо заметно в большой команде. У каждого свой характер, некоторые просто не командные игроки, но со всеми нужно работать, из них нужно «лепить» специалистов.

Тут хочу отметить, что у нас была продуктовая команда, и мы сами решали, как развиваться нашему продукту. То есть, кнопка будет слева или справа решала команда, а не заказчик (заказчик только верхнеуровнево), в следствии чего были всегда дебаты между участниками. Для решения конфликтных ситуаций приходилось собираться по нескольку раз на внеочередные митинги. Демократия.

Технические трудности — думаю описывать не стоит, их практически не было, сам процесс просто усложняется таким количеством разных ролей в команде.

Тут я на практике понял, что описанное во многих статьях про agile утверждение что рекомендуемая команда до ~6 ~8 человек является правдой. Больше — просто усложняется процесс коммуникации. Так я решил изменить сам процесс, если раньше все «жили» продуктом, были в курсе изменений, вносили свой вклад в каждую новую фичу, то теперь каждый разработчик брал на себя свой отдельный модуль и о других задачах и нововведениях узнавал уже на обзоре спринта (Sprint review) или на ретроспективном совещании (Sprint Retrospective).

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

Руководство. Отдел до 50 человек

В такой команде уже проявляется «мини-социум» очень похожий на копию нашей страны в миниатюре. Уже невозможно со всеми быть в очень хороших отношениях. Хотя я очень стремлюсь к этому и мало того в первые недели после устройства на работу я провел около 40 внутренних собеседований, чтобы со всеми лично познакомиться, узнать у кого какой уровень и какими скилами обладает человек. Предыдущий опыт мне очень пригодился. Не всегда было такое количество человек в отделе, штат увеличивался постепенно, но особенно быстро за последние 1-2 года. Не буду сейчас описывать сам процесс и оптимизацию, которую я начал, так как для меня интересен момент взаимоотношения с людьми. В такой большой группе я заметил, что любое слово может кому-то не понравится. Мы все очень разные, как по менталитету (регионы РФ) так и по социальному положению, а тебе как руководителю очень важно чтобы была сплоченность. Поэтому стал вопрос: стоит ли в чате писать что-либо еще кроме официальной информации?

Так же в такой большой группе очень сложно внедрить что-либо новое, для этого нужны активные тимлиды.

Руководство. Группа от 300 человек

Так же являюсь автором небольшой группы в телеграмме для разработчиков, соответственно могу рассказать интересный случай. ИТ группы (форумы/чаты) разработчиков всегда для меня были эталоном нейтралитета, справедливости и толерантности. Я помню, как в конце нулевых почти все сидели на форумах сайта sql.ru, и даже когда по стране шли митинги, или столкновения (не будем вспомнить детали) разработчики на форумах никогда не переключались на политику. Сейчас видимо уже не так. В группе было поздравление по поводу 23 февраля. Неожиданно, но для одного члена группы это было серьезным нарушением его моральных устоев и через несколько нецензурных слов он удалился.

P.S. Буквально сегодня на митапе Let Another Level Алексей Шаграев рассказал коротко о двух книгах в которых описываются подходы и правила управления. В первой говорится: увольняй любого за кого ты не готов биться дальше, во второй — все люди имеют право работать на зарплату и не всегда нужно челенджить сотрудника (сам не читал, примерные слова Алексея). По его словам эти обе книги верны и при этом обе противоречат друг другу и возможно причина в том, что первая книга описывает компанию где работают 100 человек , а во второй 1000.

И я опять же убеждаюсь что от количества человек в коллективе (в подчинении ) очень сильно зависит сам подход.

Завершение

Если можно в комментариях укажите кто вы «руководитель» или «исполнитель», а далее опишите свой стиль работы.

Интересует у руководителя как тесно вы общаетесь с коллективом, что можете себе позволить, а что нет, какие приемы тимбилдинга используете?

Интересует у исполнителя: какими должны быть руководители по отношению к вам? Чего вы категорически не приемлите в действиях руководителя?

Да и в принципе хочется услышать чужой опыт.

Про должности Junior, Middle и Senior разработчиков все хоть немного, но слышали, а вот с тимлидами дело обстоит иначе. Не все понимают, кто такие тимлиды, какие задачи они выполняют и как ими становятся. Можно ли выучиться на тимлида на курсах для программистов? Пишут ли они код? Сколько в среднем зарабатывают? В статье отвечаем на эти и многие другие вопросы. 

Тимлид: разработчик или руководитель?

Кто же такой тимлид, он же team lead или руководитель команды разработки разработчик? Все эти названия обозначают одно и то же — руководящую должность внутри команды разработчиков. Тимлидом может стать практически любой программист. Как правило, предпочтение отдают наиболее опытным и знающим разработчикам, но опыт — это не самый главный критерий отбора. Основная задача тимлида, помимо написания кода, это организация работы внутри команды разработчиков. 

Получается, что тимлид — это в первую очередь менеджер

Он должен хорошо знать каждого разработчика в своей команде, его сильные и слабые стороны. Держа в уме все это, тимлид распределяет обязанности между программистами, руководит рабочим процессом и следит за тем, чтобы конечный продукт соответствовал желаниям заказчика. 

Как проходит рабочий день руководителя группы разработки

Представим на секунду, что вы стали Junior программистом, в течение нескольких лет поднимались по карьерной лестнице, и в конце концов вас назначили тимлидом целой команды разработчиков. Как бы выглядел ваш рабочий день? Примерно следующим образом:

10:00 — Вы встречаетесь с менеджером проекта или непосредственно заказчиком, обсуждаете рабочие моменты, вносите правки в уже существующие наработки и договариваетесь о дедлайне для сдачи следующего черновика проекта. 

12:00 — К вам в компанию пришли устраиваться новые программисты, поэтому вы принимаете участие в их собеседовании и делитесь своими впечатлениями с  HR отделом. Ваша команда пополнилась двумя джунами. Начинают работать уже сегодня! Вы проводите им экскурсию по отделу, знакомите их с коллегами и показываете рабочие места. Затем даете новичкам несложные задания и смотрите, как они справляются с ними в течение дня.

15:20 — Общий сбор команды. Вы рассказываете коллегам, как прошла ваша встреча с заказчиком, какие коррективы необходимо внести в проект, распределяете между разработчиками зоны ответственности и назначаете каждому дедлайн по сдаче работы. Все вместе вы обсуждаете, как лучше интегрировать хотелки клиента в разработку. 

16:40 — Кажется, один из джунов уже справился со своей задачей и вполне хорошо! Отправляете его помогать с новым проектом под надзор опытных программистов. Другой джун справляется с заданием гораздо хуже и, кажется, стесняется просить о помощи. Вы садитесь рядом. Новичок тушуется и говорит, что у него ничего не получается. Вы вспоминаете, как здорово он показал себя на собеседовании и говорите ему об этом. После краткой мотивационной речи вы сидите вместе и решаете возникшую проблему. Спустя час подробных обсуждений у джуна загораются глаза, и он начинает писать код, который работает!

18:00 — Вы думаете, в какое русло направить новых программистов. В команде не хватает разработчика мобильных приложений, поэтому вы решаете понаблюдать, у кого из новеньких лучше идут дела со Swift и предложить ему поработать с мобильными приложениями. 

Что можно понять из этого гипотетического расписания? То, что у тимлидов много задач абсолютно разного характера. Их можно условно разделить на несколько категорий:

1. Обсуждение проекта с топ-менеджментом или напрямую с заказчиком, а также организация рабочего процесса в соответствии с желаниями начальства или клиентов. 

2. Участие в найме новых сотрудников, помощь в адаптации и обучении джунов, а также планирование трека развития для новичков в зависимости от нужд компании. 
3. Распределение задач и обязанностей внутри команды, назначение дедлайнов и помощь с кодом, если у кого-то возникают сложности.
4. Написание кода.

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

Сколько зарабатывают тимлиды? 

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

Кто может претендовать на должность тимлида? 

Очевидно, что нельзя выучиться на тимлида или пройти онлайн курсы и прийти в компанию на эту должность. У руководителя команды разработки должны быть отлично развиты не только хард, но и софт скилы. Так какими же знаниями и навыками должен обладать кандидат на позицию тимлида?

• Быть самым опытным и авторитетным. Как правило, тимлиды — это разработчики старшего звена. Прежде чем занять эту должность, необходимо накопить солидный багаж знаний и годы опыта в разработке. Как минимум необходимо отлично знать несколько языков программирования, а также разбираться в чужом коде;
• Нужно быть не только программистом, но и менеджером. Тимлиду придется много общаться как с командой разработчиков, так и с заказчиками или начальством. Поэтому, он должен находить общий язык с любыми людьми, уметь четко излагать свои мысли и мотивировать команду на работу;
• Быть HR на полставки. Вы будете не только сигнализировать кадровикам, какой разработчик нужен в вашу команду, но и принимать участие в их отборе. 

Тимлид — это универсальный солдат?

Получается, что тимлид должен знать все о своей команде, о своем заказчике, а также все о своем и чужом коде! В целом, это действительно так. Тимлид должен быть не только хорошим разработчиком, но и отличным менеджером. Не каждый программист готов взять на себя ответственность и руководить целой командой коллег. Но если вы прирожденный лидер и не боитесь ответственности, то эта должность принесет вам массу удовольствия (и челленджей, конечно) при этом откроет множество новых возможностей для развития.  

Узнать больше о работе «руководитель группы программистов» в России вы можете в разделе Карьера — руководитель группы программистов. Также там представлена информация по другим профессиям, уровню зарплаты, работодателям и многое другое.

Для более гибкой настройки параметров поиска вы можете воспользоваться новым гибким поиском.

Для быстрого просмотра или подбора вакансии по текущему запросу (или любому иному) попробуйте раздел быстрого поиска.

Приветствую в это нелегкое время. Я продолжаю цикл статей для предпринимателей и несколько следующих хочу посвятить краеугольному камню любого IT проекта или продукта — команде.

Специфика IT

В отличие от многих сфер бизнеса, где “чем главнее, тем круче”, IT больше похож на медицину. Линейный разработчик, как и практикующий врач в частной клинике, может получать огромные деньги, значительно выше менеджмента.

Спрос на хороших специалистов очень высок. В IT не компания выбирает из ряда сотрудников, а сотрудник из ряда компаний. Следовательно, человек не будет бояться уйти, если его что-то не устраивает.

За последние годы доля крутых специалистов на рынке сильно уменьшилась. Еще 10 лет назад разработчиками и аналитиками становились только получившие профильное техническое образование и имеющие так называемую “базу”. Но с развитием онлайн-курсов и снижением порога входа в профессию за счет появления новых технологий на рынке с каждым днем становится все больше новичков, не имеющих опыта коммерческой разработки, которые хотят космические зарплаты.

Все эти аспекты необходимо будет учитывать как при формировании своей команды, так и при работе со сторонней компанией.

Структура команды

В IT очень много вариантов построения связей в командах, и нет единого правильного рецепта. Структура зависит от рынка, типа продукта, стадии его развития и многого другого. Кому-то необходимы собственные юристы, отделы продаж и поддержки, но есть и компании из 5ти человек, работающие с такими гигантами как Meta. Поэтому я решил выбрать наиболее популярный тип продукта — облачный сервис, имеющий сайт и мобильное приложение. Также сделаю допущение, что продажи автоматизированы. Тогда мы получим следующую верхнеуровневую структуру.

Во главе продукта стоит Product manager или Product owner. Разница есть, но для нас она не существенная. Он работает с рынком, общается с пользователями и инвесторами, определяет вектор развития продукта, генерирует гипотезы и пользовательские истории, приоритезирует их и много другое. Если упростить, он на основе данных решает, какие потребности и в каком порядке необходимо закрыть.

Например, он видит, что большое количество пользователей добавляют товары в корзину, но не покупают. Его задача — самостоятельно или, подключая команду, сформулировать гипотезы по увеличению конверсии и выбрать из них самые приоритетные на данный момент. Далее он передает их команде разработки (development team), которая поочередно их тестирует на части аудитории. Если результаты положительные, изменения внедряются на всех пользователей.

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

Development team

Не стоит пугаться большому количеству человек. Целью схемы я ставил показать структуру команды, а не ее размер. Вполне реально, когда каждая из веток заканчивается на лиде, то есть все направление закрывает один специалист.

Project manager

Проектный менеджер отвечает за реализацию определенного функционала в рамках согласованных сроков и бюджета.

Он определяет методологию разработки, налаживает процессы в команде, составляет план разработки и многое другое. То есть решает, что именно (как закрывать потребность), как и когда делать. Получив от продакта гипотезу по корзине, он отправит ее аналитику на детализацию, затем подключит дизайнера и разработчиков для оценки. Если продакт посчитает реализацию целесообразной, ПМ добавит ее в план для последующей реализации, внесет это все в график работ, проконтролирует выполнение, а после завершения тестирования сдаст задачу, в результате чего на сайте и в мобильном приложении появятся изменения.

Analysts

Аналитики бывают разные: бизнес-аналитики общего профиля; аналитики, специализирующиеся на конкретной области(логистике, медицине, …) и системные аналитики, чья деятельность подразумевает наличие компетенций разработчика и архитектора.

Бизнес-аналитики составляют бОльшую часть всех аналитиков в рамках стартапов, поэтому разберу именно их. Компетенции БА я разделяю на две больших области: продуктовая аналитика и формирование требований.

О продуктовой аналитике, которую необходимо провести до начала реализации, я писал в прошлых двух статьях: Есть идея IT-продукта. Что делать дальше? и Зачем нужен MVP. Помимо описанных там анализа ЦА, конкурентов и рынка, проведения проблемных и решенческих интервью, арсенал продуктового аналитика включает в себя большой спектр инструментов, позволяющих находить точки роста. Итогом этой части работы становятся пользовательские истории — формулировки вида “как покупатель, я хочу фильтровать товары, чтобы выбирать только среди релевантных” с различными дополнениями и ограничениями вроде названий фильтров или максимально рентабельной стоимости разработки. Это своего рода условия задачи.

Когда пользовательские истории сформированы, то есть понятно, какие потребности нужно закрыть, аналитик переходит к поиску решений. Использовать сторонний сервис или реализовать самим, делать эффективнее, но дороже и дольше или упростить, уменьшив стоимость и сроки и тд. Определив вариант реализации, проконсультировавшись с лидами других направлений, он приступает к его проработке: детализирует требования, проверяет их на полноту(все аспекты учтены) и непротиворечивость с уже реализованным функционалом. В итоге получается ТЗ.

Получив задачу по детализации требований к онлайн-оплате, он должен изучить эквайринги и платежные сервисы, представленные на рынке на соответствие заявленным требованиям, отбросить явно проигрышные и предоставить результаты для выбора продакту, ПМу и клиенту. Когда те выберут конкретный сервис, учтя условия самого сервиса, стоимость интеграции, качество документации и т.д., он должен детализировать требования для интеграции с конкретным сервисом, в результате чего будет получена задача для дизайнеров и разработчиков.

Leads

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

Лиды определяют “правила игры” в своем отделе: какие инструменты, подходы, технологии и тд будут использоваться. Если каждый сотрудник в направлении будет делать по-своему, об эффективности можно забыть.

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

Designers

Веб или мобильный дизайнер не “рисует картиночки”, как часто думают об этой профессии. Это в большей степени техническая позиция, чем творческая. Его ключевая задача — проектирование и дальнейшее улучшение пользовательского опыта при взаимодействии с продуктом, где “красота” сама по себе не имеет лидирующих позиций.

Работу дизайнера можно условно разделить на 3 части:

Tech Lead

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

Техлидами становятся очень опытные разработчики, имеющие развитые коммуникативные навыки. Фактически это второй ПМ, только с другими хард-скилами.

Принцип работы приложений

Перед тем как переходить к зонам ответственности разработки, необходимо на элементарном уровне понять принцип работы веб или мобильного приложения.

Клиент — веб или мобильное приложение — эта та часть, которую видит пользователь. Например, пользователь интернет-магазина, находясь в разделе кроссовки, выбрал в фильтре по бренду Nike. Тогда клиент посылает запрос на сервер, говоря “пришли мне все кроссовки Nike”. Сервер получает и обрабатывает этот запрос: команда проекта заранее определила, что пользователям должны показывать только товары, которые есть в наличии. Сервер обращается к базе данных, которая формально может быть как на этом, так и на другом сервере: “пришли мне все кроссовки с брендом Nike, которые есть в наличии”. В ответ сервер получает список товаров, но, если отправить все сразу, страница у пользователя может грузиться очень долго. Поэтому на сервере товары дробятся на страницы, а на клиент приходит ответ: “Всего нашлось 147 товаров, я разделил их на 8 страниц по 20 товаров, держи первые 20”. В итоге у пользователя отображаются первые 20 кроссовок Nike.

Большое приложение может иметь множество серверов и баз данных, но описанные выше принципы будут неизменны.

Front-end developers

В простонародье, фронты. Это направление разработчиков отвечает за клиентскую часть веб-приложения, то есть то, что вы видите в браузере. Он получает макеты от дизайнеров, верстает их (размечает на элементы и задает им свойства), пишет логику, которая выполняется в браузере, обменивается данными с сервером и адаптирует сайт под разные браузеры и разрешения.

В процессе работы он больше всего взаимодействует с дизайнерами по вопросу макетов и с серверными разработчиками(back-end developers) по обмену данными.

Mobile developers

Суть работы мобильного разработчика очень похожа на работу фронта, только вместо браузеров он ориентируется на требования операционные системы и устройства. Фронты, конечно, тоже учитывают их, но мобильные разработчики значительно сильнее от них зависят.

Мобильных разработчиков по используемым технологиям можно разделить на нативных и кроссплатформенных. Первые пишут приложения для конкретной ОС(iOS или Android), вторые сразу под обе.

Еще одним важным отличием мобильной разработки от веба является публикация приложений в сторах. Опубликовать свой сайт максимально просто: нужно только сервер и домен. Он может быть сколь угодно ужасно написан или вообще представлять собой пустую страницу — никаких ограничений! Мобильное приложение, в свою очередь, должно пройти проверку в сторах. Оно должно содержать описание, скриншоты, быть достаточно высокого качества и быть полезным(приложение, где будет только фото вашего котика, забракуют). Эти проверки еще на несколько дней отложат долгожданный запуск.

Back-end developers

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

QA

Тестировщики бывают ручные и автоматические. Ручные сами протыкивают все сценарии, автоматические пишут код, который проверяет код самого приложения.

Итоговая цель любого тестировщика — обеспечить высокое качество продукта.

Для этого они пишут тест-кейсы (последовательность действий при тестировании и ожидаемые результаты), проверяют приложение в разных браузерах и на разных устройствах, описывают найденные баги и передают команде, а в конце проверяют исправления.

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

Помимо работы с багами тестировщики также могут анализировать пользовательский опыт при работе в приложении на предмет его улучшения.

Заключение

Как вы видите, команда проекта состоит из большого числа специалистов в разных областях. На небольших проектах количество человек в одном направлении обычно не превышает 2-3 человек, и проседание любого из них сильно ухудшит итоговый результат команды. Это делает рекрутинг одним из важнейших факторов успеха.

В следующей статье я разберу, в каких случаях лучше собрать команду самому, а когда обращаться к сторонней. Если статья была вам полезна, буду благодарен за лайк и подписку. Всем мир, до скорых встреч✌

Работа
над крупными программными проектами —
коллективная деятельность:

1. Обеспечивается
   преемственность

2. Вырабатываются
   общие универсальные стандарты разработки

3. Облегчаются
   контакты.

• БРИГАДА
  ГЛАВНОГО ПРОГРАММИСТА

Состав:
Гл.
Прогр-т,
Зам-ль,
программист.
(10 – 12 чел)

Функции
главного программиста:
Руководство
проектированием ПС, определение
структуры ПС(построение
диаграммы классов…),
распределение и
контрольработ,
связь с заказчиком, написание наиболее
важных/критичных методов, глобальное
тестирование всей системы.

Функции
зама:
замещение главного, оппонирование в
процессе создания ПО, коммуникация с
другими бригадами.

Функции
программистов:
написание текста на псевдокоде, логика
работы методов, программирование
методов, тестирование элементов, участие
в интеграции разных элементов в единое
целое.

• БРИГАДЫ
  БЕЗ ПЕРСОНАЛИЗАЦИИ ФУНКЦИЙ:

«Демократическая».
На каждом этапе свой лидер, руководящий
работой на своем этапе. Все
функции те же самые.

• ОБЪЕКТНО-ОРИЕНТЕРИРОВАННАЯ
  БРИГАДА (ДЛЯ
  КРУПНОГО ПРОЕКТА)

Архитектор
системы, проектировщик классов, обычные
программисты.

Архитектор
Определяет
общую структуру ПС (на уровне главных
классов), продумывает
функции всей ПС. Основная работа: анализ
ПО, проектирование. На более низкие
уровни не опускается. Связь с заказчиком
и пользователями.

Проектировщик
классов:
основная задача – определение структуры
классов, относящихся к какой-либо части
ПС,
их интерфейсов, и отношений между
классами;
определение всех атрибутов, свойств и
методов, входящих в класс.

Обычный
программист:
Разрабатывает на языке псевдокода
(спецификаций) тексты методов Программирует
эти методы, тестирует их и отлаживает.(+см.
Бригада главного программиста).

Порядок
разработки ПС: определение должностей,
определение структуры классов, построение
отношений между классами на заданном
уровне абстракции, планирование элементов
реализации методов. Этапы повторяются
на каждом уровне итерации ПС.

13.2- Организация коллективов программистов и разработчиков

14. Тестирование программного обеспечения. Автономное и комплексное тестирование см. Также распечатку гэ_г_тестирование, структуру ответа — лучше по ней

• Тестирование
  – проверка работоспособности
  программы
  с целью обнаружения ошибок.

• Тестовый
  набор
  – совокупность входных данных + ожидаемый
  результат.

• Тестировщики:
  Программист> Руководитель
  разработки>Внешние организации>
  cпециальные внешние организации

• Тестирование
  может осуществляться на нескольких
  уровнях:

СМ.
РАСПЕЧАТКУ ГЭ_Г_ТЕСТИРОВАНИЕ,

—
Тестирование всей программной системы

—
Тестирование на уровне модулей или
методов (выполняется самими разработчиком)

—
Тестирование наиболее важных элементов
(выполняется руководителем разработки
, главным программистом)

• СТРАТЕГИИ
  ТЕСТИРОВАНИЯ:

1. Стратегия
   белого ящика

Имеются
исходные тексты тестируемой ПС

2)
Стратегия
черного ящика

Исходные
тексты недоступны. Можем работать с
программой, прогонять программу, задавать
данные и получать результат. Доступен
исполняемый код.

• СТРАТЕГИЯ
  БЕЛОГО ЯЩИКА

1. Подбираем
   тестовые наборы так, чтобы каждый
   оператор выполнился хотя бы 1 раз

2. Подбираем
   тестовые наборы так, чтобы каждая линия
   передачи покрывалась хотя бы 1 раз

3. Подбираем
   тестовые наборы так, чтобы каждый путь
   от входа к выходу проходился хотя бы 1
   раз [Трудная задача]

Примеры…

Тестовые
наборы нужно создавать в процессе
программирования.

В
основном используется 2 метод, но это
не гарантирует полноту тестирования

При
этом используется не слишком большое
число тестов. Такое тестирование проводит
разработчик программы.

• СТРАТЕГИЯ
  ЧЕРНОГО ЯЩИКА

1. Метод
   эквивалентных разделений.
   

Предполагаем
что множество всех возможных ошибок
может быть разделено на непересекающиеся
множества.

Всё
множество всех возможных входных данных
может быть разделено на классы
эквивалентности (поясните,
что это такое),
причем если тестовый набор из класса 1
обнаруживает ошибку 1, то и другой набор
из класса 1 обнаружит эту ошибку. Если
КЭ пересекаются, то кол-во тестовых
наборов может быть сокращено (если не
пересекаются, что число ТН = число
классов).

Если
удается выделить КЭ, то чаще всего
достаточно взять по 1 набору из класса.

Разбить
ошибки на непересекающиеся множества
очень трудно.

Соседние файлы в папке ГЭ_У_Студентам

• #
• #
• #