Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

14.01.19

Управление проектом - Канбан и поставка ценности

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

Так что я не буду здесь говорить что-то из серии "все немецкие компании..." или "все российские разработчики" - понятно, что везде всё очень по-разному, и нельзя сказать, что в одной стране лучше чем в другой. Так что опишу здесь вкратце работу одной эффективной команды, опыт которой, на мой взгляд, может быть полезно перенять.

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

1. Канбан-доска - основной инструмент сопровождения разработки 

Канбан-доскаПо отзывам программеров и менеджеров существенно повышает эффективность работы и упрощает понимание ситуации с проектом. По этой доске задачи переходят из одного состояния в другое, и все могут наглядно увидеть ход проекта. Канбан-доска может быть разной - у некоторых отделов - это огромная физическая доска на колесиках, по которой тикеты переходят по классическим трем колонкам  "Offen - in Arbeit - Erledigt", ой, то-есть, простите "To do-Doing-Done". Кстати, рачительные немцы заодно эту доску используют в целях перегородки в комнате - не пропадать ли добру. И, опять же, вот такая, стоящая посреди прохода и видимая всем потенциально заинтересованным лицам доска - это тот самый, соответствующий ценностям Agile "информационный радиатор". Здесь позволю себе небольшое лирическое отступление (уже не про немецкую практику, а про гибкие подходы к управлению в целом) - "информационный радиатор" - это термин, введенный изначально в английском языке (где он смотрится чуть логичнее, чем в русском) в качестве противопоставления термину "информационный рефрижератор" (то бишь холодильник). Имеется в виду следующее: мы традиционно стараемся всю информацию по нашей работе по максимуму закрывать и изолировать. Как будто запирать внутри холодильника - чтобы кто не надо ничего лишнего не узнал. Дабы начальство лишних вопросов не задавало, коллеги советами не мучили, наши ошибки были со стороны не заметны и т. п. Так вот, современные Agile подходы к разработке, которые я всячески продвигаю и рекомендую, призывают практиковать противоположный подход к распространению информации: все, что не является явно конфиденциальным и коммерческой тайной - распространять как можно шире, и предлагать на рассмотрение всем заинтересованным лицам. Про преимущества такого подхода я немного расскажу ниже, когда буду говорить про командную работу.
Но канбан-доска, конечно же, необязательно будет физической, которую потрогать можно. Большая часть разработчиков в том самом немецком банке используют специальное ПО. А именно Jira от Atlassian - кстати, как и большинство других сторонников Agile - если посмотреть отчет Annual report от VersionOne, то Jira лидирует среди используемых программных продуктов.
В России, заметим, картинка другая - это видно, например, по отчету от ScrumTrek. Самодельное программное обеспечение лидирует.        
Одно из удобств Jira - интеграция с другими продуктами от Atlassian, в частности в банке используют Confluence - как инструмент для управления проектами и wiki-систему с документацией по продуктам, и BitBucket - как систему, предоставляющую доступ к базе данных с разными версиями.
Предполагаю, что основная причина того, что российские пользователи существенно реже используют продукты Atlassian, чем западные коллеги  - достаточно высокая стоимость использования. Я, например, наслышана про российские компании, например, использующие из экономии одного пользователя "на всех" - чтобы не платить за много лицензий сразу. Это сразу убирает половину плюсов от применения продукта - гораздо хуже видно, кто чем занимается. Но все равно оказывается достаточно удобным. Но это было лирическое отступление, давайте вернемся в немецкий банк.

2. Канбан-доска гибко адаптируется под нужный бизнес-процесс 

Бизнес-процессКанбан-доска при доработке функционала приложений на самом деле, включает в себя вовсе не три вышеупомянутых статуса, а гораздо больше, и покрывает весь процесс работы с задачей.
Перый столбец: Бизнес-запрос. Хотелка от бизнеса, чего хочется получить на выходе. Оформленная в идеале в формате user story "как __________ мне нужно ___________ чтобы _____________ " .

