Кто есть кто?

Ну с девелоперами вроде более менее понятно (хотя как человек узнает что он уже не Developer а Senior Developer? В трудовой разряд другой напишут? ). А вот с перечисленными выше товарищами не очень понятно. Особенно часто, как мне кажется путают Team lead'а/Project manager'а и Team lead'а/архитектора

В общем, если мне не изменяет память роли этих товарищей здесь уже по отдельности обсуждали, по крайней мере некоторых из них. А вот все вместе то как? Роли пересекаются... Представим что есть не очень большая компания. Что-нибудь с такой структурой:

1 Архитектор + 1 помошник архитектора
    
    Проект №1
        1 Project manager
        1 Team lead
        1 системный аналитик
        2 Senior Developer
        10 Developer
        1 Junior Developer
        2 QA (Tester)

    Проект №2
        1 Project manager
        1 Team lead
        1 системный аналитик
        5 Senior Developer
        5 Developer
        1 QA (Tester)


    Проект №3
        1 Project manager
        1 Team lead
        1 системный аналитик
        2 Senior Developer
        10 Developer
        1 QA (Tester)

Вот мое понимание.

Архитектор должен:

Проектировать архитектуру (высокоуровнево)

Занимается вопросами интеграции проектов

Занимается вопросами эволюции проектов


Тимлид должен:

распределять задачи между разработчиками

координировать работу разработчиков (а не делают ли Вася с Петей одно и тоже)

контролировать работу разработчиков (всё ли успевают)

изучать вопросы использования новых технологий (внедрить технологию X в проект Y)

организовывать различные технологические презентации команде (либо сам, либо другие опытные разработчики): использование новых технологий, программ, библиотек, best practice

создавать шаблоны кода конкретного проекта (сделать каркас, дать его команде)

контролировать код, архитектуру проекта, делать соответствующие правки.

помогать Junior'ам

Системный аналитик (не путать с бизнес аналитиком) должен заниматься вопросами проекта в целом с т.з. функционирования системы и использования ее конечными пользователями, т.е. этими вопросами:

usability

отсутствие внутренней противоречивости, согласованность модулей

бизнес логика


Менеджер должен:

планировать распределение ресурсов (MS Project ):

составлять ТЗ (MS Word )

общаться с клиентами (MS Outlook )

Но для маленькой компании один человек может выполнять роли всех этих четырех товарищей...

Так все-таки чего ожидать когда в вакансиях пишут "тимлид" и "архитектор"? И что будут ожидать от меня когда я напишу в резюме "тимлид" или "архитектор"?

Здравствуйте, MV5, Вы писали:

MV5>Кто есть кто?

MV5>Ну с девелоперами вроде более менее понятно (хотя как человек узнает что он уже не Developer а Senior Developer? В трудовой разряд другой напишут? ). А вот с перечисленными выше товарищами не очень понятно. Особенно часто, как мне кажется путают Team lead'а/Project manager'а и Team lead'а/архитектора

MV5>В общем, если мне не изменяет память роли этих товарищей здесь уже по отдельности обсуждали, по крайней мере некоторых из них. А вот все вместе то как? Роли пересекаются... Представим что есть не очень большая компания. Что-нибудь с такой структурой:


MV5>

MV5>1 Архитектор + 1 помошник архитектора
    
MV5>    Проект №1
MV5>        1 Project manager
MV5>        1 Team lead
MV5>        1 системный аналитик
MV5>        2 Senior Developer
MV5>        10 Developer
MV5>        1 Junior Developer
MV5>        2 QA (Tester)

MV5>    Проект №2
MV5>        1 Project manager
MV5>        1 Team lead
MV5>        1 системный аналитик
MV5>        5 Senior Developer
MV5>        5 Developer
MV5>        1 QA (Tester)


MV5>    Проект №3
MV5>        1 Project manager
MV5>        1 Team lead
MV5>        1 системный аналитик
MV5>        2 Senior Developer
MV5>        10 Developer
MV5>        1 QA (Tester)

MV5>

А не маловато тестеров?

Здравствуйте, anton_t, Вы писали:

_>А не маловато тестеров?

