Построение гибкого процесса разработки (3 курс)
DESCRIPTION
TRANSCRIPT
Построение гибкого процесса
разработкиот теории к практике
Codeparts developers initiative ДОИ «Тендер-2012»
Обо мне
Имя: Рахматиллаев Тимур Twitter: http://twitter.com/eskat0n Email: [email protected] VK: http://vk.com/eskat0n Skype: eskat0n
Обо мне
Получил диплом инженера по специальности 230101 в 2011 году.
С сентября 2010 до февраль 2012 года работал в компании IndyCode в должности разработчика в стеке технологий .NET
С марта по июнь 2012 года работал в компании DoneRight в должности web-разработчика в стеке технологий .NET
С августа 2012 года работаю в компании ByndyuSoft в должности ведущего разработчика / тимлида
Я...
Не менеджер Не технический директор Не внедритель Agile/Scrum/Kanban
Разработчик
С другой стороны баррикад
Что я видел
Микроменеджмент переходящий в «наноменеджмент»
Провальные в своей сути попытки внедрить Agile
Переход к Kanban от Scrum’а и обратно
Kanban-board собственной разработки
Проведение ретроспектив
Проведение стендапов
Попытка уйти от стендапов
Тайм-менеджмент
Использование sticky-notes
Mind map
Roadmap
Story mapping
User stories
Тестирование силами заказчика
Заказчик в команде
Заказчик на другом конце земного шара
Взаимодействие через wiki
И много чего еще...
Я вас предупреждал
Чего НЕ произойдет после того как вы пройдете этот тренинг
Ваши проблемы не решаться сами по себе Вы НЕ наладите оптимальный процесс
разработки Поведенческие особенности разработчиков из
ваших команд не изменятся
Но!..
Вы сможете понять ваши проблемы Вы будете знать, что вы можете сделать (и что
делают другие команды разработчиков) Вы сможете более эффективно решать
возникающие проблемы
Притча про командную греблюодна поучительная история
Выводы
Важно осознавать факт наличия проблемы Необходимо понимать, в чем именно
заключается проблема Нужно обладать набором знаний для решения
проблемы Надо обладать навыками для эффективного
применения этих знаний на практике
Проблемы самосознанияНасколько я квалифицирован, чтобы что-то решать?
Что я могу решить?
Я знаю, как я могу что-нибудь гарантировано решить?
Матрица компетентностиКомпетентность
Осознанность
да
нет да
нет
неосознаннаянекомпетентност
ь
осознанная некомпетентност
ь
осознаннаякомпетентность
неосознаннаякомпетентность
«собирание шишек»советы коллег
обучениеподражание
путь творцаопыт
Матрица компетентностиКомпетентность
Осознанность
да
нет да
нет
А че там делать? О, да тут все не просто так...
Ага, вот оно как!Я не понимаю, почему так будет правильно, но это
правильно
Анекдот
Встречаются две рыбы.
Одна другую спрашивает: «А вот как ты жабрами дышишь?»
Вторая рыба задумалась... и задохнулась.
А на самом деле...
Все правила, принципы и подходы – это просто формализованный здравый смысл.
Нахождение в 4й стадии означает использование собственного опыта и здравого смысла.
Здравый смысл формализуют для удобства запоминания, чтобы совершался переход из 2й в 3ю стадию.
Её величество ПРОБЛЕМАКак понять, что у вас есть проблемы в организации процесса разработки?
Проблемы?
Проблемы?
Вы тратите на организацию работы команды неоправданно большое время
Вы планируете дольше, чем разрабатываете В процессе разработки одновременно не
задействованы все члены команды Вы не знаете, кто и чем занимается СЕЙЧАС
Причины?
Неправильно построенный процесс Неправильно выбранные инструменты Неправильно расставленные приоритеты
UML – не панацея
Что дает вам применение диаграммы прецедентов?
Что дает вам применение диаграммы последовательности?
Что дает вам применение диаграммы классов? Что дает вам наличие нотации?
UML – не панацея
UML отъедает временные ресурсы команды UML не формирует единого представления из-за
высокого уровня абстракции UML не нужен заказчику (как правило) UML плохо декомпозируется над подзадачи
Что мы делаем при разработке?
Решаем проблемы заказчика!А не превращаем абстрактные
рисунки в код
Если бы программисты строили дома42 в мире управления процессом разработки ПО
http://bit.ly/progbuilding
Отсутствие единого мнения
Обсуждали проект. Сидоров предлагает крупноблочную архитектуру. Петрович настаивает, что все надо строить по старинке, из кирпича, не по-ламерски. Самый радикальный проект предложил Алекс: построить несколько десятков деревянных коттеджей и потом соединить их подземными туннелями. На Западе сейчас так модно. Напомнили ему, что заказчик требует именно 12-этажный дом. Пытались решить вопрос дуэлью в Quаkе. Алекса с его коттеджами завалили сразу, но между Петровичем и Сидоровым вышла ничья. В итоге каждый будет строить по своему плану, а потом попытаемся все это соединить, чтоб не рухнуло.
«Хватит трепаться – покажите мне код!»Линус Торвальдс
Главная задача – быстрый переход к непосредственной разработке
Вечные ценности командыНемного философии
Решение проблемы заказчика
Первый этаж готов! Показали его заказчику. Он интересовался, почему в разных комнатах разная высота потолков, почему из стен вываливаются кирпичи и почему в доме нет подъезда, а влезать приходится через окно. Объяснили ему, что это специальные ограничения демо-версии. Уходим на праздники, гордые собой.
Саморазвитие
Вспомнили, что у нас кран достает только до 8 этажа. Послали Сидорова доставать новый кран. Играем в Quаkе. Алекс замочил Петровича. Растет смена!
Явное ощущение прогресса
Что уже сделано?
Что осталось сделать?
Какой вклад я внес?
Коллективное владение информацией
Вернулся Сидоров. Кран не достал, зато достал крутой экскаватор. Предлагает вырыть глубокую шахту и построить дом не в высоту, а в глубину. Говорит, что нигде в контракте не сказано, что 12 этажей должны быть над поверхностью. Еле отговорили.
Ценности команды
Решение проблеммы заказчика
Саморазвитие
Явное ощущение прогресса
Коллективное владение информацией
AgileLean, Scrum, XP, Kanban, FDD
Принципы Agile
Наисвысший приоритет – удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
Над проектом должны работать мотивированные...
http://agilemanifesto.org/iso/ru
Agile-практики
Lean
XP
Scrum
Kanban
FDD
Agile-практикиXP
Whole team
Coding standard
TDD
Collective ownership
Customer tests
Pair programming
Refactoring
Planning game
Continuous integration
Simple design
Sustainable pace
Small releases
Scrum
Scrum master
Product owner
Team
Sprint planning meeting
Daily scrum
Sprint review
Product backlog
Spring backlog
Burndown chart
Kanban
Visualize the workflow
Limit WIP
Measure and optimize lead time
Agile – это не серебряная пуляВолшебства не будет – электричество закончилось
Agile – это инструментарий, который применяют людиНезнание правил техники безопасности не освобождает от ответственности
Agile нельзя внедрять!
К Agile нужно переходить
Agile – это конструктор
Нет понятия Agile
Есть набор практически полностью изолированных друг от друга микро-практик и принципов
Практики можно комбинировать друг с другом
Практики нужно комбинировать друг с другом
Не сочтите за рекламу...
Но Agile это сендвич
По какому принципу комбинировать?
Это вкусно
По какому принципу комбинировать?
Это вкусно
Это удобно
Команда уже неформально использует это
Это решает конкретную проблему
Это способствует поддержанию определенной командной ценности
Основные понятия Agile
Итеративная разработка
Выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка
Итеративная разработка
Продолжительность итерации – одна-две недели
Результат итерации – протестированная версия разрабатываемого продукта
Итерация включает в себя процесс перехода задач итерации из состояния в состояние
На самом деле всё не так
User stories
Способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на ежедневном или деловом языке пользователя.
Пример:
Я как зарегистрированный и авторизованный пользователь
Могу нажать на кнопку «Сменить пароль» после ввода нового пароля на форме «Смена пароля»
При этом мой пароль изменяется и я получаю сообщение об успешной смене пароля
User stories и Use cases
User story представляет собой описание функции системы со стороны пользователя (заказчика)
Use case представляет собой описание функции системы со стороны самой системы (как правило содержит большее число технических деталей)
WIP (work in progress)
Количество задач (user stories, etc.), находящихся в одновременной разработке
В идеале WIP на определенном этапе жизненного цикла задачи не должен превышать числа членов команды, задействованных на данном этапе
DoD (definition of done)
Совокупность требований к функциональности системы, которая является критерием готовности выпуска релиза (в т.ч. и промежуточного)
Требования выражаются на языке сценариев приемочных тестов
Требования могут выражаться в виде пользовательских историй
Понимание и четкое видение DoD обязательно должно быть общим у всех членом команды
Agile board
Доска (физическая или виртуальная) для фиксирования прогресса выполнения задач в рамках итерации
Каждая задача должна побывать во всех состояниях-колонках
Примеры состояний: «Запланировано», «В разработке», «Готово к тестированию», «В процессе тестирования», «Готово»
Решения для организации Agile board
SaaS: AgileZen – http://www.agilezen.com
YouTrack InCloud – http://www.jetbrains.com/youtrack/hosted
My agility board – http://www.myagilityboard.com
Standalone: Atlassian JIRA – http://www.atlassian.com/software/jira
Пробковая доска ;)
Некоторые практики AgileДетальное рассмотрение
http://agilesoftwaredevelopment.com
Whole team
Команда разработчиков должна включать в себя специалистов, которые способны выполнять весь набор ролей, необходимых для выпуска финальной версии продукта и поддержания жизненного цикла разработки: разработка, тестирование, оформление документации и, что наиболее важно, представители заказчика.
Collective ownershipCoding standard
Коллективное владение знаниями о проекте, техническими деталями реализации, списом требований подразумевает открые механизмы доступа к ним.
Коллективное владение исходным кодом подразумевает коллективную ответственность за качество этого исходного кода, соблюдение единого стандарта кодирование и понимание всеми членами команды разработчиков принципов проектирования согласно которым строится дальнейшее развитие продукта.
Planning game
Служит инструментом выработки и проверки наличия единого представления всех членов команды о существующих задачах
Является адаптивной системой оценки сроков выполнения задач
Оценка задач может осуществляться в любых абсолютных и относительных единицах (минуты, дни, попугаи и т.д.)
Planning poker
Оценка задачи производится «в закрытую» с использованием специальных карт оценки определенного номинала
Затем карты переворачиваются «рубашкой» вниз
Члены команды разработчиков с самой маленькой и большей оценками высказываются о причинах подобной оценки
В случае большого несовпадения мнений карты перекидываются
Small releases
В конце каждой итерации выпускается релиз – протестированная и стабильная версия системы.
Релизы делаются как можно чаще. В идеале – каждый день.
Visualize the workflow
Использование любых подручных средств для визуального представления процесса разработки:
Burndown chart
Story mapping
Agile board
Daily meeting (standup)
Ежедневное (иногда ограниченное по времени) собрание всех членов команды с целью получить ответы каждого на следующие вопросы:
Что было сделано вчера?
Какие проблемы возникли в работе? (Что мешает двигаться дальше?)
Что будет сделано сегодня?
Некоторые из вопросов могут пропускаться
Daily meeting (standup)
Цели:
Формирование единого представления о прогрессе у всей команды
Предотвращение простоев в работе
Повышение мотивации (выявление «халявщиков»)
Limit WIP
Ограничение числа задач, находящихся на стадии выполнения (разработка, тестирование).
Pair programming
Разработка двумя разработчиками за одним компьютером с последовательной передачей клавиатуры между ними.
Возможна комбинация с TDD: один разработчик пишет тест – другой реализацию.
Ролевая играИли одни 10мин из жизни команды разработчиков
Задавайте свои вопросыНе стесняйтесь
Фил фри ту аск мо квесченз
Email: [email protected] Skype: eskat0n Twitter: http://twitter.com/eskat0n VK: http://vk.com/eskat0n