Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
1066
Обучение / Re: Навыки аналитика
« : 14 Марта 2008, 15:12:56 »
Слава богу, не включили "беспрецедентный". :)

1067
В сегодняшней рассылке citforum анонс книги "Руководство командой разработчиков программного обеспечения. Прикладные мысли.":
http://citforum.ru/SE/project/teams/
Там же ссылка на саму книгу в формате PDF.

Цитата:

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

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

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

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

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

Я как-то не встречал книг, посвящённых именно выбору проектных решений. Кроме энциклопедического труда Кнута, может быть, но это уже история (хотя, может быть, стоит перечитать).

1069
Целостный взгляд может обернуться книгой на 2 тыс. страниц, я не уверен, что такой формат нужен современным инженерам.

У меня есть такая. Называется "Управление программными проектами: достижение оптимального качества при минимуме затрат".
Осилил примерно четверть и бросил. :)

А "инжиниринг" на русский можно перевести как "инженерство".

1070
Цитировать
Учитывая существующие недостатки в хорошем учебнике болжны быть следующие темы (в порядке важности):
1) Глоссарий и базовые абстрактные принципы анализа и разработки;
2) конкретные методы преобразования моделей;
3) конкретные шаблоны и примеры мелкой россыпью.

По аналогии, самый лучший учебник английского языка должен содержать следующие темы (в порядке важности):
1) Англо-русский словарь и базовые правила английской грамматики;
2) Конкретные методы перевода с английского на русский и обратно;
3) Типовые фразы и примеры использования грамматических правил.

 8)

1071
Сегодня на башорге шутка в тему :)

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

1072
Работа / Re: Заказчики
« : 14 Февраля 2008, 13:44:03 »
2. Заставляют делать БЛОХ- схемы - это же 70е годы

Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.

А UML всё-таки не является пока общепринятым стандартом, и не стоит, наверное, разрабатывать документы в предположении, что все читатели его знают. Тем более "бизнес-пользователи".

1073
Не могу согласиться с этим утверждением.

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

А кто хает? Я и на форум-то этот забрёл в поиске теоретических знаний. Потому что почувствовал их необходимость.

Но, во-первых, любая применимая на практике теория - это всё-таки обобщение накопленного опыта. ;)

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

1074
Могу личными впечатлениями поделиться. Есть такая книга: Скотт Беркун, "Искусство управления IT проектами". Автор работал в Microsoft, в частности, над проектом Internet Explorer в эпоху "войны браузеров".

Первый раз прочитал эту книгу года полтора назад, когда меня только "перебросили" с программирования на управление проектами. Прошло мимо мозга - ничего в памяти не осталось. Часто ловил себя на мысли: прочитал главу, а о чём она - не помню. Я, как теперь понимаю, ожидал найти там описание конкретных методик, планов действий по пунктам - делай раз, делай два и т. п. А автор вместо этого растекается мыслями, о методиках говорит уклончиво, даёт какие-то расплывчатые советы типа "можно делать так, а можно и этак, это зависит от масштабов проекта и организации".

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

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

1075
Я тоже пытался искать такие инструмены. Ничего не нашёл. Пытались и сами что-то подобное реализовать. Слишком узкая получалась модель, потребности реальных проектов в неё не втискивались.

Сейчас мы остановились на простой форме тестовых планов в виде файла Excel, а все сопутствующие действия (ту самую рутинную работу) всё-таки делаем вручную - как оказалось, не так уж много времени на неё требуется.

1076
xP Xd Agile ICONIX пр. / Re: Что есть ICONIX
« : 01 Февраля 2008, 12:08:49 »
http://journal.caseclub.ru/articles/iconix.html
по этой ссылке такая очень обчая информация...

Порадовало выражение "процесс Экстремального программирования". :)

1077
xP Xd Agile ICONIX пр. / Re: Кратко про Agile
« : 25 Января 2008, 19:28:53 »
А рассказывать о "некоторых методов" не обязательно?? :)

Я, оказывается, всё это уже описал более подробно в блоге на it4business.ru:

http://it4business.ru/forum/index.php?automodule=blog&blogid=60&showentry=412#comments

1078
xP Xd Agile ICONIX пр. / Re: Кратко про Agile
« : 24 Января 2008, 18:27:58 »
А рассказывать о "некоторых методов" не обязательно?? :)

Чукча теперь больше читатель, чем писатель - времени почему-то всё меньше и меньше :(

Если коротко:
- работа по итерациям. Это оказалось трудно, потому что параллельно ведётся много проектов;
- ежедневная пятиминутка (SCRUM-meeting), где каждый отвечает на три вопроса: чем занимался завтра, какие были проблемы и нужна ли помощь, чем будешь заниматься сегодня;
- task board (сейчас состоит из четырёх разделов: нераспределённые задачи, в работе, требует тестирования, выполнено);
- практикую работу в паре, но чаще это касается не собственно программирования, а разбора спецификаций, анализа трейсов, рисования диаграмм и т. п. Оказывается, очень действенный метод.

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

1079
xP Xd Agile ICONIX пр. / Re: Кратко про Agile
« : 24 Января 2008, 12:42:10 »
greesha, а конкретно ткнуть носом? что-то тяжко просматривать все темы, пытаясь найти нужное

А кто обещал, что будет легко? :)

Но лучше Асхата, пожалуй, вряд ли кто-то объяснит.

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

1080
xP Xd Agile ICONIX пр. / Re: Кратко про Agile
« : 23 Января 2008, 16:22:18 »
Agile - всего лишь слово, маркетинговая находка. Обычно пропагандисты Agile противопоставляют его процессному подходу, то есть именно графикам фаз и итераций.

Кое-что есть на форуме AgileRussia.ru:
http://agilerussia.ru/forum/index.php

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »