• Будни Scrum-Мастера: трансформация команды и себя

      Бывало ли с вами такое, что вовремя общения, чтения или изучения чего-то будто осеняет, какая-то из старых или нынешних ситуаций в буквальном смысле предстаёт в новом свете? Со мной это постоянно случается, в этот раз при чтении книги “Азбука системного мышления” Донеллы Медоуз.

      image

      Не так давно довелось попасть в две команды практикующих Scrum. Одна команда не давно стартовала, другая существует уже больше года. У обоих наблюдается одна и та же проблема, команды, а вернее члены команд сползают в старые привычки выполнения работы, когда работали в компонентных командах или функциональных колодцах.

      Один из призывов и советов Донеллы в книге — обращать внимание не на конкретные События, а на Поведение Системы в целом и на то, как устроена, её Структура.

      Событие — это результат проявления определённого Поведения системы, которое можно выявить через наблюдение за происходящими событиями. Наблюдая за поведением: что его вызывает, как этот вызов внутри системы обрабатывается и в итоге рождается проявление в виде события, — можно сделать выводы про Структуру системы, её элементы и взаимосвязи, которые и обуславливают это поведение.

      Здесь и далее команда и система будут синонимами.

      Читать дальше →
    • Как я учусь практикам и ценностям Agile


        Под катом обзор и выводы с ретроспективы MeetUp-а про командную работу и рефлексию, который 3 апреля провела Елена Литвинова.

        Для меня он стал демонстрацией как обычная команда (далее команда 1.0), отличается от подготовленной (команда 2.0).

        Подготовленная означает, что большинство членов команды не просто знакомы с практиками и ценностями Agile, но владеют ими.
        Читать дальше →
        • +10
        • 7,9k
        • 3
      • Стоимость качества в разработке программного обеспечения



          1. Что такое качество в разработке ПО?
          2. Во сколько нам обходится некачественное ПО?
          3. Кто отвечает за качество?

          Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

          Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.
          Читать дальше →
        • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов



            Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки


            В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.

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

            Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.

            Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.
            Читать дальше →
          • Анализ и сравнение своего ИТ-продукта с продуктами конкурентов


              Кто мы (наш продукт) на этой картинке?
              Это результаты работы моего стола на meetup-e Products Moscow Meetup Group от 20 апреля 2017 года, который прошёл в формате «world cafe».

              Как показал опрос 30 менеджеров по продуктам на мероприятии и мой собственный трудовой опыт, не все компании анализируют и сравнивают свой продукт с продуктами конкурентов. Компания часто фокусируется на опыте использования продукта и потребностях текущих клиентов используя их как единственную отправную точку для развития продукта.

              Это чревато тем, что в какой-то момент можно пропустить развилку, рынок пойдёт в одну сторону, а продукт нашей компаний в другую тупиковую ветку. Пример из жизни это компания Polaroid, которая сама произвела революцию на рынке пленочных фотоаппаратов предложив моментальные фотографии, а затем прошляпила следующую революцию связанную с появлением цифровых фотоаппаратов.

              Ещё один пример можно увидеть в сериале «Силиконовая долина», когда в 8 серии 1 сезона, Гевин Бэлсон из Hooli презентует на TechСrunch Disrupt как они взломали алгоритм сжатия Pied Piper, тем самым убив уникальность последнего, лишив права быть первым и технологического преимущества.

              Эти истории демонстрируют собой ответ на вопрос «Зачем изучать продукты конкурентов?», а следующий вопрос «Как анализировать и сравнивать свой ИТ-продукт с продуктами конкурентов?» На meetup-е мы обсудили кейсы участников, их я вам и презентую.
              Читать дальше →
            • Гибкое планирование выпуска релизов 101 (на основе Excel)

              • Перевод
              Предисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.

              А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?

              И эта статья о том как это сделать.


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

              Это лишь один из способов составить план выпуска релизов и уверен, что существует много других вариантов. Я использовал этот подход со многими командами разного размера во многих проектах различной величины и сложности. Во многих случаях я его расширял и дополнял, но основы всегда оставались прежними и хорошо работают. Буду рад комментариям о том, как вы это делаете со своими командами.
              Читать дальше →
              • +11
              • 12,2k
              • 3
            • Реализация процедуры «Планирование выпуска релизов по продуктам» инструментами семейства Atlassian

                Это мой доклад с Meetup-а Московской Atlassian User Group от 1 марта 2017 года

                Контекст и задача


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

                Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.

                Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.

                Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.

                Бизнес-логика



                Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).
                Читать дальше →
                • +11
                • 12,7k
                • 2
              • Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)



                  Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга... Joel Spolsky

                  Статья Джоэла о Пяти мирах (программного обеспечения) вышла в 2002 году. За прошедшие 14 лет успели образоваться новые миры: Мобильные приложения и Облака, — но соль статьи осталась неизменной.

                  Одна и та же технология в разных условиях будет давать разную эффективность.

                  Когда мы обсуждаем опыт применения какой-то технологии, мы часто не обращаем внимания на контекст её применения из-за этого возникает недопонимание, неверное толкование и применение технологий.
                   
                  Представьте, мы на Земле, наш друг Марк на Марсе. У нас стоит одна и та же цель, вырастить в своём Мире урожай картошки. Технологию будем использовать одинаковую «посадка в грунт», а результаты получим разные так как влияние факторов/переменных разное для каждого из Миров. Это кажется очевидным, но факты из жизни говорят об обратном.

                  Это Марк

                  Читать дальше →
                  • +12
                  • 11,3k
                  • 9
                • Управление задачами на разработку. История из жизни

                    О том, когда задач больше чем ресурсов на их выполнение, очередь задач со временем увеличивается и часть из них можно смело назвать «дурацкими».
                    Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.
                    О
                    • управлении потоком задач на разработку,
                      Как избавится от «дурацких» задач?
                    • управлении расходами на разработку,
                      Как определить и выбрать самые выгодные задачи?
                    • распределении ограниченных ресурсов.
                      Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

                    Читать дальше →
                  • Каким должно быть ТЗ на Корпоративную ИС?

                    Представьте, что у вас есть корпоративная информационная система в развитие которой вкладывается 200+ млн. рублей ежегодно. С момента внедрения документация на систему превратилась из одного Технического задания на 600 страниц в 300 Технических заданий, у каждого из которых есть дополнение в количестве от 1 до 10 штук, и теперь она занимает объем 3 офисных шкафов и это ещё не конец… Фабрика по производству ПО исправно и ритмично (с периодичностью в месяц) выпускает обновление системы и документирует изменения.

                    image

                    Ребята, которые разрабатывали 34-й ГОСТ явно не рассчитывали на то, что дело может принять такой оборот. Да и книги по гибким методологиям разработки тоже не дают каких-то рекомендаций как с этим быть.

                    Всё что нам казалось не очень важным тогда, со временем и в масштабе приобрело вид серьезной проблемы.

                    • Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
                    • Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
                    • Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?
                    Читать дальше →