1

Управление Проектом / Re: Зачем аналитику знать трудоемкость реализации требований?

« : 04 Июля 2012, 18:27:29 »

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

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

Для точных оценок поддержу предложенные Анной варианты, к ним и добавить-то особо нечего, единственное - фактическая трудоемкость реализации требования может пригодиться для оценки трудоемкости/сроков *будущих* проектов, если требования *переиспользуются*.

Если тим-лид по-прежнему не верит в то, что требования можно оценивать, то следует его познакомить с методиками Use Case Points, Funtion Points Analysis
В общем вывод пока такой: это будет полезно, если этим пользоваться, но использование сильно зависит от компании/команды/проекта/бизнеса/продукта.

2

Методологии / Re: Методология PDM-систем и управление проектами на промышленном предприятии

« : 15 Декабря 2011, 14:12:01 »

Поддержу Tinner, косвенно это подтверждает и недавнее слияние PTC и MKS Integrity, первый - предлагает PLM-решения, второй - ALM (ну скорее SDLC).
http://www.engineering-matters.com/2011/07/ptc-mks/

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

3

ПО Аналитика / Re: Слоёный WORD или другой инструмент для гибкого изменения спецификаций

« : 01 Ноября 2011, 17:14:49 »

Если в системе что-то поменяется, то в 70% придется править две спецификации.

В наши дни редко встретишь настолько ленивого аналитика Похвально.

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

Как мне видится, описан именно этот случай: есть общая архитектура, но есть и отклонения.
На Вашем месте я бы четко обозначил эти места в тексте, отделил бы каким-то визуальным образом (не зря в вариантах использования есть секция "Расширения").

Для текста из "фоновых моментов" установил бы шрифт "Невидимый", таким образом, получил бы печатный вариант для спеки 2. Когда придут изменения для спеки 1, то делаем Ctrl + A, свойства шрифта и "включаем" невидимый текст - вуаля у нас исходная спека 1 с расширениями для спеки 2.

4

Идеи и мозговой штурм / Re: Заказать фич-анализ конкурирущих продуктов

« : 06 Октября 2011, 19:04:09 »

Это понятно, вопрос был не в этом, а в том - где взять того человека, который а) сможет это сделать и б) захочет это сделать, ну кроме варианта "заставить"

5

Идеи и мозговой штурм / Заказать фич-анализ конкурирущих продуктов

« : 06 Октября 2011, 16:35:05 »

Друзья, озадачился вопросом: есть набор фич, есть продукт и есть конкуренты, требуется проанализировать конкурирующие продукты на полноту реализации каждой фичи, качество ее реализации и функциональные расширения фичи.

Кто-то пробовал передавать подобную работу на сторону типа фри-ланса? Как, где? Каковы результаты? Стоит ли связываться?

6

Проектирование / Re: Как стать Архитектором ПО ?

« : 14 Июля 2011, 07:59:25 »

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

вот, кстати, интересный проект для решения озвученной проблемы про "сдохнуть": http://skilltrek.ru/

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

7

Проектирование / Re: Как стать Архитектором ПО ?

« : 13 Июля 2011, 21:30:55 »

Скажите как стать Архитектором ПО ?

1. нужно иметь значительный опыт проектирования и разработки (на нескольких языках и в различных стилях).
2. нужно глубоко понимать технические аспекты ОС, платформы и создания "правильных" решених на них.
3. нужно знать основные паттерны дизайна, архитектурные механизмы и стили, и знать как применять.
4. нужно уметь понимать и выявлять технические риски и знать, как их устранять

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

Вообще-то, это обязанности разработчика, старшего уж точно

То что нужно прочитать много умных книг это понятно (кстати можете подсказать какие-нибудь маст рид книги?), но ведь нужен же еще практический опыт. Где его взять?

Нужно просто работать в этом направлении, архитектор - это следующая стадия эволюции разработчика.
Книги (минимум), рекомендую:

1. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования
2. Л. Басс, П. Клементс, Р. Кацман. Архитектура программного обеспечения на практике
3. Мартин Фаулер, Дейвид Райс, Мэттью Фоммел, Эдвард Хайет, Роберт Ми, Рэнди Стаффорд. Шаблоны корпоративных приложений
4. Мартин Фаулер. Рефакторинг. Улучшение существующего кода

8

ПО Аналитика / Re: Инструмент для генерации ТЗ из issue tracking system

« : 05 Июля 2011, 13:16:29 »

На мой взгляд, проблема в исходной постановке задачи: issue tracking по определению не предназначен для управления требованиями. Если там и есть возможность впихнуть требования, типа как использование соответствующего типа WorkItem в TFS, то основная сложность в семантике этих WorkItem, связей между ними и т.п.

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

Видимо, есть только два реальных варианта: использовать RMS (спец. инструмент для управления требованиями) и надеяться, что там кто-то реализовал экспорт требований по ГОСТ-у, либо реализовывать модуль экспорта в MSWord и, кстати, реальный вариант, если есть разработчики на C#, который готовы изучить TFS API.

Я участвую в разработке DEVPROM - инструмента для ведения проектов по разработке ПО, там есть модуль для управления требованиями. Есть выгрузка в формате MS Word, но к ГОСТ-у отношения не имеющем. Я бы рекомендовал Вам попробовать поуправлять требованиями/тикетами Вшего проекта в этой системе, чтобы лучше понять то, что Вам нужно получить на выходе, прежде чем займетесь разработкой плагинов или модулей экспорта. Как вариант, наша команда может реализовать плагин для выгрузки требований в формате ГОСТ.

9

Управление Проектом / Re: Средство автоматизации доски Scrum

« : 22 Марта 2011, 12:40:06 »

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

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

В очередной версии будет локализованная терминология под Scrum и отображение Историй пользователей в виде доски по умолчанию при создании проекта.

10

Управление Проектом / Re: Средство автоматизации доски Scrum

« : 21 Марта 2011, 11:46:58 »

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

Если не хочется ничего разворачивать самостоятельно, то рекомендую воспользоваться сервисом "Облако проектов", оно бесплатное, с доской Scrum и многим другим. Кстати, тот же инструмент, который там используется, можно захостить и как SaaS (что-то около 200р. за человека в месяце)

11

Проектирование / Re: Можно ли вообще спроектировать и реализовать систему без архитектуры?

« : 17 Октября 2010, 22:09:11 »

На мой взгляд не совсем корректно поставлен вопрос, поскольку архитектура будет присутствовать всегда, вне зависимости от желания или нежелания это замечать

Наверно имелось ввиду: можно ли спроектировать и реализовать нечто без предварительной проработки архитектуры? Если да, то опять же возникает много вопросов:

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

2. само понятие "архитектура" может быть по-разному определено: архитектура как набор базовых принципов (концепции), по которой строится решение, или речь изначально шла о дизайне?

3. Скот Амблер, например, уже несколько лет доказывает жизнеспособность своего подхода к эволюционному проектированию систем/решений (http://www.agilemodeling.com/essays/agileArchitecture.htm)

4. Часто платформа уже навязывает определенные архитектурные аспекты, которые не нужно проектировать, а прост нужно уметь использовать (J2EE, .Net и т.п.)

Если все же постараться дать краткий ответ на исходный вопрос касательно проектирования вперед кодирования, то:

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

12

Реализация / Когда разработка закончена, как быть дальше?

« : 23 Сентября 2009, 11:55:05 »

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

Возможно, еще пригодится кому-то: http://devprom.ru/blog/Новая-услуга-быстрое-создание-сайта-продукта