Второй столбец: Технический концепт. Здесь хотелка от бизнеса уже превращается в конкретное техническое задание. На самом деле, ответственный этап - я была свидетелем тому, что ошибки, допущенные на этапе переформулирования бизнес-запроса в технический концепт приводили к тому, что много месяцев дальнейшей разработки проходили впустую - в результате получался ненужный заказчику продукт, который приходилось переделывать. 

Зато, наоборот, если технический концепт сформулирован правильно - дальше в третьем столбце: Разработка, работа уже понятная и несложная, и с ней справится любой толковый Junior-программист. Кстати, в Германии сама по себе профессия программиста считается не очень сложной, и не требующей высшего образования. Соответствующую специальность можно получить по итогам 3-летнего обучения в колледже, для поступления в который необязательно получать полноценное среднее образование в гимназии, а достаточно более короткой и простой реальной школы. Ну, а по выпуску из колледжа разработчик уже будет продолжать свое образование в ходе профессиональной карьеры - разнообразные курсы повышения квалификации (от предлагаемого работодателем "обучения во время ланча", сопровождаемого бесплатными бутербродами, до выездных учебных курсов с экзаменами) предлагаются тем, кто хочет расти и развиваться в своей специальности. И, разумеется, серьезные профессионалы с соответствующим образованием тоже ценятся. 
Важный момент - в противовес бытующему в некоторых компаниях стереотипу "программисты не тестируют" разработчик ответственен за то, чтобы передать на тестирование заведомо работающий продукт. Поэтому первый (или, если хотите, нулевой) этап тестирования, который осуществляется непосредственно разработчиком, прежде чем передать работу тестировщикам, включается в этап разработки. 
Четвертый столбец: создание концепта тестирования. На этом месте структура канбан-доски перестает быть линейной, потому что концепт тестирования - то есть написание алгоритма для последующего тестирования, создается параллельно с самой разработкой. В некоторых проектах, преимущественно при создании продукта с нуля, применяется технология test driven development (TDD) - когда сначала пишутся тесты, а потом уже начинается непосредственно разработка. TDD в Германии вполне себе уважают, но в описываемой нами истории, когда речь идет о доработке и переработке уже созданного продукта, его применение оказывается нецелесообразным - поэтому тесты придумываются уже параллельно с разработкой. Задача создания концепта тестирования, что логично, считается более квалифицированной, чем собственно разработка. 

Работы в следующих трех столбцах тоже могут идти параллельно, и, что характерно, ревью кода и тестированием практически всегда занимаются разные люди. И все эти разные люди - не тот, кто занимался непосредственно разработкой.
Пятый столбец: написание код ревью - то есть отсмотр кода более опытным коллегой с комментариями про надлежащие исправления. Опыт показывает, что практика код ревью повышает качество кода. Фокус внимания специалиста, осуществляющего эту работу, заключается во-первых, в выявлении явных алгоритмических дырок. А во-вторых, в проверке его логичности и понятности не только автору, но и экспертам сопровождения, которым этот продукт в дальнейшем поддерживать. Как я уже говорила раньше, те, кто пишут код ревью не проверяют работоспособность кода, их внимание - к "хорошему тону" программирования (см. статью про ректальное программирование на Инфостарте - вот в немецких банках его всячески выкорчевывают).  

Шестой столбец: тестирование. Поскольку к программному обеспечению в банковской сфере требования серьезные, порядок тестирования как правило жестко регламентирован. Порядок тестирования более менее стандартный: обычное, интеграционное, регрессионное, пилотный проект. Как и на других этапах, здесь предполагается тесное сотрудничество разработчиков и тестировщиков. Благодаря плоской структуре команды и отсутствию “эффективных менеджеров”, рабочие совещания по ошибкам в ходе тестирования как правило бывают немноголюдными и конструктивными. 

