Agile development

[Anton Kovalenko]

Господа программеры и их менеджеры, а использует ли кто из вас agile management? Так, чтоб серьезно, по книжке, или почти по книжке :) Вопросы есть. Два основных: по какой книжке/процессу работаете и какую обязательную документацию ведете (backlog в случае Scrum, либо аналоги, плюс что-то еще?) и по каким шаблонам?

[netklon]

Agile это не система, это методология. Считается, что в каждой отдельной agile-команде выстроен собственный процесс, то есть начинали по книжкам, а потом пришли к каким-то собственным решениям и процессным практикам.

[Mansur Kuchkarov]

Антон, почитай обязательно книгу и презентацию Асхата Уразбаева, книга называется "Путеводитель по Scrum. Книга о том, как сделать разработку ПО эффективной".
Читается легко и понятно. Если нужно, вышлю pdf.

[Anton Kovalenko]

Agile это не система, это методология
Я разве иначе сказал? :)
Считается, что в каждой отдельной agile-команде выстроен собственный процесс, то есть начинали по книжкам, а потом пришли к каким-то собственным решениям и процессным практикам.
Вот именно это и интересует, конкретно на практике используемые решения, адаптированные по мере необходимости. Хочу понять кто как под себя это дело подгоняет, опыт изучить.
Антон, почитай обязательно книгу и презентацию
Буду благодарен за материал, но вообще-то теоретического материала море, а я интересуюсь опытом непосредственно тех, кто плуг подогнал под себя, и пашет на нем.

[netklon]

Считается, что в каждой отдельной agile-команде выстроен собственный процесс, то есть начинали по книжкам, а потом пришли к каким-то собственным решениям и процессным практикам.
Вот именно это и интересует, конкретно на практике используемые решения, адаптированные по мере необходимости. Хочу понять кто как под себя это дело подгоняет, опыт изучить.

Антон, отдельно документацию мы практически не ведем. Вся документация — 1) в коде 2) в системе контроля версий 3) в bug tracker-e.

[Anton Kovalenko]

отдельно документацию мы практически не ведем
Требования не документируете? Управление изменениями? Результаты тестирования, хотя бы окончательного, на соответствие требованиям? Ну если не во всех проектах, то хотя бы для самых крупных?

[azim]

Требования не документируете? Управление изменениями? Результаты тестирования, хотя бы окончательного, на соответствие требованиям? Ну если не во всех проектах, то хотя бы для самых крупных?
wiki, не?

[Anton Kovalenko]

wiki, не?
вообще-то теоретического материала море, а я интересуюсь опытом непосредственно тех, кто плуг подогнал под себя, и пашет на нем

[netklon]

отдельно документацию мы практически не ведем
Требования не документируете? Управление изменениями? Результаты тестирования, хотя бы окончательного, на соответствие требованиям? Ну если не во всех проектах, то хотя бы для самых крупных?

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

Документирования требований для своих проектов не ведем — это пустая трата времени. Максимум — документ-обсуждение в Google Docs для согласования общего видения, и по результатам задача в bug-tracker-e.

Что про управление изменение и результаты тестирования тебе интересно?

[shumbola]

Документирования требований для своих проектов не ведем — это пустая трата времени.
Как вы пришли к такому выводу?
А прототипы интерфейсов на основе чего разрабатываете? Как потом тестируете?
Что такое общее видение?

[Erkin Kuchkarov]

Что такое общее видение?
Наверняка концепция. Ну оно и понятно - концепция ни к чему не обязывает
А прототипы интерфейсов на основе чего разрабатываете?
А ты понял что это? Я - нет.

[azim]

Я не про википедию, а про вики как метод/стиль ведения документации.

[Anton Kovalenko]

Документирования требований для своих проектов не ведем — это пустая трата времени.
Как тогда предотвращаете scope creep, feature creep и, наконец, "я говорил совсем по-другому!" со стороны заказчика?
Что про управление изменение
Да собственно все то же: как фиксируется исходное требование, само изменение, как планируется внесение изменения исходя из запланированного числа итераций?
результаты тестирования
Документация, где фиксируются окончательные требования и соответствие им конечного продукта по результатам тестирования. Вы же как-то завершение проекта подписываете?
Я не про википедию, а про вики как метод/стиль ведения документации.
Содержание интересует, набор фиксируемой информации плюс сам процесс. Используемая технология интересует меньше, так как вариантов много, но в принципе тоже интересна.

[JackDaniels]

в тему вроде http://habrahabr.ru/company/scrumguides/blog/161029/

[shumbola]

Что такое общее видение?
Наверняка концепция. Ну оно и понятно - концепция ни к чему не обязывает

Ну не знаю, может быть еще чего-нибудь у них.

А прототипы интерфейсов на основе чего разрабатываете?
А ты понял что это? Я - нет.
Честно говоря, пока мало информации. Подождем...

[Anton Kovalenko]

А ты понял что это? Я - нет.
Учитывая то, что требования зачастую в первую очередь касаются представлений заказчика об интерфейсе и юзабилити, это как раз я вроде как понял :) Но прототипирование по идее должно руководствоваться какими-то исходными требованиями, и если они не будут должным образом проработаны и продуманы, количество итераций может быть бесконечным, а половина из них - бесполезными.

[Anton Kovalenko]

