«Я могу быть не согласным с Вашим мнением, но я готов отдать жизнь за Ваше право высказывать его» (Ф. Вольтер)
В наше время на нас обрушивается огромный поток информации, в котором много хлама, и мало полезного то, что считаю интересным, я вылавливаю, затем пытаюсь проникнуть в суть и записать для себя. Ведь только на бумаге мысли имеют хоть какой-то порядок, в отличие от мыслей в голове, которые жужжат, перебивая друг друга. Кое с чем на тему «Бизнес для увлеченных» я хочу поделиться.
В этой статье я поделюсь основными идеями, которые я вынес из тренинга по Lean Management, который прошел в середине декабря в Питере. Надеюсь, статья будет полезна тем, кто только хочет узнать, что такое Lean, а также тем, кто уже слышал что-то о Lean хочет получить общее представление о нем.
Т.к. идеи Lean применимы к функционированию различных
систем массового обслуживания, я разберу их на примере компании, осуществляющей доставку пиццы.
Недавно дошли руки до превращения записи моего доклада на AgileKitchen в полноценный слайдкаст.
По моему опыту, в Agile-командах процент собираемых метрик, использующихся для принятия управленческих решений, заметно выше, чем в командах, следующих более консервативным моделям разработки. Однако нужно понимать, что каждое измерение неизбежно содержит в себе ошибку. Перед тем, как принять то или иное решение на основе «аномалий» в наблюдаемых значениях, было бы не плохо понять, что стоит за этой «аномалией»: некоторая особая причина, требующая реакции со стороны руководства, или такое поведение является нормальным для рассматриваемой системы?
В слайдкасте дается намек на то, как в результатах измерений отделить свойства системы от особых причин отклонений, и рассказывается об основных ошибках при использовании данных измерений при принятии управленческих решений.
13 января 2012, 21:18
100
Столько слов придумали, все и не запомнишь — Канбан, Скрам, ЭксПи…
Есть ощущение что создается наука из ничего так-же как бухгалтерия в нашем государстве.
А ведь смысл и идея не нова, лежит в основе мироздания, матушки природы и любого производства.
Вот мои простые тезисы по этому поводу:
1. Делай только то что надо сейчас
2. Делай только то что принесет максимальный эффект
3. Если задача сложная разбивай на простые
4. Используй самый простой подход решающий задачу
5. Работай одновременно только над одной задачей
6. Переключайся только когда задача полностью готова
7. Делай работу над ошибками
В идеале готова — в нужном качестве у заказчика и он ей доволен.
Спасибо за внимание!
PS: Если статья понравилась, поднимите карму.
Потому как те кому не понравилась понимаете что сделали…
Прочитал пост "
Проблемы при внедрении Agile" хабрапользователя
adnotum, захотелось предложить несколько решений описанных проблем. Поскольку решения достаточно универсальные, решил оформить их в виде отдельного поста.
Большинство описанных проблем появляется, потому что Scrum является гибким фреймворком, а не полноценной методологией. Это является его недостатком и преимуществом одновременно. «Ванильный» или «кошерный» Scrum описан кратко в
официальном авторитетном руководстве от Сазерленда и Шваббера. «Кошерный» Scrum — это когда ты все делаешь по правилам, а получается не очень вкусно, да и сам процесс не доставляет удовольствия. Такой сферический Scrum будет работать только идеальном вакууме, но его можно и нужно адаптировать, чем собственно этот фреймворк и хорош.
19 декабря 2011, 18:00
60
Как и многие сейчас, мы решили попробовать внедрить agile для развития одного из наших решений. Точнее, поскольку в мире разработки ПО нет «черного» и «белого», мы решили «не внедрить agile», а перейти от использования менее гибких подходов к использованию более гибких.
В данном топике я хотел бы описать проблемы, с которыми мы столкнулись, а также привести соображения, как некоторых из этих проблем можно было бы избежать. Написание топика продиктовано желанием способствовать переводу дискуссии про agile из плоскости «как наконец заставить этих старомодных менеджеров перейти к прогрессивным методологиям» в плоскость «как работать по agile наиболее эффективно».
19 декабря 2011, 13:24
47
Ни об одной теме я не слышал столько негативных отзывов, как об Аджайл. Дескать, он и неэффективный, и не работает, и подходит для ленивых, и придуман для зарабатывания бабла на консультациях, и вообще,
нам аджайл не подходит.
Я здесь не собираюсь никого разубеждать. Я хочу поделиться соображениями, почему большинству компаний
аджайл действительно не подходит.
Мы обычно узнаем о новых методах разработки программного обеспечения, оплачивая консультантов и читая отчеты Gartner. Благодаря им, мы смогли узнать, что для нас должны быть важны:
На недавней конференции я вдоволь наслушалась разговоров трёх менеджеров о самоорганизующихся командах.
«Вы не можете просто так взять и дать волю людям, и предоставить команде всё решать самой. Они же всё испортят! Да, и к тому же, все эти Scrum-мастера, тренеры и самоорганизующиеся команды похоже могут оставить меня без работы», — говорил один из них с обречённостью в голосе.
«Ограничения по времени классная штука», — говорил другой. «Засуньте их всех в комнату, поддайте жару и они начнут творить», — утверждал он.
«О, так это означает, что я могу перетасовывать людей между проектами и они сами просто объединятся в команду и самоорганизуются. Я могу иметь подвижные Scrum команды по первому требованию!» — восклицал третий.
Время развеять некоторые заблуждения.
30 августа 2011, 13:12
23
Последнее время я слышу множество разговоров о разработке, основанной на тестировании (TDD), о разработке, основанной на функционировании (BDD), об экстремальном программировании (XP), о SCRUM-е, о собраниях стоя и ещё Бог знает о каком количестве методик для создания ПО, но все эти методики не имеют смысла, если ПО, которое мы создаём не соответствует требованиям пользователей. Давайте я попробую это объяснить по-другому. Идеальная реализация неправильно составленной спецификации бесполезна. Так же, как и полезность прекрасно написанной библиотеки стремится к нулю, если у неё нет документации. Что-то определённо не так, если ваше приложение не решает поставленную проблему или, если никто не знает как им воспользоваться.
Здорово. И как же нам решить эту проблему? Проще, чем вы думаете, и достаточно важно, чтобы выделить ответ в отдельный параграф.
Первым делом создайте Readme файл.
21 августа 2011, 12:41
28