Седьмой столбец: документирование. Эти работы тоже идут параллельно с тестированием. Как и многие другие команды, практикующие принцип Agile “Работающий код важнее совершенной документации”, документирование здесь осуществляют после разработки, а не на этапе технического задания.  Сюда входит как написание пользовательской документации для клиентов, так и подготовка инструкций для экспертов службы сопровождения.

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

3. Повышенное внимание командной работе 

Довольно много внимания уделяется тому, чтобы люди, работающие вместе ощущали себя единой командой. Этому помогают, в частности, регулярные (чаще всего еженедельные) встречи отдела, посвященные обмену информации о работе. Каждый разработчик рассказывает о своих задачах на канбан-доске - как об уже выполненных, так и о тех, которые он планирует взять в работу. В результате получается, что каждый имеет хотя бы общее представление о работе своих коллег. Это создает чувство единой команды, мотивирует на более интенсивную работу (ну, по-крайней мере, в условиях немецкого банка мотивирует - я не берусь предсказывать, что будет при перенесении практики в вашу организацию, честное пионерское). Кстати, в Германии вообще принято работать в полную силу. В течение всего рабочего дня никому не придет в голову заняться личными делами или посидеть в соцсети - не то, чтобы это кто-то контролировал, но просто не принято. И еще один момент - сотрудники стараются уйти от многозадачности и минимизировать перескакивание с одной задачи на другую - потому что, как известно, на переключениях теряется очень много времени. Хотя не буду лукавить, совсем уйти от него не удается даже у педантичных немцев - очень часто один и тот же сотрудник работает на нескольких проектах одновременно, просто занимается вопросами последовательно (в один день одной, на следующий - другой), а не пытается в один день решить много задач.
Один из плюсов регулярного обмена информацией заключается еще и в том, что имея общее представление о работе друг друга, людям проще "подхватить" проект коллеги, если вдруг возникает такая необходимость. Например, в связи с внеплановым больничным или выходом в декрет (в декрет в Германии, кстати, папы часто уходят наравне с мамами - это вполне принятая практика). Ну и когда через некоторое время вам поручат новую для вас задачу - вспоминая прошлые совещания, вы сможете понять, кто из ваших коллег уже занимался аналогичными запросами и с кем можно посоветоваться.
Еще один момент - минимальное вмешательство руководства в повседневную работу разработчиков. У проектов (по-крайней мере, не очень масштабных) редко бывают менеджеры в традиционном смысле этого слова. То есть у каждого проекта есть ответственный, но чаще всего это один из разработчиков. Практика показывает, что когда проектом рулят менеджеры "далекие" от программирования, они гораздо чаще выдвигают невыполнимые требования и не понимают "духа" запроса клиента, фиксируясь на "букве" требований, чем РП, выросшие из разработчиков. 

Анекдот в тему:
Сотрудники компании едут в автобусе на корпоратив за городом. Каждые 10 минут мужчина, сидящий в 3–м ряду, спрашивает у водителя, сколько километров проехали и когда он планирует быть на месте. Ответы водителя мужчина заносит в компьютер. 
Молодой сотрудник, сидящий неподалёку, спрашивает у рядом сидящего коллеги: "Кто это и зачем он все время дергает водителя?"
"Это — новый эффективный менеджер, недавно наняли," — отвечает опытный коллега. "Ему поручили обеспечить доставку сотрудников на корпоратив, вот он и думает, что управляет процессом".

Кстати сказать, подход немцев к рефлексии немного отличается от американского. Американцы регулярно проводят выделенные ретроспективы, и вообще американские книги призывают до 40% (!!!!) времени заниматься рефлексией и размышлениями о том, как улучшить процессы. В Германии, разумеется, тоже усиленно думают, как работать эффективнее или хотя бы не повторять грабли прошлых проектов в следующий раз. Но (по-крайней мере, в тех командах, о которых я рассказываю) рефлексия здесь в большей степени вплетена в повседневную работу - какие-то решения и предложения обсуждаются на рабочих совещаниях, фиксируются в рабочей рассылке, в документации и т. п. - в том смысле, что для анализа не организуются отдельные мероприятия. 

