Нельзя все сделать реюзабельным

Парни в команде придумали новый термин - Юрезабельно :)

В честь нашего ведущего архитера (Юра, не обижайся).

Это когда делаем все-все-все реюзабельным везде-везде за бюджет одного проекта. Хорошо еще, что бюджет этот не ограничен и проект по ресурсной модели.

На практике же получается, что при всей ориентированности разработчиков на ценности Agile за несколько месяцев разработки заказчик увидел только несколько форм, которые работают кое-как. О деплое даже не идет речи.

Бесконечные совещания по архитектуре (сколько у нас архитекторов на одного разработчика я уже писал пару постов назад), переделки уже реализованной функциональности под последствия очередного ревью - в итоге мы бесконечно улучшаем серверные компоненты, которые потом руководство собирается использовать в будущих проектах.

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

Вот так замечательный и интересный проект с прекрасной замотивированной и отвественной командой превратился в просто "делаем что-то, наверное когда-нибудь покажем заказчику работающие формы".

Будьте внимательны, когда начинаете вроде бы динамичный Agile проект, и есть такие признаки как:

• ресурсная модель проекта


• отсутствие обоснованных бизнес-потребностями заказчика более-менее жестких сроков проекта


• желание руководства сделать реюзабельные компоненты


• принятие руководством архитектурных решений, особенно противоречащих решениям, принятым ранее архитектором проекта

Команда - основа успеха

Сегодня закончилась вторая итерация нового проекта и уже второй раз на ретроспективе в графе "Плюсы" оказывается пункт "Вместе и слаженно решаем возникающие проблемы".

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

И уже второй раз ухожу на выходные с чувством выполненного долга :)

Истории пользователей (пожелания) и подзадачи в Jira

Так получилось, что приходится один из проектов вести в ненавистной Jira.
Пытаюсь для возможности последующего анализа на pre-sale других проектов (а на самом деле в основном для удовлетворения начальства красивым сгенеренным project-планом) получить более менее удобную картину, а именно набор пожеланий, разбитых на задачи с определенным типом.

Т.е. имеем Feature, у которой есть Subtasks: описать требования, разработать UI, разработать серверный компонент, написать тестовый сценарий и протестировать.

Как бы сделать так, чтобы при переходе одной из подзадач в InProgress, исходная фича автоматически переходила в InProgress, а при Resolve или Close последней подзадачи, исходная фича тоже автоматически считалась выполненной? Ну чтобы инструмент помогал в работе, а не создавал новых трудностей.

Может кто знает?

Вот в системе управления проектами DEVPROM, например, при планировании пожелания в итерацию, автоматически предлагается создать набор подзадач (требования, разработка, тестирование), от состояния которых зависит состояние исходного пожелания.

Крайне удобно, и никаких лишних действий не нужно.

Сколько нужно архитекторов на одного разработчика?

.. или пытаемся делать agile-like проект с огромной кучей условий, зависимостей и стейкхолдеров.

Стартовал новый проект с интересной особенностью - на трех (!) разработчиков:

• два архитектора


• два рецензента архитектуры, которые имеют свое видение и принимают окончательные решения


• ну и до кучи: менеджер, два аналитика и тестировщик

При этом аналитика и архитектура стартанули одновременно с разработкой.

Вот представьте себе состояние разработчиков, которым нужно писать код, когда мало того что ближайшие задачи не проработаны с бизнесом, так еще 4 архитектора даже между собой еще не договорились как будет выглядеть система :)

Кажется, на следующей неделе нужно обязательно всем идти в паб, иначе могут быть неприятности.

Повышаем эффективность ежедневного скрама

Все больше убеждаюсь в том, что стандартные на ежедневных скрамах вопросы "Что ты делал вчера (What did you do yesterday)" и "Что будешь делать сегодня (What will you do today)" не самый эффективный способ вести проект к успешному завершению.

Правильнее спрашивать "Что ты СДЕЛАЛ вчера" и "Что собираешься СДЕЛАТЬ сегодня" - это, во-первых, нацеленность на четкий результат (и вообще его осознание), а во-вторых дополнительный коммитмент человека перед командой.

"я буду делать.. " - это процесс, так можно считать мух на потолке или смотреть на огонь.

"я сделаю.. " - это уже четко намеченная цель, которая должна быть достигнута.

Забота о пользователях или чудеса usability

На сайте Металинка Оракл (http://metalink.oracle.com) сегодня увидел самую лучшую форму смены пароля из тех, которые требуют от пользователя следования определенным правилам:



Минут 5 сидел проверял как работают подсказки справа :)

TDD books - read it!

К материалам тренинга по TDD выложил набор хороших книжек, тем кто не читал окажутся полезными. Да и тем кто читал, наверняка не плохо было бы освежить некоторые моменты.

Архив Все-в-одном:

• Гради Буч - Объектно-ориентированный анализ и проектирование - musthave каждому разработчику прочитать хотя бы раз в жизни.


• Кент Бек - Экстремальное программирование


• Кент Бек - Экстремальное программирование. Разработка через тестирование


• Мартин Фаулер - Рефакторинг. Улучшение существующего кода


• Gerard Meszaros - xUnit Test Patterns

Ссылка (подождать минуту для скачивания)

TDD в Москве

Пару дней назад провел очередной тренинг по Test Driven Development, на этот раз открытый и в Москве.

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

Уже второй раз задают вопрос про Test Driven, да и вообще модульного тестирования пользовательского интерфейса.

Вообще если брать термин "модульный тест" и прикладывать его к UI, то получим тест интеграционный, т.е. который тестирует цепочку вызовов да еще и не изолирован от внешних ресурсов, например базы данных. Различные инструменты для UI тестирования (selenium, watin) используют фреймворки модульного тестирования, вроде xunit, но все же на мой взгляд такими тестами должны (в основном) заниматься тестировщики.

Что касается Test Driven UI, то здесь по опыту приходит на ум только один инструмент - FIT, в котором можно сначала описать простым английским как будет выполняться тест, а уже потом идти создавать саму программу, ее UI и дальше просто связывать интерфейс пользователя с написанными ранее сценариями и запускать. Правда, понадобятся дополнительные фикстуры, но их и самим можно написать.

Следующий тренинг в середине июля в Питере, после занятий сразу на ролики!

TDD в студенческие массы

Выдалась возможность прочитать настоящую лекцию настоящим студентам в НГТУ в Новосибе - вроде получилось неплохо.

Смутило то, что многие из них работают разработчиками, и при этом 100% аудитории никогда не слышала про continuous integration. Про Agile пара человек, что были на прошлогодней лекции Асхата. Про TDD опять никто. Караул.

Старался положение исправить, через два с половиной часа на моках народ уже начал выключаться :)
Зато вроде как никогда доходчиво изложил суть TDD на примерах, надеюсь хоть кто-нибудь после лекции полистает Кента Бека и попробует TDD.

Что завтрашний день покажет?

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

Измерение скорости разработки по фазам

Классическим примером оценки текущего состояния проекта является burndown диаграмма - на мой взгляд вообще самый лучший инструмент, позволяющий увидеть реальное состояние дел в итерации.

Но оказывается, и его можно усовершенствовать - дополнительно измерять скорость разработки по проектным фазам: анализ требований, разработка, тестирование, документирование и т.п.

Для 100% кросс-функциональной команды, где разработчик = тестировщик = аналитик, это наверное не так важно - если анализ требований будет не успевать, остальные накинутся и помогут. Но много ли таких команд вы знаете?

(далее рассуждаем, приняв эффективность аналитической деятельности 1 разработчика меньше эффективности такой же деятельности 1 аналитика)

Давайте представим себе, что у нас недельная итерация, в команде помимо разработчиков только один аналитик по 4 часа в день - итого 20 доступных часов. А задач на анализ оказалось на 30 часов (например, недооценили) - и все необходимо сделать, чтобы хорошо начать следующую итерацию.

В этой ситуации burndown будет нам показывать, что все хорошо (например, разработчики идут быстрее плана), однако, очевидно что анализ не будет завершен вовремя.

А burndown продолжает показывать, что все в норме!

Вот здесь и поможет еще один показатель, требуемая скорость разработки по фазам - если у нас осталось работ, например на анализ, больше чем физически доступно времени аналитиков, то загорится красная лампочка и нам придется вовремя обратить на нее внимание.

Вот например в DEVPROM такой показатель измеряется и всегда доступен команде рядом с burndown графиком.