Документ представляет собой обсуждение проблем в управлении проектами с использованием Agile и Scrum, включая проблемы с определением требований и взаимодействием с заказчиками. Основные акценты сделаны на важности поддержания 'здорового' беклога, реалистичности сроков и качестве кода, а также на предоставлении возможных решений для каждой из выявленных проблем. В заключение, автор подчеркивает необходимость постепенного изменения процессов и вовлечения команды в обсуждение улучшений.

1. Как сделать наши проекты немного более управляемыми с Agile Алексей Кривицкий IT Talk , Харьков 25 сен 2008 SCRUMguides.com

2. Кто я Тренер по Agile/Scrum Разработчик ПО http://www.linkedin.com/in/alexeykrivitsky email: [email_address] skype: alexeykrv icq: 436-471-64 gsm: +380 50 358 92 12 Консалтинговый центр по вопросам внедрения Agile- практик www.scrumguides.com

3. На вебе Сообщество Agile Ukraine www.agileukraine.org C татьи, общение, новости, события, обмен опытом. Google discussion group Присоединяйтесь, там интересно. Украинский портал по SCRUM www.scrum.com.ua Статьи, полезные ссылки, сертификация ScrumMaster.

4. А кто вы? :)

5. Проекты, проекты, проекты Кто из вас в настоящее время работает в проекте по разработке ПО? Есть ли какие-то проблемы? В нашей области принято называть проблемы словом « challenges » 

6. Челенджи, челенджи, челенджи Заказчики «Невменяемые заказчики» ;) Заказчики не знают, чего хотят Давление на команду Слишком много проектов для одной команды Заказчик – бывший программист Требования Заказчики часто меняют порядок выполнения работ От заказчиков исходят противоречивые пожелания Всё критично для реализации в ближайшее время Требования отсутствуют как таковые, решения над чем работать принимаются спонтанно

7. Челенджи, челенджи, челенджи (2) Статус проекта Нереальные сроки Отложенные релизы Никто не знает текущего состояния дел Никто не знает, когда закончится проект 50% задач готовы на 50% Команда Проблемы с качеством кода Неоцениваемые задачи Руководство «Некомпетентное руководство» ;)

8. Анти-паттерны и как с ними бороться

9. «Заказчики не знают, чего хотят» Симптомы : Заказчики часто меняют порядок выполнения работ. Требования отсутствуют как таковые, решения над чем работать принимаются спонтанно. На стороне заказчика работает группа людей, от которых исходят противоречивые пожелания. Как следствие: Никто толком не знает ближайшие цели проекта. Ощущение хаоса. На вопрос «что вы сейчас разрабатываете?» у команды нет чёткого и короткого ответа.

10. «Заказчики не знают, чего хотят» (2) Пути решения : Не называйте требования «требованиями». Как вариант - «пожелания». Заведите на проекте единственный упорядоченный список пожеланий – « product backlog » по Скраму.

11. Пример упорядоченного списка пожеланий Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation 5 Guest can change reservation dates 3 Hotel employee can see future reservations for her hotel 8 Improve exception handling 5 … 30 … 50

12. «Заказчики не знают, чего хотят» (3) Определите критерии «здоровья» беклога. Найдите на стороне заказчика человека, который бы отвечал за поддержание беклога в «здоровой форме» (Product Owner или PO по Скраму ) Не начинайте работать над очередной фазой проекта, пока есть проблемы с наполнением беклога. Помогайте вашему PO поддерживать беклог. Это его самая важная работа в течение всего проекта .

13. «Всё критично» Также может называться «Все й одразу!» :) Симптомы и другие формы челенджа: У требований нет приоритетов. Все требования имеют приоритет P1. Требования разбиты на приоритеты P1, P2 ..., но в каждой группе довольно много элементов. На вопрос, что более критично, что менее для проекта, заказчики отвечают, что критично всё. Заказчики полностью делегировали принятие решений о порядке реализации требований команде. Как сдедствие: Программисты работает над чем хотят. Либо часто перескакивают с задачи на задачу, не завершая ни одну.

14. «Всё критично» (2) Пути решения: Заведите беклог. Добавьте в беклог грубые оценки длительности реализации пожеланий. Заведите понятие текущего релиза, оговорив желаемую дату релиза и цель. Проведите в беклоге черту «текущий релиз». Зафиксируйте дату релиза и научите вашего PO манипулировать содержимым релиза для сохранения запланированной даты. 1 Dec 2008 5 2 3 8 1 5 13 2 3 13 5 2 3 8 1 13

15. «Всё критично» (3) Пути решения: Ведите график количества оставшейся работы в текущем релизе. Обновляйте его после каждой итерации.

16. «Мы на середине проекта» Также может называться: «Мы думаем, что мы успеем» или «Должны успеть!» Симптомы: Никто не знает, когда закончится проект. Никто не знает текущего состояния дел. «50% задач сделаны на 50%». Вся команда работает монотонно. Все понимают, что под конец проекта в любом случае придётся напрячься, так что нет смысла напрягаться сейчас.

