'

Как сделать наши проекты немного более управляемыми с Agile

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

4 А кто вы? :)


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

11 Пример упорядоченного списка пожеланий


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 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».


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

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


Слайд 33

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


Слайд 34

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


×

HTML:





Ссылка: