Построение гибкого процесса разработки (3 курс)

1,309 views
1,225 views

Published on

Published in: Education
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
1,309
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
43
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Построение гибкого процесса разработки (3 курс)

  1. 1. Построение гибкого процесса разработки от теории к практикеCodeparts developers initiative ДОИ «Тендер-2012»
  2. 2. Обо мне Имя: Рахматиллаев Тимур Twitter: http://twitter.com/eskat0n Email: muyou.prj@gmail.com VK: http://vk.com/eskat0n Skype: eskat0n
  3. 3. Обо мне Получил диплом инженера по специальности 230101 в 2011 году. С сентября 2010 до февраль 2012 года работал в компании IndyCode в должности разработчика в стеке технологий .NET С марта по июнь 2012 года работал в компании DoneRight в должности web-разработчика в стеке технологий .NET С августа 2012 года работаю в компании ByndyuSoft в должности ведущего разработчика / тимлида
  4. 4. Я... Не менеджер Не технический директор Не внедритель Agile/Scrum/Kanban Разработчик
  5. 5. С другой стороны баррикад
  6. 6. Что я видел Микроменеджмент переходящий в «наноменеджмент» Провальные в своей сути попытки внедрить Agile Переход к Kanban от Scrum’а и обратно Kanban-board собственной разработки Проведение ретроспектив Проведение стендапов Попытка уйти от стендапов Тайм-менеджмент Использование sticky-notes Mind map Roadmap Story mapping User stories Тестирование силами заказчика Заказчик в команде Заказчик на другом конце земного шара Взаимодействие через wiki И много чего еще...
  7. 7. Я вас предупреждал
  8. 8. Чего НЕ произойдет после того как выпройдете этот тренинг Ваши проблемы не решаться сами по себе Вы НЕ наладите оптимальный процесс разработки Поведенческие особенности разработчиков из ваших команд не изменятся
  9. 9. Но!.. Вы сможете понять ваши проблемы Вы будете знать, что вы можете сделать (и что делают другие команды разработчиков) Вы сможете более эффективно решать возникающие проблемы
  10. 10. Притча про командную греблюодна поучительная история
  11. 11. Выводы Важно осознавать факт наличия проблемы Необходимо понимать, в чем именно заключается проблема Нужно обладать набором знаний для решения проблемы Надо обладать навыками для эффективного применения этих знаний на практике
  12. 12. Проблемы самосознанияНасколько я квалифицирован, чтобы что-то решать?Что я могу решить?Я знаю, как я могу что-нибудь гарантировано решить?
  13. 13. Матрица компетентности путь творца Компетентность опыт неосознанная осознанная компетентность компетентность обучение да подражание нет да Осознанность неосознанная осознанная некомпетентность некомпетентность нет «собирание шишек» советы коллег
  14. 14. Матрица компетентности Компетентность Я не Ага, вот оно как! понимаю, почему да так будет правильно, но это правильно нет да Осознанность А че там делать? О, да тут все не просто так... нет
  15. 15. АнекдотВстречаются две рыбы.Одна другую спрашивает: «А вот как ты жабрамидышишь?»Вторая рыба задумалась... и задохнулась.
  16. 16. А на самом деле...Все правила, принципы и подходы – это простоформализованный здравый смысл.Нахождение в 4й стадии означает использованиесобственного опыта и здравого смысла.Здравый смысл формализуют для удобствазапоминания, чтобы совершался переход из 2й в3ю стадию.
  17. 17. Еѐ величество ПРОБЛЕМАКак понять, что у вас есть проблемы в организации процессаразработки?
  18. 18. Проблемы?
  19. 19. Проблемы? Вы тратите на организацию работы команды неоправданно большое время Вы планируете дольше, чем разрабатываете В процессе разработки одновременно не задействованы все члены команды Вы не знаете, кто и чем занимается СЕЙЧАС
  20. 20. Причины? Неправильно построенный процесс Неправильно выбранные инструменты Неправильно расставленные приоритеты
  21. 21. UML – не панацея Что дает вам применение диаграммы прецедентов? Что дает вам применение диаграммы последовательности? Что дает вам применение диаграммы классов? Что дает вам наличие нотации?
  22. 22. UML – не панацея UML отъедает временные ресурсы команды UML не формирует единого представления из-за высокого уровня абстракции UML не нужен заказчику (как правило) UML плохо декомпозируется над подзадачи
  23. 23. Что мы делаем при разработке? Решаем проблемы заказчика!А не превращаем абстрактные рисунки в код
  24. 24. Если бы программисты строилидома42 в мире управления процессом разработки ПОhttp://bit.ly/progbuilding
  25. 25. Отсутствие единого мненияОбсуждали проект. Сидоров предлагает крупноблочнуюархитектуру. Петрович настаивает, что все надо строить постаринке, из кирпича, не по-ламерски. Самый радикальныйпроект предложил Алекс: построить несколько десятковдеревянных коттеджей и потом соединить их подземнымитуннелями. На Западе сейчас так модно. Напомнили ему, чтозаказчик требует именно 12-этажный дом. Пытались решитьвопрос дуэлью в Quаkе. Алекса с его коттеджами завалилисразу, но между Петровичем и Сидоровым вышла ничья. Витоге каждый будет строить по своему плану, а потомпопытаемся все это соединить, чтоб не рухнуло.
  26. 26. «Хватит трепаться – покажите мне код!»Линус Торвальдс
  27. 27. Главная задача –быстрый переход кнепосредственной разработке
  28. 28. Вечные ценности командыНемного философии
  29. 29. Решение проблемы заказчикаПервый этаж готов! Показали его заказчику. Онинтересовался, почему в разных комнатах разная высотапотолков, почему из стен вываливаются кирпичи и почему вдоме нет подъезда, а влезать приходится через окно.Объяснили ему, что это специальные ограничения демо-версии. Уходим на праздники, гордые собой.
  30. 30. СаморазвитиеВспомнили, что у нас кран достает только до 8 этажа. ПослалиСидорова доставать новый кран. Играем в Quаkе. Алексзамочил Петровича. Растет смена!
  31. 31. Явное ощущение прогресса Что уже сделано? Что осталось сделать? Какой вклад я внес?
  32. 32. Коллективное владение информациейВернулся Сидоров. Кран не достал, зато достал крутойэкскаватор. Предлагает вырыть глубокую шахту и построитьдом не в высоту, а в глубину. Говорит, что нигде в контрактене сказано, что 12 этажей должны быть над поверхностью. Елеотговорили.
  33. 33. Ценности команды Решение проблеммы заказчика Саморазвитие Явное ощущение прогресса Коллективное владение информацией
  34. 34. AgileLean, Scrum, XP, Kanban, FDD
  35. 35. Принципы Agile Наисвысший приоритет – удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные...http://agilemanifesto.org/iso/ru
  36. 36. Agile-практики Lean XP Scrum Kanban FDD
  37. 37. Agile-практики XP Scrum Kanban Whole team  Scrum master  Visualize the Coding standard workflow  Product owner TDD  Limit WIP  Team Collective  Measure and ownership  Sprint planning optimize lead meeting Customer tests time  Daily scrum Pair programming  Sprint review Refactoring  Product backlog Planning game Continuous  Spring backlog integration  Burndown chart Simple design Sustainable pace Small releases
  38. 38. Agile – это не серебряная пуляВолшебства не будет – электричество закончилось
  39. 39. Agile – это инструментарий, который применяют людиНезнание правил техники безопасности не освобождает от ответственности
  40. 40. Agile нельзя внедрять!
  41. 41. К Agile нужно переходить
  42. 42. Agile – это конструктор Нет понятия Agile Есть набор практически полностью изолированных друг от друга микро-практик и принципов Практики можно комбинировать друг с другом Практики нужно комбинировать друг с другом
  43. 43. Не сочтите за рекламу...
  44. 44. Но Agile это сендвич
  45. 45. По какому принципу комбинировать? Это вкусно
  46. 46. По какому принципу комбинировать? Это вкусно Это удобно Команда уже неформально использует это Это решает конкретную проблему Это способствует поддержанию определенной командной ценности
  47. 47. Основные понятия Agile
  48. 48. Итеративная разработкаВыполнение работ параллельно с непрерывным анализомполученных результатов и корректировкой предыдущих этаповработы. Проект при этом подходе в каждой фазе развитияпроходит повторяющийся цикл: Планирование — Реализация —Проверка — Оценка
  49. 49. Итеративная разработка Продолжительность итерации – одна-две недели Результат итерации – протестированная версия разрабатываемого продукта Итерация включает в себя процесс перехода задач итерации из состояния в состояние
  50. 50. На самом деле всѐ не так
  51. 51. User storiesСпособ описания требований к разрабатываемойсистеме, сформулированных как одно или более предложенийна ежедневном или деловом языке пользователя.Пример:Я как зарегистрированный и авторизованный пользовательМогу нажать на кнопку «Сменить пароль» после ввода новогопароля на форме «Смена пароля»При этом мой пароль изменяется и я получаю сообщение обуспешной смене пароля
  52. 52. User stories и Use cases User story представляет собой описание функции системы со стороны пользователя (заказчика) Use case представляет собой описание функции системы со стороны самой системы (как правило содержит большее число технических деталей)
  53. 53. WIP (work in progress) Количество задач (user stories, etc.), находящихся в одновременной разработке В идеале WIP на определенном этапе жизненного цикла задачи не должен превышать числа членов команды, задействованных на данном этапе
  54. 54. DoD (definition of done) Совокупность требований к функциональности системы, которая является критерием готовности выпуска релиза (в т.ч. и промежуточного) Требования выражаются на языке сценариев приемочных тестов Требования могут выражаться в виде пользовательских историй Понимание и четкое видение DoD обязательно должно быть общим у всех членом команды
  55. 55. Agile board Доска (физическая или виртуальная) для фиксирования прогресса выполнения задач в рамках итерации Каждая задача должна побывать во всех состояниях- колонках Примеры состояний: «Запланировано», «В разработке», «Готово к тестированию», «В процессе тестирования», «Готово»
  56. 56. Решения для организации 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 Пробковая доска ;)
  57. 57. Некоторые практики AgileДетальное рассмотрение
  58. 58. http://agilesoftwaredevelopment.com
  59. 59. Whole teamКоманда разработчиков должна включать в себяспециалистов, которые способны выполнять весь наборролей, необходимых для выпуска финальной версии продуктаи поддержания жизненного цикла разработки:разработка, тестирование, оформление документации и, чтонаиболее важно, представители заказчика.
  60. 60. Collective ownershipCoding standardКоллективное владение знаниями о проекте, техническимидеталями реализации, списом требований подразумеваетоткрые механизмы доступа к ним.Коллективное владение исходным кодом подразумеваетколлективную ответственность за качество этого исходногокода, соблюдение единого стандарта кодирование и пониманиевсеми членами команды разработчиков принциповпроектирования согласно которым строится дальнейшееразвитие продукта.
  61. 61. Planning game Служит инструментом выработки и проверки наличия единого представления всех членов команды о существующих задачах Является адаптивной системой оценки сроков выполнения задач Оценка задач может осуществляться в любых абсолютных и относительных единицах (минуты, дни, попугаи и т.д.)
  62. 62. Planning poker Оценка задачи производится «в закрытую» с использованием специальных карт оценки определенного номинала Затем карты переворачиваются «рубашкой» вниз Члены команды разработчиков с самой маленькой и большей оценками высказываются о причинах подобной оценки В случае большого несовпадения мнений карты перекидываются
  63. 63. Small releasesВ конце каждой итерации выпускается релиз –протестированная и стабильная версия системы.Релизы делаются как можно чаще. В идеале – каждый день.
  64. 64. Visualize the workflowИспользование любых подручных средств для визуальногопредставления процесса разработки: Burndown chart Story mapping Agile board
  65. 65. Daily meeting (standup)Ежедневное (иногда ограниченное по времени) собрание всехчленов команды с целью получить ответы каждого наследующие вопросы: Что было сделано вчера? Какие проблемы возникли в работе? (Что мешает двигаться дальше?) Что будет сделано сегодня?Некоторые из вопросов могут пропускаться
  66. 66. Daily meeting (standup)Цели: Формирование единого представления о прогрессе у всей команды Предотвращение простоев в работе Повышение мотивации (выявление «халявщиков»)
  67. 67. Limit WIPОграничение числа задач, находящихся на стадии выполнения(разработка, тестирование).
  68. 68. Pair programmingРазработка двумя разработчиками за одним компьютером споследовательной передачей клавиатуры между ними.Возможна комбинация с TDD: один разработчик пишет тест –другой реализацию.
  69. 69. Ролевая играИли одни 10мин из жизни команды разработчиков
  70. 70. Задавайте свои вопросыНе стесняйтесь
  71. 71. Фил фри ту аск мо квесченз Email: muyou.prj@gmail.com Skype: eskat0n Twitter: http://twitter.com/eskat0n VK: http://vk.com/eskat0n

×