Моё меню Общее меню Пользователи Правила форума Все прочитано
Вернуться   uForum.uz > ИКТ и телеком > IT-индустрия > Системы управления процессами
Знаете ли Вы, что ...
...до того как открыть новую тему, стоит использовать поиск: такая тема уже может существовать.
<< Предыдущий совет - Случайный совет - Следующий совет >>

Системы управления процессами Раздел для обсуждения систем управления задачами, определения преимуществ и недостатков, проведения сравнений с системами документооборота


Ответить

 
Опции темы Опции просмотра
Старый 03.12.2012 00:00   #21  
Known ID Group
Аватар для netklon
Оффлайн
eSector Solutions
Интерфейс-самурай, Девелопмент-генерал
Сообщений: 2,774
+ 788  1,915/912
– 24  61/32

UzbekistanLiveJournalМой Круг
Цитата:
Сообщение от Anton Kovalenko Посмотреть сообщение
Цитата:
Сообщение от netklon Посмотреть сообщение
Детальное ТЗ на проект длиной более 3-х месяцев устаревает уже через месяц.
По каким причинам чаще всего?
Ну как по каким причинам? Изменились обстоятельства. Конкуррент выпустил фичу, появился новый партнер, первичное тестирование раннего прототипа выявило проблемы. Кратко: это жизнь.

Цитата:
Сообщение от Anton Kovalenko Посмотреть сообщение
Цитата:
Сообщение от netklon Посмотреть сообщение
С заказчиками мы обычно работаем короткими (2-4 недели) проектами, и там сроки и требования фиксированные, то есть как бы не agile.
Ну тады ой. Меня интересует именно то, как народ на практике разводит все проблемы, связанные с итеративностью и постоянным изменением/обновлением требований.
Насколько знаю в клиент-ориентированной разработке agile применяют в основном в аутсорсинге, с оплатой за time and materials, а не попроектно.
Ответить 
4 "+" от:
Реклама и уведомления
Старый 03.12.2012 17:50   #22  
Known ID Group
Аватар для Sergey Rudakov
Оффлайн
Orca Group
Директор
Сообщений: 148
+ 55  193/67
– 4  11/4

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

1. От продакт оунера в первую очередь поступает раудмэп на релиз (примерно 1-1,5 месяца) – в виде хотелки с приоритетами. Никаких спецификаций на пока.
2. По нему прикидываются примерные сроки и разбиваются зоны отвественности разработчиков. Тут конечно много пространства для воображения и додумывания. Это не конечное деление на задачи и подзадачи а условные milestone, по которым оунер в первую очередь ориентируется в прогрессе реализации. А нам хотя бы дает какую-то возможность прикинуть, в какую сторону ветер дует, понять, где есть потенциальные проблемы, прикинуть технологические аспекты и т.д.
3. На основании оценок сроков формируются итерации (1-2 недели). На выходе итераций, как правило, то, что имеет отражение и заметно для пользователя на продукте.
4. По итерациям предоставляются спецификации в виде Block Description – деление на минимально возможную функциональную единицу, которая имеет какое-то визуальное представление в продукте. Block Description – документация для разработчиков. Каждый блок не равен задаче для разработчика, тем не менее, и делиться на адресные задачи разработчикам.
5. Для тестировщика описываются Use Case – сценарии, по которым пользователи предположительно действуют используя продукт.
6. До начала итерации формируется четкое ТЗ на ближайшую итерацию, в ходе девелоринга итерации прорабатываются ТЗ на последующую итерацию и Use Case для проверки текущей.
7. После завершения итерации на тест уходит результат на основе Use Case, срочные баги фиксяться на месте. То, что посложней переносится на релизную отладку, закладываются в релиз бэклог. Обычно нерасторопность оунера дает время на багфиксинг в периоды между релизами.
8. В случае наших темпов во время итераций невсегда есть время даже на формирование списка задач в какой-то среде, типа JIRA. Это внутрянняя кухня разработки и неособо парит оунера, поэтому мы вольны в выборе и заменено на графики и списки задач просто на доске, или в виде коротких тезисов в бэклоге итерации и т.д. Ежедневные скрам митинге со временем теряют свою актуальность и значимость и заменяются частыми, суперокороткими статус апдейтами (1-3 раза в день в зависимости от длительности текущих задачек).
9. Задачи привязываются неявно к исполнителю. Если кто-то подзатянул со своей текущей задачей (а такое случается местами), его компенсирует другой разработчик, который преуспел на своих задачах.
10. Разработчки (хвала им!) не брезгуют и на С пописать, и на Питоне, и на Жава скрипте, а где надо и верстку подправят, где есть потребность. Кстати, если все разработчики в среде узкопрофильные, то применение agile выглядит очень спорно
11. На роудмэпе уже, как правило, заметны критические пути. Обычно они в сфере аутсорса и внешних данных (верстка, проектная документация и т.п.). от этих критических путей и выстраивается привязка по задачам.