+1 Тестеров в идеале должно быть столько же, сколько разработчиков.

Здравствуйте, Straight, Вы писали:

S>+1 Тестеров в идеале должно быть столько же, сколько разработчиков.

Как же так? А зачем тогда нужны unit-тесты, которые пишет САМ разработчик? Или разработчикам уже не нужно отлаживать то, что они сами написали?

Здравствуйте, anton_t, Вы писали:

_>А не маловато тестеров?

Вот такие нынче тимлиды.

Здравствуйте, screamer__, Вы писали:

__>Здравствуйте, Straight, Вы писали:

S>>+1 Тестеров в идеале должно быть столько же, сколько разработчиков.

__>Как же так? А зачем тогда нужны unit-тесты, которые пишет САМ разработчик? Или разработчикам уже не нужно отлаживать то, что они сами написали?

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

__>Как же так? А зачем тогда нужны unit-тесты, которые пишет САМ разработчик? Или разработчикам уже не нужно отлаживать то, что они сами написали?

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

Здравствуйте, Handie, Вы писали:

__>>Как же так? А зачем тогда нужны unit-тесты, которые пишет САМ разработчик? Или разработчикам уже не нужно отлаживать то, что они сами написали?

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

Все важно и юнит- и функциональное тестирование.
Я цифры "с потолка" взял. Конечно тестировщиков должно быть больше.
Да я вообще не про это спрашивал.

Здравствуйте, pvirk, Вы писали:

P>Здравствуйте, anton_t, Вы писали:

_>>А не маловато тестеров?

P>Вот такие нынче тимлиды.
Цифры взяты "с потолка".

Здравствуйте, MV5, Вы писали:

MV5>Кто есть кто?

MV5>Но для маленькой компании один человек может выполнять роли всех этих четырех товарищей...

MV5>Так все-таки чего ожидать когда в вакансиях пишут "тимлид" и "архитектор"? И что будут ожидать от меня когда я напишу в резюме "тимлид" или "архитектор"?

"лид" подразумевает наличие неких навыков управления людьми, вот собственно и все

Здравствуйте, ksg71, Вы писали:

K>Здравствуйте, MV5, Вы писали:

MV5>>Кто есть кто?

MV5>>Но для маленькой компании один человек может выполнять роли всех этих четырех товарищей...

MV5>>Так все-таки чего ожидать когда в вакансиях пишут "тимлид" и "архитектор"? И что будут ожидать от меня когда я напишу в резюме "тимлид" или "архитектор"?

K>"лид" подразумевает наличие неких навыков управления людьми, вот собственно и все
Тимлид технический специалист? Он вообще должен хоть когда-нибудь программировать?
Если это только управление, то какая разница между ним и менеджером?

Здравствуйте, MV5, Вы писали:

MV5>Здравствуйте, ksg71, Вы писали:

K>>Здравствуйте, MV5, Вы писали:

MV5>>>Кто есть кто?

MV5>>>Но для маленькой компании один человек может выполнять роли всех этих четырех товарищей...

MV5>>>Так все-таки чего ожидать когда в вакансиях пишут "тимлид" и "архитектор"? И что будут ожидать от меня когда я напишу в резюме "тимлид" или "архитектор"?

K>>"лид" подразумевает наличие неких навыков управления людьми, вот собственно и все
MV5>Тимлид технический специалист? Он вообще должен хоть когда-нибудь программировать?
MV5>Если это только управление, то какая разница между ним и менеджером?

а капитан футбольной команды должен хоть когда-нибудь играть в футбол

Здравствуйте, ksg71, Вы писали:

K>а капитан футбольной команды должен хоть когда-нибудь играть в футбол
Хорошее сравнение +1

