Программистам: agile
Oct. 28th, 2008 10:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dimrubА что вы думаете о различных методиках, проходящих под лозунгом agile development? Наверное, чтобы разговор был содержательным, предпочтительно высказываться на основании реального опыта знакомства с этим делом.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
on 2008-10-28 08:27 pm (UTC)no subject
on 2008-10-28 08:28 pm (UTC)no subject
on 2008-10-28 08:45 pm (UTC)1. Continuous build. По идее надо continuous integration, но у нас для начала билд. Как кто чек-ин делает, все сейчас же собирается на специальном сервере, и если билд не удался, виновник должен все бросить и его починить.
2. Nightly unit tests with code coverage. Опять же, если есть возможность, тесты надо гонять все время, но наши заниимают больше часа. Поэтому гоняем ночью. В разных бранчах.
3. Мы редко пишем unit test first, но как правило в source control код кладется уже с тестами. Это очень хорошо сказывается на качестве кода.
4. Релиз раз в месяц. Короткие итерации.
no subject
on 2008-10-28 08:52 pm (UTC)Книгу, кстати, нашел на работе, сейчас читаю.
no subject
on 2008-10-28 09:19 pm (UTC)no subject
on 2008-10-28 09:30 pm (UTC)no subject
on 2008-10-28 10:01 pm (UTC)Ну и так там всякие психологические трюки, которые делают жизнь приятнее.
no subject
on 2008-10-28 10:13 pm (UTC)Ну и кроме того ориентированнось на бизнес-фичи (а именно, что в конце каждого спринт'а должно быть сделано что-то, что можно показать заказчику/бэклог-оунеру) тоже далеко не для всех вещей подходит.
Короче, через некоторое время я забил на это дело.
no subject
on 2008-10-28 10:30 pm (UTC)У нас это вынуждает разбивать задачу на куски, которые можно закончить за день-два. То есть исчезает проблема "закончено на 90%!", и так 2 недели подряд.
Но я же говорю, это все психологические уловки, и если к ним возникает неприязнь, то и не сработает.
no subject
on 2008-10-28 10:43 pm (UTC)no subject
on 2008-10-29 06:30 am (UTC)no subject
on 2008-10-29 07:55 am (UTC)no subject
on 2008-10-29 07:57 am (UTC)no subject
on 2008-10-29 07:56 am (UTC)no subject
on 2008-10-29 09:07 am (UTC)И перед спринтом никто не распределяет "один человек-один бэклог-айтем", самые плодотворные наши спринты получались, когда удавалось совместно работать над чем-то.
no subject
on 2008-10-29 09:40 am (UTC)Ну,"скрам-мастер" все-таки все время меняется. И я имел в виду, что он занимается координацией и озабочен тем, чтоб "спринт-екзит" был хорошим.
И перед спринтом никто не распределяет "один человек-один бэклог-айтем"
Это я упростил немного: "бэклог-айтемы" бьются на мелкие "таски", а "таски" уже распределяются между людьми в команде динамически.
no subject
on 2008-10-28 10:44 pm (UTC)Все, что надо сделать, пишется в специальный "бэклог". Его заполняет "бэклог-оунер". Туда заносятся только "бизнес-фичи", т.е. то, что можно показать заказчику. Они называются "бэклог-айтемы". Написание тестов например или мейк-файлов в этот "бэклог" не заносятся.
Временной единицей разработки является "спринт" (~2 недели). В течение "спринта" должны быть сделаны один или несколько "бэклог-айтемов". В конце "спринта" всегда бывает ""спринт екзит". Это демонстрация на живой аппликации "бэклог-айтемов", сделанных в течение данного спринта. Т.е. получается мини-релиз каждые 2 недели.
Перед началом спринта известны "бэклог-айтемы", которы должны быть сделаны, и кто из команды за какой айтем отвечает. Каждый рабочий день в один и тот же час происходит "скрам-митинг". Вся команда садится в кружок, и каждый отвечает на 3 вопроса, что он сделал вчера/сегодня, что собирается делать сегодня/завтра и что ему мешает выполнить свой айтем.
Оперативным управлением командой в течение "спринта" занимается "скрам-мастер". Он отвечает за успех/неуспех "спринта" целиком. Он же ведет "спринт-екзит" и проводит демонстрацию новой версии в конце спринта. Роль "скрам-мастера" переходящая. То есть каждый в команде успевает работать "скрам-мастером".
no subject
on 2008-10-28 11:08 pm (UTC)1.у нас нету комнаты совещаний куда влезут одновременно все разработчики
2."Все что надо сделать" - это спецификация системы, которую писали в общей сложности с год. И продолжают писать уже после начала кодирования. Написание, поддержка в приличном состоянии, проверка что нету внутренних противоречий - это группа системных инженеров (3 человека, плюс им периодически помогают свободные программисты).
3. "Релиз" у нас проверяется (внутренние проверки) около месяца, плюс еще месяц интеграции и еще месяц финальные проверки перед передачей заказчику. Они проверяют еще месяц-два :) Наш "спринт" - это полгода :)
4. Размер "айтема" в среднем - около недели, и контроль что и когда делается иерархически - нач. группы докладывает руководителю разработки. Происходит это "совещание-статус" раз в неделю. Собирать ежедневно 15 человек (а то и больше) смысла нет.
5. командой управляет руководитель разработки (на макро-уровне). Техническое управление и надзор - на группе архитекторов (под ними - нач. групп). Есть ответственный интегратор (человек на профессиональном уровне архитектора). Но он отвечает только за качество и отсутствие багов, не за написание новых фичей. Его роль постоянная, ибо требует очень хорошее знание всего, и довольно специфический склад ума. Демонстрация новой версии в нашем случае означает прохождение соответствующей версии STD, проведенное тестерами и заверенное SQA (software quality assurance).
Это все не критика, просто материал для сравнения как такой метод (в котором есть неплохие идеи) может быть без фанатизма адаптирован к проектам вроде нашего.
no subject
on 2008-10-28 10:53 pm (UTC)Новая "фича" пишется одновременно с юнит тестом который ее проверяет (я называю юнит тестом все что технологически запускается из NUnit. Многие юнит тесты тестируют процессы затрагивающие многие модули системы.) Полное покрытие кода (за исключением так называемых "проверок на всякий случай") юнит тестами.
Короткие релизы - но в масштабах нашего проекта это раз в полгода :)
Код ревью - нач. группы в обязательном порядке делает на 100% кода, с документированием и сохранением отчета. Делается обычно 2-3 раза "в жизни модуля" - в промежутке от версии к версии.
Первые месяцы в момент создания скелета проекта и приучения команды к стилю работы все чек-ин проходили только после обязательного и 100% код ревью одного из архитекторов.
Создание (недешевое) среды симуляции позволяющей симитировать как возможные, так и невозможные ситуации в которых может оказаться система.
Написание утилит для полу/автоматической проверки особо темных углов - вроде скорости/точности вычисления различных интегралов при разной точности/модели поведения измеряемых величин после каждого прогона программы.
Нерешенные проблемы - тестирование юзер интерфейса. QTP и иже с ними возможно будут использованы, но в похожих проектах они себя показали не с лучшей стороны.
no subject
on 2008-10-29 05:17 am (UTC)no subject
on 2008-10-29 07:53 am (UTC)кстати, о формальных методологиях — их, если я не ошибаюсь, только две, экс-пи и скрам. всякие кристалы и фдд к формальным причислить нельзя, насчет экс-брида — не уверен. при этом экс-пи мне лично сложно назвать методологией менеджмента, это скорее набор инженерных практик. поэтому скрам мы делаем, а экс-пи — кому как нравится.
или все-таки речь об инженерных практиках?
no subject
on 2008-10-29 07:55 am (UTC)no subject
on 2008-10-29 03:26 pm (UTC)постулаты agile — итеративное создание value, приоритеты заказчика выше приоритетов инженерной группы, неприменимость понятие value add, смещенный баланс треугольника срок-фичи-бюджет и так далее. тдд без этих базовых вещей нисколько не agile.
no subject
on 2008-10-29 05:59 pm (UTC)Это да, это-то и раздражает :)
no subject
on 2008-10-30 07:44 am (UTC)no subject
on 2008-10-29 08:33 pm (UTC)no subject
on 2008-10-30 06:15 am (UTC)no subject
on 2008-10-30 06:18 pm (UTC)that said, какие-то идеи "из методологий" вполне универсальны: continuous build, unit-tests (если с умом), refactoring там и сям...