Описано сумбурно, но суть в том, что сами итерации проходят по каскадным принципам (требования-планирование-разработка-тестирование-отладка ), а сдвижка фаз дает место для гибкости.
Для нас документация подается подается от оунера. В таком сценарии развития она предоставляется по принципу набегающей волны. До того, как она не нужна, она нам действительно ненужна в полном масштабе. А к моменту, когда она публикуется, она уже может включать в себя более актуальную постановку задачи, включение каких-то приоритетных задач из бэклога, запросы на изменения по опыту предыдущих итераций и т.д., т.е. есть маневр подстроиться под «изменчивость обстоятельств». Надо отметить, что в нашем случае документация никогда не является исчерпывающей и темные места уточняются непосредствено между исполнителем задачи и писателем, как правило в групповых чатах, чтобы все члены разработки были в курсе. Если объем уточнений достаточно большой и важный, обновляется соответствующий кусок документации.
Ответить 
Старый 03.12.2012 19:27   #23  
Real ID Group uParty Member Ultimate Arsenicson
Аватар для Anton Kovalenko
Оффлайн
Toronto Dominion Bank
Бизнес-аналитик
AKA:Arsenicson
Сообщений: 5,486
+ 943  5,841/2,221
– 302  324/206

CanadaОтправить сообщение для Anton Kovalenko с помощью ICQОтправить сообщение для Anton Kovalenko с помощью YahooОтправить сообщение для Anton Kovalenko с помощью Skype™LiveJournalМой КругFacebook
Sergey Rudakov, шикарный ответ, большое спасибо!
Юз кейсы как документируете - UML или подробно, словами?

Последний раз редактировалось Anton Kovalenko; 03.12.2012 в 19:31.
Ответить 
Старый 03.12.2012 19:37   #24  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Сообщение от Sergey Rudakov Посмотреть сообщение
формируется четкое ТЗ
Что из себя представляет ТЗ? Документ по ГОСТу, по другому стандарту или что-то свое?
__________________
404 Not Found
Ответить 
Старый 04.12.2012 11:39   #25  
Known ID Group
Аватар для Sergey Rudakov
Оффлайн
Orca Group
Директор
Сообщений: 148
+ 55  193/67
– 4  11/4

Uzbekistan
Цитата:
Сообщение от Anton Kovalenko Посмотреть сообщение
Юз кейсы как документируете - UML или подробно, словами?
словами. Тестировщик для нас на текущем этапе заменяет обычного пользователя, поэтому проверяет адекватность реагирования системы на действия пользователя.

Цитата:
Сообщение от shumbola Посмотреть сообщение
Что из себя представляет ТЗ? Документ по ГОСТу, по другому стандарту или что-то свое?
не знаю я, как можно стандартизировать блоки в ТЗ. Они очень разношерстные, где-то описывается механика с формулами, где-то визуальная часть и интерактив с пользователем. Суть ТЗ в том, чтобы разработчик понял, что от него хочет оунер. А как выглядит и структурирован документ - вторично и несущественно. Со временем, когда команда срабатывается, уже начинаешь понимать, что ожидается, даже если это явно не указано в спеке
Ответить 
Старый 04.12.2012 20:22   #26  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Сообщение от Sergey Rudakov Посмотреть сообщение
не знаю я, как можно стандартизировать блоки в ТЗ. Они очень разношерстные, где-то описывается механика с формулами, где-то визуальная часть и интерактив с пользователем. Суть ТЗ в том, чтобы разработчик понял, что от него хочет оунер. А как выглядит и структурирован документ - вторично и несущественно. Со временем, когда команда срабатывается, уже начинаешь понимать, что ожидается, даже если это явно не указано в спеке
Из сказанного я сделал ввод, что все-таки ваше ТЗ - что-то свое - вами же изобретенный документ.
И ничего плохого в этом нет, если конечная цель достигается этим. Я видел много изобретений велосипедов. ;-)
__________________
404 Not Found
Ответить 
Старый 11.12.2012 08:40   #27  
Real ID Group uParty Member Ultimate Arsenicson
Аватар для Anton Kovalenko
Оффлайн
Toronto Dominion Bank
Бизнес-аналитик
AKA:Arsenicson
Сообщений: 5,486
+ 943  5,841/2,221
– 302  324/206

CanadaОтправить сообщение для Anton Kovalenko с помощью ICQОтправить сообщение для Anton Kovalenko с помощью YahooОтправить сообщение для Anton Kovalenko с помощью Skype™LiveJournalМой КругFacebook
Оффтоп:
всю текущую неделю участвую в буткэмпе, который ведет один из создателей BABOK
Ответить 
Ответить
Опции темы
Опции просмотра




Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Advertisement System V2.5 By Branden
OOO «Единый интегратор UZINFOCOM»


Новые 24 часа Кто на форуме Новички Поиск Кабинет Все прочитано Вверх