У тебя не совсем верное представление о том кто есть кто... Почитай тотже RUP, какой-нибудь. Модель не линейная, она скорее V. В разработке, веток, то есть, две. Одна — управление работами. Здесь линия — проджект манагер, тим лид, программер. Тут, я думаю особых вопросов быть не должно...
Другая же линия — аналитика-архитектура . Тут бизнес аналитик — ситемный аналитик — архитектор. У них назначение разное. Аналитики с арзитекторами говорят и готовят что нужно сделать с проработкой этого дела по мере своих способностей.
Эти две векти работают в параллель. Так, программерская ветка может строчить 1.0, а аналитика уже фигачит требования к 3.0 версии, а архитектор корпеет над 2.0
Организационно проджект манагер держит под собой не только программеров, но и аналитиков с архитектором. То есть, в V модели на острие сидит манагер проекта.
С тестерами же всегда бордак. Оч. эффективно, если у проекта свои тестеры и сидят под тем же манагером. Но, обычно, отдел тестеров один на кучу проектов и в лучшем случает есть специализация отдельных тестеров по проектам. Рулить ими приходится через голову нач. тестеров, у которго совсем другие проблемы, чем у проджект манагера. Вот потому стабильный, оттестированный проект — редкость.

Здравствуйте, Handie, Вы писали:

__>>Как же так? А зачем тогда нужны unit-тесты, которые пишет САМ разработчик? Или разработчикам уже не нужно отлаживать то, что они сами написали?

H>Для самоуспокоения.

для самоуспокоения как раз руками тестируют.
Это из психологии — когда человек нервничает (например о качестве билда) ему нужно чем-то руки занять (обратите внимание — как правило в таких случаях их занимают чем-то бесполезным)

H>В некоторых конторах юнит тестирование — это основной вид тестирования, создается иллюзия что продукт протестирован, но на самом деле продукт остается дерьмом.

Обычно продукт им становится в результате следующего акта: дружная команда тестеров 2 недели тестит билд. Находит к примеру 10 дефектов, из них 2 критических, которые надо пофиксить немедленно. Их фиксят. И теперь внимание — в новом билде состояние системы больше не известно, а старый никому больше не нужен. И известно оно станет через только 2 недели. А если там найдут еще критический дефект то это еще 2 недели И кончится тем, что эта бодяга всем надоест и на клиента уедет недотестированный продукт.
От этой беды есть 2 пути. Порочный — наращивать количество тестеров чтобы превратить 2 недели в пару дней (в приделе это приведет к дебилизму из серии 1 тестер — 1 дев). И непорочный — писать acceptance и по-модульные функциональные тесты. При правильном подходе после этого в системе останутся только интеграционные ошибки. И количество необходимых тестеров снизится до соотношения 1-10.

H>Если есть продукт, то более важным является функциональное и стрессовое тестирование законченного продукта.

... осуществляемое автоматически.

Здравствуйте, EM, Вы писали:

EM> Порочный — наращивать количество тестеров чтобы превратить 2 недели в пару дней (в приделе это приведет к дебилизму из серии 1 тестер — 1 дев). И непорочный — писать acceptance и по-модульные функциональные тесты. При правильном подходе после этого в системе останутся только интеграционные ошибки. И количество необходимых тестеров снизится до соотношения 1-10.

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

Здравствуйте, olen33, Вы писали:

O>Здравствуйте, EM, Вы писали:

EM>> Порочный — наращивать количество тестеров чтобы превратить 2 недели в пару дней (в приделе это приведет к дебилизму из серии 1 тестер — 1 дев). И непорочный — писать acceptance и по-модульные функциональные тесты. При правильном подходе после этого в системе останутся только интеграционные ошибки. И количество необходимых тестеров снизится до соотношения 1-10.

O>В идеале ручное тестирование должно практически отсутствовать. Весь процесс тестирования надо покрывать автоматическими тестами.

+1. о том и спич

O>А вот для этого как раз и надо иметь достаточное количество тестеров, чтобы они успевали писать автоматические тесты с той же скоростью, с какой разработчики выдают новую функциональность.

Вопрос терминологии. Я под "тестером" имел в виду ручного тестера.

Здравствуйте, MV5, Вы писали:

MV5>Кто есть кто?


Группы ролей:
Анализ. Извлечение, документирование и сопровождение требований к продукту.
Управление. Определение и управление производственными процессами.
Производство. Проектирование и разработка ПО.
Тестирование. Тестирование ПО.
Обеспечение. Производство дополнительных продуктов и услуг.


