|
|
Знаете ли Вы, что ... | |
...для каждой темы существует свой раздел. Изучите структуру форума. Если соответствующего раздела нет, то всегда есть раздел "Разное" :) | |
<< Предыдущий совет - Случайный совет - Следующий совет >> |
Системы управления процессами Раздел для обсуждения систем управления задачами, определения преимуществ и недостатков, проведения сравнений с системами документооборота |
Ответить |
|
Опции темы | Опции просмотра |
03.12.2012 00:00 | #21 | ||
Цитата:
Цитата:
|
|||
|
Ответить |
4 "+" от:
|
Реклама и уведомления | |
03.12.2012 17:50 | #22 |
Orca Group
Директор
Сообщений: 148
+ 55
193/67
– 4
11/4
|
С принципами 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. На роудмэпе уже, как правило, заметны критические пути. Обычно они в сфере аутсорса и внешних данных (верстка, проектная документация и т.п.). от этих критических путей и выстраивается привязка по задачам. Описано сумбурно, но суть в том, что сами итерации проходят по каскадным принципам (требования-планирование-разработка-тестирование-отладка ), а сдвижка фаз дает место для гибкости. Для нас документация подается подается от оунера. В таком сценарии развития она предоставляется по принципу набегающей волны. До того, как она не нужна, она нам действительно ненужна в полном масштабе. А к моменту, когда она публикуется, она уже может включать в себя более актуальную постановку задачи, включение каких-то приоритетных задач из бэклога, запросы на изменения по опыту предыдущих итераций и т.д., т.е. есть маневр подстроиться под «изменчивость обстоятельств». Надо отметить, что в нашем случае документация никогда не является исчерпывающей и темные места уточняются непосредствено между исполнителем задачи и писателем, как правило в групповых чатах, чтобы все члены разработки были в курсе. Если объем уточнений достаточно большой и важный, обновляется соответствующий кусок документации.
__________________
Успехов вам, мистер Кински |
|
Ответить |
5 "+" от:
|
03.12.2012 19:27 | #23 |
Arsenicson
|
Sergey Rudakov, шикарный ответ, большое спасибо!
Юз кейсы как документируете - UML или подробно, словами?
__________________
Мои: Живой Журнал | Сайт о фотографии | Cтатьи в журнале INFOCOM.UZ | Непопулярные посты на форуме Последний раз редактировалось Anton Kovalenko; 03.12.2012 в 19:31. |
|
Ответить |
04.12.2012 11:39 | #25 |
Orca Group
Директор
Сообщений: 148
+ 55
193/67
– 4
11/4
|
словами. Тестировщик для нас на текущем этапе заменяет обычного пользователя, поэтому проверяет адекватность реагирования системы на действия пользователя.
не знаю я, как можно стандартизировать блоки в ТЗ. Они очень разношерстные, где-то описывается механика с формулами, где-то визуальная часть и интерактив с пользователем. Суть ТЗ в том, чтобы разработчик понял, что от него хочет оунер. А как выглядит и структурирован документ - вторично и несущественно. Со временем, когда команда срабатывается, уже начинаешь понимать, что ожидается, даже если это явно не указано в спеке
__________________
Успехов вам, мистер Кински |
|
Ответить |
04.12.2012 20:22 | #26 | |
Сообщений: 3,327
+ 337
892/590
– 3
31/25
|
Цитата:
И ничего плохого в этом нет, если конечная цель достигается этим. Я видел много изобретений велосипедов. ;-)
__________________
404 Not Found |
|
|
Ответить |
11.12.2012 08:40 | #27 |
Arsenicson
|
Оффтоп: всю текущую неделю участвую в буткэмпе, который ведет один из создателей BABOK
__________________
Мои: Живой Журнал | Сайт о фотографии | Cтатьи в журнале INFOCOM.UZ | Непопулярные посты на форуме |
|
Ответить |
|