Sergey Larionov, Visual management : how to organize effective Agile workspace

Editor's Notes

• #4: No matter the way you lead your project, it is important to know what is going on to understand if it’s going to be successful. Вне зависимости от типа проекта Agile или нет, для его успешного пилотирования необходимо понимать что происходит. What is our goal/mission? Какова наша цель? What is the deadline? Что запланировано и когда мы должны закончить запланированную работу? What is our real current situation? Какова реальная нынешняя ситуация? What is important for us to mesure? Какие показатели нам важны? What do we do to make our working process better? Какие сложности существуют в нашем процессе работы и успешно ли мы их решаем?
• #5: At Toyota it has become a major project-management tool, used especially in product development, to enhance effective and timely communication. Obeya room это рабочее пространство, которое служит эффективной коммуникации и оперативному принятию решений при помощи визуализации и доступности ключевой информации. Obeya in Japanese means 'big room’ where the people involved with developing or planning a new product can come together and where the key information is readily available visually for effective communication and decision making Obeya room c’est une grande pièce dans laquelle les gens développent ou planifient un nouveau produit ensemble et l’information est visuellement disponible pour la communication et la prise de décision efficaces.
• #6: Нью-Йоркская акционерная биржа The New York Stock Exchange : l’importance d’information en temps réel для принятия решений.
• #7: Канал+ лидер кабельного телевидения на французском рынке 1 an PO sur le projet. Я вам расскажу историю ПО по успешной организации рабочего пространства для реализации и ведения проекта.
• #8: Вот так выглядела наша комната к самом начале: 4 человека, стула, рабочий стол, один на всех, дверь, окна, в общем все как положено
• #9: Первый вопрос, который возник: а зачем мы тут все собрались?
• #10: В ОКТО мы разработали фреймворк для определения цели задуманного проекта. Который помогает объединить всех участников вокруг единой цели, а иногда и выяснить что этой «гениальной идей» заниматься не стоит. Как мы это делаем: Определение цели Пользователи и их нужды Наше предложение и конкурентные преимущества Критерии успеха Утверждение идеи
• #11: Следующий вопрос: а для кого мы все это делаем?
• #13: Что мы будем делать?
• #19: Показать прогресс
• #20: Specification and client visibility simplifies communication and improves trust
• #21: Specification and client visibility simplifies communication and improves trust
• #22: Specification and client visibility simplifies communication and improves trust
• #23: Specification and client visibility simplifies communication and improves trust
• #24: Specification and client visibility simplifies communication and improves trust
• #25: Specification and client visibility simplifies communication and improves trust
• #26: Specification and client visibility simplifies communication and improves trust
• #27: Specification and client visibility simplifies communication and improves trust
• #28: Specification and client visibility simplifies communication and improves trust
• #29: Specification and client visibility simplifies communication and improves trust
• #30: Specification and client visibility simplifies communication and improves trust
• #37: Meeting check&work to reimburse the technical debt. Board to ckeck th urgency and the level of debt. Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Common causes of technical debt include (a combination of): Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes. Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications. Lack of building loosely coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs. Lack of test suite, which encourages quick and risky band-aids to fix bugs. Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid. Lack of collaboration, where knowledge isn't shared around the organization and business efficiency suffers, or junior developers are not properly mentored Parallel development at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up. Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done. Lack of alignment to standards, where industry standard features, frameworks, technologies are ignored. Eventually, integration with standards will come, doing sooner will cost less (similar to 'delayed refactoring'). Lack of knowledge, when the developer simply doesn't know how to write elegant code.
• #39: Common information (Sprint calendar, burndown, best practices, etc.) Feature slicing Communication Architecture
• #41: Que fait votre produit ?
• #42: Exchanges Services Impacts
• #44: Business : #users AppStore rating Technical : Development factory #bugs
• #45: Users feedback AppStore rating (рейтинги и отзывы в магазине приложений)
• #46: Users feedback Отзывы и ожидания пользователей в социальных сетях
• #47: Performance Показатели производительности
• #48: Development factory Build state
• #52: Вот и итоговый план, к чему мы пришли за 8 лет работы. Стоя в середине комнаты можно легко и сразу понять что происходит с проектом.
• #53: В действительности это не всегда так красиво как на плане, но практично и адаптировано к окружающей среде.
• #54: В заключении, я хотел бы поделиться некоторыми подсказками по эффективной организации Obeya room, испытанными на собственном опыте.
• #55: В заключении, я хотел бы поделиться некоторыми подсказками по эффективной организации Obeya room, испытанными на собственном опыте.
• #56: В заключении, я хотел бы поделиться некоторыми подсказками по эффективной организации Obeya room, испытанными на собственном опыте.