Группа анализа
Бизнес-аналитик. Построение модели предметной области (онтологии).
Бизнес-архитектор. Разрабатывает бизнес-концепцию системы. Определяет общее видение продукта, его интерфейсы, поведение и ограничения.
Системный аналитик. Отвечает за перевод требований к продукту в функциональные требования к ПО.
Специалист по требованиям. Документирование и сопровождение требований к продукту.
Функциональный заказчик (заинтересованное лицо). Представляет в проекте интересы пользователей продукта.

Группа управления
Руководитель проекта. Отвечает за достижение целей проекта при заданных ограничениях (по срокам, бюджету и содержанию), осуществляет операционное управление проектом и выделенными ресурсами.
Куратор проекта. Оценка планов и исполнения проекта. Выделение ресурсов.
Системный архитектор. Разработка технической концепции системы. Принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.
Руководитель группы тестирования. Определение целей и стратегии тестирования, управление тестированием.
Ответственный за управление изменениями.
Ответственный за управление конфигурациями.
Ответственный за сборку и поставку программного продукта.

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

В большом проекте может быть несколько производственных групп, ответственных, за отдельные подсистемы. Как правило проектировщик выполняет роль лидера группы и управляет своим подпроектом или пакетом работ. Стоит не забывать, что Руководитель проекта делегирует полномочия, но не ответственность.


Группа тестирования
Проектировщик тестов. Разработка тестовых сценариев.
Тестировщик. Тестирование продукта. Анализ и документирование результатов.

Группа обеспечения
Технический писатель.
Переводчик.
Дизайнер графического интерфейса.
Разработчик учебных курсов, тренер.
Участник рецензирования.
Продажи и маркетинг.
Системный администратор.
Технолог.
Специалист по инструментальным средствам.
Как правило не входят в команду проекта. Выполняют работы в рамках своей процессной деятельности.


Совмещение и разделение ролей
Зависит от масштаба проекта. Одну роль могут исполнять несколько человек. Например: разработчики, тестировщики, технические писатели.
Один человек может исполнять несколько ролей. Некоторые роли может исполнять только один человек. Например, Руководитель проекта, Системный архитектор.

Возможно:
Руководитель проекта + Системный аналитик (+ Системный архитектор)
Системный аналитик + Проектировщик тестов (+ Технический писатель)
Системный аналитик + Проектировщик интерфейса пользователя
Ответственный за управление конфигурациями + Ответственный за сборку и поставку (+ разработчик)

Не рекомендуется:
Руководитель проекта + Разработчик
Разработчик + Системный аналитик.
Разработчик + Проектировщик интерфейсов пользователя.
Разработчик + Тестировщик


(с) RUP, Wikipedia и другие источники.

Вольный пересказ.

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

Например, нарисовано по ПМу на проект, и 1 архитектор на все проекты. Реально делается иначе — 1 ПМ на всех, и по архитектору на каждом проекте.

Причина в том, что у ПМа меньше нагрузка текущими делами, т.е. нужда в 1 фуллтайм ПМ возникает при большем количестве людей, чем в 1 архитекторе.

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

Ближе к делу. Роли "архитектор" и "ведущий девелопер" предъявляют примерно одинаковые требования к человеку. Там разные не люди. Там разные функции у примерно одинаковых людей. И то, и другое — это опытный именно что разработчик.

Что же до роли "ПМ" — то там совсем другое. Совсем. Роль "аналитик требований" — в общем это третье, хотя к "ПМ" это ближе, чем к разработчик. Зачастую еще он же и сэйл, и вообще человек, работающий с клиентурой.

Типичные сочетания ролей в маленьких командах — ПМ+аналитик, и архитектор+лид девелопер. Это принципиально разные работы, работа ПМа — человек-человек, работа архитектора и девелопера — человек-знаковые системы.

__>Как же так? А зачем тогда нужны unit-тесты, которые пишет САМ разработчик? Или разработчикам уже не нужно отлаживать то, что они сами написали?

Есть девелоперское тестирование, есть тестирование в QA.

Первое — это тестирование только на девелоперской машине (без разных конфигураций и версий всего остального софта), тестирование на предмет "оно вообще живет" (выполнить основной путь кода хоть раз), на предмет правильной обработки возможных исключительных ситуаций (выполнить неосновные пути кода). Юнит-тесты с покрытием и собственно coverage analyzis — тоже туда.