Еще одно условие плодотворной работы - как я уже говорила выше, достаточно плоская структура. Команда, в которую входят и разработчики, и тестировщики, и менеджеры, и эксперты техподдержки, и продажники (выступающие в роли владельцев продукта), воспринимает себя как единое целое. И сотрудники могут взаимодействовать напрямую, а не через менеджеров - что снижает потери информации и ускоряет решение вопросов.   
В-общем, команда - решает всё. Так что желаем вам в новом году хорошей и плодотворно работающей команды!

Большое спасибо за помощь в подготовке этого материала сотрудникам немецкого банка, пожелавшим вместе с названием банка остаться неизвестными!..  

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

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

См. также

Канбан и поставка ценности Бесплатно (free)

Менеджерам постоянно приходится отвечать на вопрос «когда сделаете?» или «когда будет готово?». Но любой менеджер знает – чтобы гарантированно уложиться в срок, нужно заложить трехкратный запас времени. Заказчики этот принцип тоже знают и стремятся срезать срок, насколько это возможно. Обе роли «торгуются» и давят друг на друга, пока кто-нибудь не продавит свое решение. В итоге недовольными, как правило, оказываются все. Попробуем прервать этот порочный круг, используя немного математики и теории вероятностей. Расскажем, как прогнозировать срок задачи на основе объективных данных с вероятностью 80%.

06.05.2024    1818    0    babr79    0    

5

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4745    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3720    0    user1853337    8    

29

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6420    0    stnslv    5    

25

Канбан и поставка ценности Бесплатно (free)

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

23.05.2022    2877    0    Selikhovkin    1    

6

Канбан и поставка ценности Бесплатно (free)

Директор по проектам Инфостарт Мария Темчина на конференции Infostart Event Post-Apocalypse делала большой доклад о внедрении Канбан-систем. В преддверии старта курсов Марии по управлению ИТ-проектами редакция Инфостарт решила поделиться с читателями докладом о работе ИТ-команд с Канбан. В статье вы узнаете, зачем внедрять такую систему работы, и как она помогает договариваться разработчикам и бизнесу.

22.04.2022    4308    0    MariaTemchina    1    

19

Канбан и поставка ценности Бесплатно (free)

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    6018    0    MariaTemchina    17    

25

Канбан и поставка ценности Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Россия Бесплатно (free)

Слово "Канбан" слышали все, кто работает в производстве, в поддержке и в ИТ-разработках. В этой статье я попробую рассказать про Канбан подробно, обобщить принципы и опыт (мой и ближайшего окружения) по внедрению на практике этой системы с упоминанием возникающих при этом "граблей" и рекомендаций по борьбе с ними.

08.08.2018    33905    0    MariaTemchina    66    

85
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Vladimir Litvinenko 2895 14.01.19 19:13 Сейчас в теме
Дедушка Роберт Мартин был бы доволен и меньше бы ворчал, прочитай он это )) Жаль, что сотрудники банка отказались от такой отличной рекламы и названия компании мы не узнаем.

Спасибо за публикацию! И также за все предыдущие - все в закладках.
Kochergov; PLAstic; MariaTemchina; +3 Ответить
4. MariaTemchina 1619 14.01.19 20:41 Сейчас в теме
(1)
(1)
Жаль, что сотрудники банка отказались от такой отличной рекламы и названия компании мы не узнаем.

Ой, немцы такие бюрократы, что на согласование публикации и утверждение, что относится к non disclosed information, а что нет - ушло бы страшно представить сколько времени!...
Kochergov; +1 Ответить
2. kurpyaev 14.01.19 19:25 Сейчас в теме
Мы используем в работе https://trello.com/. На их ресурсах есть очень много полезной информации по организации Канбан-досок, плюс куча полезных плагинов. Даже сделали небольшую интеграцию между нашей 1С и Trello. Рекомендую)
3. MariaTemchina 1619 14.01.19 20:39 Сейчас в теме
(2)
Канбан-досок, плюс куча полезных плагинов. Даже сделали небольшую интеграцию между нашей

