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

×


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

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


Сообщения - SALar

Страницы: « 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 »
301
Цитировать
Цель руководителей таких предприятий снизить расходы на топливо, уменьшить износ техники
Я тоже с этого тоже долго смеялся. Не должно быть такой цели.

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

А какие есть способы чтоб группировать БП? где об это можно почитать.

Ищите: "ПРОИЗВОДСТВЕННЫЙ МЕНЕДЖМЕНТ: УПРАВЛЕНИЕ ПОТОКОМ" Одед Коуэн, Елена Федурко, и прочие статьи Одед Коуэна

302
Коллеги, у кого-нибудь есть опыт работы с TrackStudio? Интересует именно работа с документацией.
У меня есть. Система интересная. По моей оценке рвет как Тузик грелку и джиру и редмайн.
Но для работы с документацией мы ее используем относительно слабо. все таки контент менеджмент система должна отличаться от трекера.

303

Что Вы используете?

Предлагаемые варианты:
- MS Word.
- PDF.
- CHM.
Иногда распчатка. Но чаще word.

304
Методологии / Re: Обзор методологий
« : 17 Февраля 2012, 16:17:35 »
Из моих комментариев к статье двухгодичной давности:

> Гибкий метод... XP.
Горькая правда в том, что RUP не просто гибче XP, он в соревновании по гибкости рвет это XP как болид формулы-один рвет детский педальный автомобиль.

> Слайд 29.
> Также крайне важно, чтобы ни постановка задач, ни их количество, ни сроки Спринта, над
которым уже трудится команда, не менялись.
Офигеть какая гибкость. RUP и MSF тихо ржут в углу.

> Ретроспективный анализ.
Меня тренировали его просводить на тренингах по управлению в 1986 году. Скрама в  то время не то что в проекте не было...

305
И по такой цене...

306
Что любопытно, бОльшая часть докладов не про Agile, а про процессы. Черт, очередная конфа про процессную разработку. Когда ж это кончится? Сделает ли кто нибудь конфу про людей и коммуникации?

307
Методологии / Re: Обзор методологий
« : 17 Февраля 2012, 12:49:08 »
Мы используем что-то производное от РУП, что есть:
1. БМ
2. СМ + польз. требования
3. Дет. требования + UI
4. Проектирование
5. Реализация
6. Тестирование
7. Управление изменениями.
Использую примерно тоже самое.

Вместо "5. Реализация" пишу "5. Конструирование", т.к. руководство пользователя тоже является частью продукта.
Вместо "6. Тестирование" пишу "Контроль качества", т.к. "Тестирование" достаточно узкое понятие
А в целом похоже.

PS. И естественно, стремимся к Agile. Процессы - пофиг, лишь бы работали. На одном проекте будет так, на другом этак. А вот выстраивание отношений в группе - этому уделяю прилично времени.

308
"Использование этаноловой интоксикации для:
* изменения каналов коммуникации
* выявления требований
* проведения ПСИ"

Еще остается добавить "использование веществ для при фиксации требований" и набор будет полон...

309
Есть еще более интересное наблюдение. Если не брать во внимание критичность дефектов, то число зафиксированных дефектов линейно (близко к линейному) зависит от времени на тестирование.
10 тестировщиков находят  от 2000 до 10 000 в год.
Когда я вел на проекте свои метрики я был удивлен насколько близко к линейному был мой личный счет найденных дефектов.
------
Добавьте времени и будет не 3, 10 дефектов на фичу на том же самом продукте.

310
2july.
Вы будете удивлены, но хорошие, качественные тренинги по тестированию также проводят тренера, сотрудничающие с uml2.ru

311
Один из вариантов набора инструментов БА описаны в книге У. Детмера. "Теория ограничений Голдратта."
Быстро посмотреть можно тут: http://theory-c.ru/opredelenie-derevo-budushhej-realnosti/2

312
Я правильно понял, что Agile больше подходить для маленьких и иногда средних проектов (по сложности системы)?
Нет, неправильно.

Scrum действительно больше подходить для маленьких  (до десяти человеко лет) и почти никогда не подходит для средних проектов.
Что касается сложных, то непонятно как мерить... Пожалуй, что не стоит применять Scrum для разработки встроенного ПО. Банковских систем. Систем критичных к разделению прав. И т.д.
Agile же вообще вполне может использовать полный набор артефактов и ролей из RUP. И не перестанет при этом быть Agile. Также никто не мешает разрабатывать одновременно по ГОСТ и Agile. В том числе и очень сложные и очень большие системы.

313
Поэтому Agile и рекомендуется к использованию только опытным и слаженным командам.
Это неправда сразу по нескольким пунктам.
1. Как утверждают продавцы гербалайфа "консультанты" их SCRUM всегда лучше.
2. Agile всего лишь утверждает, что люди важнее процессов. Т.е. люди там могут быть разной опытности.
3. RUP так же "рекомендуется к использованию только опытным и слаженным командам."


Цитировать
В основе RUP лежат следующие принципы:

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

314
Согласно методике Agile -> Scrum  необходимо итерациями получать требования от заказчика, в том числе и после показания временного решения. В том числе что то изменять в уже существующем коде.
Это неправда сразу по нескольким пунктам.
1. Scrum  это постулирует, Agile - нет.
2. RUP, MSF и водопад постулирует порционное итерационное поступление требований.
Принципиальное отличие состоит в распределении весов этих поступлений в зависимости от времени.

При этом, если идет такой "поток задач", то откуда берется зафиксированная конечная архитектура решения и как можно гарантировать что:
1) Себестоимость проекта не "съедает"  маржу
2) Система выполнена качественно, а не в виде "нагроможденных" блоков программы
3) Что заказчик, принимая работы согласиться под свою ответсвенность подписаться под ТЗ (или тем документом, который описывал систему), которе будет неактуально на конец работ ?
Никак нельзя. Если делать по Scrum  что-то более-менее приличное по размеру, ну хотя бы юзкейсов на 500, то результат скорее всего окажется "несколько неожиданным". При этом Scrum  будет неплохо подходить для поддержки подобной системы, при условии, что разрабатывали его по более пригодному для таких систем ЖЦ. И то через несколько лет Scrum-а даже при гениальной начальной архитектуре и дизайне получится нечто не очень потребное. Но к этому времени, к счастью система устареет и ее будет логично просто заменить.

315
9. Отличия системного и бизнес аналитика. Отличие в объекте, инструментах, артефактах.
Кто-то хочет взять на себя доклад или круглый стол?

10. Целеполагание и формулировка цели. Конкретные примеры плохих и хороших целей с последовательным разбором.

Страницы: « 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 »