Второе — это все то тестирование, которое требует _деплоймента хитрых конфигураций ОС и платформ, виртуальных машин и такого прочего. Туда же — реакция на сложные open issues у клиентов, воспроизведение которых сложно по сложности инсталляции всех нужных софтов. Туда же — просто тупая отработка test matrices — такой-то сценарий на таких-то версиях в таких-то режимах.

Тестеры постоянно что-то инсталлируют. Это занимает большую часть их времени.

Такое разделение очень разумно, и вот почему: на тестера взваливается все то, где не надо знать собственно сам код. На него взваливается рутина, которая стоит столько-то часов независимо от квалификации исполнителя, и потому лучше ее взвалит на малоквалифицированного, чтобы не тратить время серьезного девелопера.

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

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

+1

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

EM>От этой беды есть 2 пути. Порочный — наращивать количество тестеров чтобы превратить 2 недели в пару дней (в приделе это приведет к дебилизму из серии 1 тестер — 1 дев). И непорочный — писать acceptance и по-модульные функциональные тесты. При правильном подходе после этого в системе останутся только интеграционные ошибки. И количество необходимых тестеров снизится до соотношения 1-10.

Свежо предание...

Самый главный источник багов при наличии более или менее адекватного тестирования — интеропы и редко возникающие хитро пограничные случаи (т.е. условия воспроизведения бага — 5 фраз, соединенных оператором AND).

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

К счастью, именно эти баги имеют обычно низкий приоритет из-за небольших значений метрик reproduceability и affected users.

EM>Вопрос терминологии. Я под "тестером" имел в виду ручного тестера.

Написание тест-сьютов, не требующих знания кода продукта и тестирующих продукт как более или менее целое — тоже работа тестера, а не девелопера.

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

K>а капитан футбольной команды должен хоть когда-нибудь играть в футбол

Совершенно верно. Тимлид — играющий тренер.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Самый главный источник багов при наличии более или менее адекватного тестирования — интеропы и редко возникающие хитро пограничные случаи (т.е. условия воспроизведения бага — 5 фраз, соединенных оператором AND).

MSS>Покомпонентное тестирование вообще не увеличивает шансы отлова вот этих радостей. Тут нужно тестировать "вширь" (по количеству сценариев), а не "вглубь" (по архитектуре).

Согласен. Наш единственный ручной тестер в команде из ~10 пишущих человек примерно этим и занимается. И его вполне хватает. Потому что решена проблема того, что состояние системы определено только во время между окончанием тестирования и внесением первого фикса в билд. Состояние зафиксировано тестами. ОК, пусть на 80-90 % а не на 100, "все равно хорошо" (С).

К слову, если тут кто есть из МС и Гугла, просветите : Много ли у вас тестируют руками ? Я вот думаю что нет.

MSS>К счастью, именно эти баги имеют обычно низкий приоритет из-за небольших значений метрик reproduceability и affected users.
+1

C>Эти две векти работают в параллель. Так, программерская ветка может строчить 1.0, а аналитика уже фигачит требования к 3.0 версии, а архитектор корпеет над 2.0

Плохо.

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

Более того, само деление на 2.0 и 3.0 зачастую происходит уже потом, после продумывания архитектуры под фичи. То есть сначала есть общая масса фич из серии "хорошо бы", потом есть эта же масса фич, но с продуманной архитектурой ("ясно, как будем реализовывать"), и уже потом эту массу распределяют по временной шкале и делят на 2.0 и 3.0.

В девелопменте при этом да, может быть и 1.0.

Здравствуйте, craft-brother, Вы писали:

CB>(с) RUP, Wikipedia и другие источники.

CB>Вольный пересказ.

В общем, спасибо.
Действительно, мне надо было сначала в WiKi заглянуть.

EM>Согласен. Наш единственный ручной тестер в команде из ~10 пишущих человек примерно этим и занимается. И его вполне хватает. Потому что решена проблема того, что состояние системы определено только во время между окончанием тестирования и внесением первого фикса в билд. Состояние зафиксировано тестами. ОК, пусть на 80-90 % а не на 100, "все равно хорошо" (С).