Кстати да, тема создания канбан-досок, интегрированных с 1С уже не первый раз всплывает на Инфостарте, народ пишет всякие надстройки и использует. Надо будет как-нибудь сделать отдельный обзор на эту тему...
Kochergov; PLAstic; +2 Ответить
5. Xershi 1547 14.01.19 20:57 Сейчас в теме
(2) как раз в своей работе тоже его использую. Было бы здорово если бы поделились наработкой или сделали публикацию для работы с трелло.
6. MariaTemchina 1619 15.01.19 11:13 Сейчас в теме
(5) Ага, по моему опыту - Trello - самое часто используемое из бесплатного. Предположила, что оно является конкурентом Jira - и тут осознала, что Atlassian (разработчик Jira) ее купил в 2017 году, видимо, под лозунгом "если безобразие невозможно прекратить, его нужно возглавить..."
user811769; +1 Ответить
7. Fragster 1149 16.01.19 12:06 Сейчас в теме
У меня в https://infostart.ru/public/556514/ получилось 7 статусов:
Новый, ожидание, в очереди, в работе, подтверждение, завершена, отменена.


Сначала задача попадает в Новый, из нее либо в очередь/работу (если все понятно, есть ресурс или критическая важность, например ошибка), либо в Ожидание (бэклог?), либо в отмену. Задачи в ожидании периодически анализируются и переносятся в очередь, далее в работу. потом в подтверждение (перенос реализации в тестовую базу) и в завешенные при накатывании на прод. в теории подтверждение можно разделить на приемку и ожидание накатывания на прод, но я не стал делить. Равно как и другие статусы дополнить - типа требуется анализ, согласование, ожидание обратной связи от заказчика, но мне показалось, что это будет избыточным.
MariaTemchina; +1 Ответить
8. MariaTemchina 1619 16.01.19 12:53 Сейчас в теме
(7) Спасибо за опыт, интересно.
в теории подтверждение можно разделить на приемку и ожидание накатывания на прод, но я не стал делить. Равно как и другие статусы дополнить - типа требуется анализ, согласование, ожидание обратной связи от заказчика, но мне показалось, что это будет избыточным.

Ну, зависит от целей применения. Если доска предназначена для однозначного понимания "на чьей стороне мячик" - то, может быть, дополнительные статусы и целесообразны - чтобы было понятно, на каком этапе задача "зависла", и какие шаги надо предпринять, чтобы она "покатилась дальше"...
9. leemuar 13.02.19 15:04 Сейчас в теме
Спасибо за статью.
Не могу писать в личку, пишу в комментариях:

- в разделе "1 Канбан доска" опечатка: не BigBucket, а BitBucket
- там же - BitBucket это не система контроля версий, а сервис хостинга репозиториев. Системы контроля версий - это Git/Mercurial, эти программы создают некоторую базу данных (репозиторий), а BitBucket эти базы данных (репозитории) хранит и предоставляет к ним доступ

Замечания несущественные, пониманию основной идеи статьи никак не мешают
10. MariaTemchina 1619 13.02.19 15:05 Сейчас в теме
11. o.nikolaev 215 13.02.19 22:36 Сейчас в теме
Я извиняюсь, "немецкий банк" и попадание в оный, это случайно не через Luxoft?
12. MariaTemchina 1619 14.02.19 12:19 Сейчас в теме
(11)
Во-первых, не могу сказать, согласно договоренностям про NDI.
Во-вторых, нет.
13. o.nikolaev 215 14.02.19 17:09 Сейчас в теме
(12) Благодарю за ответ.

Лирическое отступление...
Удивительная это вещь - NDI. Старик Оруэлл про что-то такое писал помнится. Впрочем, все суета.
Оставьте свое сообщение