17. «Мы на середине проекта» (2) Симптомы: В проекте не принято обсуждать реалистичность планов. Тестировщики молчаливо работают над подготовкой тест-кейсов.

18. «Мы на середине проекта» (3) Как следствие: Нет ни одной готовой и работающей фичи. Система постоянно в «разобранном состоянии». Тестировщикам нечего тестировать.

19. «Мы на середине проекта» (4) Пути решения: Остановить разработку нового функционала до прогона функционального и регрессионного тестирования. Тестируют все. Результаты тестирования поместить в верх беклога. Собрать команду и заказчика для поиска ответа на вопрос : «Какие из незавершённых пожеланий можно будет завершить и протестировать для демонстрации через 3 недели?» С этого момента работать итерациями. Начало – совещание по выбору пожеланий на итерацию. Завершение – демонстрация работающей системы.

20. «Заказчик – бывший программист» Симптомы: Основной заказчик – бывший программист, но ведёт себя как настоящий.  Большая часть требований ставятся команде в виде программистских задач, диаграмм классов, примеров кода... В требованиях программисткая терминология . Как следствие: Никто толком не понимает бизнес нужд. Тестировщики не знают, как тестировать систему.

21. «Заказчик – бывший программист» (2) Пути решения: Ознакомьтесь с концепцией « User Stories » ( историй ) - пожеланий, записанных в формате: As a <user> I can <do> so that <value> . Совместно с заказчиком выпишите истории для нереализованных (частично или полностью) требований, наполнив ими беклог. Упражнение: « All connections to the database go through a connection pool » . « Implement paging control on the list of orders and sort orders by date » Как можно было бы переписать это в виде истории ? Иногда помогает техника « five whys » .

22. «Заказчик – бывший программист» (3) Пути решения: В начальном списке задач поставьте в соответствие каждой задаче одну из историй. Передайте полное управление списком задач команде. Добавьте в список задач задачи по интеграции, тестированию, настройке среды и проч. Помогайте заказчику описывать новые требования в оговоренном формате .

23. «Слишком много проектов для одной команды» Симптомы: Команда разрабатывает и поддерживает спектр приложений. Никто не может точно указать кросс-приоритеты между требованиями различных приложений .

24. «Слишком много проектов для одной команды» (2) Пути решения: Заведите общий беклог на все проекты, для этого должен быть выбран один PO .

25. «Слишком много проектов для одной команды» (2) Или же разделить команду на подкоманды с независимыми беклогами. Может быть даже различными PO.

26. «Слишком много проектов для одной команды» (2) Или же выделите самый критичный проект, выделить для него постоянную команду, беклог, PO. Остальные проекты разрабатывайте, как раньше.

27. «Неоцениваемые задачи» Симптомы: Команда не может дать оценки требованиям. Требования слишком размыты, в проекте много технологических рисков и прочих неизвестных. Оценки, данные командой, рассматриваются как обещания.

28. «Неоцениваемые задачи» (2) Мотивация: Оценки нужны, пусть даже самые грубые, так как оценки влияют на решения заказчиков по порядку реализации требований и объёму их реализации.

29. «Неоцениваемые задачи» (3) Пути решения: Снять давление с команды. Оценки не являются обещаниями. Отделить исследования от реализации, создав в беклоге отдельные для них элементы. Использовать командные подходы к оценкам. К примеру planning poker. Собирать статистику и сравнивать требования, дефекты, задачи между собой.

30. «Проблемы с качеством кода» Симптомы: Код плохо пахнет. Программисты не обсуждают дизайн. Не проводятся ни в какой форме code review. В проекте нет code conventions. Написание юнит тестов очень трудоёмко. Часто ламается ранее написанная функциональность. Падает темп работы команды.

31. «Проблемы с качеством кода» (2) Пути решения: Использовать дезодоранты для кода (комментарии) Ввести code reviews за правило. Практиковать парное программирование. Как минимум на начальной и конечной фазе реализации сложных фич.

32. «Проблемы с качеством кода» (3) Завести беклог рефакторингов, выделить на них адекватный бюджет и выполнять выбранные рефакторинги каждую итерацию.

33. Советы по улучшению процесса Не пытайтесь изменить всё и сразу. Не пытайтесь сделать это самостоятельно. Начните с регулярных неформальных обсуждений процесса и поиска зон улучшений с командой и заказчиком (ретроспективы). Пытайтесь коллективно каждый месяц вводить выбранное одно-два улучшения. Через год ваш будет в намного лучшей форме , либо уже закончится. 

34. Не бойтесь менять процесс You can always start changing. You can always start now. You can always start from yourself. © Kent Beck, co-author of XP

35. Спасибо! Вопросы?