Я думаю, что 100% охват тестами каждого публичного билда — утопия. Тестировать там ИМХО надо только то, на что могло повлиять последнее изменение, и что изменение правильно работает, и что не сломано ранее работавшее.

Собственно, микрософт именно так тестирует _хотфиксы_ на WU. Вот сервис-паки и релизы ОС тестируются уже намного более тщательно, с фазами binary freeze.

Типичное распределение трудозатрат по процессам в коммерчекой разработке ПО:

– 10% Управление
– 10% Конфигурирование
– 10% Управление требованиями
– 15% Проектирование
– 25% Разработка
– 25% Тестирование
– 5% Документирование

Итого: 100%

Где-то, так.

Это был упрощенный пример как это может работать. Не более того.
На деле же есть куча нюансов. Так, например, то, что ты пишешь более-мение подходит под разрабоку коробошного продукта, но малоэффективно, скажем, при разработке долгоиграющего заказа, где есть, например, график выхода версий.
ИМХО тем RUP и хорош, что его всегда можно подогнать под конкретные условия.

C>На деле же есть куча нюансов. Так, например, то, что ты пишешь более-мение подходит под разрабоку коробошного продукта, но малоэффективно, скажем, при разработке долгоиграющего заказа, где есть, например, график выхода версий.

График выхода версий тебе тоже не сверху спускается, а создается по ходу тех же процессов. Людям на самом деле нужны не версии, а фичи . Сравнительные приоритеты разных фич при этом могут меняться динамически по воле заказчика, значит — меняется объем понятия "версия 2.0" (какие-то фичи вынесли в 3.0), а значит — и графики.

Всегда, решительно всегда есть добро в том, чтобы ознакомить архитектора — а то и лид-девелоперов — с фичами, которые, возможно, понадобятся через 3 версии после данной. Чтобы имели в виду.

CB>Типичное распределение трудозатрат по процессам в коммерчекой разработке ПО:

CB>– 10% Управление
CB>– 10% Конфигурирование
CB>– 10% Управление требованиями
CB>– 15% Проектирование
CB>– 25% Разработка
CB>– 25% Тестирование
CB>– 5% Документирование

CB>Итого: 100%

CB>Где-то, так.

Ага, только вот не ясно, что такое конфигурирование, а еще нет в этой схеме _саппорта_, что делает ее всю детсадовской игрушкой. Саппорт состоявшегося продукта — процентов 60 усилий, саппорт-инженеров и девелоперов в сумме.

Собственно, процентов 50 объема работ к следующему майлстону — это support issues, и баги, и мелкие доработки по просьбам клиентов, которые не пришли в голову на этапе анализа требований.

Это еще хороший анализ требований. При плохом будут не мелкие доработки, а крупные переделки.

И даже без саппорта схема неверна. Если брать просто по часам и людям (чтобы оценить сроки и потребности в персонале), то разработка раз в 20-50 больше проектирования. Проектирует 1 архитектор 1 месяц, разрабатывают потом 10 девелоперов 2-5 месяцев. Это нормально.

Здравствуйте, Maxim S. Shatskih, Вы писали:


MSS>Ага, только вот не ясно, что такое конфигурирование, а еще нет в этой схеме _саппорта_, что делает ее всю детсадовской игрушкой. Саппорт состоявшегося продукта — процентов 60 усилий, саппорт-инженеров и девелоперов в сумме.

MSS>Собственно, процентов 50 объема работ к следующему майлстону — это support issues, и баги, и мелкие доработки по просьбам клиентов, которые не пришли в голову на этапе анализа требований.

MSS>Это еще хороший анализ требований. При плохом будут не мелкие доработки, а крупные переделки.

Максим, а почему ты решил, что сапорт предыдущего релиза или продукта входит в новый проект? Сапорт, имхо, устранение багов в работающем у клиентов релизе в соответствие с SLA. Это операционная деятельность, которую не следует относить к проекту. Если участники проекта в этой деятельности задействованы, то надо соответствующим образом раскладывать их рабочие часы, например, 60% — на проект, 30% — на сапорт, 10% — на проч. административную деятельность. Если речь идет о реализации в новом релизе фич, которые затребовали заказчики, то это не сапорт а R&D.