в тему вроде http://habrahabr.ru/company/scrumguides/blog/161029/
Почти в тему - еще один теоретический материал. На эту тему есть целый BABOK вообще-то :) хотя тема agile там проработана слабо, но основные методики работы с требованиями описаны хорошо, все остальные, по сути, деривативы.

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

Однако, от заказчиков программной разработки, мы часто ожидаем получить готовую спецификацию требований.
Сижу и думаю: кому в здравом уме может прийти в голову ожидать от заказчика полностью готовую спецификацию требований? Такое даже во сне редко бывает, по-моему :)

[netklon]

Документирования требований для своих проектов не ведем — это пустая трата времени.
Как вы пришли к такому выводу?
А прототипы интерфейсов на основе чего разрабатываете? Как потом тестируете?
Что такое общее видение?

Требования меняются постоянно. Детальное ТЗ на проект длиной более 3-х месяцев устаревает уже через месяц. Проще регулярно (раз в 2, 3, 4 недели, зависит от проекта) согласовывать требования с командой и детализировать задачи непосредственно перед началом разработки задачи.

Что такое общее видение?

Общее видение — цели проекта, аудитория, задачи, основные инструменты, примерная оценка сроков. Плюс описание основных вариантов использования в свободном стиле.

Видения обычно достаточно для разработки прототипов интерфейса.

Как потом тестируете?

Сначала внутреннее тестирование по основным вариантам использования, собственно варианты использования используются как тест-планы. Потом тестирование по прототипам интерфейсов.

NB. Все вышенаписанное справедливо для внутренних проектов. Для клиентов требования приходится документировать и фиксировать.

[netklon]

Документирования требований для своих проектов не ведем — это пустая трата времени.
Как тогда предотвращаете scope creep, feature creep и, наконец, "я говорил совсем по-другому!" со стороны заказчика?

Антон, там важное «для своих проектов». С заказчиками мы обычно работаем короткими (2-4 недели) проектами, и там сроки и требования фиксированные, то есть как бы не agile.

[Anton Kovalenko]

Детальное ТЗ на проект длиной более 3-х месяцев устаревает уже через месяц.
По каким причинам чаще всего?
С заказчиками мы обычно работаем короткими (2-4 недели) проектами, и там сроки и требования фиксированные, то есть как бы не agile.
Ну тады ой. Меня интересует именно то, как народ на практике разводит все проблемы, связанные с итеративностью и постоянным изменением/обновлением требований.

[netklon]

Детальное ТЗ на проект длиной более 3-х месяцев устаревает уже через месяц.
По каким причинам чаще всего?

Ну как по каким причинам? Изменились обстоятельства. Конкуррент выпустил фичу, появился новый партнер, первичное тестирование раннего прототипа выявило проблемы. Кратко: это жизнь.

С заказчиками мы обычно работаем короткими (2-4 недели) проектами, и там сроки и требования фиксированные, то есть как бы не agile.
Ну тады ой. Меня интересует именно то, как народ на практике разводит все проблемы, связанные с итеративностью и постоянным изменением/обновлением требований.

Насколько знаю в клиент-ориентированной разработке agile применяют в основном в аутсорсинге, с оплатой за time and materials, а не попроектно.

[Sergey Rudakov]

С принципами 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. На роудмэпе уже, как правило, заметны критические пути. Обычно они в сфере аутсорса и внешних данных (верстка, проектная документация и т.п.). от этих критических путей и выстраивается привязка по задачам.

Описано сумбурно, но суть в том, что сами итерации проходят по каскадным принципам (требования-планирование-разработка-тестирование-отладка ), а сдвижка фаз дает место для гибкости.
Для нас документация подается подается от оунера. В таком сценарии развития она предоставляется по принципу набегающей волны. До того, как она не нужна, она нам действительно ненужна в полном масштабе. А к моменту, когда она публикуется, она уже может включать в себя более актуальную постановку задачи, включение каких-то приоритетных задач из бэклога, запросы на изменения по опыту предыдущих итераций и т.д., т.е. есть маневр подстроиться под «изменчивость обстоятельств». Надо отметить, что в нашем случае документация никогда не является исчерпывающей и темные места уточняются непосредствено между исполнителем задачи и писателем, как правило в групповых чатах, чтобы все члены разработки были в курсе. Если объем уточнений достаточно большой и важный, обновляется соответствующий кусок документации.

[Anton Kovalenko]

Sergey Rudakov, шикарный ответ, большое спасибо!
Юз кейсы как документируете - UML или подробно, словами?

[shumbola]

формируется четкое ТЗ
Что из себя представляет ТЗ? Документ по ГОСТу, по другому стандарту или что-то свое?

[Sergey Rudakov]

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

Что из себя представляет ТЗ? Документ по ГОСТу, по другому стандарту или что-то свое?
не знаю я, как можно стандартизировать блоки в ТЗ. Они очень разношерстные, где-то описывается механика с формулами, где-то визуальная часть и интерактив с пользователем. Суть ТЗ в том, чтобы разработчик понял, что от него хочет оунер. А как выглядит и структурирован документ - вторично и несущественно. Со временем, когда команда срабатывается, уже начинаешь понимать, что ожидается, даже если это явно не указано в спеке

[shumbola]

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

Из сказанного я сделал ввод, что все-таки ваше ТЗ - что-то свое - вами же изобретенный документ.
И ничего плохого в этом нет, если конечная цель достигается этим. Я видел много изобретений велосипедов. ;-)

[Anton Kovalenko]

всю текущую неделю участвую в буткэмпе, который ведет один из создателей BABOK :)