MSS>И даже без саппорта схема неверна. Если брать просто по часам и людям (чтобы оценить сроки и потребности в персонале), то разработка раз в 20-50 больше проектирования. Проектирует 1 архитектор 1 месяц, разрабатывают потом 10 девелоперов 2-5 месяцев. Это нормально.

Теперь об объеме проектирования. Если ты полагаешь, что проектированием занимается только системный архитектор, то, по это не так. Системный архитектор проектирует на высоком уровне: подсистемы, их взаимодействия, внешние интерфейсы. Разработка каждой подсистемы тоже требует проектирования: компоненты-классы-интерфейсы-алгоритмы. Этой работой, как правило, занимаются проектировщики (тим-лиды), ответственные за разработку конкретных подсистем, и непосредственно программисты, разрабатывающие пакеты и классы. 15% на проектирование это — минимум для относительно простых проектов. Системы реального времени, телеком, системное ПО требуют больших затарат на проетирование.

В принципе, видел проекты без архитектуры: порезали продукт на фичи и давай параллельно кодировать, — результат большой (в 2-5 раз больше, чем возможно при правильном проектировании) и проблемный код, поддержка которого действительно может съесть все время команды, а не только 60%.

MV5>Ну с девелоперами вроде более менее понятно (хотя как человек узнает что он уже не Developer а Senior Developer? В трудовой разряд другой напишут? )

В трудовой напишут "старший прграммист"/"программист"/"ведущий программист"/"руководитель проекта"
Да и должности в трудовой коррелируют более со штатным расписанием, нежели с проектной ролью.
Тимлидер/архитектор/ПМ — это все же проектная роль (на одном проекте ты ТЛ, на другом ПМ, на третьем — просто дев, вполне нормально), а в трудовой книжке записывается твоя должность, которая, скорее всего, будет что-т вроде "Инженер по разработке ПО". Для перевода на другую должность нужен соответствующий приказ, доп. соглашение к трудовому договору . Поэтому если человека просто назначили на проект тимлидом или архитектором, это вовсе не значит, что произойдут какие-то изменения в трудовой книжке.

MV5>Так все-таки чего ожидать когда в вакансиях пишут "тимлид" и "архитектор"? И что будут ожидать от меня когда я напишу в резюме "тимлид" или "архитектор"?

Спрашивать будут больше и жестче. А берут всех изначально все равно на девелоперов, а там уж — как вырастешь.

Здравствуйте, MV5, Вы писали:

Всем спасибо за ответы.

PS
Может что-нибудь (я имею ввиду книги) посоветуете почитать по организации разработки ПО, RUP?
Я конечно сам могу поискать, но совет все равно будет лучше.

Здравствуйте, MV5, Вы писали:

MV5>Может что-нибудь (я имею ввиду книги) посоветуете почитать по организации разработки ПО, RUP?

Rational Unified Process – это легко, Пер Кролл, Филипп Крачтен

Здравствуйте, Maxim S. Shatskih, Вы писали:

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

MSS>+1

MSS>Юнит-тесты вообще нужны только в конкретных, хорошо инкапсулированных компонентах, причем в тех, где высока цена бага — т.е. прогнать юнит-тесты с анализом покрытия намного проще по часам, чем вылавливать баг, если он там таки случится.

Позволю себе не согласиться: в идеале юнит-тесты нужны везде. А не в идеале — нужно 40%-80% покрытие юнит-тестами, иначе проект довольно быстро (по моим наблюдением — через 100 разработчико-дней) перевалит за ту черту, где каждый fix или change request потенциально уменьшает стабильность проекта.

MSS>Я думаю, что 100% охват тестами каждого публичного билда — утопия. Тестировать там ИМХО надо только то, на что могло повлиять последнее изменение, и что изменение правильно работает, и что не сломано ранее работавшее.

Ыыы... Проблема в том, что очень уж трудно локализовать ВСЕ то, на что могло повлиять изменение. Особенно если взаимозависимость патча и других кусков кода какая-нить западлистая и неочевидная.